GetAPIGetAPI.ONE
タスクに合うモデルを選ぶ
現在のカタログを明示されたエンドポイントとタスクで絞り、自分の例で小規模な評価を行い、実測した品質、遅延、現在の費用の証拠から選びます。
最初に判断基準を定める
- タスク、必要な入出力形式、言語、許容遅延、失敗のコストを書き出します。
- Responses、Chat Completions、画像、動画など、アプリケーションがすでに対応する明示済みのエンドポイントを選びます。
- 代表的な例と、人が確認できる合格条件を用意します。
{
"task": "extract support ticket fields",
"endpoint": "openai-response",
"must_pass": ["valid JSON", "required fields", "no invented facts"],
"measure": ["quality", "latency", "live request cost"]
}根拠のある候補リストを作る
- 現在のカタログを開き、クライアントが呼び出す正確なエンドポイントで絞り込みます。
- 各候補の出典付き説明と最新料金を読み、欠けている事実は不明として扱います。
- 課金の可能性を受け入れられる場合、同じ小規模で代表的な評価セットを各候補に実行します。
- 同じ条件で出力品質、エラー、遅延、観測された費用を記録します。
- 主要モデルと代替モデルは、両方が必要な仕様を満たした場合のみ選びます。
評価チェックリストを使う
| 評価軸 | 記録すること |
|---|---|
| 仕様への適合性 | 明示されたエンドポイント、必要なパラメーター、出力の解析、エラー処理。 |
| タスクの品質 | 宣伝上の順位ではなく、自分が確認した例に対する合否。 |
| 遅延 | 同じ地域とリクエスト形式で観測した中央値と長い遅延。 |
| 費用 | 最新料金と、評価で実際に発生した使用記録。 |
| 信頼性 | 自分のテスト期間中のエラーと再試行の結果。 |
期待する判断を確認
- すべての候補モデルが、連携で使用するエンドポイントへの対応を明示していること。
- 選んだモデルが、最も簡単なプロンプトだけでなく、必要な例をすべて満たしていること。
- 選定文書に観測日、テスト入力、設定、測定可能なトレードオフが記録されていること。
選択時の間違いを避ける
- 見覚えのあるモデル名からエンドポイント対応を推測せず、現在のカタログの明示を使用します。
- 異なるプロンプト、地域、出力上限、再試行方針でモデルを比較しないでください。
- ベンダーのベンチマークを GetAPI.ONE のルーティング、料金、提供状況、個別タスクの品質の証拠にしないでください。