意思決定ワークロードをDrex MaxからGemini Decision 1へ移行する

この移植はURLの変更のように見えるが、そうではない。Drex Max v1.1とGemini Decision 1はどちらも、コンテキストの塊と型付き質問の集合を受け取り、確率を返す。だから移行初日の午後は順調に進む。フィールド名を変え、クライアントのベースパスを別のものに向け、テストスイートを実行すればよい。うまくいかなくなるのは2週目で、トラフィックが増え、2つの課金モデルが「何に対して支払うのか」について食い違うことが明らかになるときだ。これは、実際に何を変える必要があるのかを記した記録であり、動作するDrex Max v1.1統合を抱え、新しいモデルの目玉のスコアが移行を正当化するのか疑問に思っている人のために書かれている。

まず、このトレードオフについて正直なところから始めましょう。Artificial Analysis Decision Index v2.1 では、Drex Max v1.1 が 73 点、Gemini Decision 1 が 66 点です。古いモデルが勝ち、その差は 6.6 点で、その大半は複合スコアの 30% を占めるコンポーネントによるものです。ワークロードが文書トリアージなら、この移行はアップグレードの衣をまとったダウングレードです。別のものであれば、読み進めてください。なぜなら、2 つのエンドポイントはリクエストの形が示唆するほど似ていないからです。

どのリーダーボードにも載らない違い

Drex Max v1.1 は各質問に独自の 131,072 トークン予算を与えます。Gemini Decision 1 はリクエスト全体に 262,144 トークンを与え、それを入力とその中の各質問の間で共有します。これら二つの文は同じ製品カテゴリーを説明しながら、正反対のエンジニアリング上の助言を生み出します。

Drex では、200 件の質問を投げると 200 個の別々の予算を消費し、リクエストの実用的な上限はコンテキストではなくレート制限です。Gemini Decision 1 では、200 件の質問と 1 件の 200,000 トークンの契約書を同じリクエストに収めることはできません。入力に 200,000 トークンを使うと、質問と指示に 62,144 トークンが残るので余裕がありますが、入力が 250,000 トークンだと 12,144 トークンしか残らず、リクエストは失敗します。上限は実在し、共有され、送信する量に応じて変わります。

これは、稼働中のDrex統合を壊す可能性が最も高い単一の変更です。というのも、その障害モードは低負荷時にエラーになるものではないからです。30,000トークンのドキュメントに対して20問を処理するテストスイートは、どちらのシステムにも余裕をもって収まります。本番環境では、180,000トークンのレコードと900問を扱うと、一方には収まり、もう一方には収まりません。

トークン単価が隠しているもの

Drex Max v1.1は、定価$0.06に対してローンチ価格として100万入力トークンあたり$0.03で掲載されており、Gemini Decision 1は$0.10です。どちらも出力には課金しません。その列だけを見れば、Drexは1.7〜3.3倍安く、大量処理を行うチームにとってはそれだけで議論を終わらせるのに十分です。

タスクあたりで測ると、差は縮まる。Artificial Analysis によれば、Drex Max v1.1 は100万意思決定タスクあたり103ドル、Gemini Decision 1 は345ドルで、比率は約3.3だ。これは定価の比較であり、ローンチ価格ではない。理由は、Gemini Decision 1 が回答に到達するまでにより多くのトークンを読むからだ。共有コンテキストは2倍のサイズで、構成スコアからは、各質問に対してより少なくではなく、より多くの入力を通していることが示唆される。タスクあたりで見れば、正直な差はおおむね Drex 有利の3対1であり、ローンチ割引は一時的な条件で、2回目の契約更新には残らないだろう。

つまり、価格設定の問いは「どちらが安いか」ではなく、「あなたのタスクのうち何割なら、正しく処理するために3倍の費用を払うか」ということだ。サポートチケットをキューに振り分けるルールは、代替手段より5%多く誤るなら、何の価値もない。契約条項を法務レビューのためにフラグ付けするルールは、その差を即座に正当化する価値がある。

ドキュメント処理こそがスコアの出どころです。

6.6ポイントの複合格差は均等に分布しているわけではなく、移行をめぐる議論は、その格差がどこに存在するかを把握していることが前提となる。

• AA-Paperclip、ウェイト30% — Drex Max v1.1 は72.8を記録し、オール・オア・ナッシング方式のテストで文書の63%をそのまま通過します。Gemini Decision 1 は56.8で、33%を通過します。このコンポーネントだけで総合スコアの差の大部分を説明できます。

• When2Call、10% — ツール呼び出しの判断力において、Drexは95.3対Geminiの80.5で14.8ポイント差。これはDrexがあらゆる項目で持つ最大の割合リードです。

• EvalSafe-O*NET-AA, 15% — 88.3 対 87.1。丸め誤差にすぎず、しかもこのセットで唯一の安全性関連テストです。

• AA-Omniscience-Decision v1.1、15% — Drex 60.3、Gemini 66.3。Geminiの優位性、そしてそのローンチ時の報道が知識を前面に打ち出した理由。

• HLE-MultiChoice v1.1、15% — Drex 46.6、Gemini 48.7。差はわずかであり、両モデルとも推測するよりも回答を控えることが十分に多いため、素の精度はこれらの数値を大きく下回ります。

• AA-Symmetry v1.1, 15% — Drex 79.8 対 70.5。質問の順序が入れ替えられ、ラベルが付け替えられ、否定されても答えが持ちこたえるかどうか。これはボード上で安定性テストに最も近いものだ。

そのうち2行は、コミットする前に再確認する価値があります。文書抽出では、厳格な指標においてDrexはほぼ2倍信頼性が高く、対称性では9ポイント安定しています。つまり、Drexベースのパイプラインは、同じ質問が異なる表現で尋ねられたときに答えが反転するケースが少なくなります。製品がユーザーに単一の回答を表示する場合、不安定さはバグ報告です。下流のスコアに供給する場合、不安定さは平均化して消せる分散です。

スピード、そして両方を維持する理由

Drex Max v1.1 はタスクを中央値 283 ミリ秒で実行します。Gemini Decision 1 は同じタスクを 211 ミリ秒で実行します。新しいモデルはより多くの処理を行っているにもかかわらず高速であり、移行が無条件に役立つ唯一の点です。ユーザー向けアクションの前に行う同期チェックにとって、70 ミリ秒は決して無視できません。

速度・価格・精度がこれほどきれいに一方向へ揃うことはめったになく、ここでも揃っていない。Gemini はより速くて劣り、Drex はより遅くて優れ、コスト比はレイテンシ比ではなく品質比に従っている。これは、片方が厳密な改善であるというより、設計が本当に異なる2つのモデルであることの証だ。

それが実際の推奨です。単一のスコアリングモデルを持つ意思決定サービスには、単一障害点と単一の意見しかありません。両方を実行すると、2つ目の統合コストがかかる代わりに、不一致シグナルを得られます。2つのモデルが高い信頼度で異なる答えを返す場合、そのケースは真に曖昧であり、おそらく自動化すべきではありません。そのパターンは古く、退屈で、単一モデルの信頼度スコアでは決して捉えられないエラーを捉えます。

呼び出し自体の移植

機械的な部分は会計的な部分より小さく、始める前に挙げておく価値のある3つの罠がある。

まず、Drex は /v1/systemone でモデル ID を drex-max に固定して呼び出されます。クイックスタートにある drex-latest エイリアスは固定された ID ではなく、これを使うと、デプロイなしにモデルが知らないうちに変わることになります。Gemini Decision 1 には逆の問題があります。エイリアスはまったくなく、gemini-decision-1 だけであり、gemini-decision を指定したリクエストは解決されません。両方で固定し、モデル ID はソース内の定数ではなく、設定内のバージョン番号として扱ってください。

次に、メディアの制限はそのまま当てはまりません。Drex Max v1.1は1リクエストあたり最大8枚の画像を受け付けます。Gemini Decision 1はテキスト、画像、音声、動画、PDFを受け付け、制限はインラインbase64で100 MB、PDF1件あたり50 MB、HTTPS URL1件あたり15 MBで、YouTubeリンクとgs:// URIは明確に拒否します。1リクエストあたり8件のページスキャンをバッチ処理するDrexパイプラインは、ページを1つのPDFとして送るか、バッチを分割するGeminiパイプラインになります。

第三に、質問タイプは近いものの、境界は同一ではありません。どちらも yes/no、choice、score をサポートします。Gemini は choice と score を 2～255 個の選択肢またはレベルに制限し、yes/no の確率を 0.01～0.99 にクランプします。そのため、Drex コードで 0.99 を超えて設定したしきい値は、移植後に黙って発火しなくなります。設定ファイル内のものだけでなく、コードベース内のすべてのしきい値定数を確認してください。

ルーターが適する場面と、適さない場面

OrcaRouterはgemini-decision-1もdrex-maxも提供していません。どちらも確率のみのエンドポイントであり、私たちのような形のルーターはchat-completionsターゲットを前面に置くものです。そうでないと主張することは、最初のリクエストで失敗する可用性の主張になります。この移行でルーターが担うのは、パイプラインのうちスコアラーではない部分です。

ほぼすべての意思決定サービスは、スコアリングされる前に下書きが作成される：生成モデルが候補条項を抽出したり、評価基準を提案したり、あるいは記録を要約して、意思決定モデルがその後読み取る共有コンテキストに落とし込んだりする。この下書き用の呼び出しこそ、ベンダー選択が実際に重要になり、2つ目の契約が痛手となる場面であり、次のモデル群にまたがって実行できる：1つのエンドポイント上の200を超えるモデル（プロバイダーのリスト価格は0%のマークアップでパススルーされる）. ルーティングDSLは、チャット製品におけるよりもここで重要である。なぜなら下書き用の呼び出しは多様であり、トリアージには安価なモデル、18万トークンの記録には長コンテキストモデルを使い分けるため、それをルールとして表現する方が3つのSDKとして表現するより優れているからだ。

正直な限界：フェイルオーバーが保護するのは下書き用の呼び出しであり、スコアリング用の呼び出しではありません。意思決定リクエストを送る場所は1つしかなく、そこが利用できなければサービスも利用できません。その依存関係を受け入れられない場合、上記の2モデルパターンは単なる精度対策ではなく、利用可能な唯一の実質的な冗長性です。なぜなら、独立した2つのスコアリングエンドポイントを持つ唯一の方法だからです。

結論

判断が知識型である場合、速度が重要な場合、または一度に記録全体を保持できる十分な大きさの共有コンテキストが必要な場合は、Gemini Decision 1 に移行してください。判断が文書型である場合は Drex Max v1.1 に留まってください。合格率が示すように、おそらくそうなっています。実際に確認してみると、ほとんどの判断ワークロードは文書抽出であることが分かるからです。誤った回答のコストが高い場合は両方を実行し、誰かにコスト削減を約束する前に3対1のコスト比を見込んでください。移行には1日分の作業と四半期分の再調整が必要です。移行するかどうかの判断は、あなたのワークロードがインデックスのどの構成要素に実際に似ているかによって決まります。