用業務評測選擇 Bedrock 模型

先建立比較方法，再選模型

準備有版本的評測集，包含普通請求、長文件、含糊問題和禁止請求，並定義預期結果與評分規則。候選模型應使用一致的提示詞、資料和輸出上限；否則“更便宜”可能只是少讀了上下文或少生成了答案。

記錄精確模型 ID 或推論設定、區域、API 和日期。把允許處理地區、影像輸入等硬約束與表達風格等偏好分開；先排除不符合硬約束的模型，再比較品質。

測量完整任務

指標	記錄內容	決策用途
品質	正確性、引用支援、合理拒答	任務是否可用
延遲	首 token 和完整回答時間，包含檢索	使用者能否完成流程
成本	輸入、輸出、快取類別及工具和檢索費用	每個合格結果的費用
穩定性	限流、超時、未完成回應	容量與回退設計

大模型可能不適合簡單任務，小模型也可能增加重試和人工修正。應比較合格結果的總成本，不能只比較 token 單價。

基線穩定後再引入路由

先形成可測量的預設設定。僅將通過評測的任務交給輕量模型，併為明確例外設計升級路徑。回退模型必須滿足同一資料邊界和輸出契約；若更換供應商會改變處理地區，就不能在故障時靜默切換。

最終輸出模型決策記錄：樣本版本、結果、排除理由、選用設定和變更觸發條件。模型、提示詞或檢索改變後重跑相關樣本，並儲存可回退設定。

官方資料

• API compatibility
• Model endpoint availability

文件核驗日期：2026 年 10 月 17 日。本文為參考指南，本次未執行真實雲端 API 呼叫。