2026.09.01
RAG精度改善を成功へ導く実践設計ガイド
IT関連
RAG精度改善では、モデルを入れ替える前に「正しい根拠を取得できたか」と「根拠どおりに答えたか」を分けて診断することが重要です。誤答の多くは生成モデル単体ではなく、文書抽出や検索設計の不備から生じます。
RAGは社内FAQ、規程、技術文書を参照して回答を生成する仕組みです。しかし、PDFの表が崩れる、旧版文書が混ざる、専門用語が揺れるといった現場の問題により、もっともらしい誤回答が発生します。
本記事では、データ準備、チャンク設計、ハイブリッド検索、リランキング、生成制約、評価と継続運用を一連の工程として整理します。小さく検証し、測定可能な改善を積み重ねる実践手順を紹介します。
RAG精度改善の前に失敗箇所を切り分ける
検索と生成を別々に測定する
RAGの精度を上げる最短経路は、検索品質と回答品質を別指標で測ることです。回答が誤っていても、必要な根拠が上位にないのか、根拠はあるのにモデルが読み違えたのかで、打つべき施策はまったく変わります。
まず質問ごとに、正解根拠が上位候補に含まれる割合を確認します。次に、取得済み根拠だけを与えた回答の正確性、引用の妥当性、回答不能時の拒否を人手で採点し、障害箇所を記録します。
たとえば正答率80%を目標にしても、検索で根拠を取り逃がせば生成プロンプトだけでは補えません。逆に根拠取得率が高いのに誤答するなら、コンテキストの並び順や回答制約を見直すべきです。
- 検索ではRecall@k、MRR、根拠の到達率を確認する
- 生成では正確性、忠実性、引用の妥当性を確認する
- 回答不能な質問を独立した評価対象にする
失敗ログから原因を分類する
原因分類では、失敗した質問を一律に「精度不足」と扱わないことが大切です。検索ゼロ件、誤った版の取得、表の抽出崩れ、質問の曖昧さ、根拠を超えた推測という分類だけでも、改善優先度が明確になります。
特に複数版の規程やスキャンPDFでは、検索エンジン以前に抽出テキストが壊れている場合があります。回答画面から原文ページへ遡れるようにし、チャンク、文書版、権限、検索順位をログとして残しましょう。
ベクトル検索単体のMRR（Mean Reciprocal Rank）は56.72%にとどまったという報告もあります。この数値はベクトル化が無効という意味ではなく、語句一致や再順位付けを組み合わせる診断が必要だと示します。
- 質問、取得文書、順位、回答、評価理由を同じログに保存する
- 誤った回答と回答拒否を区別して記録する
- 原文PDFと抽出テキストを並べて確認する
改善目標を業務成果に結び付ける
精度目標は、利用者が完了したい業務から逆算して定義します。社内規程の案内なら根拠付き回答率、保守支援なら一次解決率、法務照会なら引用箇所の正確性が、単純な正答率より実用的な基準になります。
評価セットは最低50〜100件から始め、頻出質問、複数文書をまたぐ質問、回答不能な質問、更新直後の質問を混在させます。正解が一つでないケースも含めると、実運用との乖離を抑えられます。
改善案を比較する際は、同じ質問、同じ文書版、同じLLMで検証します。チャンク、検索方式、リランカー、プロンプトを同時に変えると、どの施策が効いたのかを説明できなくなります。
- 業務ごとに成功条件を一文で定義する
- 評価セットには難問と回答不能問題を含める
- 比較実験では変更点を一つに絞る
回答の土台になる文書データを整える
パース品質を検索品質の前提にする
文書パースの品質は、検索精度の前提条件です。PDF、表、図、段組み、スキャン画像を含む資料では、見出しと本文の対応、表の行列、ページ番号が正しく抽出されているかを登録前にサンプル確認します。
10,000文字程度の文章を1,000文字ずつのチャンクに分けると合計10チャンクになります。しかし抽出時に表の見出しが本文から切り離されると、正しい検索語を含んでいても、回答に必要な条件が欠けてしまいます。
現場では、元ファイルのID、ページ、改訂日、抽出器のバージョンを保持する設計が有効です。検索結果の異常を見つけたとき、再インデックスか原文修正かを判断でき、監査時にも回答根拠を追跡できます。
- 表は見出し・単位・注記を一つの意味単位として保持する
- OCR対象は原本との照合サンプルを必ず用意する
- 文書IDとページ情報を各チャンクへ引き継ぐ
表記ゆれと文書版を正規化する
専門用語の正規化は、同義語検索の漏れを減らす基本施策です。製品名の略称、全角半角、旧組織名、英日表記を辞書化し、原文を改変せず検索用の別フィールドとして追加する方法が安全です。
文書の最新版を優先するには、公開状態、適用開始日、版番号、部署、機密区分をメタデータ化します。旧版を削除できない場合でも、回答対象から除外するフィルターがあれば、矛盾した根拠の混入を防げます。
アクセス制御も精度要件の一部です。利用者の所属や権限で候補集合を先に絞らなければ、検索スコアが高くても閲覧権限のない文書を引用しかねません。権限別の評価ケースを用意してください。
- 原文と検索用正規化フィールドを分離する
- 版番号と適用状態を必須メタデータにする
- 検索前フィルターで権限境界を強制する
用途に応じて知識ベースを分ける
知識ベースは、文書の性質と質問形式で分けると精度が安定します。短い社内FAQと詳細な技術仕様書を同じ設定で処理すると、簡潔さを求める質問と文脈を必要とする質問の双方で検索順位が崩れやすくなります。
FAQでは質問と回答を一組で保存し、マニュアルでは見出し階層と手順の前後関係を残します。法務文書では条文番号、適用範囲、改訂版を明示し、回答時には解釈ではなく該当箇所の提示を優先します。
ALION株式会社のように業種を問わずシステム開発を支援する体制では、顧客ごとの文書境界を明確にすることが欠かせません。マルチテナント環境では、精度評価と情報隔離を同じ受入条件として扱います。
- FAQはQ&Aペアを壊さず登録する
- 手順書は見出し階層と前後ステップを保持する
- 顧客・部署・機密度でデータ境界を設計する
チャンクと検索経路を質問に合わせて設計する
意味が切れないチャンクを作る
チャンク設計では、文章量を均等に切るより意味の完結性を保つことが重要です。一般的な出発点として200〜500文字、または500〜1,000トークンを設定し、見出し、段落、表、箇条書きの境界を優先して分割します。
固定長だけでなく、見出し単位のセマンティック分割や、親見出しと子チャンクを併用する階層チャンクも有効です。短い子チャンクで検索し、回答時には親節を渡すと、局所的な一致と十分な文脈を両立しやすくなります。
オーバーラップは10〜30%を起点に評価します。隣接するチャンク間に10〜20%の重複を持たせると、段落境界の条件文が切れる失敗を減らせますが、重複しすぎると候補の多様性が下がります。
- 数値ではなく文書構造を先に分割境界にする
- 短い検索単位と広い回答文脈を分けて扱う
- オーバーラップは重複率と検索結果をセットで検証する
ハイブリッド検索で漏れを補う
専門用語や型番を含む社内検索では、ベクトル検索だけに依存しない方が安全です。意味の近さに強いベクトル検索と、固有名詞や条文番号に強いBM25を組み合わせるハイブリッド検索が、取り逃がしを補います。
重み付けは、ベクトル検索に70%、BM25に30%を割り当てる方法が一般的な出発点です。ただし、この比率を正解とせず、質問タイプ別にMRR、Recall@k、引用根拠の到達率を測り、実データに合わせて調整します。
スコア尺度が異なる検索器を単純加算すると、一方が過度に優勢になることがあります。順位を統合するRRFやスコア正規化を使い、同義語質問、型番質問、長文質問の三群で順位変化を確認しましょう。
- 固有名詞・番号検索ではBM25の寄与を確認する
- 意味検索では埋め込みモデルのドメイン適合性を確認する
- 統合後の順位を質問タイプごとに評価する
質問を検索可能な形へ変換する
曖昧な質問は、そのまま検索せず検索用に変換すると根拠到達率を高められます。略語を展開する書き換え、複数条件を分ける分解、会話文から主語を補う補完を行い、元質問と変換後質問をログに残します。
Small-to-Big Retrievalでは、まず短い具体的な断片を取得し、次に親見出しや周辺段落を広げます。いきなり大きな文脈を検索するより、細かな一致を起点に必要な背景を回収できるため、技術文書の条件確認に向きます。
検索候補は上位20〜50件を集め、後段で上位5〜10件へ絞る二段構成が実務的です。ただし高リスク文書では、候補数を増やす前に権限フィルターと最新版フィルターが確実に働くことを確認します。
- 質問書き換え前後を比較可能な形で記録する
- 複合質問は条件ごとに分解して再統合する
- 候補拡張は権限フィルターの後に実行する
再順位付けと生成制約で誤答を抑える
リランカーで上位候補の順番を直す
リランキングは、候補を広く集めた後に質問と文書を対で精査し、順位を入れ替える工程です。Cross-Encoderはクエリと候補本文の関係を深く判定できるため、初段検索では見分けにくい類似文書の選別に適しています。
検索精度が62%から79%に向上し、リランキングを加えることで91%に到達した事例があります。成果はデータと評価条件に依存しますが、検索器を増やす前に上位候補の並びを検証する価値を示す数値です。
一方でリランカーは候補ごとに推論を行うため、レイテンシと費用が増えます。各ステップで100〜500msを見込み、重要質問だけに適用する、候補数を制限するなど、業務上の待ち時間と両立させます。
- 初段検索は再現率、再順位付けは適合率を担う
- Cross-Encoderは候補数を制限して利用する
- P95レイテンシと回答品質を同時に記録する
根拠だけを使う回答ルールを与える
生成段階では、モデルに「根拠に明記された内容だけで答える」と明示し、根拠不足なら回答不能と返すルールを与えます。これは知識を増やす施策ではなく、取得できていない情報を推測で埋めないための制約です。
回答には文書名、節、ページなどの引用を自動付与します。引用は利用者が検証する入口であり、評価時にはリンクが存在するかだけでなく、主張を実際に裏付けているかまで確認する必要があります。
コンテキストは関連度順に詰め込むだけでは不十分です。重複候補を除き、質問に必要な定義、条件、例外、結論を揃えます。競合する根拠がある場合は、版情報を提示して断定を避ける設計にします。
- 根拠なしの推測を禁止し、回答不能文を定義する
- 引用は回答の主張単位に対応付ける
- 矛盾する根拠は版情報とともに提示する
生成パラメータを用途ごとに固定する
生成パラメータは、用途に応じて固定し、評価時と本番で差を作らないことが基本です。温度を上げるほど表現の幅は増えますが、規程照会や技術手順では再現性と根拠忠実性を優先する方が適切です。
top_pは0.9なら上位90%の確率質量を持つトークンのみを考慮し、top_k=50なら上位50個のトークンのみを候補にします。こうした設定値は単独で良否を決めず、回答の揺れと引用整合性で判断します。
ファインチューニングは、検索不備を解消する手段ではありません。まず根拠取得、リランキング、プロンプト、出力検証を整え、それでも組織固有の文体や分類が課題となる場合に、学習コストを比較して検討します。
- 規程・FAQでは再現性を優先する
- パラメータ変更は評価セットで差分を測る
- 学習の前に検索経路と根拠制約を整える
評価と運用で精度を継続的に高める
自動評価と人手評価を併用する
継続的な品質管理では、自動評価と人手評価を併用するのが有効です。Ragas v0.4+などでfaithfulness、answer_relevancy、context_precision、context_recallを追い、同時に業務担当者が正確性と引用妥当性を確認します。
評価例としてfaithfulness 0.91、answer_relevancy 0.87、context_precision 0.82、context_recall 0.78といった指標は、どこに改善余地があるかを示します。ただし自動スコアが高くても、利用者が手続きを完了できるとは限りません。
したがって、正解根拠の有無、回答文の正確性、引用の妥当性、業務タスク達成の四層を分けて採点します。人手評価で見つかった失敗をゴールデンデータセットへ追加し、次回リリースの回帰テストに使います。
- 自動指標は原因仮説を作るために使う
- 人手評価では引用と業務達成を確認する
- 失敗例を回帰テスト用データへ蓄積する
本番ログで劣化を早く検知する
本番運用では、評価セットだけでなく実際の質問ログを監視する必要があります。ゼロ件率、回答不能率、再質問率、引用クリック率、低評価理由を追うと、文書更新や利用者の質問傾向による劣化を早く捉えられます。
改善サイクルは2〜4週間単位で回すと、変更と結果の因果を追いやすくなります。新しい埋め込みモデル、チャンク設定、プロンプトは一度に本番へ出さず、限定利用者で比較してから段階的に広げます。
リリースには、評価結果、利用した文書版、モデル、埋め込み、プロンプト、検索設定を紐付けます。品質が悪化した場合に前の構成へ戻せるため、更新の速さと安定性を両立できます。
- 本番では再質問率とゼロ件率を監視する
- 変更ごとに設定と評価結果をバージョン管理する
- 段階的ロールアウトとロールバックを用意する
費用と速度を含めて施策を選ぶ
RAG精度改善は、最高精度だけでなく費用、速度、保守性を含めて判断します。高性能なリランカーや複数回検索は有効でも、質問数が増えるほど推論コストと待ち時間が増えるため、用途別の適用範囲を決める必要があります。
小規模な検証では初期1〜2週間の開発工数で、文書品質、チャンク、検索、評価の基礎を確認できます。本格運用では1〜3ヶ月のエンジニア工数や月8〜16時間の運用工数も見込み、改善効果を業務削減時間と比較します。
たとえば重要な法務照会には再検索と厳格な引用検証を適用し、日常FAQには軽量な検索経路を使う方法があります。ALION株式会社は専属チームで伴走する開発支援を通じ、要件、評価、運用を分断しない導入設計を支援できます。
- 質問のリスク別に検索経路を使い分ける
- P95レイテンシ、費用、品質を同じ画面で比較する
- PoCの成功条件を本番の運用条件へ接続する
まとめ
RAGの品質を安定して上げるには、文書品質、検索、再順位付け、生成制約、評価を別々に測りながら接続することが不可欠です。RAG精度改善を単発のモデル変更で終わらせず、失敗ログを次の評価データに変える運用を設計しましょう。
要点
- 誤答は検索失敗と生成失敗に分けて診断する
- 文書パース、版管理、メタデータが検索品質の土台になる
- ハイブリッド検索とリランキングは評価結果を見て段階導入する
- 自動評価、人手評価、本番ログを組み合わせて回帰を防ぐ
- 精度だけでなくコスト、速度、権限管理を受入条件にする
まずは頻出質問と失敗質問を含む50〜100件の評価セットを作り、現在の検索根拠を確認してください。課題が複数工程にまたがる場合は、データ整備から検証環境、段階的な本番導入までを一貫して設計することが成功への近道です。
よくある質問
Q1. RAG精度改善で最初に確認すべき項目は何ですか？
最初に、正解根拠が検索結果に含まれるかを確認してください。根拠がないならデータ、チャンク、検索を改善し、根拠があるならリランキング、プロンプト、生成制約を見直します。
Q2. チャンクサイズはどれくらいが適切ですか？
一律の正解はありません。200〜500文字または500〜1,000トークンを出発点にし、見出し・段落・表の意味境界を優先して、評価セットで根拠到達率を比較してください。
Q3. ベクトル検索だけでは不十分ですか？
型番、条文番号、固有名詞を含む質問では、キーワード検索の強みがあります。ベクトル検索とBM25を組み合わせ、実際の質問タイプごとに効果を測ることが重要です。
Q4. RAGの評価は自動評価だけでできますか？
自動評価は継続監視に有効ですが、引用の妥当性や業務タスクの完了可否は人手確認も必要です。自動評価、人手評価、本番ログを組み合わせて判断してください。
Q5. RAGで情報漏えいを防ぐにはどうすればよいですか？
文書登録時の分類だけでなく、検索前に利用者の権限で候補をフィルタリングします。さらに権限別の評価ケース、監査ログ、文書版管理を運用に組み込みます。
参考文献・出典
[rag](/ai-information/technology/rag/)[llm](/ai-information/technology/llm/)[生成AI](/ai-information/technology/generative-ai/)[業務自動化](/ai-information/usecase/aut…
www.optimax.co.jp
[](https://arpable.com/ “Arpable”)…
arpable.com
…
www.arsaga.jp