上下文壓縮：讓 10 萬 Tokens 塞進 1 萬

Back
Category : News

Multigrid

壓縮是唯一需要花錢應用的上下文技術，因此也是最需要用算術來合理化的技術。通常有兩種更便宜的方法勝過它，而知道何時它們不適用才是真正的技巧。



先談免費的勝利

在任何基於模型的技術之前，先移除那些不帶資訊的 tokens。這看起來不華麗、是無損的，而且在真實提示詞上通常能省下 30–60%：

  • 去除標記。 提示詞中抓取的 HTML 大多是屬性、導航和腳本標籤。請提取純文字。
  • 壓縮結構化資料。 美化過的 JSON 會為每個空格付費。對於表格資料，CSV 或每欄一個緊湊鍵值的形式，遠比在每一列重複鍵值的物件陣列便宜得多。
  • 去除重複。 使用重疊區塊的檢索會傳回幾乎相同的段落。進行雜湊並丟棄。
  • 丟棄無法被讀取的內容。 Base64 資料塊、長 ID、雜湊、壓縮過的 bundle。它們無法被 tokenizer 進一步壓縮，對模型也沒有用處。
  • 修剪工具描述。 JSON Schema 描述中的每個字都會在迴圈的每次呼叫中被計費。



四種需要成本的類型

類型 描述
抽取式選取 為句子或段落根據與查詢的相關性進行評分，並保留最相關的。交叉編碼器 reranker 是標準工具。成本低，而且輸出是逐字的原始文字，這在答案必須可被引用時非常重要。
抽象式摘要 要求模型將上下文改寫得更短。壓縮率最高，風險也最高：摘要會遺漏具體數字、限定詞和否定詞，而這些常常是最終答案的關鍵。
token 剪枝 使用小型語言模型的 perplexity 作為訊號，刪除個別低資訊量的 token。這方面的已發表研究來自微軟研究院的 LLMLingua 和 LongLLMLingua（Jiang et al., EMNLP 2023 及其後續），在他們的評估任務上報告了高達約 20 倍的壓縮率，且性能損失有限。輸出不是人類可讀的，這對模型來說沒問題，但對記錄來說很麻煩。
改用檢索 根本不是壓縮 — 不要把它放進提示詞。幾乎總是最便宜的選項，也是考慮其他方法前要先排除的。



壓縮必須能回收成本

每種基於模型的技術都會花費 tokens 來節省 tokens。以下是算術，以您應該替換的示意費率為例： 

original context T  = 20,000 tok      target model input   $3.00 / M
compressed T'       =  4,000 tok      compressor in/out    $0.15 / $0.60 per M

saving per use    (20,000 - 4,000) / 1e6 * $3.00       = $0.0480
compression cost  20,000/1e6*$0.15 + 4,000/1e6*$0.60   = $0.0054

net per use, if the compressed artefact is reused      = +$0.0426
net on a single use (compress then immediately send)   = +$0.0426 as well

BUT compare against caching the same 20,000 tokens:
  cache read at a 0.1x multiplier: 20,000/1e6 * $0.30  = $0.0060
  compressed prompt, uncompressed rate: 4,000/1e6*$3   = $0.0120

Enter fullscreen mode

Exit fullscreen mode

仔細閱讀最後兩行，因為它們才是真正重要的發現。當上下文是穩定的時，快取既比壓縮便宜，又是無損的 — 沒有理由去壓縮靜態的系統提示詞。壓縮只有在每次請求的上下文都不同、其大小大到無法經濟地快取，或是必須跨沒有共享快取的模型重複使用時，才有其價值。

因此完整的決策順序是：刪除無用的內容、改用檢索而非塞入、快取穩定的部分，然後壓縮剩下的。大多數團隊卻第一個就去抓第四個。

延遲值得在算術中單獨列一行，因為壓縮只是把成本移來移去，而非單純降低。一個壓縮呼叫是一次額外的網路來回和一次額外的生成，都在關鍵路徑上，而且壓縮器必須先讀完整個上下文才能開始輸出。對於互動功能，這很容易增加比縮短提示詞所節省的更多實際時間。因此壓縮最有道理的地方是它可以離線進行 — 在攝取時或按照排程進行 — 而在人類正在等待的請求中間進行是最沒有道理的。



每種方法會破壞什麼

壓縮本質上是有損的；問題在於你能容忍哪種損失。抽取式選取會失去段落之間的連接組織，因此會損害需要跨段落進行綜合的任務。抽象式摘要會失去精確性 — 精確數字、日期、名稱，以及眾所周知的否定詞，因為「該條款不適用於子公司」和「該條款適用於子公司」在嵌入空間中幾乎會被摘要成相鄰的向量。Token 剪枝會失去語法結構，這通常能被模型恢復，但偶爾不行，而且會讓你的提示詞對半夜兩點正在除錯的人類來說無法閱讀。

有一種損失是所有方法都共有的，值得明白指出：壓縮之後你就無法再引用原始來源。如果你的產品會顯示引用，壓縮後的文字必須保留指向原始段落的識別符，否則引用功能會悄悄開始捏造內容。

在長期執行的對話中還有一種複合效應需要注意。壓縮一個已經包含先前壓縮摘要的上下文，就會變成摘要的摘要，而損失不是加成而是相乘 — 具體細節最先消失，然後是限定詞，最後是已確認事實與假設之間的區別。在每個層級都保留指向未壓縮原始內容的指標，並盡可能從原始來源重新壓縮，而不是從先前的壓縮結果壓縮。



防止最壞結果的規則

  • 絕對不要壓縮指令。 系統提示詞和使用者的問題要原封不動。它們很小，而且是規格說明。
  • 絕對不要壓縮結構化數值。 識別符、金額、日期、數量。將它們提取成一個小的逐字區塊，只壓縮它們周圍的散文。
  • 壓縮一次，快取結果。 如果同一份原始文件被重複使用，壓縮後的形式就是一個穩定的成品 — 應該儲存它，而不是每次請求都重新產生。
  • 衡量端到端的結果，而非壓縮率。 以三個答案準確度點為代價換來的 10 倍壓縮率，在幾乎任何價格下都是糟糕的交易，而除非評估是在最終答案上執行，否則你不會看到這一點。
  • 保留未壓縮的路徑。 當答案錯誤時，第一個診斷方法是用完整上下文重新執行。如果這樣就修好了，壓縮就是你的 bug；如果沒有，那它從來就不是問題。

上述損益平衡取決於壓縮器與目標模型之間的價格差距，這是兩個模型的比較而非單一查詢；把小型和大型模型的費率並排比較就足以判斷一個壓縮步驟在你開始建置前是否能回收成本。



相關文章

https://dev.to/multigrid/context-compression-making-100k-tokens-fit-in-10k-4aam

https://www.worldprogramming.org/posts/context-compression-making-100k-tokens-fit-in-10k-flby9g

Post Views: 464