用於改善資訊片段的查詢感知上下文壓縮

每個答案都始於憑證。在搜尋系統中，這些憑證通常來自文件：標題、摘要、資訊片段和程式碼片段，它們作為上下文傳遞給答案模型或代理程式。

這些原始上下文包含許多雜訊。例如，網頁可能包含使用者請求所需的資訊，但也可能包含干擾項。這些干擾項會同時出現在主體和輔助元素中，例如導覽文字元素、不相關的廣告、後設資料等等。將這些干擾項傳遞給下游代理程式會產生三個問題。

首先，它會損害準確性。即使是最強大的模型，其容量也是有限的。長串的不相關資訊會浪費模型容量，導致「上下文腐爛」，從而削弱模型處理實際使用者請求的能力。因此，最終的回應更有可能漏掉關鍵事實、過度權衡低品質資訊，或是產生難以在來源中找到依據的論點。

其次，它會導致延遲倒退。更長的上下文意味著下游模型需要處理更多權杖，特別是在查詢需要來自許多候選頁面的憑證時。儘管部分延遲成本是在預先填入階段承擔的，但更顯著的成本是在推理階段支付的，因為模型需要更多的推理權杖來處理不相關的上下文。

第三，它會增加成本。傳遞給模型的每個不必要權杖都會增加服務使用者請求的成本，因為輸入權杖和推理權杖的使用量都會隨著雜訊較多的上下文而增加。干擾項不只會降低品質；它們最終會迫使您為較差的品質支付更高的費用。

放大

為了同時提升 Perplexity 各應用程式和 API 平台的準確性、速度和成本效益，我們在改善上下文精確度方面投入了大量資金。我們這樣做的方法之一是精進我們的資訊片段生成演算法。我們將資訊片段生成視為一個上下文壓縮問題。尋找特定資訊的模型無法從文件的通用摘要或節錄中獲益。相反地，它們需要最小、最精準萃取的來源資訊片段來回應使用者的請求。其他一切都可以也必須被移除。

因此，一個好的資訊片段應該做到三件事：

透過呈現為模型回應提供依據所需的精確憑證來提升準確性。

在進行 LLM 呼叫之前移除不相關的上下文，以減少延遲和成本。

透過保持引文保真度並保持來源用詞完整來確保可追溯性。

本月，我們在應用程式和 API 平台中部署了一個全新的先進資訊片段生成器。此模組的核心是一個查詢感知上下文壓縮模型，它能為每個查詢和候選結果決定應該保留哪些子字串。本文描述了我們建構和訓練該模型的方針，以便在此關鍵任務上實現同級最佳的效能。

作為查詢感知壓縮的資訊片段

首要任務是定義任務本身。我們希望這個模型做什麼，以及我們應該如何定義輸入和輸出結構描述？

資訊片段方法大致可分為兩大類。第一種是基於選擇的：尋找相關的視窗、區塊、句子或段落，並將其傳遞到下游。第二種是基於生成的：要求模型從頁面寫出以查詢為重點的摘要。

我們對準確性、延遲和成本的關注讓設計選擇變得明確。我們可以排除生成，因為為每個頁面建立新摘要會損害所有三個重點的效能。摘要不適合我們所關心的憑證層。它可能會轉述來源，使引文對齊變得更加困難。它還可能引入頁面中不存在的用詞，當資訊片段被用作憑證而不是最終答案時，這是很危險的。所涉及的延遲和成本使得生成更加令人難以接受。

相反地，我們將任務定義為查詢感知萃取式壓縮：將檢索到的上下文中有幫助的部分與干擾部分分開。具體來說，我們的模型必須接受查詢和候選結果，並決定保留哪些子字串（最能支援查詢的子字串）以及捨棄哪些子字串（其餘部分）。模型輸出會保留來源文字，而不是重寫文字。這使得結果更易於引用、更易於驗證，且傳遞到下游的成本更低。

例如，考慮以下查詢和檢索到的結果：

放大

一個合理的模型輸出是選擇粗體句子：「在 Comet 中，助理可以...」。

我們的方法遵循與先前上下文壓縮工作（例如 FliCo、Provence 和 LooComp）大致相同的理念，並針對生產搜尋系統中的資訊片段生成進行了調整。重要的是，該模型在我們的原始檢索階段之後充當精確度階段。正如我們之前的 Perplexity 研究文章《介紹 Perplexity 搜尋 API》中所討論的，我們將檢索系統架構設計為原生在子文件或資訊片段層級運作，這已經讓我們能夠相當好地平衡精確度和召回率。引入查詢感知上下文壓縮模型使精確度與召回率的柏金圖邊界進一步向外推移。

建構與訓練上下文壓縮模型

我們在開發模型時考慮了三個主要考量：對查詢和上下文的聯合理解、細粒度的句子層級選擇，以及適合極度嚴格延遲預算的效率。

模型架構

我們使用 pplx-diffusion 模型作為骨幹。這是 pplx-embed-v1 背後的同一模型系列，我們先前的學術工作《擴散預訓練密集與上下文嵌入》以及我們的生產基準測試都證實它是適用於查詢-上下文對的強大雙向編碼器。此模型系列的關鍵屬性之一是雙向上下文：在模型決定要保留什麼內容之前，每個權杖表示都可以關注完整查詢和完整候選上下文。

在此骨幹之上，我們訓練了一個輕量級壓縮頭，用於預測應保留上下文的哪些部分。由於不涉及生成，因此這些預測是在整個上下文中平行進行的。在服務時，資訊片段引擎會在句子層級彙總這些預測，套用閾值，並將結果裁切至要求的權杖預算。

監督管線

訓練此壓縮器需要在正確的粒度層級進行監督。文件層級關聯性標籤顯然不適合我們的萃取式壓縮任務。為了產生足夠細粒度的資料以進行監督式學習，我們建構了一個子字串標記管線，用於標記與查詢相關的憑證子字串，以及應移除的干擾項子字串。

我們的管線使用 LLM 作為裁判的設定。給定使用者查詢以及包含其連結、標題和摘要的候選網頁，裁判首先執行查詢理解，分析查詢並產生可能的使用者意圖清單。以這些意圖為錨點，裁判接著處理候選內容，並傳回從文字中逐字複製的子字串，每個子字串都有一個類別，以使標籤更易於檢查。

然後，我們將傳回的子字串與來源文字進行配對。不出所料，大多數裁判輸出已經是確切的複製：簡單的字串比對恢復了 98% 的子字串。新增一個簡單的基於正規表示式的比對通道使子字串恢復率達到 100%。這為我們提供了可靠、細粒度的子字串，可以轉換為權杖層級的保留/捨棄監督。

我們使用具有手動標記子字串的小型策劃資料集評估了這個監督管線，比較了較小的裁判模型、不同的提示和不同的步驟設定。表現最佳的設定是兩階段管線：首先進行查詢理解，然後進行分類子字串標記。我們也透過下游可驗證評估（例如 BrowseComp 和 SimpleQA）驗證了一組萃取的子字串，在這些評估中，僅使用保留的憑證子字串即可保留強大的分數，同時顯著減少輸入權杖。

使用此管線，我們標記了 75k 個查詢-文件對，並使用產生的子字串透過二元交叉熵來訓練壓縮頭。此過程可讓我們的查詢-上下文壓縮模型保持來源文字完整，同時移除不太可能協助下游模型服務使用者請求的上下文。

確保即時延遲

上下文壓縮位於下游模型之前，使其成為阻斷操作。此外，每個壓縮都取決於查詢。因此，線上路徑必須在嚴格的延遲限制內為每個候選文件評估查詢-上下文對。緩慢的壓縮模型是適得其反的，因為更高精確度帶來的延遲好處會被壓縮延遲本身所抵銷。同時，智能較低的壓縮模型會對要剪裁和保留的內容做出較差的決定。

實際問題是，在壓縮品質開始下降之前，我們可以安全地移除多少模型容量。我們將完整的 28 層 pplx-diffusion 骨幹與透過層剪枝產生並針對搜尋路徑的 11 層和 17 層變體進行比較。對於每一個變體，我們都會掃描壓縮閾值並測量兩個數量：每個查詢傳送到下游的平均上下文權杖數，以及壓縮後保留的有用憑證比例。

圖 2 顯示了品質-效率邊界。當模型向左上方移動時會更好：更少的下游權杖以及保留更多有用的憑證。28 層模型提供了品質參考。11 層模型展示了過度 agressively 壓縮模型的風險。剪枝後的 17 層模型代表了一個折衷方案：它在飽和狀態下緊密追蹤 28 層模型，但在大多數生產流量運作的曲線陡峭部分會出現微小的差距。

為了縮小該差距，我們採用了權杖層級知識蒸餾。我們的方法是常規的：我們透過教師模型預測上的軟交叉熵項來擴充標準損失，並由蒸餾係數加權。這足以讓學生模型達到同等水準，讓我們能夠在生產環境中完全切換到蒸餾後的 17 層模型。這個新的生產模型使推論延遲降低了 35-40%，總體 GPU 計算量降低了 40-45%，且相對於 28 層教師模型，品質沒有下降。生產延遲在 20 毫秒（p99）以下：足夠小，可以加入服務路徑，同時大幅減少傳遞到答案模型的總權杖數。

放大

品質與權杖效率

我們使用 Perplexity 的 Agent API 作為測試平台來分析上下文壓縮的有效性。我們評估三個 Agent API 預設設定：

「低」上下文預設，將每個結果集的權杖預算限制為 1000 個權杖。

「中」上下文預設，將每個結果集的權杖預算限制為 4000 個權杖。

「高」上下文預設，將每個結果集的權杖預算限制為 10000 個權杖。

標準、無壓縮和壓縮設定都配置為遵守這些權杖預算。

代理式多步驟搜尋 (BrowseComp)

我們首先檢驗壓縮對 BrowseComp 基準測試上代理式多步驟搜尋工作流程的影響。我們使用開源的 search_evals 套件執行此評估。所有執行的評分都是相同的，使用 OpenAI 的標準 BrowseComp LLM 裁判提示。

關注的兩個維度是基準測試準確性和權杖使用量。重要的是，我們在查詢層級而非單個步驟層級測量權杖使用量，以便測量在整個請求生命週期中產生的實際權杖負載。圖 3 顯示了「分數-權杖」邊界（準確度分數對權杖使用量）。

放大

壓縮全面帶來了新的柏金圖邊界。對於每個設定，引入壓縮可將查詢層級的權杖使用量減少 10% 到 70% 不等，準確度提升介於 4 到 4.81 個百分點之間。引入壓縮甚至能讓我們的「低」預設設定表現超越無壓縮的「high」預設設定，同時將權杖使用量減少三倍以上。

我們觀察到，透過壓縮，「高」正如我們所預期的那樣產生比「中」更高的準確度。然而有趣的是，它在較低的權杖使用量下做到了这一点。這揭示了壓縮的一個微妙但重要的效果：透過壓縮，即使增加每個步驟的上下文大小，也可能使模型能夠採取更少的步驟來得出正確結果。探索這種非單調性是未來工作的一個有前景的方向。

SimpleQA：單步驟事實性

BrowseComp 強調多步驟研究，但許多生產工作流程涉及單步驟事實查詢。為了確定壓縮是否有助於單步驟狀態，我們也檢驗了 SimpleQA（一個包含 4,326 個問題的基準測試，需要在單個搜尋步驟中回答，而不是透過代理迴圈）上的效能。

如前所述，我們使用標準裁判提示繪製了準確度與每個任務的平均總權杖數的關係圖。圖 4 顯示了此單步驟設定中的分數-權杖邊界。儘管效應大小在單步驟設定中更為壓縮，但我們再次觀察到壓縮同時提高了所有預設設定的準確度和效率，從而引入了新的柏金圖邊界。啟用壓縮後，「中」預設設定達到了 95% 的準確度，每個文件平均只需 200 個權杖。鑑於平均文件長度超過 10,000 個權杖，這代表在壓縮率超過 50 的情況下實現了前沿級別的效能。

放大

什麼會留在資訊片段中？

第 4.1 節和第 4.2 節中的下游收益是端到端的。為了了解壓縮如何改變單個資訊片段，我們執行了一項獨立評估，使用 LLM 裁判將每個檢索到的資訊片段的每個權杖分類為六個類別之一：

關鍵：回答使用者查詢不可或缺的憑證。

離題：可能對其他某些目的有用，但與當前查詢無關的資訊。

廣告：會分散對使用者查詢回答注意力的不相關廣告。

後設資料：關於文件內容的後設資料。

UI 與導覽：用於前端顯示和導覽的元素。

重複：先前已併入資訊的重複。

我們的評估在驗證集中的 1,000 個混合網域查詢上執行，將生產堆疊與關閉壓縮且除此以外完全相同的基準進行比較。如圖 5 所示，與無壓縮基準相比，壓縮平均將每個資訊片段中關鍵權杖的比例提高了 63%。我們觀察到不相關權杖對應減少了 29%，其中 UI/導覽 (-58%)、後設資料 (-46%) 和廣告 (-43%) 的降幅特別陡峭。這些結果證實了上述品質-效率改善的機制：壓縮透過大幅提高每個單獨資訊片段的信噪比，提升了兩個維度的效能。

放大

圖 6 說明了單個查詢的這種變化。對於查詢「6 day old newborn milk intake per feeding」，我們展示了未壓縮的基準以及壓縮後的資訊片段。壓縮消除了非關鍵內容類別，僅保留與新生兒相關的餵食資訊。重要的是，壓縮成功消除了對該頁面來說通常可能切題，但對這個特定以新生兒為焦點的查詢來說卻離題的內容。

放大

結論

AI 系統依賴高信號資訊來智慧且有效率地服務使用者請求。必須盡可能精準地呈現此資訊，以最大化與每個請求的相關性。我們的全新查詢感知壓縮模型透過最大化每個資訊片段的切題憑證並積極剔除不相關的干擾項，確切地做到了這一點。

透過在我們的搜尋堆疊中部署這些新模型，我們能夠為依賴我們產品和 API 的人們提供更快、更好的回應。我們的方法創造了一個簡單的控制介面，允許我們的系統和 API 客戶調整壓縮程度，以在召回率、延遲和成本之間取得平衡。

上下文策劃是一個發展中的領域，要優化當今前沿智慧系統內使用的每個權杖的價值，還有很多工作要做。我們正積極致力於透過模型改善和系統架構，讓我們的上下文策劃技術變得更好，從而更廣泛地使用這些模型。

參考文獻

N. Chirkova, T. Formal, V. Nikoulina, and S. Clinchant. Provence: Efficient and Robust Context Pruning for Retrieval-Augmented Generation, 2025. Accepted to ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim, and D. Kim. LooComp: Leverage Leave-One-Out Strategy to Encoder-only Transformer for Efficient Query-Aware Context Compression, 2026. arXiv:2603.09222.

S. Eslami, M. Gaiduk, M. Krimmel, L. Milliken, B. Wang, and D. Bykov. Diffusion-Pretrained Dense and Contextual Embeddings, 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez, and G. Neubig. Learning to Filter Context for Retrieval-Augmented Generation, 2023. arXiv:2311.08377.

引文

@online{perplexity2026QueryAwareContextCompressionForBetterSnippets,
  author = {{Perplexity} and Bo Wang and Hao Zhang and Ismail Gadzhiev and Kirill Priemko and Markus Krimmel and Nandor Licker and Vitalii Polshkov and Sarah Eslami and Louis Milliken and Maksim Gaiduk and Nikita Kireev and Jerry Ma},
  title = {{Query-aware context compression for better snippets}},
  date = {2026-05-14},
  url = {https://perplexity.coolkeypoint.com/hub/blog/query-aware-context-compression-for-better-snippets}
}