検索・RAG・根拠

毎回全文を読めない量になったら、質問に必要な根拠を取得します。原文 → 解析・分割 → 候補検索 → 選択 → コンテキスト → 回答を辿ります。設定が見つかっても例外条件まで取得したとは限らず、検索スコアと回答の根拠を別々に検証します。

外部証拠を生成に取り込む

RAG（Retrieval-Augmented Generation：検索拡張生成）は、生成の前または生成の過程で外部資料を取得し、モデルがそれらを利用して回答できるようにします。古典的な研究では、パラメータモデルと検索可能な非パラメータ知識を組み合わせました。エンジニアリングにおけるRAGでは、キーワード検索、SQL、ドキュメント読み取り、またはマルチターンツールクエリを使用することもでき、ベクトルデータベースに限定されるものではありません。Retrieval-Augmented Generation

これにより、資料の更新とモデルの重み更新が部分的に分離されましたが、生成モデルが重要でなくなるわけではありません。資料が存在しない場合、検索が重要な条件を見逃す場合、アセンブリが切り捨ててしまう場合、モデルが誤読する場合もあります。これらの各段階を個別に検証する必要があり、「答えの問題は必ず検索の問題だ」と事前に想定してはいけません。

少量の完全なドキュメントの場合、全文を直接提供した方が簡単であることが多く、特に章をまたいだ全体の判断が必要な場合に有効です。大規模で頻繁に更新される、または権限が細分化されたナレッジベースでは、必要に応じて資料を取得する方が制御が容易です。ファインチューニングは、動作、スタイル、またはドメインの処理方法を改善するために使用でき、検索と組み合わせても問題ありません。選択の基準はタスクと証拠の要件であり、「全文提供かファインチューニングか」という二者択一ではありません。

ドキュメントから検索可能な証拠へ

パースの品質がインデックスの内容を決定する

まず、本文、見出しの階層、テーブル、コード、および引用の位置を特定します。PDFの2段組での順序の乱れ、見出しの欠落、スキャン文字のOCRエラーは、ベクトル化の前に意味を損なう可能性があります。検索エンジンは、誤ってパースされた結果から、存在しない原文を復元できません。

各証拠ユニットには、ドキュメントID、バージョンまたはコンテンツハッシュ、セクションパス、原文の位置、アクセス範囲、および更新時間が保存されます。原文への位置特定は、チャンク分割の変更によって変化する「何番目のチャンク」に依存するだけでなく、当時のドキュメント内の具体的な内容に戻れるものでなければなりません。

チャンク分割は、完全性と選択精度の間の妥協点です

短いチャンクは正確なマッチングには優れていますが、指示語、定義、制限事項を見落とす可能性があります。長いチャンクは関係性を保持しますが、複数のトピックが混入したり、多くのコンテキストウィンドウを消費したりする可能性があります。セクション、段落、またはコード構造に基づいて分割するのが一般的な出発点ですが、固定長やオーバーラップの比率は、資料とタスクに応じて検証する必要があり、すべてのナレッジベースが200〜500トークンに適しているとは限りません。

実行可能な設計として、小さなチャンクで検索し、親セクションや近傍の段落で回答の証拠を提供する方法があります。例えば、設定項目にヒットした場合は、そのタイトル、テーブルヘッダー、および適用制限を補完します。オーバーラップは境界の分断を緩和しますが、重複ヒットを引き起こす可能性があります。コンテキストに取り込む前に重複を除去し、異なるバージョンが誤って1つの断片に合成されていないかを確認する必要があります。

「それにより10%増加した」といった、原文の文脈なしには理解しにくい断片に対しては、ドキュメントとセクションの背景を付記します。Contextual Retrieval のエンジニアリング事例では、断片にコンテキストを補完する方法で検索を改善しています。生成された背景も検証する必要があり、モデルが補足した説明を原文の事実として扱ってはなりません。Contextual Retrieval

embedding は表現を提供するが、意味の正確な理解を保証するものではない

密な検索（Dense Retrieval）は、クエリとドキュメントをベクトルにエンコードし、内積やコサイン類似度などの尺度に基づいてソートします。トレーニングの目標は、関連するクエリと証拠を対応する空間でより近くにすることですが、これは「意味が同じであること」を保証するものではありません。否定、正確な番号、バージョンの違いは依然として区別が難しい場合があります。

クエリとドキュメントは互いに互換性のあるエンコーディングスキームを使用する必要があります。必ずしも同じエンコーダーである必要はありません。双方向エンコーダーの設計では、問題と段落を別々にエンコードできますが、トレーニングと使用法が一致していることが前提です。Dense Passage Retrieval のモデルバージョン、ベクトル次元、正規化、およびクエリプロンプトの形式は記録する必要があります。エンコーディングスキームを変更する場合は、対応するインデックスを再生成する必要があります。同じ次元だからといって、同じ空間を意味するわけではありません。

全件走査と近似最近傍（ANN）インデックスの選択は、データ量、次元、フィルタリング、ハードウェア、およびレイテンシの目標によって異なります。「数万件なら必ず全件走査、百万件ならANN」という統一された閾値はありません。近似インデックスは候補の漏れも引き起こすため、インデックスのリコールとモデルの表現能力を分離して確認する必要があります。

リコール、融合、および証拠の選択

キーワードとベクトルは補完し合える

エラーコード、商品番号、関数名は、文字通りの一致を保持するのが適しています。ユーザーが言い換えを行った場合、意味的な表現がキーワードの漏れを補う可能性があります。BM25などの手法とベクトル検索のスコアは異なるスケールにあるため、キャリブレーションなしに直接加算することはできません。ランキングベースの融合を使用するか、検証セット上で重み付け方法をキャリブレーションする必要があります。

RRF（Reciprocal Rank Fusion）は、候補 d が各結果リストでランク r にある場合、1/(c+r) を累積します。リストに出現しない場合は貢献しません。c は平滑化定数であり、最終的に何件の結果を返すかとは異なるパラメータです。RRF 原始論文

キーワード結果が A, B, C、ベクトル結果が B, D, A で、c=60 と仮定します。B のスコアは 1/62 + 1/61 ≈ 0.03252、A は 1/61 + 1/63 ≈ 0.03227 となるため、B が A より上位になります。融合は、両方のパスが特定の項目をサポートしているというシグナルを利用しますが、B の内容が必ずしも正しいことを証明するものではありません。

from collections import defaultdict
from fractions import Fraction

lists = [["A", "B", "C"], ["B", "D", "A"]]
scores = defaultdict(Fraction)
for ranking in lists:
    assert len(ranking) == len(set(ranking))
    for rank, doc in enumerate(ranking, 1):
        scores[doc] += Fraction(1, 60 + rank)
order = sorted(scores, key=lambda doc: (-scores[doc], doc))
assert order == ["B", "A", "D", "C"]
print([(doc, round(float(scores[doc]), 5)) for doc in order])

リランキングは、リコールされなかった材料を回復できない

cross-encoder によるリランキングは、クエリと候補コンテンツを結合して処理するため、通常は単一のベクトル類似度比較よりもコストが高くなります。そのため、候補数が少ない場合に頻繁に使用されます。これにより、リコールされたがランクが低かった正しい断片を最終的なコンテキストに含めることができますが、候補セット外のドキュメントを自動的に（何もないところから）追加することはできません。

候補数、リランキング後の数、およびコンテキストのトークン予算を個別に設定します。候補セットを拡大するとカバー率が向上する一方で、レイテンシも増加します。最終的な証拠を減らすとノイズが減少しますが、マルチホップ問題に必要な2番目の事実を見落とす可能性もあります。証拠のカバー率を中心に調整すべきであり、「50件投入、5件出力」といった固定の実行に依存すべきではありません。タスク横断的な検索評価でも、異なる検索手法のパフォーマンスはドメインやタスクに応じて変化することが示されています。BEIR

例えば、「部門AはインターフェースXを使用できるか」と問われた場合、権限ルール、Aのロールマッピング、およびXのバージョン制限のすべてが必要になる可能性があります。単一の断片の類似度が高くても不十分であり、システムは問題を分解するか、重要な関係に証拠があるまで検索を続ける必要があります。資料を取得できない場合は、欠落を明確にします。

2 つの順位をどう統合するか

元の順位を残すことでスコアを再計算できます。c が小さいと上位差が強まり、大きいと各ヒットの寄与が近づきます。統合後も版・権限・根拠の検証が必要です。 RRF (Cormack et al., 2009)

$$\mathrm{RRF}(d)=\sum _{\ell :d\in \ell }\frac{1}{c+r_{\ell }(d)}$$

インデックスは継続的に保守されるデータ製品

インデックスの構築は一度きりの作業ではありません。新規追加、変更、削除、権限の取り消しはすべて、更新パイプラインに入る必要があります。古い断片がベクトルデータベースやキーワードデータベースに残ったままになると、モデルが廃止されたルールを引用する原因となります。2つのインデックスの更新が同期していないと、ハイブリッド検索が互いに矛盾するバージョンを返す可能性があります。

権限制約は検索と結果の読み取りに参加させる必要があり、まず全テナントの資料をモデルに渡してから、モデルが自ら無視することを期待してはいけません。検索キャッシュも、認可範囲、ドキュメントバージョン、およびクエリ条件にバインドする必要があります。ユーザーAのヒット結果を、アクセス権限のないユーザーBにそのまま再利用することはできません。

インデックスをアップグレードする際は、まず新版を構築し、カバー率、レイテンシ、権限、および引用位置を検証してから、読み取りエントリを切り替えます。必要なロールバック情報を保持しますが、削除や権限の取り消しはロールバックによって復活させてはいけません。ベクトルデータベースに保存されているエントリは派生データであり、権威あるソースと更新記録は引き続き保持する必要があります。

コンテキストのアセンブリと引用の検証

証拠と指示を区別し、ドキュメントのID、位置、バージョン、および切り捨て状況を注釈付けします。動的な証拠は、プレフィックスの再利用を容易にするため、安定した指示の後に配置するのが適しています。具体的な配置位置の効果は測定する必要があり、「最後に配置すれば」モデルが正しく使用してくれるとは限りません。外部ドキュメントに記載されている操作指示は、自動的にアプリケーションの認可にはなりません。

引用は検証に役立ちますが、「回答にリンクが含まれているからといって」結論が支持されるわけではありません。引用が存在するか、バージョンが適用可能か、断片がその主張を本当に支持しているかを項目ごとに確認する必要があります。例えば、引用が「テスト環境でサポート」と述べているのに、回答が「本番環境でサポート」と書かれている場合、位置特定は正確ですが推論が権限外です。

証拠が不十分な場合は、親セクションの読み取り、クエリの拡張、または情報の欠如を明確に説明します。資料が十分かどうかに関わらず、モデルに確定した回答を強要しないでください。RAG は 長期記憶 も検索できます。これらには「RAG は客観的のみ、記憶は主観的のみ」といった自然的な境界線はありません。

設定だけでなく制限も取得したか

B を検索から、次にコンテキストから外して再順位付けを試します。失われる段階が異なり、未取得の条件は並べ替えでは追加できません。必要な根拠の組合せを測り、関連資料1件の命中とは区別します。

階層型評価と失敗の帰属

関連性の注釈単位を明確にする

クエリに対して関連するドキュメントまたは証拠ユニットを注釈付けし、マルチホップ問題にどのような組み合わせが必要かを説明します。クエリ Q に対して、関連集合を R、返された上位 k 件の集合を S とします。

例えば、R={A,C} で、返された結果が [B,A,D] の場合、precision@3=1/3、recall@3=1/2、reciprocal rank=1/2 となります。recall を「正しい断片が1つでもあれば」と簡略化すると、C が漏れます。関連項目がちょうど1つの場合に限り、recall はその項目が含まれているかどうかを示す値になります。

指標の計算はプログラム化できますが、関連性ラベルと証拠の要件は依然として不完全であったり、意見が分かれたりする可能性があります。拒否回答の妥当性、引用の支持、最終的な正答率、レイテンシ、およびコストも測定する必要があります。検索が関連しているからといって、回答が導出可能であるとは限りません。断片が候補セットに入ったからといって、最終的に生成ウィンドウに入るわけではありません。

失敗チェーンに沿って階層ごとに特定する

次に読む：Agent ループと実行器。