RAGの精度改善｜原因を切り分ける5手順

はじめに

社内規程を答えるRAGに「出張の宿泊費はいくらまで？」と聞く。上限額は規程に書かれているのに、回答は古い金額だった。担当者はプロンプトを直し、モデルも変えた。翌日は別の質問で外れた。

こうなると、改善は当てずっぽうになる。正解の文書を取り込めていないのか。検索で拾えていないのか。根拠は届いたのに生成モデルが読み違えたのか。三つを分けない限り、どの変更が効いたか分からない。

RAGの精度改善は、モデル交換から始めない。評価セット、元データ、チャンク、検索、生成の順に、一つずつ確かめる。変更原因を追えるため、同じ条件で再比較できる。

構築前の評価設計は既存記事へ譲り、ここでは稼働後に出た誤答を診断する手順へ絞る。

RAGの精度改善はモデル交換から始めない

RAGは、検索した情報を生成モデルへ渡し、その根拠を使って回答させる仕組みだ。したがって「回答が違う」という一つの症状にも、少なくとも五つの故障箇所がある。

最初に作るのは監視画面ではない。誤答ごとに「質問ID、正解の文書ID、取得チャンクID、回答、判定理由」を一行へ残す診断票でよい。

たとえばQ-017の正解根拠がTRAVEL-2026-04なのに、検索結果にTRAVEL-2024-10しかなければ、プロンプトの問題ではない。版管理か検索の問題だ。正解根拠が1位にあるのに回答額を間違えたなら、初めて生成側を調べる。

検索と生成を分けて考える前提は、Microsoft FoundryのRAG評価資料にも表れている。文書検索にはNDCGなどの検索指標を使い、回答には根拠性や関連性を使う。最終回答だけを丸か罰かで採点するより、直す場所が見える。

RAGの精度改善を進める5手順

1. 評価セットを20問から固定する

改善前に、現場で実際に出る質問を20問だけ選ぶ。1000問を自動生成するより、業務担当者が正解を説明できる20問の方が役に立つ。

質問は三種類を混ぜる。

• 単純参照：交通費の申請期限はいつか
• 条件付き参照：管理職が海外出張する場合の上限はいくらか
• 回答不能：規程にない個人判断や将来予測を求める質問

各問には期待回答、正解の文書ID、該当箇所を付ける。「分からない」が正解になる質問も入れる。根拠がないときに止まる力も測るためだ。

最低限、次の四つを別々に測る。

1. 正解根拠がtop-kに入った割合
2. 取得チャンクに質問と無関係な情報が混じる割合
3. 回答の主張が取得チャンクで裏付けられる割合
4. 必要な条件と例外を回答が満たした割合

NVIDIAのRAG評価ガイドも、回答の正確さ、取得文脈の関連性、根拠性、Recallを分けている。指標名をそのまま採用する必要はない。大切なのは、検索できたかと、検索結果を正しく使えたかを混ぜないことだ。

評価設計を先に固める考え方は、RAGとは？構築前に決める評価設計でも整理している。正解根拠がない場合は、改善より先にこちらへ戻った方がよい。

2. 元データの版・重複・読取失敗を直す

検索技法を変える前に、検索対象を点検する。RAGに同じ規程の2024年版と2026年版が入っていれば、両方を正しく検索するほど回答は不安定になる。

文書ごとに、次の情報を持たせる。

• 文書IDと版番号
• 施行日と失効日
• 所管部署
• 公開範囲
• 元ファイルのURLまたは保管場所
• 取り込み日時と変換結果

PDFでは、表の列ずれ、ヘッダー混入、脚注の欠落も見る。20問の正解箇所を元ファイルと変換後テキストで比べれば、読取失敗の傾向をつかめる。

古い版を削除できない場合は、有効期間をメタデータに入れ、通常検索では現行版へ絞る。アクセス権も取得後ではなく、検索前に適用する。

社内ナレッジの整え方は、NotebookLMの使い方は社内ナレッジ設計からにも共通する。ファイルを増やすことと、信頼できる知識源を作ることは別物である。

3. チャンクを文字数ではなく意味で切る

固定文字数で機械的に切ると、本文と例外条件が分かれる。たとえば「宿泊費は1泊15,000円まで」という本文と、「繁忙期に部長承認がある場合は20,000円まで」という但し書きが別チャンクになれば、片方だけが検索される。

チャンクは見出し、条項、表、箇条書きなど、意味のまとまりを優先する。親見出し、文書名、版、対象部署を各チャンクへ持たせると、短い断片でも何の話か判断しやすい。

AnthropicのContextual Retrievalは、文書全体を参照して生成したチャンク固有の短い文脈を、各チャンクへ前置してから埋め込みとBM25索引を作る。同社の実験では、両者の組み合わせで上位20件の取得失敗率が5.7%から2.9%へ下がった。再ランクを加えた条件では1.9%だった。自社の20問でも再現するか測る必要がある。

300、600、900トークンを比べるなら、埋め込みモデルやtop-kは固定する。一度に変えるのは一条件だけだ。

4. 検索はハイブリッドと再ランクを小さく試す

ベクトル検索は意味が近い表現に強い。一方、「TR-104」「商品型番AX-9」「2026年4月版」のような文字列は、キーワード検索が拾いやすい。

Azure AI Searchの公式資料では、全文検索とベクトル検索を並列に実行し、Reciprocal Rank Fusionで結果を統合するハイブリッド検索を説明している。固有名詞や専門用語、日付はキーワード検索が有効な例として挙げられている。

ここで、いきなり複雑な検索パイプラインを作る必要はない。

1. 現行のベクトル検索を基準値として保存する
2. キーワード検索を併用した条件を追加する
3. top-kを3、5、10で比較する
4. 上位候補だけ再ランクする条件を追加する
5. Recall、不要チャンク率、応答時間、1問あたり費用を並べる

top-kを増やすと無関係な文脈も増える。再ランクは遅延と費用を増やす。精度、応答時間、費用を同じ表で比べる。

20問中18問で正解根拠がtop-5に入り、95パーセンタイルの応答時間が5秒以内、といった形なら比較できる。「かなり良くなった」では運用判断ができない。

5. 生成を根拠の範囲へ閉じる

正解根拠が検索結果に入っているのに回答が外れるなら、生成側を直す。指示には次の三点を明記する。

• 取得した根拠だけで回答する
• 回答ごとに文書名、版、該当箇所を示す
• 根拠が不足または矛盾するときは推測せず、担当部署へ戻す

さらに、金額、日付、権限、禁止事項は、生成後に構造化して照合する。文章全体を感覚で採点するより、「金額は根拠と一致したか」「例外条件を落としていないか」を項目ごとに見る方が修正しやすい。

Amazon BedrockのRAG評価資料も、検索側のContext relevanceとContext coverageを、生成側のCorrectness、Completeness、Faithfulness、引用精度などと分けている。検索が成功したのに回答が失敗した問だけを集めれば、生成指示の弱点が見える。

モデル交換は最後だ。同じ取得文脈と指示で比べれば、モデル差を測れる。

2週間で回すRAG改善の検証表

RAGの精度改善は、二週間の短い検証でも始められる。範囲は一つの業務と20問に絞る。

文書や質問傾向が変わっても、同じ20問と失敗分類があれば再評価できる。診断票は受け入れ試験と変更管理の共通記録になる。

Atsumellでは、RAGやAIエージェントを作る前段から、業務フロー、参照権限、評価質問、停止条件を仕様へ落としている。回答が外れるたびに調整を繰り返しているなら、まず一つの誤答を元文書から回答まで追ってみてほしい。改善箇所を一緒に整理したい場合は、お問い合わせフォームから相談できる。

関連記事

• AIエージェントのハルシネーション対策｜5つの設計
• AIチャットボットの作り方｜5つの仕様
• AIチャットボットの費用は5項目で決まる