Ewaluacja i monitorowanie agentów na produkcji

Pisałem o budowaniu zbiorów eval dla agentów — dyscyplinie przed startem mierzenia, czy agent ukańcza swoje zadania w reprezentatywnym zbiorze. To konieczne, ale odpowiada tylko na jedno pytanie: czy agent działa na przypadkach, które pomyślałeś przetestować? Produkcja odpowiada na inne i trudniejsze: czy działa na rzeczywistości — bałaganiarskich, nieprzewidzianych, przeciwnikowych wejściach, które prawdziwi użytkownicy faktycznie wysyłają? Luka między tymi dwoma pytaniami to miejsce, gdzie agenci po cichu zawodzą, a tylko ciągłe monitorowanie na produkcji ją zamyka. To deep-dive o obserwowaniu agentów na wolności: co logować, co mierzyć, jak łapać degradację, która dzieje się po cichu, i jak awarie produkcyjne wracają do evali, by cały system stawał się lepszy z czasem.

Dlaczego evale przed startem nie wystarczają

Zacznij od granicy, bo motywuje wszystko. Zbiór eval przed startem mierzy agenta wobec przypadków, które wybrałeś — a jakkolwiek reprezentatywnym go uczyniłeś, to skończona, przewidziana próbka. Ruch produkcyjny nie jest ani skończony, ani przewidziany: prawdziwi użytkownicy wysyłają wejścia, których nigdy nie wyobraziłeś, w rozkładach, które przesuwają się z czasem, włącznie z przeciwnikowymi zaprojektowanymi, by złamać agenta. Więc agent, który ocenia się dobrze na twoim zbiorze eval, może wciąż zawieść na produkcji, bo produkcja zawiera przypadki, których twój zbiór nie miał — a jedynym sposobem, by wiedzieć, jest obserwowanie go działającego na prawdziwym ruchu. Evale mówią ci, że agent jest gotowy do startu; monitorowanie mówi ci, czy faktycznie działa teraz. Potrzebujesz obu, a drugie to to, na czym zespoły najczęściej oszczędzają, bo to ciągła praca, a nie brama startu.

Co logować

Monitorowanie agenta zaczyna się od obserwowalności, a agent wymaga więcej niż pojedyncze wywołanie LLM, bo jest cała trajektoria do uchwycenia. Dla każdego uruchomienia loguj dość, by zrekonstruować, co się stało:

Pełną trajektorię. Każdy krok — każdą decyzję, każde wywołanie narzędzia i jego wynik, każde pośrednie wyjście — nie tylko finalną odpowiedź. Gdy agent produkuje zły wynik, trajektoria to gdzie widzisz, jak tam dotarł, a bez niej awaria jest niezbadalna. To agentowy odpowiednik reguły „loguj każdą interakcję”, przeskalowany do wielokrokowej rzeczywistości.
Wejścia i wyjścia. O co agent był poproszony i co ostatecznie zrobił albo zwrócił, byś mógł zobaczyć przypadki, które rzeczywistość faktycznie wysyła, i osądzić wyniki.
Ślad kosztu i zasobów każdego uruchomienia. Kroki podjęte, tokeny wydane, czas upłynięty, narzędzia użyte — bo dla agentów wydajność to metryka zdrowia, a uruchomienie, które się ukończyło, ale wzięło dwadzieścia kroków, to sygnał, nawet jeśli wynik był w porządku.
Awarie i ich rodzaj. Gdy bariera się odpaliła, gdy limit kroków został uderzony, gdy narzędzie dało błąd, gdy agent się poddał — skategoryzowane, by awarie były policzalne, a wzorce widoczne.

Zasadą jest to, że nie możesz monitorować tego, czego nie zapisałeś, a zachowanie agenta to cała trajektoria, nie punkt końcowy. Loguj bogato, bo uruchomienie, które najbardziej potrzebujesz zrozumieć, to takie, które już się skończyło.

Co mierzyć

Logi to surowiec; monitorowanie to metryki, które z nich wyprowadzasz i obserwujesz w czasie. Te, które mają znaczenie dla agenta:

Współczynnik ukończenia zadań na wolności. Nagłówek: jak często agent faktycznie realizuje to, czego użytkownicy chcą, na prawdziwym ruchu? To metryka ukończenia zadań twojego evalu, ale mierzona ciągle na rzeczywistości zamiast raz na zbiorze testowym — a dwie mogą się rozejść, co jest dokładnie tym, co chcesz złapać.
Trendy wydajności. Średnie i ogonowe kroki, tokeny, opóźnienie i koszt na zadanie w czasie. Pełzający wzrost kroków-na-zadanie albo kosztu-na-zadanie to wczesne ostrzeżenie, że coś degraduje, często zanim współczynnik ukończenia widocznie spadnie.
Współczynniki awarii według kategorii. Jak często każdy rodzaj awarii się dzieje, trendowany. Skok w konkretnym typie awarii kieruje cię prosto na to, co się psuje.
Sygnały dryfu. Przesunięcia w rozkładzie wejść albo wyników w czasie — znak, że rzeczywistość odsunęła się od tego, co zbudowałeś i przetestowałeś, co jest jednym z najczęstszych i najcichszych sposobów, w jaki agent degraduje.

Jednoczącym celem jest złapanie cichej degradacji — agenta stającego się gorszym bez niczego rzucającego błąd. Agent może podupadać stopniowo, w jakości albo wydajności, bez żadnego wyjątku kiedykolwiek podniesionego; tylko obserwowanie metryk w czasie to ujawnia. Jasny alert, gdy ukończenie zadań spada albo koszt skacze, zamienia powolny, niewidoczny spadek w zauważone, wykonalne zdarzenie.

Łapanie cichej degradacji

To zasługuje na własne podkreślenie, bo to tryb awarii unikalny dla niedeterministycznych, długowiecznych systemów i ten, do którego łapania monitorowanie istnieje. Agent nie zawodzi tylko przez crash; zawodzi przez powolne stawanie się gorszym — ukańczając mniej zadań, biorąc więcej kroków, dryfując poza-cel — podczas gdy każde pojedyncze uruchomienie wygląda powierzchownie w porządku. Przyczyny są wszędzie: dostawca modelu aktualizuje model pod tobą, twój rozkład wejść przesuwa się, gdy twoja baza użytkowników się zmienia, zależność, na której agent polega, zmienia swoje zachowanie, podkręcenie promptu oddziałuje źle z prawdziwym ruchem. Żadne z tych nie rzuca wyjątku. Jedyną obroną jest obserwowanie trendów: współczynnika ukończenia tykającego w dół, kosztu-na-zadanie tykającego w górę, kategorii awarii wpełzającej. Ustaw progi i alertuj na nich, by pytanie „czy agent wciąż działa tak dobrze, jak działał?” miało ciągle-monitorowaną odpowiedź, zamiast być odkrytym, gdy klient się skarży.

Zamykanie pętli z powrotem do evali

Najcenniejszą rzeczą, którą produkuje monitorowanie produkcyjne, nie są tylko alerty — to materiał, który czyni twoje evale lepszymi. To pętla zwrotna, która sprawia, że cały system poprawia się z czasem, i to wypłata za bogate logowanie:

Awarie produkcyjne stają się przypadkami eval. Każdy nowy sposób, w jaki agent zawodzi na wolności, to przypadek, którego twój zbiór eval nie miał. Uchwyć go, dodaj do zbioru eval, a teraz przyszła zmiana nie może po cichu reintrodukować tej awarii — twój eval rośnie, by pokryć rzeczywistość, której twoja wyobraźnia nie.
Prawdziwy ruch ujawnia, co testować. Rozkład faktycznych wejść mówi ci, gdzie skupić wysiłek eval — częste przypadki, które mają największe znaczenie, i przypadki brzegowe, które faktycznie występują, zamiast tych, które zgadłeś.
Monitorowanie waliduje trafność evalu. Jeśli agent ocenia się dobrze na twoich evalach, ale słabo na produkcji, twój zbiór eval odsunął się od rzeczywistości i potrzebuje aktualizacji. Produkcja to prawda podstawowa, która trzyma twoje evale uczciwymi.

To zamyka pętlę: evale bramkują start, monitorowanie obserwuje rzeczywistość, a awarie rzeczywistości wracają do evali — by siatka bezpieczeństwa agenta rosła, by pasować do świata, w którym faktycznie operuje, zamiast pozostawać zamrożona na tym, co wyobraziłeś przed startem. Agent, którego zbiór eval nigdy nie uczy się z produkcji, to agent, którego testy powoli dryfują od prawdy.

Werdykt

Evale przed startem mówią ci, że agent działa na przypadkach, które pomyślałeś przetestować; produkcja mówi ci, czy działa na rzeczywistości, a tylko ciągłe monitorowanie zamyka tę lukę — bo prawdziwy ruch jest nieskończony, nieprzewidziany i przesuwający się w sposoby, których żaden skończony zbiór eval nie może zawrzeć. Monitorowanie agenta zaczyna się od logowania całej trajektorii — każdego kroku, decyzji, wywołania narzędzia i wyniku, plus wejść, wyjść, kosztu i skategoryzowanych awarii — bo zachowanie agenta to trajektoria, nie punkt końcowy, a nie możesz zbadać tego, czego nie zapisałeś. Z tych logów wyprowadzasz metryki, które mają znaczenie — ukończenie zadań na prawdziwym ruchu, trendy wydajności, współczynniki awarii według kategorii, sygnały dryfu — wszystkie obserwowane w czasie, by złapać cichą degradację, unikalny tryb awarii, gdzie agent powoli staje się gorszy bez żadnego wyjątku kiedykolwiek rzuconego, broniony tylko trendowaniem liczb i alertowaniem na nich. A najwyższą wypłatą jest zamknięcie pętli z powrotem do evali: awarie produkcyjne stają się nowymi przypadkami eval, prawdziwy ruch ujawnia, co testować, a luka między ocenami eval a produkcji trzyma twoje testy uczciwymi — by siatka bezpieczeństwa agenta rosła, by pasować do świata, zamiast pozostawać zamrożona na starcie. Evale bramkują start; monitorowanie trzyma agenta uczciwym na wolności; a dwa razem, z rzeczywistością wracającą do testów, to to, co zamienia wystartowanego agenta w takiego, który dalej działa — co, jak zawsze z agentami, jest częścią, której demo nigdy nie musi robić.