シミュレーション評価とは｜試験を5件回しても不具合は0件、14件目で5件すべて出た

試験を5件回しても不具合は0件、14件目で5件すべて出た

不具合を仕込んだ実装で実際に回しました。素直な例では0件、境目の例を含む14件目で5件すべてが出ます。

シミュレーション評価の効き方を、実際に不具合を仕込んで確かめました。題材は問い合わせを担当課に振り分ける実装です。

実装には4つの不具合を仕込んであります。試験は本当に実行しており、検出数は実測です。

function route(text) {
  if (text.includes('返金')) return '経理';
  if (text.includes('請求')) return '経理';
  if (text.includes('故障')) return '技術';
  if (text.includes('解約')) return '営業';       // 不具合1: 解約は法務が正
  if (text.includes('見積')) return '営業';
  if (text === '') return '営業';                 // 不具合2: 空文字は保留にすべき
  if (text.includes('請求') && text.includes('故障')) return '技術';  // 不具合3: 到達しない
  if (text.length > 200) return '営業';           // 不具合4: 長文は要約に回すべき
  return '営業';
}

試験件数   見つかった不具合  見逃した不具合
     1件             0件             5件
     5件             0件             5件
    10件             1件             4件
    14件             5件             0件
    20件             5件             0件
    40件             5件             0件

全 40件を回して見つかった不具合（5件）
  「領収書を再発行したい」  期待 経理 / 実際 営業
  「解約したい」  期待 法務 / 実際 営業
  「（空文字）」  期待 保留 / 実際 営業
  「請求書の件で故障の相談です」  期待 技術 / 実際 経理
  「ああああああああああああ…（250文字）」  期待 要約 / 実際 営業

件数と検出数が比例していません。5件でも0件、14件で5件、そこから26件足しても0件のままです。

素直な例では出ない

最初の9件は「返金してほしい」「見積をお願いします」といった素直な問い合わせです。実装はこれらを正しく振り分けます。正しく動く範囲を何件確かめても、壊れている場所には触れません。

後半に足した26件も同じ性質のものです。ですから検出は増えませんでした。

境目の例が効く

10件目から14件目に、境目の入力を集めてあります。語が別の分岐に先取りされる例、空文字、条件が重なる例、極端に長い例です。ここで5件すべてが出ました。

仕込んだ不具合は4つでしたが、検出は5件です。5件目の「領収書を再発行したい」は仕込んだ覚えのない漏れで、書きながら気づいていませんでした。試験の結果を記録に残す設計はエージェント可観測性の記事で扱っています。

到達しない分岐

不具合3は分かりにくい種類です。「請求」の判定が先にあるため、その後の複合条件には決して到達しません。読んで気づける人もいますが、動かせば確実に出ます。コードを自分で見直させる方法では見つけにくい種類でもあり、その限界は自己反省の記事で扱っています。

どんな試験を作ればよいのか

実際の仕事の分布を写したうえで、境目を足します。採点はコードでできる形に寄せてください。

シミュレーション評価の設計は、何を入力に選ぶかと、どう採点するかの2つで決まります。前の節の結果が、前者の重要さを示しています。

実際の分布を写す

Anthropicは方針を明確に示しています。その仕事に固有の試験にすること、つまり実際の仕事の分布を写した試験を設計することだという書き方です。

同じ文書では、境目の例を忘れないようにという注意も添えられています。前の節でいえば、10件目から14件目にあたる部分です。

採点の仕方を選ぶ

1. コードで採点する。完全一致、文字列の一致。速くて確実
2. AIに採点させる。判断が要る場合。まず信頼できるか確かめてから広げる
3. 人が採点する。質は高いが遅くて高い
4. 採点の基準を決めないまま回す。結果を読めない

1番目から検討してください。Anthropicも、コードによる採点は最も速く最も信頼でき、規模も広げやすいとしています。ただし規則で割り切れない judgment には向かない、という但し書きも付いています。

件数を増やす意味

前の節では件数を増やしても検出が増えませんでした。ただしこれは足した26件が素直な例だったからです。

同じ文書には、自動で採点できるなら少し精度の落ちる問いを多く用意するほうが、質の高い手作業の試験を少数用意するよりよいという方針も示されています。自動採点が前提であれば、件数は効きます。

シミュレーション評価とは何をする仕組みなのか

本番に出す前に、決めた入力を流して結果を採点します。何をもって成功とするかを先に決めるところから始まります。

シミュレーション評価は、本番に出す前に決めた入力を流し、返ってきた結果を採点する仕組みです。人が触る前に、機械で挙動を確かめます。

先に成功の基準を決める

始める順番が決まっています。試験を作る前に、何をもって成功とするかを決めます。ここが曖昧だと、結果が出ても読めません。

基準は測れる形にします。「性能がよい」ではなく「振り分けの正答率が95%以上」と書きます。数値にできない基準は、判定の段でぶれます。

量と質のどちらを取るか

Anthropicの方針は明確です。自動採点であれば、多少精度が落ちても問いを多く用意するほうが、手作業で丁寧に採点する少数の試験よりよいとしています。

手作業は遅く、変更のたびには回せません。回せない試験は、しばらくすると誰も回さなくなります。

確かめられる範囲

押さえておきたい限界があります。試験で分かるのは、試験に含めた範囲の挙動だけです。通ったからといって、含めていない場面が正しいとは言えません。