Samoocena modelu: sędzia, który sam podpisuje sobie wyrok

Sędzia, który sprawdza własny wyrok, zawsze go uniewinni. To najkrótsza definicja błędu, który psuje 80% projektów agentowych. Budujesz system, w którym model generuje wynik, a potem ten sam model — albo jego bliźniak — dostaje zadanie: „oceń, czy to jest poprawne". I model ocenia. Zawsze na swoją korzyść.

Samoocena modelu to konflikt interesów

Wynik jest do przewidzenia. Model przepuszcza własne halucynacje, bo w jego logice brzmią przekonująco. To ta sama sieć, te same wagi, te same ślepe plamy. Pytasz autora, czy jego własny tekst jest dobry. Co spodziewasz się usłyszeć?

To jest klasyczny LLM-as-judge ustawiony tyłem do problemu. Sędzia i oskarżony to jeden model. Nikt nie krzyczy, nie zapala się żaden czerwony alert — raporty świecą na zielono, a najgorszy rodzaj awarii to właśnie ten, którego nie widać.

Weź agenta, który wyciąga dane z faktur i zapisuje je do bazy. Pomylił kwotę, ale zrobił to spójnie: tę samą błędną liczbę wpisał w polu „do zapłaty" i w podsumowaniu. Pytasz model, czy ekstrakcja się zgadza. Widzi wewnętrzną spójność i odpowiada „tak", bo z jego punktu widzenia wszystko gra. Błąd siedzi w danych wejściowych, których sędzia nigdy nie dostał do ręki.

Na dashboardzie widzisz „Status: OK", ale w bazie lądują śmieci. System działa, tylko powoli zatruwa produkt od środka.

„Drugi przebieg" niczego nie naprawia

Naturalny odruch to puścić wynik przez model jeszcze raz. Albo postawić obok bliźniaka i kazać mu sprawdzać kolegę. Tyle że bliźniak dziedziczy te same ślepe plamy. Jeśli oryginał zmyślił endpoint API, którego nie ma, kopia z tym samym treningiem uzna go za prawdopodobny i przyklepie. Dokładasz koszt i opóźnienie, a pewność rośnie tylko pozornie. To nie weryfikacja, to echo.

Weryfikacja agentów AI w dwóch warstwach

W inżynierii agentowej nie pytam modelu, czy się nie pomylił. Dzielę weryfikację na dwie warstwy, które nie ufają sobie nawzajem.

Twarda warstwa jest nudna i dlatego działa. Schemat JSON albo się waliduje, albo nie. Test przechodzi albo nie. Liczba się zgadza albo nie. Tu nie ma miejsca na „brzmi przekonująco". Większość zespołów wpycha do LLM rzeczy, które prosty walidator załatwiłby w mikrosekundę, a potem płaci za to halucynacjami w produkcji. Sprawdzasz, czy kod się kompiluje, czy URL odpowiada, czy ID istnieje w bazie. Nie pytasz o to modelu, bo model się domyśla, a kompilator wie.

Miękka warstwa to wszystko, czego nie da się sprawdzić kodem: czy odpowiedź trzyma się kontekstu, czy ton pasuje, czy rozumowanie ma sens. Tu potrzebujesz modelu, ale osobnego. Inny prompt, inna rola, zero udziału w tworzeniu wyniku. Audytor, nie współautor. Jeśli ten sam model pisze i ocenia, masz teatr, a nie kontrolę.

Kolejność też ma znaczenie. Najpierw twarda warstwa odsiewa wszystko, co jest jednoznacznie złe, i dopiero to, co przeszło, trafia do miękkiego audytora. Dzięki temu drogi model nie marnuje tokenów na wyłapywanie literówek w JSON-ie, a Ty masz dwie niezależne bramki zamiast jednej, która kibicuje sama sobie.

Radar Inżynierii Agentowej

Przez ostatnie miesiące sprawdzałem te wzorce w boju, nie na slajdach. Zebrałem 28, które naprawdę działają w produkcji. Resztę odsiałem. Ułożyłem je w Radar Inżynierii Agentowej: 4 sektory i 4 pierścienie dojrzałości, od czystej produkcji po „Ciche Awarie" na samym brzegu. Im bliżej środka, tym system bardziej przewidywalny. Im bliżej krawędzi, tym więcej rzeczy psuje się po cichu, bez jednego czerwonego alertu.

Samoocena modelu to dopiero pierwszy wzorzec. W kolejnych wpisach pokazuję, dlaczego konsensus agentów to nie weryfikacja oraz jak rozpoznać ciche awarie systemów agentowych, zanim zatrują produkcję. Jeden wpis, jeden konkretny problem, jedno rozwiązanie. Cały radar pokażę na żywo, a potem udostępnię do pobrania.