Analiza błędów w aplikacjach LLM: przeczytaj ślady, zanim napiszesz ewaluacje

Dlaczego ogólne metryki wprowadzają w błąd

Wiele zespołów z produktem AI w fazie pilotażu zapisuje już każde wywołanie, ale nie ma definicji tego, co w ich produkcie jest błędem. Gotowe wskaźniki pomocności czy podobieństwa wyglądają na skrót, ale nikt nie sprawdził ich na prawdziwych błędach. Husain i Shankar ostrzegają, że ogólne ewaluacje marnują czas i dają fałszywe poczucie bezpieczeństwa, gdy używa się ich jako miary jakości, a przewodnik OpenAI po ewaluacji wymienia zbyt ogólne metryki, takie jak BLEU, wśród antywzorców.

Asystent obsługi klienta może dostać wysoką ocenę trafności, podając jednocześnie termin zwrotu, który zmienił się w zeszłym miesiącu. Analiza błędów zastępuje zgadywanie obserwacją: czytasz prawdziwe ślady (traces), opisujesz prostymi słowami, co poszło nie tak, grupujesz notatki w typy błędów i je liczysz. Husain i Shankar opisują tę metodę jako zaadaptowaną z badań jakościowych, gdzie oba etapy nazywa się kodowaniem otwartym i kodowaniem osiowym. Inżynierowie Anthropic dodają, że bez czytania transkryptów i ocen z wielu przebiegów nie dowiesz się, czy oceniacze działają.

Ile śladów i kto je czyta

Husain i Shankar zalecają przejrzenie co najmniej 100 śladów i czytanie dalej, dopóki wciąż czegoś się uczysz. Ich reguła zatrzymania jest ważniejsza niż sama liczba: przestań, gdy nowe ślady nie ujawniają już nowych typów błędów ani nie zmieniają tych, które znasz. Badacze jakościowi nazywają ten moment nasyceniem teoretycznym.

Ich strona o analizie błędów podaje drugą liczbę. Gdy agent AI proponuje etykiety, najpierw sam oznacz co najmniej 30 śladów, a dopiero potem przeglądaj jego sugestie, w puli około 100 zróżnicowanych śladów. Około 100 śladów czytanych do nasycenia to analiza, a 30 to minimum, które człowiek oznacza ręcznie, zanim pomoże mu agent.

Pobierz niedawne ślady ze wszystkich kanałów, języków i głównych intencji. Jeśli dodajesz ślady oznaczone przez użytkowników, raportuj je osobno, żeby nie zawyżały odsetków błędów.

Husain i Shankar mówią wprost: czytać powinien ekspert dziedzinowy, na przykład kierownik obsługi klienta albo likwidatorka szkód, których pracę naśladuje system. Sam inżynier wyłapie niepoprawny JSON i przeoczy błędną regułę zwrotu pieniędzy. Ślady z produkcji często zawierają dane osobowe, więc pseudonimizację uzgodnij przed sesją.

Jedna etykieta i jedna notatka na ślad

Dla każdego śladu ekspert zapisuje zaliczony albo niezaliczony, a przy błędzie jedno lub dwa zdania własnymi słowami. Husain i Shankar zauważają, że osoby oceniające na skalach uciekają w wartości środkowe, żeby uniknąć trudnych decyzji, i zalecają etykiety binarne, by zrozumieć, jak wygląda zły wynik. Również OpenAI zaleca pass/fail, gdy ocenia model.

W długich śladach agentów albo pipeline'ów zapisuj tylko pierwszy błąd w łańcuchu. Wcześniejsze błędy pociągają za sobą kolejne, jak podkreślają Husain i Shankar: naprawa wczesnego błędnego wywołania narzędzia często usuwa też chaotyczną odpowiedź na końcu. Przydatna notatka jest na tyle konkretna, że inna osoba odnajdzie ten sam problem:

• Wziął z tematu wiadomości zamówienie 4812 zamiast 4821, więc data dostawy dotyczy cudzego zamówienia
• Podaje 14 dni na zwrot, a polityka w bazie wiedzy mówi o 30 dniach
• Klient dwa razy poprosił o człowieka, a asystent dalej podsuwał linki do FAQ

Gdy oznacza kilka osób

Jeśli etykiety nadaje kilka osób, niech najpierw wszystkie ocenią te same 20 albo 30 śladów. Husain i Shankar zalecają mierzenie zgodności miarą skorygowaną o przypadek, taką jak kappa Cohena. Ważniejsza od liczby jest rozmowa o rozbieżnościach: zwykle kryje się za nimi niespisana reguła, na przykład czy poprawna odpowiedź, w której asystent zwraca się do niemieckiego klienta na „du” (na ty), to błąd. Zapisz ją. Shankar i współautorzy zauważyli, że kryteria zmieniają się w trakcie oceniania, i nazwali to dryfem kryteriów (criteria drift), więc później wróć do wczesnych etykiet.

Pogrupuj notatki i policz

Następnie pogrupuj notatki w typy błędów. Husain i Shankar nazywają to najważniejszym krokiem i kończą go policzeniem błędów w każdej kategorii. Dobre kategorie są na tyle wąskie, że podsuwają poprawkę, i na tyle szerokie, że mieszczą kilka notatek. LLM może naszkicować grupowanie, ale decyduje ekspert.

Hipotetyczny przykład

Weźmy hipotetycznego niemieckojęzycznego asystenta obsługi klienta w sklepie internetowym ze sprzętem AGD. Kierowniczka obsługi klienta przeczytała 100 śladów z czterech tygodni czatu. Ostatnie 20 wciąż przyniosło nowy typ błędu, więc przeczytała kolejne 20; te nie dodały żadnego, więc zakończyła na 120. 41 śladów nie zaliczyło oceny, każdy policzony w kategorii pierwszego błędu:

Błędne sprawdzenia zamówień i nieaktualne reguły to 20 z 41 błędów, mniej więcej połowa, a ogólny wskaźnik pomocności przeoczyłby jedne i drugie, bo odpowiedzi dobrze się czyta. Przy takiej próbce ani 11 wobec 9, ani 9 wobec 7 nie jest wiarygodnym rankingiem.

Napraw, sprawdź w kodzie albo zbuduj sędziego

Nie każdy typ błędu potrzebuje ewaluatora. Dla każdego wiersza zdecyduj, co usunie błąd i po czym poznasz, że wrócił.

1. 1

   Napraw, gdy przyczyna jest oczywista

   Usuń nieaktualny dokument ze źródeł i napraw kontekst, który gubi wcześniejsze wiadomości. Zachowaj kilka oryginalnych śladów jako przypadki regresyjne i nie buduj sędziego dla problemu, którego już nie ma.

2. 2

   Napisz sprawdzenie w kodzie, gdy błąd widać w danych

   Czy narzędzie zamówień dostało numer podany przez klienta, czy odpowiedź obywa się bez formy du, czy e-mail zawiera Markdown: każdą z tych rzeczy sprawdzi kilka linijek kodu. Husain i Shankar radzą, by w CI przedkładać deterministyczne sprawdzenia nad sędziów LLM, a dokumentacja Anthropic nazywa ocenę opartą na kodzie najszybszą i najbardziej niezawodną, choć brakuje jej niuansów.

3. 3

   Zbuduj sędziego LLM tylko tam, gdzie potrzebny jest osąd

   Rozpoznanie, że klient chce rozmawiać z człowiekiem, choć tego nie mówi, wymaga osądu. Zbuduj dla tego typu błędu jednego sędziego, który zgodnie z zaleceniem Husaina i Shankar zwraca zaliczone albo niezaliczone, i porównaj jego werdykty z etykietami eksperta, zanim mu zaufasz. Zacznij od najwyżej dwóch albo trzech sędziów.

W przykładzie daje to trzy sprawdzenia w kodzie, jednego sędziego i dwie poprawki, każde wynikające z błędów, które widział ekspert.

Co powstaje z taksonomii

Oznaczone ślady to twój pierwszy zestaw testowy. Niezaliczone ślady z kategorią i notatką to przypadki o znanym błędzie, a zaliczone wyłapują poprawki, które psują zwykłe rozmowy. Anthropic uważa, że 20 do 50 zadań opartych na prawdziwych błędach to dobry początek, więc 41 błędów wystarcza na start.

Kategorie stają się twoimi metrykami: odsetkiem każdego typu błędu, mierzonym jego sprawdzeniem albo zweryfikowanym sędzią, zamiast jednego wskaźnika jakości. Powtórz analizę po zmianie modelu, kanału albo linii produktów. Gdy produkt codziennie generuje wyjątki, taksonomię aktualizuje bieżąca kolejka przeglądów; dla agentów procesowych opisujemy ją w osobnym przewodniku.

Gdzie analiza błędów zawodzi

• Czytanie tylko skarg, co ukrywa ciche błędy, jak błędna data dostawy, w którą klient uwierzył
• Oznaczanie śladów przez samych inżynierów albo przez LLM, zanim człowiek sam oznaczy co najmniej 30
• Kategorie tak szerokie, że nie podsuwają żadnej poprawki, na przykład halucynacja
• Zatrzymanie się na stałej liczbie, choć wciąż pojawiają się nowe typy, albo czytanie jeszcze długo po tym, jak lista przestała się zmieniać

Praktyczny pierwszy krok: wyeksportuj 100 niedawnych śladów, usiądź z osobą, która zna tę pracę, zapisz jedno zdanie przy każdym błędzie, a potem porównaj listę z metrykami z pierwotnego planu.

Ewaluacja LLM dla produktów AIJak zamieniać błędy agentów AI z produkcji w testy