Susana López Blanco Un agente comercial envía una propuesta incorrecta. El texto está bien escrito, los datos del cliente parecen coherentes y el precio tampoco llama la atención. Al revisar la ejecución aparece el recorrido: recuperó una tarifa antigua, consultó correctamente el CRM, llamó a la herramienta de precios, interpretó mal una condición y entregó ese cálculo al paso siguiente como válido.
Guardar únicamente la propuesta final deja pocas pistas. Para corregir el caso necesitamos reconstruir qué información recibió el agente, qué modelo y prompt estaban activos, qué documentos y recuerdos recuperó, qué herramientas llamó, qué devolvió cada una y cuánto tardó todo el proceso.
Eso es lo que buscamos con la observabilidad de agentes de IA: disponer de un registro suficientemente preciso para investigar una ejecución concreta y comparar su comportamiento con otras versiones. También necesitamos saber cuánto costó completar la tarea y qué ocurrió después.
La segunda prueba llega cuando cambiamos algo. Un modelo nuevo obtiene mejores resultados en varios casos y empeora otros que llevaban meses funcionando. La comparación necesita los mismos ejemplos, las mismas métricas y un registro claro de qué versión ejecutó cada tarea. Esta evaluación forma parte de la arquitectura de IA empresarial que conecta datos, eventos, scorings, memoria, herramientas y modelos.
En esta guía vamos a trabajar sobre esas dos situaciones: reconstruir un fallo y comprobar si una versión nueva mejora el proceso antes de darle más trabajo real.
Índice de contenidos
Reconstruir una ejecución antes de intentar arreglarla
Cada tarea necesita un identificador desde que empieza hasta que termina. Puede llamarse run_id, execution_id o utilizar cualquier otra convención estable. Ese identificador relaciona los pasos de una misma ejecución.
Supongamos que run_18452 corresponde a una petición para preparar la renovación de un cliente. La traza, es decir, el registro ordenado de esa tarea, muestra:
- El CRM devuelve cliente, contrato y productos activos.
- El buscador documental recupera las condiciones comerciales aplicables.
- La memoria recupera una excepción aprobada seis meses antes.
- El agente consulta
calcular_precio_renovacion. - La herramienta devuelve 18.400 euros.
- El modelo prepara una propuesta con ese importe.
- El comercial rechaza la propuesta porque esperaba 16.900 euros.
Ahora podemos investigar. La excepción quizá había caducado. La herramienta pudo recibir un código de producto equivocado. El cálculo podía ser correcto y la interpretación posterior, incorrecta. Cada hipótesis apunta a un paso concreto.
El registro debería conservar también el modelo, su configuración, la versión del prompt y los recursos recuperados. Intentar reproducir el incidente meses después con instrucciones distintas y otro modelo nos llevaría a analizar una ejecución diferente.
En nuestra guía sobre memoria para agentes de IA explicamos qué antecedentes merece conservar un agente. Aquí interesa registrar qué recuerdo recibió aquella ejecución, cuándo se creó y qué contenido llegó al modelo.
La respuesta final apenas explica dónde apareció el error
Una salida correcta tampoco demuestra que toda la ejecución haya funcionado correctamente. El agente puede haber repetido llamadas, recuperado documentos irrelevantes o consumido mucho más contexto del necesario y terminar acertando porque un paso posterior corrigió el problema.
También podemos tener una salida incorrecta después de varios pasos bien resueltos. Modificar el prompt final durante días sirve de poco si el dato equivocado apareció antes, por ejemplo durante la recuperación documental o al llamar a una herramienta.
En la propuesta comercial anterior hay varios puntos que revisar:
- El CRM pudo entregar un contrato antiguo.
- La búsqueda documental pudo seleccionar una tarifa caducada.
- La herramienta pudo recibir argumentos incorrectos.
- La herramienta pudo calcular mal con argumentos válidos.
- El modelo pudo interpretar incorrectamente una excepción.
- Un paso posterior pudo descartar información que ya estaba disponible.
Cada origen exige una corrección distinta. Un fallo de recuperación lleva a revisar fuentes, filtros o fechas. Una herramienta defectuosa lleva al código o a la integración. Un error de interpretación obliga a examinar las instrucciones, el modelo y el contexto que recibió.
La traza sustituye diagnósticos como «el agente se inventó el precio» por una secuencia que podemos comprobar.
Qué registrar en las trazas de cada ejecución
Registrar absolutamente todo genera costes, problemas de privacidad y cantidades de información que después nadie consulta. Necesitamos conservar aquello que permita reproducir incidentes y comparar versiones.
| Qué registrar | Para qué sirve |
|---|---|
| Identificador de ejecución | Relaciona los pasos de una misma tarea. |
| Fecha y hora | Indica qué datos y versiones estaban vigentes. |
| Usuario, cliente o proceso | Identifica el contexto operativo. |
| Modelo y configuración | Ayudan a reproducir el comportamiento. |
| Versión del prompt | Identifica las instrucciones utilizadas. |
| Documentos recuperados | Muestran qué información documental recibió el modelo. |
| Memoria recuperada | Permite revisar qué antecedentes intervinieron. |
| Llamadas a herramientas | Registran operaciones, argumentos y respuestas. |
| Entradas y salidas intermedias | Ayudan a localizar dónde apareció una desviación. |
| Errores y reintentos | Descubren fallos ocultos tras una salida aparentemente normal. |
| Tiempo | Localiza los pasos que retrasan la tarea. |
| Coste | Atribuye consumo a una ejecución concreta. |
| Resultado | Relaciona la ejecución con lo ocurrido después. |
| Revisión humana | Conserva aceptación, corrección o rechazo cuando existen. |
Como referencia técnica, OpenTelemetry publica convenciones para registrar operaciones de inteligencia artificial generativa, entre ellas el modelo utilizado, consumo de tokens, llamadas a herramientas y resultados. Utilizar nombres consistentes ayuda a consultar las trazas de distintas aplicaciones con la misma lógica.
Hay que tratar aparte los datos sensibles. Una plataforma de trazas no necesita almacenar copias completas de contratos, credenciales o datos personales para demostrar qué recurso se consultó. Según el caso pueden bastar identificadores, referencias, hashes o versiones.
Empezaría por los campos que un equipo utilizaría durante una investigación real. Si un dato lleva meses almacenándose y nadie sabe qué decisión permite tomar, merece revisar su conservación.
Las llamadas a herramientas necesitan su propia trazabilidad
Los agentes de IA en la empresa pueden consultar aplicaciones y ejecutar operaciones. En esas llamadas interesa registrar argumentos, respuesta, duración, errores, reintentos y cualquier efecto producido fuera del agente.
Tomemos solicitar_reembolso. Una consulta errónea puede terminar en una respuesta incorrecta. Una operación repetida puede provocar dos movimientos reales.
tool: solicitar_reembolso
order_id: 78421
amount: 129.00
reason: producto_defectuoso
attempt: 1
status: timeout
effect: ninguno
tool: solicitar_reembolso
order_id: 78421
amount: 129.00
reason: producto_defectuoso
attempt: 2
status: completed
effect: refund_id_99214
latency_ms: 841
El registro muestra que hubo un reintento y que únicamente el segundo produjo un efecto. Si aparecen dos devoluciones, podemos buscar otra ejecución o una operación posterior en lugar de reconstruir el incidente a partir del saldo final.
También interesa conservar la respuesta obtenida entonces. Un CRM puede devolver hoy un valor diferente, una API puede cambiar de formato y una consulta puede recuperar información que ya ha sido actualizada. Investigar con el estado actual puede ocultar lo que recibió realmente el agente.
En nuestro Máster en Agentes IA y Automatización No-Code trabajamos estos recorridos completos: una decisión del agente termina consultando o modificando aplicaciones que ya forman parte del negocio.
Cuánto cuesta resolver una tarea completa
El precio por millón de tokens ayuda a comparar modelos. Para una empresa interesa además cuánto cuesta terminar correctamente una tarea.
Una incidencia de soporte puede requerir cuatro llamadas al modelo, dos búsquedas documentales, una consulta al CRM, otra al ERP y un reintento porque una herramienta agotó su tiempo de espera. Si termina en revisión manual, hay que añadir el tiempo de esa persona.
La misma cuenta sirve para una propuesta comercial, la revisión de un contrato o una investigación de fraude. Podemos atribuir a la ejecución:
- llamadas a modelos;
- embeddings y recuperación documental;
- servicios externos;
- herramientas de pago;
- reintentos;
- otros agentes que hayan intervenido;
- infraestructura atribuible;
- revisión humana.
El tiempo también debe medirse sobre el recorrido completo. Un modelo puede responder en 800 milisegundos mientras la tarea tarda 42 segundos porque una consulta documental consume 18 y una herramienta agota su tiempo de espera.
Las medias esconden a menudo los casos lentos. Una mediana razonable puede convivir con un grupo de ejecuciones que tarda un minuto. Los percentiles y la segmentación por tipo de tarea ayudan a localizar dónde aparece el retraso.
Coste, tiempo y resultado deben leerse juntos. Una ejecución barata pierde atractivo si termina con frecuencia en revisión manual. Otra algo más cara puede cerrar más casos sin correcciones. La comparación empresarial termina en el coste de completar correctamente el proceso.
Los casos de evaluación tienen que parecerse al trabajo real
Las primeras demos suelen utilizar ejemplos cómodos. Producción aporta después contratos incompletos, clientes duplicados, documentos antiguos, incidencias reabiertas y excepciones que nadie incluyó en las pruebas.
El conjunto de evaluación debe incorporar ese material. Incluiría:
- tareas normales y frecuentes;
- casos difíciles que un experto puede resolver con un criterio claro;
- errores encontrados anteriormente en producción;
- excepciones conocidas;
- tareas que exigen herramientas;
- casos con información incompleta;
- situaciones donde aceptamos varias respuestas;
- operaciones que requieren revisión humana por su impacto.
Cada caso necesita un criterio de corrección. Una clasificación puede tener una etiqueta esperada. Una extracción permite comparar campos. Una llamada a herramientas se puede evaluar por sus argumentos y su efecto. En una propuesta comercial admitiremos distintos textos siempre que precio, condiciones y productos respeten las reglas del caso.
Comparar palabra por palabra resulta poco útil cuando existen muchas respuestas válidas. Es preferible evaluar hechos obligatorios, errores, restricciones, herramientas elegidas y resultado de la tarea.
Otro modelo puede revisar determinadas propiedades de una salida cuando el volumen lo justifica. Estos evaluadores necesitan criterios bien definidos y ejemplos revisados por personas. También cometen errores y pueden premiar una respuesta bien redactada aunque mantenga un fallo importante.
La revisión humana resulta especialmente útil al principio, ante errores nuevos, en casos ambiguos y en operaciones de alto impacto. Una muestra periódica sirve para comprobar si las evaluaciones automáticas siguen reflejando el criterio de quienes conocen el proceso.
En nuestro Máster en Data Science: Big Data e Inteligencia Artificial trabajamos esta relación entre datos, métricas y decisiones: una medida ayuda cuando sabemos qué estamos comparando y qué haremos con el resultado.
Cómo detectar regresiones antes de desplegar una versión nueva
Una regresión aparece cuando un cambio empeora casos que la versión anterior resolvía correctamente. Evaluar únicamente los ejemplos que motivaron la actualización puede ocultarla.
Supongamos que sustituimos el modelo porque interpreta mejor contratos largos. Mejora esa tarea, pero al ejecutar el conjunto completo descubrimos que llama peor a una herramienta, tarda más en consultas sencillas y vuelve a fallar en una excepción que habíamos corregido meses atrás.
La decisión necesita todos esos resultados. Quizá compense ajustar la aplicación antes del despliegue, utilizar el nuevo modelo solo en determinadas tareas o mantener temporalmente la versión anterior para algunos casos.
Para comparar necesitamos saber qué cambió. Guardaría, como mínimo:
- modelo y versión;
- prompt;
- parámetros relevantes;
- definición de herramientas;
- workflow;
- reglas aplicadas;
- configuración de recuperación documental;
- corpus o índice utilizado cuando afecte al resultado.
Si sustituimos el modelo, reescribimos el prompt, cambiamos el buscador y modificamos herramientas dentro de una misma versión, podremos comparar el conjunto completo, pero costará bastante más localizar qué modificación produjo cada mejora o regresión.
Los cambios pequeños simplifican el diagnóstico y la vuelta atrás. Cuando una modificación grande sea inevitable, el conjunto de evaluación y el registro de versiones adquieren más peso.
Probar una versión nueva antes de darle todo el tráfico
Una versión candidata puede procesar copias de tareas reales sin ejecutar las acciones que propone. Sus resultados se almacenan y se comparan con los de la versión activa. Esta práctica suele denominarse shadow testing.
Funciona bien con respuestas, clasificaciones, recuperación de información o decisiones sobre herramientas siempre que podamos impedir sus efectos externos. Si la candidata decide reembolsar 129 euros, conservamos la decisión sin enviar la orden.
Después podemos asignarle una pequeña parte del tráfico real. El porcentaje y la duración dependen del riesgo, el volumen y la facilidad para volver a la versión anterior. Una herramienta interna admite un despliegue distinto de una aplicación que modifica precios o comunica decisiones sensibles a clientes.
Las comparaciones deberían segmentarse por tipo de caso. Un promedio general puede esconder que la candidata mejora consultas fáciles y empeora precisamente las operaciones con mayor impacto.
Cuando participan varios agentes, la traza debe indicar qué agente ejecutó cada paso, qué recibió y qué devolvió. El diseño de esa coordinación corresponde a los sistemas multiagente; aquí nos interesa poder reconstruir después la ejecución completa.
Las métricas dependen del trabajo que hace el agente
Tokens, errores HTTP y tiempo de respuesta ayudan a mantener la aplicación. Para saber si el agente hace bien su trabajo necesitamos métricas del proceso.
En soporte pueden ser incidencias resueltas, reaperturas, derivaciones a una persona, tiempo hasta resolución, errores en herramientas y reclamaciones posteriores.
En ventas interesa observar propuestas aceptadas o corregidas, errores de precio, intervenciones del comercial y tiempo de preparación. Relacionar estas métricas con ventas posteriores exige cuidado porque el resultado depende también del vendedor, el producto, el precio y la competencia.
En extracción documental podemos comparar campos, medir omisiones, falsos positivos y documentos enviados a revisión.
| Proceso | Métricas útiles |
|---|---|
| Soporte | Resolución, reaperturas, derivaciones, tiempo, errores en herramientas |
| Ventas | Correcciones, errores de precio, tiempo de preparación, uso por comerciales |
| Documentos | Exactitud de campos, omisiones, revisión humana, tiempo por documento |
| Operaciones | Tareas completadas, reintentos, acciones fallidas, coste por tarea correcta |
| Agentes con herramientas | Selección correcta, argumentos válidos, errores, efectos duplicados |
Las métricas técnicas y las del proceso deben verse juntas. Si una versión reduce el tiempo de respuesta y aumenta las correcciones humanas, el equipo necesita ambas cifras para decidir.
Cómo montar la evaluación antes de ampliar el uso de agentes
Empezaría registrando unas pocas ejecuciones completas: identificador, versión, contexto recuperado, herramientas, tiempos, costes y resultado. Después comprobaría si ese registro basta para reconstruir un fallo sin recurrir a capturas de pantalla, recuerdos del equipo o conversaciones antiguas.
El siguiente paso sería reunir veinte o treinta casos conocidos. Incluiría situaciones normales, excepciones y errores que ya hayan ocurrido. Cada uno necesita una definición clara de qué consideramos correcto.
- Versionar modelo, prompt, herramientas y configuración.
- Ejecutar los mismos casos antes de desplegar un cambio.
- Comparar resultados por tipo de tarea.
- Medir tiempo y coste de la ejecución completa.
- Revisar los casos que han empeorado.
- Probar la versión candidata en paralelo cuando sea posible.
- Asignarle una parte limitada del trabajo real.
- Incorporar los errores nuevos al conjunto de evaluación.
El conjunto irá creciendo con producción. Un contrato que rompe una extracción entra en las pruebas. También una llamada incorrecta a una herramienta o una excepción comercial que nadie había contemplado.
Cuando llegue una nueva versión, ejecutaremos los mismos casos, veremos dónde mejora y dónde retrocede, calcularemos el coste por tarea y decidiremos con resultados obtenidos sobre nuestro propio proceso.
Preguntas frecuentes sobre observabilidad y evaluación de agentes de IA
¿Qué es la observabilidad de agentes de IA?
Es el registro que permite reconstruir una ejecución: entrada, modelo, prompt, información recuperada, herramientas utilizadas, resultados intermedios, errores, tiempo, coste y salida. Se utiliza para investigar fallos y comparar el comportamiento de distintas versiones.
¿Qué información debería registrar un agente?
Como mínimo, identificador de ejecución, fecha, modelo, versión del prompt, herramientas, entradas y salidas relevantes, errores, reintentos, tiempo, coste y resultado. Si utiliza RAG o memoria, interesa conservar también qué información recuperó.
¿Cómo se evalúa un agente de IA?
Se ejecuta sobre casos conocidos y se compara el resultado con criterios definidos para la tarea. Podemos medir exactitud, resolución, uso correcto de herramientas, coste, tiempo o necesidad de revisión humana. Los fallos encontrados en producción deberían incorporarse a las pruebas futuras.
¿Qué es una regresión en un agente?
Es un caso que una nueva versión resuelve peor que la anterior. Puede aparecer después de cambiar modelo, prompt, herramientas o recuperación documental. Ejecutar el mismo conjunto de pruebas sobre ambas versiones ayuda a detectarla antes del despliegue.
¿Cómo comparar dos versiones de un agente?
Ejecutándolas sobre los mismos casos y conservando la configuración de cada una. La comparación puede incluir resultados correctos, errores, llamadas a herramientas, tiempo, coste y métricas del proceso.
¿Qué métricas sirven para agentes en producción?
Dependen de la tarea. En soporte podemos medir resolución y reaperturas; en extracción, exactitud de campos; en operaciones, tareas completadas y errores; en agentes con herramientas, llamadas correctas y efectos duplicados. Coste y tiempo deberían calcularse sobre la tarea completa.
¿Puede utilizarse otro modelo para evaluar respuestas?
Sí. Resulta útil cuando hay muchas salidas y criterios suficientemente claros. Sus resultados deben contrastarse con casos revisados por personas y comprobarse periódicamente, porque el propio modelo evaluador también puede cometer errores.