Evaluarea LLM: de la benchmark-uri publice la propriul tău set de aur

Aproape fiecare dispută despre evaluare este formată din doi oameni care măsoară lucruri diferite. Există trei proiecte și nu folosesc același instrument.

Confuzia este scumpă într-o direcție. Un leaderboard îți spune că un model este puternic la raționament de nivel postuniversitar; nu îți poate spune dacă îți va ruta tichetele de suport. Iar o evaluare de aplicație care punctează un singur răspuns per input nu poate vedea deloc un agent, pentru că un agent are o distribuție de traiectorii, iar un răspuns este o singură mostră din ea. Capitolul 22 a numit acel al treilea rând și l-a lăsat gol: măsura de performanță, singura parte din specificația unui agent pe care echipele o scriu ultima sau niciodată.

Ordinea contează și ea, iar furnizorul care îți vinde modelul spune asta. Ghidul OpenAI pentru agent reduce selecția modelului la trei pași, în această ordine: „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”.¹ Evaluarea vine prima, pentru că pașii doi și trei nu au sens fără un număr.

Un set de aur este o listă de inputuri, fiecare cu răspunsul notat, și un grader care decide dacă un output se potrivește. Este plictisitor, este mic și este singurul artefact din acest capitol care îți aparține. Cel construit aici are douăzeci de sarcini peste un director cu cinci fișiere — nu cele trei din Capitolul 23, deci răspunsurile nu sunt aceleași — iar grader este scris înainte ca agent să ruleze:

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

Două proprietăți sunt portante. Lista mustNot există pentru că un model care numește trei fișiere, inclusiv pe cel corect, nu a răspuns. Iar answer este scris în proză, precum și în patterns, pentru că atât un om, cât și un judge vor avea nevoie de el mai târziu — iar scrierea aceluiași fapt de două ori, în două notații, este modul în care afli că nu erai de acord cu tine însuți despre ce era sarcina.

Acum tabelul care decide. Patru sisteme candidate, aceleași douăzeci de sarcini, acuratețe cu intervalul ei și cele două coloane pe care un tabel doar cu acurateți le ascunde mereu:

Citește intervalele înainte de câștigător. Rulările brațului B merg de la 11 % la 47 %; cele ale brațului A de la 3 % la 30 %. Se suprapun pe cea mai mare parte din lungime, ceea ce este constatarea din Capitolul 4 ajungând exact unde fusese promisă: douăzeci de cazuri nu pot ierarhiza patru sisteme. Capitolul 15 a ascuțit asta punând în schimb întrebarea pereche — în cazurile în care două brațe nu sunt de acord, cât de dezechilibrată este împărțirea? — pentru că dificultatea comună a setului se anulează. Iată fiecare pereche:

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

Niciuna dintre cele șase comparații nu este stabilită. Cel mai bun braț bate brațul fără niciun tool cu cincisprezece puncte, iar totul se sprijină pe trei cazuri discordante. Douăzeci de cazuri arată un mecanism și nu pot alege un furnizor; a spune contrariul într-o ședință este modul în care se cumpără un model prost.

Există un lucru pe care acest tabel îl stabilește, și este coloana pe care nu o pune nimeni. Brațul D costă de treisprezece ori mai mult decât brațul B per sarcină rezolvată, pentru că eșantionarea a trei traiectorii și alegerea răspunsului modal triplează nota de plată indiferent dacă triplează sau nu acuratețea. Tabelele de acuratețe care omit costul fac acest compromis invizibil.

Acum constatarea care schimbă felul în care vei citi fiecare benchmark pe care îl vei vedea vreodată. Ia aceleași două sute de transcripturi — douăzeci de sarcini, zece rulări, niciun token regenerat — și punctează-le în trei moduri:

Zero, treisprezece, douăzeci și șase. Sistemul nu s-a schimbat. Grader s-a schimbat. Potrivirea exactă întoarce zero nu pentru că agent este inutil, ci pentru că niciun răspuns în text liber nu este vreodată identic byte cu byte cu o referință: măsoară formatarea și o raportează ca abilitate.

Asta nu este o curiozitate, este un mecanism și are un nume. O metrică hard-cutoff punctează o sarcină totul-sau-nimic peste mai multe sub-fapte, deci se compune multiplicativ. Sarcina t12 cere trei coduri de status simultan. Pe cele zece rulări:

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

Fiecare fapt este corect cam trei sferturi din timp; a le cere pe toate trei simultan înjumătățește scorul, iar $0.77^3 = 0.457$ este suficient de aproape de 0.50 măsurat ca să arate de unde a venit scăderea. Generalizează:

Citește rândul 0.90 față de rândul 0.95 la $k = 10$: o îmbunătățire per fapt de cinci puncte devine douăzeci și cinci de puncte pe conjuncție. Nu s-a întâmplat nimic discontinuu cu modelul. O curbă lină citită printr-o metrică totul-sau-nimic arată ca un salt — exact argumentul făcut de Schaeffer, Miranda și Koyejo despre abilitățile emergente, pe care Capitolul 10 l-a amânat până aici.² Auditul lor a constatat că cel mult 5 dintre cele 39 de metrici preferate ale BIG-Bench afișează vreo emergență, două metrici discontinue explicând peste 92 % din cazurile revendicate.

Deci disciplina, într-o singură linie: un salt într-un grafic este dovadă despre metrică până se arată contrariul. Înainte să crezi că a apărut o abilitate, trasează aceleași rulări cu o metrică ce acordă credit parțial și vezi dacă prăpastia supraviețuiește.

Există o versiune de ordinul doi a acestui lucru despre care Kalai și colegii susțin că produce daune mai în amonte: benchmark-urile punctate corect-sau-greșit recompensează ghicitul în locul răspunsului „nu știu”, deci un model optimizat pe ele învață să ghicească. Soluția lor propusă nu este încă un benchmark de halucinații, ci „modifying the scoring of existing benchmarks that are misaligned but dominate leaderboards”.³ Setul tău de aur are aceeași pârghie, și este o singură linie: decide dacă o abținere contează ca eșec sau ca propria categorie. Cei mai mulți nu decid niciodată, așa că ea contează în tăcere ca eșec, iar sistemul pe care îl livrează ghicește.

Tot ce a fost până acum a punctat o încercare per sarcină. Un agent nu este o încercare. Capitolul 17 a stabilit că nu ai determinism nici măcar la temperatură zero, deci același input produce o distribuție de traiectorii, iar un benchmark care rulează fiecare sarcină o singură dată raportează o mostră din ea.

Contribuția τ-bench este metrica pentru asta. Lucrarea o definește simplu: „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.”⁴ Rulează fiecare sarcină de $n$ ori, numără cele $c$ succese, iar estimatorii nepărtinitori sunt:

Al doilea este familiarul pass@k din generarea de cod: șansa ca cel puțin una dintre $k$ încercări să reușească. Pune-le una lângă alta pe aceleași numărători măsurate și se mișcă în direcții opuse:

Aceleași rulări, același grader, aceleași douăzeci de sarcini. O coloană spune că sistemul se îmbunătățește cu mai multe încercări, iar cealaltă spune că se înrăutățește, și ambele sunt corecte, pentru că răspund la întrebări diferite. pass@k este metrica potrivită când un om filtrează outputul — generare de cod, drafturi, brainstorming — iar încercările suplimentare sunt ieftine. pass^k este metrica potrivită când agent acționează fără filtru, ceea ce înseamnă „agent”. Publicarea primei acolo unde se aplică a doua este cea mai comună exagerare din acest domeniu, iar titlul propriu al τ-bench este versiunea onestă: gpt-4o la aproximativ 61 % pass^1 pe retail scade la aproximativ 25 % la pass^8.⁴

Acum lovitura din propriile mele numere. pass^10 pe cele douăzeci de sarcini ale mele este 5.0 %: exact o sarcină din douăzeci rezolvată în toate cele zece rulări. Acea sarcină este t19, „Did deploy 42 succeed?”, iar aici sunt două dintre cele zece răspunsuri pe care rubrica le-a punctat ca fiind corecte:

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

Primul nu răspunde niciodată. Al doilea adaugă o afirmație falsă — deploy 41 a fost rollback. Ambele au potrivit /succe|yes/. Singura sarcină care ține pass^10 peste zero este un artefact de grader, deci cifra reală este zero, iar niciun agregat nu mi-ar fi arătat asta. Eșantionarea transcripturilor din spatele sarcinii cu cel mai bun scor este locul unde grader-ele merg să moară.

Și încă un număr, cel după care este numită această secțiune. Zece evaluări identice — același sistem, aceleași douăzeci de sarcini, același cod, nimic schimbat în afară de seeds:

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

Un interval de treizeci de puncte pe un sistem care nu s-a schimbat. Dacă rulezi suita o dată înainte de un release și o dată după, o „îmbunătățire” de opt puncte este în interiorul acelei răspândiri și o vei livra crezând că tu ai cauzat-o. De aceea intervalul pooled de mai sus — 26.0 % [20.4, 32.5] — este prea îngust ca să fie citat singur: tratează două sute de încercări corelate ca pe două sute de încercări independente. Rezumatul onest al unei evaluări de agent este o medie și o răspândire între repetări, iar aproape nimeni nu o publică pe a doua.

Rubricile nu se scalează la răspunsuri deschise, așa că mișcarea standard este să pui un model să noteze outputul. Funcționează suficient de bine la frontier scale încât să fie implicită și are trei moduri de eșec numite: position bias, verbosity bias și self-enhancement bias.⁵

Măsoară-l înainte să ai încredere în el. Aceleași șaizeci de răspunsuri — trei dintre cele zece rulări — au fost etichetate în trei moduri. Eticheta umană este a mea: am citit toate cele șaizeci cu cele cinci fișiere deschise și am aplicat o singură regulă scrisă, trece dacă și numai dacă răspunsul afirmă faptul cerut de întrebare și nu conține nimic contrazis de fișiere.

Judge a spus PASS de șaizeci de ori din șaizeci. Ar fi raportat acest agent la 100 % acuratețe pe un set unde omul îl punctează la 18 %. Un judge fără putere discriminativă nu este un instrument zgomotos; este o funcție constantă, iar o funcție constantă dă același scor celui mai bun sistem al tău și celui mai slab.

Prompting nu l-a salvat. Patru variante, aceleași șaizeci de elemente:

Inversarea ordinii celor două etichete din instrucțiune a mutat patru verdicte. Este un efect măsurabil și este tipul greșit de efect: judge răspunde la forma prompt mai degrabă decât la răspunsul din fața lui.

Demonstrația curată este pe perechi. Douăzeci de întrebări, fiecare cu un candidat evident corect și unul evident greșit, prezentate în ambele ordine:

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 ales poziția A de patruzeci de ori din patruzeci. Cei 50 % pe corectitudine nu sunt competență parțială — sunt aritmetică, pentru că răspunsul corect stă în poziția A în exact jumătate dintre încercări. Consistența aici este definită așa cum o definește MT-Bench, „the percentage of cases where a judge gives consistent results when swapping the order of two assistants”, ceea ce permite comparației să fie mere cu mere: GPT-4 obține 65.0 % pe acea măsură, iar few-shot prompting a ridicat-o la 77.5 %.⁵ Al meu obține zero.

Mitigarea standard vine tot din acea lucrare: „call a judge twice by swapping the order of two answers and only declare a win when an answer is preferred in both orders.”⁵ Aplic-o aici și judge produce zero verdicte utilizabile din douăzeci de perechi — ceea ce este rezultatul corect și infinit mai bun decât douăzeci de verdicte încrezătoare.

O notă metodologică mai valoroasă decât rezultatul. Am rulat și un test de verbosity: același răspuns corect, cu o copie umplută cu o propoziție de 36 de cuvinte care nu adaugă nimic. Judge a preferat versiunea mai lungă în exact 50 % dintre încercări — ceea ce arată ca absența verbosity bias și nu este deloc asta, pentru că un judge care alege mereu poziția A obține 50 % pe orice pereche echilibrată. Nu poți măsura un al doilea bias până când primul nu este controlat. Inversarea pozițiilor nu este un rafinament de adăugat mai târziu; este ceea ce face fiecare altă măsurătoare interpretabilă.

Avertismentul onest: acest judge este un model de jumătate de miliard de parametri, iar nimeni nu ar trebui să noteze cu unul. Ideea nu este că judge-urile sunt rele. Ideea este că numerele de mai sus au costat opt minute să fie produse, iar fără ele verdictul acestui judge asupra unei decizii de livrare ar fi fost 100 %.

Acesta este al treilea și ultimul panou Python declarat al cursului, iar motivul este locul de unde vin numerele publice. lm-evaluation-harness acoperă „over 60 standard academic benchmarks for LLMs, with hundreds of subtasks and variants implemented” și este „the backend for Hugging Face's popular Open LLM Leaderboard”; HELM, SWE-bench și τ-bench sunt pachete Python cu puncte de intrare Python.⁶ A rula modelul tău față de o cifră publicată înseamnă a rula codul lor, iar în ziua în care vrei să compari cu un număr citat de cineva, acesta este ecosistemul în care te afli:

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

Al doilea motiv este că o măsurătoare din acest capitol este imposibilă peste HTTP. Contaminarea — setul de test care s-a scurs în datele de antrenare — este eșecul care face un benchmark public să devină, în tăcere, lipsit de sens, iar cea mai ascuțită probă pentru el are nevoie de loss-ul propriu al modelului, pe care nicio chat API nu îl întoarce. Este cross-entropy per token din Capitolul 8, îndreptată către o întrebare despre memorie:

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)

Zece perechi de propoziții: cinci aflate în fiecare crawl al webului de când există, cinci scrise pentru acest capitol în această dimineață, fiecare împerecheată cu o versiune reformulată care poartă același conținut.

Modelul este de patru ori mai surprins de o propoziție scrisă în această dimineață decât de una pe care a văzut-o de un milion de ori, iar reformularea costă de două ori mai mult pe cele celebre — costul suplimentar fiind partea memorată mai degrabă decât înțeleasă. Loss-ul absolut confundă memorarea cu naturalețea obișnuită, deci diferența este statistica mai bună, iar testul de continuare este și mai bun. Dă-i primele șase cuvinte:

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

Trei dintre cele cinci șiruri celebre au continuat perfect, cuvânt cu cuvânt, de la șase cuvinte; niciunul dintre cele cinci proaspete nu a făcut-o. Acesta este un model de jumătate de miliard de parametri recitând MIT License. Dacă benchmark-ul tău este pe webul public, presupune că este în weights. Este și argumentul întregului capitol: un set de aur scris de tine din datele tale, ținut departe de orice repository citit de un crawler, este singurul set de test despre care poți fi sigur că nu a fost niciodată folosit la antrenare.

Merită încă citite, atâta timp cât citești ce măsoară fiecare, nu numărul unic atașat lui.

Ia tabelul, nu un rând anume. Benchmark-urile agentic pun toate oamenii mult peste modele, ceea ce este opusul benchmark-urilor de cunoștințe și cel mai bun rezumat într-o singură linie al locului în care se află domeniul; cifrele lor îmbătrânesc în câteva luni, deci citează-le cu data la care le-ai citit; și fiecare măsoară o sarcină care nu este a ta.

Acuratețea este metrica despre care te cerți. Acestea sunt cele care decid dacă lucrul se livrează. Toate patru ies din cele două sute de rulări deja măsurate.

Cost per sarcină rezolvată, nu per call. agent costă $0.001345 per încercare și $0.005172 per sarcină efectiv rezolvată — de 3.85 ori mai mult, pentru că trei sferturi dintre încercări nu produc nimic. Latența se comportă la fel: 1,213 ms per încercare, 4,667 ms per sarcină rezolvată. Fiecare retry, fiecare re-ask, fiecare traiectorie abandonată este în al doilea număr și invizibilă în primul.

Un diagnostic care bate acuratețea. În 123 din 200 de încercări agent a răspuns fără să apeleze niciun tool — a ghicit în loc să caute. Împărțind după asta:

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

Intervalele nici nu se apropie de atingere. Asta valorează mai mult decât agregatul de 26 %, pentru că numește lucrul de reparat — modelul nu eșuează la raționament, eșuează la a se uita — iar remedierea este în harness, nu în model. O rezervă pe care acest capitol o datorează propriilor standarde: cele două grupuri sunt sarcini diferite, nu aceleași sarcini împerecheate, deci o parte din diferență poate fi faptul că sare peste tool-uri tocmai la întrebările pe care le găsește grele. Împărțirea este un diagnostic, nu o afirmație cauzală.

Rata de intervenție umană este metrica pe care un cumpărător o cere prima: ce fracțiune din rulări s-a oprit la o aprobare, un guardrail sau un handoff. Întreruperile tipizate din Capitolul 23 o fac numărabilă, iar numărată per tip de sarcină și per săptămână este ceea ce separă un agent care își învață treaba de unul care devine în tăcere o coadă.

Abandonul este cea pe care nicio suită offline nu o poate vedea: utilizatorul care a citit răspunsul, a închis tabul și a făcut singur sarcina. Evaluarea offline este o poartă; evaluarea în producție este un eșantion continuu de trafic real, punctat cu același grader plus aceste patru metrici.

Și o regulă moștenită din Capitolul 17: nu face niciodată aserțiuni pe output exact. Fă aserțiuni pe proprietăți — JSON valid, schema corectă, tool-ul potrivit apelat, un număr în toleranță, un substring necesar prezent. Coloana de potrivire exactă de la începutul acestui capitol este ce se întâmplă când regula este încălcată.

Evaluarea unui furnizor nu este doar despre acuratețe, iar aceasta este a doua jumătate a eticii din acest curs, cu propriul titlu în loc de anexă.

Măsoară bias-ul, nu îl presupune. Indiferent ce crezi despre comportamentul unui model pe nume, dialecte, genuri sau naționalități, este o proprietate măsurabilă a pipeline-ului tău, iar instrumentul este cel pe care îl ai deja: ia setul tău de aur, variază doar atributul, compară pereche. HELM există tocmai pentru că acuratețea singură era raportată acolo unde bias-ul, toxicitatea, calibrarea și robustețea erau și ele decidabile.⁸ Model card-ul unui furnizor este un punct de pornire, nu dovadă despre inputurile tale.

Contaminarea este și o întrebare pentru furnizor. Proba de mai sus este motivul să întrebi pe ce a fost măsurat un număr publicat și când a fost tăiat setul de date al modelului.

Retenție, antrenare și rezidență, citite pe 7 septembrie 2026. Acestea se schimbă, deci notează data lângă răspuns. Pagina de politici Anthropic afirmă: „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”, cu excepția conținutului pe care îl trimiți explicit ca feedback, care este stocat „for up to 5 years”.¹⁶ Documentația OpenAI privind controalele de date afirmă că „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)”, descrie o retenție implicită de treizeci de zile pentru logurile de monitorizare a abuzurilor și oferă Zero Data Retention, care „excludes customer content from abuse monitoring logs”, plus rezidență de date configurabilă într-o listă de regiuni.¹⁷

Patru întrebări de obținut în scris înainte de primul call de producție, pentru că fiecare are un proprietar diferit: datele mele sunt folosite pentru antrenare; cât timp sunt reținute și de cine; unde sunt procesate și stocate; și ce se întâmplă cu toate acestea dacă folosesc un reseller, un gateway sau un agregator în locul providerului direct. Ultima este locul unde trăiesc cele mai multe surprize, și niciun benchmark nu îți va spune.

Acum ai instrumentul: un set de aur pe care îl deții, un interval pe fiecare număr, un test pereche pentru fiecare comparație, pass^k pentru rulările pe care nu le-ai arătat nimănui, un judge măsurat și o probă pentru dacă un scor public înseamnă ceva. Afirmația finală din Capitolul 23 poate fi acum verificată în loc să fie afirmată — un harness face un agent guvernabil, nu corect — iar verificarea ei a luat două sute de rulări și opt minute.

Există o proprietate a unui agent pe care nimic din toate acestea nu o măsoară, și este cea care face oameni să fie concediați.

Fiecare sarcină din setul de aur al acestui capitol a fost scrisă de mine, iar fiecare fișier citit de agent a fost scris de mine. Nimic din acel director nu încerca să facă nimic. Schimbă o linie într-un fișier pe care agent este instruit să îl citească — o linie care se termină cu o instrucțiune adresată oricărui lucru o citește mai departe — iar agent care a punctat 26 % o va urma cu aceleași tool-uri, aceleași permisiuni și același trace curat, iar fiecare număr din acest capitol va rămâne exact unde este. O suită de evaluare măsoară cât de des un sistem ajunge la obiectivul tău. Nu măsoară cât de ușor poate altcineva să îl înlocuiască cu al lui.

Capitolul 30 este despre asta: prompt injection, trifecta letală a datelor private, conținutului neîncrezător și comunicării externe, și cât costă să dai unui agent permisiuni reale. Se deschide cu observația pe care acest capitol a evitat-o — că același scor de trecere este compatibil cu un agent care face exact ce a scris un atacator într-un fișier pe care i s-a spus să îl citească.

Fiecare număr de mai sus a fost produs pe o singură mașină și niciunul nu a atins un endpoint plătit. agent este bucla din Capitolul 23 cu două dintre cele patru tool-uri peste un director cu cinci fișiere; modelul din spatele portului este Qwen/Qwen2.5-0.5B-Instruct, expus printr-un server mic cu aceeași formă ca un endpoint de chat completions exact ca în Capitolul 23, dar în half precision pe un GPU consumer în loc de CPU-ul acelui capitol. Costurile folosesc ratele din Capitolul 16 — $2.00 per milion de input tokens și $12.00 per milion de output — aplicate numărătorilor măsurate de tokens. Rulările repetate folosesc temperatura 0.7 cu seeds fixe, astfel încât întregul set se reproduce; tabelul cu patru brațe este greedy. Intervalele sunt Wilson la 95 %, comparațiile pereche sunt teste exacte ale semnelor, bilaterale, pe perechile discordante; intervalul Wilson este cel din Capitolul 4, iar testul exact al semnelor pereche este cel din Capitolul 15, ambele reutilizate neschimbate. Etichetele umane sunt ale mele, aplicate la șaizeci de răspunsuri sub regula scrisă citată în text. Citește fiecare magnitudine de aici ca proprietate a unui model de jumătate de miliard de parametri și fiecare metodă ca transferabilă: un model mai mare mută toate numerele în sus și nu mută niciunul dintre instrumente.