Оцінювання LLM: від публічних benchmark до вашого golden set

Майже кожна суперечка про оцінювання — це двоє людей, які вимірюють різні речі. Є три проєкти, і в них немає спільного інструмента.

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

Порядок теж має значення, і вендор, який продає вам модель, сам це каже. Посібник OpenAI для agent зводить вибір моделі до трьох кроків, саме в такому порядку: «Налаштуйте evals, щоб встановити performance baseline», «Зосередьтеся на досягненні вашої цілі точності з найкращими доступними моделями», «Оптимізуйте вартість і затримку, замінюючи більші моделі меншими там, де це можливо».¹ Оцінювання йде першим, бо кроки два й три без числа не мають сенсу.

Golden set — це список вхідних даних, кожен із записаною правильною відповіддю, і 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 написаний і прозою, і pattern, бо і людині, і judge він знадобиться пізніше — а записати той самий факт двічі у двох нотаціях означає з’ясувати, що ви самі з собою не погодилися щодо того, у чому було завдання.

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

Читайте інтервали до переможця. Запуски плеча B лежать від 11 % до 47 %; плеча A — від 3 % до 30 %. Вони перекриваються на більшій частині довжини, і це висновок розділу 4, який приходить саме туди, де був обіцяний: двадцять випадків не можуть ранжувати чотири системи. Розділ 15 загострив це, поставивши натомість парне запитання — у випадках, де два плеча не згодні, наскільки перекошений поділ? — бо спільна складність набору скорочується. Ось кожна пара:

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

Жодне із шести порівнянь не встановлене. Найкраще плече б’є плече без жодних інструментів на п’ятнадцять пунктів, і все це тримається на трьох discordant випадках. Двадцять випадків показують механізм і не можуть вибрати постачальника; сказати протилежне на зустрічі — це спосіб купити погану модель.

Є одна річ, яку ця таблиця таки встановлює, і це стовпець, який ніхто не додає. Плече D коштує у тринадцять разів дорожче за плече B на розв’язане завдання, бо sampling трьох траєкторій і вибір modal відповіді потроює рахунок незалежно від того, чи потроює він accuracy. Таблиці accuracy, які опускають cost, роблять цей компроміс невидимим.

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

Нуль, тринадцять, двадцять шість. Система не змінилася. Змінився grader. Exact match повертає нуль не тому, що agent марний, а тому, що жодна відповідь вільним текстом ніколи не є побайтово ідентичною reference: він вимірює форматування й звітує про нього як про capability.

Це не курйоз, а механізм, і в нього є назва. Hard-cutoff metric оцінює завдання за принципом усе-або-нічого на кількох підфактах, тому ефект множиться. Завдання t12 питає одразу про три коди статусу. За десять запусків:

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 на п’ять пунктів перетворюється на двадцять п’ять пунктів на кон’юнкції. З моделлю не сталося нічого дискретного. Гладка крива, прочитана через all-or-nothing metric, виглядає як стрибок — саме це Schaeffer, Miranda і Koyejo доводили щодо emergent abilities, і саме це розділ 10 відкладав сюди.² Їхній аудит виявив, що щонайбільше 5 із 39 preferred metrics BIG-Bench узагалі демонструють emergence, причому дві дискретні metrics дають понад 92 % заявлених випадків.

Отже, дисципліна в один рядок: стрибок на графіку є свідченням про metric, доки не доведено протилежне. Перш ніж повірити, що capability з’явилася, побудуйте ті самі запуски з metric, яка дає частковий credit, і подивіться, чи урвище виживе.

Є друга версія цього ефекту, про яку Kalai та колеги стверджують, що вона шкодить вище за течією: benchmark, оцінені як правильно-або-неправильно, винагороджують вгадування замість відповіді «я не знаю», тож модель, optimized під них, вчиться вгадувати. Їхнє запропоноване виправлення — не ще один hallucination benchmark, а «зміна scoring наявних benchmark, які неузгоджені, але домінують у leaderboard».³ У вашого golden set є та сама важільна точка, і це один рядок: вирішити, чи abstention рахується як failure, чи як окрема категорія. Більшість людей ніколи не вирішує, тож він мовчки рахується як failure, і система, яку вони випускають, вгадує.

Досі все оцінювало одну спробу на завдання. Agent — це не одна спроба. Розділ 17 встановив, що детермінізму у вас немає навіть за temperature zero, тож той самий input породжує розподіл траєкторій, а benchmark, який запускає кожне завдання один раз, звітує про один sample із нього.

Внесок τ-bench — metric для цього. Стаття визначає її прямо: «ми пропонуємо нову metric — pass^k (pass hat k), визначену як імовірність того, що всі k i.i.d. trials завдання будуть успішними, усереднену за завданнями».⁴ Запустіть кожне завдання $n$ разів, порахуйте $c$ успіхів, і незміщені estimators такі:

Друга — це знайома pass@k з генерації коду: шанс, що принаймні одна з $k$ спроб буде успішною. Поставте їх поруч на тих самих виміряних counts, і вони рухаються в протилежних напрямках:

Ті самі запуски, той самий grader, ті самі двадцять завдань. Один стовпець каже, що система покращується з більшою кількістю спроб, а інший — що погіршується, і обидва правильні, бо відповідають на різні запитання. pass@k — правильна metric, коли людина фільтрує output: генерація коду, чернетки, brainstorming — і додаткові спроби дешеві. pass^k — правильна metric, коли agent діє без фільтра, тобто саме те, що означає «agent». Публікувати першу там, де застосовується друга, — найпоширеніше перебільшення в цій сфері, і власний заголовок τ-bench є чесною версією: gpt-4o приблизно з 61 % pass^1 на retail падає приблизно до 25 % при pass^8.⁴

Тепер жало в моїх власних числах. pass^10 на моїх двадцяти завданнях — 5.0 %: рівно одне завдання з двадцяти розв’язане на всіх десяти запусках. Це завдання t19, «Чи був deploy 42 успішним?», і ось дві з десяти відповідей, які rubric оцінив як правильні:

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 вище нуля, — артефакт grader, тож справжня цифра — нуль, і жоден aggregate цього мені не показав би. Sampling transcript за вашим завданням із найкращим score — це місце, де grader помирають.

І ще одне число, на честь якого названо цей розділ. Десять ідентичних оцінювань — та сама система, ті самі двадцять завдань, той самий код, нічого не змінено, крім seeds:

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

Діапазон у тридцять пунктів у системи, яка не змінилася. Якщо ви запустите suite один раз перед release і один раз після, «покращення» на вісім пунктів буде всередині цього розкиду, і ви випустите його, вважаючи, що спричинили зміну. Саме тому pooled interval вище — 26.0 % [20.4, 32.5] — надто вузький, щоб цитувати його сам по собі: він трактує двісті корельованих trials як двісті незалежних. Чесний підсумок оцінювання agent — це середнє і розкид між повторами, а друге майже ніхто не публікує.

Rubric не масштабуються на open-ended відповіді, тому стандартний хід — доручити моделі grade output. На frontier scale це працює достатньо добре, щоб бути default, і має три названі failure mode: position bias, verbosity bias і self-enhancement bias.⁵

Виміряйте це, перш ніж довіряти. Ті самі шістдесят відповідей — три з десяти запусків — були розмічені трьома способами. Людська мітка — моя: я прочитав усі шістдесят із відкритими п’ятьма файлами й застосував одне письмове правило: pass тоді й лише тоді, коли відповідь стверджує факт, про який було запитання, і не містить нічого, що суперечить файлам.

Judge сказав PASS шістдесят разів із шістдесяти. Він звітував би про цього agent як про 100 % accuracy на наборі, де людина оцінює його у 18 %. Judge без discriminative power — не шумний інструмент; це стала функція, а стала функція дає вашій найкращій і найгіршій системі однаковий score.

Prompting його не врятував. Чотири варіанти, ті самі шістдесят items:

Заміна порядку двох labels в інструкції зрушила чотири verdicts. Це вимірюваний ефект, і це неправильний тип ефекту: judge реагує на форму prompt, а не на відповідь перед ним.

Чиста демонстрація — попарна. Двадцять запитань, кожне з одним очевидно правильним і одним очевидно неправильним кандидатом, подані в обох порядках:

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: «відсоток випадків, коли judge дає consistent results після перестановки порядку двох assistants», що робить порівняння apples to apples: GPT-4 має 65.0 % за цією мірою, а few-shot prompting підняв її до 77.5 %.⁵ Мій має нуль.

Стандартне пом’якшення також із цієї статті: «викликати judge двічі, міняючи порядок двох відповідей, і оголошувати перемогу лише тоді, коли відповідь preferred в обох порядках».⁵ Застосуйте це тут, і judge видає нуль придатних verdicts із двадцяти пар — це правильний результат і нескінченно кращий за двадцять упевнених.

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

Чесне застереження: цей judge — модель на пів мільярда параметрів, і ніхто не має grade з такою. Суть не в тому, що judge погані. Суть у тому, що числа вище коштували вісім хвилин, і без них verdict цього judge щодо рішення про shipping був би 100 %.

Це третя й остання оголошена Python-панель курсу, і причина — у тому, звідки беруться публічні числа. lm-evaluation-harness охоплює «понад 60 стандартних академічних benchmark для LLM, із сотнями підзавдань і реалізованих варіантів» і є «backend для популярного Open LLM Leaderboard від Hugging Face»; HELM, SWE-bench і τ-bench — це Python packages із Python entry points.⁶ Запустити вашу модель проти опублікованої цифри означає запустити їхній код, і в день, коли ви захочете порівнятися з числом, яке хтось процитував, ви опинитеся саме в цій екосистемі:

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 беззмістовним, а найгостріший зонд для нього потребує власного 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 вебу від його появи, п’ять написані для цього розділу сьогодні вранці, кожне в парі з переформульованою версією з тим самим змістом.

Модель у чотири рази більше здивована реченням, написаним сьогодні вранці, ніж тим, яке бачила мільйон разів, а переформулювання коштує вдвічі дорожче на відомих — ця додаткова вартість і є частиною, яку запам’ятали, а не зрозуміли. Absolute loss змішує memorisation зі звичайною природністю, тому gap — краща статистика, а 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."

Три з п’яти відомих рядків продовжилися слово в слово з шести слів; жоден із п’яти свіжих — ні. Це модель на пів мільярда параметрів, яка декламує MIT License. Якщо ваш benchmark є у відкритому вебі, вважайте, що він є у weights. Це також аргумент на користь усього розділу: golden set, який ви написали зі своїх даних і тримаєте поза будь-яким repository, який читає crawler, — єдиний test set, щодо якого ви можете бути впевнені, що на ньому ніколи не тренували.

Їх усе ще варто читати, якщо ви читаєте те, що кожен із них вимірює, а не одне число, приклеєне до нього.

Беріть таблицю, а не окремий рядок. Усі agentic benchmark ставлять людей значно вище за моделі, що є протилежністю knowledge benchmark і найкращим однорядковим підсумком стану галузі; їхні цифри старіють за місяці, тож цитуйте їх із датою, коли прочитали; і кожен із них вимірює завдання, яке не є вашим.

Accuracy — це metric, про яку ви сперечаєтеся. Ось ті, що вирішують, чи річ піде в shipping. Усі чотири випливають із уже виміряних двохсот запусків.

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

Діагностика, краща за accuracy. У 123 зі 200 спроб agent відповів без жодного tool call — він вгадав, а не подивився. Поділ за цим:

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 %, бо називає річ, яку треба виправити: модель не failing to reason, вона failing to look — і виправлення в harness, а не в моделі. Одне застереження, яке цей розділ винен власним стандартам: дві групи — це різні завдання, а не ті самі завдання в парі, тож частина gap може бути через те, що вона пропускає інструменти саме на запитаннях, які вважає складними. Поділ — це діагностика, не causal claim.

Human intervention rate — metric, про яку покупець питає першою: яка частка запусків зупинилася на approval, guardrail або handoff. Типізовані interruptions із розділу 23 роблять це підраховним, а підрахунок за типом завдання й за тиждень відділяє agent, який вчиться своїй роботі, від того, що тихо перетворюється на чергу.

Abandonment — це те, чого не бачить жодна offline suite: користувач, який прочитав відповідь, закрив вкладку й зробив завдання сам. Offline evaluation — це gate; production evaluation — безперервний sample реального трафіку, оцінений тим самим grader плюс ці чотири.

І правило, успадковане з розділу 17: ніколи не assert on exact output. Assert on properties — valid JSON, correct schema, викликаний правильний інструмент, число в межах tolerance, наявний required substring. Стовпець exact-match на початку цього розділу — те, що стається, коли це правило порушене.

Оцінювання постачальника — це не лише accuracy, і це друга половина етики цього курсу, з власним заголовком, а не додатком.

Вимірюйте bias, не припускайте його. Що б ви не думали про поведінку моделі щодо імен, діалектів, гендерів чи національностей, це вимірювана властивість вашого pipeline, і інструмент у вас уже є: візьміть ваш golden set, змінюйте лише attribute, порівнюйте в парі. HELM існує саме тому, що accuracy alone звітували там, де bias, toxicity, calibration і robustness також були decidable.⁸ Model card вендора — це відправна точка, а не evidence щодо ваших input.

Contamination — також запитання до постачальника. Зонд вище — причина спитати, на чому вимірювали опубліковане число і коли були відсічені дані моделі.

Retention, training і residency, прочитано 7 вересня 2026 року. Це змінюється, тож записуйте дату поруч із відповіддю. Сторінка політики Anthropic стверджує: «За замовчуванням ми не використовуватимемо ваші inputs або outputs з наших commercial products (наприклад Claude for Work, Anthropic API, Claude Gov тощо) для тренування наших моделей», за винятком content, який ви явно надсилаєте як feedback і який зберігається «до 5 років».¹⁶ Документація OpenAI щодо data controls стверджує, що «data, надіслані до OpenAI API, не використовуються для тренування чи покращення моделей OpenAI (якщо ви явно не погодитеся поділитися data з нами)», описує тридцятиденне default retention для abuse-monitoring logs і пропонує Zero Data Retention, що «виключає customer content із abuse monitoring logs», плюс configurable data residency у списку регіонів.¹⁷

Чотири запитання, на які треба отримати письмову відповідь до першого production call, бо кожне має іншого власника: чи використовуються мої data для training; як довго вони retained і ким; де вони processed і stored; і що стається з усім цим, якщо я використовую reseller, gateway або aggregator замість provider напряму. Останнє — місце, де живе більшість сюрпризів, і жоден benchmark вам про це не скаже.

Тепер у вас є інструмент: golden set, який належить вам, інтервал на кожному числі, paired test для кожного порівняння, pass^k для запусків, які ви нікому не показали, виміряний judge і зонд для того, чи публічний score щось означає. Фінальне твердження розділу 23 тепер можна перевірити, а не просто проголосити — harness робить agent керованим, не правильним — і перевірка зайняла двісті запусків і вісім хвилин.

Є одна властивість agent, яку все це не вимірює, і саме через неї людей звільняють.

Кожне завдання в golden set цього розділу написав я, і кожен файл, який читав agent, написав я. Ніщо в тому каталозі не намагалося нічого робити. Змініть один рядок в одному файлі, який agent має прочитати, — рядок, що закінчується інструкцією, адресованою тому, хто прочитає його наступним, — і agent, який набрав 26 %, виконає її з тими самими інструментами, тими самими дозволами й тим самим чистим trace, а кожне число в цьому розділі залишиться рівно там, де було. Evaluation suite вимірює, як часто система досягає вашої мети. Вона не вимірює, наскільки легко хтось інший може підмінити її своєю.

Розділ 30 — саме про це: prompt injection, lethal trifecta приватних data, untrusted content і external communication, а також вартість надання agent реальних permissions. Він відкривається спостереженням, якого цей розділ уникав: той самий passing score сумісний з agent, який робить саме те, що attacker написав у файлі, який йому наказали прочитати.

Кожне число вище було отримане на одній машині, і жодне не торкалося платного endpoint. Agent — це цикл із розділу 23 з двома з чотирьох інструментів над каталогом із п’яти файлів; модель за портом — Qwen/Qwen2.5-0.5B-Instruct, exposed through a small server of the same shape as a chat completions endpoint exactly as in Chapter 23, but in half precision on one consumer GPU rather than that chapter's CPU. Costs use rates із розділу 16 — $2.00 за мільйон input tokens і $12.00 за мільйон output — applied to measured token counts. Repeated runs use temperature 0.7 with fixed seeds so the whole set reproduces; the four-arm table is greedy. Інтервали — Wilson at 95 %, paired comparisons are two-sided exact sign tests over the 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. Читайте кожну величину тут як властивість моделі на пів мільярда параметрів, а кожен метод — як переносний: більша модель піднімає всі числа і не змінює жодного інструмента.