Testy regresji agentów AI: przestań naprawiać jedno i psuć trzy
Dlaczego golden dataset i bramki CI to jedyna niezawodna obrona przed cichymi regresjami agenta, gdy modele, prompty i narzędzia zmieniają się pod spodem.
Definicja
Testy regresji agenta odpalają stały zestaw reprezentatywnych przypadków — golden dataset — przy każdej zmianie, by wykryć, kiedy poprawka lub aktualizacja pogarsza zachowanie gdzie indziej. Wpięte w CI z progami zamieniają ciche regresje w widoczne błędy builda.
Zmieniasz prompt, by naprawić jeden uciążliwy przypadek. Działa. Trzy inne przypadki teraz padają po cichu, a dowiadujesz się o tym na produkcji. To problem regresji agenta, a golden dataset wpięty w CI to jedyne niezawodne lekarstwo.
Dlaczego agenci regresują?
Wszystko pod agentem się rusza: prompty się poprawia, modele aktualizuje, narzędzia zmieniają wyniki. Każda zmiana rozchodzi się przez niedeterministyczny system w sposób, którego nie ogarniesz inspekcją. Poprawka podnosząca jeden przypadek często zatapia inne — a ponieważ nie ma błędu kompilatora, regresja jest cicha, póki nie trafi na nią użytkownik.
Golden dataset
Lekarstwem jest golden dataset: stały, wyselekcjonowany zbiór reprezentatywnych przypadków, który punktujesz przy każdej zmianie. Zbuduj go z dwóch źródeł:
- Realne, zróżnicowane użycie — przypadki odzwierciedlające faktyczne użycie, nie tylko szczęśliwą ścieżkę.
- Każda przeszła awaria — naprawiając błąd produkcyjny, dodaj go jako stały przypadek, by nigdy nie wrócił po cichu.
Każdy przypadek potrzebuje wejścia i sposobu oceny wyniku — dokładne dopasowanie, gdzie się da, skalibrowany sędzia LLM, gdy wyjście jest otwarte, plus wyrywkowy przegląd człowieka.
Wepnij to w CI
Golden dataset chroni tylko, gdy działa automatycznie. Traktuj go jak zestaw testów:
- Odpalaj przy każdej zmianie promptów, modeli lub narzędzi.
- Ustaw progi — wskaźnik ukończenia, wierność, koszt na zadanie.
- Niech build pada, gdy próg spadnie. Zmiana promptu polepszająca jeden przypadek, lecz zatapiająca zestaw, nie powinna iść na produkcję.
To eval-driven development: zmieniasz agenta względem mierzalnej poprzeczki, a poprzeczka łapie to, co umyka intuicji.
| Wymiar | Jednorazowa ewaluacja | Testy regresji |
|---|---|---|
| Kiedy działa | Raz, na żądanie | Przy każdej zmianie, automatycznie |
| Na co odpowiada | Jak dobry jest dziś? | Czy dziś jest gorzej niż wczoraj? |
| Łapie ciche regresje | Nie | Tak |
| Rola | Migawka | Bariera ochronna |
Utrzymaj zestaw uczciwym
- Powiększaj go ciągle. Każda nowa awaria staje się przypadkiem; zestaw mocnieje z każdym incydentem.
- Odświeżaj wobec dryfu. Gdy modele się zmieniają, weryfikuj ponownie, że sędzia nadal zgadza się z ocenami ludzi.
- Wypatruj przeuczenia. Jeśli zaczynasz stroić pod konkretne przypadki, a nie pod dobre zachowanie, dodaj świeże przypadki, których agent nie widział.
Demo dowodzi, że agent potrafi zadziałać raz. Testy regresji dowodzą, że wciąż działa po setnej zmianie. To one pozwalają zwiększać autonomię i wdrażać na dowodach, nie na nadziei. Pojęcia są w słowniku.
Najczęstsze pytania
Dlaczego agenci tak łatwo regresują?
Bo wszystko pod agentem się rusza, a każda zmiana rozchodzi się przez niedeterministyczny system w sposób, którego nie przewidzisz, czytając diff. Poprawka promptu, aktualizacja modelu, narzędzie zmieniające format wyjścia — każde z nich potrafi przesunąć zachowanie na przypadkach pozornie niezwiązanych ze zmianą, którą zrobiłeś. Konkretna pułapka jest taka, że poprawka polepszająca jeden przypadek bardzo często pogarsza kilka innych, bo ten sam prompt lub model rządzi nimi wszystkimi naraz, a Ty w praktyce na nowo ważysz całe zachowanie za każdym razem, gdy je stroisz. W tradycyjnym oprogramowaniu zmiana łamiąca zwykle rzuca błąd kompilatora lub testu; u agenta takiego sygnału nie ma, więc regresja jest cicha, póki nie trafi na nią użytkownik na produkcji. Niedeterminizm to pogłębia, bo awaria może się nawet nie powtarzać w każdym przebiegu. Jedyny niezawodny sposób, by zobaczyć regresje, to mierzyć stały, reprezentatywny zbiór przypadków przy każdej zmianie, by spadek pokazał się jako liczba, a nie jako zgłoszenie tygodnie później.
Co wchodzi w golden dataset?
Dwa rodzaje przypadków, czerpane z rzeczywistości, nie z wyobraźni. Po pierwsze, realne i zróżnicowane użycie: przykłady odzwierciedlające, jak agent jest faktycznie używany w pełnym zakresie wejść, które widzi, w tym te niechlujne i nietypowe, nie tylko szczęśliwa ścieżka dobrze wyglądająca w demie. Po drugie, każda naprawiona dotąd awaria: rozwiązując błąd produkcyjny, dodajesz go do zbioru jako stały przypadek, by dokładnie ta awaria nigdy nie wróciła po cichu, i to właśnie sprawia, że zestaw kumuluje wartość w czasie. Każdy przypadek potrzebuje wejścia i sposobu oceny wyniku — dokładne dopasowanie, gdy odpowiedź jest dobrze określona, skalibrowany sędzia LLM, gdy wyjście jest otwarte, oraz wyrywkowy przegląd człowieka na najważniejszych przypadkach. Trzymaj go reprezentatywnym, nie wyczerpującym: kilkaset dobrze dobranych przypadków pokrywających, jak agent naprawdę się udaje i zawodzi, ochroni Cię lepiej niż tysiące bliskich duplikatów, a zbiór powinien rosnąć rozmyślnie, jeden przypadek na nowy tryb awarii, by mocniał dokładnie tam, gdzie się sparzyłeś.
Czym to różni się od jednorazowych evals?
Jednorazowa ewaluacja to migawka: mówi, jak agent radzi sobie dziś, co jest użyteczne do decyzji idziemy albo nie idziemy w danym momencie, ale nic nie mówi o jutrze. Testy regresji to bariera ochronna: odpalają ten sam stały zbiór przypadków przy każdej zmianie, automatycznie, i mówią, czy dziś jest gorzej niż wczoraj na tych dokładnie przypadkach. To przejście od migawki do ciągłego porównania jest całym sednem, bo problem regresji agenta jest fundamentalnie o zmianie w czasie — poprawce, która po cichu psuje coś innego — a łapie to tylko stabilny, powtarzany pomiar. Oba są komplementarne, nie konkurencyjne: możesz odpalić szeroką jednorazową ewaluację, wybierając model, a potem wydestylować reprezentatywny wycinek w zestaw regresyjny bramkujący każdą kolejną zmianę. Cechy definiujące testy regresji to bycie stałym (te same przypadki w każdym przebiegu), automatycznym (wpięte w CI) i bramkującym (spadek psuje build), co razem zamienia kontrolę jakości z okazjonalnego zdarzenia w stałą obronę.
Czy odpalanie evals przy każdej zmianie nie jest zbyt wolne lub drogie?
To realna obawa, ale problem strojenia, a nie powód, by pominąć zestaw, a koszt jego braku — wysłanie cichej regresji do użytkowników — jest niemal zawsze wyższy. Dźwignią jest rozmiar i skład golden setu: trzymaj go małym i reprezentatywnym, nie wyczerpującym, by pełny przebieg trwał minuty, nie godziny, i byś nie płacił za ponowne punktowanie tysięcy bliskich duplikatów przy każdym commicie. Możesz też warstwować przebiegi: szybki rdzeniowy zestaw przy każdej zmianie do bramki i większy, wolniejszy zestaw nocą lub przed wydaniem dla głębszego pokrycia. Tam gdzie koszt zdominuje sędzia LLM, użyj tańszego modelu do rutynowego punktowania, a mocniejszego sędziego zostaw do przypadków na styk, i cache'uj wyniki dla niezmienionych przypadków. Ekonomia zwykle z dużą przewagą sprzyja zestawowi, bo jeden powstrzymany incydent produkcyjny — zmarnowane debugowanie, zaufanie użytkownika, rollback — opłaca mnóstwo compute na evals. Traktuj koszt przebiegu jako budżet do zarządzania, nie powód, by lecieć na ślepo.