ゴールドパッセージを超えた文脈的埋め込み

文脈的埋め込みは、ドキュメント全体の文脈における各パッセージまたはチャンクの意味を捉えます。それらのトレーニングと評価では通常、「ゴールドパッセージ」として知られる、クエリごとに1つの関連チャンクが想定されます。しかし、実際にはゴールドパッセージだけでは不十分なことがよくあります。回答が含まれていても、それを理解または検証するために必要な裏付けとなる文脈が欠けているため、単体では曖昧なままになってしまいます。

私たちは新しい文脈的埋め込みモデルである pplx-embed-v2-context-9b-preview を紹介します。このモデルは、Perplexityの文脈圧縮モデルを教師として使用する新しいアプローチでトレーニングされています。そのトークンレベルの予測をチャンクレベルの関連性スコアに集約し、単一のゴールドチャンクではなく、回答チャンクとサポートする文脈の両方を取得するように埋め込みモデルに教えています。モデルは追加の推論コストなしでチャンクごとに1つの埋め込みを生成し、1024次元およびint8埋め込みをサポートします。

これは、turbopuffer によって作成および非公開で保持されている文脈認識検索のための新しいベンチマークである context-bench と、広く使用されているパブリックベンチマークである ConTEB において、最先端の結果を達成しています。私たちのモデルはcontext-benchとは独立して開発され、ブラインドサブミッションとして評価されました。

Context-benchは、21ドメインにおける38,894件の長いドキュメントに対する2,099件のクエリで構成されており、文脈的埋め込みの3つの能力（ほぼ重複するドキュメント間でのドキュメントの曖昧性解消、遠隔の文脈に意味が依存するゴールドチャンクの取得、および回答の検証に必要な裏付け証拠の想起）を評価します。

モデルのプレビューは Hugging Face で一般公開されています。トレーニングの汚染リスクを軽減し、進捗測定のための価値を維持するために、ベンチマークはturbopufferによって非公開で保持されています。評価をリクエストするには、contextbench@turbopuffer.com のturbopufferまでご連絡ください。

context-benchにおけるドキュメント、回答、および証拠の取得結果 — 図 1: Perplexity v2プレビュー 9BをVoyage Context 4、Voyage 4 Large、およびPerplexity context v1 4Bと比較した、context-benchにおけるAnswer@K、Document@K、Evidence Recall@K、およびAll-Evidence@10。

検索システムは通常、長いドキュメントを、独立してインデックス化および検索できる小さなチャンクに分割します。チャンク化は実用上便利ですが、各チャンクが本来出現した文脈が失われ、情報圧縮の粒度とエンコード時に使用される文脈の間にトレードオフが生じます。チャンクは、前で紹介されたエンティティを参照したり、セクションの見出しからその意味を受け継いだり、ドキュメントの他の場所にある定義に依存したりする場合があります。抽出されると、クエリと確実に一致させるのに十分な情報がもはや含まれていない可能性があります。ドキュメント全体を単一のベクトルとしてエンコードしても、1つのプーリングされた表現では長いドキュメントのあらゆる側面を忠実に捉えることができないため、これは解決されません。

文脈的埋め込みモデルは、周囲のコンテンツの文脈の中で各チャンクを表現することにより、この制限に対処します。最も一般的なのはレイトチャンキングを通じた方法です。ドキュメントが単一のパスでエンコードされ、その後チャンク表現がプーリングされるため、すべてのチャンクベクトルがドキュメント全体を見据えて計算されます。先行研究（ConTEB や当社の pplx-embed-context-v1 など）により、文脈化されたチャンク表現は、独立してエンコードされたチャンクと比較して、特に長いドキュメントにおいて検索が大幅に改善されることが示されています。

文脈的埋め込みモデルをトレーニングするには、ドキュメントのどの部分が特定のクエリに関連しているかを特定するスーパービジョンが必要です。一般的なアプローチはゴールドチャンクアノテーションです。各クエリについて、通常は大規模言語モデル（LLM）であるアノテーターが、それに答えるドキュメントのチャンクを特定します。

トレーニングでは通常、2つの対比損失が組み合わされます。ゴールドチャンクを他のドキュメントのチャンクと対比させる ドキュメント間損失 と、同じドキュメント内の他のチャンクと対比させる ドキュメント内損失 です。

このアプローチにはいくつかの制限があります：

1つのチャンクのみに関連性がある。 ドキュメント内の他のすべてのチャンクをネガティブとして扱いますが、これには有用なサポート情報を持つチャンクも含まれます。ドキュメントレベルのスーパービジョンは、もう一つの極端なケースで動作します。ドキュメント内のどのチャンクが重要かを指定することなく、ドキュメントを関連性があるものとして特定します。実際には、関連性はこの極端なケースの間にあることがよくあります。回答を含むチャンクは、エンティティを導入したり、参照を解決したり、補完的な事実を提供したりする少数のサポートチャンクに依存する一方で、ドキュメントの残りの部分は無関係である場合があります。したがって、モデルは、単一のゴールドチャンクよりも広く、ドキュメント全体よりも焦点を絞った、適切なレベルの選択性を学習する必要があります。
粗いスーパービジョン。 各アノテーションは、ドキュメント全体の関連性の度合いを捉えるのではなく、単一のゴールドチャンクを特定するため、その生成に費やされた計算量に対するトレーニング信号が制限されます。
スケールするのにコストがかかる。 すべてのトレーニングペアには、LLMがドキュメントを読み込んで関連するチャンクを選択する必要があるため、アノテーションコストはトレーニングセットのサイズに比例して増加し、トレーニングデータの量と多様性が制限されます。
チャンク境界に敏感。 ラベルは、アノテーション時に使用されるチャンク境界にも結び付けられています。固定されたトークンサイズのウィンドウに割り当てられたゴールドラベルは、どの短い文または長いパラグラフが関連しているかを指定しません。したがって、チャンク化戦略を変更したり、ドキュメントがインデックス時にどのように分割されるかに対するロバスト性を向上させるために複数のチャンク化にわたってトレーニングを行ったりするには、コーパスに再度アノテーションを付ける必要がある場合があります。

私たちは、クエリ対応文脈圧縮モデルから関連性判断を蒸留することで、ゴールドチャンク・スーパービジョンの制限に対処します。このモデルは教師として機能し、クエリとドキュメントを共同で読み込み、各ドキュメントトークンに関連性スコアを割り当てます。その予測は、文脈的埋め込みをトレーニングする上でいくつかの利点を提供します：

柔軟なチャンク境界。 トークンレベルの関連性スコアを任意の選択されたチャンク境界に集約できるため、同じ教師の予測を使用して、再アノテーションなしで異なるチャンク化を監督できます。
連続的な関連性。 バイナリのゴールドチャンク・ラベルとは異なり、教師は、回答を含むチャンク、サポートする文脈、および無関係なコンテンツを自然に区別する関連性の度合いを捉える連続的なスコアを提供します。
アノテーションコストの削減。 教師はコンパクトで関連性スコアリングに特化しているため、汎用LLMよりも大規模に監督するコストがはるかに安価になります。

クエリ・ドキュメントペアのバッチにわたる ドキュメントレベル対比損失 と チャンクレベル蒸留損失 の重み付き和を使用してモデルをトレーニングします。各クエリについて、ペアのドキュメントがポジティブとして機能し、同じバッチ内の残りのドキュメントがネガティブとして機能します。

各バッチについて、チャンク化戦略をランダムに選択し、それに応じてドキュメントを分割し、チャンク間にセパレータトークンを挿入します。次に、単一のフォワードパスで各ドキュメントを処理し、各チャンク内のトークン表現を平均プーリングして文脈的チャンク埋め込みを取得します。クエリは個別にエンコードされ、そのトークン表現にわたって平均プーリングされます。最後に、すべてのクエリ埋め込みとバッチ内のすべてのチャンク埋め込みの間のコサイン類似度を計算します。

埋め込みモデルはチャンクレベルの類似度のみを生成しますが、そこから自然にドキュメントレベルの類似度を導出できます。ドキュメントdは、最も関連性の高いチャンクと同じくらいクエリqに関連しているとみなします。このスコアリングルールは、ColBERT のMaxSim操作に着想を得たもので、ここではトークンではなくチャンクに適用されています。

具体的には、埋め込み q を持つクエリqと、埋め込み c を持つチャンクcの順序付きリストとしてのドキュメントdが与えられたとき、ドキュメントレベルの類似度を次のように定義します：

s(q,d):=\max_{c\in d}\mathbf{q}^{\top}\mathbf{c}.

これらのドキュメントレベルの類似度が与えられると、バッチ内ネガティブに対するドキュメントレベルの InfoNCE目的関数を定式化できます。

クエリqについて、d⁺をその関連ドキュメント、𝒟をバッチ内のドキュメントとします。可読性を高めるために温度を省略すると、対比損失は次のようになります：

\mathcal{L}_{\mathrm{doc}}(q,d^{+})=-\log\frac{\exp(s(q,d^{+}))}{\sum_{d\in\mathcal{D}}\exp(s(q,d))}

対比損失は、どのドキュメントがクエリに関連しているかをモデルに教えます。蒸留損失は、そのドキュメント内のどこに関連性があるかをモデルに教えます。これは文脈モデルにとって不可欠です。

トレーニング中、各ポジティブなクエリ・ドキュメントペアを文脈圧縮モデルに渡し、ドキュメント内のすべてのトークンに関連性スコアを割り当てます。ドキュメントレベルのスコアリングと同様に、各チャンクの関連性を、最も関連性の高いコンテンツから導出します。チャンク境界にあるトークンを含む、外れ値トークンに対する感度を減らすために、チャンクレベルの関連性を、チャンク内の上位n個のトークンスコアの平均として定義します。

各クエリについて、ターゲット分布を取得するために、ポジティブドキュメント内の教師のチャンクレベル関連性スコアに温度スケーリングされたソフトマックスを適用します。バッチ内の他のドキュメントのチャンクは、ターゲット確率がゼロになります。バッチ内のすべてのチャンクにわたるターゲットと予測分布の間でフォワードKLダイバージェンスを最小化することにより、このターゲットに一致するように埋め込みモデルをトレーニングします：

\mathcal{L}_{\mathrm{dist}}(q,d^{+})=\mathrm{KL}\!\left(p^{\mathrm{T}}\parallel p^{\mathrm{S}}\right)

p^{\mathrm{T}}(c_j)=\frac{\exp(r_j)}{\sum_{c_k\in d^{+}}\exp(r_k)}

p^{\mathrm{S}}(c)=\frac{\exp(\mathbf{q}^{\top}\mathbf{c})}{\sum_{d\in\mathcal{D}}\sum_{c_k\in d}\exp(\mathbf{q}^{\top}\mathbf{c}_k)}

ここで、上付き文字TとSはそれぞれ教師と学生を示し、rⱼはポジティブドキュメントd⁺内のチャンクcⱼに対する教師の関連性スコアです。教師のターゲット分布は、バッチ内の他のすべてのドキュメントのチャンクにゼロの確率を割り当てます。

単一のゴールドチャンク・ラベルとは異なり、このターゲットは関連性の度合いを捉えます。サポートするチャンクは、ネガティブとして扱われるのではなく教師のスコアに従って重み付けを受け取り、モデルに回答だけでなくサポートする文脈も取得するように教えます。

私たちの複合トレーニング目的関数は、ドキュメントレベル対比損失とチャンクレベル蒸留損失の重み付き和です。この重み付き損失を、クエリ・ドキュメントペアのバッチにわたって平均化します。

図 2は、私たちのトレーニングアプローチを示しています。文脈コンプレッサーは、トレーニング中のみ教師として機能します。推論時には、埋め込みモデルは追加の圧縮や再ランキングステージなしで、チャンクごとに1つの文脈的埋め込みを生成します。このアプローチにより、インデックスのストレージを増やしたり、検索時に教師モデルのレイテンシを追加したりすることなく、文脈的埋め込みがどのように学習されるかが向上します。

文脈的埋め込み蒸留のトレーニング設定 — 図 2: 当社モデルのトレーニング設定。文脈エンコーダー（学生、左）は、それぞれ複数のチャンクで構成されるドキュメントを処理します。各チャンクは、周囲のドキュメント文脈に関して埋め込まれます。クエリAはドキュメントAの既知のマッチであり、すべてのドキュメントのチャンクに対してスコアリングされて予測された類似度を取得します。これらのチャンクレベルのスコアはマックスプーリングされてドキュメントレベルのスコアになります。チャンクレベルの予測とドキュメントレベルの予測をトレーニングして、ターゲット分布（右）に一致させます。チャンクレベルのターゲットは、トレーニング時に既知の関連ドキュメント内の文脈コンプレッサーの予測として計算され、既知の無関係なドキュメント内ではゼロに設定されます。ドキュメントレベルのターゲット分布は、既知の関連ドキュメントに対してワンホットになるように設定されます。

トレーニングデータは、50以上の言語をカバーする約430件の公開および社内のクエリ・ドキュメントデータセットで構成されています。

当社は、PIIでフィルタリングされた本番データから、また長いドキュメントに対して関連するクエリを合成することによって、社内のペアデータセットを構築しています。フォワードパスごとに1つのデータセットを選択し、そこからバッチ全体をサンプリングすることで、バッチ内ネガティブの難易度を高め、ショートカット学習を回避しています。トレーニングデータセットにはチャンクレベルのアノテーションは一切含まれていません。ドキュメント内のすべてのスーパービジョンは圧縮モデルから提供され、トレーニングにConTEBデータは使用されません。さらに、モデルの開発中にはcontext-benchデータは一切使用できませんでした。

モデルは社内の90億パラメータのColBERT検索モデルから開始し、線形射影層を介して2048次元の埋め込みを生成します。学習済みの <|chunk_sep|> トークンでチャンク境界をマークし、そのトークン埋め込みを平均化して各チャンクの埋め込みを形成します。クエリは同じモデルによってエンコードされ、そのトークン埋め込みは単一のベクトルに平均化されます。

1024次元と2048次元の両方の埋め込みをサポートするために Matryoshkaトレーニングを使用し、ネイティブint8埋め込みをサポートするために量子化認識トレーニングを使用します。トレーニング中、学習率は徐々に増加し、一定に保たれた後、減少します。

リリースされたモデルは、同じトレーニングランからのいくつかのチェックポイントの重みを平均化したモデルスープです。

ConTEBなどのパブリックな文脈的検索ベンチマークは、ゴールドチャンク・スーパービジョンの背後にある前提を共有しています。つまり、各クエリには単一の関連チャンクがあり、モデルはそのチャンクを最初にランク付けした場合のみ報酬が与えられるというものです。また、その制限も引き継いでいます。

第一に、ConTEBは、周囲の文脈がなければチャンクが曖昧になるタスクで検索をテストします。これらのタスクでは、文脈モデルは各チャンクを個別にエンコードするモデルよりも優れた性能を発揮しました。しかし、モデルがチャンクを理解しやすくするドキュメントの他の部分も表面化させるかどうかについては問いません。

第二に、同じコーパス内のほぼ同一のドキュメントが、それ以外は同一の文を取り巻く文脈のみが異なる場合に、適切なドキュメントを見つけられるかを体系的にテストしません。

検索エージェントやユーザーがドキュメント全体ではなく少数の取得された文から回答を理解し検証する必要がある場合、両方の能力が重要になります。したがって、私たちは、一般的な検索品質からドキュメント文脈の使用を区別するように設計された、長いドキュメントに対する検索のための制御されたベンチマークであるcontext-benchを構築しました。これは、文脈的埋め込みがドキュメント内の他の場所からの情報を使用して、次の3つの能力をサポートするかどうかをテストします。

ドキュメントの曖昧性解消: ほぼ同一の選択肢の中から正しいドキュメントを特定します。
回答の取得: 意味がドキュメント内の他の場所の詳細に依存する、回答を含むチャンクを取得します。
証拠の取得: 回答を明確にする、または裏付けるサポートチャンクを取得します。

Context-benchには2,099件のクエリと38,894件のドキュメントが含まれています。文の長さのチャンクが使用され、合計2,458,072個のチャンクになります。クエリは、企業向け開示資料、臨床研究、旅行、エンターテインメント、教育、政府、法務契約、ソフトウェアドキュメントなど、21のドメインをカバーしています。

各クエリは、12の文脈的能力のいずれかをテストするように設計されています。主要なターゲットドキュメントは意図的に長く、1,197件の異なる主要ターゲットドキュメントのうち1,061件が少なくとも200の文を持ち、中央値の長さは約6,100トークンです。すべてのクエリには、コーパス内に正確に1つの正解があります。ゴールドドキュメント内で同じ事実が複数回記載されている場合（例えば、要約文やテーブルの行など）、それらの文のいずれも回答として受け入れられます。

回答ルートとは、回答チャンクと、それを解釈または検証するために必要な裏付け証拠の有効な組み合わせのことです。2,099件のクエリのうち、主要ターゲットドキュメントの回答ルートは、964件のクエリで1つの証拠グループ、735件で2つ、332件で3つ以上、68件でゼロとなっています。代替の有効な回答ルートでは、異なる証拠グループが必要になる場合があります。

表 1: ベンチマークの統計。

統計	値
クエリ	2,099
ドキュメント	38,894
文チャンク	2,458,072
主要ターゲットドキュメントの長さの中央値	6,100 トークン
ドメイン	21
クエリあたりの証拠グループ（主要ターゲットドキュメントの回答ルート）	1: 964; 2: 735; 3+: 332; なし: 68

表 2: context-benchによってテストされる12の文脈的能力と、説明的な例。

能力	クエリ例	回答チャンク	必要なドキュメントの文脈
1. エンティティの同一性	Northlakeは自社株買いにいくら費やしましたか？	同社は128億ドルの株式を買い戻しました。	冒頭部分でNorthlakeが「その会社」として特定されています。類似したSouthlakeのレポートは無関係です。
2. 期間またはバージョン	M40リビジョンBに適合するカートリッジはどれですか？	KC-42カートリッジを取り付けてください。	適用範囲のセクションには、これらの指示はリビジョンCではなくリビジョンBを対象としていると記載されています。
3. 定義とエイリアス	15 mg群の離脱率はどのくらいでしたか？	Zetaの離脱率は12.7%でした。	レポートではZetaを15 mg群と定義しています。その定義がなければ、チャンクは要求されたグループを特定できません。
4. テーブル構造	Maxモデルのバッテリー容量はいくつですか？	標準容量: 4,250 \| 4,700 \| 5,150。	テーブルのヘッダーには、mAh単位で測定されたMini \| Base \| Maxが設定されています。したがって、答えは5,150 mAhとなります。
5. 条件と例外	商用利用におけるバッテリー保証期間はどれくらいですか？	バッテリー保証は18か月間続きます。	セクションの冒頭で、この保証は商用設置に限定されることが規定されており、一般家庭への設置には異なる保証が適用されます。
6. 参照と代名詞	マラが副市長に就任したのはいつですか？	彼女は2021年に就任しました。	前の記述から、「彼女」とは同じく議論されているエリンではなくマラを指していることが確立されます。
7. リストの順序と位置	アンコールで最初に演奏された曲は何ですか？	14. Lantern Road。	別の箇所の注記には、14〜16曲目がアンコールを構成していたと記載されています。したがって、トラック14がそのオープニング曲となります。
8. セクションのスコープ	映画の撮影にはどのレンズが使用されましたか？	全編を通じて35mmプライムレンズが使用されました。	この一節は、宣伝用の写真に関する別のセクションではなく、「本撮影」に属しています。
9. 話者の属性	市長はどのような再開日を約束しましたか？	6月12日に再開します。	トランスクリプトでは、話者が市長であると特定されています。請負業者による同じ発言では、市長の約束を立証することはできません。
10. 時間経過に伴う変化	5月の改正後、どのような通知期間が適用されましたか？	通知期間は現在45日です。	改正の履歴により、この変更が5月に発効し、以前の30日ルールに代わるものであったことが確立されます。
11. 因果関係	西側のポンプが停止したのはなぜですか？	その不具合がシャットダウンを引き起こしました。	調査により「その不具合」とは西側ポンプのベアリングの焼き付きであることが特定されており、無関係な吸気口の閉塞とは区別されています。
12. 比喩的またはクロス言語の意味	比喩的：詩における「冬の部屋」は何を象徴していますか？クロス言語：フランス語の指示では、技術者にどの部品を取り外すように伝えていますか？	比喩的：物理的な部屋ではなく、追放を表しています。クロス言語： Retirez le capot.（カバーを取り外してください。）	比喩的：解説では「それ」を詩に繰り返し登場する「冬の部屋」のイメージとして特定しています。クロス言語：ガイドの用語集には、「capot」は出荷用カバーではなく保護用のモーターフードを意味すると明記されています。

テストされているクエリ、ドキュメント、および能力は、turbopufferの顧客との会話から着想を得ています。

一例として、プロパティマネジメント会社の検索ニーズを考えてみましょう。これらの企業には、テナント名、日付、その他のいくつかの重要な詳細を除いて同一の数百、時には数千の賃貸契約があります。そのデータセットの一般的なクエリは、「5パークアベニューの賃貸契約はいつ終了し、現在の家賃はいくらか？」というものかもしれません。また、賃貸契約は長くなる可能性があり、正しいドキュメントを取得したことを確認するための重要な曖昧性解消コンポーネント（日付、住所、テナント名など）は、月額賃貸料金を含む重要な回答文から非常に離れていることがよくあります。実際には、「月額家賃は$X,XXXです。」といった同一の文が、コーパス内の多くのドキュメントに出現する可能性があります。

優れた文脈的埋め込みモデルは、ドキュメント全体からの文脈を使用して正しいドキュメントを特定し、回答とその裏付けとなる文の両方を取得する必要があります。これにより、ユーザーや検索エージェントは回答を素早く検証し、それが正しいドキュメントからのものであることを確認できます。

各クエリについて、ターゲットドキュメント内の「回答」および「証拠」の文にラベル付けを行います。モデルが回答文を各証拠グループから少なくとも1つの文と一緒に取得した場合、当社の「リーダー十分性」テストに合格します。これらの文が合わさることで、読者が裏付け証拠付きで回答を検証するのに十分な文脈が提供されます。

文脈的埋め込みモデルがこれをうまく行うと、検索エージェントが確認する必要のあるトークンの数を劇的に削減できるだけでなく、ユーザーがドキュメント全体を読むことなく、元のクエリに対する正しい回答を特定できたことを迅速に確認することが非常に容易になります。

すべての証拠グループを回収する必要がありますが、グループの代替案のいずれか1つで回収するには十分です。これらの長いドキュメント全体で、同じ事実がいくつかの場所で述べられていることはよくあります。各証拠グループから1つの文だけを取得することは、リーダー十分性の基準を満たしており、そのため完璧な証拠想起として受け入れられます。

すべてのドキュメントは文にチャンク化され、すべてのモデルで同じ境界が使用されます。非文脈的埋め込みモデルについては、各文が個別に埋め込まれる条件と、ドキュメント全体が単一のチャンクとして埋め込まれる条件の2つがテストされます。

回答の再現率とエビデンスの再現率を測定するために、文レベルの条件を使用します。これは、文脈を持たないモデルが、周囲の文書へのアクセスなしに各文が埋め込まれた状態で、正しい回答とそれを裏付けるエビデンスを特定できるかどうかをテストするものです。これは意図的に困難な設定にされています。多くのクエリにおいて、回答文単体では、コーパス内の他の場所にある類似の文と区別するために必要な詳細が不足しています。

ドキュメントレベルの条件をドキュメント想起のベースラインとして使用します。これは、きめ細かな文の埋め込みが、ドキュメントあたり1つのベクトルを保存することと比較して、追加のストレージコストを正当化するのに十分な検索のメリットを提供するかどうかをテストします。文レベルのインデックスはドキュメントレベルのインデックスよりも大幅に多くのベクトルを作成するため、そのコストを正当化するには、1ベクトル/ドキュメントのベースラインを上回る必要があります。

すべての評価では、2,458,072個のすべてのチャンクに対する網羅的なランキングを使用します。したがって、モデル間の違いはインデックスの設定ではなく表現を反映しています。私たちは3つの主要な指標に焦点を当てています。

Document@K の定義は以下の通りです：

\text{Document@K}=1[\operatorname{rank}(d^{*})\le K]

ここで $d^{*}$ は $D_q$ 内で最もランクの高いドキュメントです。

Answer@K の定義は以下の通りです：

\text{Answer@K}=1[A_q\cap C_K(q)\ne\varnothing]

ここで $C_K(q)$ は全コーパスの上位 $K$ 個のチャンクであり、 $A_{q}$ は受け入れられた回答チャンクのセットです。

Evidence Recall@K は内で次のように測定されます：の文を類似度順に並べ替え、最もランクの高い回答文を除外し、残りのうち上位個をとします。証拠グループについて、何らかの代替案がを満たす場合、グループは回収されたとみなされ、 $d^{*}$ $d^{*}$ $R_K(q)$ $K$ $G_q=\{g_1,\ldots,g_m\}$ $g_j$ $E\in g_j$ $E\subseteq R_K(q)$

\text{EvidenceRecall@K}=1[\operatorname{rank}(d^{*})\le10]\cdot\frac{1}{m}\sum_{j=1}^{m}1[g_j\ \text{recovered}].

Document@K は、文脈化によって、語彙を共有する兄弟ドキュメントやディストラクターよりも正しいドキュメントが上位になるかどうかを問いかけます。

Answer@K は、回答文自体が上位チャンクの中にランクインするかどうかを問いかけます。

Evidence Recall@K は、最もランクの高い回答チャンクを除外した上で、正しいドキュメントの上位K個のチャンクの中で、サポートする文脈がどの程度回収されるかを問いかけます。回答を除外することで、証拠想起が Answer@K ですでに測定されているものを二重計上するのを防ぎ、サポートする文脈のためにすべての $K$ スロットを残します。ゴールドドキュメントが上位10個の取得されたドキュメントに含まれていることを要求することは、どのモデルも、浮上させることができなかったドキュメントに対して証拠のクレジットを受け取らないことを意味します。また、すべてのグループが回収されたクエリの割合である All-Evidence@10 も報告します。

これらの指標は、文脈的埋め込みモデルが直面する課題、すなわち、適切なドキュメントの特定、適切な回答の特定、および回答が正しい理由を示す最小限の文脈の復元を分解します。

図 3 は、プロパティマネジメントの例を用いて指標を示しています。

context-benchのドキュメント、回答、および証拠の取得がどのようにスコアリングされるか — 図 3: 賃貸クエリで示されたcontext-benchの指標。Document@Kは正しいドキュメントの取得をテストします。Answer@Kはその回答チャンクの取得をテストします。Evidence Recall@Kは、ターゲットドキュメント内のサポートする証拠グループの回収を測定します。この例では、家賃の検証に住所と賃貸年の両方の証拠が必要です。証拠想起では、トップの回答チャンクを除外し、ターゲットドキュメントがトップ10にランクインすることを求めます。

私たちは、4つの面で文脈的および非文脈的埋め込みモデルに対して私たちのモデルを評価します。

私たちの文脈的ベースラインは pplx-embed-context-v1-4B および voyage-context-4 です。私たちの非文脈的ベースラインは voyage-4-large およびNVIDIAの Nemotron-3-Embed-8B-BF16 であり、これらはチャンクを独立してエンコードします。各図に示されているように、ベースラインのセットは実験によって異なります。

この作業の動機となる能力を直接テストするcontext-benchから始め、次に文脈的埋め込みの標準的なパブリックベンチマークであるConTEBの結果を報告します。これらの改善が一般的な検索品質を犠牲にして得られたものでないことを確認するために、公開データセットから構築したドメイン固有のドキュメントおよびチャンク検索ベンチマークも評価します。最後に、デプロイにおける2つの実用的なプロパティ、すなわちベクトルあたりのストレージコストに対する検索品質と、インデックス作成時に使用されるチャンクサイズに対する感度を調べます。すべての評価では、最大32,768トークンのドキュメントを単一のパスでエンコードします。

はじめにの図 1 に示されているように、私たちのプレビューは、報告されているすべてのカットオフにおいてAnswer@KとEvidence Recall@Kでリードしており、All-Evidence@10でも同様です。K = 10において、45.5%の回答想起、40.6%の証拠想起、31.1%の全証拠想起を達成しています。また、Document@1およびDocument@10でもリードしており、それぞれ15.2%と61.6%に達しています。K = 10において、私たちのプレビューは、回答想起でvoyage-context-4を14.4パーセンテージポイント上回り、証拠想起で5.0ポイント上回っています。

私たちのプレビューモデルは、図 4のConTEBに示されたモデルの中で最高の平均nDCG@10を達成しています。すべてのタスクでリードしているわけではありません。pplx-context-v1-4BはNarrativeQAでより高いスコアを記録し、Nemotron-3-8BはCOVID-QAで最高スコアを記録しています。メインの著者らもConTEBの論文で指摘しているように、COVID-QAには、非常に抽出型であり、技術的な医療用語に対する単純な表面的な語彙マッチングで満たすことができるクエリとチャンクのペアリングが大部分含まれています。その結果、このタスクでは文脈の理解があまり役に立たず、非文脈的モデルが文脈的モデルよりも優れたパフォーマンスを発揮する傾向があります。

ConTEBにおける10でのタスクレベルnDCG — 図 4: クエリからチャンクへの設定におけるConTEBでのタスクレベルnDCG@10。平均は8つのタスクにわたる重み付けなしの平均です。

文脈的埋め込み向けに設計されたベンチマークを超えて、私たちはモデルのドメイン固有のパフォーマンスを評価します。

私たちのクエリからチャンク（Q2C）スイートは、LegalBenchやFinanceBenchなどのMTEBタスクと、公開データセットから独自にキュレーションした追加の検索タスクを使用します。関連する各ドキュメント内で、タスクが正確な回答スパンを提供している場合はそれに該当するものとして、そうでない場合はLLMがクエリとの関連性を判断して、チャンクに関連性のラベルが付けられます。クエリからドキュメント（Q2D）スイートは同じタスクを使用し、関連するドキュメントが取得されるかどうかをスコアリングします。

私たちのモデルは、図 5のチャンク検索で最高平均スコアを達成し、法務、技術、健康の各ドキュメントでリードしています。すべてのドキュメントでリードしているわけではありません。financeおよび多言語検索ではvoyage-context-4の方がスコアが高く、会話検索ではNemotron-3-8Bが最高スコアを記録しています。図 6のドキュメント検索では、私たちのモデルの平均スコアはvoyage-context-4をわずかに下回る一方で、技術ドメインではリードしています。pplx-context-v1-4Bベースラインは両方のスイートで平均スコアが低くなっており、これはConTEBのトレーニングセットのみでトレーニングされたことと一致しており、1つのベンチマークのゴールドチャンクに結び付けられたスーパービジョンは他のドキュメントにうまく転移しないことを示しています。

ドメイン別のクエリからチャンクへの検索スコア — 図 5: ドメインごとにグループ化された、クエリからチャンク（Q2C）タスクでの平均nDCG@10。ドメインバーは、そのドメイン内のタスクレベルスコアの重み付けなしの平均であり、全体的な平均は表示されているすべてのタスクにわたる重み付けなしの平均です。

ドメイン別のクエリからドキュメントへの検索スコア — 図 6: ドメインごとにグループ化された、クエリからドキュメント（Q2D）タスクでの平均検索スコア。ドメイン内の各バーは、そのタスクレベルの主要スコアの重み付けなしの平均であり、全体的な平均は表示されているすべてのタスクにわたる重み付けなしの平均です。

文脈的埋め込みモデルはチャンクごとに1つのベクトルを生成するため、私たちのモデルで構築されたインデックスには、同じチャンク化戦略を持つ従来のチャンクレベルインデックスとまったく同数のベクトルが含まれます。文脈化は、保存されるベクトルの数ではなく、各ベクトルが何をエンコードするかを変更します。したがって、ストレージのフットプリントは各ベクトルのサイズによって決まります。モデルはこれを削減する2つの方法を提供しています。埋め込みを2048次元から1024次元に切り詰めることと、int8に量子化することです。

図 7は、検索品質とベクトルストレージの間の好ましいトレードオフを示しています。1024次元において、当社のint8埋め込みはベクトルあたり1 KBを使用する一方で、float32で2048次元の場合（ベクトルあたり8 KBを使用）のvoyage-context-4のチャンク検索スコアをわずかに上回っています。埋め込みサイズを2048次元に増やすと、ベクトルあたり2 KBで検索品質がさらに向上します。これらのストレージ数値はベクトル単体を指しており、インデックスの残りの部分は含みません。

チャンク検索品質対ベクトルあたりのストレージ — 図 7: ベクトルあたりのストレージの関数としてのチャンク検索品質（平均nDCG@10）。実線はfloat32を示し、破線はint8を示します。ラベルは埋め込み次元を示しています。

図 8は、チャンクサイズが64から512トークンに増加しても、検索品質の変化がわずかであることを示しています。平均スコアは81.0%から79.9%へと、1.1パーセンテージポイント減少しています。これは、モデルがテストされたチャンクサイズ全体で有効性を維持していることを示唆しており、インデックス作成パイプラインがドキュメントの分割方法において柔軟性を持つことを可能にします。

チャンクサイズの感度：64〜512トークンのチャンクの検索スコア — 図 8: 当社モデルのチャンクサイズ感度。各点は74のMTEBタスクにわたる重み付けなしの平均nDCG@10であり、指定されたチャンクサイズでドキュメントがインデックス化されています。

turbopufferは、context-benchのすべてのコーパス、クエリ、ラベルを非公開に維持し、提出されたモデルの結果を報告します。このようなパブリックベンチマークでは、そのクエリやドキュメントに対する直接的なトレーニングが誘発され、徐々に飽和して、経時的な進捗追跡における価値が損なわれることになります。ベンチマークでのモデルの評価をご希望の場合は、turbopuffer（contextbench@turbopuffer.com）までご連絡ください。

当社のモデルのプレビューは Hugging Face で利用可能であり、この投稿のすべての結果はこのプレビューについて報告されています。私たちはPerplexity APIを通じてモデルを利用できるようにすること、およびturbopufferとともに長いドキュメントに対する検索をさらに改善することに取り組んでいます。

BibTeX

@online{perplexity2026ContextualEmbeddingBeyondTheGoldPassage,
  author = {{Perplexity} and Sarah Eslami and William Barber and Markus Krimmel and Antoine Chaffin and Bo Wang and Louis Milliken and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Contextual embedding beyond the gold passage}},
  date = {2026-09-30},
  url = {https://www.perplexity.ai/hub/blog/contextual-embedding-beyond-the-gold-passage}
}

はじめに

検索において文脈が重要な理由

ゴールドチャンク・スーパービジョンの限界

文脈学習に対する新しいアプローチ

損失関数

ドキュメントレベル対比損失

チャンクレベル蒸留損失

複合損失

トレーニングデータ

トレーニング設定

チャンクレベル検索のための新しいベンチマーク

ドキュメントとクエリ

回答と証拠のラベル

指標

評価結果

Context-bench

ConTEB

ドメインをまたいだ一般的な検索品質

検索品質とストレージコスト

チャンクサイズの感度

リリース

引用