今天介紹 LiteLLM 時，我們提到一個很好用的功能：
主要模型失敗，可以切到備援模型。
這叫做 Fallback。
但真正開始設定時，最容易犯的錯就是：
只寫一條規則。
模型 A 出錯，就換模型 B。
看起來很有備援。
實際上卻把完全不同的錯誤混在一起。
因為：
伺服器暫時過載，是一種錯。
文件太長，是另一種錯。
資料根本不完整，又是另一種錯。
今天只學一個動作：
設定 Fallback 前，先把錯誤分成「可切換、不可切換、轉人工」三類。
第一類：可切換
這一類通常是：
工作本身沒有問題，只是目前這個模型或 Provider 暫時無法完成。
例如：
- Rate Limit。
- 暫時服務錯誤。
- 某個模型部署無法連線。
- Timeout。
假設客服工作已經確認：
模型 A 和模型 B 都能完成。
而且兩個模型都通過同一組真實案例測試。
這時：
模型 A 暫時過載。
切模型 B。
就很合理。
這才是最典型的：
可自動切換。
LiteLLM 本身就支援這種 Fallback
LiteLLM 的 Router 可以先 Retry。
如果主要模型經過設定的重試後仍然失敗，再依照事先安排的 Fallback 順序切到其他模型群組。
所以系統可以是：
主要模型。
失敗。
先重試。
還是不行。
再切備援模型。
這是工具幫你處理的技術部分。
但真正重要的商業規則仍然是：
什麼錯誤才有資格進入這條備援路線？
第二類：不可切換
有些問題不是模型 A 壞掉。
而是：
這個工作本身現在就沒有足夠條件完成。
例如：
- 客戶沒有提供訂單編號。
- 重要文件缺了一頁。
- 價格資料有兩個互相矛盾的版本。
- 需要使用圖片，但備援模型不支援圖片。
- 需要特定 Tool Calling，但備援模型沒有通過測試。
這時如果只是把問題換給另一個模型：
缺少的資料還是缺少。
矛盾還是矛盾。
能力缺口也沒有消失。
所以這一類應標成：
不可自動切換。
例如：資料不足不是 Provider 故障
假設客戶問：
「幫我確認這筆退款。」
但系統裡根本沒有訂單編號。
模型 A 回答：
無法確認。
這時如果 Gateway 自動切到模型 B。
模型 B 還是沒有訂單編號。
如果它反而猜了一個答案，事情只會更糟。
所以：
資料不足時，正確下一步不是換模型，而是補資料。
Context 太長則是另一種情況
LiteLLM 本身可以針對 Context Window 過長設定專門的 Fallback。
例如主要模型無法容納這份長文件。
可以切到一個已經確認具有更大 Context Window，而且能完成同樣工作的模型。
這和「資料本身缺少」完全不同。
前者是：
資料有，只是模型裝不下。
後者是：
資料根本不存在。
所以不要都叫做：
模型失敗。
第三類：直接轉人工
還有一些工作，就算第二個模型也能做：
仍然不代表應該讓它自動接手。
例如：
- 正式退款。
- 付款。
- 修改合約條件。
- 正式報價。
- 對客戶做重要承諾。
- 刪除重要資料。
假設主要 AI 執行到這裡失敗。
最安全的備援不一定是：
模型 B。
而可能是：
停下來，交給人。
為什麼人工也算一種 Fallback？
因為備援的真正目的不是：
確保 AI 永遠一定要完成。
而是：
主要路徑出問題後，工作仍然有一條正確的下一步。
這條下一步可能是：
- 另一個模型。
- 另一個部署。
- 要求補資料。
- 停止。
- 人工處理。
只要能安全把工作接下去，它就是備援設計的一部分。
最簡單的三格表
設定 LiteLLM 前，可以先不要碰程式。
先拿出你現在真正的 AI 工作。
畫三格。
第一格：可自動切換。
- Provider 暫時故障。
- Rate Limit。
- Timeout。
- 已驗證的部署不可用。
第二格：不可自動切換。
- 資料不足。
- 輸入格式不符。
- 備援模型缺少必要能力。
- 結果本身互相矛盾。
第三格：直接轉人工。
- 正式付款。
- 退款核准。
- 不可逆修改。
- 重要對外承諾。
先完成這一張表。
再設定 Fallback。
不要把「內容被拒絕」自動理解成模型壞了
LiteLLM 也提供 Content Policy Fallback。
也就是某一個 Provider 因內容政策拒絕後，可以設定另一個模型作為備援。
技術上可以做到。
但企業使用時要特別小心。
因為模型拒絕的原因可能是：
- 不同 Provider 的內容政策不同。
- 你的工作碰到敏感內容。
- 原本流程本來就應該人工確認。
如果規則只是：
「誰拒絕，就一直換到有人肯回答。」
這其實不是備援。
而是在繞過原本應該檢查的邊界。
所以 Content Policy Error 要不要切換，應該另外制定規則。
例如一般客服和高風險客服要分開
一般客服：
「營業時間是幾點？」
模型 A 因暫時服務故障無法回答。
可以切模型 B。
高風險客服：
「幫我直接把這筆退款退掉。」
模型 A 無法完成。
這時不要因為 B 能操作工具，就自動切過去。
正確下一步可能是：
人工核准。
另一個常見錯誤：模型 B 有回答，就算備援成功
不是。
Fallback 成功至少有兩層。
第一層：技術成功。
模型 B 收到 Request，也正常產生 Response。
第二層：工作成功。
模型 B 的結果符合原本工作需要。
例如：
- 答案正確。
- 格式正確。
- 工具正確。
- 重要資料沒有遺漏。
第一層成功，不代表第二層成功。
所以正式設定前，要先測備援模型
最簡單的方法就是沿用我們之前做過的測試。
從真實工作挑一組代表案例。
讓主要模型和備援模型使用：
- 同樣資料。
- 同樣 Prompt。
- 同樣輸出要求。
比較：
- 正確率。
- 人工修改時間。
- 工具呼叫。
- 輸出格式。
- 成本。
通過之後，才進入：
可自動切換名單。
最重要的是測「真正故障時會不會切」
設定檔寫好還不算完成。
LiteLLM 官方現在建議，Proxy 的 Fallback 驗證應該在非正式環境裡，真的讓主要部署不可用，再送正常請求測試。
也就是不要只看：
設定看起來正確。
而是實際確認：
- 主要路徑真的失敗。
- Retry 有照規則發生。
- Fallback 有切到正確模型。
- 最後結果仍然符合要求。
測試時不要只測「模型掛掉」
至少可以準備四種情境。
情境一：Provider 暫時故障。
預期：
自動切換。
情境二：輸入太長。
預期：
只有已設定的大 Context 模型可以接手。
情境三：資料不足。
預期：
不要切模型，要求補資料。
情境四：正式付款。
預期：
不再嘗試其他模型，直接停在人類確認點。
這樣才是在測：
工作流程。
不是只測 API。
可以直接使用的 Fallback 分類 Prompt
你是我的 AI 備援流程設計助手。 我要建立 LiteLLM Fallback。 目前 AI 工作是： [描述工作] 主要模型： [模型] 候選備援模型： [模型] 請先不要產生 LiteLLM 設定檔。 先把可能失敗情況分成三類。 第一類：可以自動切換 只有在： 工作資料本身完整， 備援模型已通過相同工作測試， 而且問題主要來自 Provider、Rate Limit、Timeout 或暫時服務錯誤時， 才放進這一類。 第二類：不可自動切換 包含： 資料不足、 資料互相矛盾、 輸入格式錯誤、 備援模型缺少必要能力、 工作條件本身無法完成。 請寫清楚下一步應該補什麼，而不是換模型。 第三類：直接轉人工 包含任何： 付款、 退款核准、 正式報價、 合約修改、 刪除重要資料、 重要對外承諾、 其他不可逆或高風險操作。 最後替我產生一張清單： 錯誤情境。 分類。 是否 Retry。 是否 Fallback。 Fallback 到哪個已驗證模型。 是否必須人工確認。 如果某個錯誤無法判斷，標成「先停止」，不要預設系統一定要給出結果。
如果現在還沒有 LiteLLM，也可以先做這一步
今天這個方法並不一定要等工程師裝完 LiteLLM。
只要公司已經同時使用兩個 AI，就可以先問：
主要工具不能用時，我現在怎麼辦？
例如：
寫文章：
ChatGPT 暫時不能用，可以改 Claude。
公司正式付款：
原本流程出錯，不要換另一個 AI 自己決定。
資料缺少：
不是換 Gemini。
而是先找到缺的資料。
這就是同一個觀念。
今天最容易犯的錯
很多人以為備援就是：
A 不行。
換 B。
B 不行。
換 C。
直到有一個 AI 願意回答。
真正成熟的備援不是這樣。
因為有些錯誤：
換模型能解決。
有些錯誤：
所有模型都不該解決。
所以 Fallback 設定真正第一步不是：
選第二個模型。
而是：
先決定哪些失敗有資格換模型。
今天只需要記住一句話
LiteLLM 可以替你自動切換模型。
但它不能替你的公司決定：
這一次到底該不該切。
所以設定備援以前，先分清楚：
暫時故障，可以換。
資料或能力有問題，不要換。
高風險操作，直接交回人。
這三條線畫清楚之後，Fallback 才是在提高可靠性。
否則只是讓錯誤更有機會繼續往下跑。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
