Els agents converteixen l’observabilitat en un requisit empresarial
Els equips de programari ja entenen per què importa l’observabilitat. Registres, mètriques, traces, alertes i fluxos d’incidents ajuden a saber si un sistema està saludable i per què alguna cosa ha canviat. Els agents d’IA hereten aquesta necessitat, però afegeixen un problema més complex: el sistema ja no és només programari determinista.
Un agent pot rebre la mateixa sol·licitud dues vegades i produir sortides diferents. Pot recuperar context diferent, cridar una eina distinta, seguir un pla alternatiu o parar abans del que s’esperava. Una resposta tècnicament exitosa pot ser, encara així, errònia, incompleta, massa cara, massa lenta o inapropiada per al procés empresarial que hauria de donar suport.
Per això l’observabilitat d’agents no es pot reduir al temps d’activitat. Una resposta 200 d’un endpoint LLM no vol dir que l’agent hagi fet la feina correcta. Els equips de producció han de saber què va veure l’agent, què va utilitzar, què va decidir, què va canviar i si el resultat va generar valor.
Les fallades d’IA sovint passen de manera silenciosa
Les aplicacions tradicionals normalment fallen de formes fàcilment detectables: un servei cau, una sol·licitud expira, un procés es bloqueja o un tauler deixa de carregar-se. Els agents d’IA poden fallar més silenciosament. Poden respondre amb confiança utilitzant coneixement obsolet. Poden ometre una crida crucial a una eina. Poden resumir malament un document. Poden produir una sortida que sembla plausible però que no compleix el requisit operatiu.
Les fallades silencioses són especialment perilloses quan els agents estan connectats a fluxos de treball reals. En un procés d’atenció, l’agent podria enrutar el cas a l’equip equivocat. En un procés de documentació clínica, podria passar per alt una evidència que afecti el reemborsament. En un flux regulatori, podria fallar a preservar la traçabilitat necessària per a la revisió.
El risc operatiu no és només que el model estigui equivocat. El risc és que l’organització no pugui veure on va entrar l’error al sistema.
La resposta final és només l’última milla
Molts equips comencen monitoritzant la resposta final: va ser útil, fefaent, rellevant, segura i alineada amb la marca? Aquestes verificacions importen. Però no són suficients per als agents de producció perquè la resposta final és només l’extrem visible d’un flux de treball més llarg.
L’observabilitat d’agents ha de seguir el procés des de la font fins a la sortida. Això vol dir fer seguiment de la sol·licitud de l’usuari, la intenció detectada, la versió del prompt, el coneixement recuperat, el model utilitzat, les eines cridades, els permisos aplicats, la latència i el cost de cada pas, la sortida final i l’impacte posterior.
Sense aquest recorregut complet, els equips poden veure que una resposta va ser dolenta però encara no saber per què. El prompt era feble? Les dades font estaven incompletes? La recuperació va retornar el document equivocat? Una eina va fallar silenciosament? El model era massa petit per a la tasca? L’agent va triar la branca equivocada del procés? L’observabilitat és el que converteix aquestes preguntes en evidència.
Què haurien d’observar els equips
Els senyals exactes depenen del cas d’ús, però els agents de producció normalment necessiten visibilitat en diverses capes.
- Entrada i intenció: què va demanar l’usuari o el sistema, com es va classificar la sol·licitud i quin flux de treball es va disparar.
- Context i recuperació: quins documents, registres, llocs web, bases de dades o fonts de coneixement internes es van utilitzar.
- Model i execució del prompt: versions de prompt, elecció de models, paràmetres, latència, cost, reintents i errors.
- Activitat d’eines i sistemes: crides d’API, consultes a bases de dades, accions de navegador, permisos, aprovacions i transferències.
- Qualitat de la sortida: rellevància, fets comprovables, exhaustivitat, to, compliment de polítiques i utilitat per al flux de treball.
- Resultat empresarial: si l’agent va resoldre la sol·licitud, va reduir treball manual, va millorar la conversió, va estalviar temps o va crear valor operatiu mesurable.
Avaluacions i traçat són la base
Hi ha dues capacitats especialment importants: les avaluacions i el traçat (tracing).
Les avaluacions ajuden els equips a jutjar la qualitat de la sortida a escala. Algunes comprovacions són deterministes, com si hi ha un camp obligatori present o si una resposta conté una afirmació prohibida. Altres fan servir avaluacions basades en models per mesurar dimensions com l’utilitat, la rellevància, l’exhaustivitat o si la resposta està fonamentada en el context aprovat.
El traçat explica com va passar una sortida. Un traçat útil mostra els passos que va fer l’agent, els sistemes que va tocar, el context que va recuperar i el cost i la latència de cada part de l’execució. Per als equips que operen processos reals, el traçat no és només una funció de depuració. És com revisen incidents, responen preguntes d’interessats i milloren el flux de treball amb el temps.
L’observabilitat ha d’incloure dades, codi, sistemes i models
Un error comú és tractar l’observabilitat com quelcom que comença i acaba a la frontera del model. En la pràctica, molts problemes que semblen falles de model són causats aigües amunt o aigües avall.
Les dades font poden estar obsoletes. Un document pot haver estat indexat incorrectament. Un canvi de prompt pot haver reduït el rendiment per a un segment específic d’usuaris. Una eina pot estar retornant resultats parcials. Una regla de permisos pot ser massa ampla o massa restrictiva. El model pot estar funcionant bé, però el flux de treball circumdant pot ser feble.
Les operacions d’IA fiables requereixen visibilitat a través de tot el sistema: la capa de dades, la capa d’aplicació, la capa de prompt i codi, les eines connectades i la capa de models. Els agents són sistemes de sistemes. L’observabilitat ha d’encaixar amb aquesta realitat.
L’objectiu no són els taulers. L’objectiu és el control.
La monitorització només és útil si els equips poden actuar sobre allò que detecten. Un tauler que mostra un augment de l’índex d’errors, un cost més alt o una puntuació d’avaluació més baixa és un punt de partida. El valor real prové de poder resoldre l’incident.
Això pot significar canviar un prompt, reemplaçar una font de coneixement, desactivar una eina, ajustar permisos, afegir un pas de revisió humà, moure un flux de treball a un altre model o crear una nova avaluació per a un mode de fallada que abans no era visible.
Aquí és on l’observabilitat esdevé operativa. Dona als equips un bucle de retroalimentació: observa què va passar, entén per què va passar, canvia el sistema i mesura si el canvi ha millorat el procés.
Com començar
Els equips no necessiten instrumentar-ho tot des del primer dia. Però haurien de començar amb els senyals que s’ajustin al risc del procés. Un assistent públic del lloc web pot començar amb la qualitat de les respostes, les preguntes sense resposta, el cost i la conversió. Un agent d’operacions intern pot necessitar traces d’eines, permisos, aprovacions i la finalització de tasques. Un flux de treball regulat pot requerir historial d’evidències, versionat i rastrejos de revisió des del principi.
La mesura important és dissenyar l’observabilitat abans que l’agent esdevingui crític. Els pilots poden sobreviure amb revisió manual i depuració ad hoc. Els fluxos de treball de producció no. Un cop hi ha usuaris reals, dades reals i decisions empresarials reals, la pregunta deixa de ser si l’agent pot fer una bona demo. La pregunta és si l’organització pot operar-lo de manera responsable.
Els agents d’IA seran cada cop més útils a mesura que tinguin accés a més context i més eines. Això també fa que siguin més difícils d’entendre sense la visibilitat adequada. L’observabilitat és com els equips mantenen aquest poder usable, mesurable i sota control.