亞馬遜 Bedrock 推出查詢感知壓縮技術 降低 RAG 令牌成本
在大規模 Retrieval Augmented Generation（檢索增強生成，簡稱 RAG） 工作負載中，傳入基礎模型（Foundation Model, FM）的 輸入令牌（input tokens） 往往佔了主要成本。亞馬遜 Bedrock 近期公布的 查詢感知壓縮（query‑aware compression） 機制，提供了一條在不犧牲答案品質的前提下，顯著減少輸入令牌數量的解決方案。
背景與技術概念
傳統 RAG 流程會在檢索階段以高召回率（high recall）返回大量可能相關的文本片段（chunks），常見的設定是 top‑k 5–20 個片段，每個片段大小不一，導致每次查詢的輸入令牌數可達數千。雖然此設計確保模型在推論時擁有充分的來源資訊，但隨著工作負載規模擴大，令牌成本也隨之飆升。
Bedrock 的新模式在 檢索完成後、最終生成答案前，插入一個 低成本小模型（本文以 Claude Haiku 為例）來過濾檢索結果。小模型同時讀取使用者查詢與檢索回傳的片段，僅輸出與問題直接相關的文字區段（verbatim spans），其餘無關內容被剔除。經過此一步，主要的大模型只需處理被精簡過的上下文，從而降低令牌數量、減少計算資源消耗，並同時縮小 幻覺（hallucination） 的產生範圍。
實作要點與成本效益
- 架構：Bedrock 以開放且可組合的方式支援自訂的後檢索處理。開發者可將過濾邏輯封裝於 AWS Lambda 函式中，與 Bedrock 服務串接。
- 成本模型：因小模型的計算單價遠低於大型基礎模型，僅用於過濾的令牌費用相對微不足道。若原本每次查詢需要 3,000 令牌，經過查詢感知壓縮後可降至約 800–1,200 令牌，依照 AWS 的計費方式，月度支出可減少 30% 以上。
- 延遲權衡：加入過濾步驟會產生額外的 Lambda 呼叫延遲，通常在 50–150 ms 之間。對於即時性要求不高的企業應用，此延遲可接受；若需極低延遲，仍可依需求調整模型規模或並行度。
- 品質驗證：測試顯示，過濾後的上下文仍能維持與未過濾時相近的答案正確率，且因噪聲減少，模型產生錯誤資訊的機率下降。
此外，此模式可與 Bedrock 已有功能如 Prompt Caching（提示快取）、Intelligent Prompt Routing（智慧提示路由） 以及 Rerank API（重新排序介面） 串聯，形成多層次的成本節省。
影響與未來展望
查詢感知壓縮為使用 Bedrock 建置 RAG 應用的開發者提供了 成本‑效能平衡 的新選項，特別適用於技術文件、法律條文等需要大量檢索的領域。未來，隨著更精細的語意過濾模型與自動化管線成熟，預期可進一步降低延遲，同時提升答案的可信度。對於企業而言，這意味著在保持資訊完整性的前提下，能以更低的雲端開支推動 AI 驅動的知識服務。
讀者啟示：若您正規劃或已部署 RAG 解決方案，建議先行評估「檢索後過濾」的可行性，透過簡易的 Lambda 實作測試令牌減量與品質變化，從而在成本與效能之間找到最適合自家業務的配置。