超越黃金段落的上下文 embedding
用於檢索答案及其支援上下文的新訓練方法、模型與基準測試。
導言
上下文嵌入在整份文件的上下文中捕捉每個段落或片段的含義。它們的訓練和評估通常假設每個查詢有一個相關片段,稱為「黃金段落」。然而,黃金段落往往在實務上不夠用。它可能包含答案,但缺乏理解或驗證它所需的支援上下文,使其在孤立狀態下顯得模稜兩可。
我們正在推出 pplx-embed-v2-context-9b-preview,這是我們全新的脈絡嵌入模型。這個模型採用一種新穎方法訓練,使用 Perplexity 的 context compression model 作為教師。我們將其 token 級預測彙總為區塊級相關性分數,教導嵌入模型同時檢索答案區塊與支援脈絡,而非只檢索單一 gold 區塊。此模型可為每個區塊產生一個嵌入,且不會增加額外推論成本,並支援 1024 維與 int8 嵌入。
它在 context-bench(由 turbopuffer 創建並私有保存的用於上下文感知檢索的新基準測試)以及廣泛使用的公開基準測試 ConTEB 上實現了最先進的結果。我們的模型是在獨立於 context-bench 的情況下開發的,並作為盲測提交進行評估。
Context-bench 包含 21 個領域中 38,894 份長文件的 2,099 個查詢,並評估上下文嵌入的三種能力:在幾近重複的文件中進行文件消歧義、檢索其含義取決於遠處上下文的黃金片段,以及回憶驗證答案所需的支援證據。
該模型的預覽版已公開在 Hugging Face 上。該基準測試由 turbopuffer 私人保存,以降低訓練污染的風險並保留其用於衡量進展的價值。若要要求評估,請透過 contextbench@turbopuffer.com 與 turbopuffer 聯繫。
為什麼上下文對檢索至關重要
檢索系統通常將長文件分割成較小的片段,以便可以獨立進行索引和搜尋。片段化在實務上很方便,但它去除了每個片段原本出現的上下文,在資訊壓縮的粒度與編碼期間使用的上下文之間製造了權衡取捨。片段可能會參考先前引入的實體、從章節標題繼承其含義,或依賴文件中其他地方的定義。一旦被提取,它可能不再包含足夠的資訊,無法可靠地與查詢相匹配。將整份文件編碼為單一向量並無法解決此問題,因為單一池化表示無法忠實地捕捉長文件的每一個面向。
上下文 embedding 模型透過在其周圍內容的上下文中表示每個片段來解決這個限制,最常見的是透過後期片段化(late chunking):文件在單次前向傳遞中進行編碼,並且隨後對片段表示進行池化,以便計算每個片段向量時都能看到整份文件。先前的研究工作,例如 ConTEB 以及我們自己的 pplx-embed-context-v1,已經表明上下文化的片段表示大幅改善了對獨立編碼片段的檢索,特別是在長文件上。
黃金片段監督的限制
訓練上下文 embedding 模型需要識別文件的哪些部分與給定查詢相關的監督。常見的方法是黃金片段標註:對於每個查詢,標註者(通常是大語言模型 [LLM])會識別回答該查詢的文件片段。
訓練通常結合了兩種對比損失:將黃金片段與來自其他文件的片段進行對比的跨文件損失,以及將其與同一文件中的其他片段進行對比的文件內損失。
這種方法有一些限制:
- 只有一個片段是相關的。它將文件中的所有其他片段視為負樣本,包括那些帶有有用支援資訊的片段。文件層級監督則處於另一個極端。它將文件識別為相關文件,但未指定其中哪些片段重要。在實務上,相關性通常介於這些極端之間。帶有答案的片段可能取決於少數幾個引入實體、解析參照或提供補充事實的支援片段,而文件的其餘部分則是不相關的。因此,模型必須學習正確的選擇性水準:比單一黃金片段更廣泛,但比整份文件更具針對性。
- 粗糙的監督。由於每個標註都識別單一黃金片段,而不是捕捉整份文件的相關性程度,因此它為產生它所花費的計算量提供了有限的訓練訊號。
- 擴展成本高昂。每個訓練對都需要 LLM 閱讀文件並選擇相關片段,因此標註成本隨著訓練集的大小呈線性增長,並限制了訓練資料的數量和多樣性。
- 對片段邊界敏感。標註也與標註期間使用的片段邊界綁定。分配給固定 Token 大小視窗的黃金標籤並未指定哪些較短的句子或較長的段落是相關的。因此,改變片段化策略,或跨多個片段化進行訓練以提高對文件在索引時如何分割的強固性,可能需要重新標註語料庫。
上下文學習的新方法
我們透過從查詢感知上下文壓縮模型中提取相關性判斷,來解決黃金片段監督的限制。這個模型充當教師:它共同讀取查詢與文件,並為每個文件 Token 分配相關性分數。其預測為訓練上下文 embedding 提供了幾個優勢:
- 靈活的片段邊界。Token 層級的相關性分數可以在任何選定的片段邊界上進行聚合,允許相同的教師預測監督不同的片段化,而無需重新標註。
- 連續相關性。與二元黃金片段標籤不同,教師提供連續的分數,這些分數捕捉了自然區分答案帶有片段、支援上下文和不相關內容的相關性程度。
- 降低標註成本。教師結構精簡且專門用於相關性評分,與通用的 LLM 相比,在大規模監督下的成本要低得多。
我們透過查詢-文件對批次上的文件層級對比損失與片段層級蒸餾損失的加權和來訓練我們的模型。對於每個查詢,配對的文件作為正樣本,而同一批次中的其餘文件作為負樣本。
對於每個批次,我們隨機選擇一個片段化策略,相應地分割文件,並在片段之間插入分隔符號 Token。然後,我們在單次前向傳遞中處理每個文件,並對每個片段內的 Token 表示進行平均池化,以獲得上下文片段嵌入。查詢分開進行編碼,並對其 Token 表示進行平均池化。最後,我們計算批次中每個查詢嵌入與每個片段嵌入之間的餘弦相似度。
損失函數
文件層級對比損失
雖然我們的 embedding 模型只產生片段層級的相似度,但我們可以自然地從中衍生出文件層級的相似度。我們認為文件 d 與查詢 q 的相關性等同於其最相關的片段。這種評分規則受啟發於 ColBERT 的 MaxSim 操作,此處應用於片段而非 Token。
具體而言,給定具有嵌入 q 的查詢 q 以及作為片段 c 的有序列表(帶有嵌入 c)的文件 d,我們將文件層級相似度定義為:
給定這些文件層級的相似度,我們可以在批次內負樣本上構建文件層級的 InfoNCE 目標。
對於查詢 q,令 d⁺ 表示其相關文件,𝒟 表示批次中的文件。對比損失如下所示,為求易讀性而省略了溫度:
片段層級蒸餾損失
對比損失教導模型哪份文件與查詢相關。蒸餾損失教導模型該文件中的相關性位於何處,這對上下文模型至關重要。
在訓練期間,我們將每個正查詢-文件對傳遞給我們的上下文壓縮模型,該模型為文件中的每個 Token 分配相關性分數。與文件層級評分一樣,我們從每個片段最相關的內容中衍生出其相關性。為了減少對極端 Token(包括片段邊界處的 Token)的敏感度,我們將片段層級相關性定義為片段內前 n 個 Token 分數的平均值。
對於每個查詢,我們將溫度縮放的 softmax 套用到正文件中教師的片段層級相關性分數,以獲得目標分佈。批次中其他文件中的片段獲得零目標機率。我們透過最小化目標與其對批次中所有片段的預測分佈之間的正向 KL 散度,來訓練 embedding 模型以匹配此目標:
在此,上標 T 和 S 分別表示教師和學生,rⱼ 是教師對正文件 d⁺ 中片段 cⱼ 的相關性分數。教師的目標分佈為批次中所有其他文件中的片段分配零機率。
與單一黃金片段標籤不同,這個目標捕捉了相關性程度。支援片段根據教師的分數獲得權重,而不是被視為負樣本,這教導模型檢索支援上下文以及答案。
組合損失
我們的組合訓練目標是文件層級對比損失和片段層級蒸餾損失的加權和。我們對查詢-文件對批次求這個加權損失的平均值。
圖 2 說明了我們的訓練方法。上下文壓縮器僅在訓練期間充當教師。在推論時,embedding 模型每個片段產生一個上下文 embedding,無需額外的壓縮或重新排序階段。該方法改善了上下文 embedding 的學習方式,而不會增加索引儲存或在檢索時增加教師模型的延遲。
訓練資料
訓練資料由大約 430 個涵蓋 50 多種語言的公開及內部查詢-文件資料集組成。
我們透過過濾個資(PII)的生產資料以及在長文件上合成相關查詢,來建構內部配對資料集。在每個前向傳遞中,我們選擇一個資料集並從中抽樣整個批次,以增加批次內負樣本的難度並避免捷徑學習。我們的訓練資料集均不帶有片段層級的標註:所有文件內監督均來自壓縮模型,且訓練過程未用到任何 ConTEB 資料。此外,模型開發期間並未提供任何 context-bench 資料。
訓練設置
模型從內部的 9B 參數 ColBERT 檢索模型開始,並透過線性投影層產生 2048 維嵌入。我們使用學習到的 <|chunk_sep|> Token 標記片段邊界,並透過平均其 Token 嵌入來形成每個片段嵌入。查詢由同一模型進行編碼,其 Token 嵌入被平均為單一向量。
我們使用 Matryoshka 訓練 來支援 1024 維與 2048 維嵌入,並使用量化感知訓練來支援 原生 int8 嵌入。在訓練期間,我們會逐步提高學習率,將其維持不變,然後再降低。
發布的模型是一個模型融合(model soup),它平均了來自同一訓練執行的多個檢查點的權重。
用於片段層級檢索的新基準測試
諸如 ConTEB 等公開上下文檢索基準測試共用了黃金片段監督背後的假設:每個查詢都有一個單一相關片段,且模型僅因將該片段排名第一而獲得獎勵。它們也繼承了其限制。
首先,ConTEB 測試了片段在沒有周圍上下文時會產生歧義的任務上的檢索能力。在這些任務中,上下文模型的表現優於獨立編碼每個片段的模型。然而,它並未探討模型是否也會浮現文件中使該片段易於理解的其他部分。
其次,當同一語料庫中幾近相同的文件僅在包圍原本相同的句子的上下文有所不同時,它並未系統性地測試是否能找到正確的文件。
當搜尋代理程式或使用者必須從少數檢索到的句子而非整份文件來理解並驗證答案時,這兩種能力都至關重要。因此,我們建構了 context-bench,這是一項針對長文件檢索的受控基準測試,旨在區分文件上下文的使用與一般檢索品質。它測試上下文嵌入是否利用文件中其他地方的資訊來支援三種能力:
- 文件消歧義:在幾近相同的替代項目中識別正確的文件。
- 答案檢索:檢索其含義取決於文件中其他地方細節的帶有答案的片段。
- 證據檢索:檢索釐清或佐證答案的支援片段。
Context-bench 包含 2,099 個查詢與 38,894 份文件。使用句子長度區塊,總共產生 2,458,072 個區塊。這些查詢涵蓋 21 個領域,包括公司申報文件、臨床研究、旅遊、娛樂、教育、政府、法律合約以及軟體文件。
每個查詢都旨在測試十二種上下文能力之一。主要目標文件故意設計得很長:1,197 個不同的主要目標文件中有 1,061 個至少有 200 個句子,中位數長度約為 6,100 個 Token。每個查詢在語料庫中都有剛好一個正確答案。若在黃金文件中多次陳述同一事實(例如在摘要句和表格列中),則其中任何句子均可被接受為答案。
答案路徑是答案片段與解讀或驗證它所需的支援證據的有效組合。在 2,099 個查詢中,主要目標文件的答案路徑有 964 個查詢對應一組證據群組,735 個查詢對應兩組,332 個查詢對應三組或更多,68 個查詢則沒有。替代的有效答案路徑可能需要不同的證據群組。
表 1:基準測試統計數據。
統計數據 | 數值 |
查詢數 | 2,099 |
文件數 | 38,894 |
句子片段數 | 2,458,072 |
主要目標文件長度中位數 | 6,100 個 Token |
領域數 | 21 |
每個查詢的證據群組(主要目標文件答案路徑) | 1:964;2:735;3+:332;無:68 |
表 2:context-bench 測試的十二種上下文能力與說明範例。
能力 | 範例查詢 | 答案片段 | 所需的檔案上下文 |
1. 實體身分 | Northlake 花費多少金額來買回股份? | 該公司買回了 128 億美元的股份。 | 導言將 Northlake 識別為「該公司」。類似的 Southlake 報告則不相關。 |
2. 期間或版本 | 哪種濾心適用於 M40 B 版修訂版? | 安裝 KC-42 濾心。 | 適用性章節指出這些說明適用於 B 版,而非 C 版。 |
3. 定義與別名 | 15 毫克組的退出率是多少? | Zeta 的退出率為 12.7%。 | 報告將 Zeta 定義為 15 毫克組。若無該定義,該片段便無法識別所請求的組別。 |
4. 表格結構 | Max 型號的電池容量是多少? | 典型容量:4,250 | 4,700 | 5,150。 | 表格標題確立了 Mini | Base | Max,以 mAh 為單位。因此答案為 5,150 mAh。 |
5. 條件與例外 | 商業用途的電池保固期有多長? | 電池保固期為 18 個月。 | 章節導言將此保固限制於商業安裝;家用安裝則享有不同的保固。 |
6. 參照與代名詞 | Mara 是在何時成為副市長的? | 她於 2021 年就職。 | 前文確立了「她」指的是 Mara,而非同被討論的 Elin。 |
7. 清單順序與位置 | 哪首歌是安可曲的開場曲? | 14. Lantern Road。 | 其他地方的註解指出第 14 至 16 首歌曲構成安可曲。因此第 14 首音軌為其開場曲。 |
8. 章節範圍 | 該電影的攝影使用了哪顆鏡頭? | 全程使用 35 毫米定焦鏡頭。 | 此段落屬於「主攝影」,而非關於宣傳照的獨立章節。 |
9. 發言者歸屬 | 市長承諾了哪個重新開放日期? | 我們將於 6 月 12 日重新開放。 | 逐字稿識別出市長為發言者。承包商說出相同的話並不能確立市長的承諾。 |
10. 隨時間的變化 | 5 月修訂案生效後的預告期為何? | 目前的預告期為 45 天。 | 修訂歷史確立此變更於 5 月生效,取代了先前的 30 天規定。 |
11. 因果關係 | 西側幫浦為何停止運作? | 該故障導致了系統關閉。 | 調查將「該故障」識別為西側幫浦中的軸承卡死,並將其與不相關的進氣口阻塞區分開來。 |
12. 隱喻或跨語言含義 | 隱喻: 詩中的「冬日房間」象徵什麼? 跨語言: 法語指令指示技術人員移除哪個組件? | 隱喻: 它代表流放,而非實體房間。 跨語言: Retirez le capot. (移除外蓋。) | 隱喻: 評論將「它」識別為詩中重複出現的「冬日房間」意象。 跨語言: 指南的詞彙表指明「capot」意指保護性馬達罩,而非運送護蓋。 |
文件與查詢
正在測試的查詢、文件與能力皆受到與 turbopuffer 客戶對話的啟發。
舉例來說,考慮物業管理公司的搜尋需求。這些公司擁有數百甚至數千份租賃協議,這些協議僅在承租人姓名、日期和其他一些關鍵細節上有所不同。該資料集的常見查詢可能是「5 Park Avenue 的租約何時到期且目前的租金是多少?」。租賃協議也可能很長,且能確認您已檢索到正確文件的關鍵消歧義組件(如日期、地址、承租人姓名等)通常可能距離包含每月租金金額的關鍵答案句非常遙遠。在實務上,「Monthly rent is $X,XXX.」等相同的句子可能會出現在語料庫的許多文件中。
優秀的上下文 embedding 模型應利用來自整份文件的上下文來識別正確的文件,並檢索答案及其支援句子。這讓使用者或 AI 代理程式能夠快速驗證答案,並確認它來自正確的文件。
答案與證據標籤
對於每個查詢,我們在目標文件中標註「答案」與「證據」句子。如果模型檢索到答案句子以及來自每個證據群組的至少一個句子,則通過我們的「讀者充分性」測試。這些句子共同提供了足夠的上下文,供讀者透過支援證據來驗證答案。
當上下文嵌入模型能很好地做到這一點時,它們可以大幅減少 AI 代理程式需要審查的 Token 數量,同時也能讓個人更容易快速確認他們已經找到原始查詢的正確答案,而不必閱讀整份文件。
必須恢復每個證據群組,但群組的任何替代方案中的一個就足以恢復它。常見的情況是在這些長篇文件的多個地方陳述相同的事實。從每個證據群組檢索僅一個句子即可符合讀者充分性標準,因此將被接受為完美的證據回憶。
指標
每份文件都被切分為句子片段,且所有模型都使用相同的邊界。非上下文嵌入模型測試了兩種條件:一種是每個句子都被獨立嵌入,另一種是整份文件被嵌入為單一片段。
我們使用句子層級條件來衡量答案回憶與證據回憶。它測試非上下文模型是否能在每個句子在沒有存取周圍文件的情況下進行嵌入時,識別出正確答案與支援證據。這是有意設計的挑戰。在許多查詢中,僅憑答案句子本身缺乏將其與語料庫中其他地方相似句子區分開來所需的細節。
我們使用文件層級條件作為文件回憶基準。它測試與每個文件儲存一個向量的成本相比,細粒度的句子嵌入是否提供了足夠的檢索效益來證明其額外的儲存成本是合理的。句子層級索引產生的向量實質上多於文件層級索引,因此它應當超越每個文件一個向量的基準,以證明該成本的合理性。
所有評估都使用針對所有 2,458,072 個片段的窮舉排名。因此,模型之間的差異反映的是表示方式,而非索引配置。我們專注於三個關鍵指標:
Document@K 的定義為:
其中 是 中排名最高的文件。
Answer@K 的定義為:
其中 是整個語料庫中前 個區塊,而 是可接受答案區塊的集合。
Evidence Recall@K 在 內的衡量方式如下:依相似度對 的句子進行排名,移除排名最高的答案句子,並讓 為剩下的前 個。對於證據群組 ,如果某個替代方案 滿足 ,則群組 被恢復,且
Document@K 詢問上下文是否能讓正確的文件勝過共用其詞彙的同級與干擾項目。
Answer@K 詢問答案句子本身是否名列前茅的片段中。
Evidence Recall@K 會衡量:在排除最高排名的答案區塊後,於正確文件的前 K 個區塊中,回收了多少支援脈絡。移除答案可避免 evidence recall 與 Answer@K 已經衡量的內容重複計算,並保留所有 個位置供支援脈絡使用。要求 gold 文件必須位於前 10 個檢索文件中,表示模型不會因為它本來就不會找出的文件而獲得 evidence 點數。我們也報告 All-Evidence@K,即所有群組都被回收的查詢比例。
這些指標共同解析了上下文嵌入模型所面臨的挑戰:找到正確的文件、找到正確的答案,以及恢復足以證明答案正確性的最小上下文。
圖 3 以物業管理範例說明了這些指標。
評估結果
我們從四個方面評估了我們的模型與上下文及非上下文 embedding 模型的表現。
我們的脈絡基準模型是 pplx-embed-context-v1-4B 與 voyage-context-4。我們的非脈絡基準模型是 voyage-4-large 與 NVIDIA 的 Nemotron-3-Embed-8B-BF16,它們會獨立編碼區塊。基準模型集合會因實驗而異,如各圖所示。
我們從 context-bench 開始,它直接測試了推動這項工作的能力,然後回報了 ConTEB(上下文嵌入的標準公開基準測試)的結果。為了檢查這些增益是否以犧牲一般檢索品質為代價,我們還評估了我們從公開資料集建構的特定領域文件與片段檢索基準測試。最後,我們檢驗了部署時的兩個實際屬性:檢索品質與每個向量的儲存成本之間的關係,以及對索引時所用片段大小的敏感度。所有評估皆在單次前向傳遞中對最多 32,768 個 Token 的文件進行編碼。
Context-bench
如導言中的圖 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 個百分點。
ConTEB
我們的預覽版模型在圖 4 中 ConTEB 所顯示的模型中實現了最高的平均 nDCG@10。它並非在每個任務中都領先:pplx-context-v1-4B 在 NarrativeQA 上得分較高,而 Nemotron-3-8B 在 COVID-QA 上得分最高。正如主要作者在 ConTEB 論文中所指出的,COVID-QA 主要包含高度提取式的查詢-片段配對,可以透過對醫療技術術語進行簡單的表面詞彙匹配來滿足。因此,上下文理解對這項任務的用處較小,非上下文模型的表現通常優於上下文模型。
跨領域的一般檢索品質
除了專為上下文嵌入設計的基準測試之外,我們還評估了我們模型的特定領域效能。
我們的查詢至片段(Q2C)套件使用 MTEB 任務(例如 LegalBench 和 FinanceBench)以及我們從公開資料集中策劃的其他檢索任務。在每個相關文件中,如果任務提供了確切的答案範圍,則片段被標記為相關,否則透過 LLM 判斷其與查詢的相關性來標記。查詢至文件(Q2D)套件使用相同的任務,並對是否檢索到相關文件進行評分。
我們的模型在圖 5 中的片段檢索上獲得了最高的平均分數,並在法律、技術和健康領域領先。它並非在每個領域都領先:voyage-context-4 在財務和多語言檢索中得分較高,而 Nemotron-3-8B 在對話檢索中得分最高。在圖 6 的文件檢索中,我們的模型的平均得分略低於 voyage-context-4,同時在技術領域領先。pplx-context-v1-4B 基準模型在兩個套件中的平均得分較低,這與它僅在 ConTEB 訓練集上進行過訓練一致,這表明與某個基準測試的黃金片段繫在一起的監督很難轉移到其他領域。
檢索品質與儲存成本
上下文嵌入模型每個片段產生一個向量,因此使用我們模型建立的索引包含的向量數量,與採用相同片段化策略的傳統片段層級索引完全相同。上下文設定改變的是每個向量編碼的內容,而不是儲存的向量數量。因此,儲存佔用空間取決於每個向量的大小。該模型提供了兩種減少它的方法:將嵌入從 2048 維截斷至 1024 維,以及將其量化為 int8。
圖 7 顯示了檢索品質與向量儲存之間有利的權衡取捨。在 1024 維下,我們的 int8 嵌入每個向量使用 1 KB,同時稍微超越了 float32 中 2048 維下 voyage-context-4 的片段檢索分數(每個向量使用 8 KB)。將我們的嵌入大小增加到 2048 維可在每個向量 2 KB 的情況下進一步提高檢索品質。這些儲存數字僅指向量本身,不包含索引的其餘部分。
片段大小敏感度
圖 8 顯示隨著片段大小從 64 個 Token 增加到 512 個 Token,檢索品質只有適度變化:平均分數從 81.0% 下降到 79.9%,減少了 1.1 個百分點。這表明該模型在測試的片段大小範圍內仍然有效,為索引管線在如何分割文件方面提供了靈活性。
發布
turbopuffer 會對 context-bench 的完整語料庫、查詢與標籤嚴格保密,並回報所提交模型的評估結果。這類公開基準測試會引誘他人直接針對其查詢與文件進行訓練,這將導致其逐漸飽和,並削弱其追蹤長期進展的價值。如果您希望您的模型接受基準測試的評估,請透過 contextbench@turbopuffer.com 與 turbopuffer 聯繫。
我們的模型預覽版可在 Hugging Face 上取得,這篇貼文中的所有結果都是針對此預覽版進行回報的。我們正致力於透過 Perplexity API 提供該模型,並與 turbopuffer 一起進一步改善對長文件的檢索。
引用
@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}
}