Kto ocenia oceniającego? Weryfikacja zestawów do oceny agentów przed zaufaniem im.

W 2026 roku prawie każdy zespół wprowadzający agenta AI korzysta również z zestawu narzędzi do oceny, zawierającego panele kontrolne, wskaźniki skuteczności, bramy CI oraz systemy oceny LLM, które oceniają wyniki według określonych kryteriów. Wszystko to świadczy o rygorze i wydaje się odróżniać system produkcyjny od demonstracji, która przypadkowo zadziałała dwa razy.

Jednak gdy postawi się następne oczywiste pytanie, robi się cicho. Kto sprawdził, czy ten zestaw rzeczywiście mierzy to, co należy, czy robi to prawidłowo i czy nadal podaje prawdę pół roku po jego stworzeniu? Prawie nikt. Przemysł spędził dwa lata na budowie narzędzi do oceny agentów, a dopiero teraz zaczyna tworzyć narzędzia do oceny tych narzędzi. Ta luka jest już widoczna w systemach produkcyjnych, w kilku przewidywalnych sposobach.

Przypuszczenie, którego nikt nie formułuje

Za większością systemów oceny agentów kryje się niewypowiedziane założenie: wynik pozytywny oznacza, że agent zachował się prawidłowo, a negatywny – że tak nie zrobił. Jeśli to zaakceptujemy, cały zestaw narzędzi staje się czarną skrzynką, której ludzie automatycznie ufają. Panel sterowania pokazuje zielony kolor, fuzja zmian przebiega pomyślnie, a zespół przechodzi do kolejnych zadań.

Badania nad śladami działania agentów zaczęły podważać to założenie. Jedno z badań przeanalizowało 58 takich śladów, które system oceny uznał za udane, i odkryło, że u 83 procent z tych przypadków kryły się naruszenia procedur lub zasad bezpieczeństwa, których system oceny w ogóle nie wykrył. Agent podał prawidłową odpowiedź i otrzymał perfekcyjną ocenę, mimo że wybrana przez niego ścieżka była w rzeczywistości błędna. Różnica pomiędzy wynikiem końcowym a procesem jest właśnie tym, co ma wykrywać system oceny, a co z konstrukcyjnego punktu widzenia większość takich systemów nie jest w stanie dostrzec.

Cztery wzorce awarii zasługują na odrębne nazwy. Każdy z nich wymaga własnego rozwiązania, a zespoły zazwyczaj zauważają tylko ten, który im zaszkodził.

Drift sędziego. Wszystko, co ma charakter semantyczny, jest zwykle oceniane przez model językowy, ponieważ sprawdzenie oparte na regułach nie może stwierdzić, czy „przyszła piątek” został przekształcony na prawidłową datę. Jednak sędzia to również model, a modele się zmieniają. Zespoły pracujące z długotrwałymi zestawami testowymi często widzą, jak cała tabela regresji pogarsza się przez noc, tracą dzień na badania i ostatecznie odkrywają, że oceny uległy zmianie z powodu aktualizacji modelu sędziego, a nie dlatego, że agent stał się gorszy. Ustalenie konkretnej wersji modelu sędziego oraz stałego hasła rubryk zmniejsza problem, ale nie eliminuje go całkowicie, ponieważ hostowane punkty końcowe sędziego ciągle się zmieniają.

Błąd wyniku. Ocena wyłącznie stanu końcowego wymazuje ciekawą część całego procesu. Agent może użyć niewłaściwego narzędzia, cztery razy odesłać ten sam błędny argument, a mimo to dzięki szczęściu lub wytrwałości dojść do prawidłowej odpowiedzi, a system, który analizuje tylko ostatnią wiadomość, uzna to za pomyślne.

Prywatne sposoby awarii. Publiczne standardy takie jak BFCL czy tau-bench pomagają w porównywaniu modeli, ale nie są w stanie wykryć awarii występujących wewnątrz własnego rejestru narzędzi zespołu: wartości null w polu opcjonalnym, błąd związany z strefą czasową w argumencie daty, niezgodność waluty w polu finansowym. Takie awarie należą do narzędzi zespołu i nigdy nie pojawiają się na ogólnodostępnych listach rankingowych. Jeśli pokrycie testowe pochodzi wyłącznie z publicznych standardów, narzędzie walidacyjne jest ślepe dokładnie w tych miejscach, które są najważniejsze – w tych częściach systemu, których nikt inny nie przetestował.

Slup kosztowy. Najmniej omawiany, a być może najważniejszy. Systemy oceny mogą wskazywać, że agent jest dokładny we wszystkich badanych aspektach, nie zastanawiając się przy tym, czy agent sam pokrywa swoje koszty. Jeden z dobrze znanych przypadków dotyczył agenta, który spełniał wszystkie dwanaście kryteriów jakości, ale został usunięty z użycia, ponieważ każde udane rozwiązanie kosztowało więcej niż proces realizowany przez człowieka, który miał zostać zastąpiony. Wyniki oceny jakości były dokładne. Brakowało jednak wskaźnika na pytanie, które przesądziło o jego losie.

Agenat rezerwacyjny z doskonałą oceną, który poniósł porażkę

Załóżmy, że agent rezerwacyjny ma za zadanie znaleźć loty na „przyszłą piątkę”. Z bazy zawierającej dziesiątki narzędzi wybiera odpowiednie, dzięki czemu wybór narzędzia otrzymuje doskonałą ocenę 1,0. Następnie wysyła datę jako zwykły ciąg znaków, nie przetwarzając najpierw wyrażenia względnego. API odpowiada błędem walidacji, a agent cztery razy wysyła ten sam błędny ciąg znaków, zanim przeprosi i zakończy pracę.

Ten zapis dostarcza dwóch wartości: perfekcyjną ocenę 1,0 za wybór narzędzia oraz 0 za ukończenie zadania. Żadna z nich nie wskazuje, co dokładnie poszło nie tak: błędne wyodrębnienie argumentów, błąd w odpowiedzi, którego agent nigdy nie przeczytał, czy logika ponawiania prób, która krąży w nieskorygowanym wejściu. Szczegółowa analiza oceny wywoływania narzędzi pokazała, że sprawdzanie jedynie tego, czy wywołano właściwe narzędzie, testuje intencję, a nie realizację, a to właśnie intencja nie zawiodła.

To jest cały problem w skali mikro. Pakiet wygenerował dwa liczby – żadna z nich nie była całkowicie błędna, ale obie okazały się bezużyteczne w odniesieniu do jedynego istotnego pytania: co należy naprawić?

Praktyki, które pomagają

Gdy pakiet do oceny jest traktowany jako system wymagający własnych kontrol jakości, dojrzała konfiguracja wygląda inaczej. Kilka nawyków odróżnia zespoły, które szybko wykrywają problemy, od tych, które odkrywają je dopiero w trudnych sytuacjach:

• Własna warstwa metaoceny. W poważnych implementacjach praca dzieli się teraz na ocenę rezultatu, ocenę każdego kroku w procesie oraz warstwę, która sprawdza wzajemną spójność ocen, aby wyniki pojedynczych oceniających nie były przyjmowane bez krytycznej analizy.
• Weryfikacja oparta na wykonywaniu zadań zamiast porównywania tekstu. Najbardziej wiarygodne testy sprawdzają, co faktycznie uległo zmianie w rzeczywistości. tau-bench odczytuje stan bazy danych, SWE-Bench wykonywa rzeczywiste testy, a tau2-bench używa metody pass-at-k, aby sprawdzić, czy agent konsekwentnie odnosi sukcesy przy powtarzanych próbach. Lokalne zestawy testowe powinny postępować w ten sam sposób i potwierdzać rzeczywiste zmiany, niezależnie od tego, co zgłasza agent.
• Koszt obok jakości. W przypadku finansów argumentuje się za śledzeniem kosztu za każdy udany wynik jako kluczowej miary obok dokładności, która powinna być obliczana od samego początku, a nie później, gdy ktoś odpowiedzialny za budżet zaczyna o to pytać.
• Kaskadowe testy CI. Pełne oceny od początku do końca są kosztowne, ponieważ każde zadanie wymaga dwóch wywołań modeli – agenta i sędziego – a zestaw stu zadań z pięcioma próbami każdego z nich mniej więcej podwaja koszt testów CI. Zespoły, które utrzymują to pod kontrolą, rozdzielają szybkie, bezpłatne i deterministyczne sprawdzenia, które odbywają się przy każdym commitie, od wolnych, drogich ocen opartych na sędziach, które uruchamiają się tylko wtedy, gdy zmiana wpływa na funkcjonowanie agenta.
• Zestaw, który pozostaje aktualny. W niedawnej ankiecie przeprowadzonej w branży większość respondentów stwierdziła, że ich testy nie dają oczekiwanych rezultatów, ponieważ ruch w produkcji odbiega od pierwotnego zestawu testowego, co utrudnia jego aktualizację. Zestaw nienaruszony od momentu uruchomienia nie jest bezpieczny – mierzy system, który przestał istnieć.

Cztery kroki dla zestawu, który już posiadasz

Dla zespołu posiadającego zestaw narzędzi do oceny, który chce je zweryfikować, a nie po prostu im ufać, cztery kroki zamkną większość luk:

1. Weź od dziesięciu do dwudziestu śladów z produkcji, które zestaw oznaczył jako pomyślne, i ręcznie przeczytaj każdą całkowitą ścieżkę, a nie tylko odpowiedź. Liczba takich pomyślnych przypadków, w których kryje się błąd proceduralny, stanowi rzetelny wskaźnik tego, na ile zielona karta kontrolna zasługuje na zaufanie.
2. Ustal wersję modelu oceniającego oraz tekst kryteriów oceny i rejestruj oba elementy wraz z każdą oceną, aby aktualizacja modelu oceniającego była widoczna jako oznaczone zdarzenie, a nie tajemnicza regresja.
3. Od pierwszego dnia śledź koszt każdego pomyślnego wyniku, nawet zanim ktoś o to poprosi.
4. Stwórz mały zbiór przypadków regresji na podstawie rzeczywistych awarii w produkcji, a nie tylko syntetycznych przypadków. Publiczne punkty odniesienia określają minimalne standardy, natomiast historia incydentów samego zespołu pozwala przewidzieć kolejną kłopotliwą awarię.

Nic z tego nie zastępuje zestawu testowego. Po prostu przestaje się traktować ten zestaw jako pojedynczą komponentę zbyt ważną, by ją sprawdzać.

Odpowiedzi szybkie

Co oznacza walidacja zestawu testowego dla agentów? Oznacza to zastosowanie takiej samej dokładnej analizy systemu oceny, jaką system stosuje wobec agenta, sprawdzając, czy sędzia, kryteria oceny oraz proces punktowania nadal mierzą to, co deklarują.

Dlaczego wyniki oceny przy użyciu LLM jako sędziego ulegają zmianom? Sędzią jest model. Gdy jego dostawca go aktualizuje lub zastępuje nowszą wersją, wyniki mogą się zmieniać, mimo że oceniany agent pozostał niezmieniony.

Czy publiczne benchmarki mogą zastąpić dostosowany zestaw testowy? Nie. Pomagają one porównywać modele w zadaniach typowych, ale pomijają problemy wynikające z własnych narzędzi, danych i specyficznych przypadków zespołu.

Czy wysoki wskaźnik powodzenia wystarcza, by agent pozostał w produkcji? Sam w sobie nie. Agent może osiągać dobre wyniki pod względem dokładności i jakości trajektorii, a mimo to zostać usunięty, jeśli koszt każdego udanego rezultatu nie uzasadnia wartości, jaką dostarcza.

Jak często należy przeglądać lub odbudowywać ten zestaw narzędzi? Ciągle, w miarę zmian w ruchu w produkcji. Wykorzystanie narzędzi odsuwa się od pierwotnego zestawu testowego, dlatego przypadki pochodzące z rzeczywistych awarii muszą być dostarczane regularnie, a nie tylko przy uruchomieniu.

Twierdzenie stojące za panelami kontrolnymi

Zestaw testów nie jest dowodem na to, że agent funkcjonuje prawidłowo. Jest to stwierdzenie dotyczące tego, co oznacza „prawidłowe funkcjonowanie”, napisane przez osobę, która go stworzyła, oceniane przez sędziego, którego oceny mogą ulec zmianie, na zbiorze testowym, który zaczyna „starzeć się” od chwili jego stworzenia. Uznawanie tego stwierdzenia za oczywistą prawdę sprawia, że agenci trafiają na rynek, które wyglądają dobrze na wszystkich panelach kontrolnych, a mimo to nie odpowiadają na kluczowe pytania. Ręczna analiza dziesięciu śladów działania, jak opisano powyżej, szybko pokazuje, ile informacji ukrywa panel kontrolny.