昨天把 AI 系統的 Latency 拆開之後，我終於比較清楚那幾秒到底花在哪裡，有些時間在 Retrieval，有些花在模型開始產生第一個 Token 之前，還有一部分來自外部 API，本來只看到一個「整體回應時間」，拆開之後才知道每一層其實都有自己的等待。

但今天實際多跑幾次時，碰到了一個更麻煩的情況，有些 Request 不是單純比較慢，而是真的卡住了。

平常可能兩三秒就回來的請求，偶爾會突然等十幾秒，甚至某個外部服務沒有正常回應時，整條流程就一直掛在那裡，使用者看到的畫面只剩下 Loading。

平均 Latency 看起來可能還是很漂亮，但只要真的遇到一次這種情況，使用體驗就會瞬間變差。

每一層不能無限等下去

以前做 Demo 的時候，我很少認真處理 Timeout，因為測試環境通常很單純，API 正常、網路正常、模型也正常，只要 Request 最後有回來就算完成。

真正把流程拆開後才發現，Production 裡面每一個外部依賴其實都可能卡住。

Retriever 可能查不到資料，第三方 API 可能沒有回應，LLM Provider 也可能暫時變慢，如果整個系統只是一路等下去，那前面做的 Latency Optimization 很快就失去意義。

所以今天先替不同步驟設定 Timeout，例如 Retrieval 超過一定時間就停止等待，外部 Tool 超時就回傳失敗狀態，LLM Request 也設定自己的上限。

重點不是所有步驟都設定同一個秒數，而是先決定「這一步最多值得等多久」。

Timeout 之後不能只顯示 Error

設定 Timeout 很簡單，真正麻煩的是超時之後要做什麼。

假設只是某個額外資訊查不到，但主要答案其實還能產生，那我可能會選擇繼續回覆，只是在結果中少掉那部分資訊；如果缺少的是回答一定需要的資料，就不能假裝什麼事情都沒發生，這時候可能要停止生成，或改走另一條流程。

模型本身超時也一樣，可以嘗試切換到另一個 Model，但這件事不能毫無限制地一直重試，不然原本一個五秒的 Request 最後可能變成三十秒，而且 Token Cost 還跟著一起增加。

昨天看的 Latency、前幾天做的 Model Routing 和 Cache，到這裡開始慢慢串在一起，因為系統到底要「繼續等、換模型、用快取結果，還是直接停止」，其實是在 Quality、Latency 和 Cost 之間做選擇。

Fallback 開始變得重要

我今天也試著替其中一條流程加上簡單的 Fallback。

原本的設定是先取得相關文件，再交給主要模型整理答案，如果主要模型超時，就換成速度比較快的模型，前提是 Retrieval 已經成功，而且這個問題不需要太複雜的推理。

這樣做之後並不能保證答案品質完全一樣，但至少不會讓使用者一直停在 Loading。

如果 Retrieval 本身就失敗，我反而不讓模型直接猜答案，因為這個系統原本就需要根據文件回答，資料都沒有拿到，再換一個模型也解決不了問題。

所以 Fallback 也開始需要條件，不能單純寫成「失敗就換下一個」。

Production 開始出現另一種問題

寫到這裡，我越來越能理解為什麼一個看起來很正常的 AI Demo，真的要搬到 Production 之後會冒出一堆以前沒想過的事情。

Prompt 寫得好、回答正確，解決的是其中一部分問題，當同一套系統開始被持續呼叫，就會遇到延遲、超時、外部服務失敗、模型暫時不可用，甚至不同錯誤同時出現。

今天做的事情其實不複雜，只是替流程設定 Timeout，再決定幾種情況下應該走哪個 Fallback，但整個 AI Application 已經開始比較像一個需要長時間運作的服務。

明天我想繼續處理這件事，如果同一個 Provider 連續失敗很多次，系統還一直把 Request 送過去其實很浪費，下一步就來看看怎麼避免一個已經出問題的服務，把整個 AI 系統一起拖慢。