實作指南 / 9 分鐘
把模型選擇留在系統邊緣
依測試過的能力 routing，不把流行名稱寫死。
OpenAI model catalog 會持續改變。產品程式應要求測試過的 capability profile——quality、latency、modalities、tool support 與 budget——再由 configuration 與 evaluations 解析。
工作原則
名稱是 deployment data
Active model identifier 留在 config 或 registry；historical fixtures 可以 pinned 以保持 reproducibility。
能力需要測試
Documentation 只縮小候選；fixtures 才能證明 prompts、tools、schemas 與 latency 是否適用。
保留 routing roles
不要把所有 workload 壓成一個 model；分開 quality、latency、realtime 與 background roles。
實地程序
- 01
定義 capability profiles
為每個 workload 記錄 modalities、tools、structured output、context、latency 與 budget。
- 02
建立 model registry
把 profile name 對應 deployable model identifier，並移出 feature code。
- 03
建立代表性 fixtures
包含 normal、edge、adversarial、refusal 與 tool-use cases，且有 observable acceptance rules。
- 04
執行 shadow comparison
切換前比較 candidate 與 current 的 quality、schema success、tool outcome、latency 與 cost。
- 05
可逆 rollout
分階段增加比例、監看 product outcome，並保留快速 rollback。
PASS / FAIL
驗收清單
- Feature branch 不寫死 volatile model name。
- Profiles 列出 hard 與 soft requirements。
- Evaluation 包含 tool 與 schema behavior。
- Rollout 與 rollback 都是 configuration change。
WATCH / REJECT
失敗模式
- 只看 leaderboard 或 marketing label。
- 沒有 behavior test 就更新 production default。
- 不相干 workload 共用一個 global model setting。