複数の言語モデルを使うサービスは、どの依頼にどのモデルが答えるべきかという地味な選択を毎日迫られています。すべてを最も高いモデルに送れば簡単な質問にお金を無駄にし、すべてを最も安いモデルに送れば難しい質問で品質が落ちます。ルーターはこれをプロンプトごとに決めようとする仕組みです。ACM Web Conference 2027向けに書かれた、イタリア国立研究評議会とピサ大学のプレプリントは、そこにひとひねり加えます。最良の答えは、複数のモデルに同時に尋ねることである場合もある、というものです。
PISAは単一モデル版です。プロンプトを似た依頼のグループにゆるやかに割り当て、それをモデルごとに学習させた予測器と組み合わせることで、そのプロンプトに対する各モデルの能力を見積もります。PISA-Eはこれをアンサンブルに広げたもので、どのモデルを何個呼ぶかを選び、各モデルの推定能力に応じて似た回答に重みを付けて答えをまとめます。実用上の最大の特徴は、再学習なしに推論時に調整できるコストと品質のつまみです。同じシステムで、混雑時には安い回答を、上位プランの利用者にはより良い回答を優先する、といった運用ができます。
チームは、LLMRouterBench Track-2、RouterBench、FusionBench、SPROUTという4つの公開ルーティングベンチマークで、既知のタスク群と取り置いたタスク群の両方を使って試しました。単一モデルのルーターの中では、PISAがどちらの条件でもコストと性能の平均的なバランスが最も 良く、8通りの組み合わせのうち6つで首位でした。品質重視に設定したPISA-Eは、最も強いアンサンブル手法を既知のタスクで2.09ポイント、未知のタスクで2.87ポイント上回りました。より安い設定でも同等以上の成績を保ちつつ、平均コストを約36%と25%削減しました。
すでにOpenRouterのようなゲートウェイを使い、1つのアカウントで多くのモデルを利用しているチームにとって、これはその上に載せられる仕組みです。窓口は1つで、依頼ごとにシステムがモデルを選びます。当サイトのOpenRouterのレビューでは、その強みはモデルと提供元の幅広さにあると書きました。どのプロンプトにどのモデルを使うかは大部分が利用者任せで、PISAが狙うのはまさにその空白です。
改善幅は控えめで、試験はオフラインです。どの手法も、ベンチマークが用意したモデルの回答で採点されており、プロンプトが移り変わり、価格が変わり、待ち時間がコストと同じくらい重要になる実際の通信では試されていません。アンサンブルは呼び出し回数も増やすため、節約になるかは、ルーターが単一モデルを選ぶ頻度しだいです。私たちが読んだ範囲では、ルーター自体にかかる負荷の数字は示されておらず、本番で使う人は乗り換える前にそれを知りたいはずです。