社内文書を入れたのに答えられない——RAGの検索品質を切り分ける

「出張の精算期限はいつ？」と尋ねる。社内アシスタントは自信をもって答えたが、根拠として示したのは二年前の規程だった。担当者は回答文を調整しようとする。別の人は、資料をもっと登録しようと言う。

その前に、止まった場所を確かめたい。利用者が閲覧してよい文書だったか。検索対象に最新版が入っていたか。規程の本文と例外が一緒に取り出されたか。取り出せていたのに、回答で落としたのか。これらは別の問題であり、直す担当も方法も違う。

RAG（検索拡張生成）は、質問に関係する情報を探し、その情報を渡してAIに回答を作らせる仕組みである。業務の感覚では「社内資料を探してから答えるアシスタント」に近い。文書を登録した事実は、必要な文書を検索できたことも、その文書から正しく答えたことも示さない。

一つの「精度」を、五つの確認へ分ける

回答が弱いときは、自分が利用を認められた質問と資料の一件を、次の順に追う。確認できない記録や設定は、推測せず担当へ渡す。

最初から完璧な正解文を大量に作る必要はない。現場で実際に出る質問を選び、期待する根拠文書、必ず含めたい事項、答えず人へ渡す条件を記録する。この評価用質問集が、改善前後を同じ基準で見る台本になる。

「精度が上がった」という感想ではなく、一件ごとにどの層で外れたかを記録する。すると、資料を増やすべきか、権限を直すべきか、回答の作り方を直すべきかが見えてくる。

権限は、検索品質より前に決める境界

権限制御は、利用者ごとに閲覧や取得を許す情報の範囲を決める仕組みである。検索結果をよくするために、全利用者へ全資料を見せてよいわけではない。逆に、必要な規程への権限がない状態を、回答の言い回しだけで直すこともできない。

権限と検索は、順番で分けると分かりやすい。まず、その利用者が取得してよい文書の集合を決める。その許可された集合の中から、質問に関係する箇所を検索する。関係者限定の資料が候補に出たなら、それは「よく探せた」ではなく、権限の境界を確認する問題になる。

評価記録には、質問文だけでなく、利用者の役割も残す。同じ質問でも、総務担当と一般社員で表示してよい根拠が違う場合があるからだ。ここで決めるのは個別の権限設計そのものではない。検索品質の試験を、権限が曖昧な資料集合の上で始めないことである。

分割の良し悪しは、必要な一節がそろうかで見る

索引は、登録した文書を検索しやすい形に並べた情報である。検索は、この索引から質問に近い候補を取り出す。必要な文書が候補にないなら、回答生成より前に、検索対象と取り出し方を調べる。

そのとき焦点になるのが文書分割だ。長い規程を検索用の小さな単位へ区切る処理だが、単に同じ文字数で切ればよいとは限らない。精算期限だけが取れ、直後の例外条件が別の断片に離れれば、回答へ渡る情報が欠ける。反対に大きすぎる断片では、関係の薄い記述が混ざり、必要な箇所を見分けにくくなる。

元の文書名、章見出し、対象部署、版、発効日などのメタデータは、断片がどこから来たかを示す手がかりになる。質問ごとに、本来必要な断片が候補へ入ったか、前提と例外がそろったか、関係の薄い候補ばかりになっていないかを見る。

必要な文書が候補にないなら、回答の文章を磨く前に、検索対象と分割を直す。

鮮度は「新しい文書がある」ではなく反映で確かめる

正しい検索でも、検索対象が古ければ古い答えを返す。鮮度は、現行の正本と、検索に使われる索引の版が対応している状態である。共有フォルダに最新版があることと、その内容が検索へ反映されたことは別の確認だ。

文書管理者は、どれが正本か、いつ発効したか、旧版をいつ失効させたかを示す。仕組みの担当は、追加・変更・削除がいつ索引へ反映されたかを示す。評価では、取得した断片に文書名、版、発効日が付いているかを見て、正本と照合する。

古い版が出たときに、すぐ検索方式のせいだと決めつけない。正本の指定が曖昧、更新が未反映、旧版が検索対象に残っている、といった原因を分ける。更新頻度や失効の扱いは業務によって異なるため、自社の文書管理手順から決める必要がある。

ただし、「昨年の出張にはどの規程が適用されたか」という質問なら、必要なのは当時の版である。旧版を一律に削除するのではなく、現行の手続きを尋ねる質問と過去時点を尋ねる質問を分け、どの適用期間の資料を探すかまで評価用質問集に残す。

文書が取れた後に、生成を評価する

必要な現行文書が候補にあり、利用者の権限にも問題がない。それでも、期限だけ答えて例外を落とす、文書にない理由を補う、根拠と異なる結論を出すことがある。ここで初めて回答生成を点検する。

見るのは、質問に必要な事項がそろっているか、取得した文書の範囲に沿っているか、利用者が根拠箇所を確認できるか、資料に答えがないとき保留できるかである。忠実性とは、回答が取得した資料の内容から外れていない度合いを指す。文章が自然なことや、利用者の期待に近いこととは別の評価だ。

Amazon BedrockのRAG評価指標に関する公式文書 は、検索した情報の関連性・必要情報のカバーと、生成した回答の正しさ・完全性・忠実性・引用の評価を分けている。この分類は、検索と生成を別々に見る根拠になる。ただし、そこで示される評価方法やAIによる採点が、自社の正解を保証するわけではない。他のサービスでも同じ数値になるという資料でもない。

影響の大きい規程や例外の多い質問は、文書管理者と利用部門が評価用質問集を確認する。取得結果を見ずに回答だけ採点すると、直す場所を取り違える。

利用範囲を決める担当へは、層ごとの確認結果を渡す。権限と正本を確認できないなら保留する。検索できる質問が限られるなら対象業務を絞る。文書は取れるが生成が不安定なら、根拠表示と人の確認を条件にする。問題が残ったことを導入全体の失敗にせず、利用範囲と次の修正へ変える。

答えられなかった一件をたどり、直す場所と担当を決める

社内文書を入れたのに答えられないとき、「AIの精度」という一語から離れる。誰が読めるか。正本が検索対象に入ったか。適切な単位で取り出せたか。最新版が反映されたか。取得した内容に沿って答えたか。この順に一件を追えば、直す場所と担当が決まる。

次に答えが外れたら、質問と期待する原文、実際に取れた文書と回答を一件だけ並べてみたい。自分に見える結果から確かめ、見えない権限設定や索引の状態は担当へ質問する。資料の量を増やす前に、どこを直すかを絞る材料ができる。

参考資料

• Amazon Bedrock User Guide: RAG evaluation metrics