カスケードと並列質問

どちらのパターンの動機も単純です。大きなモデルの呼び出しは高価で、 ほとんどのリクエストは簡単です。 意思決定の 1 回は生成の 1 回より 1〜2 桁安いので、「まず安い方に聞き、不確かなら上げる」という形は当然の帰結です。

カスケード：確信があるところだけ確定させる

医療における幻覚検出の比較評価が、きれいな数字を出しています。

意思決定モデルが 90% 以上確信している 37% をその場で確定させると、 各大モデルの精度を保ったまま、大モデルの呼び出しを 37% 削減できる。

引用に値するのは、カスケードの節約額が何なのかを言い切っているからです。 高信頼領域に落ちるトラフィックの割合であって、固定のパーセンテージではありません。 信頼区間を締めるほど多く省けます —— ただしその信頼度が本物である限りにおいて、 という話は校正に戻ります。

見落としやすい点が二つあります。

① エスカレーション後、大モデルに無制限の自由を与えない。 不確かな行を LLM に渡すある実装は、その LLM に同じラベル集合から選ぶことを強制します。 そうしないと、小モデルの「不確か」が、パイプラインが扱えない出力に変換されます。

② 一度選んだら固定する。 あるモデルルータは、prompt cache の連続性のために セッション全体で選択を保持します。毎回選び直すとプレフィックスが変わり キャッシュが落ちます —— 安い呼び出しで浮いた分が、キャッシュで戻っていきます。

並列質問：節約されるのは入力

意思決定モデルは多数の質問を 1 リクエストにまとめられます。 公式の例では一度に数十問を投げています。

2,976 回の呼び出しを回したベンチマークが、その効果を測っています。

つまり節約の実体は「モデルが速い」ではなく、同じ state を一度だけ送ることです。 質問が増えるほど、この固定費が薄まります。質問が 1〜2 問だと、並列と逐次の差は リクエスト間のゆらぎと同じ桁で、アーキテクチャを変える価値はありません。

反例：バッチ処理が順位付けを壊す

このページで最も直感に反する結果です。

ある DuckDB 拡張は既定で 40 行ずつまとめて処理します。 ベンチマークでは、バッチ経路は順位品質のゲートを通らず、 1 行 1 リクエストは通るという結果でした。

理由は復元できます。40 行を 1 リクエストに詰めると、40 個の相対順序を 一度に出すことを求められます。少数の候補を比べるより難しい。 ここで費用と忠実さは衝突しています —— そして費用側は見えますが（請求書）、 忠実さ側は測るゲートを作らない限り見えません。

一般則として、並列質問は互いに独立な問い（分類・採点・判定）に向き、 互いに比較する必要がある順位付けには向きません。

もう一つの前提：誤りがランダムであること

カスケードが成立するのは、小モデルの誤りがランダムノイズであり、 大モデルがそれを正せるという暗黙の仮定の上です。

独立した分布外校正テストは、それに反する証拠を出しています。 Choice と Score は体系的に過信、Boolean は体系的に自信不足。 体系的な偏りはノイズではありません。小モデルはある種の入力全体で 高い信頼度を返すようになり、その種は決してエスカレーションされず、 一貫して間違えられます。

したがってリスクは「精度が少し下がる」ではなく、ある種の入力が安定的に 取りこぼされることで、しかも全体指標では見えません。見つけるには 部分クラスごとに精度を見る必要があります。

一文で

カスケードの節約額は「高信頼領域のカバー率」に比例し、並列質問の節約額は 「薄まる固定費」に比例します。どちらにも代償があります —— 前者は誤りが ランダムであることに賭け、後者は相互比較が必要なタスクを傷つけます。