AIモデルが特定のシナリオで役立つためには、通常、背景知識を利用する必要がある。例えば、カスタマー・サポート・チャットボットは、それがサービスを提供する特定のビジネスを理解する必要があり、法的分析ボットは、多数の過去のケースにアクセスする必要がある。
開発者はしばしば、知識ベースから関連情報を検索し、それをユーザーのプロンプトに添付することで、モデルの応答性を大幅に向上させる手法であるRAG（Retrieval-Augmented Generation）を使用して、AIモデルの知識を補強する。問題は、従来の ラグ プログラムは情報を符号化する際に文脈を失うため、システムが知識ベースから関連情報を取り出すことができなくなることが多い。
本論文では、RAGの検索ステップを大幅に改善できるアプローチを概説する。このアプローチは文脈検索（Contextual Retrieval）と呼ばれ、文脈埋め込み（Contextual Embeddings）と文脈BM25（Contextual BM25）という2つのサブテクニックを用いる。このアプローチにより、検索失敗の数が491 TP3T減少し、再ランク付けと組み合わせると671 TP3T減少する。これらの改善により、検索精度が劇的に向上し、下流タスクの性能向上に直結する。
その本質は、意味的に類似した結果と単語頻度が類似した結果の混合であり、意味的な結果が真の意図を表していないこともある。文末に掲載されているリンクを読んでほしい。この「古い」戦略が発表されてから2年が経つが、極めて複雑なRAG戦略に陥るか、埋め込み＋並べ替えだけを使うか、この方法が使われることはまだほとんどない。
この記事は、「キャッシュ・ヒント」を使って、文書の全体的な文脈に合ったテキスト・ブロックの文脈を低コストで生成するという、古い戦略を少し改良したものである。小さな変更だが、その結果は印象的だ！
そのためには サンプルコード 利用する クロード 独自のコンテクスト検索ソリューションを展開。
長めのチップの簡単な使い方についてのメモ
最も単純な解決策が最良であることもあります。知識ベースが200,000トークン（約500ページの資料）以下であれば、RAGや同様の方法を使用しなくても、モデルに提供されるプロンプトに知識ベース全体を直接含めることができます。
数週間前、私たちはクロードのためにリリースした。 キュー・キャッシュ新しいAPIに加え、このアプローチを大幅に高速化し、コストを削減しました。開発者はAPI呼び出しの間に頻繁に使用されるヒントをキャッシュすることができるようになり、レイテンシを2倍以上、コストを最大90%削減することができます。 ヒントキャッシュのサンプルコード (仕組みを理解する）。
しかし、ナレッジ・ベースが大きくなるにつれて、よりスケーラブルなソリューションが必要になる。それでは、本題に入ろう。
RAGの基本：より大きな知識ベースへの拡大
RAGは、コンテキスト・ウィンドウに収まらない大規模な知識ベースに対する典型的なソリューションである。RAGは以下のステップで知識ベースを前処理する：
- 知識ベース（文書 "コーパス"）を、通常数百トークンを超えない、より小さなテキスト断片に分解する（過度に長いテキストブロックは、より多くの意味を表現する、つまり意味的に豊かすぎる）。
- セグメントは、埋め込みモデルを使って意味をエンコードするベクトル埋め込みに変換される；
- これらの埋め込みは、意味的類似度で検索するためのベクトルデータベースに格納される。
実行時に、ユーザーがクエリをモデルに入力すると、ベクトルデータベースはクエリの意味的類似性に基づいて最も関連性の高いフラグメントを見つける。そして、最も関連性の高いフラグメントは、生成モデルに送信されるプロンプトに追加される（より大きなモデル参照のコンテキストとして質問に答える）。
埋め込みモデルは意味的な関係を捉えるのには適しているが、重要な完全一致を見逃すことがある。BM25は、語彙マッチングによって単語やフレーズの完全一致を見つけるランキング機能である。ユニークな識別子や専門用語を含むクエリに特に効果的である。
BM25 BM25は、文書の長さを考慮し、単語頻度に飽和関数を適用することで、一般的な単語が結果を支配するのを防ぐ。
ユーザーがテクニカルサポートデータベースに「エラーコードTS-999」を問い合わせたとする。(ベクトル)埋め込みモデルは、エラーコードに関する一般的なコンテンツを見つけるかもしれませんが、正確に "TS-999 "にマッチしないかもしれません。その代わりに、BM25は関連するドキュメントを特定するために、その特定のテキスト文字列を探します。
埋め込み技術とBM25技術を組み合わせることで、RAGプログラムは以下のように、最も関連性の高い断片をより正確に取り出すことができる：
- 知識ベース（文書「コーパス」）は、通常は数百トークン以下の小さなテキスト片に分解される；
- これらのセグメントについて、TF-IDFエンコーディングと意味（ベクトル）埋め込みを作成する；
- BM25を使用して、完全一致に基づいて最適なフラグメントを検索します；
- ベクトルの）埋め込みを使って、意味的な類似度が最も高いセグメントを見つける；
- ステップ(3)と(4)の結果は、並べ替えフュージョン技術、例えば専用の並べ替えモデルRerank 3.5を使ってマージされ、強調されなくなる。
- 最初のKセグメントをプロンプトに追加し、応答を生成する。
BM25と埋め込みモデルを組み合わせることで、従来のRAGシステムは、より包括的で正確な結果を提供するために、正確な用語マッチングと幅広い意味理解のバランスをとることができる。
TF-IDF（単語頻度-逆文書頻度）は単語の重要度を測定し、BM25の基礎となる。
このアプローチにより、単一のプロンプトで対応できるよりもはるかに大きな知識ベースまで、低コストで拡張することができる。しかし、このような従来のRAGシステムには重大な限界がある。
合理的な設計を行うために検索スキームに基づいて、ここで言えば、まだ表示するテキストの切り捨てブロックの話されていない、テキストの切り捨てブロックは、同じコンテンツを表現することですが、決して切り捨てられるべきではありませんが、上記のRAGスキーム必然的に文脈は切り捨てられる.これは単純かつ複雑な問題である。この記事の本題に入ろう。
従来のRAGにおける文脈上の困難
従来のRAGでは、効率的な検索のために文書を小さなチャンクに分割することが多い。このアプローチは多くのアプリケーションシナリオに適しているが、個々のチャンクに十分なコンテキストがない場合、問題が発生する可能性がある。
例えば、あなたの知識ベース（例えば米国証券取引委員会の報告書）に財務情報が埋め込まれており、次のような質問を受けたとする："ACMEコーポレーションの2023年第2四半期の収益成長率は？"
関連ブロックには次のようなテキストが含まれる：「同社の売上高は前四半期から3%増加した。 しかし、このブロック自体が特定の企業や関連する期間について明示していないため、正しい情報を検索したり、効果的に利用したりすることが難しい。
文脈検索の導入
文脈検索は、各ブロックに特定のブロックを追加してから埋め込むことで行われる。解釈の背景(「コンテキスト埋め込み」)とBM25インデックス(「コンテキストBM25」)の作成がこの問題を解決する。
SECレポート集の例に戻ろう。以下はブロックがどのように変換されるかの例である：
original_chunk = "同社の収益は前四半期から3%増加した。"
contextualised_chunk = "このチャンクはACME Corporationの2023年第2四半期の業績に関するSECレポートからのもので、前四半期の収益は$314Mだった。同社の収益は前四半期から3%増加した。"
検索を改善するために文脈を利用する他の方法が、過去に数多く提案されてきたことは注目に値する。他の提案には次のようなものがある：ブロックに一般的な文書要約を追加する(実験してみたところ、ゲインが非常に限られていることがわかった）、仮のドキュメント埋め込み 歌で応える 抽象ベースの索引付け(評価した結果、性能は低かった）。これらの方法は、本稿で提案する方法とは異なる。
コンテキストの質を向上させる方法の多くは、実験的にその効果が限定的であることが示されている。この変換プロセスに説明的な文脈を加えると、多かれ少なかれ情報が失われるからだ。.
完全な段落をテキストブロックに分割し、その完全な段落の内容に複数レベルの見出しをつけたとしても、上記の例が夢を語っているように、この段落を単独で、文脈を無視して、知識を正確に伝えることはできないかもしれない。
この方法は、テキストブロックのコンテンツが単独で存在する場合、文脈的な背景がないため、コンテンツが孤立して意味がないという問題を効果的に解決する。
文脈検索の有効化
もちろん、知識ベース内の何千、何百万ものブロックに対して手作業でコンテキストを注釈するのはあまりに大変な作業である。文脈検索を可能にするために、私たちはClaudeに注目し、文書全体の文脈に基づいて、簡潔でブロック固有の文脈を提供するようモデルに指示するヒントを書いた。以下は、Claude 3 Haikuのヒントを使用して、各ブロックのコンテキストを生成した方法である：
<ドキュメント
{{whole_document}}。
これは、ドキュメント全体に配置したいチャンクです。
{{chunk_content}}です。
</chunk
チャンクの検索性を向上させるために、チャンクを文書全体の文脈の中に配置するための簡潔な文脈を記述してください。簡潔な文脈のみを答え、それ以外のものは含めないでください。
生成されるコンテキスト・テキストは通常50～100トークンで、埋め込み前とBM25インデックスを作成する前にブロックに追加される。
このキュー実行は、テキストブロックに対応する完全なドキュメント（500ページ以上はないはずですね）をキューキャッシュとして参照する必要があります。をキューキャッシュとして参照し、ドキュメント全体に対するテキストブロックに関連するコンテキストを正確に生成します。
これは、クロードのキャッシュ機能に依存し、入力をキャッシュするプロンプトとして完全な文書は、キャッシング、毎回支払う必要はありませんが、ちょうど一度だけ支払うので、前提条件を達成するためのプログラムは次のとおりです。大型モデルで長時間のドキュメント・キャッシュが可能DeepSeekなどのモデルも同様の機能を持っている。
以下は、実際の前処理プロセスである：
文脈検索は、検索精度を向上させる前処理技術である。
コンテクスト検索を使用することに興味がある場合は、次のサイトを参照してください。 操作マニュアル スタート。
ヒントキャッシュによる文脈検索のコスト削減
クロード・コンテキストを介した検索は、前述した特別なヒント・キャッシュ機能のおかげで低コストで実現できる。ヒント・キャッシングを使えば、ブロックごとに参照ドキュメントを渡す必要はない。単にドキュメントを一度キャッシュにロードし、それから以前にキャッシュされたコンテンツを参照するだけです。ブロックごとに800トークン、ドキュメントごとに8kトークン、コンテキスト命令ごとに50トークン、ブロックコンテキストごとに100トークンと仮定するとコンテキスト化されたブロックを生成するための1回限りのコストは、100万ドキュメント・トークンあたり$1.02です。.
方法論
複数の知識ドメイン（コードベース、小説、ArXiv論文、科学論文）、埋め込みモデル、検索戦略、評価指標で実験を行った。実験は 付録 II 各ドメインで使用した質問と回答の例を以下に挙げる。
下図は、最も性能の良い埋め込み設定（Gemini Text 004）を使用し、最初の20個のスニペットを検索した場合の、全ての知識ドメインにわたる平均性能を示している。評価指標として、1マイナスrecall@20を使用し、最初の20スニペットで検索できなかった関連文書の割合を測定している。すべての結果は付録で見ることができます - コンテキスト化は、評価した埋め込みソースのすべての組み合わせでパフォーマンスを向上させます。
パフォーマンス向上
私たちの実験によれば、こうだ：
- 文脈埋め込みは、最初の20フラグメントの検索失敗率を35%減少させた。(5.7% → 3.7%）。
- 文脈埋め込みと文脈BM25を組み合わせることで、最初の20フラグメントの検索失敗率が49%減少した。(5.7% → 2.9%）。
文脈埋め込みと文脈BM25を組み合わせることで、最初の20フラグメントの検索失敗率が49%減少した。
実施上の留意点
コンテクスト検索を導入する際には、以下の点に留意する必要がある：
- フラグメントの境界： 文書をどのように断片に分割するかを考える。フラグメントのサイズ、境界、重複の選択は検索性能に影響する^1^。
- モデルを埋め込む： 文脈検索は、我々がテストしたすべての埋め込みモデルのパフォーマンスを向上させるが、特定のモデルはより多くの恩恵を受ける可能性がある。その結果 ジェミニ 歌で応える 航海 エンベディングは特に効果的だ。
- カスタムのコンテクストキュー： 我々が提供する一般的なプロンプトはうまく機能するが、特定のドメインやユースケース用にプロンプトをカスタマイズすることで、より良い結果を得ることができる（例えば、知識ベース内の他のドキュメントで定義されている可能性のある重要な用語の用語集を含めるなど）。
- クリップの数 コンテキスト・ウィンドウに多くのフラグメントを追加することで、関連する情報が含まれる可能性を高めることができる。しかし、情報が多すぎるとモデルの注意をそらす可能性があるため、数を制御する必要がある。私たちは、5、10、20のフラグメントを試し、これらのオプションでは20フラグメントを使うのが最もうまくいくことがわかりました（詳細は付録を参照）が、ユースケースに応じて実験する価値があります。
常に査定を行う： レスポンス生成は、コンテキスト化されたスニペットを渡し、コンテキストとスニペットを区別することで改善できる。
並べ替えでパフォーマンスをさらに向上
最後のステップでは、文脈検索を別の技術と組み合わせることで、パフォーマンスをさらに向上させることができる。従来のRAG（Retrieval-Augmented Generation）では、AIシステムは関連する可能性のある情報の断片を知識ベースから検索する。大規模な知識ベースでは、最初の検索は通常、関連性と重要性が異なる多数の断片を返す。
並べ替えは、最も関連性の高い部分のみがモデルに渡されるようにする、一般的なフィルタリング技術である。リオーダリングは、モデルが処理する情報が少ないため、コストとレイテンシを削減しながら、より良いレスポンスを提供する。主な手順は以下の通り：
- 最初に検索を行い、最も関連性の高いセグメントを取得した（最初の150件を使用）；
- 最初の N 個のセグメントとユーザークエリを並べ替えモデルに渡す；
- 並べ替えモデルを使用して、各クリップをキューとの関連性と重要性に基づいてスコアリングし、上位K個のクリップを選択した（上位20個を使用）；
- 最初のK個のセグメントがコンテキストとしてモデルに渡され、最終的な結果が生成される。
文脈検索と並べ替えを組み合わせることで、検索精度を最大化。
パフォーマンス向上
市場には様々な再注文モデルがある。私たちは コヒーレ・リコーダ 航海 再注文も可能しかし、それをテストする時間はなかった。我々の実験は、並べ替えステップを追加することで、様々なドメインにおいて検索をさらに最適化できることを示している。
具体的には、文脈埋め込みと文脈BM25を並べ替えることで、上位20フラグメントの検索失敗率が671 TP3T減少することがわかった（5.71 TP3T → 1.91 TP3T）。
文脈埋め込みと文脈BM25の並び替えにより、最初の20フラグメントの検索失敗率が67%減少した。
コストと遅延の考慮
並べ替えに際して考慮すべき重要な点は、特に大量のフラグメントを並べ替える場 合、待ち時間とコストに与える影響である。並べ替えは実行時に余分なステップを追加するため、並べ替えを行う側がすべてのフラグメントを並べてスコアリングする場合でも、必然的に待ち時間が発生する。パフォーマンスを上げるためにフラグメントの並び替えを多くするか、レイテンシとコストを下げるためにフラグメントの並び替えを少なくするかは、トレードオフの関係にある。最適なバランスを見つけるために、特定のユースケースでさまざまな設定を試してみることをお勧めします。
評決を下す
我々は、上記のすべての技術（埋め込みモデル、BM25の使用、文脈検索の使用、リコーダーの使用、検索結果のトップKの数）のさまざまな組み合わせを比較する多くのテストを実行し、さまざまな種類のデータセットで実験を行った。以下はその結果の要約である：
- エンベデッド＋BM25は、エンベデッドだけを使うよりも良い；
- 航海と ジェミニ は、我々のテストで最もうまく機能した埋め込みモデルである；
- 最初の20セグメントをモデルに渡すことは、最初の10セグメントや5セグメントだけを渡すよりも効果的である；
- セグメントにコンテキストを追加することで、検索精度が大幅に向上する；
- 並べ替えは、並べ替えをしないよりはましだ；
- これらの利点はすべて積み重ねることができる： パフォーマンスを最大限に向上させるには、（VoyageやGeminiからの）文脈埋め込み、文脈BM25、ステップの並べ替え、プロンプトへの20のスニペットの追加を組み合わせて使用することができる。
ナレッジベースを使用するすべての開発者に 練習マニュアル 新しいレベルのパフォーマンスを引き出すために、これらの方法を試してみよう。
付録I
以下は、データセット、埋め込みプロバイダー、埋め込みと組み合わせて使用されるBM25、文脈検索の使用、並び替えの使用に関するRetrievals @ 20の結果の内訳である。
各データセットの検索回数（10回）と検索回数（5回）の内訳、および質問と回答のサンプルについては、以下を参照のこと。 付録 II.
データセットと埋め込みプロバイダーの結果について、1マイナス・リコール@20。
日本語 
简体中文 
English 
Deutsch (Sie) 
Português do Brasil