コールセンターRAGの検索精度を評価する　正解FAQに届くテストセットの作り方

Amazon Bedrockのナレッジベース評価には、生成を切り離して検索だけを対象にする評価ジョブがある。検索のみ評価のデータセット仕様では、質問と正解（referenceResponses）を組にしたJSON Lines形式で、1つのデータセットに最大1,000問まで入れられる。つまり主要なクラウド基盤が、RAG（検索拡張生成。質問に関係する社内文書を探してから回答を作らせる仕組み）の評価を「検索」と「生成」の二段に分けて扱い始めている。では、あなたのセンターのFAQ検索AIが間違った回答を返したとき、検索が外れたのか、生成が壊れたのか、切り分けられるだろうか。

本稿の立場を先に書く。回答の誤りの調査は、生成された文章ではなく、その手前の検索結果から始めるべきだと見ている。検索が正解FAQに届いていなければ、生成がどれほど流暢でも正しい回答は出ない。そのために要るのが、実際の質問と期待FAQを組にしたテストセットである。本稿では、その作り方と回し方を4つの手順に分け、編集部（相原ことは）の提案として示す。生成された回答文そのものの採点は本稿では扱わない。

手順に入る前に、なぜ検索から固めるのかを整理しておく。検索部分の良し悪しは、RAG評価の解説が整理するとおり、上位k件に正解が入っているか（再現率）、上位k件に無関係なものが混ざっていないか（適合率）という、検索エンジンの世界で使われてきた指標でそのまま測れる。正解さえ決めてあれば、採点は機械的に再現できる。一方、生成された文章の採点は人手では追いつかず、AIに採点させる方法が広がっているが、採点AIの偏りを定量化した研究は、回答の提示順や長さ、自分が生成した文への甘さなど、採点者側の偏りを複数報告している。生成の採点は便利だが、真値ではない。だから、機械的に白黒がつく検索の回帰テストを先に作る。これが本稿の骨子である。

実際の質問と期待FAQを組にする

テストセットの材料は、作文した想定質問ではなく、オペレーターや顧客が実際に打った質問である。問い合わせログやオペレーターの検索ログから原文のまま拾い、その質問に対して「このFAQが出てくるべき」という正解の文書IDを担当者が付ける。この1行が1テストケースになる。

ここで2つの偏りに気をつけたい。1つは頻度の偏りで、ログの上位から機械的に取ると、呼量の多い定型質問ばかりのセットになる。件数は少なくても間違えると損害が大きい質問、たとえば解約、障害、料金請求の類を意図的に混ぜる。もう1つは鮮度の偏りである。ナレッジ運用の方法論KCS v6は「利用こそがレビュー」という技法で、記事は使われるたびに見直されて初めて品質が保たれると説く。テストセットも同じで、作った時点のFAQ構成に固定したままでは、半年後には存在しない記事を正解に指定し続けることになる。

もう1点、ログの転用には情報管理の確認が要る。実際の質問文には氏名・契約番号・通話の経緯が混ざる。テストセットは評価のたびに複製されて出回りやすいファイルなので、正解付けの前に固有情報を落とす工程を挟み、評価基盤に社外サービスを使うなら持ち出し可否を先に確認しておく。