優化大型語言模型效能：使用 Adola 將輸入 Token 減少 70%

隨著大型語言模型（LLM）被整合到生產環境中，與龐大上下文窗口相關的成本與延遲正逐漸成為關鍵瓶頸。當開發者實作檢索增強生成（RAG）或複雜的代理工作流程時，常會遇到「噪聲」上下文——冗餘資訊、無關片段或過長的工具紀錄——這會在不提升最終答案價值的情況下增加 Token 消耗。

Adola 推出 Rose 1，一個語意提示壓縮引擎，旨在於模型呼叫前裁剪這些噪聲。透過「保留重要內容」的概念，Rose 1 目標將輸入 Token 減少至最高 70%，同時確保模型的核心推理與事實準確性不受影響。

語意壓縮運作原理

不同於簡單截斷（可能會切掉提示結尾的重要資訊），Adola 採用語意壓縮。此過程會辨識並移除冗餘或無關的資料，同時保留回答特定問題所需的關鍵文字片段。

例如，在技術支援情境中，提示可能包含支援討論串的重複筆記或無關的工單歷史。Rose 1 會過濾掉這些內容，只保留關鍵的結構、政策例外、帳號等級與引用路徑，以讓模型提供安全且精確的回應。

效能與基準測試

提示壓縮的主要挑戰之一是「讓模型失明」的風險——移除過多資訊導致準確度下降。Adola 已針對六個主要評估集合發布 Rose 1 的生產基準，顯示即使在 70% 壓縮率（僅保留原始提示的 30%）下仍具高度穩定性。

基準結果

評估集合 專注領域 準確度影響
AIME 競賽數學 下降 0%
GPQA Diamond 專家科學問答 下降 0%
GDPval-AA 專業任務 下降 0%
CommonsenseQA 常識推理 下降 0%
GSM8K 小學數學 下降 0%
ARC-Challenge 小學科學 下降 2%

這些結果顯示，對於絕大多數高難度推理任務，語意噪聲可以被剔除，而不會影響模型得出正確結論的能力。

生產使用案例

Adola 定位為「模型前置 API」或提示閘道，意味著它可嵌入現有工作流程，而無需更換模型供應商。主要應用領域包括：

1. 代理追蹤

在多步驟的代理工作流程中，工具紀錄可能變得極為冗長。Adola 可在下一個規劃步驟前裁剪這些紀錄，降低對話後續回合的成本。

2. RAG 檢索

檢索系統常會過度擷取片段以確保答案存在。Rose 1 會縮減這些過度擷取的片段，同時保留含答案的部分，優化上下文窗口。

3. 支援副駕

對於客服機器人而言，壓縮工單歷史、政策文件與帳號上下文，使模型能處理更多的歷史與文件，而不會觸及 Token 限制或增加延遲。

實作

此工具為開發者設計，提供 Python、JavaScript、TypeScript、Go 與 Rust 的 SDK。典型的實作方式是將原始上下文與使用者查詢送至 Adola API，並指定目標壓縮比例。

from adola import Adola

client = Adola(api_key="rose_...")
result = client.compress(
    input=open("retrieved_context.txt").read(),
    query="Which incident caused latency?",
    compression={"target_ratio": 0.3},
    include_spans=False,
)

compressed = result["output"]

社群觀點

雖然最初的回應凸顯了成本節省的潛力，但部分使用者對壓縮策略的彈性提出疑問。某位使用者指出：

「我可以根據優化目標選擇不同的 Token 減少策略嗎？例如，我可以接受品質下降，以換取巨大的成本節省。」

這顯示出對於準確度與激進成本降低之間的權衡，需要更細緻的控制功能，讓開發者能根據任務的具體重要性調整壓縮程度。

Sources