LLM 평가: 공개 벤치마크에서 나만의 골든 세트까지

평가에 관한 거의 모든 논쟁은 서로 다른 것을 측정하는 두 사람의 대화입니다. 세 가지 프로젝트가 있고, 이들은 같은 도구를 공유하지 않습니다.

혼동은 한 방향으로 비쌉니다. leaderboard는 어떤 model이 대학원 수준 reasoning에 강하다고 말해줄 수는 있지만, 그 model이 당신의 지원 티켓을 routing할지는 말해줄 수 없습니다. 그리고 입력당 하나의 답을 채점하는 애플리케이션 평가는 agent를 전혀 볼 수 없습니다. agent에는 trajectory의 분포가 있고, 하나의 답은 그 분포에서 나온 단일 sample이기 때문입니다. Chapter 22는 그 세 번째 행에 이름을 붙이고 비워두었습니다. 성능 척도, 즉 agent specification에서 팀들이 가장 마지막에 쓰거나 아예 쓰지 않는 그 부분입니다.

순서도 중요하며, model을 파는 vendor도 그렇게 말합니다. OpenAI의 agent guide는 model 선택을 다음 세 단계로, 이 순서대로 줄입니다. "Set up evals to establish a performance baseline", "Focus on meeting your accuracy target with the best models available", "Optimize for cost and latency by replacing larger models with smaller ones where possible".¹ 평가는 먼저 옵니다. 숫자가 없으면 두 번째와 세 번째 단계는 의미가 없기 때문입니다.

golden set은 입력 목록이며, 각 입력에는 정답이 적혀 있고, 출력이 맞는지 판단하는 grader가 붙어 있습니다. 지루하고, 작고, 이 장에서 당신의 것이라고 부를 수 있는 유일한 artefact입니다. 여기서 만든 것은 다섯 개 파일이 있는 디렉터리에 대한 스무 개 작업으로 구성됩니다 — Chapter 23의 세 개가 아니므로 답도 같은 답이 아닙니다 — 그리고 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
];

두 속성이 하중을 지탱합니다. mustNot 목록이 존재하는 이유는 올바른 파일을 포함해 세 개의 파일 이름을 대는 model이 답한 것이 아니기 때문입니다. 그리고 answer는 pattern뿐 아니라 prose로도 작성됩니다. 나중에 인간과 judge가 둘 다 필요로 하기 때문입니다 — 그리고 같은 사실을 두 표기법으로 두 번 쓰는 것이, 애초에 그 작업이 무엇이었는지 스스로와 합의하지 못했다는 사실을 발견하는 방법입니다.

이제 결정하는 표입니다. 네 후보 시스템, 같은 스무 개 작업, 구간이 붙은 정확도, 그리고 정확도 표만으로는 항상 숨겨지는 두 열입니다.

승자를 보기 전에 구간을 읽으세요. arm B의 실행은 11%에서 47%까지 뻗고, arm A는 3%에서 30%까지 뻗습니다. 둘은 길이 대부분에서 겹칩니다. Chapter 4의 발견이 정확히 약속된 곳에 도착한 것입니다. 스무 개 case로는 네 시스템의 순위를 매길 수 없습니다. Chapter 15는 대신 paired 질문을 던져 이것을 더 날카롭게 만들었습니다 — 두 arm이 disagree하는 case들에서 split이 얼마나 한쪽으로 치우쳤는가? — set의 공통 난도가 상쇄되기 때문입니다. 모든 pair는 다음과 같습니다.

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

여섯 비교 중 하나도 확립되지 않았습니다. 최고의 arm은 tool이 전혀 없는 arm보다 15포인트 앞서지만, 그것이 기대고 있는 것은 discordant case 세 개뿐입니다. 스무 개 case는 mechanism을 보여줄 수는 있지만 supplier를 선택할 수는 없습니다. 회의에서 다르게 말하는 것이 나쁜 model을 사게 되는 방식입니다.

이 표가 확립하는 것이 하나 있긴 합니다. 아무도 넣지 않는 열입니다. arm D는 해결된 작업당 arm B보다 13배 비쌉니다. trajectory 세 개를 sampling하고 modal answer를 고르는 것은 정확도를 세 배로 만들든 아니든 청구서를 세 배로 만들기 때문입니다. 비용을 생략한 정확도 표는 이 trade-off를 보이지 않게 만듭니다.

이제 앞으로 보게 될 모든 benchmark를 읽는 방식을 바꾸는 발견입니다. 같은 200개 transcript — 스무 개 작업, 열 번 실행, token 하나도 재생성하지 않음 — 를 세 가지 방식으로 채점해 봅니다.

0, 13, 26. 시스템은 바뀌지 않았습니다. grader가 바뀌었습니다. exact match가 0을 반환하는 것은 agent가 쓸모없어서가 아니라, 자유 텍스트 답변이 reference와 byte 단위로 동일한 경우가 없기 때문입니다. 그것은 formatting을 측정하고 capability로 보고합니다.

이것은 호기심거리가 아니라 mechanism이며, 이름도 있습니다. hard-cutoff metric은 여러 sub-fact에 걸쳐 작업을 전부 아니면 전무로 채점하므로 복리처럼 누적됩니다. 작업 t12은 세 status code를 한 번에 묻습니다. 열 번 실행하면 다음과 같습니다.

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 정도 맞습니다. 세 개를 한 번에 모두 요구하면 score가 절반이 되고, $0.77^3 = 0.457$은 측정된 0.50에 충분히 가까워 하락이 어디서 왔는지 보여줍니다. 일반화하면 다음과 같습니다.

$k = 10$에서 0.90 행과 0.95 행을 비교해 읽어보세요. per-fact 5포인트 향상이 conjunction에서는 25포인트가 됩니다. model에 불연속적인 일이 일어난 것은 아닙니다. 전부 아니면 전무 metric을 통해 읽은 매끄러운 곡선이 jump처럼 보이는 것입니다 — 이것이 바로 Schaeffer, Miranda, Koyejo가 emergent ability에 대해 제기한 주장이고, Chapter 10이 여기로 미뤄둔 내용입니다.² 그들의 audit은 BIG-Bench가 선호한 39개 metric 중 최대 5개만이 emergence를 보이며, 두 개의 불연속 metric이 주장된 case의 92% 이상을 설명한다는 것을 발견했습니다.

따라서 규율은 한 줄입니다. 차트의 jump는 달리 입증되기 전까지 metric에 대한 증거입니다. capability가 나타났다고 믿기 전에, 같은 실행을 partial credit을 주는 metric으로 plot하고 cliff가 살아남는지 보세요.

여기에는 Kalai와 동료들이 upstream에 해를 끼치고 있다고 주장하는 2차 버전도 있습니다. 맞음/틀림으로 채점되는 benchmark는 "모르겠습니다"라고 말하는 것보다 추측을 보상하므로, 이에 맞춰 최적화된 model은 추측하는 법을 배웁니다. 그들이 제안한 해결책은 또 다른 hallucination benchmark가 아니라 "leaderboard를 지배하지만 misaligned된 기존 benchmark의 scoring을 수정하는 것"입니다.³ 당신의 golden set에도 같은 lever가 있고, 한 줄이면 됩니다. abstention을 실패로 셀지, 별도 category로 셀지 결정하세요. 대부분의 사람은 결정하지 않기 때문에, 그것은 조용히 실패로 계산되고, 그들이 ship하는 시스템은 추측합니다.

지금까지는 작업당 한 번의 시도만 채점했습니다. agent는 한 번의 시도가 아닙니다. Chapter 17은 temperature zero에서도 determinism이 없다는 점을 확립했습니다. 따라서 같은 입력은 trajectory의 분포를 만들고, 각 작업을 한 번만 실행하는 benchmark는 그 분포에서 나온 sample 하나를 보고합니다.

τ-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$개의 성공을 세면, unbiased estimator는 다음과 같습니다.

두 번째는 code generation에서 익숙한 pass@k입니다. $k$번의 시도 중 최소 하나가 성공할 확률입니다. 같은 측정 count를 나란히 놓으면 둘은 반대 방향으로 움직입니다.

같은 실행, 같은 grader, 같은 스무 개 작업입니다. 한 열은 시도가 늘수록 시스템이 좋아진다고 말하고, 다른 열은 나빠진다고 말합니다. 둘 다 맞습니다. 서로 다른 질문에 답하기 때문입니다. pass@k은 인간이 출력을 걸러볼 때 — code generation, draft, brainstorming — 그리고 추가 시도가 저렴할 때 올바른 metric입니다. pass^k은 agent가 filter 없이 행동할 때 올바른 metric이며, 그것이 "agent"가 의미하는 바입니다. 두 번째가 적용되는 곳에 첫 번째를 공개하는 것은 이 분야에서 가장 흔한 과장입니다. τ-bench 자체의 headline은 정직한 버전입니다. retail에서 gpt-4o는 대략 61% pass^1이지만 pass^8에서는 약 25%로 떨어집니다.⁴

이제 제 숫자 안의 따끔한 지점입니다. 제 스무 개 작업에서 pass^10는 5.0%입니다. 열 번 실행 모두에서 해결된 작업이 스무 개 중 정확히 하나라는 뜻입니다. 그 작업은 t19, *"Did deploy 42 succeed?"*이고, rubric이 correct로 채점한 열 개 답변 중 두 개는 다음과 같습니다.

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."

첫 번째는 답하지 않습니다. 두 번째는 거짓인 주장을 덧붙입니다 — deploy 41은 rollback되었습니다. 둘 다 /succe|yes/와 match했습니다. pass^10을 0 위에 붙들고 있는 유일한 작업은 grader artefact입니다. 따라서 진짜 수치는 0이고, 어떤 aggregate도 그것을 보여주지 않았을 것입니다. 가장 높은 점수를 받은 작업 뒤의 transcript를 sampling하는 곳이 grader가 죽으러 가는 곳입니다.

그리고 하나 더, 이 section의 이름이 된 숫자입니다. 동일한 평가 열 번 — 같은 시스템, 같은 스무 개 작업, 같은 코드, seed만 변경:

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

변하지 않은 시스템에서 30포인트 범위가 나옵니다. release 전 suite를 한 번, 후에 한 번 실행했다면, 8포인트 "개선"은 그 spread 안에 있고, 당신은 그것을 자신이 일으켰다고 믿으며 ship할 것입니다. 이것이 위의 pooled interval — 26.0 % [20.4, 32.5] — 을 단독으로 quote하기에 너무 좁은 이유입니다. 그것은 200개의 correlated trial을 200개의 independent trial처럼 취급합니다. agent 평가의 정직한 요약은 평균 그리고 반복 간 spread이며, 두 번째를 공개하는 사람은 거의 없습니다.

Rubric은 open-ended answer로 scale하지 않으므로, 표준적인 움직임은 model이 출력을 채점하게 하는 것입니다. frontier scale에서는 default가 될 만큼 충분히 잘 작동하고, 이름 붙은 세 가지 failure mode가 있습니다. position bias, verbosity bias, self-enhancement bias입니다.⁵

신뢰하기 전에 측정하세요. 같은 60개 답변 — 열 번 실행 중 세 번 — 을 세 방식으로 label했습니다. human label은 제 것입니다. 저는 다섯 파일을 열어둔 채 60개 모두를 읽고 하나의 written rule을 적용했습니다. 답변이 질문이 요구한 사실을 진술하고, 파일들과 모순되는 내용을 전혀 포함하지 않을 때 그리고 오직 그때만 pass.

judge는 60번 중 60번 PASS라고 말했습니다. human이 18%로 채점한 set에서 이 agent를 100% accuracy로 보고했을 것입니다. discriminative power가 없는 judge는 noisy instrument가 아닙니다. constant function이며, constant function은 최고의 시스템과 최악의 시스템에 같은 score를 줍니다.

Prompting으로도 구해지지 않았습니다. 네 variant, 같은 60개 item입니다.

지시문에서 두 label의 순서를 바꾸자 verdict 네 개가 움직였습니다. 측정 가능한 효과이고, 잘못된 종류의 효과입니다. judge가 눈앞의 답변이 아니라 prompt의 모양에 반응하고 있습니다.

깨끗한 시연은 pairwise입니다. 스무 개 질문, 각 질문마다 명백히 맞는 후보 하나와 명백히 틀린 후보 하나를 두 순서 모두로 제시했습니다.

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%는 부분적 competence가 아닙니다 — 산술입니다. correct answer가 정확히 절반의 trial에서 position A에 있기 때문입니다. 여기서 consistency는 MT-Bench가 정의한 대로, "the percentage of cases where a judge gives consistent results when swapping the order of two assistants"입니다. 그래서 비교가 apples to apples가 됩니다. GPT-4는 그 척도에서 65.0%를 기록하고, few-shot prompting은 그것을 77.5%로 끌어올렸습니다.⁵ 제 것은 0점입니다.

표준 mitigation도 그 논문에서 옵니다. "call a judge twice by swapping the order of two answers and only declare a win when an answer is preferred in both orders."⁵ 여기에 적용하면 judge는 스무 pair에서 usable verdict를 0개 만들어냅니다 — 이것이 올바른 결과이며, 자신감 넘치는 스무 verdict보다 무한히 낫습니다.

결과보다 더 가치 있는 방법론적 note. 저는 verbosity test도 실행했습니다. 같은 correct answer를 두고, 한 copy에는 아무것도 더하지 않는 36단어 문장을 덧붙였습니다. judge는 trial의 정확히 50%에서 더 긴 버전을 선호했습니다 — 이는 verbosity bias가 없는 것처럼 보이지만 전혀 그렇지 않습니다. 항상 position A를 고르는 judge는 어떤 balanced pairing에서도 50%를 기록하기 때문입니다. 첫 번째 bias가 통제되기 전에는 두 번째 bias를 측정할 수 없습니다. position을 바꾸는 것은 나중에 추가할 refinement가 아닙니다. 다른 모든 측정을 해석 가능하게 만드는 것입니다.

정직한 caveat: 이 judge는 5억 parameter model이고, 아무도 이런 것으로 채점해서는 안 됩니다. 요점은 judge가 나쁘다는 것이 아닙니다. 위 숫자를 만드는 데 8분이 들었고, 이 숫자들이 없었다면 이 judge의 shipping decision verdict는 100%였을 것이라는 점입니다.

이것은 course의 세 번째이자 마지막으로 선언된 Python 패널이고, 이유는 공개 숫자가 나오는 곳에 있습니다. lm-evaluation-harness는 "over 60 standard academic benchmarks for LLMs, with hundreds of subtasks and variants implemented"를 다루며, "the backend for Hugging Face's popular Open LLM Leaderboard"입니다. HELM, SWE-bench, τ-bench는 Python entry point가 있는 Python package입니다.⁶ 당신의 model을 published figure와 비교한다는 것은 그들의 코드를 실행한다는 뜻이고, 누군가가 인용한 숫자와 비교하고 싶은 날에는 다음 생태계 안에 있게 됩니다.

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

두 번째 이유는 이 장의 한 측정이 HTTP로는 불가능하기 때문입니다. Contamination — test set이 training data로 새어 들어간 것 — 은 공개 benchmark를 조용히 무의미하게 만드는 failure이고, 그것을 가장 날카롭게 probe하려면 model 자신의 loss가 필요합니다. chat API는 이를 반환하지 않습니다. 이것은 Chapter 8의 cross-entropy per token을 memory에 관한 질문에 겨눈 것입니다.

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)

열 개의 sentence pair입니다. 다섯 개는 웹이 존재한 이후 모든 crawl에 있었던 문장, 다섯 개는 오늘 아침 이 장을 위해 쓴 문장이고, 각각은 같은 내용을 담은 reworded version과 pair를 이룹니다.

model은 오늘 아침 쓰인 문장에 대해 백만 번 본 문장보다 네 배 더 놀라고, 유명한 문장에서는 rewording 비용이 두 배 더 큽니다 — 그 추가 비용이 이해된 부분이 아니라 암기된 부분입니다. absolute loss는 memorisation과 ordinary naturalness를 혼동시키므로 gap이 더 나은 statistic이고, continuation test는 더 낫습니다. 처음 여섯 단어를 줘보세요.

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."

유명한 string 다섯 개 중 세 개는 여섯 단어에서 word-perfect로 이어졌습니다. fresh 다섯 개 중 그렇게 된 것은 하나도 없었습니다. 이것은 5억 parameter model이 MIT License를 암송하는 장면입니다. benchmark가 공개 웹에 있다면, weights 안에 있다고 가정하세요. 이것은 또한 이 장 전체의 논거입니다. 당신이 자신의 data로 직접 작성하고 crawler가 읽는 어떤 repository에도 넣지 않은 golden set만이 train된 적 없다고 확신할 수 있는 유일한 test set입니다.

각 benchmark가 측정하는 것을 읽고, 붙어 있는 단일 숫자만 읽지 않는 한, 여전히 읽을 가치가 있습니다.

어떤 한 행보다 표 전체를 가져가세요. agentic benchmark는 모두 model보다 인간을 훨씬 위에 둡니다. 이는 knowledge benchmark와 반대이며, 이 분야가 어디에 있는지에 대한 최고의 한 줄 요약입니다. 그 수치는 몇 달 안에 낡으므로 읽은 날짜와 함께 인용하세요. 그리고 각각은 당신의 것이 아닌 task를 측정합니다.

Accuracy는 당신이 논쟁하는 metric입니다. 아래는 실제로 ship 여부를 결정하는 metric입니다. 네 가지 모두 이미 측정한 200개 실행에서 나옵니다.

call당 비용이 아니라 해결된 작업당 비용. agent는 attempt당 $0.001345가 들고, 실제로 해결된 task당 $0.005172가 듭니다 — 3.85배 더 큽니다. attempt의 4분의 3이 아무것도 만들어내지 못하기 때문입니다. Latency도 같은 방식으로 작동합니다. attempt당 1,213 ms, 해결된 task당 4,667 ms입니다. 모든 retry, 모든 re-ask, 모든 abandoned trajectory는 두 번째 숫자에 들어 있고 첫 번째에서는 보이지 않습니다.

accuracy를 이기는 diagnostic. 200개 attempt 중 123개에서 agent는 단 하나의 tool도 호출하지 않고 답했습니다 — 찾아본 것이 아니라 추측한 것입니다. 이를 기준으로 나누면 다음과 같습니다.

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%보다 더 가치 있습니다. 고쳐야 할 것을 이름 붙이기 때문입니다 — model이 reasoning에 실패하는 것이 아니라, 보러 가는 데 실패하고 있습니다 — 그리고 fix는 model이 아니라 harness 안에 있습니다. 이 장의 기준에 비추어 caveat 하나는 필요합니다. 두 group은 같은 task를 paired한 것이 아니라 서로 다른 task들이므로, 그 gap의 일부는 agent가 어렵다고 느끼는 질문에서 정확히 tool을 건너뛰기 때문일 수 있습니다. 이 split은 diagnostic이지 causal claim이 아닙니다.

Human intervention rate는 buyer가 가장 먼저 묻는 metric입니다. 실행 중 몇 퍼센트가 approval, guardrail, handoff에서 멈췄는가. Chapter 23의 typed interruption 덕분에 셀 수 있고, task type별 및 week별로 집계하면 자기 일을 배우는 agent와 조용히 queue가 되어가는 agent를 가르는 지표가 됩니다.

Abandonment는 offline suite가 볼 수 없는 metric입니다. 답을 읽고 tab을 닫은 뒤 스스로 작업을 처리한 user입니다. Offline evaluation은 gate이고, production evaluation은 같은 grader와 이 네 가지로 채점되는 실제 traffic의 continuous sample입니다.

그리고 Chapter 17에서 물려받은 규칙입니다. exact output에 assert하지 마세요. property에 assert하세요 — valid JSON, 올바른 schema, 호출된 올바른 tool, tolerance 안의 number, 필요한 substring present. 이 장 맨 위의 exact-match 열은 그 규칙을 어겼을 때 일어나는 일입니다.

supplier를 평가하는 것은 accuracy만의 문제가 아닙니다. 이것은 이 course 윤리의 후반부이며, appendix가 아니라 별도 heading을 가질 자격이 있습니다.

bias를 가정하지 말고 측정하세요. 이름, 방언, 성별, 국적에 대한 model의 행동에 대해 무엇을 믿든, 그것은 당신의 pipeline에서 측정 가능한 속성입니다. 도구는 이미 가지고 있습니다. golden set을 가져와 attribute만 바꾸고 paired로 비교하세요. HELM은 accuracy만 보고되던 곳에서 bias, toxicity, calibration, robustness도 판정 가능했기 때문에 존재합니다.⁸ vendor의 model card는 출발점이지, 당신의 입력에 대한 증거가 아닙니다.

Contamination도 supplier 질문입니다. 위의 probe는 공개된 숫자가 무엇으로, 그리고 model 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의 기본 30일 retention을 설명하며, "excludes customer content from abuse monitoring logs"인 Zero Data Retention과 지역 목록에 걸친 configurable data residency를 제공합니다.¹⁷

첫 production call 전에 서면으로 받아야 할 네 가지 질문이 있습니다. 각각 owner가 다르기 때문입니다. 내 data가 training에 사용되는가; 얼마나 오래, 누구에 의해 retained되는가; 어디에서 processed되고 stored되는가; 그리고 provider를 직접 쓰는 대신 reseller, gateway, aggregator를 쓰면 이 모든 것에 무슨 일이 생기는가. 마지막 질문에 대부분의 surprise가 숨어 있고, 어떤 benchmark도 그것을 말해주지 않습니다.

이제 당신에게는 도구가 있습니다. 당신이 소유한 golden set, 모든 숫자의 구간, 모든 비교를 위한 paired test, 아무에게도 보여주지 않은 실행을 위한 pass^k, 측정된 judge, 그리고 공개 score가 의미 있는지에 대한 probe입니다. 이제 Chapter 23의 closing claim — harness는 agent를 통제 가능하게 만들지만 올바르게 만들지는 않는다 — 은 주장되는 대신 확인될 수 있습니다. 그리고 그것을 확인하는 데 200번의 실행과 8분이 걸렸습니다.

이 모든 것이 측정하지 못하는 agent의 속성이 하나 있고, 그것이 사람들을 해고당하게 만듭니다.

이 장의 golden set에 있는 모든 작업은 제가 썼고, agent가 읽은 모든 파일도 제가 썼습니다. 그 directory 안의 어떤 것도 무엇인가를 하려고 하지 않았습니다. agent에게 읽으라고 한 파일 하나의 한 줄만 바꿔보세요 — 그 줄이 다음에 그것을 읽는 무엇에게 보내는 instruction으로 끝나도록 — 그러면 26%를 기록한 agent는 같은 tool, 같은 permission, 같은 clean trace로 그것을 따를 것이고, 이 장의 모든 숫자는 정확히 그대로 있을 것입니다. evaluation suite는 시스템이 당신의 목표에 얼마나 자주 도달하는지를 측정합니다. 다른 누군가가 자신의 목표로 얼마나 쉽게 바꿔치기할 수 있는지는 측정하지 않습니다.

Chapter 30이 바로 그것입니다. prompt injection, private data와 untrusted content와 external communication의 lethal trifecta, 그리고 agent에게 real permission을 주는 비용입니다. 이 장이 피하고 있던 관찰로 시작합니다 — 같은 passing score가, agent가 읽으라고 지시받은 파일에 attacker가 쓴 일을 정확히 수행하는 agent와도 양립한다는 점입니다.

위의 모든 숫자는 한 machine에서 생성되었고, paid endpoint에는 전혀 닿지 않았습니다. agent는 다섯 개 파일 directory에 대해 네 tool 중 두 개를 쓰는 Chapter 23의 loop입니다. port 뒤의 model은 Qwen/Qwen2.5-0.5B-Instruct이며, Chapter 23과 정확히 같은 chat completions endpoint 형태의 작은 server를 통해 노출되지만, 그 장의 CPU가 아니라 소비자용 GPU 하나에서 half precision으로 실행되었습니다. 비용은 Chapter 16의 rate — input token 100만 개당 $2.00, output 100만 개당 $12.00 — 를 측정된 token count에 적용했습니다. 반복 실행은 fixed seed와 temperature 0.7을 사용하므로 전체 set이 reproduce됩니다. four-arm table은 greedy입니다. 구간은 95% Wilson이고, paired comparison은 discordant pair에 대한 two-sided exact sign test입니다. Wilson interval은 Chapter 4의 것이고 exact paired sign test는 Chapter 15의 것이며, 둘 다 변경 없이 재사용했습니다. human label은 제 것이며, text에서 인용한 written rule에 따라 60개 답변에 적용했습니다. 여기의 모든 magnitude는 5억 parameter model의 속성으로 읽고, 모든 method는 transfer 가능한 것으로 읽으세요. 더 큰 model은 모든 숫자를 위로 옮기지만 어떤 도구도 옮기지 않습니다.