Golden dataset w testach agentów AI nie powinien być katalogiem „ładnych promptów”. To zestaw reprezentatywnych przypadków, który chroni konkretne zachowania systemu przed regresją i pozwala porównywać kolejne wersje w kontrolowanych warunkach.
Najlepszy materiał na test: realny błąd, kosztowny proces biznesowy, krytyczny edge case albo zachowanie, które już raz wróciło po zmianie promptu, modelu czy integracji.
1. Golden dataset opisuje oczekiwane zachowanie, nie zawsze dokładny tekst
Dla klasycznego testu expected output bywa jedną wartością. W LLM application często lepiej zapisać oczekiwania w kilku warstwach: intencja, dozwolone/zakazane zachowanie, tool call, argumenty, źródło wiedzy i finalny stan backendu.
Dzięki temu system może wygenerować inne poprawne zdanie i nadal przejść test, jeśli zachował wszystkie wymagane invariants.
2. Skąd brać przypadki
- incydenty i błędy znalezione na produkcji,
- support tickets i rozmowy oznaczone jako problematyczne,
- krytyczne przepływy biznesowe,
- edge cases wynikające z reguł domenowych,
- zmiany multi-turn i korekty użytkownika,
- tool/API failures, timeouty, retry i race conditions,
- przypadki safety/guardrail ważne dla konkretnego zastosowania.
Zestaw powinien rosnąć wraz z rzeczywistymi failure modes, a nie być raz napisanym benchmarkiem, którego nikt później nie aktualizuje.
3. Co zapisywać przy scenariuszu
Warto także przechowywać wersję promptu/modelu, konfigurację, wersję KB/RAG i identyfikator release'u. To pozwala odtworzyć baseline i zrozumieć, dlaczego candidate zachował się inaczej.
4. Dobierz scorer do rodzaju kryterium
Nie wszystko trzeba oceniać jednym LLM judge. Twarde reguły najlepiej sprawdzać kodem: dokładny tool, argumenty, status, identyfikator, liczba rekordów, business invariant. Kryteria semantyczne mogą używać judge/scorera, najlepiej z jasną rubryką.
Jeżeli zachowanie jest stochastyczne, pojedyncze uruchomienie może być za słabym dowodem. Wtedy sensowniejsze są powtórzenia i próg akceptacji dopasowany do ryzyka. Nie istnieje jeden uniwersalny pass rate dobry dla wszystkich agentów.
5. Nie optymalizuj wyłącznie pod rozmiar datasetu
1000 przypadków o niskim ryzyku może dać mniej wartości niż 80 przypadków, które dobrze pokrywają krytyczne procesy i historyczne awarie. Coverage powinno odpowiadać mapie ryzyka: które procesy są najważniejsze, gdzie system mutuje dane i gdzie błąd może wprowadzić użytkownika w błąd.
6. Dataset jest artefaktem żyjącym
- Złap nowy failure mode.
- Zamień go w reprodukowalny scenariusz.
- Dodaj kryteria i severity.
- Uruchom przeciw baseline i candidate.
- Po naprawie zostaw przypadek w suite, żeby błąd nie wrócił.
To podejście łączy eval dataset z praktycznym regression suite. Zamiast jednego agregowanego score'u dostajesz listę zachowań, które muszą nadal działać.
Ź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.