RAGの精度が安定しないときに
見直すポイント

「精度が低い」は、どこが低いのかを分解する

RAGの不調は、ひとまとめに「LLMが悪い」とされがちです。実務では次を切り分けます。

• 検索が悪い：正しい文書が top-k に入らない（Recall不足）
• 文脈が悪い：入っているが断片が切れている／表と説明が分離
• 生成が悪い：根拠はあるのに要約や判断を誤る
• 評価が曖昧：何を正解とするかが人によって違う

検索が悪いのに生成プロンプトだけ直しても改善しません。まず Recall@k を測れる評価セット（ゴールデンセット）を用意するのが先です。

1. チャンク設計を疑う

エンタープライズ向けの実践知では、「まず直すならチャンク」が定石です。チャンクは検索可能な知識単位そのものだからです。

• 目安サイズ：256 / 512 / 1024 トークン程度を比較検証
• オーバーラップ：10〜20% を起点に調整
• 見出し・章パス・文書タイトルをメタデータ／前置テキストとして付与
• 可能なら見出しや表境界に沿った構造分割を優先（単純な固定長より有効なことが多い）

スキャンPDFや図表混在資料では、OCRと構造化の品質がチャンク品質を上限づけます。ここはデモクロのデータ処理工程の中心テーマです。

2. ハイブリッド検索（ベクトル + BM25）を入れる

意味的に近い言い換えはベクトル検索が強く、型番・規程番号・固有名詞は BM25 系が強い、というのが典型です。両方を走らせ、Reciprocal Rank Fusion（RRF）で順位融合するのが実務の定番です。

• RRF はスコア尺度が違う手法を混ぜやすい（順位ベースのため校正が不要）
• よく使われる平滑化定数は k=60 が起点（Cormackら、2009）
• 候補を多めに取ってから、必要ならクロスエンコーダで再ランキング

3. 再ランキングは「銀の弾丸」ではない

再ランカーは関連度を上げやすい一方、コストとレイテンシが増えます。正しいチャンクが候補集合に入っていないと再ランキングは救えません。まず fetch 幅とハイブリッド検索で Recall を確保し、そのうえで効果を測定して採用可否を決めるのが安全です。

4. 評価と改善のループ

• 質問セット（実業務の言い回し）を 30〜100 件から用意
• 正解文書ID／必須根拠をラベル付け
• 変更は1要因ずつ（チャンク→検索→再ランク→プロンプト）
• 未回答・低信頼時は「推測で埋めない」方針を明示

まとめ

RAG精度の改善は、モデル競争ではなくデータと検索の工学です。デモクロでは OCR・構造化からチャンク／ハイブリッド検索／評価設計まで一気通貫で支援し、必要に応じて Agentic な再検索へ拡張します。