Оценка LLM: от публичных benchmarks до вашего golden set

Почти каждый спор об оценке — это два человека, измеряющие разные вещи. Есть три проекта, и у них нет общего инструмента.

Путаница дорого обходится в одном направлении. Leaderboard говорит, что модель сильна в рассуждениях уровня магистратуры; он не может сказать, будет ли она маршрутизировать ваши тикеты поддержки. А оценка приложения, которая scoring один ответ на один input, вообще не видит agent, потому что у agent есть распределение траекторий, а один ответ — это один sample из него. Глава 22 назвала эту третью строку и оставила её пустой: мера производительности, та часть спецификации agent, которую команды записывают последней или не записывают никогда.

Порядок тоже важен, и поставщик, продающий вам модель, говорит то же самое. Руководство OpenAI по agent сводит выбор модели к трём шагам, именно в таком порядке: "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 — это список inputs, у каждого из которых записан ответ, и grader, решающий, совпадает ли output. Он скучный, маленький, и это единственный артефакт в этой главе, который принадлежит вам. Построенный здесь набор содержит двадцать задач по каталогу из пяти файлов — не три файла из главы 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 существует потому, что модель, назвавшая три файла, среди которых есть правильный, не ответила на вопрос. А answer записан и прозой, и patterns, потому что позже он понадобится и человеку, и judge — и запись одного и того же факта дважды в двух нотациях показывает, что вы сами с собой не договорились о том, чем была задача.

Теперь таблица, которая решает. Четыре системы-кандидата, те же двадцать задач, accuracy с интервалом и две колонки, которые таблица одних accuracy всегда скрывает:

Читайте интервалы раньше, чем победителя. У arm B разброс от 11 % до 47 %; у arm A — от 3 % до 30 %. Они перекрываются почти по всей длине, и это вывод главы 4, пришедший ровно туда, куда было обещано: двадцать случаев не могут ранжировать четыре системы. Глава 15 уточнила это, задав вместо этого парный вопрос: среди случаев, где два arms расходятся, насколько перекошен счёт? — потому что общая сложность набора сокращается. Вот каждая пара:

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 опережает arm без инструментов на пятнадцать пунктов, и всё это держится на трёх discordant случаях. Двадцать случаев показывают механизм и не могут выбрать поставщика; утверждать обратное на встрече — хороший способ купить плохую модель.

Есть одна вещь, которую эта таблица действительно устанавливает, и это колонка, которую никто не вставляет. Arm D стоит в тринадцать раз дороже arm B за решённую задачу, потому что sampling трёх траекторий и выбор modal answer утраивает счёт независимо от того, утраивает ли accuracy. Таблицы accuracy без стоимости делают этот компромисс невидимым.

Теперь вывод, который меняет то, как вы будете читать любой benchmark. Возьмите те же самые двести transcripts — двадцать задач, десять запусков, ни один token не сгенерирован заново — и оцените их тремя способами:

Ноль, тринадцать, двадцать шесть. Система не изменилась. Изменился grader. Exact match возвращает ноль не потому, что agent бесполезен, а потому что свободный текстовый ответ никогда не совпадает с эталоном байт-в-байт: он измеряет форматирование и выдаёт его за способность.

Это не курьёз, а механизм, и у него есть название. Метрика с жёстким порогом оценивает задачу по нескольким подфактам как всё-или-ничего, поэтому эффект перемножается. Задача t12 просит сразу три status codes. За десять запусков:

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

Каждый факт верен примерно в трёх четвертях случаев; требование всех трёх сразу режет score вдвое, и $0.77^3 = 0.457$ достаточно близко к измеренным 0.50, чтобы показать, откуда взялось падение. Обобщим:

Сравните строку 0.90 со строкой 0.95 при $k = 10$: улучшение per-fact на пять пунктов превращается в двадцать пять пунктов на conjunction. С моделью не произошло ничего дискретного. Гладкая кривая, прочитанная через метрику всё-или-ничего, выглядит как скачок — именно этот аргумент Schaeffer, Miranda и Koyejo выдвинули про emergent abilities, и именно сюда глава 10 его отложила.² Их аудит показал, что максимум 5 из 39 preferred metrics BIG-Bench вообще демонстрируют emergence, причём две discontinuous metrics отвечают более чем за 92 % заявленных случаев.

Итак, дисциплина в одну строку: скачок на графике — это свидетельство о метрике, пока не доказано обратное. Прежде чем поверить, что появилась способность, построите те же runs с метрикой, которая даёт partial credit, и посмотрите, сохранится ли обрыв.

Есть версия второго порядка, которая, по аргументу Kalai и коллег, наносит вред выше по течению: benchmarks, оцениваемые как right-or-wrong, вознаграждают угадывание вместо ответа "я не знаю", поэтому модель, оптимизированная под них, учится угадывать. Их предложенное исправление — не ещё один hallucination benchmark, а "modifying the scoring of existing benchmarks that are misaligned but dominate leaderboards".³ У вашего golden set есть тот же рычаг, и это одна строка: решите, считается ли abstention провалом или отдельной категорией. Большинство людей никогда этого не решает, поэтому он молча считается провалом, а система, которую они shipping, угадывает.

До сих пор мы оценивали одну попытку на задачу. Agent — это не одна попытка. Глава 17 установила, что у вас нет детерминизма даже при temperature zero, поэтому один и тот же input порождает распределение траекторий, а benchmark, запускающий каждую задачу один раз, сообщает один sample из него.

Вклад τ-bench — метрика для этого. Статья определяет её прямо: "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$ successes, и несмещённые estimators будут такими:

Второй — знакомый pass@k из code generation: шанс, что хотя бы одна из $k$ попыток успешна. Поставьте их рядом на одних и тех же измеренных counts, и они пойдут в противоположные стороны:

Те же runs, тот же grader, те же двадцать задач. Одна колонка говорит, что система улучшается с большим числом попыток, другая — что становится хуже, и обе правы, потому что отвечают на разные вопросы. pass@k — правильная метрика, когда человек фильтрует output: code generation, черновики, brainstorming, — а дополнительные попытки дёшевы. pass^k — правильная метрика, когда agent действует без фильтра, что и означает "agent". Публиковать первую там, где применима вторая, — самое распространённое преувеличение в этой области, и собственный headline τ-bench честен: gpt-4o примерно с 61 % pass^1 на retail падает примерно до 25 % при pass^8.⁴

Теперь неприятный укол в моих собственных числах. pass^10 по моим двадцати задачам — 5.0 %: ровно одна задача из двадцати решена во всех десяти runs. Эта задача — 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 был rolled back. Оба совпали с /succe|yes/. Единственная задача, удерживающая pass^10 выше нуля, — artefact grader, значит истинная цифра — ноль, и никакой aggregate мне бы этого не показал. Sampling transcripts за вашей задачей с лучшим score — место, где graders умирают.

И ещё одно число, в честь которого назван этот раздел. Десять идентичных оценок — та же система, те же двадцать задач, тот же код, ничего не менялось, кроме seeds:

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

Диапазон в тридцать пунктов у системы, которая не менялась. Если вы запустите suite один раз до релиза и один раз после, "улучшение" на восемь пунктов окажется внутри этого разброса, и вы отправите релиз, веря, что это вы его вызвали. Поэтому pooled interval выше — 26.0 % [20.4, 32.5] — слишком узок, чтобы цитировать его отдельно: он трактует двести correlated trials как двести independent ones. Честное резюме оценки agent — это среднее и разброс по repeats, а второе почти никто не публикует.

Rubrics плохо масштабируются на открытые ответы, поэтому стандартный ход — поручить модели grading output. На frontier scale это работает достаточно хорошо, чтобы быть default, и у него есть три именованных режима отказа: position bias, verbosity bias и self-enhancement bias.⁵

Измерьте это, прежде чем доверять. Одни и те же шестьдесят ответов — три из десяти runs — были размечены тремя способами. Human label — мой: я прочитал все шестьдесят с открытыми пятью файлами и применил одно письменное правило: pass тогда и только тогда, когда ответ утверждает факт, о котором спрашивал вопрос, и не содержит ничего, что противоречит файлам.

Judge сказал PASS шестьдесят раз из шестидесяти. Он сообщил бы 100 % accuracy для этого agent на наборе, где человек оценивает его в 18 %. Judge без discriminative power — не шумный инструмент; это constant function, а constant function даёт вашей лучшей системе и худшей системе один и тот же score.

Prompting не спас. Четыре варианта, те же шестьдесят items:

Перестановка порядка двух labels в инструкции сдвинула четыре verdicts. Это измеримый эффект, и эффект неправильного типа: judge реагирует на форму prompt, а не на ответ перед ним.

Чистая демонстрация — pairwise. Двадцать вопросов, у каждого один явно правильный и один явно неправильный candidate, показанные в обоих порядках:

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 %

Он выбрал позицию A сорок раз из сорока. 50 % по correctness — не частичная компетентность, а арифметика, потому что правильный ответ находится в позиции A ровно в половине trials. 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 %.⁵ Мой получает ноль.

Стандартная 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 выдаст ноль usable verdicts из двадцати пар — это правильный outcome и бесконечно лучше двадцати уверенных.

Методологическое замечание, стоящее больше результата. Я также провёл verbosity test: тот же правильный ответ, одна копия дополнена предложением из 36 слов, которое ничего не добавляет. Judge предпочёл более длинную версию ровно в 50 % trials — это выглядит как отсутствие verbosity bias и вообще им не является, потому что judge, который всегда выбирает позицию A, получает 50 % на любой сбалансированной паре. Нельзя измерять второй bias, пока первый не взят под контроль. Перестановка позиций — не refinement, который добавляют позже; это то, что делает любое другое измерение интерпретируемым.

Честная оговорка: этот judge — модель на полмиллиарда parameters, и никому не следует grading с такой. Суть не в том, что judges плохи. Суть в том, что числа выше стоили восьми минут, а без них verdict этого judge по shipping decision был бы 100 %.

Это третья и последняя объявленная 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 packages с Python entry points.⁶ Прогнать вашу модель против опубликованной цифры значит запустить их код, и в день, когда вы захотите сравнить себя с числом, на которое кто-то сослался, вы окажетесь именно в этой ecosystem:

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 — это failure, из-за которого публичный benchmark молча теряет смысл, а самый острый probe для неё требует собственный loss модели, который не возвращает ни один chat API. Это cross-entropy per token из главы 8, направленная на вопрос о памяти:

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)

Десять пар предложений: пять — в каждом crawl веба с момента его существования, пять написаны сегодня утром для этой главы, и к каждому подобрана переформулировка с тем же содержанием.

Модель в четыре раза сильнее удивляется предложению, написанному сегодня утром, чем предложению, которое она видела миллион раз, а rewording обходится вдвое дороже на famous ones — дополнительная стоимость и есть та часть, которая была запомнена, а не понята. Absolute loss смешивает memorisation с обычной 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."

Три из пяти famous strings продолжились word-perfect с шести слов; ни одна из пяти fresh ones — нет. Это модель на полмиллиарда parameters, декламирующая MIT License. Если ваш benchmark есть в публичном вебе, считайте, что он уже в weights. Это также аргумент в пользу всей главы: golden set, который вы написали из собственных данных и держите вне любого repository, читаемого crawler, — единственный test set, о котором вы можете быть уверены, что на нём никогда не training.

Их всё ещё стоит читать, если читать то, что измеряет каждый из них, а не одно число, прикреплённое к нему.

Читайте таблицу, а не отдельную строку. Все agentic benchmarks ставят людей намного выше моделей — это противоположно knowledge benchmarks и лучший однострочный summary того, где находится область; их figures стареют за месяцы, поэтому цитируйте их с датой, когда вы их читали; и каждый из них измеряет задачу, которая не является вашей.

Accuracy — метрика, о которой спорят. Вот метрики, которые решают, будет ли система shipping. Все четыре получаются из уже измеренных двухсот runs.

Cost per solved task, not per call. Agent стоит $0.001345 за попытку и $0.005172 за фактически решённую задачу — в 3.85 раза больше, потому что три четверти попыток ничего не дают. Latency ведёт себя так же: 1,213 ms за попытку, 4,667 ms за решённую задачу. Каждый retry, каждый re-ask, каждая abandoned trajectory находится во втором числе и невидим в первом.

Диагностика, которая лучше accuracy. В 123 из 200 попыток agent ответил не вызвав ни одного инструмента — он угадывал, а не смотрел. Разделение по этому признаку:

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, не в модели. Одна оговорка, которую эта глава должна собственным стандартам: две группы — это разные задачи, а не одни и те же задачи в паре, поэтому часть gap может объясняться тем, что она пропускает инструменты именно на вопросах, которые считает трудными. Разделение — diagnostic, а не causal claim.

Human intervention rate — метрика, которую покупатель спрашивает первой: какая доля runs остановилась на approval, guardrail или handoff. Typed interruptions из главы 23 делают её countable, а подсчёт по типам задач и по неделям отделяет agent, который учится своей работе, от agent, который тихо превращается в очередь.

Abandonment — та, которую не видит ни один offline suite: пользователь, прочитавший ответ, закрывший вкладку и сделавший задачу сам. Offline evaluation — gate; production evaluation — continuous sample реального traffic, scoring тем же grader плюс эти четыре.

И правило, унаследованное из главы 17: никогда не assert on exact output. Assert on properties — valid JSON, correct schema, вызван правильный tool, число в пределах tolerance, присутствует required substring. Колонка exact-match в начале этой главы — то, что происходит, когда это правило нарушают.

Оценка поставщика — это не только accuracy, и это вторая половина ethics этого курса, с собственным heading, а не приложением.

Измеряйте bias, не предполагайте его. Что бы вы ни думали о поведении модели на именах, dialects, genders или nationalities, это измеримое свойство вашего pipeline, а инструмент — тот, что у вас уже есть: возьмите свой golden set, меняйте только attribute, сравнивайте paired. HELM существует именно потому, что сообщали только accuracy там, где bias, toxicity, calibration и robustness тоже были decidable.⁸ Model card поставщика — отправная точка, а не evidence о ваших inputs.

Contamination — тоже вопрос к поставщику. Probe выше — причина спросить, на чём было измерено опубликованное число и когда были отсечены данные модели.

Retention, training и residency, прочитано 7 сентября 2026 года. Это меняется, поэтому записывайте дату рядом с ответом. На странице политики Anthropic сказано: "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", за исключением content, который вы явно отправляете как feedback и который хранится "for up to 5 years".¹⁶ Документация OpenAI по data controls говорит, что "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)", описывает тридцатидневное default retention для abuse-monitoring logs и предлагает Zero Data Retention, который "excludes customer content from abuse monitoring logs", плюс configurable data residency across a list of regions.¹⁷

Четыре вопроса, на которые нужно получить письменный ответ до первого production call, потому что у каждого свой владелец: используются ли мои данные для training; как долго они хранятся и у кого; где они обрабатываются и хранятся; и что происходит со всем этим, если я использую reseller, gateway или aggregator вместо прямого обращения к provider. Последний пункт — место, где живёт большинство сюрпризов, и ни один benchmark вам о нём не скажет.

Теперь у вас есть инструмент: golden set, которым вы владеете; интервал на каждом числе; paired test для каждого сравнения; pass^k для runs, которые вы никому не показали; измеренный judge; и probe, показывающий, значит ли что-нибудь публичный score. Заключительное утверждение главы 23 теперь можно проверить, а не просто заявлять: harness делает agent управляемым, а не правильным, — и проверка заняла двести runs и восемь минут.

Есть одно свойство agent, которое всё это не измеряет, и именно оно приводит к увольнениям.

Каждая задача в golden set этой главы была написана мной, и каждый файл, который читал agent, был написан мной. Ничто в этом каталоге не пыталось ничего сделать. Измените одну строку в одном файле, который agent должен прочитать, — строку, заканчивающуюся инструкцией, адресованной тому, кто прочитает её следующим, — и agent, получивший 26 %, последует ей с теми же инструментами, теми же permissions и тем же чистым trace, а каждое число в этой главе останется ровно на месте. Evaluation suite измеряет, как часто система достигает вашей цели. Он не измеряет, насколько легко кто-то другой может подменить её своей.

Глава 30 — об этом: prompt injection, lethal trifecta из private data, untrusted content и external communication, и сколько стоит дать agent реальные permissions. Она открывается наблюдением, которого эта глава избегала: один и тот же passing score совместим с agent, который делает ровно то, что attacker написал в файле, который ему велели прочитать.

Каждое число выше было получено на одной машине, и ни одно не коснулось paid endpoint. Agent — это цикл из главы 23 с двумя из четырёх его инструментов по каталогу из пяти файлов; модель за port — Qwen/Qwen2.5-0.5B-Instruct, exposed through small server той же формы, что chat completions endpoint, ровно как в главе 23, но в half precision на одной consumer GPU вместо CPU той главы. Costs используют rates из главы 16 — $2.00 за миллион input tokens и $12.00 за миллион output — применённые к measured token counts. Repeated runs используют temperature 0.7 с fixed seeds, чтобы весь set воспроизводился; four-arm table — greedy. Интервалы — Wilson at 95 %, paired comparisons — two-sided exact sign tests по discordant pairs; Wilson interval — из главы 4, exact paired sign test — из главы 15, оба reused unchanged. Human labels — мои, applied to sixty answers under the written rule quoted in the text. Читайте каждую magnitude здесь как свойство модели на полмиллиарда parameters, а каждый method — как transferable: большая модель поднимает все числа и не меняет ни одного инструмента.