回答精度50%から最大99%へ、中小企業向けITサポートのRAGチャットボット

検索対象の文書にあらかじめ下処理を施し、検索が効く状態に整えてから生成側へ渡すという順序が、この改善の土台になっています。RAG（外部の文書を検索してAIの回答に使う仕組み）が振るわないとき、原因は回答の言い回しよりも検索で必要な文書を拾えていないことにあり、拾えなかった情報は生成側でどれだけ工夫しても補えません。文書を整えるという地味な手当てを先に置いた判断が、後段のプロンプト調整を意味のある作業へ変えたと考えられます。

ユーザーの質問をそのまま検索にかけず、いったんAmazon Bedrockで要約して検索クエリを組み立て、Amazon Kendraで引いた文書からAmazon Bedrockが回答を生成するという二段構えも効いています。現場から寄せられる問い合わせは前置きや曖昧な指示語を含みがちで、検索語としては素直ではありません。質問を受け取る役と検索する役を分けたロジックは、この落差を吸収する狙いだったのでしょう。あわせてプロンプトを練り直し、大規模言語モデルをClaude 3.5 Sonnetへ引き上げたことで、参照できる文書がない質問には答えを作らないという線引きも回答の設計に組み込まれました。

改善の試行回数を増やす仕組みを開発と並行して用意した点も、この案件を特徴づけています。1回の精度検証には100問程度の質問を用意し、生成された回答をあらかじめ作成した正解データと突き合わせる必要があり、人手なら半日仕事。質問の作成からドキュメントの投入、回答の評価までを自動化するスクリプトは当初のスコープ外でしたが、支援側からの提案で組み込まれました。毎日30分程度の朝会でその日の課題を翌日に持ち越さず片づけ、開発フェーズと検証フェーズにそれぞれ適した担当者を立てる進め方も、3カ月という限られた期間に密度を持たせたはずです。