社内ナレッジAIが間違えたときは、原資料に正解があるか、正しい資料が検索されたか、検索結果を回答が正しく使ったかの順に見ます。この三段階を分ければ、資料の更新と検索設定の調整を取り違えずに済みます。
対象は、社内規程や手順書をAIで検索・質問できるようにした中小企業の現場責任者です。導入方式の比較は社内ナレッジAIの作り方で扱っています。ここでは運用中に「回答が違う」と報告された後の切り分けに絞ります。
まず、間違いを一件の記録にする
「AIの精度が悪い」だけでは、担当者が再現できません。質問した人の名前を広く共有する必要はありませんが、質問文、質問日時、回答全文、表示された出典、期待した正しい答えとその根拠を一件ずつ残します。顧客名や個人情報は、調査に必要な範囲だけに絞ります。
例えば「出張旅費の上限はいくらか」と尋ね、AIが旧版の金額を答えたとします。現行の旅費規程の版と適用開始日、旧版が残っている場所まで確認できれば、単なる数字の誤りを調査可能な事象に変えられます。金額だけでなく、どの条件に適用される上限かも記録します。
AWSのRAGの説明では、外部資料を用意し、関連情報を検索してから、取得した情報を質問とともにモデルへ渡す流れを示しています。誤りを一括して「AIの問題」と呼ばず、この流れのどこで生じたかを探すのが出発点です。
図の左から順に確認します。最初の段階に正しい情報がなければ、後段の設定だけを変えても期待した答えは安定しません。下段には各段階で確かめる項目を示しました。
第1段階：原資料に「正解」が存在するか
現場が正本とする規程や手順書を、AIを介さずに開きます。該当の条項、版、施行日、対象部門、例外条件を確認してください。最新版の文書があっても、質問への答えがその中に書かれていないなら、AIに要求する前に文書を整える必要があります。
次に、AIへ取り込ませた資料と正本が同じかを調べます。更新したばかりの規程が未同期、旧版と新版が並存、表の注記が取り込み時に欠けた、という状態が考えられます。ここで正本との差が見つかったら、資料の管理担当に修正を依頼し、取り込み後に同じ質問を再実行します。
旧版を単に削除する前に、保存義務や履歴参照の必要性は社内の規程で確認します。AIが検索対象にする版の管理と、原本を保管する方針は別の話です。AWSも検索に使う外部データを更新する必要性に触れています。ただし、具体的な同期頻度は利用する製品と社内の更新頻度で決めます。
第2段階：正しい箇所が検索結果に入ったか
正本が存在したら、次はAIがその箇所を取得したかを見ます。出典リンクだけでなく、可能なら開発担当に実際の検索結果の文書名と抜粋を確認してもらいます。正しい資料が候補に出ていなければ、回答文を何度書き直しても原因は残ります。
候補には出ていても、件数制限や途中の処理で外れ、回答を作るモデルには渡っていない場合があります。調査できる仕組みなら、検索候補とモデルへ実際に渡された抜粋の両方を見ます。候補だけに正解があるなら、回答の言い回しよりも、この受け渡しを先に調べます。
ここでは質問語と社内文書の語がずれていないかを確認します。「旅費」と聞いているのに規程の見出しは「交通費・宿泊費」だけ、あるいは同じ名前の旧版が先に並ぶ、といった具合です。OpenAIの検索ドキュメントは、意味による検索、属性による絞り込み、検索順位の調整を説明しています。特定製品の設定をそのまま採用する必要はありませんが、検索された候補を見てから調整するという順序は共通します。
正しい抜粋が結果にあるのに順位が低いなら、検索語、文書の区切り方、版や部署の属性、順位付けを開発担当と確認します。検索結果に機密文書が混じる場合は、順位の問題として処理せず、閲覧権限の設定を先に調べます。正しい資料が「存在する」ことと、その質問者に「表示してよい」ことは違います。
第3段階：取得した根拠を回答が正しく使ったか
正しい箇所がモデルへ渡された抜粋に入っていても、回答が条件を落とすことがあります。例えば抜粋には「国内出張、宿泊を伴う場合」とあるのに、回答がすべての出張に同じ上限を当てはめた場合です。回答中の主張を文ごとに抜粋へ戻し、条件、数値、日付が一致するかを確認します。
MicrosoftのRAG評価資料は、検索した資料の関連性を測る評価と、回答が資料に根拠を持つかを測る評価を分けています。前者が良くても後者が良いとは限りません。資料にない内容を回答が加えたなら、開発担当は回答時の指示や渡す抜粋の量を見直せます。
逆に、検索された抜粋自体が誤っていれば、この段階で文章表現を調整しても解決しません。根拠がない質問に「分かりません」と答える設計も必要です。これはAIに全件を正答させる約束ではなく、確かめられない回答を業務判断に使わないための運用です。
開発担当へ渡す一枚の記録
次の表は、障害報告ではなく原因を切り分けるためのメモです。初回は一件で構いません。複数の部署で同じ誤りが出るなら、案件番号を付けて横断して見られるようにします。
| 記録欄 | 書く内容の例 |
|---|---|
| 質問と回答 | 質問文、日時、回答全文、表示された出典 |
| 正本 | 現行規程の文書名、版、該当箇所、適用条件 |
| 取り込み | 正本とAIの検索対象が一致するか、旧版の扱い |
| 検索結果 | 取得した抜粋に正しい箇所があったか |
| 回答との照合 | 抜粋にない数字や、抜けた条件は何か |
| 暫定対応 | 担当者による原本確認、対象質問の利用保留など |
調査中は、その質問の回答を業務の確定情報として扱わず、正本を確認する導線を示します。重要な問い合わせなら、誰が原本を確認して回答するかも決めておきます。社外へ送る文面の最終確認は生成AIの出力を社外へ出す前のチェック項目を参照してください。ここで扱うのは、その前段にある社内検索の品質です。
修正後は同じ質問だけでなく、条件を一つ変えた質問も試します。国内と海外、現行と過去、一般社員と管理職など、規程に実際にある区分から選びます。AI開発のPoCで確認したい質問の考え方も、再テストの範囲を決めるときに役立ちます。一件が直ったことと、同種の誤りが減ったことは分けて判断してください。
次の一歩
まず、最近の誤回答を一件だけ選び、表を埋めてみてください。正本に問題があれば資料の管理担当へ、検索結果に問題があれば検索の担当者へ、回答の解釈に問題があれば生成部分の担当者へ渡します。作る前のデータ整理は社内ナレッジAIの作り方、既存AIに資料をつなぐ方式はRAGとChatGPTの関係で確認できます。
外部の開発担当へ相談するなら、製品名だけでなく、この一枚の記録を共有すると話が進みます。資料の正本とアクセス権を確認できる範囲で、再現条件をそろえてから相談してください。
よくある質問
出典リンクが付いていれば、回答は正しいですか？
いいえ。リンク先が質問に適用される版か、回答に書かれた条件や数字を実際に含むかまで確認します。リンクがあるだけでは、内容の裏付けになりません。
正しい資料があるのに、AIが見つけません。最初に何を変えますか？
設定の前に、正しい資料がAIの検索対象へ取り込まれているかを確認します。その後、実際の検索結果と質問語を比べます。順位や資料の区切り方の調整は、結果を見てから検討します。
何件試せば「直った」と言えますか？
万能な件数はありません。同じ質問の再現に加え、誤りが出た条件と隣接する条件を試します。対象業務の重要性に応じ、現場責任者と開発担当が、残る誤りをどこまで許容するかを決めます。