RATCHET: iteruj agenta wobec zamrożonej miarki jakości

W poprzednich wpisach tej serii rozłożyłem na czynniki dwa sposoby, w jakie agent okłamuje sam siebie: samoocena modelu to pętla autokłamstwa, a konsensus agentów to tylko echo tych samych błędów, powtórzone chórem. Skoro nie ufasz sędziemu, który sam sobie pisze wyrok, potrzebujesz czegoś, czego model nie tknie: zamrożonej miarki.

To pierwszy pozytywny wpis w serii — mniej narzekania, więcej wzorca, który u mnie po prostu działa. Nazywam go RATCHET. W inżynierii agentowej znaczy jedno: każdą iterację — prompt, model, kod agenta — porównujesz do tej samej, zamrożonej miarki. Immutable yardstick. Punkt odniesienia, który ustalasz raz i którego potem nie ruszasz.

Mechanizm jest banalny

Cała sztuczka mieści się w czterech krokach. I nie ma w nich nic z magii AI.

Zwróć uwagę na słowo „mierzalnie”. Nie „wydaje mi się, że lepiej”. Liczba albo jest wyższa, albo wracasz do poprzedniej wersji. To jest test regresji dla jakości — taki sam, jaki masz już w kodzie, tylko że mierzy sens, a nie składnię. Iteracja agenta przestaje być kwestią nastroju, a staje się zapadką: jakość może rosnąć albo stać, nigdy nie zsuwa się po cichu.

Brzmi prosto, bo jest proste. Trudność nie leży w kodzie, tylko w dyscyplinie — w tym, żeby nie ulec pokusie i nie ruszyć miarki, gdy akurat psuje Ci dobry humor. Bo właśnie w momencie, w którym wynik spada, najbardziej chcesz uwierzyć, że to test jest zły, a nie Twoja zmiana.

Poziomica, której nie wolno ruszać

RATCHET działa jak poziomica na budowie. Problem zaczyna się w sekundzie, w której zaczynasz ją podkręcać do tego, co już postawiłeś.

„Jeśli zmieniasz poziomicę w trakcie stawiania ściany, żeby pasowała do krzywizny, którą sam wyprodukowałeś, nigdy nie zbudujesz pionu.”

Dokładnie to robi większość zespołów z ewaluacją jakości. Iterują agenta, a kiedy nowa wersja wypada gorzej, „poprawiają” sam test, żeby pokazał zielone. Po trzech takich rundach miarka mierzy już tylko to, co chciałeś zobaczyć. Immutable znaczy immutable: jak raz zamrozisz yardstick, jego cyfra jest jedynym arbitrem — nawet jeśli akurat boli.

Dowód z OffBall

Nie piszę tego ze slajdów, tylko z okopów. W jednym z moich projektów, OffBall, zbudowałem taką miarkę i sprawdziłem ją na ludziach. Pytanie było proste: czy automat ocenia jakość tak samo jak ktoś, kto się na tym zna?

Oceniała prawie tak samo jak żywi eksperci — układała te same rzeczy w tej samej kolejności. Mierzone twardo, to 0,83 w korelacji rang Spearmana. Innymi słowy: ranking miarki i ranking ekspertów to praktycznie ta sama lista. Na tyle wiarygodnie, że whitepaper oparty na tej ewaluacji przeszedł trzy rundy recenzji bez ani jednej poprawki merytorycznej. Żadnej magii AI. Po prostu twarda, powtarzalna miara, której model nie umie podejść.

Dla mnie to był moment, w którym ewaluacja przestała być formalnością, a stała się narzędziem. Mogłem zmieniać model i prompt, wiedząc, że jeśli jakość spadnie, miarka powie mi to głośno — zanim zrobi to recenzent albo klient.

Iteracja na wyczucie kontra miarka

Większość zespołów iteruje na wyczucie. Zmieniają prompt, model i narzędzia naraz, odpalają kilka przykładów i mówią „chyba lepiej”. To nie jest inżynieria. To zgadywanie z dobrym PR-em. A po dwóch tygodniach nikt już nie pamięta, dlaczego agent zachowuje się tak, a nie inaczej. Ja wolę wiedzieć — wiedzieć, że nowa wersja jest o konkretne X punktów lepsza od poprzedniej i która dokładnie zmiana to dała.

• Jedna zmienna naraz. Skoro miarka jest stała, każdy ruch w górę albo w dół przypisujesz konkretnej zmianie. Bez tego nie wiesz, czy pomógł nowy model, czy nowy prompt.
• Brak miejsca na samookłamywanie. Yardstick nie zna Twoich intencji. Wyższa liczba albo revert — koniec dyskusji.
• Historia jako zapadka. Każdy regres jest widoczny i odrzucony, więc Twój system nie cofa się niezauważenie między jednym a drugim deployem.