Agent AI zawiódł po pięciu krokach? Jeden trace pokaże miejsce awarii

Aby monitorować agenta AI, przypisz całemu zadaniu jeden ślad wykonania, a wywołania modelu, narzędzi i pamięci zapisuj jako osobne spany. Jeśli agent zawiedzie po pięciu krokach — to umowny przykład, nie opis incydentu — opis śladów OpenTelemetry wskazuje dane o wywołaniach modelu, takie jak czas, zużycie tokenów i błędy, które pomagają znaleźć podejrzany etap.

Do śladu dodaj wynik całego zadania: wykonane, niewykonane albo wymagające weryfikacji. Sam brak błędu API nie oznacza, że agent osiągnął cel. Zestawienie wyniku z kolejnymi operacjami pozwala odróżnić awarię techniczną od odpowiedzi, która dotarła do użytkownika, lecz nie spełniła warunku zadania.

Utwórz jeden ślad dla całego zadania

Span główny powinien zaczynać się przy przyjęciu zadania i kończyć po zapisaniu rezultatu. Nadaj mu identyfikator zadania, nazwę procesu, wersję konfiguracji agenta, czas rozpoczęcia i zakończenia oraz status wyniku. Ten sam kontekst śladu przenoś do operacji asynchronicznych, aby odpowiedź narzędzia pozostała częścią właściwego przebiegu.

Wewnątrz twórz spany potomne dla rzeczywistych operacji. Konwencje semantyczne OpenTelemetry określają wspólne nazwy operacji i atrybutów dla śladów, metryk, logów, profili oraz zasobów. Używaj odpowiedniego pola standardowego tam, gdzie istnieje; własny cel biznesowy agenta i kryterium ukończenia zadania opisz w udokumentowanych polach aplikacji.

Umowny schemat śladu może wyglądać tak:

1. Span główny „obsłuż zadanie” obejmuje cały przebieg i zapisuje końcowy wynik.
2. Span „odczytaj pamięć” zapisuje źródło kontekstu, identyfikatory znalezionych elementów i rezultat odczytu.
3. Span „wywołaj model” zapisuje model, czas odpowiedzi, zużycie tokenów i status wywołania.
4. Span „uruchom narzędzie” zapisuje nazwę narzędzia, wynik, opóźnienie i ewentualną ponowną próbę.
5. Span „oceń rezultat” zapisuje, czy warunek zakończenia został spełniony i jaki stan zadania pozostał po decyzji.

To przykład struktury, a nie wymagana kolejność działania. Każde ponowne wywołanie modelu lub narzędzia powinno mieć własny span powiązany z tym samym zadaniem. W przeciwnym razie ponowne próby ukryją część czasu i zużycia zasobów, a ostatnia odpowiedź może wyglądać na jedyną wykonaną operację.

Zapisuj dane, które wyjaśniają decyzję agenta

Sam czas wywołań nie wyjaśni, dlaczego agent zakończył pracę z błędnym wynikiem. Autorzy pracy AgentTrace proponują powiązanie logów operacyjnych, poznawczych i kontekstowych podczas działania agenta. Poniższy zestaw pól jest praktyczną propozycją wdrożeniową, a nie gotowym schematem z tej pracy.

• Model: nazwa i wersja modelu, identyfikator wywołania, parametry potrzebne do diagnozy, tokeny wejścia i wyjścia, czas, status, typ błędu oraz informacja, czy odpowiedź zażądała użycia narzędzia.
• Narzędzie: nazwa i wersja operacji, identyfikator wywołania, status odpowiedzi, czas, liczba prób oraz bezpieczny kod wyniku, na przykład „brak rekordu” albo „odmowa dostępu”.
• Pamięć lub wyszukiwanie: nazwa źródła, wersja indeksu albo zbioru, identyfikatory zwróconych elementów, czas odczytu i informacja, czy pobrany kontekst został użyty.
• Decyzja o zakończeniu: powód zatrzymania, spełniony lub niespełniony warunek zadania, zmiana stanu, status zatwierdzenia przez człowieka, jeśli jest wymagane, oraz identyfikator rezultatu w systemie docelowym.

Rozdziel status operacji, decyzję agenta o zakończeniu i potwierdzenie rezultatu. Poprawna odpowiedź narzędzia może zawierać pusty wynik: wywołanie się udało, ale zadanie mogło pozostać niewykonane. Jeśli agent zapisał zmianę w innym systemie, odnotuj identyfikator tej zmiany lub potwierdzenie zapisu. Dzięki temu można ustalić, czy problem pojawił się przy pobraniu danych, w decyzji agenta, czy dopiero przy wykonaniu działania.

Ogranicz zapis treści promptów

Prompt, odpowiedź modelu i argumenty narzędzia mogą zawierać dane użytkownika albo poufne informacje pobrane z pamięci. Domyślnie zapisuj metadane: wersję szablonu promptu, typ zadania, rozmiar wejścia, identyfikatory użytych zasobów oraz kody wyniku. Pełną treść przechowuj tylko wtedy, gdy jest potrzebna do diagnozy, z ograniczonym dostępem i określonym czasem przechowywania.

Maskowanie wykonuj przed wysłaniem telemetrii do odbiorcy. Dla każdej operacji ustal dozwolone pola; z argumentów narzędzi usuń sekrety, dane identyfikujące użytkownika i fragmenty dokumentów zbędne do ustalenia przebiegu. Ukrycie treści wyłącznie w widoku śladu nie ochroni jej, jeśli niezamaskowana kopia trafiła już do eksportu lub logów pomocniczych.

Jeżeli konkretny prompt jest konieczny do odtworzenia błędu, w śladzie można zachować bezpieczny identyfikator kontrolowanego zapisu. Uprawniona osoba powiąże wtedy treść z przebiegiem zadania, a rutynowy dostęp do śladów nie będzie oznaczał dostępu do pełnych rozmów. Tę samą zasadę zastosuj do odpowiedzi narzędzi i elementów pamięci, bo w nich również może znaleźć się poufny kontekst.

Mierz koszt, opóźnienie, błędy i nieudane wyniki

Metryki agreguj osobno od szczegółowych śladów. Dla kosztu sumuj zużycie tokenów i koszt obliczony według cennika używanego modelu, uwzględniając ponowne próby. Dla opóźnienia obserwuj zarówno czas całego zadania, jak i czas poszczególnych operacji. Bez tego długie oczekiwanie na narzędzie łatwo przypisać modelowi.

Utrzymuj oddzielne liczniki błędów wywołań i nieudanych rezultatów zadania. Pierwszy obejmuje odmowy, limity, przekroczenia czasu i wyjątki. Drugi wymaga kryterium ukończenia, na przykład potwierdzenia zapisu w systemie docelowym albo oceny przez człowieka. Wynik nieoceniony oznaczaj osobno, zamiast automatycznie zaliczać go do sukcesów.

Alerty ustaw względem własnych limitów czasu i budżetu oraz oczekiwanego udziału ukończonych zadań. Przydatne są osobne powiadomienia o wzroście błędów konkretnego narzędzia, przekroczeniu kosztu zadania, wydłużeniu całego przebiegu i spadku liczby potwierdzonych rezultatów. Wymiary metryk ogranicz do pól takich jak typ zadania, model i narzędzie; identyfikator pojedynczego zadania zachowaj w śladzie.

Po uruchomieniu alertu ślad pozwala przejść od wyniku zadania do pierwszej operacji z błędem, pustymi danymi albo nieoczekiwaną zmianą stanu. To wskazuje miejsce, od którego warto rozpocząć diagnozę. Przyczynę ustalisz, zestawiając ten etap z warunkiem zadania, odpowiedzią narzędzia i decyzją agenta; sam znacznik błędu nie zawsze wyjaśnia, dlaczego rezultat okazał się nieudany.

Przeczytaj także:

• ChatGPT dla nastolatków zawiódł w 4 tys. prób — alerty nie zawsze działają
• Kontrahent wygląda wiarygodnie? Pięć rejestrów pokaże ryzyko
• Sprawdzasz tylko KRS? Pięć rejestrów pokaże większe ryzyko kontrahenta