Retrieval Pipeline とは？

Scrapeless Agent Browser は、ブラウザベースでの Web コンテンツ収集をサポートします。

Retrieval pipeline は、リクエストに関連する情報を発見・準備する一連の処理ステージです。ドキュメントをインジェストし、インデックスを構築し、クエリを解釈し、候補を検索してランキングし、選択された証拠を返すことができます。生成は検索の後に続く場合もありますが、retrieval pipeline は言語モデルを使わずに検索結果をそのまま返すこともできます。

AI アプリケーションにおいて、パイプラインの役割は、要求された回答を裏付けられる情報を提供することです。類似したテキストであっても、必ずしも十分な証拠とは限りません。各ステージを「次のステージが何を必要とするか」を基準に設計し、なぜそのドキュメントが選ばれたかを検証できるだけのソース情報を保持してください。

オフライン経路とリクエスト時経路

Retrieval pipeline には通常、検索可能なコンテンツを準備するインジェスト経路と、クエリに対して情報を選択するリクエスト時経路があります。インジェストには、収集、テキスト抽出、正規化、チャンク分割、インデックス作成などが含まれます。リクエスト時には、クエリ処理、アクセスフィルタリング、候補検索、ランキング、コンテキスト組み立てなどが含まれます。

この分離が重要なのは、それぞれの経路で異なるタイプの失敗が起こるからです。インデックスに入っていない欠落ドキュメントは、どれだけランキングを改善しても取り戻せません。インデックスされている関連ドキュメントも、弱いクエリや制限が厳しすぎるフィルタによって除外され得ます。ステージごとの観測結果を保持し、それらのケースが「RAG の品質が低い」といったあいまいなラベル 1 つに押し込められないようにしてください。

元々の retrieval-augmented generation の研究 は、ジェネレータと検索された情報を組み合わせています。アプリケーションにおいては、その関係が明確な契約を生みます。検索は候補となる証拠を提供し、生成はそれを用いて応答を作成します。能力の高いジェネレータであっても、欠落したソース資料を安定して補うことはできないため、両方のステージを評価する必要があります。

インジェストはソースレコードから始まる

ドキュメントインジェストでは、テキストを変換する前に、各ソースの同一性と起源を保持すべきです。正規の識別子、ソースの場所、収集時刻、および関連するバージョン情報を保持してください。これらのフィールドは、処理中に失われる可能性のあるファイル名だけに埋め込むのではなく、抽出されたテキストと結び付けておきます。

Web ソースでは、関連コンテンツが利用可能になる前にブラウザ操作が必要な場合があります。 Agent Browser ワークフロー は、その収集ステージに属します。収集後も、どのテキストが有用か、ソースがスコープ内かどうか、そのレコードをどのようにインデックスすべきかを決めるのはアプリケーションです。

仮想的なプロダクトサポートコーパスでは、各構成ページを、その製品バージョンとともに 1 つのソースとして保存します。適用条件や警告は残しつつ、繰り返されるナビゲーションを削除します。もし表に回答が含まれているなら、その行ラベルと値の関係を保持します。すべてのセルを 1 つの非構造テキストストリームに平坦化すると、単語はすべて残っていても、後段の検索が誤解を招く可能性があります。

チャンク分割では「答えられる単位」を保つ

チャンク分割は、検索器が選択でき、下流のリーダーが解釈できる単位にドキュメントを分割します。適切な単位は、ドキュメント構造とユーザーが尋ねる質問に依存します。短い定義なら 1 段落に収まるかもしれませんが、手順的な回答には複数のステップと関連する警告が必要かもしれません。

例でよく見かけるからという理由だけでチャンクサイズを決めるのは避けてください。代表的なドキュメントを確認し、取得されたチャンクが完全な裏付けを含んでいるかを測定します。見出し、ソース ID、および元の文書内で該当箇所を特定できるオフセットなどを保持してください。チャンクが条件文の途中から始まると、回答ジェネレータは、その指示が何に適用されるのかを見落とす可能性があります。

オーバーラップしたチャンクは連続性を保てますが、その一方で重複した証拠を生み出すこともあります。コンテキスト組み立ての段階で重複排除を行い、完全なソースへのリンクを保持してください。検索結果は、高い類似度スコアを返すだけでなく、その文章が何を意味し、どこから来たのかを次のステージに伝えるべきです。

候補検索とランキングは異なる問題を解く

候補検索は、潜在的に関連するレコードの扱いやすい集合を見つける一方で、ランキングはそれらの中からリクエストに最もよく応えるレコードを決定します。キーワード検索は、正確な名称や識別子に役立ちます。Dense retrieval は、学習された表現を使ってクエリとパッセージを比較します。ハイブリッド設計では、タスクにとって有益な場合に両方のシグナルを組み合わせることができます。

この dense passage retrieval アーキテクチャ は、質問とパッセージを別々にエンコードして検索する仕組みを示しています。しかしこのメカニズムは、意味的類似性が事実としての裏付けと同一であることを保証するものではありません。製品の旧バージョンに関するパッセージは、現行バージョンについての質問とよく似ていても、誤ったバージョンに答えてしまう可能性があります。

タスクの一部として、ソースのスコープ、アクセス権、バージョン、時刻などの制約がある場合は、そのためのフィルタを適用してください。そのうえで有効な集合内で関連性を評価します。禁止されたコンテンツをモデルコンテキストに検索で取り込み、その後でジェネレータにアクセス制御の誤りを修正させようとしてはいけません。許可チェックは、証拠を開示する前に行う必要があります。

証拠の来歴を失わずにコンテキストを組み立てる

コンテキスト組み立ては、次のコンシューマーのために検索された証拠を選択・整理します。RAG アプリケーションでは、そのコンシューマーはしばしばモデルです。回答の追跡可能性を保つために、ソース ID と関連する但し書きを含めてください。重複や無関係なコンテンツを取り除く際も、その記述が真となる条件まで捨ててしまわないようにします。

数値を含む一節には、その単位、表見出し、適用開始日が必要になる場合があります。圧縮によってそれらの詳細が削除されると、短いコンテキストは長いコンテキストよりも有用性が低くなることがあります。〜に関する研究では 長いコンテキストにおける情報の配置 も、容量だけでは不十分な理由を示しています。リトリーバが生成した生の候補リストだけでなく、モデルが実際に受け取るコンテキストを評価してください。

この エージェント型のライブウェブ検索によるリトリーバルワークフロー には、別の検索や精査が必要かどうかの判断が加わります。そうした判断が予測可能な場合は、固定パイプラインの方が望ましいこともあります。いずれにせよ、コンテキストの組み立てでは、どのソースが選択され、どの要求された主張が依然として証拠を欠いているかを記録すべきです。

回答を判断する前にリトリーバルを測定する

リトリーバル評価では、パイプラインが定義された一連の質問に必要な証拠を返しているかどうかを問います。既知の関連ソースや、レビュー済みの関連性ラベルを持つ例を構築してください。サポートの欠如が、取り込み、候補の検索、フィルタリング、ランキング、コンテキストの組み立てのどこに起因するのかを調査します。

関連性とカバレッジを別々に測定します。結果リストがほとんど関連していても、必須のサブクエスチョンに答えるのに必要な一節だけが抜け落ちている場合があります。また、パイプラインが正しいソースを取得していても、不完全なチャンクだけを露出させている場合もあります。回答ステップで消費されるレベル、すなわち最終的に組み立てられた証拠パケットのレベルで評価してください。

回答の評価は分離しておきます。生成モデルは有用な証拠を無視したり、その文を支持していないソースを引用したりすることがあります。エンドツーエンドのテストでは、主張の裏付け、完全性、適切な不確実性を評価する必要があります。回答の流暢さをリトリーバル品質の代用として用いることは避けてください。洗練された文章は、欠落した文書や古いソースを覆い隠してしまうことがあります。

鮮度には更新ポリシーが必要

リトリーバルパイプラインには、インデックス化されたソースを更新、置換、削除するためのポリシーが必要です。収集タイムスタンプは、システムがページを観測した時刻を示すものであり、そのページが公開された時刻や、記述された出来事が起きた時刻を必ずしも示すものではありません。これらの区別が利用可能な場合は保持してください。

仮想的なリリースドキュメントコーパスでは、新しいページバージョンが、古い設定に関するアドバイスを無効にしてしまう場合があります。ソースレコードを更新し、バージョンポリシーに従って、古いチャンクをアクティブなリトリーバルから削除してください。明確なメタデータなしに両方を残しておくと、システムが矛盾する手順を同じだけ最新のものとして提示してしまうことがあります。

削除にも同様の注意が必要です。ソースファイルを削除しても、そのチャンクがインデックスやキャッシュされた証拠パケットに残っていれば不十分です。更新が検索可能な表現とストレージの両方に影響するよう、依存関係を追跡してください。以前に引用した証拠が利用できなくなった場合に、無関係なソースに黙って置き換えるのではなく、アプリケーションがどのように応答するかを定義してください。

境界チェックでパイプラインを診断する

境界チェックは、リトリーバル各段階の間で交換される成果物をテストします。抽出後には、関連するコンテンツが存在するかどうかを確認します。チャンク化後には、完全な単位が残っているかどうかを確認します。検索後には、関連する単位が候補集合に含まれているかどうかを確認します。組み立て後には、必要な但し書きとともに、それがモデルに届いているかどうかを確認します。

スループットの最適化に取り組む前に、小さなコーパスとレビュー済みの質問セットから始めてください。処理設定とコーパスのバージョンを評価結果に紐付けておきます。後から埋め込みモデルや抽出ルールを変更した場合は、同じケースを実行して、どの境界が変化したかを確認してください。出典を再現できない大きなスコアよりも、小さく追跡可能な評価の方が有用です。

収集インフラストラクチャを、インデックス化と推論のコストから切り離してください。 Scrapeless の料金オプション は、あなたの設計で使用される収集サービスに関するものです。インデックスストレージ、ランキング、モデル呼び出しには、それぞれ独自の会計があります。これらのカテゴリを保持しておくことで、実際にコストやレイテンシを支配している段階を改善しやすくなります。

まとめ

リトリーバルパイプラインは、明示的な処理段階を通じてリクエストを選択済みの証拠へと変換します。ソースの同一性を保持し、有効な範囲内で検索し、下流に渡される正確な一節を評価してください。回答が失敗したときは、モデルに別のプロンプトが必要だと決めつける前に、段階ごとの境界を調査してください。