W agentach AI jedna z najgroźniejszych klas błędów powstaje wtedy, gdy rozmowa wygląda poprawnie, ale akcja pod spodem jest zła. Dlatego regression testing tool calli nie powinien kończyć się na sprawdzeniu, czy model „wybrał jakieś narzędzie”.
Testuj kontrakt działania: czy agent wybrał właściwy tool, podał poprawne argumenty, spełnił preconditions, obsłużył wynik i zostawił system w prawidłowym stanie.
1. Tool call ma kontrakt, nie tylko nazwę
Dla każdego krytycznego narzędzia warto zdefiniować obserwowalne kryteria. Przykład dla reschedule_appointment(): właściwa wizyta, nowy termin, uprawnienia użytkownika, atomowość operacji i zachowanie, jeśli nowy slot przestanie być dostępny.
- selection: czy wybrano właściwe narzędzie,
- arguments: typy, wartości, jednostki i brak starych slotów,
- preconditions: czy warunki biznesowe zostały sprawdzone przed mutacją,
- result handling: czy odpowiedź toola została poprawnie zinterpretowana,
- state: czy finalny backend odpowiada temu, co agent zakomunikował.
2. Najważniejsze scenariusze regresyjne
Zły argument po korekcie użytkownika
Użytkownik zmienia godzinę z 14:00 na 16:00. Agent odpowiada poprawnie, ale tool dostaje stary argument. To klasyczny błąd stanu rozmowy, który można złapać deterministyczną asercją.
Timeout z nieznanym wynikiem operacji
Po timeoutcie agent nie powinien automatycznie zakładać, że operacja się nie wykonała. Jeśli system zdalny zapisał zmianę, retry może stworzyć duplikat albo wykonać mutację drugi raz.
Partial failure
W procesie składającym się z kilku mutacji jedna może przejść, a kolejna nie. Test powinien weryfikować invariant finalnego stanu, a nie tylko pojedyncze statusy HTTP.
3. Retry i idempotency muszą być częścią testu
Jeśli narzędzie wykonuje mutację, scenariusze powinny sprawdzać zachowanie po ponowieniu żądania, utracie odpowiedzi i duplikacie eventu. Nie każda integracja ma idempotency key, ale wtedy system potrzebuje innej strategii rozpoznania, czy operacja już zaszła.
To szczególnie istotne w rezerwacjach, płatnościach, anulowaniach, tworzeniu zgłoszeń i wszędzie tam, gdzie powtórzona mutacja ma realny koszt.
4. Co da się ocenić deterministycznie
W tool calling duża część krytycznych kryteriów nie wymaga LLM judge. Można twardo sprawdzić nazwę toola, schema-valid arguments, identyfikator encji, status odpowiedzi, liczbę utworzonych rekordów i invariant backendu. Judge przydaje się dopiero do warstw semantycznych, np. czy eskalacja była uzasadniona na podstawie kontekstu.
5. Regression suite musi zapisywać wersje
Przy porównaniu baseline → candidate trzeba wiedzieć, co się zmieniło: prompt, model/provider, tool schema, kod orkiestracji, dane/RAG, feature flags i środowisko. Bez tego wynik regresji jest trudny do odtworzenia.
Dla stochastycznych elementów scenariusz może wymagać kilku uruchomień i progu zamiast jednego PASS/FAIL. Dla backend invariants zwykle można pozostać przy twardej asercji.
6. Quality gate powinien być severity-aware
Cztery kosmetyczne problemy językowe nie muszą oznaczać NO-GO. Jeden krytyczny false confirmation albo utrata danych może. Gate powinien wynikać z ryzyka biznesowego i z góry ustalonych reguł, a nie z arbitralnego „overall score”.
Źródła i standardy
To są źródła techniczne, na których opiera się metodologia opisana wyżej. Nie oznacza to certyfikacji zgodności z tymi standardami.