Stabilne agenty AI w praktyce: koszty, odchylenia pamięci i problem 80%.
Co poszło nie tak po zastąpieniu jednorazowych poleceń agentami ciągle aktywnymi: niekontrolowane rachunki za tokeny, powierzchowne prośby o zmiany, odchylenia od specyfikacji oraz dlaczego praca programisty przeniosła się w kierunku kontekstu.
Źródła: I Replaced My Prompting Habit With Persistent Agents. Here’s What Broke.
Przez około dwa lata standardowym sposobem korzystania z modelu była rozmowa. Wpisujesz wiadomość, czytasz odpowiedź, a następnie ją wykorzystujesz lub się z nią spierasz. Jesteś w ciągłym obiegu i sprawdzasz każdy wynik, zanim trafi on gdziekolwiek indziej. Następnie zalecenia uległy zmianie: przestać wpisywać polecenia, zamiast tego uruchamiać agenty, które pracują samodzielnie, mają pamięć, narzędzia oraz uprawnienia do ukończenia zadań bez konieczności nadzoru na każdym kroku. Spróbuj tego przez tydzień z agentami, które potrafią czytać kod, wykonywać polecenia i otwierać pull requests – w niektórych przypadkach to rozwiązanie się sprawdza. W wielu jednak nie. Błędy pojawiają się w dość przewidywalnej kolejności.
Dlaczego ludzie porzucili polecenia
Odchodzenie od używania promptów odzwierciedla rzeczywisty limit. Prompt to jedno pytanie i jedna odpowiedź, co wystarcza do szybkiego wyszukiwania informacji. Są jednak nieskuteczne w sytuacjach, gdy model musi zbierać dane z kilku źródeł, analizować to, co wie, korzystać z narzędzi i korygować swoje działania na podstawie uzyskanych informacji. Prośba o zrobienie tego wszystkiego za jednym razem nie odpowiada sposobowi pracy w rzeczywistym świecie.
Potrzebny jest cykl: myślenie, działanie, sprawdzenie wyniku, ponowne myślenie. Dodanie pamięci, która przetrwa między sesjami, daje to, co ludzie nazywają agentem trwałym. Jedna kwestia wymaga jasnego określenia już na początku – transkrypcja rozmowy nie jest pamięcią agenta. Pamięć przypomina raczej plik, do którego agent może czytać i pisać, aby zapamiętywać informacje. Ta różnica zostanie omówiona poniżej.
Zatem ta decyzja ma sens i nikt nie powinien udawać inaczej. Ważne jest to, co dzieje się po faktycznym podjęciu tego kroku – począwszy od kosztów, a skończywszy na tym, kto nadal odpowiada za rezultat.
Rachunek
Pierwszą rzeczą, o której nikt nie wspomina, jest to, że każde wezwanie API zaczyna się od zera. Dostawca nie przechowuje żadnych informacji o wcześniejszych wezwaniach, więc program musi za każdym razem wysyłać całą rozmowę, gdy o coś prosi. Pierwszy krok jest tani. Do dwudziestego kroku, gdy pojawiają się wyniki narzędzi i dodatkowe szczegóły, każde wezwanie może zawierać tysiące słów, a za wszystkie one trzeba płacić przy każdym z nich.
Rachunki stają się nieprzyjemne. Analiza trzydziestu zespołów inżynieryjnych wykazała, że jeden opóźniony krok w realizacji zadania kosztował około piętnastu centów. Brzmi to błahe, dopóki nie pomnoży się to przez pięćdziesiąt kroków w jednym zadaniu, dziesiątki zadań dziennie na jednego programistę oraz cały zespół. Wynik wynosi sześć cyfr miesięcznie, a agenci zużywają znacznie więcej tokenów niż przy zwykłej rozmowie do wykonania tego samego zadania.
Kolejnym ryzykiem jest niekontrolowany wzrost kosztów. Pętla, która ciągle próbuje coś, co nie może się udać, nadal generuje rachunki. Krąży historia o firmie, która dostała rachunek w wysokości pół miliarda dolarów właśnie z powodu takiego schematu. Niezależnie od tego, czy ta kwota jest dokładna, zupełnie wiarygodne jest to, że jeden źle skonfigurowany agent może zużyć cały dzienny budżet na dziesięciominutowe zadanie ręczne. Najbardziej niepokojące jest to, że wszystko wygląda normalnie, podczas gdy to się dzieje. Agent pracuje – po prostu krąży w kółko.
Rozwiązanie, które sprawdziło się w praktyce, składa się z trzech elementów:
- Jasny, dzienny budżet dla każdego agenta, kontrolowany poza samym agentem
- Okno kontekstowe o zmiennej wielkości, dzięki któremu wcześniejsze kroki są usuwane i nie gromadzą się
- Przekazywanie rutynowych zadań taniego modelu, a tylko trudne przypadki – do silniejszego modelu
Zespoły, które zastosowały takie proste rozwiązania, stwierdziły, że koszty agentów spadły o ponad 50% w ciągu miesiąca. Mądrzejszy model nigdy nie był kluczem do sukcesu; kluczową rolę odgrywała kontrola, i warto o tym otwarcie mówić, ponieważ pierwszą reakcją przy otrzymaniu rachunku jest szukanie lepszego modelu.
Pierwszy pull request to podstęp
Pierwszy pull request agenta może wyglądać imponująco – cała funkcja pojawia się w ciągu kilku minut, wszystkie testy przechodzą, i naturalną reakcją jest ulga. Potem pojawia się podejrzenie, że rzeczywała praca jeszcze nie została wykonana, a to podejrzenie zazwyczaj jest słuszne.
Zespoły ciągle zgłaszają ten sam wzorzec: pierwszy PR robi wrażenie, a przy piątym coś psuje się w produkcji, czego żaden test nie wykrył. Brakowało ponownej próby. Przypadek null nie został obsłużony. Sprawdzenie autoryzacji obejmowało trzy punkty końcowe i pominęło czwarty. Kod działał, ale nie wytrzymał kontaktu z rzeczywistością.
Często nazywa się to problemem 80%. Agent realizuje oczywiste 80% zadań, ale stale pomija te 20% składające się z wymagań niefunkcjonalnych, trybów awarii i spójności architektonicznej, ponieważ te 20% wymaga kontekstu, którego agent nie posiada. Pisze kod, który działa, a nie kod, który przetrwa.
Oto jednozdaniowa wersja tego problemu: kod się skompilował, przeszedł sprawdzenie formatowania i mimo to robił złą rzecz, ponieważ uwaga na niego osłabła. Wynik wygląda kompletnie, więc jest szybko przejrzany, tak jak spojrzy się na prace ukończone przez juniora.
Lepsze naprawienie problemu później kosztuje więcej niż jego szybka korekta na początku. Te luki pojawiają się w całym kodzie, więc nie ma jednego miejsca, gdzie można je naprawić.
Pamięć występuje w dwóch formach
Największym problemem była pamięć, która przybierała dwie formy, które początkowo nie były oczywiste.
Pierwsza z nich to zapominanie w trakcie wykonywania zadania. Gdy proces trwa zbyt długo, agent traci informacje o decyzjach podjętych na początku. Powszechnym rozwiązaniem w tej branży jest dostarczenie mu większej ilości kontekstu – miliona lub dwóch milionów tokenów – w przekonaniu, że widok wszystkiego prowadzi do lepszych decyzji. To jednak nie działa. Agent, który musi przetwarzać dużą ilość skomplikowanego kodu, popada w zamieszanie. Może naprawić jeden problem, ale spowodować większy, ponieważ widzi wiele małych elementów, ale nie rozumie całości.
Druga forma jest bardziej podstępna i to właśnie ona powoduje rzeczywiste szkody: odchylenie kontekstowe. Agent kieruje się plikami konfiguracyjnymi i specyfikacjami. Baza kodu ewoluuje, podczas gdy te pliki pozostają nieruchome. Wkrótce pracownik działający nieprzerwanie zaczyna z pewnością siebie pisać kod według standardu, który przestał obowiązywać już miesiące temu, a nic nie wygląda źle, ponieważ słusznie postępuje zgodnie z instrukcjami pochodzącymi ze starych danych. Gdy takie sytuacje występują w kilku agentach i repozytoriach, luka ta powiększa się z każdym dniem bez żadnego dźwięku.
Wtedy winę przenosi się z modelu. Problemem nie był model, lecz pamięć projektu – ta część przechowywana na dysku, która przetrwa każdą sesję i której nie stworzono.
Zmieniła się rola programisty
Programista nie zmniejszył się w liczbie. Zmieniło się miejsce jego pracy, a rezultat jest mniej dramatyczny niż to, co obiecywano lub co krytykowano.
Kiedy agent działa przez długi czas, tworzenie precyzyjnych instrukcji przestaje mieć tak wielkie znaczenie. Kluczowy jest kontekst: to, co agent może zobaczyć, co może zapamiętać, co jest mu dozwolone robić oraz jak można dowiedzieć się, co zrobił. Zespoły, które osiągnęły wyniki, nie korzystały z genialnych instrukcji – opracowywały specyfikacje, utrzymywały je w aktualności, dostarczały je agentowi jako jego pamięć i same sprawdzały architekturę.
Praca oparta na specyfikacjach sprawia, że deweloper staje się ważniejszy, a wysiłek jest skierowany na inne cele: określanie tego, co system powinien robić, zatwierdzanie granic jego działań oraz analiza proponowanej architektury. Gdy zmieniają się wymagania, zmienia się specyfikacja, a nie instrukcje. Agent opracowuje projekty, je wdraża i testuje zgodnie z tą specyfikacją, nie decydując o kierunku rozwoju. Taki podział był jedynym rozwiązaniem, które zapobiegało awariom.
Pod tym wszystkim kryje się umiarkowana ostrość. Jedno z badań zmierzyło czas pracy programistów nad rzeczywistymi kodami i stwierdziło, że są oni mniej więcej o 19% wolniejsi, chociaż sami czuli się szybsi o około 20%. Poczucie szybkości i rzeczywista szybkość rozdzieliły się. Wytrwałe agenty powiększają tę luki, gdy tylko mają taką możliwość, ponieważ doskonale potrafią tworzyć wrażenie szybkości. To, co ją zmniejsza, jest nudne, ale konieczne: zarządzanie, przeglądanie, specyfikacja odpowiadająca rzeczywistości oraz ograniczenie wydatków.
Powrót do czystego formułowania zadań nie jest rozwiązaniem, ponieważ pętla jest potężniejsza. Ale agent nie jest kolegą. To szybki, pewny siebie wykonawca, który nigdy nie przyznał się do braku pewności. Zatrzymuje się takiego wykonawcę, ponieważ jest przydatny, i zawsze czyta wszystko, co mu podaje.
Literatura pokrewna
- Tworzenie zapytań dla modelu Astra openai: autonomia, umiejętności, weryfikacja i zasady zatrzymania — Stare nawyki tworzenia zapytań mogą szkodzić nowszemu, bardziej autonomicznemu modelowi. Skoryguj poziom autonomii, priorytet instrukcji, styl, zasady testowania i zatrzymania za pomocą gotowych do skopiowania zapytań oraz listy kontrolnej.
- Ekspertowe rozwiązania RAG: HyDE, kompresja, samodzielne zapytania i prace agencyjne — Cztery zaawansowane techniki wyszukiwania danych do zastosowań produkcyjnych RAG w Haystack: HyDE, kompresja kontekstowa, samodzielne zapytania i prace agencyjne, wraz z informacjami o tym, kiedy je stosować.