Agenci AI rzadko ulegają awarii. Zawodzą po cichu — badania wyjaśniają dlaczego

Agenci oparte na dużych modelach językowych odpowiadają już na zgłoszenia do działu obsługi klienta, odpytują bazy danych i planują podróże. Gdy coś idzie nie tak, zazwyczaj zwracają odpowiedź brzmiącą pewnie i kod powodzenia. Coraz więcej badań wyjaśnia, dlaczego takie błędy trudno dostrzec i jak zespoły inżynierskie uczą się je mierzyć.

Awaria, która wygląda jak sukces

Tradycyjne oprogramowanie zwykle zawodzi w sposób wyraźny. Funkcja zgłasza wyjątek, serwer zwraca kod błędu, a pulpit monitorowania czerwienieje. Agent AI działa inaczej. Jego działanie ma postać pętli: model językowy odczytuje prompt, decyduje, czy wywołać narzędzie, takie jak interfejs API wyszukiwarki lub bazę danych, odczytuje wynik i postanawia, co zrobić dalej. Na każdym etapie może dojść do błędu, choć wszystkie żądania sieciowe w całym łańcuchu kończą się powodzeniem.

Rozważmy typowy przypadek. Narzędzie pogodowe ulega awarii i w zwróconej odpowiedzi, która poza tym wygląda normalnie, pojawia się tekst „usługa niedostępna”. Model odczytuje ten tekst, uprzejmie przeprasza albo, co gorsza, na podstawie danych treningowych tworzy wiarygodnie brzmiącą prognozę. Użytkownik otrzymuje płynną odpowiedź. W dziennikach serwera widać udane żądanie o typowym czasie odpowiedzi. W konwencjonalnym zestawie narzędzi do monitorowania nic nie odnotowuje, że coś poszło nie tak.

Dostawcy modeli opisują tę samą lukę we własnej dokumentacji. Przewodnik Google dotyczący interfejsu Gemini API wyjaśnia, że model „sam nie wykonuje funkcji”. Jedynie proponuje nazwę funkcji i argumenty, a wywołanie realizuje aplikacja programisty. To właśnie aplikacja jest więc jedynym elementem systemu, który widzi rzeczywisty wynik. Przewodnik inżynierski Anthropic na temat budowania agentów zwraca uwagę na powiązaną kwestię: agenci potrzebują na każdym etapie „rzeczywistych danych” z otoczenia, takich jak wyniki działania narzędzi, aby oceniać własne postępy. Gdy narzędzie zgłasza awarię w postaci zwykłego tekstu, te dane są błędne, a agent nie ma możliwości tego zauważyć.

Nie jest to nowy rodzaj problemu, lecz jedynie bardziej wyrazista odsłona starego. W 2015 roku inżynierowie Google pod kierownictwem D. Sculleya opisali „ukryty dług techniczny” w systemach uczenia maszynowego. Argumentowali, że większość ryzyka związanego z produkcyjnym systemem uczenia maszynowego leży poza kodem modelu — w zależnościach od danych, konfiguracji i kodzie łączącym poszczególne elementy. Agenci dodają do tej listy nową warstwę. Prompty i opisy narzędzi to elementy konfiguracji, które mogą zmienić zachowanie systemu bez jakiejkolwiek zmiany jego kodu.

Drobne zmiany, duże skutki

Jak duże znaczenie może mieć niewielka zmiana promptu? W artykule zaprezentowanym na konferencji ICLR 2024 Melanie Sclar z University of Washington i jej współpracownicy zmienili wyłącznie format promptów few-shot: separatory, odstępy i wielkość liter. Znaczenie pozostało takie samo. Mimo to wyniki tego samego zadania w modelu LLaMA-2-13B różniły się nawet o 76 punktów dokładności. Wrażliwość ta nie zniknęła w przypadku większych modeli, większej liczby przykładów ani dostrajania instrukcyjnego.

Autorzy zalecają podawanie zakresu wyników uzyskiwanych przy wiarygodnych formatach promptów, zamiast jednej wartości. Dla zespołów inżynierskich wniosek praktyczny jest prostszy. Zmiana promptu to zmiana w kodzie. Wymaga historii wersji i testu, zanim trafi do użytkowników.

To samo dotyczy opisów narzędzi, które model odczytuje jako część promptu. Przewodnik Anthropic zaleca poświęcać definicjom narzędzi „tyle samo uwagi przy projektowaniu promptów”, co głównemu promptowi. Opisuje agenta programistycznego, który wciąż popełniał błędy przy używaniu względnych ścieżek do plików. Gdy zmieniono narzędzie tak, by wymagało ścieżek bezwzględnych, model zaczął z niego korzystać bez błędów. Model się nie zmienił. Zmienił się tylko opis, który odczytywał.

Jeden sukces niewiele dowodzi

Drugi nurt badań dotyczy spójności działania. Test porównawczy τ-bench, opublikowany przez Shunyu Yao i jego współpracowników z Sierra oraz zaprezentowany na konferencji ICLR 2025, symuluje rozmowy z obsługą klienta, w których agent musi korzystać z narzędzi i przestrzegać zasad biznesowych. Autorzy wprowadzili miarę o nazwie pass^k: prawdopodobieństwo, że agent poprawnie rozwiąże to samo zadanie we wszystkich k próbach.

Wyniki dały do myślenia. Agent GPT-4o rozwiązał około 61% zadań z handlu detalicznego w pojedynczej próbie. Gdy musiał poprawnie wykonać to samo zadanie osiem razy z rzędu, odsetek ten spadł do około 25%. Demonstracja, która zadziała raz, niewiele mówi o tym, jak system zachowa się przy tysięcznym uruchomieniu.

Gdzie zawodzą systemy wieloagentowe

Wiele zespołów łączy teraz kilku agentów: jeden planuje, drugi wykonuje zadania, a trzeci sprawdza rezultaty. W badaniu z 2025 roku przeprowadzonym na UC Berkeley, „Dlaczego systemy LLM z wieloma agentami zawodzą?”, przeanalizowano ponad 1600 opisanych śladów wykonania z siedmiu popularnych struktur wieloagentowych. Autorzy, pod kierownictwem Merta Cemriego, opracowali taksonomię o nazwie MAST, obejmującą 14 rodzajów błędów w trzech grupach: problemy z projektem systemu, brak zgodności między agentami oraz weryfikacja zadań.

Główny wniosek z badania jest taki, że wiele błędów wynika ze sposobu zaprojektowania systemu, a nie tylko z ograniczeń bazowego modelu. Agenci ignorują przypisaną im rolę, tracą wątek rozmowy albo uznają zadanie za zakończone, nie sprawdzając wyniku. Takie błędy nie pozostawiają po sobie komunikatu o błędzie. Można je dostrzec tylko wtedy, gdy ktoś jest w stanie sprawdzić, co faktycznie zrobił każdy agent. Omówienie przez Unite.AI paradoksu wieloagentowości wskazuje na powiązaną kwestię dotyczącą architektury: dodanie agentów może wzmocnić wczesny błąd zamiast go wyeliminować.

Jak ujawnić to, co niewidoczne

Odpowiedź inżynierów czerpie z systemów rozproszonych, w których od dawna śledzi się żądania przechodzące przez wiele usług za pomocą techniki zwanej śledzeniem przebiegu. W przypadku agentów każde żądanie użytkownika staje się śladem, a każde wywołanie modelu lub narzędzia — zawartym w nim „spanem”. Span rejestruje dane wejściowe, dane wyjściowe, użyte tokeny oraz czas wykonania. Organizacja OpenTelemetry, która opracowuje standardy branżowe w tej dziedzinie, przygotowuje wspólne konwencje dotyczące spanów dla generatywnej AI. W 2026 roku konwencje te wciąż mają status „w trakcie opracowywania”, więc nazwy atrybutów mogą się jeszcze zmienić.

Kilka projektów open source, takich jak Langfuse, Arize Phoenix i AcruxCore, już wykorzystuje tę koncepcję. Ich kod źródłowy jest publicznie dostępny, dzięki czemu zespoły mogą sprawdzić, jak przechowywany jest ślad, i uruchomić oprogramowanie na własnych serwerach. Projekty te rejestrują wywołania modeli i narzędzi jako spany w ramach jednego śladu oraz pozwalają zespołom przypisywać im oceny jakości. Wybór narzędzia ma mniejsze znaczenie niż jeden szczegół: span narzędzia musi rejestrować to, co narzędzie faktycznie zwróciło, a nie tylko informację, czy żądanie sieciowe zakończyło się powodzeniem. Bez tego opisana wcześniej awaria narzędzia pogodowego pozostaje niewidoczna.

Badania branżowe wskazują, że śledzenie przebiegu jest już powszechne, ale testowanie pozostaje w tyle. W badaniu przeprowadzonym pod koniec 2025 roku na potrzeby raportu LangChain „State of Agent Engineering” wzięło udział 1 340 specjalistów. Jakość była najczęściej wskazywaną przeszkodą we wdrażaniu agentów do środowiska produkcyjnego — wymieniło ją 32% respondentów. 89% organizacji zadeklarowało stosowanie jakiejś formy obserwowalności swoich agentów, a 62% prowadziło szczegółowe śledzenie poszczególnych kroków i wywołań narzędzi. Tylko 52,4% przeprowadzało ewaluacje offline na zbiorach testowych, a 37,3% oceniało ruch na żywo. Większość zespołów widzi, co zrobiły ich agenty. Mniej zespołów sprawdza, czy zrobiły to poprawnie.

Ocenianie odpowiedzi na dużą skalę

Ślady pokazują, co się wydarzyło. Nie mówią jednak, czy odpowiedź była dobra. Ręczne czytanie każdej rozmowy nie sprawdza się na dużą skalę, dlatego zespoły coraz częściej wykorzystują drugi model do oceniania odpowiedzi. Podejście to określa się jako LLM-as-a-judge. W artykule opublikowanym na konferencji NeurIPS 2023 Lianmin Zheng i jego współpracownicy wykazali, że silne modele, takie jak GPT-4, zgadzały się z ludzkimi preferencjami w ponad 80% przypadków — mniej więcej tak często, jak ludzie zgadzają się ze sobą nawzajem.

W tym samym artykule opisano słabe strony tej metody. Modele oceniające preferują odpowiedź pokazaną jako pierwsza, dłuższe odpowiedzi, a także tekst napisany przez siebie. Oceny modeli oceniających są zatem szacunkowe. Przydają się przy dużej liczbie przykładów, ale trzeba je weryfikować na niewielkim zbiorze przykładów ocenionych przez ludzi, losowo zmieniając kolejność odpowiedzi.

Od praktyki do polityki

Takie pomiary stają się również oczekiwanym elementem zarządzania. Amerykańska instytucja National Institute of Standards and Technology opublikowała swój AI Risk Management Framework w styczniu 2023 roku. Jedna z czterech podstawowych funkcji tego dokumentu, „Measure” („Mierz”), wymaga od organizacji ilościowego określania ryzyka związanego z AI, śledzenia go i dokumentowania w czasie. W przypadku agenta ślady i wyniki ewaluacji stanowią dowody, których wymaga ta funkcja.

Co zespoły mogą zrobić już teraz

Nawiązuje to do tezy przedstawionej na tej platformie, że prawdziwym sprawdzianem agentowej AI jest niezawodność. Przytoczone badania uzupełniają tę tezę o szczegóły dotyczące pomiaru: niezawodność nie jest właściwością, którą obserwuje się tylko raz — to zakres, który trzeba stale mierzyć.

Badania wskazują na kilka prostych dobrych praktyk, z których wiele zalecają również najwięksi dostawcy modeli. Praktyczny przewodnik OpenAI po tworzeniu agentów zaleca zespołom, by przed optymalizacją „przygotowały ewaluacje w celu ustalenia poziomu bazowego wydajności” oraz przekazywały kontrolę człowiekowi, gdy agent przekroczy ustaloną liczbę nieudanych prób lub stanie przed działaniem obarczonym wysokim ryzykiem. Anthropic zaleca „szeroko zakrojone testy w środowiskach izolowanych” przed zezwoleniem agentom na samodzielne działanie.

W praktyce oznacza to kilka konkretnych kroków. Wersjonuj prompty i opisy narzędzi tak jak kod. Testuj każdą zmianę promptu na stałym zbiorze danych i spodziewaj się zakresu wyników, a nie jednej liczby. Uruchamiaj każdy przypadek testowy kilkakrotnie, bo pojedyncza próba ukrywa niespójność. Zapisuj wyniki narzędzi w śladach, aby awaria narzędzia nie mogła ukryć się za kodem powodzenia. Traktuj automatyczne oceny modeli jako szacunki i weryfikuj je z udziałem ludzi.

Żadna z tych praktyk nie wymaga przełomu w możliwościach modeli. Wymagają one traktowania agenta AI zgodnie z tym, czym jest: systemem probabilistycznym, który trzeba mierzyć, ponieważ rzadko sam zasygnalizuje własne błędy.