エージェント挙動の評価
出荷前に評価器を整える——評価セット、採点器、そして「コードかモデルか」の取舍。
なぜ「目視で良さそう」は通用しないのか
「いくつか出力を見たけど良さそう」という判断は、モデル更新・プロンプト修正・トラフィック増のどれにも耐えません。採点器がなければ改善と劣化の区別がつかず、すべての変更が賭けになります。
使える評価は 3 点セットです：ケース、採点器、ベースライン。
合成 200 件ではなく実ケース 20 件から
最も多い誤りは、実利用が何もない段階で大量の合成データを作ることです。合成データは「こう使われるはず」という思い込みを符号化します。たいてい外れます。
現実から集めましょう：
- 記憶にある実際の失敗
- ユーザーが実際に打ち込んだ不格好な入力
- 過去に壊した境界条件
- 「正解」自体が議論の余地あるケース
実ケース 20 件は、想像した 200 件に勝ります。実トラフィックが何が足りないか教えてくれてから拡張すれば十分です。
判定できる最も安い採点器を選ぶ
測る対象に合わせます。コードで済むのにモデルを使わない：
| 何を確認するか | 採点器 | 理由 |
|---|---|---|
| 形式・JSON の妥当性 | コード | 決定的、無料、即時 |
| 必須引用の有無 | コード（正規表現） | 判断不要 |
| 数値が許容範囲内か | コード | LLM より安く厳密 |
| トーン・明瞭さ・網羅性 | モデル（ルーブリック） | 判断が必要 |
| 計画が妥当か | モデル＋人手抜き取り | 影響が大きすぎる |
今日 80% の失敗を捕まえるコード採点器は、来月まで調整中のモデル採点器より価値があります。
自分と一致するルーブリックを書く
モデル採点器は揺れます。制約を入れます：
- 次元ごとに採点（正確性・網羅性・トーン）。総合点 1 つにしない
- 1〜5 の各段階を文章で定義する。両端だけ定義しない
- 根拠となる該当箇所の引用を必須にする
- 同一ケースを 3 回採点し、1 点以上のブレがあればルーブリックが曖昧
最後の檢查を飛ばすチームが多く、だから評価結果が再現しません。
数値の読み方
バージョン間で次を追跡します：
- 合格率——基準セットの代表指標
- 劣化リスト——以前は通っていたのに落ちたケース（最も行動に直結する成果物）
- 採点器の不一致率——ここが急上昇したらエージェントではなくルーブリックの破損
合格率が下がったら、手を付ける前に劣化リストを見ます。2〜3 件の具体例で差分の大半が説明できることがほとんどです。
注意
評価が測るのは基準セットであって製品ではありません。ユーザー行動が変わったらケースを見直してください。古いスイートは、もはやカバーしていない劣化を自信満々で通してしまいます。