L'explosió dels agents d'intel·ligència artificial ha transformat la forma en què les empreses aborden l'automatització i la presa de decisions. Però amb aquesta capacitat arriba un desafiament silenciós: la impredictibilitat del rendiment. A diferència de les aplicacions tradicionals, on un índex de base de dades o una consulta pesada explica la lentitud, en un sistema basat en LLM una sola petició d'usuari pot encadenar múltiples trucades a APIs externes, recerques en bases de dades vectorials, formateig de prompts i respostes en streaming. Si un client es queixa que el seu assistent virtual triga a respondre, no n'hi ha prou amb mirar l'ús de CPU del servidor. Cal saber quin model específic va consumir més temps, quants tokens es van gastar i si la recuperació de context va ser el coll d'ampolla. La resposta a aquesta necessitat de visibilitat profunda és OpenTelemetry aplicat al món de la IA.
En Q2BSTUDIO portem anys ajudant empreses a construir aplicacions a mesura que resolen problemes reals. Ara, amb la irrupció de la intel·ligència artificial generativa, hem vist que l'observabilitat ja no és un luxe sinó un requisit per mantenir el control de costos i la qualitat del servei. El nostre equip integra solucions de telemetria personalitzada en els pipelins d'agents IA, permetent als nostres clients monitoritzar no només l'estat del servidor, sinó cada pas lògic de la conversa amb el model.
La clau està en no conformar-se amb l'autoinstrumentació genèrica que només reporta que es va fer una petició HTTP. Per obtenir mètriques realment útils —com el nombre de tokens d'entrada i sortida, el nom del model o la latència exacta de la recerca vectorial— cal escriure traces semàntiques explícites. Això s'aconsegueix creant un tracer personalitzat amb OpenTelemetry que defineixi un span pare per a l'execució completa de l'agent i spans fills per a cada operació: la consulta a la base de dades vectorial, la trucada al LLM i, si es treballa amb streaming, el temps fins al primer token. Així obtenim un mapa temporal detallat que es pot visualitzar en eines com SigNoz o Jaeger.
Imaginem un escenari real: una empresa utilitza un agent IA per atendre dubtes tècnics sobre els seus productes. El client pregunta i el sistema, després de buscar en una base de coneixement vectorial, envia el context a GPT-4o. Amb la instrumentació adequada, podem veure que la recerca vectorial va consumir 400 mil·lisegons, la generació del model 1,8 segons i que es van gastar 370 tokens en total. Si de sobte una petició tarda 5 segons, el gràfic de flama ens mostrarà a l'instant quin pas es va allargar: potser la base de dades vectorial va començar a degradar-se per falta d'índexs, o el proveïdor del LLM va tenir una latència puntual. Sense aquestes traces, estaríem fent enginyeria a cegues.
Més enllà de la latència, el cost és l'altre gran dolor de cap. Cada token té un preu, i quan s'escalen els agents a cents o milers d'usuaris, la despesa es pot disparar. En adjuntar atributs com llm.total_tokens i llm.model_name als spans, podem construir dashboards en eines de Business Intelligence com Power BI o directament sobre ClickHouse, agrupant per model i sumant tokens. Això es converteix en un panell executiu que mostra en temps real quant estem gastant per cada versió de GPT o Claude. És un servei d'intel·ligència de negoci aplicada a l'operació d'IA.
Un altre aspecte crític que descobrim en els nostres projectes de programari a mida és la necessitat de no sobredimensionar la traçabilitat en fluxos asíncrons. Si l'agent retorna la resposta token a token mitjançant streaming, embolicar tot el bucle en un span infla artificialment la latència, perquè inclou la velocitat de xarxa del client. El correcte és mesurar el temps des que s'envia la petició fins que arriba el primer byte —el famós Time-To-First-Token— i després deixar que la resta de la transmissió flueixi sense ser cronometrada com a part de l'span principal. A més, en entorns productius cal usar sempre un BatchSpanProcessor, no el SimpleSpanProcessor, per evitar que l'aplicació esperi que el recol·lector de traces confirmi la recepció de dades, la qual cosa degradaria el rendiment de l'usuari final.
La integració d'aquesta telemetria amb la infraestructura cloud és natural. Molts dels nostres clients despleguen els seus agents en serveis cloud AWS i Azure, i utilitzar OpenTelemetry permet centralitzar les traces independentment del proveïdor. Combinat amb polítiques de ciberseguretat que impedeixin la fuga de dades sensibles a través dels atributs dels spans, aconseguim un sistema robust i auditable.
En Q2BSTUDIO considerem que la IA per a empreses ha de ser mesurable i governable. Per això oferim consultoria i desenvolupament d'aquestes solucions, ajudant les organitzacions a implementar agents IA amb traçabilitat completa. Si desitges aprofundir en com instrumentar els teus propis pipelins, et convidem a conèixer el nostre enfocament en intel·ligència artificial i observabilitat i com apliquem aquest coneixement a projectes reals. La transparència en el cost i el rendiment ja no és una opció: és la base per escalar la intel·ligència artificial amb confiança.
