Per què el teu agent d'IA necessita observabilitat abans que falli en producció
Has estat revisant els resultats del teu agent durant tres setmanes. Cada tiquet que tanca es llegeix bé: llenguatge clar, to adequat, una resposta plausible. Aproves el patró i passes al següent incendi. Llavors, un client envia una captura de pantalla: l'agent va citar una política de devolucions que va expirar fa vuit mesos. Havia estat extraient informació d'un document obsolet tot el temps, i totes les respostes intermèdies semblaven tan segures com les correctes.
Això no és estrany. El 57% de les organitzacions reporten tenir agents d'IA en producció, i en aquest grup, la qualitat, no el cost, s'ha convertit en la barrera principal per escalar. La resposta final que et dona l'agent és la part menys diagnòstica del seu resultat. El que realment et diu si el sistema funciona és si pots reconstruir com hi va arribar.
Quan "funciona" no és un diagnòstic
L'observabilitat de programari clàssica respon a una pregunta limitada: es va executar el sistema? Els registres, les mètriques i els panells de latència et diuen si una sol·licitud es va completar, quant va trigar i si alguna cosa va llançar una excepció. Això és suficient quan la lògica és determinista: la mateixa entrada produeix la mateixa sortida, en tot moment.
Els agents trenquen aquesta suposició. La mateixa entrada pot encaminar-se de manera diferent, recuperar un context diferent i generar una resposta diferent segons la variació del model, la disponibilitat d'eines o un índex de recuperació que va canviar fa una hora. L'observabilitat de l'agent ha de respondre a una pregunta més difícil: no només si es va executar, sinó què va decidir i per què.
El vocabulari que ha sorgit al voltant d'això (en gran part a través d'eines com Langfuse) proporciona un model mental útil. Una traça (trace) és el registre complet d'una execució d'agent de principi a fi. A dins, les observacions són els passos individuals: una crida d'eina, una recuperació, una generació LLM. Cada observació pot tenir una puntuació: un número o etiqueta assignat per humà o model que diu si aquell pas específic va ser bo.
Els quatre llocs on un agent realment es trenca
Un error comú: els equips assumeixen que un agent que falla s'anunciarà a si mateix: una excepció llançada, un estat 500, alguna cosa visible als registres. La majoria dels errors d'agents no ho fan. L'agent tria la branca equivocada, recupera el document equivocat o generalitza més enllà del que les proves recolzen, i tot i així retorna una resposta ben formada i segura amb un 200.
4.1 Encaminament: l'agent tria la branca equivocada
Qualsevol agent amb més d'una ruta pren una decisió d'encaminament en el seu nucli, generalment un LLM que classifica la intenció de la consulta. Quan aquesta classificació és incorrecta, tot el que ve després pot ser tècnicament correcte i igualment inútil.
Senyal: la resposta està ben formada però aborda una pregunta adjacent a la formulada.
Pregunta diagnòstica: de les teves últimes deu decisions d'encaminament, la branca seleccionada coincideix amb la que un humà hauria triat només amb la consulta?
4.2 Recuperació: branca correcta, evidència incorrecta
L'encaminament encerta, però el pas de recuperació extreu fragments que són obsolets, estan fora de tema o són merament similars en la redacció però no en el significat.
Senyal: la resposta sembla específica, però els detalls no es sostenen sota una verificació de la font.
Pregunta diagnòstica: extreu els 3 fragments recuperats darrere d'una resposta recent — els hauries triat tu, donada la consulta?
4.3 Generació: evidència correcta, ignorada
La recuperació va fer el seu treball. El context correcte estava al prompt. El model va generar una resposta que el va ignorar a favor del seu propi coneixement paramètric.
Senyal: la resposta és més àmplia o segura del que justifica el context recuperat.
Pregunta diagnòstica: per a una resposta mostrejada, cada afirmació es remunta a una línia específica del context recuperat — o el model va afegir alguna cosa?
4.4 Cost i Latència: resposta correcta, economia incorrecta
La fallada més difícil de notar, perquè res sembla trencat — la resposta és precisa. Però l'agent va prendre sis crides a eines i 40 segons per produir-la.
Senyal: la correcció es manté, però el cost per resolució o la latència augmenta a mesura que creix el volum.
Pregunta diagnòstica: per a la teva consulta mediana, quants nodes toca la traça — i aquest número està pujant o baixant mes a mes?
Full de referència: símptoma → traça
Si vols els quatre modes de fallada comprimits en alguna cosa que puguis capturar i fixar damunt del teu escriptori:
| Símptoma | Causa probable | On buscar a la traça |
|---|---|---|
| L'agent respon a una pregunta que ningú va fer | L'encaminament va enviar la consulta a la branca o eina equivocada | Node d'encaminament — comparar branca seleccionada vs. branca esperada |
| La resposta cita el document o política incorrecta | La recuperació va retornar context obsolet o irrellevant | Span de recuperació — revisar chunks top-k i les seves puntuacions de rellevància |
| Fonts correctes recuperades, però la resposta les ignora | La generació va subponderar el context i va recórrer al coneixement paramètric | Span de generació — comparar finestra de context amb la sortida final |
| La resposta és segura però factualment incorrecta | Context parcial recuperat, el model va generalitzar massa | Span de generació — revisar completitud del context en generar |
| L'agent pren 5+ passos per fer el que hauria de prendre 1 | Bucle d'encaminament o condicions de bifurcació poc clares | Recompte de transicions de nodes — buscar visites repetides al mateix node |
| La resposta triga més de 8 segons | Un node lent, no tota la cadena | Durades de spans — aïllar el node individual més lent |
| Pic de cost en una consulta rutinària | Tier de model incorrecte seleccionat, o sense caché en crides repetides | Recompte de tokens i selecció de model per span de generació |
| L'agent va bé en evals, falla en producció | Les traces d'eval no reflecteixen patrons de tràfic real | Comparar formes de traces de producció contra el teu dataset d'eval |
Com es veu això fora de la pissarra
AlamedaDev va construir una versió d'aquest problema per a un centre de trucades als EUA que gestiona interaccions amb clients d'empreses multinacionals. El punt de partida: milers de trucades al dia, revisades manualment contra requisits estrictes de compliment — divulgacions obligatòries, llenguatge de consentiment, salutacions correctes — sense forma d'escalar el procés de revisió.
El sistema que vam construir no només puntua una trucada com a conforme o no — exposa el perquè. Un model de veu a text afinat transcriu cada trucada amb més del 95% de precisió, i un model de puntuació supervisat avalua cadascuna contra senyals específiques: salutacions, consentiment, divulgacions, to i resolució.
És el mateix principi que rastrejar un agent, aplicat a un pipeline de puntuació en lloc d'una cadena de LLM: la sortida d'alt nivell és la part menys útil del sistema per si sola. El que el va fer utilitzable va ser la capacitat de retrocedir des d'una puntuació fins a l'evidència específica darrere d'ella.
Per a equips que avaluen eines en lloc de construir des de zero: LangSmith és l'estàndard pràctic si ja esteu a LangChain o LangGraph. Braintrust lidera en fluxos d'avaluació. Nous participants com Laminar aposten per instrumentació nativa d'OpenTelemetry construïda específicament per a agents.
Dos errors que desfan tot això
Error 1: tractar "la resposta sona bé" com la prova d'acceptació. És l'error més fàcil de cometre perquè és ràpid — llegir una sortida i assentir pren deu segons; rastrejar la ruta d'execució pren deu minuts. El cost real apareix setmanes després, quan alguna cosa es trenca en producció i ningú té l'historial de traces.
Error 2 (el contrapès): instrumentar-ho tot sense convenció de metadades. Els equips cremats per l'error 1 de vegades sobrecorregeixen — connecten el rastreig en cada crida de funció, sense etiquetat consistent per a ID de sessió, versió de l'agent o segment d'usuari.
La veritable pregunta no és "funciona?" És "pots mostrar-me per què va funcionar, en aquesta trucada específica, per a aquest usuari específic, ara mateix?" Si la resposta triga més que obrir una traça, no tens observabilitat.
Primers passos
Si ja tens un agent en producció:
Instrumenta primer els nodes de major risc — decisions d'encaminament i crides de recuperació, no cada funció de la cadena.
Defineix 3–4 puntuacions mínimes abans d'afegir-ne més: èxit de la tasca, rellevància de la recuperació, llindar de latència, cost per resolució.
Fixa la teva convenció de metadades ara — ID de sessió, versió de l'agent, segment d'usuari — abans que creixi el volum de traces.
Alerta per llindars de puntuació, no només per registres d'error. Els errors silenciosos mai llancen una excepció.
Si encara estàs decidint si ho necessites:
Cronometra't. Tria una interacció passada real i mesura quant trigues a explicar per què l'agent va respondre com ho va fer.
Compta les teves re-execucions manuals. Si el moviment per defecte del teu equip per depurar és reexecutar la consulta a mà en lloc de treure una traça, aquesta és la bretxa que això tanca.
Pregunta què està cobrint "generalment funciona". Aquesta frase significa que algú, en algun lloc, no pot assenyalar l'error.
Conclusió
La resposta final mai va ser la unitat de confiança — la ruta d'execució ho és. Un agent que obté la resposta correcta per la raó equivocada eventualment obtindrà la resposta incorrecta amb la mateixa confiança, i sense una traça, no ho veuràs venir fins que ho faci un client.
Si estàs enviant un agent a producció i encara no pots respondre "per què va fer això" per a una interacció específica, estarem encantats de tenir aquesta conversa. Sense pitch — només una trucada de 30 minuts amb un dels nostres enginyers.
Construïm junts
Unim experiència i innovació per portar el teu projecte al següent nivell.