Prompting 知識養成 Day30

第30天：提示壓縮 (Prompt Compression)

想像一個日常用戶與 AI的對話場景，用戶一口氣輸入一大篇長文/資訊/對話...etc.加上需求，希望得到解答。

在這個標準流程中，我們也知道可能帶來的缺點是：
1.高成本：長文帶有大量 Token，將大幅度拉高 LLM 運行成本
2.延遲：LLM 處理長 Prompt 的時間相對冗長
3.失敗風險：一旦超出 LLM 的上下文視窗限制，極易導致任務失敗

為了避免這種情況，「提示壓縮 (Prompt Compression)」便應運而生。

▶︎「提示壓縮」 的運作概念

簡單地說，當用戶所提供的資料數據是大量的，不採取同步處理，也就是：不是「一次性同步」將資料數據＆目標任務給到 LLM，而是先處理消化大量資料數據，「壓縮」至 LLM 合適接收的量體，再將「合適量體」的資料數據，連同目標任務，給到 LLM。

透過「壓縮」提示，可有效避免 LLM 的「上下文視窗限制 (Context Window Limit)」，從而解決文章一開始提到的 3個缺點。而這個技術的重點就在於「壓縮」：要如何在縮減用戶資訊數據 (i.e.上下文/Prompt)的長度後，仍完整保有「關鍵」資訊。

▶︎「提示壓縮」 的工作流程

如上一段所提到，當應用程式接收到來自用戶一次性的「大量資料數據＋任務需求」時**，並不採取同步處理，而是將資訊與任務分開處理。_{(**註：這也是最常見的使用情境。)}
所以在工作流程上，就會是「分任務」，也是「分階段」進行。如下：

▫︎ 工作流程(by 任務)
應用程式會將任務拆解為兩個子任務。
子任務1「壓縮」：LLM 壓縮大量資料數據，生成「壓縮版本」的資料數據
子任務2「執行」：LLM 依據「壓縮版本」的資料數據，執行任務

▫︎ 工作流程(by 階段)
〈階段一：資料壓縮〉
針對用戶提供的大量資料數據，
Step.1－應用程式會將大量資料數據＋「壓縮 Prompt**」推送給 LLM，由 LLM 進行壓縮。^{(**註：壓縮Prompt模板的設計方法，下方會再說明。)}
Step.2－LLM 壓縮完成後，傳回「壓縮版本」的資料數據。
Step.3－應用程式將「壓縮版本」的資料數據儲存於資料庫中；而非儲存用戶提供的原始資料數據。
〈階段二：用戶回應〉
針對用戶提出的任務需求，
Step.1－應用程式不會提供用戶提供的原始資料數據，而是發送「壓縮版本」的資料數據＋「用戶提出的任務需求」Prompt給 LLM。
Step.2－LLM 直接依據「壓縮版本」的資料數據及任務需求，生成用戶所需的內容。 Step.3－應用程式將 LLM 的生成內容提供給用戶。

→→由於這個分階段的工作流程，是一個後端的內部流程，所以可以教育用戶，也可以不教育用戶；怎麼做都不影響用戶收到穩定性高的生成內容。

▶︎「提示壓縮」的Prompt 模板設計

文章開頭便已提到，這個技術操作的重點是，在縮減用戶資訊數據後仍完整保有「關鍵」資訊。所以「壓縮 Prompt」的設計就至關重要。

設計上必須注意壓縮的「比例」與「細節內容取捨」，比例過高或取捨不當可能損失關鍵上下文，導致任務表現下降。而壓縮比例過低或無法取捨，則無法節省 Token 成本，失去壓縮的目的。

▫︎ 壓縮 Prompt 模板設計主要有2種方式：
1.基於摘要的壓縮 (Summarization-based Compression)
概念說明： 要求 LLM 以「節錄摘要」方式壓縮，常用於冗長文本或對話歷史。
2.基於核心資訊提取的壓縮 (Information Extraction-based Compression)
概念說明： 要求 LLM 直接提取出最關鍵資訊，例如關鍵字詞、明確定義數據。這是比摘要更radical的做法。
(兩種方式對照請參考下表)

▫︎ 壓縮 Prompt 模板骨架(示意)
任務：壓縮輸入內容，保留對 X 任務有幫助的核心資訊  
限制：最長不超過 N Token  
格式：以條列列出關鍵要點  

壓縮方式對照簡表

→→還有1種方式，不需要設計 Prompt、透過 LLM 即可做到：「基於 Token-level 的壓縮 (Token Pruning)」。這只需在應用程式端，利用程式碼移除文本中冗餘、低價值的 Token，包含填充詞、停用詞(的/和/是)即可完成。
這種方式很俐落，好處是成本低、運行快速，適合用於資訊檢索或關鍵詞匹配類任務。但它並不適用於「依賴長上下文推理」的任務，因為在此類文本(及其任務)中的任何 Token的移除，都可能輕易破壞語境或關鍵推理。

❖ 小結

總的來說，提示壓縮是 Prompt Engineering 的一個前瞻應用。透過在應用程式層面，以「流程設計」解決技術限制，目的是讓 LLM 可以產出更好、更穩定的生成內容。在理解提示壓縮的實際效用後，我們也很容易能推想出，這個技術最適合的任務是：高度重複查詢，且上下文資料量大的任務。

提示壓縮的好處是：
▫︎ 成本低廉：節約了後續每一次問答的 Token 運行成本。
▫︎ 無延遲：利用「壓縮版」的資料數據，後續都能極快回應用戶問題。
▫︎ 穩定性高：避免超出上下文視窗限制，確保生成內容品質(任務達成)的穩定性。

不過也如「工作流程」那一段所提到的，由於這是在後端的內部流程，若在用戶不知情的情況下，可能也會帶給用戶「延遲感」(至少在「壓縮」階段)。所以是否一定能為用戶帶來更好的使用體驗(就等待時間而言)？尚不一定。可能還是會建議要教育用戶、與用戶溝通，才是較好的做法。