[Day 22] RAG 從單次 Request 到大量流量壓力測試

現在我們知道 AI 助理：

• 回答品質如何
• Request 哪裡變慢
• 發生錯誤時在哪個階段
• 一次 Request 花多少 Token
• 一次 Request 大約多少成本

但 Production 還有一個很重要的問題：

如果今天不是只有一個人使用，而是同時有多人使用並對系統發出 Request，系統還撐得住嗎

這就是今天要處理的問題：

從單次 Request，進一步測試大量流量下的 RAG 系統

但單次測試只能證明「系統可以運作」，不能證明「系統可以承受流量」

模擬大量使用者同時對系統發送 Request，觀察系統的行為

Throughput 是什麼

Throughput 可以理解成：

系統單位時間可以處理多少 Request

所以當流量增加時，Throughput 是否還能持續提升

因為任何一個環節都成為瓶頸，也可能拖慢整個系統

如何判斷系統是否「撐得住」

實際 Production 應該依照：

• 業務需求
• 使用者體驗
• API SLA
• 模型特性
• 硬體資源
• 預期流量

確認系統是否符合事先定義的服務要求

今天學到什麼

今天從「單次 Request」進一步走向「大量流量」

最重要的概念有模擬預期流量，確認系統是否可以正常運作、持續增加負載並找出系統極限

這時候我們測試的已經不只是：

「RAG 能不能回答問題」

而是開始回答：

「RAG 在大量使用者進來時，能不能穩定、快速、可控成本地提供服務」

但當系統開始面對大量 Request 時，還有一個問題：

每一次 Request 都真的需要重新做一遍所有工作嗎

不但增加 Latency，也會增加 Token 與 API Cost

因此下一篇將開始進入另一個重要的 Production 優化方向：

Day 23：RAG 用 Cache 降低 Latency、Token 與 API 成本

讓我們開始思考：

哪些結果可以重複利用，而不是每一次 Request 都重新計算