[Day 21] RAG Cost 從 Token Usage 到 Production 成本分析

前幾天，我們已經把 RAG 系統逐步加入 Production 所需要的能力

到了今天，又會遇到一個很現實的問題：

這套 AI 助理如果真的有使用者，每回答一個問題，到底要花多少錢

因為 RAG 並不是只有一次 LLM API Call

其中可能涉及：

• Embedding API
• Reranking Model
• LLM Input Token
• LLM Output Token
• API Request 次數
• 失敗重試
• Context 長度
• 不同模型的價格

因此今天要建立：

RAG Cost：把每一次 Request 的使用量轉換成可以分析的成本資料

為什麼 RAG 需要 Cost Tracking

如果只有開發環境：

如果自己測試問幾個問題

API 可以正常回答

可能不太需要在意成本

但 Production 上線後：

這時候如果沒有 Cost Tracking，很容易發生：

系統越成功，成本也越高，但我們卻不知道錢花在哪裡

最重要的概念：Input Token 與 Output Token

RAG 的成本，很大一部份其實來自「送進 LLM 的 Context 有多長」

不只是影響 Retrieval Quality

它們也會影響成本

實際價格則應該依照目前使用的模型與官方定價設定

Production 不應該只把 Cost 放在 Trace 裡

我們還需要保存成結構化資料

從單次 Cost 進一步計算 Daily Cost

除了總成本之外，一個非常重要的 KPI 是：

Cost Per Request

如果系統有使用者資訊

這可以協助理解：

• 哪些使用情境最耗成本
• 哪些功能使用頻率最高
• 是否有異常大量 Request

不過這裡需要注意：

User-level Cost Tracking 必須考量個資與權限控管

不要為了成本分析，就把不必要的個人資料全部寫入 Log 或 Trace

Cost Per Feature

比 User 更實用的一種分析方式，是：

不同功能各花多少錢

這時候我們不只知道：

「AI 花了多少錢」

而是知道：

「哪一種功能正在消耗成本」

最值得分析的：Cost vs. Quality

因為最便宜的模型不一定能提供足夠好的答案

Cost Efficiency

因此可以建立一個概念

這不是單純追求最低成本

符合系統品質要求的成本區間

因此：

Retry 不只是影響 Latency，也可能增加 API Cost

從 Cost 回頭找 RAG 優化機會

今天最有價值的地方，其實不是「算錢」

而是：

透過 Cost Data 找出系統可以優化的地方

今天學到什麼

今天從 Day 20 的 Tracing 再往前一步，把：

「這次 Request 發生了什麼」

延伸成：

「這次 Request 花了多少成本」

也就是從：

「把 RAG 做出來」

逐漸走向：

「讓 RAG 可以被管理、監控、除錯、優化，而且知道成本」

但下一個問題是：

如果使用量突然增加，系統能不能撐住

因此下一篇將從 Production 的「單次 Request」進一步走向「大量使用者」：

Day 22：RAG Load Testing 從單次 Request 到大量流量壓力測試

開始測試這套 RAG 系統在真實流量增加時，效能、延遲、錯誤率與成本會發生什麼變化