Testowanie systemów opartych na AI — dlaczego zwykłe testy nie wystarczają

Klasyczny test oprogramowania sprawdza, czy dla danego wejścia program zwraca oczekiwany wynik. Jeśli funkcja dodaje dwie liczby, wynik jest zawsze ten sam. System oparty na modelu językowym działa inaczej: na to samo pytanie może odpowiedzieć na kilka poprawnych sposobów, a drobna zmiana instrukcji potrafi poprawić wyniki w jednym typie spraw i pogorszyć w innym. Zespoły, które próbują testować takie systemy tak samo jak zwykły kod, albo piszą testy, które ciągle się psują, albo rezygnują z testów i dowiadują się o problemach od klientów.

Autor: zespół Convert Studio — software house z Kielc i Krakowa, projektujemy aplikacje webowe, sklepy i wdrożenia AI dla firm.

Czym testowanie AI różni się od zwykłego

Co testować zwykłymi testami

Duża część systemu AI to zwykły kod i ten fragment należy testować tradycyjnie, z pełną automatyzacją.

• Narzędzia agenta — czy pobierają właściwe dane, odrzucają niedozwolone parametry, respektują uprawnienia.
• Walidacja odpowiedzi modelu — czy kod poprawnie obsługuje odpowiedź w złym formacie, pustą lub niekompletną.
• Obsługa błędów — niedostępność API modelu, przekroczenie limitów, zbyt długi czas odpowiedzi.
• Budowanie kontekstu — czy do modelu trafiają właściwe dokumenty i dane.
• Limity i bezpieczniki — czy agent zatrzymuje się po określonej liczbie kroków.
• Integracje — zapis wyników w systemach docelowych.

W tych testach model zastępuje się atrapą zwracającą przygotowane odpowiedzi, co pozwala uruchamiać je szybko i powtarzalnie w procesie ciągłej integracji. O automatyzacji testów w zespole piszemy w tekście o CI/CD dla małego zespołu.

Zestaw ewaluacyjny

Serce testowania jakości to zestaw przypadków reprezentujących realne użycie systemu. Jego jakość decyduje o tym, czy wyniki ewaluacji cokolwiek znaczą.

• Prawdziwe przypadki — pytania, dokumenty i zgłoszenia z realnego ruchu, zanonimizowane w razie potrzeby.
• Proporcje zbliżone do rzeczywistości — częste przypadki odpowiednio reprezentowane.
• Przypadki rzadkie, ale ważne — dobrane celowo, bo losowa próbka ich nie zawiera.
• Przypadki trudne — niejednoznaczne, wielowątkowe, z błędami w pisowni, w obcym języku.
• Przypadki, w których system powinien odmówić lub przekazać sprawę człowiekowi.
• Błędy z produkcji — każdy zgłoszony i potwierdzony błąd trafia do zestawu.
• Oczekiwany wynik lub kryteria oceny dla każdego przypadku.

Sposoby oceny wyników

Ocena przez model jest wygodna, ale sama wymaga sprawdzenia. Przed zaufaniem jej wynikom warto porównać ją z oceną ludzi na próbce przypadków. Jeśli zgodność jest niska, instrukcja oceniająca wymaga poprawy.

Kiedy uruchamiać ewaluację

• Po każdej zmianie instrukcji — nawet drobnej, bo jej wpływ trudno przewidzieć.
• Przy zmianie modelu lub jego wersji.
• Po zmianie w danych — nowe dokumenty w bazie wiedzy, zmiana sposobu ich dzielenia.
• Po zmianie narzędzi dostępnych dla agenta.
• Okresowo — dostawcy aktualizują modele, a zachowanie może się zmienić bez zmiany po stronie firmy.
• Przed każdym wdrożeniem na produkcję jako warunek dopuszczenia zmiany.

O utrzymaniu stabilnych wyników przy zmianach instrukcji piszemy w tekście o instrukcjach dla modelu.

Regresja — najważniejsze zagrożenie

Zmiana, która poprawia odpowiedzi na nowy rodzaj pytań, może jednocześnie pogorszyć odpowiedzi na pytania, które wcześniej działały dobrze. Bez ewaluacji na pełnym zestawie takie pogorszenie jest niewidoczne aż do skarg klientów.

• Wynik dla każdej kategorii przypadków, nie tylko ogólny odsetek.
• Porównanie z poprzednią wersją — które przypadki się poprawiły, a które pogorszyły.
• Próg dopuszczenia — zmiana nie może obniżyć wyniku w krytycznych kategoriach.
• Wielokrotne uruchomienie niepewnych przypadków, żeby odróżnić zmianę od losowej zmienności.
• Zapis wyników każdej ewaluacji z wersją instrukcji i modelu.

Testy bezpieczeństwa

Oprócz jakości trzeba sprawdzać, czy system zachowuje się bezpiecznie w sytuacjach, których nie przewidziano w zwykłym użyciu.

• Próby zmiany instrukcji przez treść wiadomości lub dokumentu.
• Próby wydobycia danych innych klientów lub treści instrukcji systemowej.
• Próby wymuszenia niedozwolonych działań — rabatów, zmian w systemach, obietnic.
• Treści obraźliwe i prowokacyjne — czy system reaguje zgodnie z zasadami.
• Pytania poza zakresem — czy system rozpoznaje, że nie powinien odpowiadać.

Szczegóły tych zagrożeń opisujemy w tekście o bezpieczeństwie systemów AI.

Monitorowanie na produkcji

Zestaw testowy nigdy nie pokryje wszystkich sytuacji. Dlatego ewaluacja przed wdrożeniem musi być uzupełniona obserwacją działającego systemu.

Losowa próbka rozmów oceniana regularnie przez ludzi pozwala wykryć problemy, których nie widać we wskaźnikach. Źródłem danych do takiej oceny jest dziennik działań agenta.

Organizacja pracy

• Właściciel zestawu ewaluacyjnego — osoba odpowiedzialna za jego aktualność.
• Eksperci dziedzinowi w ocenie — pracownicy znający proces, nie tylko programiści.
• Automatyczne uruchamianie ewaluacji w procesie wdrożenia.
• Czytelny raport porównujący wersje, zrozumiały dla osób nietechnicznych.
• Ścieżka od błędu do testu — każdy potwierdzony błąd z produkcji trafia do zestawu w ustalonym czasie.

Przykład z praktyki

Firma korzysta z asystenta odpowiadającego pracownikom na pytania o procedury wewnętrzne. Zespół zmienia instrukcję, żeby asystent odpowiadał krócej, bo użytkownicy skarżyli się na zbyt długie odpowiedzi. Ręczne sprawdzenie kilku pytań wypada dobrze i zmiana trafia na produkcję. Po tygodniu dział kadr zgłasza, że asystent przestał podawać terminy składania wniosków urlopowych, które wcześniej były częścią odpowiedzi.

Po tym zdarzeniu zespół buduje zestaw ewaluacyjny: sześćdziesiąt pytań z dziennika, pogrupowanych według tematów, z listą informacji, które muszą znaleźć się w odpowiedzi. Część sprawdzana jest regułami — czy odpowiedź zawiera termin, link do procedury, nazwę formularza — a część oceniana przez model według opisanych kryteriów, porównanych wcześniej z oceną pracownika kadr. Każda kolejna zmiana instrukcji jest uruchamiana na całym zestawie, a raport pokazuje, które pytania się poprawiły, a które pogorszyły. Kolejna próba skrócenia odpowiedzi zostaje wdrożona dopiero wtedy, gdy wynik w kategorii urlopów nie spada.

Z tego przykładu płynie prosta nauka: ręczne sprawdzenie kilku pytań daje złudne poczucie bezpieczeństwa. Dopiero systematyczny zestaw pokazuje pełny wpływ zmiany, także w obszarach, o których zespół w danej chwili nie myślał. Koszt przygotowania takiego zestawu zwraca się przy pierwszej uniknięciu regresji.

Po kilku miesiącach taki zestaw staje się jednym z najcenniejszych zasobów zespołu, bo zawiera wiedzę o tym, jak system powinien działać, zapisaną w formie możliwej do automatycznego sprawdzenia.

Podsumowanie

Systemy oparte na AI wymagają dwóch rodzajów testów: zwykłych testów kodu wokół modelu oraz ewaluacji jakości wyników na zestawie reprezentatywnych przypadków. Ewaluacja łączy ocenę automatyczną z oceną ludzi, jest uruchamiana po każdej zmianie instrukcji, modelu lub danych i chroni przed regresją, która w takich systemach jest głównym zagrożeniem. Całość uzupełnia monitorowanie działającego systemu i przenoszenie wykrytych błędów do zestawu testowego.

Jeśli Twój system AI działa bez ewaluacji, zacznij od zebrania pięćdziesięciu realnych przypadków z oczekiwanymi wynikami i uruchamiaj je przed każdą zmianą. Już taki mały zestaw pozwala uniknąć większości niespodzianek. Jak ewaluacja wpisuje się w cały proces budowy agenta, opisujemy na stronie wdrożenie agenta AI.