Jak ostatnio pisałem o sędzim, który ocenia mój benchmark, zostawiłem jedną rzecz na boku. Bo tam opowiadałem o dokładaniu modelu do oceniania, a nie o tym, że model jest w tej całej maszynce ostatnią rzeczą, po którą sięgam.
Ocena modelu AI do kodowania to nie jedna liczba, tylko kilka różnych pytań: czy spełnił specyfikację, czy to w ogóle działa, czy ładnie wygląda, czy kod jest czysty i czy agent zachował się sensownie. Każde z tych pytań ma innego naturalnego sędziego. Dlatego w Refio ocenę rozbiłem na trzy warstwy: sędzia deterministyczny (mierzy to, co da się zmierzyć maszynowo), silni sędziowie LLM (czytają kod i oceniają to, czego maszyna nie zważy) oraz człowiek (gust wizualny i ostateczna decyzja). Całość jedzie tym samym silnikiem agentowym, którego używa produkcyjny plugin, tylko headless. Efekt: porównania modeli, którym można ufać, bo są wielowymiarowe, powtarzalne i odzwierciedlają realne działanie narzędzia.
„Działa u mnie” nie skaluje się do 480 prób
Każdy, kto podpinał nowy model do swojego agenta, zna ten moment. Odpalasz prompt, model wypluwa appkę, otwierasz ją w przeglądarce i mówisz „o, całkiem nieźle” albo „no bez sensu”. Próbujesz drugi raz – wychodzi coś innego. Podpinasz kolejny model i po godzinie masz w głowie mętne „ten pierwszy chyba lepszy”. To nie jest ocena, to zgadywanie z dobrą wolą.
Rankingi tego nie ratują, bo mierzą co innego: jak model radzi sobie z zamkniętymi zadankami. Nie mówią, czy twój agent, twoimi narzędziami i twoim budżetem kontekstu, wyciągnie z niego coś, co się otworzy i nie zasypie konsoli błędami. A ja mam ten problem przy tworzeniu plugina, bo Refio ma sens tylko wtedy, gdy potrafię uczciwie powiedzieć: ten lokalny model, za darmo, na twoim GPU, jest wystarczająco dobry do takich zadań, a tamten nie.
Dlaczego jedna liczba kłamie
Weźmy prawdziwe zadanie z mojego katalogu: prosty edytor 3D w przeglądarce, w jednym pliku HTML – widok sceny, dodawanie i przesuwanie obiektów, panel właściwości, zero błędów w konsoli. Jak to ocenić jedną cyfrą? Nie da się, bo w środku siedzi kilka niezależnych pytań:
- zgodność z wymaganiami – czy da się dodać obiekt, czy jest panel właściwości, czy nazwa pliku się zgadza,
- działa od razu – czy otwiera się bez ręcznego naprawiania, czy sypie błędami,
- wygląd – to jest gust, nie pomiar,
- jakość i struktura kodu – czysto czy kłąb z martwymi funkcjami,
- poprawność logiki – czy trzyma się kupy, kiedy przeczytasz kod. Ekran potrafi ładnie kłamać,
- logika agenta – czy agent sprawdził pliki, wygenerował, zweryfikował, podsumował. Czy raczej błądził.
Model potrafi wymiatać w jednym i lec w drugim – świetny wygląd przy rozjechanej logice to u mnie codzienność. A do tego dochodzi niedeterminizm: ten sam prompt dwa razy daje dwa różne pliki.
Zasada, na której to stoi
Nie oceniaj wszystkiego jednym narzędziem. Nie wołaj modelu tam, gdzie wystarczy zwykła funkcja – i nie udawaj, że regexp zważy gust.
Popatrz na skrajności. „Czy ta strona się renderuje?” ma odpowiedź binarną, sprawdzalną maszynowo; pytanie modelu „jak myślisz, czy się renderuje?” wprowadza szum tam, gdzie mogła być pewność. Po prostu ją wyrenderuj. W drugą stronę „czy to wygląda dobrze?” jest z definicji sądem estetycznym – regexp go nie zważy, a nawet mocny model zrobi to gorzej niż człowiek z gustem.
Stąd trzy warstwy.
Warstwa 1: sędzia, który nie ma opinii
Pierwsza warstwa nie ma nic wspólnego z AI i od razu ważne zastrzeżenie: to jest wskazówka, a nie wynik. Te oceny towarzyszą wpisowi, kiedy go oglądam, i tam kończy się ich rola – do finalnych rezultatów nie przechodzą. Mierzy trzy rzeczy, które da się policzyć obiektywnie z przebiegu testu e2e.
Zgodność przez markery. Do każdego zadania definiuję zestaw markerów (needles) – fragmentów treści, które muszą znaleźć się w dostarczonym pliku. Wszystkie trafiły to 1, część to 0.5, zero to 0. Marker to zwykły tekst albo regex, więc reguła jest twarda i powtarzalna. Tu pada zwykle pytanie „przecież nie ma testów jednostkowych, jak to mierzysz” – no właśnie tak. Jak artefaktem jest plik HTML, a nie funkcja z sygnaturą, to klasycznych testów nie napiszesz, ale możesz powiedzieć, co musi w nim być.
Działa od razu przez realny render. Plik ląduje w headlessowej przeglądarce. Renderuje się czysto – 1, z błędami w konsoli – 0.5, wcale – 0. Zero interpretacji. Ta warstwa wyrosła zresztą wprost z tego, o czym pisałem w kodzie, który zabija przeglądarkę: jak raz zobaczysz nieskończoną pętlę rysowania zawieszającą tab, przestajesz ufać zrzutowi ekranu jako dowodowi, że „działa”.
Logika agenta przez status i kolejność narzędzi. Przebieg musi skończyć się statusem SUCCESS, a jeśli zadanie wymaga określonej kolejności narzędzi, sprawdzam, czy jest ona ciągiem faktycznych wywołań – nie muszą iść jedno po drugim, ale porządek ma się zgadzać. SUCCESS z właściwą kolejnością to 1, ze złą 0.5, brak SUCCESS to 0.
Całość jest darmowa, natychmiastowa i w stu procentach powtarzalna. Zanim cokolwiek obejrzę, wiem już, czy strona wstała i czy agent doszedł właściwą drogą. I co ważne: świadomie nie dotyka wyglądu ani jakości kodu, bo tego mechanicznie zmierzyć się nie da.
Warstwa 2: modele, ale dopiero teraz
Druga warstwa bierze to, czego maszyna nie zważy, a uważne przeczytanie kodu owszem: strukturę kodu i poprawność logiki. Tu sąd wymaga inteligencji, więc dopiero tu wołam model (poprzez agenty Claude code i Codex). Budowę opisałem w poprzednim wpisie – folder z dowodami zamiast pytania „oceń w skali 1-10”, zrzuty w trzech momentach, klikanie w kontrolki, ocenianie na ślepo. Dwie rzeczy wynikają wprost z warstwowości.
Agreguję medianą, nie średnią. Mediana jest odporna na jednego sędziego, który odjechał, a średnia grzecznie wciąga jego odjazd do wyniku. Znane grzeszki sędziów-modeli (premiowanie gadatliwości, wrażliwość na kolejność, niespójność między przebiegami) nie znikają, ale przestają decydować, jak masz ich dwóch i bierzesz środek. Dlatego sędzia jest u mnie doradcą, a nie instancją ostateczną – mówi mi, gdzie patrzeć, a podpis pod rankingiem i tak jest mój.
Sędziowie LLM nie oceniają logiki agenta. Nie dlatego, że nie potrafią – tego, jak agent pracował na żywo, nie da się odtworzyć z martwego pliku. To pytanie o proces, nie o produkt. Dobry system oceny wie, czego jego sędziowie nie powinni dotykać.
Warstwa 3: człowiek, przycięty do minimum
Ostatnia mila należy do mnie i robię w niej jedną rzecz, której nie da się zautomatyzować: dokładam wygląd (jedyne kryterium ze skalą 0-2, bo tu jest miejsce na „lepiej, niż się spodziewałem”) i podejmuję ostateczną decyzję.
Automat składa gotowy wpis do kolejki recenzji – jest tam artefakt, zrzuty, czas, tokeny, koszt, wskazówki deterministyczne, werdykty sędziów i orientacyjne przeszedł/nie przeszedł. Wchodzę, oglądam, dokładam swoje i promuję wpis do wyników albo odrzucam. Nic, co dało się policzyć, nie jest przepisywane ręcznie. Do tego znacznik rozjazdu: pokazuje największą różnicę między moją oceną a agregatem sędziów. Działa w obie strony – albo sędzia się pomylił, albo ja przeoczyłem coś, co on wyłapał czytając kod.
Powtarzalność i skąd biorą się zadania
Skoro modele są niedeterministyczne, jeden ładny wynik może być fartem, więc osobno mierzę stabilność. U mnie to sześć prób na model i zadanie – mniej niż trzy i nie odróżnisz fartu od formy, więcej i przestaje się to opłacać przy kilkunastu modelach. Dla grupy (zadanie, model, środowisko) z co najmniej dwiema próbami liczę wariancję ocen i podobieństwo wygenerowanego kodu. Nawiasem, ta druga miara była materiałem na osobny wpis – okazało się, że wszystkie LLM-y piszą tego samego Todo App, i to dosłownie.
Same zadania mają jedno źródło prawdy: jeden opis plus jeden prompt, z którego generator emituje jednocześnie scenariusz automatyczny e2e i zadanie do recenzji w panelu. Uczyłem się tego na własnych błędach – jak masz opis zadania w dwóch miejscach, to po miesiącu masz dwa różne zadania o tej samej nazwie. Trudność jest celowo rozstrzelona: od Snake’a i Todo, przez edytor 3D, po jednoplikowe potwory typu modularny syntezator na Web Audio, symulator układów logicznych czy proceduralny świat wokselowy. Tam słabszy model po prostu pęka, i o to chodzi.
Ten sam silnik, tylko bez okienek
Najważniejsze na koniec. Benchmark nie woła modelu przez czyste API w laboratoryjnych warunkach – prowadzi go przez dokładnie ten sam silnik agentowy, te same narzędzia, ten sam pipeline kontekstu i te same zabezpieczenia, których używa produkcyjny plugin w IntelliJ. Tylko headless.
Czyli mierzę model tak, jak faktycznie doświadczysz go w Refio: z jego dyscypliną używania narzędzi i zachowaniem w pętli agenta. Przez to benchmark jest podwójnie użyteczny – ocenia modele, ale przy okazji jest moim poligonem. Kiedy guardrail zabija sensowny przebieg albo model wpada w pętlę, widzę to tutaj, zanim zobaczy to ktokolwiek inny.
Co z tego wychodzi
- Uczciwość. Model nie schowa zepsutej logiki za ładnym wyglądem, bo to dwa różne kryteria u dwóch różnych sędziów.
- Powtarzalność. Wskazówki, od których zaczynam każdy wpis, są deterministyczne, a stabilność mierzę wprost.
- Realizm. Mierzę model w tym samym silniku, w którym go używasz.
- Tanie decyzje. Dorzucam nowy lokalny model i w jedno popołudnie wiem, czy warto go wypuścić.
Filozofia mieści się w jednym zdaniu: deterministycznie tam, gdzie się da, modelem tam, gdzie trzeba, a człowiek do gustu. Banalnie proste, a zamienia „chyba ten pierwszy był lepszy” w liczby, którym mogę zaufać.
Wyniki są tutaj: benchmark.refio.dev. Jak budujesz własny harness do oceniania, ciekawi mnie, gdzie postawiłeś granicę między „policzę to sam” a „niech oceni model”. Bo podejrzewam, że większość ludzi wchodzi od razu na warstwę drugą i płaci za to szumem.
0 komentarzy