RAGチャットは作れた。それでも「答えられない」壁があった

RAGを使ったチャットボットは、仕組みとしては比較的早く形になります。私たちの案件でも、Cognitoでログインし、セッションを呼び出し、search toolでvector storeを参照して回答を返す、というところまでは想定どおりに動作しました。

「動く」ことと「使える」ことの間にある壁

問題が見えてきたのは、実際のデータを投入してからです。公開資料をパワポ形式に変換した62ファイルをデータとして使ったところ、単純な質問に対してすら、うまく答えられないケースが出てきました。仕組みが動いていることと、実際の質問に答えられることの間には、思っていた以上の距離がありました。

boto3が使えない部分があった

インフラの構築自体はboto3で進めていましたが、一部のmanaged vector storeはboto3に対応しておらず、AWSコンソールから手動で作成する必要がありました。自動化を前提に組んでいた構築フローの中に、手作業を挟まざるを得ない箇所が残った形です。

評価データを自分たちで作ったから見えたもの

「答えられない」という壁がなぜ見えたかというと、評価用のデータセットも生成AIを使って自分たちで作成していたからです。公開されている企業の開示資料PDF60ファイルをClaude Codeでエージェンティックに変換し、240ファイルを生成、そこから質問と回答の対を120問、あわせて自動作成しました。この評価データセットで実際にテストしたことで、単に「動いている」だけでは見えなかった、回答できない質問のパターンが明らかになりました。

1万件規模のドキュメントに向けた仮説

1万件以上の社内ドキュメントから情報を拾う設計としては、あらかじめ要約を作っておくことで、RAG時に見つけやすく、絞り込みやすく、コストも抑えられるのではないかという仮説を検討しています。ただし、これは短期の案件では要素技術の開発そのものになりかねません。既存のサービスの組み合わせだけで完結できるかどうかが、実際には判断の分かれ目になります。

まとめ

RAGチャットは、仕組みとして動かすところまでは比較的たどり着けます。しかし、それが「使える」水準に届いているかどうかは、自分たちで評価データを用意し、実際に問いを投げてみるまで分かりません。私たちにとっても、この評価の工程を飛ばさないことの重要性を、あらためて確認する経験になりました。