Ewaluacja LLM: od publicznych benchmarków do własnego złotego zestawu

Prawie każda kłótnia o ewaluację to dwie osoby mierzące różne rzeczy. Są trzy projekty i nie mają wspólnego instrumentu.

To pomieszanie pojęć jest kosztowne w jedną stronę. Leaderboard mówi ci, że model jest mocny w rozumowaniu na poziomie studiów magisterskich; nie powie ci, czy będzie poprawnie routować twoje zgłoszenia do supportu. A ewaluacja aplikacji, która ocenia jedną odpowiedź na wejście, w ogóle nie widzi agent, bo agent ma rozkład trajektorii, a jedna odpowiedź jest pojedynczą próbką z tego rozkładu. Rozdział 22 nazwał ten trzeci wiersz i zostawił go pusty: miara wydajności, jedyna część specyfikacji agent, którą zespoły spisują na końcu albo nigdy.

Kolejność też ma znaczenie i mówi to również dostawca sprzedający ci model. Przewodnik OpenAI po agent sprowadza wybór modelu do trzech kroków, w tej kolejności: „Skonfiguruj evals, aby ustalić baseline wydajności”, „Skup się na osiągnięciu docelowej dokładności przy użyciu najlepszych dostępnych modeli”, „Optymalizuj koszt i opóźnienie, zastępując większe modele mniejszymi tam, gdzie to możliwe”.¹ Ewaluacja jest pierwsza, bo kroki drugi i trzeci nie mają sensu bez liczby.

Złoty zestaw to lista wejść, każde z zapisaną odpowiedzią, oraz grader, który decyduje, czy output pasuje. Jest nudny, mały i jest jedynym artefaktem w tym rozdziale, który należy do ciebie. Ten zbudowany tutaj ma dwadzieścia zadań nad katalogiem pięciu plików — nie trzema z rozdziału 23, więc odpowiedzi nie są tymi samymi odpowiedziami — a grader jest napisany przed uruchomieniem 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
];

Dwie właściwości są nośne. Lista mustNot istnieje dlatego, że model, który wymienia trzy pliki, w tym właściwy, nie odpowiedział. A answer jest zapisane prozą oraz wzorcami, bo później będą tego potrzebować zarówno człowiek, jak i judge — a zapisanie tego samego faktu dwa razy w dwóch notacjach pokazuje, czy nie zgadzasz się sam ze sobą co do tego, czym było zadanie.

Teraz tabela, która decyduje. Cztery systemy kandydujące, te same dwadzieścia zadań, accuracy z przedziałem oraz dwie kolumny, które sama tabela accuracy zawsze ukrywa:

Czytaj przedziały przed zwycięzcą. Wyniki ramienia B rozciągają się od 11% do 47%; ramienia A od 3% do 30%. Nakładają się na większości swojej długości, co jest ustaleniem z rozdziału 4 dokładnie w miejscu, w którym było obiecane: dwadzieścia przypadków nie potrafi uszeregować czterech systemów. Rozdział 15 wyostrzył to, zadając zamiast tego pytanie sparowane — w przypadkach, w których dwa ramiona się różnią, jak bardzo jednostronny jest podział? — bo wspólna trudność zestawu się znosi. Oto każda para:

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

Żadne z sześciu porównań nie jest ustalone. Najlepsze ramię bije ramię bez żadnych narzędzi o piętnaście punktów, a opiera się to na trzech przypadkach niezgodnych. Dwadzieścia przypadków pokazuje mechanizm i nie potrafi wybrać dostawcy; mówienie czegoś innego na spotkaniu to sposób, w jaki kupuje się zły model.

Jest jedna rzecz, którą ta tabela ustala, i jest to kolumna, której nikt nie dodaje. Ramię D kosztuje trzynaście razy więcej niż ramię B za rozwiązane zadanie, bo próbkowanie trzech trajektorii i branie modalnej odpowiedzi potraja rachunek niezależnie od tego, czy potraja accuracy. Tabele accuracy, które pomijają koszt, czynią tę wymianę niewidzialną.

Teraz ustalenie, które zmienia sposób czytania każdego benchmarku, jaki kiedykolwiek zobaczysz. Weź te same dwieście transcriptów — dwadzieścia zadań, dziesięć uruchomień, ani jeden token nie został wygenerowany ponownie — i oceń je na trzy sposoby:

Zero, trzynaście, dwadzieścia sześć. System się nie zmienił. Zmienił się grader. Dokładne dopasowanie zwraca zero nie dlatego, że agent jest bezużyteczny, lecz dlatego, że żadna odpowiedź free-text nigdy nie jest bajt w bajt identyczna z referencją: mierzy formatowanie i raportuje je jako capability.

To nie ciekawostka, tylko mechanizm, i ma nazwę. Metryka z twardym progiem ocenia zadanie zero-jedynkowo po kilku podfaktach, więc je mnoży. Zadanie t12 pyta o trzy kody statusu naraz. W dziesięciu uruchomieniach:

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

Każdy fakt jest poprawny mniej więcej w trzech czwartych przypadków; wymaganie wszystkich trzech naraz zmniejsza wynik o połowę, a $0.77^3 = 0.457$ jest na tyle blisko zmierzonego 0.50, by pokazać, skąd wziął się spadek. Uogólnijmy:

Czytaj wiersz 0.90 wobec wiersza 0.95 przy $k = 10$: poprawa accuracy na fakt o pięć punktów staje się dwudziestoma pięcioma punktami na koniunkcji. Z modelem nie stało się nic nieciągłego. Gładka krzywa oglądana przez metrykę wszystko-albo-nic wygląda jak skok — i dokładnie taki argument Schaeffer, Miranda i Koyejo wysunęli wobec emergent abilities, co rozdział 10 odłożył do tego miejsca.² Ich audyt wykazał, że co najwyżej 5 z 39 preferowanych metryk BIG-Bench w ogóle pokazuje emergencję, a dwie nieciągłe metryki odpowiadają za ponad 92% deklarowanych przypadków.

Dyscyplina w jednym zdaniu: skok na wykresie jest dowodem dotyczącym metryki, dopóki nie pokażesz inaczej. Zanim uwierzysz, że pojawiła się capability, narysuj te same przebiegi metryką z częściowym kredytem i zobacz, czy urwisko przetrwa.

Istnieje też wersja drugiego rzędu, o której Kalai i współautorzy twierdzą, że szkodzi wyżej w łańcuchu: benchmarki oceniane jako poprawne lub błędne nagradzają zgadywanie zamiast odpowiedzi „nie wiem”, więc model optymalizowany pod nie uczy się zgadywać. Proponowanym rozwiązaniem nie jest kolejny benchmark hallucination, ale „zmodyfikowanie punktacji istniejących benchmarków, które są źle dopasowane, lecz dominują leaderboardy”.³ Twój złoty zestaw ma tę samą dźwignię i jest to jedna linia: zdecyduj, czy abstencja liczy się jako porażka, czy jako własna kategoria. Większość ludzi nigdy nie decyduje, więc po cichu liczy się jako porażka, a system, który wysyłają, zgaduje.

Wszystko do tej pory oceniało jedną próbę na zadanie. Agent nie jest jedną próbą. Rozdział 17 ustalił, że nie masz determinizmu nawet przy temperaturze zero, więc to samo wejście produkuje rozkład trajektorii, a benchmark, który uruchamia każde zadanie raz, raportuje jedną próbkę z tego rozkładu.

Wkładem τ-bench jest metryka do tego. Artykuł definiuje ją prosto: „proponujemy nową metrykę – pass^k (pass hat k), zdefiniowaną jako szansa, że wszystkie k niezależne i identycznie rozłożone próby zadania zakończą się sukcesem, uśredniona po zadaniach”.⁴ Uruchom każde zadanie $n$ razy, policz $c$ sukcesów, a nieobciążone estymatory są takie:

Drugi to znane pass@k z generowania kodu: szansa, że co najmniej jedna z $k$ prób się powiedzie. Połóż je obok siebie na tych samych zmierzonych liczbach, a poruszają się w przeciwnych kierunkach:

Te same przebiegi, ten sam grader, te same dwadzieścia zadań. Jedna kolumna mówi, że system poprawia się przy większej liczbie prób, druga mówi, że się pogarsza, i obie mają rację, bo odpowiadają na inne pytania. pass@k jest właściwą metryką, gdy człowiek filtruje output — generowanie kodu, szkice, brainstorming — a dodatkowe próby są tanie. pass^k jest właściwą metryką, gdy agent działa bez filtra, czyli wtedy, gdy naprawdę mówimy „agent”. Publikowanie pierwszej tam, gdzie stosuje się druga, to najczęstsze zawyżenie w tej dziedzinie, a własny nagłówek τ-bench jest uczciwą wersją: gpt-4o przy około 61% pass^1 w retail spada do około 25% przy pass^8.⁴

Teraz haczyk w moich własnych liczbach. pass^10 na moich dwudziestu zadaniach wynosi 5,0%: dokładnie jedno zadanie z dwudziestu rozwiązane we wszystkich dziesięciu uruchomieniach. To zadanie to t19, „Czy deploy 42 się powiódł?”, a oto dwie z dziesięciu odpowiedzi, które rubryka oceniła jako poprawne:

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

Pierwsza nigdy nie odpowiada. Druga dodaje twierdzenie fałszywe — deploy 41 został wycofany. Obie dopasowały /succe|yes/. Jedyne zadanie utrzymujące pass^10 powyżej zera jest artefaktem gradera, więc prawdziwa wartość to zero, a żaden agregat by mi tego nie pokazał. Próbkowanie transcriptów stojących za najlepiej ocenionym zadaniem to miejsce, gdzie gradery idą umrzeć.

I jeszcze jedna liczba, od której ta sekcja bierze nazwę. Dziesięć identycznych ewaluacji — ten sam system, te same dwadzieścia zadań, ten sam kod, nic niezmienione poza seedami:

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

Zakres trzydziestu punktów w systemie, który się nie zmienił. Jeśli uruchomisz suite raz przed wydaniem i raz po nim, ośmiopunktowa „poprawa” mieści się w tym rozrzucie, a ty wypuścisz ją z przekonaniem, że to twoja zasługa. Dlatego powyższy przedział łączony — 26,0% [20,4, 32,5] — jest zbyt wąski, by cytować go samodzielnie: traktuje dwieście skorelowanych prób jak dwieście niezależnych. Uczciwe podsumowanie ewaluacji agent to średnia i rozrzut między powtórzeniami, a prawie nikt nie publikuje tego drugiego.

Rubryki nie skalują się do odpowiedzi otwartych, więc standardowy ruch to kazać modelowi oceniać output. Na frontier scale działa to wystarczająco dobrze, by być domyślne, i ma trzy nazwane tryby awarii: position bias, verbosity bias i self-enhancement bias.⁵

Zmierz to, zanim temu zaufasz. Te same sześćdziesiąt odpowiedzi — trzy z dziesięciu uruchomień — oznaczono na trzy sposoby. Etykieta ludzka jest moja: przeczytałem wszystkie sześćdziesiąt z otwartymi pięcioma plikami i zastosowałem jedną zapisaną regułę: pass wtedy i tylko wtedy, gdy odpowiedź podaje fakt, o który pytało pytanie, i nie zawiera niczego sprzecznego z plikami.

Judge powiedział PASS sześćdziesiąt razy na sześćdziesiąt. Zaraportowałby tego agent jako mającego 100% accuracy na zestawie, na którym człowiek daje mu 18%. Judge bez mocy dyskryminacyjnej nie jest szumiącym instrumentem; jest funkcją stałą, a funkcja stała daje twojemu najlepszemu systemowi i twojemu najgorszemu systemowi ten sam wynik.

Prompting go nie uratował. Cztery warianty, te same sześćdziesiąt elementów:

Zamiana kolejności dwóch etykiet w instrukcji przesunęła cztery werdykty. To mierzalny efekt i jest to zły rodzaj efektu: judge reaguje na kształt prompt, a nie na odpowiedź przed sobą.

Czysta demonstracja jest parami. Dwadzieścia pytań, każde z jedną wyraźnie poprawną i jedną wyraźnie złą odpowiedzią kandydującą, pokazane w obu kolejnościach:

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 %

Wybrał pozycję A czterdzieści razy na czterdzieści. 50% poprawności nie jest częściową kompetencją — to arytmetyka, bo poprawna odpowiedź siedzi w pozycji A dokładnie w połowie prób. Spójność jest tu zdefiniowana tak, jak definiuje ją MT-Bench: „odsetek przypadków, w których judge daje spójne wyniki po zamianie kolejności dwóch assistantów”, co pozwala porównywać jabłka z jabłkami: GPT-4 osiąga 65,0% w tej mierze, a few-shot prompting podniósł to do 77,5%.⁵ Mój ma zero.

Standardowa mitigacja też pochodzi z tamtego artykułu: „wywołaj judge dwa razy, zamieniając kolejność dwóch odpowiedzi, i ogłoś zwycięstwo tylko wtedy, gdy odpowiedź jest preferowana w obu kolejnościach”.⁵ Zastosuj to tutaj, a judge produkuje zero użytecznych werdyktów z dwudziestu par — co jest wynikiem poprawnym i nieskończenie lepszym niż dwadzieścia pewnych werdyktów.

Uwaga metodologiczna warta więcej niż wynik. Uruchomiłem też test verbosity: ta sama poprawna odpowiedź, jedna kopia dopchana 36-wyrazowym zdaniem, które nic nie wnosi. Judge preferował dłuższą wersję dokładnie w 50% prób — co wygląda jak brak verbosity bias, ale wcale nim nie jest, bo judge, który zawsze wybiera pozycję A, osiąga 50% na dowolnym zbalansowanym parowaniu. Nie możesz mierzyć drugiego bias, dopóki pierwszy nie jest kontrolowany. Zamiana pozycji nie jest udoskonaleniem do dodania później; to ona czyni każdy inny pomiar interpretowalnym.

Uczciwe zastrzeżenie: ten judge to model o pół miliarda parametrów i nikt nie powinien nim oceniać. Nie chodzi o to, że judge są złe. Chodzi o to, że powyższe liczby kosztowały osiem minut, a bez nich werdykt tego judge w decyzji o wdrożeniu wyniósłby 100%.

To trzeci i ostatni zadeklarowany panel Pythona w kursie, a powodem jest miejsce, z którego pochodzą publiczne liczby. lm-evaluation-harness obejmuje „ponad 60 standardowych akademickich benchmarków dla LLMs, z setkami zaimplementowanych podzadań i wariantów” i jest „backendem popularnego Open LLM Leaderboard Hugging Face”; HELM, SWE-bench i τ-bench są pakietami Pythona z pythonowymi entry points.⁶ Uruchomienie twojego modelu wobec opublikowanej liczby oznacza uruchomienie ich kodu, a w dniu, w którym chcesz porównać się z liczbą, którą ktoś zacytował, jesteś w tym ekosystemie:

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

Drugim powodem jest to, że jeden pomiar w tym rozdziale jest niemożliwy przez HTTP. Contamination — wyciek zestawu testowego do danych treningowych — to awaria, która po cichu odbiera publicznemu benchmarkowi sens, a najostrzejsza sonda wymaga własnej straty modelu, której nie zwraca żadne chat API. To cross-entropy per token z rozdziału 8, skierowana na pytanie o pamięć:

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)

Dziesięć par zdań: pięć obecnych w każdym crawl webu od jego powstania, pięć napisanych dziś rano do tego rozdziału, każde sparowane z przeredagowaną wersją niosącą tę samą treść.

Model jest cztery razy bardziej zaskoczony zdaniem napisanym dziś rano niż takim, które widział milion razy, a przeredagowanie kosztuje dwa razy więcej na słynnych zdaniach — dodatkowy koszt to część zapamiętana, a nie zrozumiana. Bezwzględna strata miesza memorisation ze zwykłą naturalnością, więc luka jest lepszą statystyką, a test kontynuacji jest jeszcze lepszy. Daj mu pierwsze sześć słów:

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

Trzy z pięciu słynnych stringów zostały dokończone słowo w słowo od sześciu słów; żaden z pięciu świeżych nie. To model o pół miliarda parametrów recytujący MIT License. Jeśli twój benchmark jest w publicznym webie, załóż, że jest w weights. To także argument za całym rozdziałem: złoty zestaw napisany przez ciebie z własnych danych, trzymany poza każdym repozytorium czytanym przez crawler, jest jedynym test setem, o którym możesz mieć pewność, że nigdy nie był użyty w treningu.

Wciąż warto je czytać, pod warunkiem że czytasz to, co każdy z nich mierzy, a nie pojedynczą przypiętą do niego liczbę.

Weź tabelę, nie dowolny pojedynczy wiersz. Benchmarki agentic wszystkie stawiają ludzi daleko nad modelami, co jest odwrotnością benchmarków wiedzy i najlepszym jednozdaniowym podsumowaniem tego, gdzie jest dziedzina; ich liczby starzeją się w miesiące, więc cytuj je z datą odczytu; i każdy z nich mierzy zadanie, które nie jest twoje.

Accuracy to metryka, o którą się kłócisz. Te decydują, czy rzecz trafia do release. Wszystkie cztery wypadają z dwustu przebiegów już zmierzonych.

Koszt za rozwiązane zadanie, nie za call. Agent kosztuje $0.001345 za próbę i $0.005172 za faktycznie rozwiązane zadanie — 3,85 raza więcej, bo trzy czwarte prób niczego nie produkuje. Latency zachowuje się tak samo: 1,213 ms za próbę, 4,667 ms za rozwiązane zadanie. Każdy retry, każde dopytanie, każda porzucona trajektoria jest w drugiej liczbie i niewidoczna w pierwszej.

Diagnostyka, która bije accuracy. W 123 z 200 prób agent odpowiedział bez wywołania ani jednego narzędzia — zgadywał zamiast sprawdzić. Podział według tego:

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

Przedziały nawet nie zbliżają się do zetknięcia. To warte więcej niż zbiorcze 26%, bo nazywa rzecz do naprawy — model nie zawodzi w rozumowaniu, zawodzi w patrzeniu — a poprawka jest w harness, nie w modelu. Jedno zastrzeżenie, które ten rozdział jest winien własnym standardom: dwie grupy to różne zadania, nie te same zadania w parach, więc część tej luki może wynikać z tego, że pomija narzędzia dokładnie przy pytaniach, które uważa za trudne. Podział jest diagnostyką, nie twierdzeniem przyczynowym.

Wskaźnik interwencji człowieka to metryka, o którą kupujący pyta jako pierwszą: jaka część przebiegów zatrzymała się na approval, guardrail albo handoff. Typowane przerwania z rozdziału 23 czynią ją policzalną, a liczona według typu zadania i tygodnia odróżnia agent uczącego się swojej pracy od takiego, który po cichu staje się kolejką.

Porzucenie to ta, której nie zobaczy żaden offline suite: użytkownik, który przeczytał odpowiedź, zamknął kartę i zrobił zadanie samodzielnie. Offline evaluation jest bramką; production evaluation to ciągła próbka realnego ruchu, oceniana tym samym graderem plus tymi czterema.

I zasada odziedziczona z rozdziału 17: nigdy nie rób assert na dokładny output. Rób assert na właściwościach — valid JSON, poprawny schemat, wywołane właściwe narzędzie, liczba w tolerancji, obecny wymagany substring. Kolumna exact-match na początku tego rozdziału pokazuje, co dzieje się po złamaniu tej zasady.

Ewaluacja dostawcy nie dotyczy tylko accuracy i to jest druga połowa etyki tego kursu, z własnym nagłówkiem, a nie dodatkiem.

Mierz bias, nie zakładaj go. Cokolwiek sądzisz o zachowaniu modelu wobec imion, dialektów, płci czy narodowości, jest to mierzalna właściwość twojego pipeline, a instrument jest tym, który już masz: weź swój złoty zestaw, zmieniaj tylko atrybut, porównaj parami. HELM istnieje dokładnie dlatego, że raportowano samą accuracy tam, gdzie bias, toxicity, calibration i robustness również były rozstrzygalne.⁸ Model card dostawcy to punkt wyjścia, nie dowód dotyczący twoich danych wejściowych.

Contamination jest też pytaniem do dostawcy. Powyższa sonda jest powodem, by zapytać, na czym zmierzono opublikowaną liczbę i kiedy odcięto dane modelu.

Retencja, trening i residency, czytane 7 września 2026. To się zmienia, więc zapisz datę obok odpowiedzi. Strona polityki Anthropic stwierdza: „Domyślnie nie będziemy używać twoich inputs ani outputs z naszych produktów komercyjnych (np. Claude for Work, Anthropic API, Claude Gov itd.) do trenowania naszych modeli”, z wyjątkiem treści, które jawnie prześlesz jako feedback, przechowywanych „do 5 lat”.¹⁶ Dokumentacja kontroli danych OpenAI stwierdza, że „dane wysyłane do OpenAI API nie są używane do trenowania ani ulepszania modeli OpenAI (chyba że jawnie zgodzisz się udostępniać nam dane)”, opisuje domyślną trzydziestodniową retencję logów monitorowania nadużyć i oferuje Zero Data Retention, które „wyklucza treści klienta z logów monitorowania nadużyć”, plus konfigurowalne data residency na liście regionów.¹⁷

Cztery pytania, które trzeba dostać na piśmie przed pierwszym production call, bo każde ma innego właściciela: czy moje dane są używane do treningu; jak długo są przechowywane i przez kogo; gdzie są przetwarzane i przechowywane; oraz co dzieje się z tym wszystkim, jeśli używam resellera, gateway albo agregatora zamiast bezpośrednio provider. To ostatnie jest miejscem większości niespodzianek i nie powie ci tego żaden benchmark.

Masz już instrument: własny złoty zestaw, przedział przy każdej liczbie, test sparowany dla każdego porównania, pass^k dla przebiegów, których nikomu nie pokazałeś, zmierzonego judge i sondę sprawdzającą, czy publiczny wynik cokolwiek znaczy. Końcowe twierdzenie z rozdziału 23 można teraz sprawdzić zamiast ogłaszać — harness czyni agent sterowalnym, nie poprawnym — a sprawdzenie tego zajęło dwieście przebiegów i osiem minut.

Jest jedna właściwość agent, której nic z tego nie mierzy, a właśnie ona zwalnia ludzi z pracy.

Każde zadanie w złotym zestawie tego rozdziału napisałem ja i każdy plik czytany przez agent napisałem ja. Nic w tym katalogu nie próbowało nic zrobić. Zmień jedną linię w jednym pliku, który agent ma przeczytać — linię kończącą się instrukcją skierowaną do tego, co przeczyta ją następne — a agent, który uzyskał 26%, wykona ją tymi samymi narzędziami, z tymi samymi uprawnieniami i tym samym czystym trace, a każda liczba w tym rozdziale pozostanie dokładnie taka sama. Evaluation suite mierzy, jak często system osiąga twój cel. Nie mierzy, jak łatwo ktoś inny może podstawić swój.

Rozdział 30 jest właśnie o tym: prompt injection, śmiertelna triada prywatnych danych, niezaufanej treści i komunikacji zewnętrznej oraz koszt nadania agent prawdziwych uprawnień. Otwiera go obserwacja, której ten rozdział unikał — że ten sam passing score jest zgodny z agent, który robi dokładnie to, co attacker wpisał w pliku, który kazano mu przeczytać.

Każda liczba powyżej została wyprodukowana na jednej maszynie i żadna nie dotknęła płatnego endpointu. Agent to pętla z rozdziału 23 z dwoma z czterech narzędzi nad katalogiem pięciu plików; model za portem to Qwen/Qwen2.5-0.5B-Instruct, wystawiony przez mały serwer o takim samym kształcie jak endpoint chat completions dokładnie jak w rozdziale 23, ale w half precision na jednej konsumenckiej GPU zamiast CPU z tamtego rozdziału. Koszty używają stawek z rozdziału 16 — $2.00 za milion input tokens i $12.00 za milion output — zastosowanych do zmierzonych liczników token. Powtarzane przebiegi używają temperatury 0.7 ze stałymi seedami, więc cały zestaw jest odtwarzalny; tabela czterech ramion jest greedy. Przedziały to Wilson przy 95%, porównania sparowane to dwustronne dokładne testy znaków na parach niezgodnych; przedział Wilsona jest z rozdziału 4, a dokładny sparowany test znaków z rozdziału 15, oba użyte bez zmian. Etykiety ludzkie są moje, zastosowane do sześćdziesięciu odpowiedzi według pisemnej reguły cytowanej w tekście. Czytaj każdą wielkość tutaj jako właściwość modelu o pół miliarda parametrów, a każdą metodę jako przenośną: większy model podnosi wszystkie liczby i nie zmienia żadnego instrumentu.