HopBase
結論から言うと、LLM API プロバイダーがモデルをすり替えていないか、こっそり品質を落としていないかは、約束ではなく再現可能なテストで確かめられます。そして、モデル自身に「あなたは何者か」と尋ねても何の証明にもなりません。システムプロンプト 1 つで、どのモデルにもどんな名前でも名乗らせられるからです。第一に、プロンプトキャッシュの経済性です。同じ長いシステムプロンプトでリクエストを繰り返し、2 回目以降に cache_read_input_tokens が安定してヒットするかを見ます。ランダムにルーティングされたトラフィックでは、ヒット率が低いかゼロになります。第二に、モデルファミリーの境界です。実際のコンテキスト上限、トークナイザーのカウント、パラメーターの扱い、ストリーミングの癖が、偽装しにくい指紋になります。第三に、ベンダーの公式 API との A/B 比較で、注入された指示をあぶり出します。第四に、temperature 0 で 20-50 件の客観的なタスクを使ったブラインドテストを、数週間にわたって繰り返します。第五に、エンジニアリング品質です。P95 の初回トークンレイテンシ、ストリーム途中での打ち切り、429/529 などのエラーコードが透過されるかを確認します。こうしたテストを歓迎しないプロバイダーは、それ自体がすでに答えになっています。
サードパーティのプロバイダーやアグリゲーターから LLM API を購入する際の最大の不安は、モデルは本物か、こっそり品質を落とされていないか、データはどこへ行くのか、という点です。市場でよく見られる答えは「ルーティングしない、品質を落とさない、すり替えない」という約束です。約束は検証できませんが、方法は検証できます。私たちはこうしたチェックを長期にわたって継続して実施しています。本記事はその社内メソドロジーの公開版です。どのチャネルにも使えます。もちろん、私たちにも。
ステップ 0:モデルに正体を尋ねるのはやめる
システムプロンプト 1 つで、どのモデルにもどんな名前でも名乗らせられます。しかも公式モデルでさえ、自分のバージョンを誤って答えることは珍しくありません。正体は自己申告ではなく、振る舞いで検証する必要があります。
チェック 1:プロンプトキャッシュの経済性(もっとも偽装しにくい)
Claude と GPT のプロンプトキャッシュには、公式に定義された課金構造があります。キャッシュ書き込みには割増、キャッシュ読み取りには割引が適用され、usage で cache_read_input_tokens を確認できます。これは組み込みの嘘発見器になります。
- 同じ長いシステムプロンプトでリクエストを繰り返すと、2 回目以降は安定したキャッシュヒットが見られるはずです(読み取りトークンの比率が高く、初回トークンも速くなります)。
- トラフィックをランダムにルーティングしているサービスでは、ヒット率が大幅に低いかゼロになります。リクエストが別々のアカウントやマシンに振り分けられるためです。
- ヒット率は実際のお金に直結します。長期的に偽装するということは、チャネル側があなたの費用を肩代わりするということであり、経済的に成り立ちません。
チェック 2:モデルファミリーの明確な境界
どのモデルファミリーにも隠しきれない境界があります。実際のコンテキストウィンドウの上限(上限近くの入力を投入し、切り詰めの挙動を観察します)、トークナイザーの違い(同じテキストでもトークン数はファミリーごとに体系的に異なるため、usage と照合します)、パラメーターの対応範囲(未対応のパラメーターは、公式 API とまったく同じようにエラーになるか無視されるべきです)、そして停止シーケンスやストリームの分割の癖です。単一の項目だけでは証拠になりませんが、組み合わせた指紋を完全に偽装するのは非常に困難です。
チェック 3:注入の痕跡
チャネルによっては、あなたのシステムプロンプトの前後に独自の指示を注入するものがあります。正体の書き換え、広告、制約などです。これは対照比較で検出できます。同じリクエストセットをベンダーの公式 API とテスト対象のサービスの両方に送り、指示の復唱やロールの境界に関するタスクで、指示への従い方の細部を比較します。私たちは 1 行の偽装から 4KB の注入ブロックまでさまざまなケースを見てきましたが、いずれも A/B 比較で浮かび上がりました。
チェック 4:品質劣化のブラインドテスト(サンプル数が重要)
「なんだか賢くなくなった気がする」は証拠になりません。公式 API でも出力のばらつきは大きいからです。信頼できる手順は次のとおりです。客観的な正解がある 20-50 件のタスク(コード補完、多段階推論、指示追従)を固定し、両方のチャネルを temperature 0 で実行して合格率を比較します。さらに数週間にわたって再テストし、時間帯によるモデルのすり替えを捉えます。ノイズを超えて持続する差だけが、結論と言えます。
チェック 5:エンジニアリング品質
モデルが本物でも、経路が悪いことはあります。平均値ではなく初回トークンレイテンシの分布を見ること(P95 のばらつきが大きい=経路が不安定)、長い出力でのストリーム途中の打ち切り率(サイレントな打ち切りはもっとも悪質な障害パターンです)、そしてモデルプロバイダーのエラーコードが透過されるか(429/529 を握りつぶしてタイムアウトに変えてしまうサービスは、リトライロジックを台無しにします)を確認します。
なぜこの方法を公開するのか
これは HopBase が自らに課している基準だからです。新しいルートを導入する際にもこの方法でテストし、その結果をもとに提供するかどうかを判断しています。また、料金ページでは各プランのチャネル属性を公開しています。透明なチャネルの出自と再現可能な検証は、「すり替えは絶対にしません」と百回繰り返すよりも説得力があります。本記事のすべてのチェックを、ぜひ私たちに対して実行してください。
企業での導入評価についてはアドバイザーにご相談ください。接続方法の詳細はドキュメントをご覧ください。