RAG 成本優化：從每次問答一塊錢降到一毛

成本歸因

cost = {
  'embed':    n_query_tokens / 1e6 * EMBED_PRICE,
  'rerank':   n_candidates * RERANK_PRICE_PER_DOC,
  'generate': (ctx_tokens * GEN_IN + out_tokens * GEN_OUT) / 1e6,
}
log.info('qa_cost', extra={**cost, 'total': sum(cost.values())})

六個實際有效的優化

1. 縮小上下文：k 從 8 降到 4，生成成本直接砍半。先用評測確認品質不掉。
2. 縮短片段：父片段從 1500 字降到 800 字，多數任務影響很小。
3. 壓縮系統提示：長系統提示每次都算錢，這是最容易被忽略的固定成本。
4. 開前綴快取：系統提示佔比高時效果顯著。
5. 減少重排候選：從 50 降到 20，重排成本降六成。
6. 分級生成：簡單問題用小模型，只有複雜問題升級。

嵌入成本的一次性優化

嵌入的大宗成本在建索引，是一次性的；但如果你頻繁重建索引（例如每天全量重跑），它就會變成持續成本。改成增量同步後，這一項通常能降到接近零。

用離線批次處理建索引

# 建索引不需要即時，用批次 API 單價通常較低
# 也避免大量嵌入請求擠壓線上服務的配額

優化順序建議

1. 先量測、歸因，找出佔比最高的一項。
2. 從不影響品質的優化開始：前綴快取、批次處理、去除重複呼叫。
3. 再做需要驗證的優化：降 k、縮片段、分級模型，每一項都跑評測。
4. 最後才考慮換更便宜的模型。

設定成本目標

訂一個「每次問答成本上限」並做成監控。超標時告警，而不是等月底看帳單。目標值可以從商業模式反推：若每位使用者每月付 300 元、平均問 200 次，那麼每次問答的成本上限就很清楚。