01 · PROMPT
Zmiana instrukcji
Poprawia ton lub routing, ale może zmienić warunek eskalacji albo kolejność pytań.
AI Regression Testing · Voice · Chat · Agents
Testy regresyjne AI, które pokazują, co zepsuła ostatnia zmiana.
Zmiana promptu, modelu, RAG-u, toola albo integracji może poprawić jeden scenariusz i po cichu zepsuć inny. Buduję powtarzalny zestaw testów PASS / FAIL, który sprawdza nie tylko odpowiedź modelu, ale też akcje i finalny stan procesu.
regresja po zmianachbusiness rules + backend stateopcjonalny CI quality gate
Regression run · przykład
RELEASE_CANDIDATE_013
BASELINEprompt_v12 · model_A132 / 132 PASS
CANDIDATEprompt_v13 · model_B128 PASS · 4 FAIL
Critical regression · RESCHEDULE_APPOINTMENT
RESPONSEPASS
TOOL / API409 SLOT_TAKEN
BACKEND STATENOT CHANGED
BUSINESS OUTCOMEFAIL
SEVERITY · CRITICALQUALITY GATE FAILED
Dlaczego regresja w AI jest inna
Mała zmiana w konfiguracji może zmienić zachowanie całego procesu.
W klasycznym teście łatwo sprawdzić konkretny output. W systemie opartym na LLM trzeba pilnować także kontekstu, retrievalu, argumentów tool calla, retry i tego, czy backend naprawdę wykonał operację.
02 · MODEL
Model swap
Ten sam prompt nie gwarantuje tego samego zachowania przy innym modelu lub providerze.
03 · RAG
Nowa wiedza
Zmiana źródeł, chunkingu lub retrievera może podmienić poprawny kontekst na pozornie podobny.
04 · TOOLS
Schema / integracja
Odpowiedź może brzmieć poprawnie mimo złych argumentów, timeoutu albo nieudanego API.
05 · VOICE
Warstwa głosowa
ASR, barge-in, endpointing lub latency mogą zepsuć scenariusz, który tekstowo przechodzi.
Jak testuję
Regression Suite zaczyna się od definicji PASS, nie od losowej listy promptów.
Scenariusz ma przejść wtedy, gdy system zachowa się poprawnie z punktu widzenia procesu biznesowego. Sama „dobra odpowiedź” modelu nie wystarcza.
01
Definiuję kryteria PASS
Proces, warunki wstępne, invariants i finalny stan. Ustalamy, co system musi zrobić, czego nie może zrobić i które błędy są krytyczne.
02
Buduję scenariusze
Happy path, edge cases, korekty multi-turn, wcześniejsze bugi, błędne dane, timeouty, retry i przypadki wynikające z realnego użycia.
03
Dobieram evaluatory
Deterministyczne asercje, reguły biznesowe, walidacja tool calli i backend state. Gdy wynik jest semantyczny lub stochastyczny, używam odpowiedniego scorera i w razie potrzeby kilku prób zamiast oczekiwać identycznego tekstu za każdym razem.
04
Ustalam baseline
Zapisuję wersję promptu, modelu, konfiguracji i danych, które tworzą punkt odniesienia. Dla twardych reguł baseline może być binarny; dla zachowań stochastycznych może obejmować próg lub rozkład wyników z kilku uruchomień.
05
Uruchamiam po zmianach
Ręcznie przed wydaniem albo opcjonalnie w CI/CD. Raport pokazuje, który scenariusz się zepsuł, gdzie i z jaką wagą.
Jeden scenariusz, kilka warstw
Bot może odpowiedzieć poprawnie i nadal oblać test.
Przykład · przełożenie wizyty
„Gotowe” nie jest dowodem wykonania operacji.
Użytkownik prosi o przeniesienie wizyty. Odpowiedź jest naturalna i zgodna z intencją. Regression test nie kończy się jednak na tekście: sprawdza tool call, odpowiedź API i stan wizyty.
W tym przykładzie jedna regresja o severity CRITICAL wystarcza, żeby quality gate nie przeszedł.
USERPrzenieś wizytę na czwartek 16:00.
RESPONSEPASS · „Gotowe...”
TOOL CALLreschedule_appointment()
API409 SLOT_TAKEN
STATEappointment NOT changed
FINALFAIL · FALSE CONFIRMATION
Co dostajecie
Nie dashboard z jednym score'em. Zestaw, który da się uruchomić ponownie.
SCENARIOS
Zestaw scenariuszy
Krytyczne przepływy, edge cases i znane failure modes zapisane w powtarzalnej formie.
GOLDEN DATASET
Dane testowe i oczekiwania
Wejścia, kontekst, preconditions i oczekiwane zachowanie dla scenariuszy, które mają chronić release.
EVALUATORS
Asercje i evaluatory
Sprawdzenie odpowiedzi, tool calli, argumentów, reguł biznesowych oraz stanu systemu.
DIFF
Baseline → candidate
Czytelna informacja: co nadal przechodzi, co się poprawiło i które zachowanie wróciło jako regresja.
SEVERITY
Waga błędów
CRITICAL / HIGH / MEDIUM zamiast traktowania wszystkich FAIL-i tak samo.
OPTIONAL CI
Quality gate
Jeśli architektura pozwala, zestaw może zwracać PASS / FAIL w pipeline przed releasem.
Dla kogo
Najwięcej wartości daje tam, gdzie system AI regularnie się zmienia.
DOBRY FIT
- software house lub AI agency oddająca boty klientom
- zespół produktowy z częstymi zmianami promptu, modelu lub RAG
- agent korzysta z API, CRM, kalendarza lub innych tools
- manualne przeklikiwanie regresji zabiera czas zespołu
- błąd może dać fałszywe potwierdzenie albo zły stan biznesowy
Możliwe white-label jako niezależna warstwa QA przed handoverem do klienta.
MNIEJ SENSU NA TYM ETAPIE
- bardzo wczesny prototyp bez stabilnego procesu
- brak kryteriów poprawnego wyniku biznesowego
- potrzebny jest tylko jednorazowy usability review
- celem jest wyłącznie ogólny „LLM score” bez testowania działań systemu
W takim przypadku lepszy może być najpierw AI Agent Audit albo mały Quality Check.
Kto odpowiada za testy
Adam Stankiewicz · AI Quality Engineer
Na co dzień pracuję hands-on z ewaluacją produkcyjnych voicebotów i chatbotów. Wcześniej przez ponad 3 lata testowałem systemy rynku energii, gdzie błędy miały realne konsekwencje biznesowe.
FAQ
Najczęstsze pytania
Czy regression suite wymaga dostępu do kodu źródłowego?
Nie zawsze. Dużą część scenariuszy można testować black-box przez interfejs, numer telefonu lub API. Dostęp do logów i kodu pomaga wtedy, gdy chcemy precyzyjnie walidować retriever, tool calle, parametry lub stan backendu.
Czy testy regresyjne obejmują voiceboty?
Tak. Dla systemów głosowych do scenariuszy można dołączyć m.in. ASR, barge-in, turn-taking, endpointing, latencję oraz zachowanie po błędnym rozpoznaniu krytycznego slotu.
Czy każdy FAIL powinien blokować release?
Nie. Quality gate powinien uwzględniać wagę scenariusza i severity. Krytyczny błąd w potwierdzeniu operacji biznesowej może blokować wydanie, podczas gdy drobny problem językowy nie musi.
Czy testy mogą działać w CI?
Tak, jeśli architektura i dostęp na to pozwalają. Zestaw można uruchamiać ręcznie przed wydaniem albo zintegrować z pipeline CI/CD i zwracać wynik PASS / FAIL jako quality gate.
Od ilu scenariuszy warto zacząć?
Nie ma jednej właściwej liczby. Zaczynam od procesów o największym ryzyku biznesowym i znanych failure modes. Bezpłatny AI Quality Check wykorzystuje 5 celowanych scenariuszy jednego procesu jako małą próbkę.
Zacznij od jednego procesu
Sprawdźmy, czy zmiana nie zepsuła czegoś poza happy pathem.
W bezpłatnym Quality Checku wybiorę 5 celowanych scenariuszy jednego procesu i pokażę wynik w formie krótkich ustaleń PASS / FAIL.