Mogućnost promatranja za AI agente: Što bilježiti, pratiti i alarmirati

Prvi put kada AI agent pogrešno obradi produkcijski zahtjev — odobri povrat koji je trebao eskalirati, halucinira politiku povrata proizvoda ili potroši 200 $ na tokene u jednoj sesiji — vaš tim shvati da dashboard koji su izgradili prikazuje samo količine tokena i percentile latencije. Nijedno ne govori što je agent zapravo napravio, zašto je to napravio ili hoće li sljedeće izvođenje ponoviti istu pogrešku.

Mogućnost promatranja za AI agente nije APM s LLM oznakom. Agenti uvode tragove odluka koji se granaju, pozive alata koji uspijevaju ili ne uspijevaju asinkrono i kvalitetu izlaza koja se ne može svesti na statusni kod. Ovaj post definira površine bilježenja, praćenja i alarmiranja koje odvajaju upravljivu implementaciju agenta od one gdje svaki incident počinje s “nemamo pojma što se dogodilo.”

ID-ovi izvođenja i propagacija traga

Svako pokretanje agenta treba jedinstveni ID izvođenja koji se propagira kroz svaki pod-poziv koji agent napravi — inferenciju modela, izvršenje alata, upit vektorske baze i ljudsku predaju. Bez stabilnog korijena traga, povezivanje korisničke pritužbe s određenim slijedom odluka agenta postaje ručno pogađanje.

Što bilježiti. ID izvođenja sjedi u strukturiranoj omotnici loga uz hash verzije agenta, okidački događaj ili korisnički unos i ID roditeljskog traga ako je ovo pokretanje pokrenuo drugi agent. Svaki nizvodni poziv nasljeđuje ID izvođenja kao baggage zaglavlje ili ključ konteksta. Log unos za poziv alata uključuje njegov ID izvođenja, naziv alata, proslijeđene argumente, neobrađenu povratnu vrijednost, latenciju u milisekundama i status poziva (uspjeh, neuspjeh, timeout ili odbacivanje filtera sadržaja).

Zašto vam ovo treba. Korisnička prijava “AI mi je dao pogrešne informacije” bez propagacije traga zahtijeva pregled svake log datoteke iz prozora incidenta i pogađanje koji pozivi pripadaju kojoj sesiji. S propagacijom traga, filtrirate po ID-u izvođenja i rekonstruirate točan slijed poziva modela, poziva alata i međustanja koji su proizveli pogrešan izlaz.

Proračuni latencije poziva alata

Pozivi alata su mjesto gdje AI agenti najčešće pucaju u produkciji. Poziv modela koji traje dvije sekunde je prihvatljiv; poziv alata koji traje trideset sekundi jer je uzvodni API spor uzrokuje zastoj agenta, korisnik ponovno učita stranicu i model pokušava logiku povratka koja može proizvesti gori ishod.

Što bilježiti po pozivu alata. Zabilježite latenciju na zidu, vrijeme-do-prvog-bajta od nizvodne usluge i broj pokušaja ponavljanja prije uspjeha ili neuspjeha. Zabilježite puni payload argumenata i punu povratnu vrijednost (ili skraćeni prikaz kada povrat prelazi 4 KB) tako da možete ponoviti odluku izvan linije. Označite svaki poziv alata s modelovim finish_reason — poziv alata pokrenut jer je model odlučio koristiti ga izgleda drugačije od onoga pokrenutog jer je model bio prisiljen u način korištenja alata od strane aplikacijskog sloja.

Što alarmirati. Postavite P2 alarm kada bilo koji poziv alata premaši 2× svoj p95 latencije kroz prozor od 5 minuta. Postavite P1 kada stopa uspješnosti poziva alata padne ispod 95 % za bilo koji pojedinačni alat u kliznom prozoru od 10 minuta. Alat koji uspijeva 99 % vremena na p50 = 300 ms, ali ima 90. percentilni rep od 12 sekundi je prijetnja pouzdanosti — korisnici koji pogode dugi rep vide zamrznuto korisničko sučelje i agent može timeoutirati vlastitu petlju razmišljanja.

Signali detekcije halucinacija

Otkrivanje haluciniranog izlaza u produkciji bez da čovjek čita svaki odgovor je najteži problem mogućnosti promatranja s kojim se AI agenti suočavaju. Ne možete bilježiti “halucinirano = true” — halucinacija je prosudba, ne očitanje senzora. Ali možete bilježiti signale koji koreliraju s rizikom halucinacije i alarmirati kada rizik prijeđe prag.

Što bilježiti. Modelove izlazne logprobe za svaki token u odgovoru — konkretno vjerojatnost najboljeg tokena i jaz vjerojatnosti između dva najbolja tokena. Sužavanje jaza između najvjerojatnijeg i drugog najvjerojatnijeg tokena korelira s činjeničnom nesigurnošću u nekim obiteljima modela. Zabilježite ocjene pouzdanosti iz bilo kojeg vanjskog klasifikatora činjeničnosti ili provjere dosljednosti koju pokrećete: ocjenu samodosljednosti (uzorkovanje istog predloška N puta i mjerenje slaganja odgovora), ocjenu utemeljenosti u dohvaćenom (koji udio tvrdnji u izlazu ima potporni izvor u dohvaćenom kontekstu) i zastavicu kontradikcije (izlaz je u suprotnosti s poznatim činjenicama iz baze znanja).

Što alarmirati. Odgovor s prosječnom logprobom najboljeg tokena ispod −0.5 i ocjenom samodosljednosti ispod 0.6 kroz N=3 uzorka trebao bi pokrenuti automatsku eskalaciju ljudskom pregledu. Zabilježite latentni razlog: “niska samodosljednost (0.5), niska logprob (−0.8), nema potpornog konteksta dohvaćanja za 23 % tvrdnji.” Poruka eskalacije uključuje ID izvođenja, označeni odgovor i očitanja senzora tako da preglednik može donijeti informiranu odluku bez kopanja kroz sirove logove.

Praćenje troška po izvođenju

Dashboardi količine tokena govore vam agregatnu potrošnju, ali skrivaju distribuciju troška po sesiji i korisniku. Jedna korisnička sesija koja pet puta prođe kroz neuspješan poziv alata prije uspjeha može koštati 10× medijan sesije — i bez atribucije troška po izvođenju, tiho plaćate tu neučinkovitost.

Što bilježiti. Za svako dovršeno izvođenje, zabilježite ukupne tokene predloška, ukupne tokene dovršetka, tokene potrošene od strane svakog poziva modela, tokene potrošene na reintegraciju rezultata poziva alata i izračunati trošak na temelju cijena po razinama vašeg pružatelja. Označite izvođenje s korisnikom koji je pokrenuo, kontekstom značajke (chat, sažimanje, klasifikacija) i verzijom agenta.

Što alarmirati. Izvođenje čiji trošak premašuje 5× p90 trošak za svoju kategoriju značajke treba pokrenuti alarm za anomaliju troška. Uključite ID izvođenja i detalj koji je stupanj potrošio najviše tokena. Obrazac gdje korisnici u određenoj skupini ili koji koriste određenu značajku dosljedno premašuju prag anomalije ukazuje na problem inženjeringa predloška ili dizajna agenta koji nikakvo ograničavanje neće popraviti.

Logovi eskalacije ljudskom pregledu

Eskalacije agenta čovjeku — bilo da ih pokreće izlaz niske pouzdanosti, osjetljiva akcija (financijska transakcija, brisanje računa) ili korisnik koji izričito traži čovjeka — sam događaj eskalacije mora biti potpuno revizijski.

Što bilježiti. Okidač eskalacije (koji senzor ili pravilo se aktiviralo), punu povijest razgovora do točke eskalacije, predloženu akciju ili odgovor agenta, odluku ljudskog preglednika (odobri, odbij, izmijeni) i ishod nakon eskalacije. Svaka eskalacija dobiva vlastiti ID eskalacije povezan s ID-om roditeljskog izvođenja.

Što alarmirati. Ljudski preglednik koji odbija više od 20 % eskalacija iz određene verzije agenta ili značajke sugerira da agent ili previše agresivno eskalira (gubi ljudsko vrijeme) ili proizvodi izlaze koje preglednik dosljedno poništava (ukazuje na jaz u kvaliteti). Alerirajte na taj omjer po verziji agenta i pokrenite pregled predloška ili modela.

Okvir za odlučivanje: Vaš prvi prolaz mogućnosti promatranja

Ako krećete od nule, implementirajte ovih pet točaka instrumentacije redom:

Prioritet	Instrumentacija	Vrijeme implementacije	Prvi signal koji dobivate
1	ID izvođenja + propagacija traga	1–2 dana	Možete ponoviti bilo koju korisničku sesiju
2	Bilježenje latencije poziva alata	1 dan	Vidite koji alati ne uspijevaju i zašto
3	Atribucija troška po izvođenju	2–3 dana	Vidite koji korisnici i značajke najviše koštaju
4	Revizijski log ljudske eskalacije	1 dan	Mjerite točnost pregleda i obrasce odbijanja
5	Senzori rizika halucinacije	3–5 dana	Hvatate dio haluciniranih izlaza prije korisnika

Prioritet 1 i 2 zajedno eliminiraju klasu incidenata “nemamo pojma što se dogodilo.” Prioritet 3 sprječava iznenađenje na mjesečnom računu. Prioritet 4 i 5 grade prema samopoboljšavajućem agentskom sustavu gdje eskalacije proizvode označene podatke za obuku, a alarmi halucinacije otkrivaju rizik prije nego ga korisnik prijavi.

Početak rada: Predložak dashboarda za nadzor

Evo Python predloška koji možete prilagoditi svom nadzornom stogu. Hvata osnovne metrike koje ovaj post pokriva — ID-ove izvođenja, latenciju alata, atribuciju troška i okidače eskalacije — u strukturi koju Grafana, Datadog ili vaš prilagođeni dashboard mogu konzumirati.

import json
import time
import uuid
from dataclasses import dataclass, field, asdict
from typing import Optional

@dataclass
class AgentRunMetrics:
    run_id: str = field(default_factory=lambda: str(uuid.uuid4()))
    agent_version: str = ""
    user_id: str = ""
    feature: str = ""
    prompt_tokens: int = 0
    completion_tokens: int = 0
    tool_calls: list = field(default_factory=list)
    escalation: Optional[dict] = None
    start_time: float = field(default_factory=time.time)
    end_time: Optional[float] = None

    def log_tool_call(self, name: str, args: dict, result: str,
                      duration_ms: float, status: str):
        self.tool_calls.append({
            "name": name,
            "args_truncated": json.dumps(args)[:200],
            "result_truncated": result[:200],
            "duration_ms": round(duration_ms, 1),
            "status": status,
        })

    def log_escalation(self, trigger: str, reason: str,
                       conversation_excerpt: str):
        self.escalation = {
            "trigger": trigger,
            "reason": reason,
            "conversation_excerpt": conversation_excerpt[:500],
        }

    def finish(self):
        self.end_time = time.time()
        return asdict(self)

## Upotreba u vašem AI gateway middlewareu:
metrics = AgentRunMetrics(
    agent_version="v2.3.1",
    user_id="user_abc123",
    feature="customer_support"
)
## ... nakon svakog poziva alata:
metrics.log_tool_call("search_kb", {"query": "refund policy"},
                      "results: ...", 340, "success")
## ... po završetku:
output = metrics.finish()
## Pošaljite u svoj pipeline metrika:
print(json.dumps(output))

Kopirajte ovaj predložak, uključite ga u svoj AI gateway middleware i imate mogućnost promatranja na razini izvođenja unutar sat vremena. JSON izlaz izravno se hrani u pipeline agregacije logova — parsirajte ga u svoj pozadinski sustav metrika i izgradite dashboarde odatle.

Zaključak

Mogućnost promatranja za AI agente nije dodatak nadzoru — to je infrastruktura koja čini ponašanje agenta revizijskim, otklonjivim i poboljšivim. Instrumentirajte pet gornjih površina (propagacija traga, latencija alata, rizik halucinacije, atribucija troška, ljudska eskalacija), postavite alarme na pragove i prvo pitanje vašeg tima nakon incidenta pomaknut će se s “što se dogodilo” na “što prvo popravljamo.”

Započnite s predloškom dashboarda za nadzor iznad — treba sat vremena za uključivanje i daje vam mogućnost promatranja na razini izvođenja od prvog dana.