Dlaczego agenci AI przechodzą testy QA, a następnie zawodzą w produkcji

Nieliczne uczenie się staje się dyscypliną inżynierską, która pozwala agentom na poprawę po wdrożeniu, bez psucia tego, co już działało.

Agent AI może przejść wszystkie testy przed wdrożeniem i nadal zawieść w produkcji tydzień później. To nie jest sprzeczność. Zestaw testowy odzwierciedla to, co zespół wiedział, aby przetestować przed wdrożeniem. Produkcja to miejsce, w którym pojawiają się brakujące przypadki: dziwne sformułowania, brakujący kontekst, krawędzie narzędzi, niecierpliwi użytkownicy, sprzeczne zasady i przepływy pracy, których nie wyobraził sobie żaden projektant testu.

Agent jest poprawiany przez użytkowników cały czas. Rozczarowuje użytkowników. Następnie sesja kończy się, log jest przechowywany, a następny użytkownik spotyka podstawowo ten sam system.

To jest powodem, dla którego nieliczne uczenie się staje się centralnym elementem inżynierii agentów. Nie jest to funkcja jednego produktu. Jest to kategoria metod, które pozwalają agentom na poprawę dzięki doświadczeniu, przy zachowaniu tego, co już działa. Klasyczne badania nad nielicznym uczeniem się opisywały problem jako uczenie się w czasie bez katastrofalnego zapomnienia. Agenci powodują, że ten problem staje się szerszy. Rzecz, która ulega zmianie, może być modelem, ale może również być promtem, narzędziem, umiejętnością, przepływem pracy lub pamięcią.

Ta różnica jest istotna, ponieważ większość awarii agentów nie jest rozwiązywana przez natychmiastowe przeszkolenie modelu.

Odruch dostrajania jest zbyt wąski

Gdy zespoły mówią o poprawie systemu AI, plan brzmi często tak: zbierz awarie, oznacz lepsze odpowiedzi, dostrój model. Ten odruch jest zrozumiały. Nadzorowane dostrajanie, Bezpośrednia optymalizacja preferencji, Grupowa relatywna optymalizacja polityki, oraz metody wydajne pod względem parametrów, takie jak LoRA, są przydatnymi narzędziami, gdy model sam wymaga zmiany.

Ale wiele awarii w produkcji nie jest spowodowanych przez wagi modelu. Są to awarie systemowe.

Agent może polegać na sterylnej pamięci, pominąć wymagane potwierdzenie, wywołać narzędzie z niewłaściwym argumentem lub skierować przypadek przez niewłaściwy przepływ pracy. Często problemem nie jest zdolność podstawowego modelu. Jest to kontekst, pamięć, interfejs narzędzia lub przepływ pracy otaczający go.

Nowoczesny agent składa się z kilku warstw. Model rozważa i generuje. Obudowa wokół niego definiuje prompty, narzędzia, umiejętności, kod, routing i przepływ pracy. Pamięć przenosi fakty i nauczone procedury przez sesje. Nieliczne uczenie się jest dyscypliną decydującą, jaka warstwa powinna ulec zmianie, jak mała może być zmiana i jak sprawdzić, czy zmiana naprawdę pomogła.

Czasami odpowiednim rozwiązaniem jest zapis w pamięci. Czasami jest to edycja promptu. Czasami jest to obudowa narzędzia, reguła routingu lub łatka przepływu pracy. Dostrajanie powinno pozostać dostępne, ale nie powinno być pierwszą odpowiedzią na każdą awarię.

Testy są przydatne, ale produkcja rzadko daje im przyzwolenie

Istnieje interesująca praca nad optymalizacją samej obudowy agenta. Metody takie jak GEPA, Meta-Harness, oraz pokrewne podejścia do optymalizacji promptów lub przepływu pracy traktują agenta jako system, który może być mutowany i testowany. Mogą one proponować edycje promptów lub innych składników obudowy, uruchamiać kandydatów i zachowywać wersje, które uzyskują lepsze wyniki.

To jest właściwy kierunek. Przenosi on poprawę poza wąskie ramy „aktualizacji wag” i do szerszych ram „poprawy agenta”.

Ale jest haczyk: te metody zwykle zakładają test. Potrzebują zadania, które można wykonać wielokrotnie, i ewaluatora, który mówi, czy kandydat A jest lepszy niż kandydat B. Bez tego optymalizacja staje się zgadywaniem z lepszymi narzędziami.

To nie jest to, co większość zespołów ma w produkcji.

To, co mają, to logi. Mają ślady, korekty użytkowników, bilety wsparcia, zdarzenia thumbs-down, notatki eskalacyjne i okazjonalne opinie ekspertów. Te sygnały są cenne, ale nie są jeszcze testem. Mówią one, że coś się stało. Nie mówią automatycznie, jak odtworzyć to, jaki powinien być sukces, czy jak ocenić proponowaną poprawkę.

To przerwa jest miejscem, w którym wiele wysiłków ciągłego uczenia się zawodzi. Zespół ma doświadczenie, ale nie ma jeszcze środowiska uczenia się.

Logi nie są lekcjami

Log produkcji rejestruje jeden ślad interakcji. Użytkownik poprosił o lot. Agent wyszukał. Użytkownik powiedział, że data była nieprawidłowa. To jest dowód awarii, ale nie jest wystarczające, aby się czegoś nauczyć.

Log nie definiuje kontrfaktów. Czy agent powinien poprosić o potwierdzenie? Czy powinien wywnioskować datę z wcześniejszego kontekstu? Czy powinien wywołać inne narzędzie? Czy powinien odmówić kontynuowania, dopóki nie rozwiąże niejednoznaczności? Człowiek może wiedzieć odpowiedź po przeczytaniu śladu, ale system nie otrzymuje tej struktury za darmo.

Aby ciągłe uczenie się działało, surowa awaria musi zostać przekształcona w coś, co można odtworzyć. To oznacza zadanie, które agent może ponownie spotkać, użytkownik lub symulator, który odtwarza istotny wzorzec, narzędzia, które agent może wywołać, oraz ewaluatory, które definiują sukces. Ewaluator może sprawdzić ostateczną odpowiedź, wywołania narzędzi, granicę polityki, opóźnienie, koszt lub wszystko powyższe.

To jest mniej widoczna część pracy, ale jest to część, która czyni poprawę realną. Gdy awaria staje się środowiskiem, które można odtworzyć, można zadać konkretną pytanie: czy proponowana poprawka naprawdę poprawiła zachowanie?

Bez tego kroku zespoły są głównie łatane z pamięci.

David Silver i Richard Sutton opisali nadchodzącą erę doświadczenia, w której agenci uczą się głównie z interakcji ze światem, a nie ze statycznych danych ludzkich. Dla agentów przedsiębiorstw ta wizja zależy od przekształcenia nieładnego doświadczenia produkcyjnego w środowiska, które można odtworzyć, ocenić i ponownie wykorzystać.

Doświadczenie samo w sobie nie jest wystarczające. Musi być uczynione testowalnym.

Regresja jest ukrytym kosztem

Nawet gdy awaria staje się testowalna, najtrudniejszą częścią pozostaje naprawienie jej bez złamania czegoś innego.

Każdy, kto utrzymywał złożonego agenta, widział ten wzorzec. Dodajesz instrukcję, aby agent eskalował agresywne prośby o zwrot pieniędzy. Teraz eskaluje rutynowe zwroty, które powinny być obsługiwane szybko. Zmniejszasz wywołania narzędzi w jednym przepływie pracy. Teraz inny przepływ pracy pomija wymagane sprawdzenie. Poprawiasz sterylną pamięć. Teraz agent przeszacowuje korektę do innego produktu.

Każda poprawka ma sens lokalnie. System nadal dryfuje globalnie.

To jest wersja agenta katastrofalnego zapomnienia. W sieciach neuronowych fraza zwykle odnosi się do nowego szkolenia, które nadpisuje starsze zdolności. W agentach awaria jest szersza i często trudniejsza do zobaczenia. Zapomnienie może wystąpić w promptach, narzędziach, pamięci, routingu i przepływie pracy. Pojawia się nie jako czysty wskaźnik na krzywej szkoleniowej, ale jako użytkownik mówiący: „To kiedyś działało”.

Dlatego kontrola regresji nie może być ostatecznym krokiem przeglądu. Musi być wewnątrz samej pętli uczenia się.

Celem nie jest po prostu maksymalizacja wydajności w najnowszej awarii. Celem jest poprawienie nowego przypadku przy zachowaniu starych. Każda poprawka, która działa, powinna stać się częścią rosnącej pamięci agenta o tym, co musi nadal działać. W praktyce oznacza to, że stare awarie stają się testami regresji. Historia agenta staje się ograniczeniem, a nie tylko archiwum.

To jest miejsce, w którym ciągłe uczenie się staje się bardziej poważną inżynierią oprogramowania niż zabawą z promptami. Poprawka nie jest dobra, bo brzmi lepiej. Jest dobra, bo poprawia zmierzone zachowanie i nie regresuje zachowań, które system już zdobył.

Czego wymaga praktyczne ciągłe uczenie się

Pętla ciągłego uczenia się gotowa do produkcji wymaga czterech właściwości.

Po pierwsze, awarie muszą być odtworzalne. Jednorazowa awaria to anegdota. Odtworzalne, oceniane środowisko to test. Dopóki agent nie będzie mógł spotkać tego samego wzorca ponownie, nikt nie będzie mógł udowodnić, że poprawka działała.

Po drugie, diagnoza musi być holistyczna. Poprawka może należeć do modelu, ale może również należeć do pamięci, promptu, warstwy narzędzi lub przepływu pracy. Najlepsza poprawka jest zwykle najmniejszą trwałą zmianą, która wyjaśnia awarię.

Trzecia, uczenie się musi być całożyciowe. Agent nie powinien poprawiać się w tym tygodniu, cicho unieważniając zachowanie z poprzedniego tygodnia. Poprzednie sukcesy powinny stać się ograniczeniami podczas optymalizacji, a nie niespodziankami po wdrożeniu.

Czwarta, pętla musi być wydajna. Jeśli każda poprawka wymaga projektu szkoleniowego co kwartał, system nigdy nie będzie mógł nadążyć za produkcją. Pętla musi najpierw spróbować tanich poprawek, eskalować tylko w razie potrzeby i utrzymywać weryfikację blisko zmiany.

Żadne z tego nie oznacza, że agenci powinni aktualizować się ślepo. Oznacza to coś przeciwnego. Poprawka powinna stać się mierzalna. Każda zmiana powinna mieć test, wynik przed i po, oraz sprawdzenie regresji.

To jest to, co zmienia ciągłe uczenie się z mglistej aspiracji w dyscyplinę inżynierską.

Przyszłość agentów nie będzie określona tylko przez większe okna kontekstowe, silniejsze modele podstawowe lub więcej narzędzi. Te rzeczy będą miały znaczenie. Ale ważniejszym pytaniem dla przedsiębiorstw jest to, co się dzieje po wdrożeniu.

Gdy agent zawiedzie jutro, czy system może przekształcić tę awarię w test? Czy może skierować poprawkę do odpowiedniej warstwy? Czy może udowodnić, że poprawka pomogła? Czy może udowodnić, że nic innego nie zostało złamane?

Jeśli odpowiedź brzmi nie, agent nie naprawdę uczy się z produkcji. Nagromadza ryzyko.

Agenci, którzy będą miały znaczenie, zrobią coś lepszego. Będą kumulować.