# 複数LLMを比較して安い方へ流す時、品質ゲートを嘘つきにしない作り方 ## これは何か 「分類はA社、生成はB社、コードはC社」のようにタスク種別ごとに安いLLMへ振り分けると、コストは大きく下がる。 その判断を支えるのが**ゴールデンタスクによる成功率の実測**だが、**この計測は放っておくと必ず楽観側へ壊れる**。 この指示書は、複数プロバイダの成功率を比較して自動でルーティングを推薦する仕組みを作る時に、 **「安くする判断を、過大な品質評価が承認してしまう」**のを防ぐための設計と検証手順を示す。 実際に運用中の仕組みで、3つのプロバイダが過大報告されていた事例を一般化したもの。 ## 前提 - 5〜20問程度のゴールデンタスク（カテゴリ別に数問ずつ）を用意している - 複数プロバイダへ同じ問題を投げ、LLM-as-a-judge か決定的な照合で採点している - その結果からカテゴリごとの推奨プロバイダを自動で決めている ## 設計 ### 1. 成功率の分母は「試行数」にする（最重要） 最も踏みやすい罠。採点できた件数を分母にすると、**エラーや切断で脱落した問題が分母から消え、 大半を完了できないプロバイダほど高得点に見える。** ``` 悪い: rate = pass / graded ← エラーは分母から消える 良い: attemptedRate = pass / n ← 試行した全件が分母 ``` 実例（同一の15問セット）: | プロバイダ | pass/graded の表示 | 実態 pass/n | 内訳 | |---|---:|---:|---| | P社 flash | **100.0%**（表の最上位） | **0%** | 全件が429（無料枠クォータ切れ） | | Q社 9b | **100.0%** | **13.3%** | 出力切断13件 | | Q社 flash | 80.0% | **26.7%** | 出力切断10件 | 既に `pass/graded` で履歴を蓄積している場合、**定義を変えずに試行ベースの率を併記する**。 過去との比較が壊れるので、既存の指標は消さない。 ### 2. 「計測不能」という区分を作り、点数に関わらず推薦から外す 成功率の高低とは独立に、完走できたかどうかで足切りする。 ``` (errors + truncated) / n > 0.10 → 計測不能。順位に関わらず推薦候補から除外 ``` **「良い点だが大半が完走していない」は良い結果ではない。** 表示上は警告アイコンを付けるだけでなく、 **推薦を生成する関数の側で確実に除外する**こと。表示だけの警告は、自動推薦の経路では読まれない。 ### 3. 問題ごとの内訳を保存する カテゴリ単位の集計しか保存していないと、**どの問題が落ちたかを後から追えない**。 結果レコードに `{id, category, pass, status}` の配列を持たせる。 `status` は `pass` / `fail` / `error` / `truncated` を区別する（**エラーと不正解を同じ扱いにしない**）。 ### 4. 全滅した問題は「対象」ではなく「問題」を疑う 参加プロバイダの半数以上が落とした問題は、モデルの優劣ではなく**設問か採点基準が壊れている**可能性が高い。 ``` その問題を推薦の根拠から除外し、「設問または採点基準が疑わしい」と警告する ``` これをやらないと、**たまたま採点者の期待に一致した1つ**を「このカテゴリの勝者」として選んでしまう。 実例では、ある返信文生成の問題を7社中6社が落としており、隔離した結果そのカテゴリの推薦先が実際に変わった。 ### 5. 無料枠は「成功と失敗の間」ではなく「成功と沈黙の間」で壊れる 無料枠のAPIはクォータを使い切ると 429 を返すだけで、**何も言わずに結果が減る**。 リトライを実装していると、リトライ後の最終エラーだけが記録されて件数がさらに見えにくくなる。 **エラー件数と、その内訳（HTTPステータス）を必ず結果に残す。** ## 検証（ここまでやって初めて信用してよい） 1. **合成データの単体テスト**: エラー率が閾値を超えるプロバイダが「計測不能」に分類され、 **推薦関数の戻り値に現れない**ことを検証する。表示のテストだけでは不十分 2. **実データでの端から端まで**: 実際のログに対してレポートを出し、 過大報告されていたプロバイダが除外されること・推薦が実際に変わることを目で確認する 3. **同一条件の2回計測**: 1回では判断しない。実例では同じプロバイダが同日2回の計測で **93.3% → 66.7%** と振れた。**1回の計測は安定した根拠にならない** ## 運用上の原則 - **安くする変更は「品質が落ちていない実測」とセットでのみ採用する。** 実測が無い節約案は提案止まりにする - 計測が古くなると、実測を根拠にしていたはずの判断が惰性に変わる。 **最終計測日からの経過日数を監視し、一定日数で警告を出す** - 推薦を自動で他システムへ流し込んでいる場合（設定ファイル生成、エージェントへの指示注入など）、 **その経路の先で誰が何を決めているかを把握しておく**。 過大な推薦は、人が表を見て気付く前に自動で採用されてしまう - 他ドメインのベンチマーク結果を、自分のドメインの判断へ横流ししない。 「保険金査定10問で品質を維持したまま65%安くなった」は、 設計や横断調査を含むタスクで同じ結論になる保証にはならない ---