LLM評価：公開ベンチマークから自社のgolden setへ

評価をめぐる議論のほとんどは、2人が別々のものを測っているだけです。プロジェクトは3つあり、共有する計器はありません。

この混同は一方向に高くつきます。リーダーボードは、あるモデルが大学院レベルの推論に強いことは教えてくれますが、あなたのサポートチケットをroutingできるかは教えてくれません。また、入力ごとに1つの答えを採点するアプリケーション評価では、agentはまったく見えません。agentには軌跡の分布があり、1つの答えはそこからの単一サンプルにすぎないからです。第22章はこの3行目に名前を付け、空欄のままにしました。performance measure、つまりagent仕様のうち、チームが最後に、あるいはまったく書かない部分です。

順序も重要であり、モデルを売るvendor自身もそう言っています。OpenAIのagent guideは、モデル選択を次の3ステップに、この順序で縮約しています。「performance baselineを確立するためにevalsを設定する」「利用可能な最良のモデルでaccuracy targetを満たすことに集中する」「可能なところで大きなモデルを小さなモデルに置き換え、コストとlatencyを最適化する」。¹ Evaluationが最初です。数字がなければ、ステップ2と3は意味を持たないからです。

golden setとは、入力のリストであり、それぞれに答えが書かれ、出力が一致するかを判定するgraderが付いているものです。退屈で、小さく、この章で唯一あなた自身のartefactです。ここで作るものは、5ファイルのディレクトリに対する20個のタスクです。第23章の3個ではないので、答えも同じではありません。そしてgraderはagentを走らせる前に書かれます。

export type Task = {
  id: string;
  prompt: string;
  answer: string;          // the fact, in words, for a human and for a judge
  must: RegExp[];          // ALL must match the final answer
  mustNot?: RegExp[];      // NONE may match
};

export const GOLDEN: Task[] = [
  { id: "t04", prompt: "Which file is the largest?", answer: "access.log",
    must: [/access\.log/i], mustNot: [/errors\.log/i, /notes\.txt/i] },       
  { id: "t12", prompt: "Which HTTP status codes appear in access.log? List all of them.",
    answer: "200, 429 and 500", must: [/200/, /429/, /500/] },                
  // ...eighteen more
];

2つの性質が要です。mustNotリストが存在するのは、正しいファイルを含めて3つのファイル名を挙げるモデルは、答えたことにならないからです。そしてanswerはpatternだけでなく散文でも書かれています。人間とjudgeの両方があとで必要とするからです。同じ事実を2つの記法で2回書くことは、自分がそのタスクとは何かについて自分自身と合意していなかったことを発見する方法です。

では、判断する表です。4つの候補system、同じ20タスク、区間付きaccuracy、そしてaccuracyだけの表が必ず隠してしまう2つの列です。

勝者を見る前に区間を読んでください。arm Bの実行は11%から47%まで広がります。arm Aは3%から30%です。両者は長さの大部分で重なっています。これは第4章の発見が、約束された場所にそのまま到着したものです。20件では4つのsystemをrank付けできません。第15章は、代わりにpairedな問いを立てることでこれを鋭くしました。2つのarmが不一致になるcaseでは、分割はどれだけ偏っているか。setの共通の難しさが相殺されるからです。全ペアは次のとおりです。

A vs B  +0 / -3   p = 0.2500       B vs C  +4 / -1   p = 0.3750
A vs C  +2 / -2   p = 1.0000       B vs D  +4 / -0   p = 0.1250
A vs D  +2 / -1   p = 1.0000       C vs D  +1 / -0   p = 1.0000

6つの比較のうち、確立されたものは1つもありません。 最良のarmはtoolsをまったく持たないarmを15ポイント上回っていますが、その根拠は3つのdiscordant caseです。20件は仕組みを示すことはできますが、supplierを選ぶことはできません。会議でそれ以外のことを言うのは、悪いモデルが買われる経路です。

この表が1つだけ確立していることがあります。それは誰も表に入れない列です。arm Dはsolved taskあたりでarm Bの13倍かかります。3つの軌跡をsamplingしてmodal answerを取ると、accuracyが3倍になろうがなるまいが請求は3倍になるからです。コストを省いたaccuracy表は、このtrade-offを見えなくします。

ここからは、今後目にするあらゆるbenchmarkの読み方を変える発見です。同じ200本のtranscript――20タスク、10回実行、tokenを1つも再生成していない――を3通りで採点します。

ゼロ、13、26。systemは変わっていません。graderが変わったのです。Exact matchがゼロを返すのは、agentが役に立たないからではありません。自由記述の答えがreferenceとbyte単位で同一になることはないからです。これはformattingを測り、それをcapabilityとして報告します。

これは珍事ではなく、仕組みであり、名前があります。hard-cutoff metricは、複数のsub-factを含むタスクをall-or-nothingで採点するため、複利のように効きます。タスクt12は3つのstatus codeを同時に尋ねます。10回の実行では次のようになりました。

per-code presence   200: 9/10    429: 6/10    500: 8/10    (mean 0.77 per fact)
all three at once   5/10

各factは約4分の3の確率で正しい。しかし3つすべてを同時に要求するとscoreは半分になり、$0.77^3 = 0.457$は測定値0.50に十分近く、落ち込みの由来を示しています。一般化するとこうです。

$k = 10$で0.90行と0.95行を比べてください。per-factの5ポイント改善が、conjunctionでは25ポイントになります。モデルに不連続な出来事が起きたわけではありません。all-or-nothing metricを通して滑らかな曲線を読むと、jumpのように見えるのです。これはまさにSchaeffer、Miranda、Koyejoがemergent abilitiesについて行った議論であり、第10章がここに先送りしたものです。² 彼らのauditでは、BIG-Benchの39個のpreferred metricsのうち、emergenceを示すものは多くても5個で、主張されたcaseの92%以上は2つの不連続metricで説明されました。

したがって、規律は1行で言えます。chartのjumpは、そうでないと示されるまではmetricについての証拠です。 capabilityが現れたと信じる前に、同じrunをpartial creditを与えるmetricでplotし、その崖が残るかを見てください。

これには2次のversionもあり、Kalaiらは、それが上流で害を生んでいると論じています。正誤で採点されるbenchmarkは「分からない」と言うより推測を報酬するため、それに対して最適化されたモデルは推測を学びます。彼らが提案する修正は、別のhallucination benchmarkではなく、「リーダーボードを支配しているがmisalignedな既存benchmarkの採点を変更する」ことです。³ あなたのgolden setにも同じleverがあり、1行で済みます。abstentionを失敗と数えるのか、独自categoryと数えるのかを決めることです。ほとんどの人は決めないので、黙って失敗として数えられ、出荷されるsystemは推測します。

ここまでは、タスクごとに1回のattemptを採点してきました。agentは1回のattemptではありません。第17章で確認したように、temperature zeroでもdeterminismはありません。同じ入力は軌跡の分布を生み、各タスクを1回だけ走らせるbenchmarkは、そこからの1サンプルを報告しているだけです。

τ-benchの貢献は、そのためのmetricです。論文は明快に定義しています。「we propose a new metric – pass^k (pass hat k), defined as the chance that all k i.i.d. task trials are successful, averaged across tasks」。⁴ 各タスクを$n$回走らせ、成功数$c$を数えると、不偏推定量は次のようになります。

2つ目はcode generationでおなじみのpass@kです。$k$回のattemptのうち少なくとも1回成功する確率です。同じ測定countで並べると、両者は反対方向に動きます。

同じrun、同じgrader、同じ20タスクです。一方の列はattemptを増やすとsystemが良くなると言い、もう一方は悪くなると言います。そしてどちらも正しい。答えている問いが違うからです。人間が出力をfilterする場合――code generation、draft、brainstorming――で、追加attemptが安いなら、pass@kが正しいmetricです。agentがfilterなしに行動する場合、つまり「agent」が意味するものの場合には、pass^kが正しいmetricです。後者が当てはまるところで前者を公開することは、この分野で最も一般的な誇張です。そしてτ-bench自身のheadlineは正直なversionです。retailでgpt-4oはおよそ61%のpass^1から、pass^8では約25%まで落ちます。⁴

では、私自身の数字の痛点です。20タスクに対するpass^10は5.0%です。10回すべてで解かれたタスクは20個中ちょうど1つ。そのタスクはt19、*「deploy 42は成功したか？」*です。そしてrubricが正解と採点した10個の答えのうち2つがこれです。

run 2  "To check if 'deploy.log' succeeded in deploying 42, I will list the file
        names in the working directory using the list_files function..."
run 8  "Yes, deploy 42 has successfully deployed. Deploying was successful for 41
        as well."

1つ目は答えていません。2つ目は誤ったclaimを追加しています――deploy 41はrollbackされていました。どちらも/succe|yes/にmatchしました。pass^10をゼロより上に支えている唯一のタスクはgrader artefactなので、真の値はゼロです。そしてaggregateだけではそれは分かりませんでした。最高scoreのタスクの裏にあるtranscriptをsamplingする場所こそ、graderが死ぬ場所です。

もう1つ、このsectionの名前になっている数字です。10回の同一evaluation――同じsystem、同じ20タスク、同じcode、変えたのはseedだけ――です。

per-run correct: 5 2 5 5 8 5 8 5 4 5   ->  10 % .. 40 %,  mean 26.0 %,  sd 8.8 points

変わっていないsystemで30ポイントの範囲です。release前にsuiteを1回、release後に1回走らせた場合、8ポイントの「改善」はこの広がりの中にあり、あなたは自分が原因だと信じて出荷するでしょう。これが、上のpooled interval――26.0% [20.4, 32.5]――だけをquoteするには狭すぎる理由です。200個の相関したtrialを200個の独立trialとして扱っているからです。agent評価の正直なsummaryは、平均とrepeat間のspreadです。そしてほとんど誰も2つ目を公開しません。

Rubricはopen-ended answerにはscaleしないため、標準的な手はモデルに出力を採点させることです。frontier scaleではdefaultになる程度にはうまく機能しますが、3つの名前付きfailure modeがあります。position bias、verbosity bias、self-enhancement biasです。⁵

信頼する前に測ってください。同じ60個のanswer――10回のrunのうち3回分――を3通りでlabelしました。human labelは私のものです。5つのファイルを開いたまま60個すべてを読み、1つの書かれたruleを適用しました。answerが質問されたfactを述べており、かつファイルと矛盾するものを含まない場合に限りpass。

judgeはPASSを60回中60回言いました。humanが18%と採点するsetで、このagentを100% accuracyと報告していたでしょう。識別力のないjudgeはnoisy instrumentではありません。constant functionです。そしてconstant functionは、最良のsystemにも最悪のsystemにも同じscoreを与えます。

Promptingでも救えませんでした。4つのvariant、同じ60 itemsです。

instruction内の2つのlabelの順序を入れ替えただけで、4つのverdictが動きました。これは測定可能な効果であり、悪い種類の効果です。judgeは目の前のanswerではなく、promptの形に反応しています。

明快なデモはpairwiseです。20の質問について、明らかに正しいcandidateと明らかに間違ったcandidateを1つずつ用意し、両方の順序で提示します。

picked the FIRST option              40/40 = 100.0 %
order-consistent (same winner both ways)   0/20 = 0.0 %   [Wilson 0.0, 16.1]
picked the CORRECT answer            20/40 = 50.0 %

40回中40回、position Aを選びました。correctnessの50%は部分的な能力ではありません。算術です。正解がちょうど半分のtrialでposition Aに置かれているからです。ここでのconsistencyはMT-Benchの定義に従います。「2人のassistantの順序を入れ替えたとき、judgeがconsistentな結果を出すcaseの割合」です。これにより比較はapples to applesになります。GPT-4はこのmeasureで65.0%、few-shot promptingで77.5%まで上がりました。⁵ 私のものはゼロです。

標準的なmitigationも同じ論文から来ています。「2つのanswerの順序を入れ替えてjudgeを2回呼び、両方の順序でanswerがpreferされた場合にだけwinを宣言する」。⁵ ここに適用すると、judgeは20ペアからusable verdictをゼロ生成します。これは正しい結果であり、20個の自信満々なverdictより無限にましです。

結果そのものより価値のあるmethodological noteがあります。verbosity testも実行しました。同じ正しいanswerを2つ用意し、一方には何も追加しない36語のsentenceをpaddingしました。judgeは長いversionをtrialのちょうど50%でpreferしました。verbosity biasがないように見えますが、まったくそうではありません。position Aを常に選ぶjudgeは、どんなbalanced pairingでも50%をscoreするからです。最初のbiasをcontrolするまでは、2つ目のbiasを測れません。 positionをswapすることは、あとで加えるrefinementではありません。他のすべてのmeasurementを解釈可能にするものです。

正直なcaveatです。このjudgeは5億parameterのモデルであり、誰もこれで採点すべきではありません。要点はjudgeが悪いということではありません。上の数字を出すのに8分しかかからず、それがなければこのjudgeのshipping decisionに対するverdictは100%だった、ということです。

これはcourseで宣言している3つ目で最後のPythonパネルです。理由は公開数字がどこから来るかにあります。lm-evaluation-harnessは「LLM向けの60を超える標準的なacademic benchmarksを、数百のsubtaskとvariantの実装とともに」coverし、「Hugging Faceの人気Open LLM Leaderboardのbackend」です。HELM、SWE-bench、τ-benchはPython entry pointを持つPython packageです。公開figureに対して自分のモデルを走らせるとは、彼らのcodeを走らせるということです。そして誰かが引用した数字と比較したい日、あなたがいるecosystemはここです。

lm_eval --model hf \
    --model_args pretrained=EleutherAI/gpt-j-6B \
    --tasks hellaswag \
    --device cuda:0 \
    --batch_size 8

2つ目の理由は、この章の1つの測定がHTTP越しには不可能だからです。Contamination――test setがtraining dataへ漏れていること――は公開benchmarkを黙って無意味にするfailureであり、その最も鋭いprobeにはモデル自身のlossが必要です。chat APIはそれを返しません。これは第8章のcross-entropy per tokenを、記憶に関する問いへ向けたものです。

def nll(text: str) -> float:
    """Mean negative log-likelihood per token, in nats."""
    ids = tok(text, return_tensors="pt").input_ids.to(model.device)
    with torch.no_grad():
        out = model(ids, labels=ids)
    return float(out.loss)

10組のsentence pairです。5つはwebが存在して以来あらゆるcrawlに入っているもの、5つは今朝この章のために書いたものです。それぞれに、同じ内容を持つ言い換えversionを組み合わせています。

モデルは、今朝書かれたsentenceに対して、何百万回も見たsentenceの4倍驚いています。そして有名なものでは、言い換えのcostが2倍です。その追加costが、理解ではなく記憶されていた部分です。absolute lossはmemorisationと通常の自然さを混同するため、gapのほうが良いstatisticであり、continuation testはさらに良いものです。最初の6語を与えます。

famous  "Permission is hereby granted, free of"
     -> "charge, to any person obtaining a copy of this software and associated
         documentation files (the "
famous  "All human beings are born free"
     -> "and equal in dignity and rights. The right to life, liberty, and security"
fresh   "All evaluation harnesses are born tiny"
     -> ", and the most common way to measure their size is by using a ruler."

有名な5つのstringのうち3つは、6語からword-perfectに続きました。freshな5つではゼロでした。これは5億parameterのモデルがMIT Licenseを暗唱しているということです。あなたのbenchmarkがpublic webにあるなら、それはweightsの中にあると仮定してください。 これはこの章全体の論点でもあります。自分のdataから自分で書き、crawlerが読むrepositoryの外に置いたgolden setだけが、trainingされていないと確信できる唯一のtest setです。

それでも読む価値はあります。ただし、各benchmarkが何を測っているかを読み、そこに付いた単一の数字だけを読まない限りです。

個々の行ではなく表を受け取ってください。agentic benchmarkではすべてhumanがmodelを大きく上回っており、これはknowledge benchmarkとは逆です。そしてこの分野がどこにいるかを示す最高の1行summaryです。数字は数か月で古くなるので、引用するときは読んだ日付を添えてください。そしてどれも、あなたのタスクではないタスクを測っています。

Accuracyはあなたが議論するmetricです。こちらは、それがshipされるかを決めるmetricです。4つすべては、すでに測定した200 runから出ます。

callあたりではなく、solved taskあたりのコスト。 agentはattemptあたり$0.001345、そして実際に解けたtaskあたり$0.005172かかります。3.85倍です。attemptの4分の3は何も生まないからです。Latencyも同じです。attemptあたり1,213 ms、solved taskあたり4,667 ms。すべてのretry、すべてのre-ask、すべてのabandoned trajectoryは2つ目の数字に載り、1つ目では見えません。

accuracyに勝るdiagnostic。 200 attempt中123回、agentはtoolを1つも呼ばずに答えました。調べずに推測したのです。そこで分けるとこうなります。

answered without reading anything   8/123  =  6.5 %  [3.3, 12.3]
answered after reading something   44/77   = 57.1 %  [46.0, 67.6]

区間は近づきもしません。これはaggregateの26%より価値があります。直すべきものに名前を付けているからです。モデルはreasoningに失敗しているのではありません。見ることに失敗しています。そして修正はモデルではなくharnessにあります。この章自身のstandardに照らしたcaveatを1つ。2つのgroupは同じtaskのpairedではなく、異なるtaskです。したがってgapの一部は、まさに難しいと感じた質問でtoolsをskipしていることによるかもしれません。このsplitはdiagnosticであり、causal claimではありません。

Human intervention rateはbuyerが最初に尋ねるmetricです。runの何割がapproval、guardrail、handoffで止まったか。第23章のtyped interruptionsにより数えられます。task typeごと、週ごとに数えることで、仕事を学んでいるagentと、静かにqueueへ変わっているagentを分けます。

Abandonmentはoffline suiteでは見えないmetricです。answerを読み、tabを閉じ、自分でtaskを行ったuserです。Offline evaluationはgateです。production evaluationはreal trafficのcontinuous sampleであり、同じgraderにこの4つを加えて採点します。

そして第17章から継承したruleです。exact outputにassertしてはいけません。 propertyにassertしてください。valid JSON、正しいschema、正しいtoolが呼ばれたこと、tolerance内のnumber、必須substringの存在です。この章の冒頭にあったexact-match列は、そのruleを破ったときに起きることです。

supplierの評価はaccuracyだけの話ではありません。これはこのcourseのethicsの後半であり、appendixではなく独自のheadingを持ちます。

biasは仮定せず、測る。 名前、方言、gender、nationalityに関するモデルの挙動について何を信じていようと、それはあなたのpipelineの測定可能なpropertyです。そして計器はすでにあります。golden setを取り、attributeだけを変え、pairedで比較します。HELMが存在するのはまさに、bias、toxicity、calibration、robustnessも決定可能である場面でaccuracyだけが報告されていたからです。⁷ vendorのmodel cardは出発点であり、あなたの入力に関する証拠ではありません。

Contaminationもsupplierへの質問です。 上のprobeは、公開数字が何で測られたのか、そしてモデルのdata cutがいつだったのかを尋ねる理由です。

Retention、training、residency。2026年9月7日に読んだもの。 これらは変わるため、答えの横に日付を記録してください。Anthropicのpolicy pageはこう述べています。「By default, we will not use your inputs or outputs from our commercial products (e.g. Claude for Work, Anthropic API, Claude Gov, etc.) to train our models」。例外は、明示的にfeedbackとして提出したcontentであり、それは「for up to 5 years」保存されます。¹⁵ OpenAIのdata controls documentationは、「data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)」と述べ、abuse-monitoring logのdefault 30日retentionを説明し、customer contentをabuse monitoring logから除外するZero Data Retentionと、region listにわたるconfigurable data residencyを提供しています。¹⁶

最初のproduction callの前に、書面で取るべき質問は4つです。それぞれownerが異なるからです。自分のdataはtrainingに使われるのか。どれくらい保持され、誰が保持するのか。どこで処理され、保存されるのか。providerを直接使わず、reseller、gateway、aggregatorを使った場合、そのすべてに何が起きるのか。最後の1つに、ほとんどの驚きが潜んでいます。そしてどんなbenchmarkもそれを教えてくれません。

これでinstrumentは揃いました。自分が所有するgolden set、すべての数字に付く区間、すべての比較に対するpaired test、誰にも見せなかったrunのためのpass^k、測定済みのjudge、そして公開scoreが意味を持つかを調べるprobeです。第23章の最後のclaim――harnessはagentをgovernableにするがcorrectにはしない――は、主張ではなく確認できるようになりました。そして確認には200 runと8分がかかりました。

それでも、これらのどれも測らないagentのpropertyが1つあります。そしてそれこそが人を解雇に追い込むものです。

この章のgolden setにあるすべてのtaskは私が書き、agentが読んだすべてのfileも私が書きました。そのdirectory内のものは、何かをしようとしていたわけではありません。agentが読むよう指示されたfileの1行を変えてください――次にそれを読むものへ宛てたinstructionで終わる1行です。26%をscoreしたagentは、同じtools、同じpermissions、同じclean traceでそれに従い、この章のすべての数字はまったく同じ場所に留まります。evaluation suiteは、systemがあなたのgoalに到達する頻度を測ります。誰か別の人が自分のgoalにすり替えるのがどれほど簡単かは測りません。

第30章はそれです。prompt injection、private data、untrusted content、external communicationのlethal trifecta、そしてagentに実際のpermissionを与えるcostです。この章が避けてきた観察から始まります。同じpassing scoreは、読めと言われたfileにattackerが書いたことをそのまま実行するagentとも両立する、という観察です。

上のすべての数字は1台のmachineで生成され、有料endpointには一切触れていません。agentは第23章のループで、5ファイルのdirectoryに対して4つのtoolsのうち2つを使います。portの背後にあるモデルはQwen/Qwen2.5-0.5B-Instructで、第23章とまったく同じchat completions endpointの形をした小さなserverを通じて公開しています。ただし、その章のCPUではなく、consumer GPU 1枚でhalf precisionです。コストは第16章のrates――input tokens 100万あたり$2.00、output 100万あたり$12.00――を、測定したtoken countに適用しています。repeated runsはtemperature 0.7、fixed seedsで、set全体が再現されます。four-arm tableはgreedyです。Intervalsは95%のWilson、paired comparisonsはdiscordant pairsに対するtwo-sided exact sign testsです。Wilson intervalは第4章、exact paired sign testは第15章のものを、そのまま再利用しています。human labelsは私のもので、本文に引用したwritten ruleの下で60 answerに適用しました。ここでのあらゆる大きさは5億parameterモデルのpropertyとして読み、あらゆるmethodはtransferableとして読んでください。より大きなモデルはすべての数字を上げますが、instrumentは1つも動かしません。