搜尋意圖： 如果你在找「上下文壓縮 是什麼」或「上下文壓縮 和相近概念差在哪」，先看這頁的短定義、完整說明與延伸比較。
TL;DR： 將冗長的上下文內容壓縮為簡潔的摘要或關鍵信息，減少語言模型的輸入長度和計算成本。
實用情境： 適合用在閱讀 AI 文章、產品文件或和同事討論時，先用一頁快速對齊概念。
下一步： 先讀完定義，再往下看延伸比較與對應工具，把概念轉成實際應用。
將冗長的上下文內容壓縮為簡潔的摘要或關鍵信息，減少語言模型的輸入長度和計算成本。
核心概念
上下文壓縮（Context Compression）在現代 AI 應用中變得越來越重要。大型語言模型雖然有較大的上下文窗口（如 GPT-4 的 128K tokens），但並非無限的，而且更長的上下文導致更高的計算成本和更長的推理延遲。在檢索增強生成（RAG）場景中，系統可能檢索到大量相關文段，但將所有文段都傳給模型會造成計算浪費。在多輪對話中，完整的對話歷史快速增長，但早期對話對當前回應的影響逐漸減弱。上下文壓縮解決的就是這類問題。
上下文壓縮有多個維度。內容維度，即什麼內容應該被保留、什麼應該被刪除。時間維度，即是否應該將相似的多個信息合併。結構維度，即是否應該改變信息的表示形式以更高效地編碼。目標維度，即壓縮應該最大化對下游任務的支持，而不是單純的長度縮減。
運作原理
上下文壓縮的常見方法包括摘要提取、關鍵信息篩選和自適應選擇等多種策略。
摘要提取是最直接的方法。系統使用摘要模型（可以是抽取式或生成式）從原始文本中生成簡潔的摘要。抽取式摘要選擇原文中的重要句子組成摘要，保留原汁原味的表述；生成式摘要由模型生成新的文字，可能更簡潔但需要確保準確性。對於多個相關文段，可以生成統一摘要而非逐個摘要，進一步減少冗餘。
關鍵信息篩選根據任務特定的重要性進行選擇。例如，在問答任務中，系統可以識別出與問題最相關的文段部分，刪除無關內容。這可以通過相似度計算（查詢與文段的相似度）或訓練一個分類器（識別哪些句子對任務重要）實現。
自適應選擇根據已有的上下文長度和計算預算，動態決定保留多少內容。系統可能設置一個總的 token 預算，在滿足預算的前提下選擇最重要的信息。這涉及為不同的信息片段分配重要性分數，然後按重要性排序選擇。
時間感知壓縮在對話場景中特別有用。系統可以根據對話的遠近遠近，對信息進行衰減或聚合。非常久遠的對話細節可能可以聚合成「討論過 X 話題，結論是 Y」，而最近的對話保留完整細節。
層次化壓縮適用於嵌套結構的信息。例如，一篇文章由多個章節組成，每個章節由多個段落組成。系統可以首先對每個章節進行摘要，再對章節摘要進行摘要，形成分層概要。當需要詳細信息時，可以逐層展開。
實際應用
在 RAG 系統中，上下文壓縮用於在檢索大量文段後進行過濾和總結。系統可能檢索 10 個相關文段，但不是全部傳給模型，而是進行去重、相似信息合併、關鍵信息提取，最終只傳給模型 3-5 個關鍵文段的摘要，大幅降低成本。
在客服系統中，上下文壓縮幫助系統管理長對話。客戶和客服可能進行了 20 輪對話，系統不需要完整保存所有歷史，而是提取關鍵信息（如「客戶問題是訂單退貨」「已解決」），基於關鍵信息和最近幾輪對話生成回應。
在多文檔摘要任務中，系統需要從多個長文檔生成統一摘要。上下文壓縮技術幫助系統先分別摘要每個文檔，再進行跨文檔的信息融合和進一步壓縮。
在代碼審查輔助系統中，當 diff 很大時，系統可以壓縮為變更摘要（「修改了 10 個函數，其中 3 個涉及 API 變更」），避免將全部代碼送給模型進行分析。
在會議記錄總結中，系統可以將 2 小時的會議記錄（數千個 tokens）壓縮為 5 分鐘的摘要（數百個 tokens），抓住決策點和行動項。
在電子郵件摘要中，系統可以壓縮長郵件鏈（多個往返回覆）為核心信息和未解決的問題。
常見誤區
誤區一：認為壓縮比越高越好。過度壓縮會丟失重要信息，導致模型無法正確理解上下文。應該在壓縮率和信息保留之間找平衡，通常 50-70% 的壓縮率是合理的。
誤區二：認為所有上下文具有相同的重要性。實際上，不同信息對不同任務的重要性不同。應該根據具體任務特性進行選擇性壓縮。
誤區三：認為一個通用的壓縮策略適用所有場景。不同的應用（問答、對話、摘要）需要不同的壓縮策略。在對話中，最近的交互很重要；在文檔QA中，最相關的片段很重要。
誤區四：忽視壓縮過程本身的成本。生成摘要或進行複雜的篩選也需要計算。在某些情況下，壓縮的成本可能超過節省的成本，需要進行成本效益分析。
與相關技術的比較
上下文壓縮與摘要：摘要是生成簡潔版本的技術，是上下文壓縮的一個主要方法。但上下文壓縮還包含其他策略如關鍵詞提取、去重、選擇性保留，不限於摘要。
上下文壓縮與 Token 優化：Token 優化是更廣泛的概念，包括上下文壓縮、提示優化、向量化等多種技術。上下文壓縮專注於減少上下文的 token 數，是 Token 優化的一個方面。
上下文壓縮與檢索過濾：在 RAG 系統中，檢索過濾決定傳給模型哪些文段，上下文壓縮決定如何表示這些文段。兩者可以結合，先通過過濾選擇最相關的文段，再對這些文段進行壓縮。
上下文壓縮與知識蒸餾：知識蒸餾是通過小模型學習大模型的知識，是一種遠程的信息壓縮。上下文壓縮是直接壓縮輸入信息。兩者目標相關但方法和應用場景不同。
常見問題
如何決定應該壓縮多少上下文？
這取決於多個因素：模型的 token 成本（某些模型輸出 token 成本是輸入的倍數，例如 Claude 3 的輸出成本是輸入的 3 倍），應用的延遲要求，以及保留關鍵信息的必要性。一般的策略是設定一個 token 預算（例如 2000 tokens），在此預算內最大化信息保留。通過離線評估（對壓縮後的上下文進行下游任務評測）可以找到最優平衡點。
對話歷史中應該保留多少輪對話？
這取決於對話的性質和任務。對於簡單的對話助手，保留最近 5-10 輪（通常 500-2000 tokens）足夠；對於複雜推理任務，可能需要更多背景。實用方法是使用滑動窗口（保留最近 N 輪）或基於重要性的選擇（提取關鍵信息片段）。系統應該對用戶提供控制選項，讓他們能選擇使用多少歷史信息，因為有時候用戶可能希望開始新的對話分支而非繼承完整歷史。
壓縮是否會影響模型的性能？
適度壓縮通常不會顯著影響性能，因為模型往往關注最相關的信息。但過度壓縮會導致性能下降，例如遺漏支持證據、破壞邏輯推理鏈等。建議通過 A/B 測試評估壓縮的影響：測試不同的壓縮率，度量最終任務的性能（準確率、用戶滿意度等）。通常 50-70% 的壓縮率在大多數任務上不會導致明顯性能下降，但應根據具體應用進行調整。