BlogAgenci AI

Sygnały, że agent na produkcji drożeje albo działa gorzej

Licz wszystko na obsłużoną sprawę, a nie na wywołanie modelu: ile kosztowała sprawa, czy zakończyła się bez człowieka, dlaczego została eskalowana i czy kontrola uznała ją za poprawną. Rozbijaj te liczby według typu sprawy i wersji agenta i ustal z góry, od jakiego poziomu podejmujesz działanie. Telemetria kondycji przebiegu, czyli błędy, opóźnienia i tokeny, nie zobaczy sprawy obsłużonej źle bez żadnego błędu. Kontrole wyniku emitowane jako telemetria zobaczą ją dla typów spraw, które obejmują, a resztę pokrywa próbka sprawdzana przez ludzi.

Zaktualizowano

Jednostką jest sprawa, a nie wywołanie

Jedna sprawa może obejmować kilka przebiegów, dziesiątki wywołań modelu, pauzę na akceptację i kilka minut pracy urzędnika. Koszt tokenów na wywołanie sam w sobie niewiele mówi. Koszt na obsłużoną sprawę, wliczając czas przeglądu i poprawki, to liczba, którą właściciel procesu może porównać z dzisiejszym kosztem pracy ręcznej.

Wymaga to identyfikatora sprawy w każdym spanie i każdej linii logu. Konwencje semantyczne OpenTelemetry dla spanów agentów definiują atrybuty takie jak gen_ai.conversation.id, gen_ai.agent.version oraz liczniki tokenów gen_ai.usage.input_tokens i gen_ai.usage.output_tokens. Konwencje mają wciąż status Development, więc przypnij wdrażaną wersję i dodaj własny atrybut z identyfikatorem sprawy, jeśli rozmowa nie odpowiada sprawie jeden do jednego.

Arkusz sygnałów dla jednego agenta procesowego

To lista startowa dla hipotetycznego agenta fakturowego. Każdą pozycję rozbija się według typu sprawy i wersji agenta.

Sygnały dotyczące wyniku

  • Odsetek spraw zakończonych bez człowieka
  • Odsetek spraw eskalowanych, według powodu eskalacji
  • Odsetek błędów w przeglądzie próbki zakończonych spraw przez ludzi
  • Późniejsze korekty, na przykład księgowania później stornowane

Sygnały dotyczące kosztów

  • Koszt na obsłużoną sprawę, z osobno pokazanym kosztem modelu, platformy i przeglądu
  • Wywołania modelu, wywołania narzędzi i tokeny na sprawę, jako percentyle

Sygnały dotyczące kondycji i dryfu

  • Błędy narzędzi według narzędzia i typu błędu oraz liczba spraw z nieznanym wynikiem zapisu
  • Czas od wpłynięcia do zakończenia oraz wiek najstarszej sprawy czekającej na człowieka
  • Rozkład typów przychodzących spraw w porównaniu z rozkładem, na którym testowano agenta

Uzgodnij progi, zanim będą potrzebne

SRE Workbook Google'a zaleca wyrażanie wskaźników poziomu usług jako stosunku dobrych zdarzeń do wszystkich, wybór niewielkiej ich liczby, pomiar możliwie blisko użytkownika i spisanie z góry, co się dzieje, gdy budżet błędów się wyczerpie. W przypadku agenta procesowego użytkownikiem jest proces, więc mierz w systemie źródłowym, a nie wewnątrz agenta.

Hipotetyczny cel: co najmniej 97 procent sprawdzonych w próbce, automatycznie zakończonych faktur jest poprawnych w kroczącym oknie czterech tygodni. Liczba to założenie dla ilustracji; właściciel procesu ustala ją na podstawie odsetka błędów obecnego procesu ręcznego. Powiązana zasada może mówić, że jeśli cel nie zostanie osiągnięty, dany typ spraw wraca do akceptacji, dopóki przyczyna nie zostanie usunięta.

Wychwytywanie pełzającego wzrostu kosztów

Koszt na sprawę rzadko skacze. Dryfuje, gdy dokumenty się wydłużają, agent wykonuje więcej wywołań narzędzi, rośnie liczba ponowień albo więcej spraw trafia do człowieka. Obserwuj percentyle zamiast średnich; rozdział o monitoringu w SRE Workbook zwraca uwagę, że średnie ukrywają wolne żądania, a to samo dotyczy drogich spraw. Ten sam rozdział zaleca rejestrowanie zamierzonych zmian, takich jak wersje i konfiguracja, żeby przesunięcia dało się powiązać z wdrożeniami. W przypadku agentów oznacza to wersje modelu, promptu i narzędzi przy każdej sprawie.

Jakość wymaga próbki, nie tylko dashboardu

Telemetria kondycji przebiegu pokazuje, że przebieg się zakończył, a nie że faktura trafiła na właściwe konto. Automatyczne kontrole wyniku w systemie źródłowym zamykają część tej luki, a ich wyniki można emitować jako metryki z własnymi alarmami. Dla typów spraw, których nie obejmują, utrzymuj niewielki, regularny przegląd zakończonych spraw przez ludzi. Przewodnik Anthropic po ewaluacji agentów opisuje monitoring produkcji jako przydatny, ale reaktywny, i zaleca łączenie go z automatycznymi ewaluacjami i ręcznym czytaniem transkryptów, żeby każda warstwa wyłapywała to, co pominą inne.

Co powinno kogoś alarmować

Alarmuj człowieka tylko przy stanach, na które może zareagować: narzędzie zawodzi dla całej kategorii spraw, jakakolwiek sprawa ma nieznany wynik zapisu, kolejka akceptacji jest starsza niż jej cel albo cel jest zagrożony. Powolny dryf kosztów należy do cotygodniowego przeglądu, a nie do alarmu. SRE Workbook zaleca też testowanie reguł alarmowych na danych syntetycznych, bo reguła, która nigdy się nie uruchamia, może być po prostu zepsuta. Praktyczny pierwszy krok: zaznacz w powyższym arkuszu sygnałów, które liczby potrafisz już dziś wyliczyć na sprawę, i zacznij od nich.

Pytania

Jaką platformę observability wybrać?

Wystarczy każda platforma, która potrafi grupować dane według twojego identyfikatora sprawy i wersji agenta i pozwala eksportować surowe rekordy. Te dwa wymagania są ważniejsze niż jakakolwiek lista funkcji dla agentów.

Czy przechowywać pełne prompty i odpowiedzi modelu?

Przydają się przy badaniu błędów, ale często zawierają dane osobowe. Konwencje OpenTelemetry traktują treść wiadomości i argumenty narzędzi jako opt-in. Ustal razem z inspektorem ochrony danych, co rejestrujesz, jak długo i kto może to czytać.

Porozmawiaj z inżynierem

Przyjdź z jednym zadaniem, które chcesz usprawnić. Rozmowa trwa 30 minut i nie wymaga dostępu do twoich systemów ani danych.

Rezerwacja odbywa się w Kalendarzu Google.

Wolisz najpierw napisać? Zostaw adres e-mail i kilka zdań, a odpowiemy, proponując terminy.

Przycisk przygotowuje e-mail w twoim własnym programie pocztowym, a wysyłasz go samodzielnie. Polityka prywatności (wersja robocza)