Testy regresji w systemach AI

Testy regresji w systemach AI sprawdzają, czy zmiana w systemie nie zepsuła działania, które wcześniej było poprawne. Zmianą może być nowy model, inna wersja promptu, dodatkowy dokument w kontekście, nowy krok w n8n, inne narzędzie albo reguła oferty. W klasycznym oprogramowaniu porównujesz przewidywalny wynik funkcji. W systemie AI odpowiedzi bywają różne, dlatego test określa warunek biznesowy: poprawną kategorię leada, obowiązkowy fakt z briefu, zakaz wymyślania ceny, właściwą eskalację lub prawidłowe wywołanie narzędzia. Celem nie jest identyczne zdanie. Celem jest zachowanie uzgodnionego standardu działania.

Regresja jest szczególnie zdradliwa, bo nowe wdrożenie może wyglądać lepiej na jednym przykładzie, a jednocześnie pogarszać wiele zwykłych przypadków. Na przykład po skróceniu promptu agent może szybciej pisać follow-upy, lecz przestać zaznaczać, że brakuje danych w briefie. Po podmianie modelu odpowiedzi mogą brzmieć bardziej naturalnie, ale pomijać warunek kwalifikacji. Bez stałego zestawu przypadków taki błąd odkrywasz dopiero po wysłaniu złej wiadomości albo utraconej szansie sprzedażowej. OpenAI zaleca ewaluować system na zadaniach reprezentatywnych dla realnego użycia, a nie polegać na pojedynczym, efektownym demie.

Praktyczny przykład: masz automatyzację, która po formularzu rozpoznaje usługę, pilność i proponuje następny krok. Przygotuj 12 do 20 zanonimizowanych briefów: typowe, niepełne, sprzeczne i wymagające ręcznej rozmowy. Dla każdego zapisz oczekiwaną klasyfikację oraz twarde warunki, na przykład „nie podaje ceny, której nie ma w briefie” i „brak budżetu kieruje do człowieka”. Po zmianie promptu uruchom cały zestaw ponownie. Jeśli wynik dla dowolnego przypadku przestaje spełniać kryterium, workflow nie powinien automatycznie trafić na produkcję. Najpierw sprawdzasz różnicę, potem świadomie poprawiasz zmianę albo wymaganie.

Podstawą takich testów jest złoty zbiór testowy, czyli zatwierdzone wejścia i oczekiwane decyzje. Do prostych reguł używaj kontroli deterministycznych: czy zwrócony JSON jest poprawny, czy są wszystkie pola, czy numer telefonu nie został wysłany do niewłaściwego systemu. Treści jakościowe oceniaj rubryką, a nie ogólnym pytaniem, czy odpowiedź jest dobra. Rubryka może sprawdzać zgodność z briefem, ton marki, jedno CTA i zasadność eskalacji. W tym drugim kroku może pomóc LLM jako sędzia, ale jego werdykt wymaga porównania z próbką ocenioną przez człowieka. Model nie jest niezależnym dowodem prawdy.

Test regresji powinien mieć próg i decyzję operacyjną. Ustal, co jest błędem blokującym, na przykład halucynacja ceny, ujawnienie danych lub brak eskalacji. Ustal też błędy do obserwacji, jak zbyt długie zdanie w szkicu posta. Zapisuj wersję promptu, modelu, źródeł danych i konfiguracji narzędzi przy każdym przebiegu. Wersjonowanie pozwala wskazać, co rzeczywiście spowodowało różnicę. Anthropic rekomenduje zdefiniowanie mierzalnych kryteriów sukcesu przed budową ewaluacji oraz regularne uruchamianie ich podczas rozwoju. W małej firmie wystarczy arkusz lub skrypt, jeśli wynik jest odtwarzalny i ktoś jest właścicielem decyzji.

Nie próbuj testować wszystkiego od pierwszego dnia. Wybierz workflow o dużej częstotliwości albo wysokim koszcie błędu, na przykład kwalifikację leadów, publikację contentu lub tworzenie ofert. Dodawaj przypadki, gdy pojawia się realny błąd albo nowy ważny typ klienta. Nie zmieniaj oczekiwanego wyniku po cichu tylko dlatego, że test jest czerwony. Najpierw rozstrzygnij, czy biznes świadomie zmienił zasadę, czy automatyzacja się pogorszyła. Dzięki temu testy chronią standard, zamiast stać się dekoracją, którą dopasowuje się do ostatniej wersji modelu.

Testy regresji nie gwarantują, że AI poradzi sobie z każdym nowym przypadkiem. Sprawdzają wyłącznie znane ryzyka opisane w zestawie. Potrzebujesz więc także monitorowania pracy produkcyjnej, kolejki wyjątków i człowieka w pętli przy decyzjach finansowych, prawnych, publikacji lub dostępie do danych klienta. Najlepszy efekt daje prosty rytm: przed zmianą uruchamiasz testy, po wdrożeniu monitorujesz wyjątki, a wartościowe błędy po ręcznym zatwierdzeniu trafiają do zestawu. Wtedy automatyzacja rozwija się na dowodach, a nie na nadziei, że nowy prompt niczego nie zepsuł.