プロンプトの複雑さに基づくルーティングが、有意義なコスト削減をもたらすかどうかを評価するベンチマークを実施しました。公開されているHuggingFaceのデータセットを使用しました。結果は以下のとおりです。
セットアップ
ベースライン：すべてにClaude Opusを使用。2つの戦略を検証しました：
- イントラプロバイダ — 同一プロバイダ内で複雑さに応じてルーティング。シンプル→Haiku、ミディアム→Sonnet、複雑→Opus
- フレキシブル — ミディアムプロンプトは自己ホストのQwen 3.5 27B / Gemma 3 27Bへ。複雑なものは常にOpusにとどめる
使用したデータセット
すべてHuggingFaceのAdaptLLM/finance-tasksから：
- FiQA-SA — 金融ツイートの感情
- Financial Headlines — はい/いいえ分類
- FPB — 金融ニュースの形式的な感情
- ConvFinQA — 実10-K提出書類に基づくマルチターンQ&A
結果
| タスク | イントラプロバイダ | フレキシブル（OSS） |
|---|---|---|
| FiQA 感情 | -78% | -89% |
| Headlines | -57% | -71% |
| FPB 感情 | -37% | -45% |
| ConvFinQA | -58% | -40% |
ブレンド平均：~60%の削減。
最も興味深い発見
ConvFinQAは複雑なマルチターンQAデータセットであるにもかかわらず、58%のイントラプロバイダ削減を示しました。スコアラーは、長い10-K文書の中には多くの質問が“単なる参照（ルックアップ）”で済むことを、周辺の文書が複雑であっても正しく特定できていました。
「2014年の営業キャッシュフローはいくらでしたか？」 → 答えは表にある → Haiku
「3年間にまたがる、推定される実効税率の調整はどのようになりますか？」 → 複数ステップの推論 → Opus
注意点
- 金融の縦型（vertical）に限定
- ECTSumのトランスクリプト（~5Kトークン）では毎回“複雑”とスコアされ、ルーティングできなかった。いまも長文タスク向けに調整中
- 代表的なサンプルに対する品質検証であり、全自動の評価ではない
タスク固有のLLMルーティング判断を評価するために、どのようなデータセットを使っていますか？具体的には、単純な分類から複雑なマルチステップ推論までをまたぐベンチマークを見つけようとしているのですが。
[リンク] [コメント]
