LLM-értékelés: nyilvános benchmarkoktól a saját golden setig

Az értékelésről szóló viták többségében két ember különböző dolgokat mér. Három projekt van, és nincs közös műszerük.

A zavar az egyik irányban drága. Egy ranglista megmondhatja, hogy egy modell erős posztgraduális szintű következtetésben; azt nem mondhatja meg, hogy jól fogja-e route-olni a support jegyeidet. És egy alkalmazásértékelés, amely inputonként egy választ pontoz, egy agentet egyáltalán nem lát, mert egy agent trajektóriák eloszlásával rendelkezik, egy válasz pedig ennek egyetlen mintája. A 22. fejezet megnevezte ezt a harmadik sort, és üresen hagyta: a teljesítménymutatót, az agent specifikációjának azt az egy részét, amelyet a csapatok utoljára írnak le, vagy soha.

A sorrend is számít, és ezt az a vendor is kimondja, aki a modellt eladja neked. Az OpenAI agent útmutatója a modellválasztást három lépésre redukálja, ebben a sorrendben: „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”.¹ Az értékelés jön először, mert a második és harmadik lépés szám nélkül értelmetlen.

A golden set inputok listája, mindegyikhez leírt válasszal, és egy graderrel, amely eldönti, hogy egy output megfelel-e. Unalmas, kicsi, és ebben a fejezetben az egyetlen artefaktum, amely a tiéd. Az itt felépített készlet húsz feladatot tartalmaz egy öt fájlból álló könyvtáron — nem a 23. fejezet három fájlján, tehát a válaszok nem ugyanazok —, és a grader még az agent futása előtt készül el:

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
];

Két tulajdonság tartja az egészet. A mustNot lista azért létezik, mert az a modell, amely három fájlt nevez meg, köztük a helyessel, még nem válaszolt. A answer pedig prózában és mintákban is le van írva, mert később embernek és judge-nak egyaránt szüksége lesz rá — és ugyanannak a ténynek két jelölésben való leírása az a mód, ahogy kiderül, hogy te magad sem értettél egyet magaddal abban, mi volt a feladat.

Most a döntő táblázat. Négy jelöltrendszer, ugyanaz a húsz feladat, pontosság intervallummal, és az a két oszlop, amelyet a puszta pontosságtáblázatok mindig elrejtenek:

Előbb az intervallumokat olvasd, csak utána a győztest. A B kar 11%-tól 47%-ig fut; az A kar 3%-tól 30%-ig. Hosszuk nagy részén átfednek, vagyis a 4. fejezet állítása pontosan ott érkezik meg, ahová ígértük: húsz eset nem tud négy rendszert rangsorolni. A 15. fejezet ezt úgy élezte ki, hogy inkább a párosított kérdést tette fel — azokban az esetekben, ahol két kar eltér, mennyire egyoldalú a megoszlás? —, mert a készlet közös nehézsége kiesik. Íme minden pár:

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

A hat összehasonlítás közül egyetlenegy sem bizonyított. A legjobb kar tizenöt ponttal veri a tool nélküli kart, és ez három discordant eseten nyugszik. Húsz eset mechanizmust mutat, de nem választ beszállítót; az ellenkezőjét mondani egy meetingben az a mód, ahogy rossz modellt vásárolnak.

Egy dolgot viszont ez a táblázat tényleg bizonyít, mégpedig azt az oszlopot, amelyet senki nem tesz bele. A D kar tizenháromszor annyiba kerül megoldott feladatonként, mint a B, mert három trajektória samplingelése és a modális válasz kiválasztása akkor is megháromszorozza a számlát, ha a pontosságot nem háromszorozza meg. A költséget kihagyó pontosságtáblák láthatatlanná teszik ezt a cserét.

Most jön az a felismerés, amely megváltoztatja, hogyan olvasol majd minden benchmarkot, amit valaha látsz. Vedd ugyanazt a kétszáz transcriptet — húsz feladat, tíz futás, egyetlen token sincs újragenerálva —, és pontozd háromféleképpen:

Nulla, tizenhárom, huszonhat. A rendszer nem változott. A grader változott. Az exact match nem azért ad nullát, mert az agent használhatatlan, hanem mert egy szabad szöveges válasz soha nem byte-ra azonos a referenciával: formázást mér, és képességként jelenti.

Ez nem érdekesség, hanem mechanizmus, és neve is van. A hard-cutoff metric több résztényen pontoz egy feladatot mindent-vagy-semmit módon, ezért összeszorzódik. A t12 feladat három státuszkódot kér egyszerre. A tíz futásban:

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

Mindegyik tény az esetek nagyjából háromnegyedében helyes; mindhárom egyszerre való megkövetelése megfelezi a pontszámot, és a $0.77^3 = 0.457$ elég közel van a mért 0,50-hez ahhoz, hogy megmutassa, honnan jött az esés. Általánosítva:

Olvasd össze a 0,90-es sort a 0,95-össel $k = 10$ mellett: egy tényenkénti ötpontos javulás huszonöt ponttá válik a konjunkción. A modellel nem történt semmi diszkontinuus. Egy sima görbe mindent-vagy-semmit metrikán át olvasva ugrásnak látszik — pontosan ezt az érvet hozta Schaeffer, Miranda és Koyejo az emergens képességekről, és ezt halasztotta ide a 10. fejezet.² Auditjuk szerint a BIG-Bench 39 preferált metrikájából legfeljebb 5 mutat egyáltalán emergenciát, és két diszkontinuus metrika felel a bejelentett esetek több mint 92%-áért.

A fegyelem tehát egy mondatban: egy grafikonon látható ugrás először a metrikáról szóló bizonyíték, amíg be nem bizonyosodik az ellenkezője. Mielőtt elhiszed, hogy megjelent egy képesség, rajzold fel ugyanazokat a futásokat részpontszámot adó metrikával, és nézd meg, túléli-e a szakadék.

Ennek van egy másodrendű változata is, amely Kalai és kollégái szerint már upstream kárt okoz: a helyes-vagy-helytelen módon pontozott benchmarkok a találgatást jutalmazzák az „nem tudom” helyett, ezért az ellenük optimalizált modell megtanul találgatni. Javasolt javításuk nem egy újabb hallucinációs benchmark, hanem „a félreigazított, de a ranglistákat domináló meglévő benchmarkok pontozásának módosítása”.³ A te golden setedben ugyanez a kar egyetlen sor: döntsd el, hogy a tartózkodás hibának számít-e vagy saját kategóriának. A legtöbben soha nem döntenek, ezért csendben hibának számít, és a shipelt rendszer találgat.

Eddig minden egy feladatonkénti egy próbálkozást pontozott. Egy agent nem egy próbálkozás. A 17. fejezet megmutatta, hogy még temperature nulla mellett sincs determinizmus, tehát ugyanaz az input trajektóriák eloszlását adja, és az a benchmark, amely minden feladatot egyszer futtat, ennek egyetlen mintáját jelenti.

A τ-bench hozzájárulása ehhez a metrika. A paper egyszerűen definiálja: „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.”⁴ Futtasd minden feladatot $n$ alkalommal, számold meg a $c$ sikert, és a torzítatlan becslők:

A második a kódgenerálásból ismert pass@k: annak esélye, hogy $k$ próbálkozásból legalább egy sikerül. Tedd őket egymás mellé ugyanazokon a mért számlálásokon, és ellentétes irányba mozognak:

Ugyanazok a futások, ugyanaz a grader, ugyanaz a húsz feladat. Az egyik oszlop azt mondja, hogy a rendszer javul több próbálkozással, a másik azt, hogy romlik, és mindkettő igaz, mert más kérdésre válaszolnak. A pass@k a jó metrika, amikor ember szűri az outputot — kódgenerálásnál, vázlatoknál, ötletelésnél —, és az extra próbálkozások olcsók. A pass^k a jó metrika, amikor az agent szűrő nélkül cselekszik, márpedig ezt jelenti az „agent”. Az első publikálása ott, ahol a második érvényes, a terület leggyakoribb túlzása, és a τ-bench saját főcíme az őszinte verzió: gpt-4o retailen nagyjából 61% pass^1 értékről körülbelül 25%-ra esik pass^8 mellett.⁴

Most a csípős rész a saját számaimban. A pass^10 a húsz feladatomon 5,0%: pontosan egy feladat húszból sikerült mind a tíz futásban. Ez a feladat a t19, „Sikerült a deploy 42?”, és itt van két válasz a tízből, amelyet a rubric helyesnek pontozott:

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

Az első soha nem válaszol. A második hozzátesz egy hamis állítást — a deploy 41-et visszagörgették. Mindkettő illeszkedett a /succe|yes/ mintára. Az egyetlen feladat, amely a pass^10 értéket nulla fölött tartja, grader-artefaktum, tehát a valódi szám nulla, és ezt semmilyen aggregátum nem mutatta volna meg. A legjobb pontszámú feladat mögötti transcriptek samplingelése az a hely, ahol a graderek meghalnak.

És még egy szám, amelyről ez a szakasz a nevét kapta. Tíz azonos értékelés — ugyanaz a rendszer, ugyanaz a húsz feladat, ugyanaz a kód, semmi nem változott a seedeken kívül:

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

Harmincpontos tartomány egy olyan rendszeren, amely nem változott. Ha a suite-odat egyszer futtatod release előtt és egyszer utána, egy nyolcpontos „javulás” ezen a szóráson belül van, és úgy shippeled, hogy azt hiszed, te okoztad. Ezért túl szűk önmagában idézni a fenti pooled intervallumot — 26,0% [20,4, 32,5] —: kétszáz korrelált próbát kezel kétszáz függetlenként. Egy agent-értékelés őszinte összefoglalója egy átlag és a repeat-ek közötti szórás, és a másodikat szinte senki nem publikálja.

A rubricek nem skálázódnak nyílt végű válaszokra, ezért a standard lépés az, hogy egy modell osztályozza az outputot. Frontier méretben elég jól működik ahhoz, hogy ez legyen az alapértelmezés, és három néven nevezett hibamódja van: pozíciótorzítás, verbosity bias és self-enhancement bias.⁵

Mérd meg, mielőtt megbízol benne. Ugyanazt a hatvan választ — a tíz futás közül hármat — háromféleképpen címkéztük. Az emberi címke az enyém: mind a hatvanat elolvastam az öt fájllal megnyitva, és egy írott szabályt alkalmaztam: pass akkor és csak akkor, ha a válasz kimondja a kérdés által kért tényt, és nem tartalmaz semmit, amit a fájlok cáfolnak.

A judge hatvanszor mondott PASS-t hatvanból. Ezt az agentet 100%-os pontosságúnak jelentette volna egy olyan készleten, ahol az ember 18%-ra pontozza. Egy diszkriminatív erő nélküli judge nem zajos műszer; konstans függvény, a konstans függvény pedig a legjobb és a legrosszabb rendszerednek ugyanazt a pontszámot adja.

A prompting nem mentette meg. Négy variáns, ugyanaz a hatvan elem:

A két címke sorrendjének felcserélése az instrukcióban négy ítéletet mozdított el. Ez mérhető hatás, és a rossz fajta hatás: a judge a prompt alakjára reagál, nem az előtte lévő válaszra.

A tiszta demonstráció páros. Húsz kérdés, mindegyikhez egy nyilvánvalóan helyes és egy nyilvánvalóan rossz jelölt, mindkét sorrendben bemutatva:

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 %

Negyvenből negyvenszer az A pozíciót választotta. Az 50%-os helyesség nem részleges kompetencia — aritmetika, mert a helyes válasz pontosan a próbák felében ül A pozícióban. A konzisztenciát itt úgy definiáljuk, ahogy az MT-Bench: „the percentage of cases where a judge gives consistent results when swapping the order of two assistants”, így az összehasonlítás almát almával vet össze: GPT-4 ezen a mércén 65,0%-ot ér el, és few-shot prompting 77,5%-ra emelte.⁵ Az enyém nulla.

A standard mitigáció szintén ebből a paperből jön: „call a judge twice by swapping the order of two answers and only declare a win when an answer is preferred in both orders.”⁵ Alkalmazd itt, és a judge nulla használható ítéletet ad húsz párból — ez a helyes eredmény, és végtelenül jobb húsz magabiztosnál.

Egy módszertani megjegyzés, amely többet ér az eredménynél. Futtattam verbosity tesztet is: ugyanaz a helyes válasz, az egyik példány 36 szavas, semmit hozzá nem tevő mondattal kitöltve. A judge pontosan a próbák 50%-ában preferálta a hosszabb verziót — ami úgy néz ki, mint a verbosity bias hiánya, de egyáltalán nem az, mert egy judge, amely mindig az A pozíciót választja, bármilyen kiegyensúlyozott párosításon 50%-ot ér el. Nem mérhetsz második torzítást, amíg az első nincs kontroll alatt. A pozíciók felcserélése nem későbbi finomítás; ez tesz minden más mérést értelmezhetővé.

Az őszinte kikötés: ez a judge félmilliárd paraméteres modell, és senkinek nem kellene ilyennel osztályoznia. Nem az a lényeg, hogy a judge-ok rosszak. Hanem az, hogy a fenti számok előállítása nyolc percbe került, és nélkülük ennek a judge-nak az ítélete egy shipping döntésről 100% lett volna.

Ez a kurzus harmadik és utolsó deklarált Python panelje, és az ok az, ahonnan a nyilvános számok jönnek. A lm-evaluation-harness „over 60 standard academic benchmarks for LLMs, with hundreds of subtasks and variants implemented” lefedését adja, és „the backend for Hugging Face's popular Open LLM Leaderboard”; a HELM, a SWE-bench és a τ-bench Python csomagok Python belépési pontokkal.⁶ A published figure elleni modellfuttatás azt jelenti, hogy az ő kódjukat futtatod, és azon a napon, amikor egy valaki által idézett számmal akarsz összevetni, ebben az ökoszisztémában vagy:

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

A második ok az, hogy ebben a fejezetben egy mérés HTTP-n keresztül lehetetlen. Contamination — amikor a tesztkészlet kiszivárgott a training data-ba — az a hiba, amely egy nyilvános benchmarkot csendben értelmetlenné tesz, és a legélesebb szonda hozzá a modell saját lossát igényli, amit semmilyen chat API nem ad vissza. Ez a 8. fejezet tokenenkénti cross-entropyje, egy memóriáról szóló kérdésre irányítva:

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)

Tíz mondatpár: öt, amely a web minden crawl-jában benne van, amióta létezik, és öt, amelyet ma reggel írtam ehhez a fejezethez; mindegyik egy ugyanazt a tartalmat hordozó átfogalmazással párosítva.

A modell négyszer jobban meglepődik egy ma reggel írt mondaton, mint olyanon, amelyet milliószor látott, és az átfogalmazás kétszer annyiba kerül a híreseknél — a pluszköltség az a rész, amelyet memorizált, nem megértett. Az abszolút loss összekeveri a memorizálást a hétköznapi természetességgel, ezért a rés a jobb statisztika, a folytatási teszt pedig még jobb. Add meg az első hat szót:

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

Az öt híres stringből három hat szóból szó szerint folytatódott; az öt frissből egy sem. Ez egy félmilliárd paraméteres modell, amely az MIT License-t szavalja. Ha a benchmarkod a nyilvános weben van, feltételezd, hogy benne van a weightsben. Ez egyben az egész fejezet érve is: a saját adataidból írt, crawler által olvasott repositoryn kívül tartott golden set az egyetlen tesztkészlet, amelyről biztos lehetsz, hogy soha nem tanították rajta.

Még mindig érdemes olvasni őket, amíg azt olvasod, hogy mindegyik mit mér, nem pedig a hozzá ragasztott egyetlen számot.

A táblát vedd, ne bármelyik sort. Az agentic benchmarkok mind az embereket teszik messze a modellek fölé, ami a tudásbenchmarkok ellentéte, és a terület jelenlegi állapotának legjobb egymondatos összefoglalója; számaik hónapok alatt öregszenek, ezért dátummal idézd őket, amikor olvastad; és mindegyik olyan feladatot mér, amely nem a tiéd.

A pontosság az a metrika, amin vitatkoztok. Ezek döntik el, hogy shipel-e a dolog. Mind a négy kijön a már mért kétszáz futásból.

Költség megoldott feladatonként, nem hívásonként. Az agent próbálkozásonként $0.001345-be kerül, és $0.005172-be ténylegesen megoldott feladatonként — 3,85-ször többe, mert a próbálkozások háromnegyede semmit nem termel. A latency ugyanígy viselkedik: 1.213 ms próbálkozásonként, 4.667 ms megoldott feladatonként. Minden retry, minden újrakérdezés, minden elhagyott trajektória a második számban van, és láthatatlan az elsőben.

Egy diagnosztika, amely veri a pontosságot. 200 próbálkozásból 123-ban az agent egyetlen tool hívása nélkül válaszolt — találgatott, nem nézett utána. Erre bontva:

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

Az intervallumok meg sem közelítik egymást. Ez többet ér az aggregált 26%-nál, mert megnevezi a javítandó dolgot — a modell nem a reasoningben bukik el, hanem abban, hogy nem néz utána —, és a javítás a harnessben van, nem a modellben. Egy kikötéssel tartozik ez a fejezet a saját sztenderdjeinek: a két csoport különböző feladatokból áll, nem ugyanazokból párosítva, így a rés egy része abból is jöhet, hogy éppen azokon a kérdéseken hagyja ki a toolokat, amelyeket nehéznek talál. A bontás diagnosztika, nem kauzális állítás.

Human intervention rate az a metrika, amelyet egy vevő először kérdez: a futások mekkora része állt meg approvalnél, guardrailnél vagy handoffnál. A 23. fejezet tipizált megszakításai megszámolhatóvá teszik, és feladattípusonként, hetente számolva ez választja el a munkáját tanuló agentet attól, amely csendben sorban állássá válik.

Abandonment az, amit offline suite nem láthat: a user, aki elolvasta a választ, bezárta a lapot, és maga végezte el a feladatot. Az offline értékelés kapu; a production értékelés a valós forgalom folyamatos mintája, ugyanazzal a graderrel plusz ezzel a néggyel pontozva.

És egy szabály a 17. fejezetből: soha ne assertelj exact outputra. Tulajdonságokra assertelj — érvényes JSON, helyes séma, a megfelelő tool hívása, tolerancián belüli szám, kötelező substring jelenléte. A fejezet eleji exact-match oszlop az, ami akkor történik, ha ezt a szabályt megszegik.

Egy beszállító értékelése nem csak pontosságról szól, és ez a kurzus etikájának második fele, saját címmel, nem függelékként.

Mérd a torzítást, ne feltételezd. Bármit hiszel egy modell viselkedéséről neveken, dialektusokon, nemeken vagy nemzetiségeken, az a te pipeline-od mérhető tulajdonsága, és a műszer már megvan: vedd a golden seted, csak az attribútumot változtasd, hasonlíts párosítva. A HELM pontosan azért létezik, mert pusztán pontosságot jelentettek ott, ahol bias, toxicitás, kalibráció és robusztusság is eldönthető volt.⁸ Egy vendor model cardja kiindulópont, nem bizonyíték a te inputjaidról.

A contamination is beszállítói kérdés. A fenti szonda az oka annak, hogy meg kell kérdezni, min mérték a publikált számot, és mikor vágták el a modell adatait.

Retention, training és residency, 2026. szeptember 7-én olvasva. Ezek változnak, ezért rögzítsd a dátumot a válasz mellé. Az Anthropic policy oldala ezt írja: „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”, kivéve azokat a tartalmakat, amelyeket kifejezetten feedbackként küldesz be, és amelyeket „for up to 5 years” tárolnak.¹⁶ Az OpenAI data controls dokumentációja szerint „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)”, leírja az abuse-monitoring logok harmincnapos alapértelmezett retentionjét, és kínál Zero Data Retentiont, amely „excludes customer content from abuse monitoring logs”, valamint konfigurálható data residencyt régiók listáján.¹⁷

Négy kérdést kérj írásban az első production hívás előtt, mert mindegyiknek más a tulajdonosa: használják-e az adataimat trainingre; mennyi ideig őrzik meg, és ki; hol dolgozzák fel és tárolják; és mi történik mindezzel, ha nem közvetlenül a szolgáltatót, hanem viszonteladót, gatewayt vagy aggregátort használok. Az utolsónál él a legtöbb meglepetés, és ezt egyetlen benchmark sem mondja meg.

Most már megvan a műszer: saját golden set, intervallum minden számon, párosított teszt minden összehasonlításhoz, pass^k azokhoz a futásokhoz, amelyeket senkinek nem mutattál meg, mért judge, és szonda arra, hogy egy nyilvános pontszám jelent-e bármit. A 23. fejezet záró állítása most már ellenőrizhető, nem csak kijelenthető — egy harness kormányozhatóvá tesz egy agentet, nem helyessé —, és az ellenőrzés kétszáz futásba és nyolc percbe került.

Van az agentnek egy tulajdonsága, amelyet mindez nem mér, és ez az, ami miatt embereket kirúgnak.

A fejezet golden setjének minden feladatát én írtam, és minden fájlt, amelyet az agent olvasott, én írtam. Abban a könyvtárban semmi nem próbált semmit tenni. Változtass meg egy sort egy fájlban, amelyet az agentnek olvasnia kell — egy sort, amely egy instrukcióval végződik a következő olvasóhoz címezve —, és a 26%-ot elérő agent követni fogja ugyanazokkal a toolokkal, ugyanazokkal az engedélyekkel és ugyanazzal a tiszta trace-szel, miközben ebben a fejezetben minden szám pontosan ott marad, ahol volt. Egy evaluation suite azt méri, milyen gyakran éri el egy rendszer a te célodat. Nem méri, milyen könnyen cserélheti ki valaki más a sajátjára.

A 30. fejezet erről szól: prompt injection, a private data, untrusted content és external communication halálos hármasa, és mennyibe kerül valódi engedélyeket adni egy agentnek. Azzal a megfigyeléssel nyit, amelyet ez a fejezet eddig került — hogy ugyanaz a passing score kompatibilis egy olyan agenttel, amely pontosan azt teszi, amit egy támadó írt egy fájlba, amelyet olvasnia kellett.

A fenti számok mind egy gépen készültek, és egyik sem érintett fizetős endpointot. Az agent a 23. fejezet loopja a négy tool közül kettővel egy öt fájlból álló könyvtáron; a port mögötti modell Qwen/Qwen2.5-0.5B-Instruct, egy kis szerveren keresztül expose-olva, amely alakjában ugyanaz, mint egy chat completions endpoint, pontosan úgy, mint a 23. fejezetben, de fél precisionben egy consumer GPU-n, nem pedig annak a fejezetnek a CPU-ján. A költségek a 16. fejezet díjait használják — $2.00 millió input tokenenként és $12.00 millió outputonként — a mért token countsra alkalmazva. Az ismételt futások temperature 0.7-et használnak fix seedekkel, hogy a teljes készlet reprodukálható legyen; a négykarú táblázat greedy. Az intervallumok 95%-os Wilson-intervallumok, a párosított összehasonlítások kétoldali exact sign tesztek a discordant párokon; a Wilson-intervallum a 4. fejezeté, az exact párosított sign test a 15. fejezeté, mindkettő változatlanul újrahasznosítva. Az emberi címkék az enyémek, hatvan válaszra alkalmazva a szövegben idézett írott szabály szerint. Minden nagyságrendet itt egy félmilliárd paraméteres modell tulajdonságaként olvass, és minden módszert átvihetőként: egy nagyobb modell minden számot feljebb tol, és egyik műszert sem mozdítja el.