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

IT withのヘルプデスクで標準提供されていたAIチャットボットは、同社がこれまで蓄積したIT管理のノウハウを体系化したデータをもとに答える仕組みで、返せるのはどの企業にも当てはまる一般的な内容にとどまっていました。利用企業からは、自社が実際に導入しているシステムや自社のIT業務に沿って答えてほしいという声が寄せられます。ところが自社の技術検証で得られた回答精度は50%程度で、社内では当初、そのあたりが限界だと受け止められていました。

編集部の見立てでは、ここでの壁は生成AIの賢さではなく、利用者の質問と社内文書のあいだをどう橋渡しするかという設計側の問題だったのではないでしょうか。一般的な回答を返すボットは、答えの幅が狭いぶん外しにくい。対して顧客ごとの文書を相手にするとなれば、話し言葉の質問をそのまま検索に流した時点で必要な一文へ届かず、生成の段階では取り返しがつきません。50%という数字は、AIの限界というより、検証の入口に立った時点の値だったと捉えるほうが自然です。

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

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

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

ドキュメントへの下処理を加えた段階で、当初50%程度だった回答精度は一気に80%以上へ上がり、最終的に回答可能な質問への精度は最大99%に達しました。参照できるドキュメントがない質問を判定する精度も最大87%まで改善し、「検索対象のドキュメントがありません」と明示できるようになった点はサービス品質に直結します。精度検証も1回あたり半日から30分程度へ短縮されました。支援終了後も開発と検証は続き、2025年3月末に顧客の社内ドキュメントを検索対象とする新AIチャットボットがリリースされ、既存顧客からトライアルの申込みが寄せられています。