ライブの capability surface を読む
実装時に公式 models directory を確認します。自分の account と region での availability、input/output、tool 対応、context limit、現在の価格を確認し、family name から能力を推測しません。
設定の近くにドキュメントリンクを置き、次の担当者が古い comment ではなく判断を再確認できるようにします。
Leaderboard ではなく仕事を評価
実際のタスクと失敗から代表的な set をつくり、correctness、instruction following、evidence quality、latency、total cost を採点します。media や voice では modality 固有の品質と配信条件も含めます。
対話速度、深い分析、media、fallback で別モデルを使う routing policy も可能です。ただし理解可能に保ち、routing 自体もテスト対象にします。
- 本番ではテスト済み identifier を pin する。
- 自動移行に使う alias の挙動を先に確認する。
- 障害前に fallback を定義する。
交換を日常作業にする
model identifier、timeout、reasoning control、feature flag を検証済み設定に置きます。変更ごとに evaluation baseline と rollback value を残します。
catalog やアプリ変更時に同じケースを再実行します。品質 gate 後に昇格し、latency、error、task success の drift を監視します。