現場実装の クムビーバー です。性能の測り方が固まったら、品質の門番（評価基準）を具体的に設計します。ここが弱いと、速いだけの構成が現場に流れます。
この回の答え
品質は速さの表とは別ノート。共通7軸で語彙を揃え、スモーク→用途別スイート→深い判定の順。量子化比較では平均だけでなく QualityRetention（品質保持）と最悪サンプルを見る。
この回だけの用語
| 用語 | ひとことで |
|---|---|
| スモーク | 軽い門番テスト。壊れていないかを先に見る |
| 用途別スイート | coding / JSON / tool-call など、用途に寄せた問題セット |
| 共通7軸 | 正確性・関連性・一貫性など、用途を跨いで揃える品質の語彙 |
| QualityRetention | 量子化前後で品質がどれだけ残ったか。平均だけでは足りない |
| scorer | 機械で判定できる採点器。LLMジャッジより先に置く |
| pass_rate | 合格率。未計測は None（0 と読まない） |
品質は「なんとなく良い」で止めない
性能が良くても、コードが壊れる・JSONが欠ける・ツールを呼べない構成は使えません。かといって、最初から巨大な人間評価やLLMジャッジに頼ると回りません。
社内では、品質を次の段階で扱います（評価軸標準の Smoke → 用途別 → Deep に対応）。
- スモーク（オフラインで即判定）
- 用途別スイート（coding / JSON / tool-call、指示追従など）
- 深い判定（実行ベースの coding ベンチ、judge、長文など）
この回は、その具体的な落とし込みです。
共通品質軸（用途を跨ぐ・7軸）
用途が違っても、まず次の 共通7軸 で語彙を揃えます（社内評価軸標準 §2.1。1〜5 などで採点する想定）。スモークや scorer の回は「門番の実装」、ここは 何を見るかの定義 です。別記事には分けていません。
| # | 軸 | 定義 | 判定で見るもの |
|---|---|---|---|
| 1 | Accuracy（正確性） | 事実・計算・コードの正しさ | 誤情報、バグ、計算ミス |
| 2 | Relevance（関連性） | 質問意図への合致 | 的外れ、過不足 |
| 3 | Coherence（一貫性） | 論理構成・文の繋がり | 破綻、矛盾、冗長 |
| 4 | Instruction Following（指示追従） | 制約（語数・形式・言語など）の遵守 | 逸脱の有無 |
| 5 | Format Compliance（形式遵守） | JSON / 表 / guided などの構造妥当性 | パース可否、必須キー |
| 6 | Language Correctness（言語適合） | 要求言語での応答 | 日英混在、言語誤り |
| 7 | Safety（安全性） | 有害要求の拒否・不適切生成の回避 | 過剰拒否も減点 |
加えて運用上、reasoning 系では次を 8番目の確認項目 として残します（軸というより測定バグの検知）。
- 思考過程と最終
contentを分けて見る（経路によってキー名が違う。直叩きではreasoning、入口経由ではreasoning_contentなどに正規化されることがある） finish_reason=lengthかつ content 空になっていないか（max_tokens 不足の典型）- thinking のキー名がモデル系列どおりか（キー不一致は OFF と同義）
- 全候補が大きく公開値未達なら、モデル弱さより測定を疑う
judge 採点は便利ですが 代理値 です。厳密比較は、用途固有の実行指標（pass@1、CER、needle 命中など）を正とします。共通7軸は「会議で同じ言葉を使うため」、用途ベンチは「採否の本体」です。
事実性スイートでは、正答率だけでは足りないことがあります。事実退行と**過信（誤答でも自信を持って答える）**は別シグナルです。平均 Accuracy が近くても、棄権せず誤答する傾向が強い候補は、本番既定が thinking OFF の用途では特に危険です。逆に、thinking ON と努力度指定で強みが伸びる候補でも、本番既定が thinking OFF なら長所が発揮されず短所だけが残ることがあります。用途プロファイルで ON／努力度を明示してください。
最小スイートの中身（門番）
coding-smoke 系で最初に置く典型は次です。
| タスク種 | 見ること | scorer例 | 合格の意味 |
|---|---|---|---|
| coding | 必要断片・シグネチャ | contains | 次の比較に進めてよい |
| json_schema | パースと必須キー | json_valid | 構造化出力の土台がある |
| tool_call | 期待ツールと必須引数 | tool_call | エージェント用途の入口 |
重要なのは、pass_rate だけで終わらないことです。タスク別内訳がないと、「何が弱いか」が消えます。
合否を残す一文テンプレ
- coding: 「指定関数名と基本シグネチャ断片が出力に含まれる」
- json_schema: 「パース可能で必須キーが揃った JSON である」
- tool_call: 「期待ツールが必須引数付きで選択される」
コーディングは1種類ではない（検証の拾い方）
門番の coding タスクは「関数っぽい断片が出るか」までです。本計測では、コーディングを 段階 で分けて拾います。混ぜると「コードが得意」の意味が消えます。
| 段階 | 何を見るか | 代表指標（例） | 比較で固定すること |
|---|---|---|---|
| 関数レベル | 単一関数・短い問題の正しさ | pass@1（HumanEval+ / MBPP+ 等） | 言語・問題セット版・temperature |
| リポジトリレベル | 複数ファイル・Issue 修正・テスト追加 | 解決率、変更精度、破壊的変更の有無 | 対象リポジトリ／Issue セット |
| エージェントレベル | ツール選択・多段実行・回復 | tool 選択/引数、タスク完遂、ループ率 | ツール定義・パーサ設定・手順 |
周辺として、テスト生成 や セキュリティ診断 のような用途スライスも別枠です。関数 pass@1 が良くても、ここが弱いことは普通に起きます。ピックアップ時は「どの段階／どのスライスの話か」をラベルに残します。
運用ルール
- スイートを変えたら版を上げる
- 未起動の全滅をモデル不合格と読まない
- 重い判定は門番通過後だけ
- 合否は観点名で会話し、感想で会話しない
- コーディング比較は段階ラベル（関数 / リポジトリ / エージェント）を必須にする
チェックリスト（品質runの前）
- [ ] 最小3タスク（coding / JSON / tool-call）があるか
- [ ] 合格条件が一文で書かれているか
- [ ] スイート版を記録するか決めたか
- [ ] 未起動全滅の読み方を共有したか
- [ ] 門番通過を採用決定と混同しないか確認したか
- [ ] 深い coding 比較なら段階（関数/リポジトリ/エージェント）を明示したか
- [ ] 量子化比較なら QualityRetention・最悪サンプル・誤り件数を残すか
- [ ] 深い品質ベンチで sampling・生成長・thinking キーを公式推奨と突合したか
- [ ] 全候補が大きく公開値未達なら、測定無効を先に潰したか
- [ ] 事実性なら過信（誤答でも自信）を正答率と分けて見たか
量子化前後の品質保持（平均だけで決めない）
モデルやプロファイルを量子化したときは、スモーク通過だけでは足りません。社内では量子化前を基準に QualityRetention（量子化後 / 基準）を軸別・総合で残し、性能比とセットで見ます。地図は 量子化をレイヤで見る 側です。
転びやすいのは次です。
| 罠 | 対策の型 |
|---|---|
| 平均が意味改変を希釈する | per-sample の最悪値・誤り件数の増分 |
| 小標本の点推定で誤 FAIL | 区間が重なるか（有意な退行か）を見る |
| tok/s だけ見て採用 | 品質保持ゲートを同じ run に残す |
OCR／転記では「平均 CER が近い」ことと「数値や語の意味が別物になっていない」ことは別問題です。コーディングでも同様に、平均 pass の隣に最悪ケースを置きます。
門番を過大評価しない
スモーク通過は採用決定ではありません。意味は「次のコストを払う価値がある」までです。長文や同時実行で落ちる構成を、門番通過だけで本番相当扱いすると事故ります。
逆に門番が弱いと、明らかに不適合な候補へベンチ時間を溶かします。バランスは、速く落とすことと早く進めすぎないことの間にあります。
シナリオで言うと、coding-smoke に通った構成を「開発者向けエージェント本番」と宣言するのは飛びすぎです。次に関数レベルの実行指標、必要ならエージェント段階と同時実行を見てから、testing ラベルを付けます。
ポイント
品質評価の成果物は点数ではなく、落ちた観点名と次の仮説です。
つまずいたこと
人手レビューだけに頼ると、評価が好みの投票になります。逆に自動スコアだけだと、現場の怒りと一致しません。両方を同時に設計できず、しばらくはどちらかに振れました。
つらかったのは、赤い結果を「モデルが悪い」で片付けてしまう文化です。プロンプトと採点器と入力分布を分けて疑うまで、同じ失敗を繰り返しました。
この回の要点
- 共通品質は7軸（＋reasoning 時空応答チェック）で語彙を揃える
- スモーク → 用途別 → 深い判定の順を守る
- コーディングは関数 / リポジトリ / エージェントで分けて拾う
- 量子化比較は QualityRetention と最悪サンプルを見る
- 赤を『モデルが悪い』で片付けず、プロンプト・採点器・入力を切り分ける
品質の語彙と段階（スモーク→用途別→深い判定）は公開していますが、用途別の合格点は未確定です。赤票の実例スコアは再計測と匿名化が済んだものから足します。
次は「3タスクで始める品質評価：coding-smokeの設計」です。7軸の語彙を持ったまま、最短のスモーク設計へ落とします。
よくある質問
品質評価は最初から深いベンチが必要ですか？
いいえ。オフラインで即判定できるスモークを門番にし、通過した候補だけを用途別・深い判定へ進めます。
共通品質軸は何本ですか？
社内標準では7軸です。用途が違っても、まずこの語彙で揃えてからスイートを増やします。
コーディング評価はどう段階分けしますか？
関数単位→リポジトリ単位→エージェント（ツール連続）の順です。一段飛ばすと失敗原因が混ざります。
量子化後の平均スコアが近ければ合格ですか？
いいえ。平均は意味改変級の失敗を薄めます。QualityRetention に加え、最悪サンプルと誤り件数を見ます。
候補がそろって公開スコアを大きく下回ったらモデルが悪いですか？
いいえ。まず sampling・生成長・thinking キー・リクエスト実体を疑います。測り方が壊れていると順位まで入れ替わります。
