查詢感知上下文壓縮以獲得更好的片段

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

這些原始上下文充滿雜訊。例如，網頁可能包含使用者請求所需的資訊，但也可能包含干擾項。這些干擾項可能會出現在主體內容以及導覽文字元素、無關的廣告、元資料等附屬元素中。將這些干擾項傳遞給下游代理程式會引發三個問題。

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

其次，它會導致延遲回歸。更長的上下文意味著下游模型需要處理更多的 Token，特別是當查詢需要來自許多候選頁面的證據時。雖然部分延遲成本發生在預填充階段，但更顯著的成本是在推理階段產生的，模型需要更多的推理 Token 來處理不相關的上下文。

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

放大

為了同時提升 Perplexity 各應用程式和 API 平台 的準確性、速度和成本效益，我們投入大量資源改善上下文精確度。其中一種方法是改進我們的片段生成演算法。我們將片段生成視為上下文壓縮問題。尋找特定資訊的模型不會從文件的廣義摘要或節錄中受益。相反，它們需要從來源資訊中以手術般精確的方式提取出的最小片段來回應使用者的請求。其他一切內容都可以且必須被移除。

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

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

在呼叫 LLM 之前移除不相關的上下文，以降低延遲和成本。

透過保持引用準確性並保持原始文字完整來確保可追溯性。

本月，我們在應用程式和 API 平台 中部署了一款全新的尖端片段產生器。該模組的核心是一個查詢感知上下文壓縮模型，它能針對每個查詢和候選結果，決定應保留哪些片段子集。本文介紹了我們構建和訓練該模型以在此關鍵任務中實現一流效能的方法。

作為查詢感知壓縮的片段

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

片段提取方法分為兩大類。第一類是基於選擇的方法：找到相關的視窗、區塊、句子或段落，並將其傳遞給下游。第二類是基於生成的方法：要求模型根據頁面撰寫以查詢為焦點的摘要。

我們對準確性、延遲和成本的關注使得設計選擇顯而易見。我們可以排除生成式方法，因為為每個頁面建立新摘要會損害這三個方面的效能。摘要對於我們關注的證據層來說並不適合。它可能會轉述原始來源，使得引用對齊變得更加困難。它還可能引入頁面中原本不存在的措辭，當片段被用作證據而非最終答案時，這具有風險。所涉及的延遲和成本使得生成式方法更加令人無法接受。

相反，我們將任務定義為查詢感知提取式壓縮：將檢索到的上下文中對我們有幫助的部分與干擾部分分開。具體來說，我們的模型必須接收查詢和候選結果，並決定保留哪些對查詢最有支援性的段落，以及捨棄其餘部分。模型輸出保留了原始文字，而不是進行重寫。這使得結果更容易引用、更容易驗證，並且傳遞給下游的成本更低。

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

放大

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

我們的方法遵循與先前上下文壓縮工作（如 FliCo、Provence 和 LooComp）相同的廣泛理念，並針對生產搜尋系統中的片段生成進行了調整。重要的是，該模型在我們原始檢索階段之後作為精確度階段發揮作用。正如我們之前的 Perplexity 研究文章 Introducing the Perplexity Search API 中所討論的那樣，我們構建的檢索系統能夠在子文件（或片段）層級原生運作，這已經使我們能夠很好地平衡精確度和召回率。引入查詢感知上下文壓縮模型將精確度-召回率的柏拉圖前沿進一步向外推移。

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

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

模型架構

我們使用 pplx-diffusion 模型作為主幹。這與 pplx-embed-v1 背後使用的模型系列相同，而且我們之前的學術工作 Diffusion-Pretrained Dense and Contextual Embeddings 以及我們的生產基準測試都證實，它是查詢-上下文對的強大雙向編碼器。該模型系列的一個關鍵屬性是雙向上下文：每個 Token 表示在模型決定保留什麼之前，都可以關注完整的查詢和完整的候選上下文。

在此主幹之上，我們訓練了一個輕量級壓縮頭，用於預測應該保留哪些上下文部分。由於不涉及生成，這些預測是在整個上下文中並行完成的。在服務時，片段引擎會在句子層級聚合這些預測，應用閾值，並將結果修剪至請求的 Token 預算內。

監督管線

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

我們的管線使用 LLM 作為評審設定。給定使用者查詢以及包含連結、標題和摘要的候選網頁，評審首先執行查詢理解，分析查詢並產生可能的使用者意圖清單。以這些意圖為錨點，評審接著處理候選上下文，並返回從文字中逐字複製的片段，並為每個片段提供分類，以便於檢查標籤。

然後，我們將返回的片段與原始文字進行比對。不出所料，大多數評審輸出都已經是精確的副本：簡單的字串比對恢復了 98% 的片段。加入簡單的正規表示式比對傳遞後，片段恢復率達到了 100%。這為我們提供了可靠、細緻的片段，可以轉換為 Token 層級的保留/捨棄監督。

我們使用一個包含人工標記片段的小型策展資料集評估了此監督管線，比較了較小的評審模型、不同的提示詞和不同的步驟配置。表現最好的設定是兩階段管線：先進行查詢理解，然後進行分類片段標記。我們還透過下游的可驗證評估（如 BrowseComp 和 SimpleQA）驗證了提取的片段集合，在這些評估中，僅使用保留的證據片段即可保持高分，同時顯著減少輸入 Token。

使用此管線，我們標記了 750k 個查詢-文件對，並使用所得片段透過二元交叉熵來訓練壓縮頭。此過程使我們的查詢感知壓縮模型能夠在保留原始文字完整的同時，移除不太可能幫助下游模型滿足使用者請求的上下文。

確保即時延遲

上下文壓縮位於下游模型之前，使其成為阻塞運算。此外，每次壓縮都依賴於查詢。因此，線上路徑必須在嚴格的延遲限制內為每個候選文件評分查詢-上下文對。一個緩慢的壓縮模型會適得其反，因為更高精確度帶來的延遲優勢會被壓縮本身的延遲所抵消。同時，一個智慧程度較低的壓縮模型會在決定切割和保留什麼內容時做出較差的決策。

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

圖 2 顯示了品質-效率前沿。當模型向左上方移動時表現更好：下游 Token 更少且保留了更多有用的證據。28 層模型提供了品質參考。11 層模型展示了過於激進壓縮模型的風險。剪枝後的 17 層模型代表了一個中間地帶：它在飽和狀態下與 28 層模型密切吻合，但在大多數生產流量運作的曲線陡峭部分出現了小幅差距。

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

放大

品質與 Token 效率

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

一種將每個結果集的 Token 預算限制為 1000 個 Token 的「低」上下文預設。

一種將每個結果集的 Token 預算限制為 4000 個 Token 的「中」上下文預設。

一種將每個結果集的 Token 預算限制為 10000 個 Token 的「高」上下文預設。

標準（無壓縮）設定和壓縮設定皆已設定為遵守這些 Token 預算。

代理式多步驟搜尋 (BrowseComp)

我們首先檢查壓縮對 BrowseComp 基準測試中代理式多步驟搜尋工作流程的影響。我們使用我們的開源 search_evals 工具進行此評估。評分在所有執行中都是一致的，使用 OpenAI 的標準 BrowseComp LLM 評審提示詞。

關注的兩個維度是基準準確性和 Token 使用量。重要的是，我們在查詢層級而非個別步驟層級測量 Token 使用量，以便測量整個請求生命週期中產生的實際 Token 負載。圖 3 顯示了「分數-Token」前沿，即準確性分數與 Token 使用量的對比。

放大

壓縮在各方面都帶來了新的柏拉圖前沿。對於每個設定，引入壓縮可將查詢層級的 Token 使用量減少 10% 到 70%，準確性提升幅度在 4 到 4.81 個百分點之間。引入壓縮甚至能讓我們的「低」預設值優於無壓縮的「高」預設值，同時將 Token 使用量減少了三倍以上。

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

SimpleQA：單步驟事實性

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

與之前一樣，我們使用標準評審提示詞繪製了準確性與每個任務平均總 Token 的關係圖。圖 4 顯示了此單步驟設定中的分數-Token 前沿。雖然單步驟設定中的效果幅度更為壓縮，但我們再次觀察到，壓縮同時改善了所有預設值的準確性和效率，從而引入了新的柏拉圖前沿。啟用壓縮後，中預設值實現了 95% 的準確性，且每個文件平均僅使用 200 個 Token。鑑於超過 10,000 個 Token 的平均文件長度，這代表在超過 50 的壓縮比下實現了前沿水準的效能。

放大

片段中最終保留了什麼？

第 4.1 節和第 4.2 節中的下游收益是端對端的。為了了解壓縮如何改變個別片段，我們進行了單獨評估，使用 LLM 評審將每個檢索到的片段中的每個 Token 分類為六個類別之一：

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

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

廣告：分散回答使用者查詢注意力的無關廣告。

元資料：關於文件內容的元資料。

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

重複：先前已包含資訊的重複。

我們的評估在驗證集中的 1,000 個混合領域查詢上執行，比較了生產堆疊與關閉壓縮的完全相同基準。如圖 5 所示，壓縮使每個片段的關鍵 Token 比例平均比無壓縮基準增加了 63%。我們觀察到不相關 Token 相對應地減少了 29%，其中 UI/導覽 (-58%)、元資料 (-46%) 和廣告 (-43%) 的降幅尤為顯著。這些結果證實了上述品質-效率改善的機制：壓縮透過大幅提高每個個別片段的訊雜比，改善了兩個維度的效能。

放大

圖 6 展示了單個查詢的這種變化。針對查詢「6 天大新生兒每次餵食的奶量」，我們展示了未壓縮的基準片段和壓縮後的片段。壓縮消除了非關鍵內容類別，並僅保留了與新生兒餵食相關的資訊。重要的是，壓縮成功地消除了那些對該頁面來說通常可能是相關的，但對於這個特定的新生兒焦點查詢來說卻是離題的內容。

放大

結論

AI 系統依賴高訊號資訊來智慧且高效地滿足使用者請求。這些資訊必須以盡可能精確的方式呈現，以最大限度地提高與每個請求的相關性。我們全新的查詢感知壓縮模型透過最大限度地提高每個片段的相關證據並主動剔除不相關的干擾項，精確地實現了這一點。

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

上下文策展是一個新興領域，要優化當今尖端智慧系統中使用的每個 Token 的價值，還有很多工作要做。我們正積極透過模型改進和系統架構，讓上下文策展技術變得更好，從而更廣泛地利用這些模型。

參考文獻

N. Chirkova, T. Formal, V. Nikoulina, and S. Clinchant. Provence: Efficient and Robust Context Pruning for Retrieval-Augmented Generation, 2025. 已被 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}
}