先把任務分類，而不是先挑模型
多模型路由最常見的失敗，是一開始就把問題看成模型比較。工程上更穩的做法，是先把請求分成幾種任務類型：一般問答、企業知識檢索、資料整理、程式碼或 SQL 產生、長文件摘要、客服回覆、內部流程代理。不同任務對延遲、成本、正確性、上下文長度、工具調用與資料保護的要求不同，路由規則應該從這些條件開始。
例如 RAG 問答通常需要穩定遵守引用與禁止臆測的規則，模型的推理能力重要，但檢索品質、提示結構與回答格式也同樣重要。客服快速回覆可能更重視低延遲與語氣一致；財務或法務類內部助理則可能需要較保守的回答策略，寧可回覆資料不足，也不要產生看似合理但無根據的內容。這些差異無法只用單一排行榜決定。
我們通常會先定義每個任務的服務等級：哪些任務可以接受較慢但較穩的模型，哪些任務必須在短時間回覆，哪些任務可以用較便宜的模型處理，哪些任務一旦信心不足就必須要求使用者補充資訊或轉人工。這會讓後續的模型選型與 fallback 設計有清楚依據。
路由條件要明確，避免變成不可解釋的黑箱
實務上，多模型路由可以從規則式開始，再逐步加入評分或分類器。規則式不代表粗糙，反而比較容易除錯。常見條件包括輸入長度、語言、是否包含附件、是否命中特定知識庫、是否需要工具調用、是否涉及高風險領域、使用者角色、成本預算、目前供應商狀態與歷史錯誤率。這些條件最好記錄在 request metadata 中，讓每次模型選擇都能被追蹤。
不要把路由邏輯散落在多個 endpoint、prompt 或前端參數裡。建議集中在一個 routing layer，輸出包含 selected model、reason、timeout、fallback chain、safety policy 與 response contract。這樣當模型供應商調整 API、價格或速率限制時，工程團隊可以在單一位置更新策略，而不是到處搜尋硬編碼。
- 依任務路由：摘要、客服、RAG、分類、資料抽取等任務走不同模型或不同 prompt profile。
- 依風險路由：高風險內容使用較保守模型、較嚴格工具權限與較短的自動化鏈路。
- 依成本路由：大量低風險請求優先使用成本較低模型，必要時升級到較強模型。
- 依延遲路由：互動式介面優先選擇回應快的模型，背景批次任務可使用較慢但更完整的流程。
- 依可用性路由：當供應商異常、超時或速率限制時，自動切換到預先驗證過的替代模型。
Fallback 不是重試而已，而是降級設計
Fallback 的目標不是讓任何請求都硬產生一個答案，而是在可接受的品質範圍內維持服務。最基本的 fallback 是同模型重試，但這只適合暫時性網路錯誤或偶發 timeout。若失敗原因是上下文太長、工具調用錯誤、輸出格式不合約、內容安全限制或模型能力不足，單純重試通常只會浪費成本並增加延遲。
比較可靠的做法，是把 fallback chain 設計成有意義的降級。第一層可以調整參數或縮短輸入，第二層切換到同級替代模型，第三層改用較強模型或更保守 prompt，最後才是要求使用者補充資訊、回傳部分結果、建立待處理任務或轉人工。每一層都應該定義停止條件，避免同一請求在多個模型間循環。
Fallback 還要保留回應契約。若前端或 ERP 流程期待 JSON schema，替代模型也必須符合相同 schema；若系統需要引用來源，fallback 後仍然不能省略引用。很多事故不是模型沒有回答，而是 fallback 回答的格式或權限假設改變，導致下游流程錯誤。
觀測、評估與人工邊界要一起設計
多模型系統沒有觀測就很難維運。每次請求至少應記錄任務類型、路由原因、模型、token 使用量、延遲、錯誤類型、fallback 次數、檢索命中文件、輸出驗證結果與使用者回饋。這些資料不只是成本報表，也能協助判斷哪些任務應該重新設計 prompt、調整檢索、改路由或限制自動化。
評估也不能只看單次人工感覺。建議保留一組代表性測試集，包含常見問題、邊界問題、資料不足問題、惡意輸入、長上下文、繁體中文語境與企業內部術語。每次更換模型、調整 prompt 或新增 fallback，都用同一批測試檢查回答品質、格式、引用、工具調用與拒答行為。這會讓模型升級變成工程流程，而不是賭運氣。
最後，要明確定義人工介入邊界。當系統偵測到資料不足、輸出驗證失敗、高風險決策或多次 fallback 後仍不穩定，最好的回應可能不是再換一個模型，而是停止自動化並交給人處理。多模型路由的價值，在於讓企業 AI 系統可控地使用不同能力，而不是把所有不確定性藏在一個聊天框裡。若團隊需要把 AI 助理接進 LINE、ERP、CRM 或內部知識庫，這些路由與 fallback 規則應該在系統設計初期就被納入。