Bariery i evale dla agentów produkcyjnych

Pisałem wcześniej o tym, czym jest agent — function calling w pętli — i o ewaluowaniu niedeterministycznego wyjścia LLM. Postawienie agenta na produkcji łączy najtrudniejsze części obu, i potem dodaje nowe. Agent to nie pojedyncze wywołanie, które możesz owinąć i sprawdzić; to pętla, gdzie model decyduje o akcjach, uruchamia narzędzia i steruje przez wiele kroków, co znaczy znacznie większą powierzchnię awarii i fundamentalnie trudniejszą rzecz do ewaluowania. Uczynienie agenta produkcyjnego godnym zaufania bierze dwie odrębne dyscypliny pracujące razem: bariery, które ograniczają, co agent może zrobić w czasie wykonania, i evale, które mierzą, czy faktycznie działa w czasie. Odpowiadają na różne pytania — „czy to może pójść źle właśnie teraz?” kontra „czy to staje się lepsze czy gorsze?” — i potrzebujesz obu. To deep-dive o każdej i o tym, dlaczego agent wymaga więcej od obu, niż kiedykolwiek wymagało pojedyncze wywołanie LLM.

Dlaczego agent jest trudniejszy niż pojedyncze wywołanie

Zacznij od rzeczy, która czyni wszystko inne trudniejszym. Pojedyncze wywołanie LLM ma jedno wejście, jedno wyjście i jedną awarię: daje złą odpowiedź. Agent ma wiele kroków, każdy budujący na poprzednim, każdy potencjalnie wołający narzędzie, które działa na świecie — więc jego tryby awarii mnożą się i kumulują. Zła decyzja w kroku drugim nie tylko produkuje złą odpowiedź; wysyła agenta ścieżką, gdzie każdy późniejszy krok rozumuje z błędu, możliwie podejmując prawdziwe akcje po drodze. To dlatego agent potrzebuje zarazem ciaśniejszego ograniczenia w czasie wykonania (bo promień rażenia złej akcji jest większy) i bardziej wyrafinowanej ewaluacji (bo oceniasz całą trajektorię, nie pojedyncze wyjście). Trzymaj to rozróżnienie — ograniczenie w czasie wykonania kontra pomiar w czasie — bo dwie dyscypliny mapują się na nie.

Bariery: ograniczanie agenta w czasie wykonania

Bariery to kontrole czasu wykonania, które ograniczają, co agent może zrobić gdy działa, by gdy pójdzie źle — a pójdzie — szkoda była ograniczona. To pas, aktywny przy każdym pojedynczym uruchomieniu. Niezbędny zestaw, budujący na podstawach bezpieczeństwa agentów, ale wzmocniony pod produkcję:

• Bariery wejścia. Waliduj i sanityzuj to, co wchodzi do agenta. Filtruj próby prompt-injection, odrzucaj źle uformowane albo poza-zakresem żądania i ograniczaj przestrzeń zadania, zanim pętla w ogóle się zacznie. Agent nigdy nie powinien zacząć uruchomienia na wejściu, którego nie sprawdziłeś.
• Bramkowanie akcji. Najważniejsza bariera. Narzędzia, które działają — modyfikują dane, wysyłają wiadomości, wydają pieniądze, cokolwiek nieodwracalne — muszą przejść przez punkt kontroli: zatwierdzenie człowieka albo co najmniej twarde sprawdzenie polityki, przed wykonaniem. Narzędzia tylko-do-odczytu mogą działać swobodnie; brzemienne nie mogą działać z niezatwierdzonej decyzji modelu. To nie-do-negocjacji dla agenta na produkcji.
• Limity kroków i zasobów. Twarda czapka na iteracjach, by rozszalała pętla padła po N krokach zamiast kręcić się wiecznie; timeouty, by utknięty agent nie zawisł; i czapki kosztu, bo agent to wiele opomiarowanych wywołań, a rozszalały jest drogi, gdy jest bezużyteczny. Te zamieniają „pętli wiecznie / kosztuje bez ograniczeń” w ograniczone, obsługiwalne awarie.
• Bariery wyjścia. Waliduj to, co agent produkuje albo ma zrobić, zanim dotrze do użytkownika albo systemu — sprawdzając nieodpowiednią treść, naruszenia polityki albo akcje poza zakresem agenta. Ostatnia linia, zanim wyjście agenta stanie się realne.
• Piaskownica i najmniejszy przywilej. Daj agentowi tylko narzędzia i dostęp, których naprawdę potrzebuje, ograniczone tak wąsko, jak to możliwe, by zasięg dowolnego błędu był ograniczony strukturalnie. Agent, który tylko musi czytać, nie może uszkodzić tego, czego nie może dotknąć.

Jednoczącą zasadą jest ta, do której ta seria wciąż wraca: model proponuje, twój kod dysponuje. Każda brzemienna rzecz, którą agent „decyduje”, przechodzi przez punkt kontroli, który posiadasz, gdzie walidujesz, bramkujesz, ograniczasz albo odmawiasz. Bariery nie czynią agenta poprawnym; czynią jego niepoprawność przeżywalną, co na produkcji jest tym, co ma znaczenie.

Evale: mierzenie agenta w czasie

Bariery powstrzymują uruchomienie od wyrządzenia szkody, ale nie mówią ci, czy agent jest w ogóle dobry, ani czy zmiana, którą zrobiłeś, poprawiła go czy zdegradowała. To jest to, do czego służą evale — a ewaluowanie agenta jest znacząco trudniejsze niż ewaluowanie pojedynczego wyjścia LLM, bo nie oceniasz jednej odpowiedzi, oceniasz całą trajektorię: sekwencję decyzji i wywołań narzędzi ku celowi. Dyscypliny:

• Ewaluuj całą trajektorię, nie tylko finalną odpowiedź. Agent może dotrzeć do właściwej odpowiedzi przez okropną ścieżkę — dziesięć marnotrawnych kroków, narzędzie zawołane źle, potem odzyskane — albo złą odpowiedź przez rozsądnie-wyglądające kroki. Obchodzi cię zarazem wynik i ścieżka: czy zrealizował zadanie i czy zrobił to wydajnie i poprawnie po drodze? Ocenianie tylko finalnego wyjścia mija połowę tego, co może być złe.
• Mierz ukończenie zadania wobec reprezentatywnego zbioru. Jak z evalami pojedynczego wyjścia, zbuduj zbiór reprezentatywnych zadań — włącznie z trudnymi i przeciwnikowymi — i mierz, jak często agent faktycznie ukańcza je poprawnie. To twoja nagłówkowa metryka: czy agent realizuje to, do czego jest, w zakresie wejść, z którymi się zmierzy?
• Trzymaj zbiór regresji przeszłych awarii. Za każdym razem, gdy agent zawiedzie w nowy sposób na produkcji, dodaj ten scenariusz do zbioru eval, by przyszła zmiana nie mogła po cichu reintrodukować awarii. Z czasem ten zgromadzony zbiór „sposobów, w jakie agent się złamał” staje się najcenniejszym aktywem testowym, jakie masz — dokładnie jak dla funkcji pojedynczego wyjścia, ale bardziej, bo agenci mają więcej sposobów, by się złamać.
• Śledź wydajność, nie tylko poprawność. Kroki podjęte, narzędzia zawołane, tokeny wydane, czas upłynięty — bo agent, który ukańcza zadanie, ale bierze dwadzieścia kroków, by zrobić trzykrokową pracę, jest zarazem drogi i kruchy. Wydajność to wymiar jakości dla agentów w sposób, w jaki nie jest dla pojedynczego wywołania.

Zmianą od evali pojedynczego wyjścia jest ruch od oceniania odpowiedzi do oceniania procesu. Jest trudniejszy, ale to jedyny sposób, by wiedzieć, czy twój agent działa i czy twoje zmiany pomagają — a bez niego dostrajasz wielokrokowy niedeterministyczny system na ślepo, co jest przepisem na agenta, który po cichu degraduje.

Jak te dwie pasują razem

Kluczowym punktem jest to, że bariery i evale są komplementarne, nie alternatywne, bo odpowiadają na różne pytania w różnych czasach. Bariery operują w czasie wykonania, na każdym pojedynczym uruchomieniu, ograniczając, co to wykonanie może zrobić — chodzi o bezpieczeństwo i ograniczenie, zapewnienie, że żadne uruchomienie nie wyrządza szkody. Evale operują w czasie, na zbiorze testowym, mierząc, czy agent działa dobrze i czy zmiany go poprawiają — chodzi o jakość i postęp. Agent z barierami, ale bez evali, jest bezpieczny, ale nie masz pojęcia, czy jest w ogóle dobry, ani czy czynisz go gorszym; agent z evalami, ale bez barier, może oceniać się dobrze na twoim zbiorze, ale wyrządzić prawdziwą szkodę na przeciwnikowym wejściu produkcyjnym, którego nie przetestowałeś. Agenci produkcyjni potrzebują obu: barier, by awarie były przeżywalne, evali, byś mógł faktycznie poprawić rzecz z pewnością. Razem to one zamieniają imponujące demo agenta w agenta, którego możesz odpowiedzialnie uruchamiać przed prawdziwymi użytkownikami i prawdziwymi systemami.

Werdykt

Postawienie agenta na produkcji jest trudniejsze niż pojedyncze wywołanie LLM, bo agent to pętla z pomnożoną, kumulującą się powierzchnią awarii — a godność zaufania wymaga dwóch odrębnych dyscyplin pracujących razem. Bariery ograniczają agenta w czasie wykonania, na każdym uruchomieniu: waliduj wejścia, bramkuj brzemienne akcje za zatwierdzeniem albo twardą polityką (ta nie-do-negocjacji), egzekwuj limity kroków, czasu i kosztu, by rozszalałe pętle padały ograniczone, waliduj wyjścia i stosuj piaskownicę najmniejszego przywileju, by zasięg dowolnego błędu był ograniczony. Nie czynią agenta poprawnym; czynią jego niepoprawność przeżywalną. Evale mierzą agenta w czasie wobec reprezentatywnego zbioru, a kluczową zmianą od ewaluacji pojedynczego wyjścia jest ocenianie całej trajektorii — wyniku i ścieżki — nie tylko finalnej odpowiedzi, śledzenie ukończenia zadania, trzymanie rosnącego zbioru regresji przeszłych awarii i mierzenie wydajności obok poprawności. Te dwie są komplementarne: bariery odpowiadają „czy to uruchomienie może wyrządzić szkodę właśnie teraz?”, a evale odpowiadają „czy ten agent jest dobry i czy moje zmiany pomagają?” — ograniczenie w czasie wykonania kontra pomiar w czasie. Agent potrzebuje obu, bo bariery bez evali to bezpieczne-ale-nieznane, a evale bez barier to dobre-na-papierze-ale-niebezpieczne. Zbuduj obie, a masz dyscyplinę, która zamienia demo agenta w agenta produkcyjnego, któremu faktycznie możesz ufać — co, jak zawsze, jest większością prawdziwej pracy.