Pułapka nasycenia: kiedy Twoja ewaluacja bazowa jest zbyt dobra, by ją mierzyć
W bezpośrednim porównaniu 14 zadań (2026-06-11) nasz jednoseansowy model bazowy uzyskał wynik 0,984 i zremisował w 13 z 14 zadań. Dzięki temu wyzwanie, które nigdy nie było gorsze, zanotowało 7,1% przewag, podczas gdy próg 60% uniemożliwił jego wdrożenie. Bramka przestała mierzyć wyzwanie, a zaczęła mierzyć same zadania.

Brama ewaluacji porównawczej („nowy system musi pokonać stary w co najmniej 60% zadań”) cicho przestaje działać w momencie, gdy baza nasyca się kryteriami oceny. Stało się to również w naszym przypadku. Zbudowaliśmy bramę porównawczą, aby zdecydować, czy bardziej złożony potok wieloetapowy zasługuje na miejsce obok naszego wdrożonego jednoseansowego zachowania. Przeprowadziliśmy test i otrzymaliśmy werdykt, który wyglądał na jednoznaczną rezygnację: 7,1% przewag przy progu 60%. W tej rundzie model wyzwania nigdy nie był gorszy w żadnym zadaniu: zremisował w 13 z 14 i wygrał to, którego nie zremisował. Wynik nie mówił nam, że model wyzwania zawiódł. Mówił, że nasze zadania były zbyt łatwe, by odróżnić oba systemy, i prawie pomyliliśmy jeden z drugim.
Ta porażka ma kształt, który warto nazwać, ponieważ jest niewidoczna, dopóki nie spojrzymy na bezwzględny wynik bazy. Nazywamy ją pułapką nasycenia: gdy baza osiąga wynik bliski maksimum, wskaźnik przewag przestaje mierzyć wyzwanie.
Bramka, którą zbudowaliśmy
Decyzja była konkretna. Potok wieloetapowy (planowanie, następnie wykonanie, następnie weryfikacja) jest droższy w działaniu niż jednoseansowy model, ponieważ wykonuje kilka wywołań modelu, podczas gdy model jednoseansowy wykonuje jedno. Dlatego próg nie brzmiał „czy jest dobry”, tylko „czy jest wyraźnie lepszy, by uzasadnić dodatkowy koszt”. Jeśli tylko dorównywał modelowi jednoseansowemu, oznaczało to wzrost kosztów bez wzrostu jakości i nie powinien zostać wdrożony. (Celowo nie publikujemy wewnętrznej struktury modelowej potoku ani ekonomii na token; lekcja dotyczy tutaj ewaluacji, a nie naszego routingu.)
Zoperacjonalizowaliśmy „wyraźnie lepszy” jako dwie linie, które musiały zostać spełnione jednocześnie, ponieważ każda z nich z osobna może być manipulowana:
- Wskaźnik przewag co najmniej 60%. Model wyzwania musi wygrać wyraźnie w co najmniej 60% zadań. Remisy liczą się przeciwko niemu: remis przy wyższym koszcie to strata w kategoriach produktu. Ustawiliśmy próg na 60%, a nie 50%, aby wynik musiał przetrwać szum sędziów na małym zbiorze zadań; 7 na 12 zaledwie to wynik, który można odwrócić jednym zmienionym osądem.
- Średnia delta wyniku ściśle dodatnia. Średnia różnica wyników na zadanie (model wyzwania minus baza) musi być powyżej zera, aby kilka wąskich zwycięstw nie maskowało dużych regresji gdzie indziej.
Zbiór zadań składał się z 14 głównych przepływów w w pełni syntetycznym środowisku roboczym: fikcyjne 30-osobowe SaaS przetwarzające z celowo wprowadzonymi defektami (przestarzała polityka ISMS cytująca wycofany ISO/IEC 27001:2013, polityka kontroli dostępu z samoprzeciwstawną regułą MFA, szablon reagowania na incydenty, częściowy spis przetwarzania). Brak danych klientów. Każde zadanie miało kryteria oceny niezależnie kwalifikowalne, binarne, oceniane przez sędziego LLM (claude-haiku-4-5, temperatura 0, jeden werdykt JSON na kryterium). Sędzia widział jedynie opublikowane rezultaty, nigdy wewnętrzny plan potoku, więc plan obiecujący „uwzględnić art. 28(3)” nie mógł uzyskać punktów, których nie zawierał ostateczny dokument.
Przeprowadzony test i dwie linie, które się sprzeczały
Oto pełny wynik. Baza to jednoseansowy model (claude-opus-4-6); model wyzwania to potok wieloetapowy, którego wewnętrzna struktura modelowa trzymamy z dala, ponieważ dotyczy routingu. To w porządku, ponieważ lekcja dotyczy architektury i nie zależy od tego, który model znajduje się wewnątrz potoku. Jeden przebieg na system, 2026-06-11.
| Miara | Wartość |
|---|---|
| Średni wynik bazy (14 zadań) | 0,984 |
| Średni wynik wyzwania (14 zadań) | 1,000 |
| Remisy | 13 z 14 |
| Przewagi wyzwania | 1 |
| Porażki wyzwania | 0 |
| Wskaźnik przewag (remisy liczą się przeciwko wyzwaniu) | 7,1% (1/14) |
| Średnia delta wyniku (wyzwanie minus baza) | +0,016 |
Odczytaj bramkę w kontekście tych liczb, a dwie linie się sprzeczają. Linia średniej delty przechodzi: model wyzwania jest, średnio rzecz biorąc, bardzo nieznacznie lepszy i nigdy gorszy. Linia wskaźnika przewag załamuje się katastrofalnie: 7,1% przy progu 60%. Pojedyncza bramka, która mówi zarówno „model wyzwania jest co najmniej tak dobry we wszystkich zadaniach”, jak i „model wyzwania przegrywa w 93% przypadków”, nie mierzy modelu wyzwania. Ta sprzeczność to sygnatura pułapki nasycenia i to jest znak, na który należy uważać.
Mechanizm jest arytmetyczny, nie sądowy. Baza uzyskała wynik doskonały 1,0 w 13 z 14 zadań. W zadaniu, w którym baza już uzyskała 1,0, najlepsze, co może zrobić model wyzwania, to zremisować, ponieważ nie ma miejsca powyżej 1,0, by wygrać. A remisy, zgodnie z naszym założeniem, liczą się przeciwko niemu. Tak więc kryterium, które baza opanowała, zamienia prawie każde zadanie w strukturalną porażkę dla modelu wyzwania, niezależnie od tego, jak dobry jest model wyzwania. Wskaźnik przewag przestał być właściwością modelu wyzwania i stał się właściwością zbioru zadań: konkretnie, udział zadań, które baza pozostawiła do pokonania. Zostawiła jedno.
Jedyne miejsce, w którym baza straciła punkty
Spójrz na jedyne zadanie, w którym baza nie uzyskała wyniku doskonałego 1,0. Uzyskała 0,78 i to nie dlatego, że nie mogła wykonać pracy. Było to zadanie, w którym zrobiła zbyt wiele: poproszona o przygotowanie brakującej dokumentacji GDPR zgodnie z kryteriami określającymi trzy do pięciu artefaktów, model jednoseansowy wyprodukował siedem. Każdy artefakt był kompetentny i poprawnie cytowany. Jego jedyną stratą punktową w całym przebiegu była kara za nadmierne dostarczenie, za niedostrzeżenie, kiedy przestać.
To cała lekcja w jednym punkcie danych. Gdy oba systemy potrafią wykonać zadanie, „czy potrafi wykonać zadanie” przestaje być pytaniem, na które ewaluacja powinna odpowiadać, ponieważ oba odpowiadają „tak” i remisują. Pozostają jedynie porażki do ocenienia: porażki powściągliwości: zrobienie zbyt wiele, powiedzenie zbyt wiele, cytowanie zbyt pewnie, twierdzenie rzeczy, których nie powinno się twierdzić. Nasze pierwsze kryterium mierzyło zdolność, baza nasyciła je, a jedyny sygnał, który przetrwał, to porażka powściągliwości, której prawie nie napisaliśmy, by ją uchwycić.
„Więc wdróż bazę”
Szczery zarzut wobec całej tej sytuacji jest taki, że baza uzyskująca 0,984 mówi Ci, by wdrożyć bazę i pominąć drogi potok. Jeśli tani model jest tak dobry, dlaczego nadal mierzyć? To uczciwe wyzwanie i jest w połowie słuszne: w tych zadaniach tani model był rzeczywiście tak dobry, a to realne spostrzeżenie.
Jest w połowie słuszne, ponieważ nasycenie w zadaniach zdolnościowych nic nie mówi o zadaniach powściągliwości, a powściągliwość to dokładnie obszar, w którym potok wieloetapowy (który może sprawdzić swoją pracę przed jej opublikowaniem) mógłby rzeczywiście wysunąć się na prowadzenie lub spaść z powodu własnego nadmiaru. Nasze główne przepływy nie badały tego. Jedyny, który przypadkowo to zrobił (zadanie nadmiernego dostarczenia), był jedynym, który się poruszył. Tak więc 0,984 nie było dowodem na to, że oba systemy są równoważne. Było dowodem na to, że nasze zadania nie potrafiły ich odróżnić na osi, która pozostała. Nasycenie to stwierdzenie o Twoim kryterium, nigdy werdykt o równoważności Twoich systemów.
Co zmieniliśmy
Nie przeprowadziliśmy ponownie testu bramki. Ponowne przeprowadzenie nasyconej ewaluacji nie może podnieść wskaźnika przewag, ponieważ model wyzwania nie może uzyskać wyniku powyżej 1,0 bazy w zadaniach, w których już remisuje; ponowny przebieg po prostu odtworzy ten sam pułap przy większym koszcie. Zamiast tego wzmocniliśmy zbiór zadań, dodając zadania, których kryteria mocny model jednoseansowy może naprawdę nie zdać, każde ukierunkowane na oś powściągliwości, którą główne przepływy zignorowały:
- Dyscyplina zakresu: przygotuj dokładnie trzy dokumenty onboardingu, nie więcej. Ocenia odruch nadmiernego dostarczania, który kryje się za jedyną stratą bazy.
- Pominięcie odpowiednie dla odbiorcy: e-mail bezpieczeństwa skierowany do klienta plus nota wewnętrzna, gdzie przestrzeń robocza zawiera wewnętrzną notatkę partnerską. Ocenia, czy model utrzymuje poufną treść z dala od artefaktu skierowanego na zewnątrz.
- Poprawność cytowań: plan audytu wewnętrznego, który musi cytować właściwą normę dla danej tezy, a nie prawdopodobnie brzmiącą błędną. Ocenia, czy model nie cytuje błędnych standardów.
- Postępowanie z niezweryfikowanymi dowodami: raport statusu audytu, w którym audyt jest nadal w toku. Ocenia, czy model raportuje to, co zweryfikował, zamiast twierdzić ukończenie, którego nie może poprzeć.
Szkielet anty manipulacyjny, który umożliwił bezpieczne iterowanie, warto przedstawić jasno, ponieważ wzmocniony zbiór zadań jest wart tyle, ile warte jest dyscyplina wokół niego. Kanoniczny zestaw identyfikatorów zadań jest zamrożony i zahaszowany (sha256 nad identyfikatorami zadań, kryteriami i dokumentami fixture, wraz z wersją modelu sędziego), a odczyt bramki jest akceptowany jedynie dla tej dokładnej wersji: brak podzbiorów, brak dodatków. To utrudnia ciche wybieranie zadań, które dają pożądany werdykt, a nieaktualny lub ręcznie edytowany raport nie może cicho zablokować wydania.
Granice tego podejścia
Jeden przebieg na system, jeden model sędziego, 14 zadań. Pojedynczy sędzia oceniający kryteria binarne ma wariancję, a to jest cała przyczyna, dla której próg wskaźnika przewag wynosi 60%, a nie 50%. Baza również działała z rzeczywistym systemowym promptem produkcyjnym, ale bez pamięci, zapisanych umiejętności i wyszukiwania sieciowego, które może mieć żywa sesja, a każda z tych luk osłabia bazę w porównaniu z rzeczywistym jednoseansowym modelem, co ułatwia wyzwaniu, a nie utrudnia. Innymi słowy, rzeczywista baza jest prawdopodobnie jeszcze bardziej nasycona niż 0,984. Te liczby są punktowe na dzień 2026-06-11. Nie opublikowaliśmy odczytu bramki na wzmocnionym zbiorze zadań; celem tego wpisu jest porażka, którą ujawnił pierwszy przebieg, a nie nowy werdykt.
To inna porażka niż metryka, która pozostaje zielona, podczas gdy produkt się psuje, o której pisaliśmy osobno. Tamta liczba kłamała. Ta liczba mówiła prawdę (baza naprawdę jest tak mocna w tych zadaniach) i nadal nie mogła odpowiedzieć na pytanie, które jej zadaliśmy. Obie są sposobami, w jakie ewaluacja, która wygląda na przechodzącą, może być bezwartościowa, i wymagają przeciwnych napraw: pierwsza potrzebuje lepszej metryki, druga — trudniejszych zadań.
Lista kontrolna dla bram porównawczych
- Przeczytaj bezwzględny wynik bazy, zanim zaufasz wskaźnikowi przewag. Jeśli baza znajduje się blisko Twojego pułapu, próg wskaźnika przewag jest strukturalnie nieosiągalny. Napraw zadania, nie przeprowadzaj ponownie testu.
- Obserwuj wskaźnik remisów. Sterta remisów to nasycone kryterium, a nie prawdziwy remis. Jeśli większość zadań kończy się remisem, Twój zbiór nie ma miejsca na zwycięstwo żadnej ze stron.
- Zdecyduj, co oznaczają remisy, zanim odczytasz wynik. Gdy remisy liczą się przeciwko wyzwaniu, nasycona baza zamienia lepszy system w werdykt porażki. Może to być właściwa polityka (nasza była, ze względu na koszty), ale wiedz, że ją wybierasz.
- Traktuj sprzeczne linie bramki jako diagnostykę. Jeśli Twoja linia średniej delty przechodzi, podczas gdy linia wskaźnika przewag załamuje się, to nie jest mieszany wynik do uśrednienia. To nasycenie ogłasza się samo.
- Oceniaj powściągliwość, nie tylko zdolność. Gdy oba systemy potrafią wykonać zadanie, dyskryminującymi porażkami są nadmierne dostarczanie, wycieki do odpowiedniej grupy odbiorców, nadmierne cytowanie i twierdzenie nie zweryfikowanych faktów. Napisz zadania, w których mocny model przegrywa, robiąc zbyt wiele.
- Zaprojektuj co najmniej jedno zadanie, w którym baza przegra. Jeśli nic nie rozdziela Twoich systemów, nie zmierzyłeś ich. Zmierzyłeś swój zbiór zadań i stwierdziłeś, że jest zbyt łatwy.
- Zamroź i zahaszuj kanoniczny zestaw. Abyś ani przyszłe wydanie nie mogło cicho wybrać zadań dających pożądaną odpowiedź.
Pułapka nie polega na tym, że baza była dobra. Dobre bazy są celem. Pułapka polega na odczytywaniu wskaźnika przewag jako faktu o wyzwaniu, gdy stał się on faktem o zadaniach. Gdy porównanie się nasyca, ewaluacja przestaje mówić Ci o Twoich modelach i zaczyna mówić o Twoim kryterium. Użyteczny ruch to posłuchanie tej drugiej wiadomości i napisanie zadania na tyle trudnego, by mocny model je przegrał.
Powyższe dane pochodzą z wewnętrznej ewaluacji porównawczej, przeprowadzonej 2026-06-11, baza claude-opus-4-6 (jednoseansowy) przeciwko potokowi wieloetapowemu plan-execute-verify, ocenianej przez claude-haiku-4-5, na 14 zadaniach w w pełni syntetycznym środowisku roboczym bez treści klientów. Punktowy na dzień 2026-06-11. Kontekst ramowy: ISO/IEC 27001:2022, RODO (art. 28, art. 30).
