RAG 與推論工程
AWS 以小模型先壓縮 RAG 證據：輸入 token 減至一成，但請求延遲增加 12% 至 19%
新架構在檢索與主模型之間加入一次低成本模型呼叫，只保留與問題相關的原文片段及來源識別碼。AWS 的內部測試錄得約三成成本下降，但評分依賴單一企業語料與 LLM judge。
AWS 公開一種可插入 Amazon Bedrock RAG 管線的 query-aware compression 模式，核心不是縮短檢索結果數量，而是在高召回檢索之後加入小模型。Lambda 先把問題與全部 top-k chunks 送給 Claude Haiku，要求逐字抽取相關句段、保留 chunk ID、不得摘要或改寫；再把縮短後的證據交給 Claude Sonnet生成答案。兩次呼叫都使用 Bedrock Converse API，因此可替換成 Nova Micro／Nova Pro 等同系列組合，也能疊加 rerank、prompt caching 或 Intelligent Prompt Routing。
這種級聯只有在小模型讀取完整檢索內容的成本，低於主模型因此少讀 token 的節省額時才成立。若原始檢索量為 `R`、壓縮倍率為 `c`，主模型輸入由 `R` 降至 `R/c`，但系統會新增小模型的 `R` 個輸入 token 及約 `R/c` 個輸出 token。AWS 以超過 50 萬份、九類企業文件及 500 條問題測試：單用壓縮把送入主模型的 token 降至基線 12%，成本降至 67%，端到端延遲增加 19%；先 rerank 再壓縮則分別為 10%、64%及增加 12%。四項品質綜合分數約保留 97.5%，至少含一項無來源支持主張的答案比例由 51%降至 44%，加入 rerank 後為 38%。
實作時真正的風險是證據遺失，而非 API 接線。`temperature=0` 不能保證模型完整抽取，多跳問題、否定條件、表格與跨 chunk 引用尤其需要獨立驗證。團隊應固定相同檢索結果做 A/B 測試，同時計算完整度、引用準確率、忠實度、成本與 P95 延遲；窄問題、超過約五千 token 的上下文最可能受益，短上下文或次秒互動服務則可能被額外呼叫拖慢。