Оценяване на LLM: от публични benchmarks до вашия златен набор

Почти всеки спор за оценяване е двама души, които измерват различни неща. Има три проекта и те не споделят инструмент.

Объркването е скъпо в една посока. Leaderboard може да ви каже, че даден модел е силен в разсъждения на ниво докторантура; не може да ви каже дали ще маршрутизира вашите support tickets. А оценяване на приложение, което точкува по един отговор на input, изобщо не може да види agent, защото agent има разпределение от траектории, а един отговор е единична извадка от него. Глава 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“.¹ Оценяването е първо, защото стъпки две и три са безсмислени без число.

Златният набор е списък с 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 с интервала ѝ и двете колони, които таблица само с accuracies винаги скрива:

Прочетете интервалите преди победителя. Резултатите на arm B са от 11 % до 47 %; на arm A — от 3 % до 30 %. Те се припокриват през по-голямата част от дължината си, което е изводът от Глава 4, пристигащ точно там, където беше обещан: двадесет случая не могат да класират четири системи. Глава 15 изостри това, като вместо това зададе paired въпроса — при случаите, в които две 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 отговора утроява сметката, независимо дали утроява accuracy. Таблици с accuracy, които пропускат цената, правят тази размяна невидима.

Сега изводът, който променя начина, по който четете всеки benchmark, който някога ще видите. Вземете същите двеста transcripts — двадесет задачи, десет runs, нито един token регенериран — и ги оценете по три начина:

Нула, тринадесет, двадесет и шест. Системата не се промени. Grader се промени. Exact match връща нула не защото agent е безполезен, а защото никой free-text отговор никога не е byte-identical с reference: той измерва форматиране и го докладва като способност.

Това не е любопитен факт, а механизъм, и има име. Hard-cutoff metric оценява задача all-or-nothing върху няколко подфакта, така че ефектът се натрупва. Задача t12 иска три status codes наведнъж. В десетте runs:

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. Нищо discontinuous не се е случило с модела. Гладка крива, прочетена през all-or-nothing metric, изглежда като скок — точно това твърдят Schaeffer, Miranda и Koyejo за emergent abilities, и което Глава 10 отложи дотук.² Техният audit установява, че най-много 5 от 39-те preferred metrics на BIG-Bench изобщо показват emergence, като две discontinuous metrics обясняват над 92 % от заявените случаи.

Затова дисциплината в едно изречение: скок в графика е доказателство за метриката, докато не се покаже друго. Преди да повярвате, че се е появила способност, начертайте същите runs с metric, която дава partial credit, и вижте дали пропастта оцелява.

Има версия от втори ред, за която Kalai и колеги твърдят, че нанася щети нагоре по веригата: benchmarks, оценявани като right-or-wrong, възнаграждават налучкването вместо „не знам“, така че модел, оптимизиран срещу тях, се учи да налучква. Предложената от тях поправка не е поредният hallucination benchmark, а „modifying the scoring of existing benchmarks that are misaligned but dominate leaderboards“.³ Вашият златен набор има същия лост, и той е един ред: решете дали abstention се брои като failure или като собствена категория. Повечето хора никога не решават, така че то тихомълком се брои като failure, а системата, която пускат, налучква.

Всичко дотук оценяваше по един опит на задача. Agent не е един опит. Глава 17 установи, че нямате determinism дори при temperature zero, така че един и същ input произвежда разпределение от траектории, а benchmark, който пуска всяка задача веднъж, докладва една извадка от него.

Приносът на τ-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$ успеха, и unbiased estimators са:

Втората е познатата pass@k от code generation: шансът поне един от $k$ опита да успее. Сложете ги една до друга върху същите измерени counts и те се движат в противоположни посоки:

Същите runs, същият grader, същите двадесет задачи. Едната колона казва, че системата се подобрява с повече опити, а другата — че се влошава, и двете са верни, защото отговарят на различни въпроси. pass@k е правилната metric, когато човек филтрира output — code generation, чернови, brainstorming — и допълнителните опити са евтини. pass^k е правилната metric, когато agent действа без филтър, което е значението на „agent“. Публикуването на първата там, където важи втората, е най-честото преувеличение в тази област, а собственото заглавие на τ-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 над нулата, е grader artefact, така че истинската стойност е нула, и нито един aggregate нямаше да ми го покаже. Sampling на transcripts зад вашата задача с най-добър score е мястото, където graders отиват да умрат.

И още едно число, онова, на което е кръстена тази секция. Десет идентични evaluations — същата система, същите двадесет задачи, същият код, нищо променено освен 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 и веднъж след него, осемпунктово „подобрение“ е вътре в този spread и ще го ship-нете с убеждението, че вие сте го причинили. Затова pooled interval по-горе — 26.0 % [20.4, 32.5] — е твърде тесен, за да се цитира самостоятелно: той третира двеста correlated trials като двеста independent. Честното резюме на evaluation на agent е mean и spread across repeats, а почти никой не публикува второто.

Rubrics не се мащабират към open-ended answers, така че стандартният ход е модел да grade-ва output. Работи достатъчно добре на frontier scale, за да е default, и има три именувани failure modes: position bias, verbosity bias и self-enhancement bias.⁵

Измерете го, преди да му се доверите. Същите шестдесет отговора — три от десетте runs — бяха етикетирани по три начина. Human label е мой: прочетох всичките шестдесет с отворени пет файла и приложих едно писмено правило, pass if and only if the answer states the fact the question asked for and contains nothing contradicted by the files.

Judge каза PASS шестдесет пъти от шестдесет. Той щеше да докладва този agent при 100 % accuracy върху набор, където човекът го оценява на 18 %. Judge без discriminative power не е шумен инструмент; той е constant function, а constant function дава еднакъв score на най-добрата и най-лошата ви система.

Prompting не го спаси. Четири варианта, същите шестдесет items:

Размяната на реда на двата labels в инструкцията премести четири verdicts. Това е измерим ефект и е грешният вид ефект: 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 %

Той избра position A четиридесет пъти от четиридесет. 50 % по correctness не е partial competence — това е аритметика, защото правилният отговор стои на position 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 %.⁵ Моят постига нула.

Стандартното смекчаване също е от този документ: „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 произвежда нула използваеми verdicts от двадесет pairs — което е правилният резултат и безкрайно по-добър от двадесет уверени.

Методологична бележка, която струва повече от резултата. Пуснах и verbosity test: същия correct answer, едно копие допълнено с 36-word sentence, което не добавя нищо. Judge предпочете по-дългата версия в точно 50 % от trials — което изглежда като липса на verbosity bias и изобщо не е такова, защото judge, който винаги избира position A, score-ва 50 % при всяко balanced pairing. Не можете да измерите втори bias, докато първият не е контролиран. Размяната на positions не е refinement за добавяне по-късно; тя е това, което прави всяко друго измерване интерпретируемо.

Честната уговорка: този judge е модел с половин милиард parameters, и никой не бива да grade-ва с такъв. Смисълът не е, че 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.⁶ Да пуснете своя модел срещу публикувана стойност означава да пуснете техния код, а в деня, когато искате да сравните с число, което някой е цитирал, това е екосистемата, в която се намирате:

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 на web, откакто той съществува, пет написани за тази глава тази сутрин, всяко с преформулирана версия със същото съдържание.

Моделът е четири пъти по-изненадан от изречение, написано тази сутрин, отколкото от такова, което е виждал милион пъти, а rewording струва двойно повече при известните — допълнителната цена е частта, която е memorised, а не understood. Absolute loss смесва memorisation с обикновена naturalness, така че 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."

Три от петте известни strings продължиха word-perfect от шест думи; нито една от петте нови не го направи. Това е модел с половин милиард parameters, който рецитира MIT License. Ако вашият benchmark е в публичния web, приемете, че е в weights. Това е и аргументът за цялата глава: златен набор, който сте написали от собствените си данни и държите извън всяко repository, което crawler чете, е единственият test set, за който можете да сте сигурни, че никога не е бил използван за training.

Те все още си струва да се четат, стига да четете какво измерва всеки, а не единичното число, закачено за него.

Вземете таблицата, не отделен ред. Agentic benchmarks поставят хората далеч над моделите, което е обратното на knowledge benchmarks и най-доброто едноизреченско резюме къде е областта; числата им остаряват за месеци, така че ги цитирайте с датата, на която сте ги прочели; и всяко от тях измерва задача, която не е ваша.

Accuracy е метриката, за която спорите. Тези са тези, които решават дали нещото се ship-ва. И четирите излизат от вече измерените двеста runs.

Cost per solved task, not per call. Agent струва $0.001345 на опит и $0.005172 на реално решена задача — 3.85 пъти повече, защото три четвърти от опитите не произвеждат нищо. Latency се държи по същия начин: 1,213 ms на опит, 4,667 ms на solved task. Всеки retry, всяко re-ask, всяка изоставена траектория е във второто число и невидима в първото.

Diagnostic, който бие accuracy. В 123 от 200 опита agent отговори без да извика нито един инструмент — guessed rather than looked. Разделено по това:

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 %, защото назовава нещото за поправяне — моделът не се проваля да разсъждава, той се проваля да погледне — и поправката е в harness, не в модела. Една уговорка, която тази глава дължи на собствените си стандарти: двете групи са различни задачи, не едни и същи задачи paired, така че част от този gap може да е, че той пропуска инструментите точно при въпросите, които намира за трудни. Split е diagnostic, не causal claim.

Human intervention rate е metric, която купувачът пита първа: каква част от runs са спрели на approval, guardrail или handoff. Typed interruptions от Глава 23 я правят countable, а броена по тип задача и по седмица, тя е това, което отделя agent, който се учи да върши работата си, от такъв, който тихо се превръща в queue.

Abandonment е онази, която никоя offline suite не може да види: потребителят, който е прочел отговора, затворил е tab и е свършил задачата сам. Offline evaluation е gate; production evaluation е continuous sample от реален traffic, оценен със същия grader плюс тези четири.

И правило, наследено от Глава 17: никога не assert-вайте exact output. Assert-вайте properties — валиден JSON, correct schema, извикан правилният инструмент, число within tolerance, required substring present. Exact-match колоната в началото на тази глава е това, което се случва, когато това правило бъде нарушено.

Оценяването на доставчик не е само accuracy, и това е втората половина от етиката на този курс, със собствено заглавие вместо appendix.

Измервайте bias, не го предполагайте. Каквото и да вярвате за поведението на модел спрямо имена, диалекти, полове или националности, то е измеримо свойство на вашия pipeline, а инструментът е този, който вече имате: вземете златния си набор, променяйте само attribute, сравнявайте paired. HELM съществува точно защото accuracy alone се докладваше там, където bias, toxicity, calibration и robustness също бяха decidable.⁸ Model card на vendor е отправна точка, не доказателство за вашите inputs.

Contamination също е въпрос към доставчика. Сондата по-горе е причината да попитате върху какво е измерено публикувано число и кога е било cut-нато data на модела.

Retention, training and 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“, с изключение на съдържание, което изрично изпращате като feedback и което се съхранява „for up to 5 years“.¹⁶ Документацията за data controls на OpenAI казва, че „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)“, описва thirty-day 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, защото всеки има различен owner: използват ли се моите data за training; колко дълго се retain-ват и от кого; къде се processed и stored; и какво става с всичко това, ако използвам reseller, gateway или aggregator вместо директно provider. Последното е мястото, където живеят повечето изненади, и никой benchmark няма да ви го каже.

Сега имате инструмента: златен набор, който притежавате, интервал върху всяко число, paired test за всяко сравнение, pass^k за runs, които не сте показали на никого, измерен judge и сонда дали public score изобщо означава нещо. Заключителното твърдение на Глава 23 вече може да се провери, вместо да се заявява — harness прави agent управляем, не правилен — а проверката отне двеста runs и осем минути.

Има едно свойство на agent, което нищо от това не измерва, и то е онова, заради което хора биват уволнявани.

Всяка задача в златния набор на тази глава беше написана от мен, и всеки файл, който agent прочете, беше написан от мен. Нищо в тази директория не се опитваше да направи каквото и да било. Променете един ред в един файл, който на agent е казано да прочете — ред, който завършва с инструкция, адресирана до каквото го прочете следващо — и agent, който score-на 26 %, ще я последва със същите инструменти, същите permissions и същия clean 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 малък server със същата форма като chat completions endpoint точно както в Глава 23, но в half precision на един consumer GPU вместо CPU от онази глава. Разходите използват тарифите от Глава 16 — $2.00 на милион input tokens и $12.00 на милион output — приложени към measured token counts. Repeated runs използват temperature 0.7 with fixed seeds, така че целият набор се възпроизвежда; four-arm table е greedy. Интервалите са Wilson при 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 писменото правило, цитирано в текста. Четете всяка magnitude тук като свойство на модел с половин милиард parameters и всеки метод като transferable: по-голям модел премества всички числа нагоре и не премества нито един от инструментите.