Evaluación fuera de línea vs monitoreo en línea para agentes de IA

Definiendo la evaluación fuera de línea

Composición de trayectorias

Una trayectoria es una lista ordenada de pasos que el agente debe seguir cuando recibe una entrada específica. Cada paso contiene:

- la expresión del usuario o evento del sistema que desencadena al agente - el pensamiento o razonamiento que el agente debe producir (si se registra la cadena de pensamiento) - la llamada a la herramienta o solicitud de API que el agente debe realizar - la respuesta de la herramienta o retroalimentación del entorno esperada - la salida final del agente que se debe mostrar al usuario o sistema downstream

Cuando se recopilan trayectorias, generalmente se comienza con un pequeño conjunto de historias de usuario representativas, luego se expanden agregando casos de borde que se han visto en registros o que se pueden imaginar a partir de documentos de requisitos.

Rubrica de calificación

La evaluación fuera de línea compara la trayectoria real del agente con la trayectoria dorada utilizando una rubrica que puede contener varias dimensiones independientes:

- Coincidencia exacta – ¿el agente produce la misma secuencia de llamadas a herramientas y respuestas? - Similitud semántica – ¿las expresiones o salidas son equivalentes en términos de significado, aunque la redacción sea diferente? - Fidelidad – ¿el razonamiento del agente se mantiene fundamentado en las salidas de herramientas proporcionadas? - Éxito de la tarea – ¿la salida final satisface los criterios de éxito definidos para la historia?

Cada dimensión recibe una puntuación entre 0 y 1. La puntuación general fuera de línea suele ser un promedio ponderado, pero también se puede tratar cada dimensión como una puerta separada.

Ejecución de la evaluación fuera de línea en CI

Debido a que el conjunto de trayectorias es estático y la rubrica es determinista, se puede ejecutar la evaluación como un paso en la tubería de integración continua. El paso generalmente:

- verifica el código del agente y los fixtures de trayectorias - instala las dependencias requeridas - ejecuta el agente en cada trayectoria, capturando la traza real - aplica la rubrica y escribe un informe JSON - falla la compilación si alguna puntuación cae por debajo de un umbral predefinido

Esto proporciona una retroalimentación rápida sobre las regresiones que se pueden reproducir.

Definiendo el monitoreo en línea

Lo que se observa en producción

El monitoreo en línea no compara con un guión preescrito. En su lugar, transmite señales en vivo desde el agente en ejecución y busca desviaciones de líneas de base establecidas. Las señales típicas incluyen:

- distribución de la longitud de la expresión del usuario o recuento de tokens - frecuencia de cada llamada a herramientas - tasas de error devueltas por API externas - latencia de cada paso en el bucle del agente - tasa de comportamientos de fallback o reintentos - deriva semántica en la salida final (medida con la distancia de incrustación a un conjunto de referencia reciente)

Debido a que el tráfico de producción es ilimitado, se recopilan estas señales en ventanas de tiempo (por ejemplo, ventanas deslizantes de cinco minutos) y se comparan con cuantiles históricos.

Puntos de instrumentación

Para obtener los datos necesarios, se debe instrumentar el agente en algunos puntos clave:

- en el punto de entrada – capturar la solicitud del usuario cruda y una marca de tiempo - antes de cada llamada a herramientas – registrar la llamada intencionada y los argumentos - después de cada respuesta de herramientas – registrar la bandera de éxito, código de error y tamaño de carga útil - después de que el agente produce su salida final – registrar el texto de salida y cualquier puntuación de seguridad - en intervalos regulares – emitir un latido que incluya el uso de memoria y la carga de CPU

Estos registros se envían a una parte trasera de observabilidad (Prometheus, Loki o una serie de tiempo personalizada) donde se pueden crear paneles y alertas.

Regla de alerta de ejemplo

Una regla útil es alertar cuando la proporción de llamadas a una API externa que devuelven un error 5xx supera el percentil 99 de las últimas dos semanas durante tres ventanas consecutivas. Esto detecta una degradación repentina en una dependencia que el conjunto fuera de línea nunca cubrió porque el modo de fallo solo aparece bajo carga del mundo real.

Peligros comunes al confiar solo en una capa

- Envío con solo puntuaciones fuera de línea – es posible que pase la puerta pero aún así lance un agente que falla en frases de usuario raras o en un comportamiento de herramientas que solo se muestra bajo alta concurrencia. - Envío con solo paneles – es posible que note un problema días después de que el cambio ofensivo se haya fusionado, lo que hace que el rollback sea más difícil y aumenta el impacto en el usuario. - Comparar números de producción en un período en el que también cambiaron el modelo, el prompt o la lista de herramientas – la deriva observada podría deberse a la actualización intencional en lugar de una regresión, lo que lleva a falsas alarmas. - Usar el mismo umbral para señales fuera de línea y en línea – las puntuaciones fuera de línea suelen ser ajustadas (se esperan coincidencias casi perfectas) mientras que las métricas en línea son ruidosas; aplicar un solo corte puede causar falsos positivos o detecciones perdidas. - Descuidar la versión del conjunto de trayectorias – si se actualizan las trayectorias doradas sin r…

Construyendo una puerta de regresión en CI

A continuación, se muestra un ejemplo concreto de cómo se podría estructurar la puerta para un agente de soporte al cliente que utiliza un modelo de lenguaje, una herramienta de recuperación y una API de creación de tickets.

Paso | Herramienta o script | Salida | Frecuencia Checkout del código y fixtures | git clone + git checkout | espacio de trabajo limpio | una vez por ejecución de la tubería Instalación de dependencias | pip install -r requirements.txt | entorno aislado | una vez por ejecución de la tubería Ejecución del agente en cada trayectoria | python run_agent.py --trayectorias data/trayectorias.jsonl | archivo JSONL con trazas reales | una vez por ejecución de la tubería Aplicación de la rubrica | python score_traces.py --rubrica config/rubrica.yaml | puntuaciones por dimensión y general | una vez por ejecución de la tubería Verificación de umbrales | python gate_check.py --min-overall 0.92 --min-fidelidad 0.88 | estado de aprobación/rechazo | una vez por ejecución de la tubería Publicación del informe | curl -X POST -d @report.json https://metrics.example.com/ingest | registro en la serie de tiempo | una vez por ejecución de la tubería

Cada paso se mantiene deliberadamente idempotente para que la reejecución de la tubería produzca el mismo resultado. Si algún paso falla, la tubería se detiene y la solicitud de fusión se bloquea.

Configuración de alertas de producción que importan

El monitoreo en línea efectivo se centra en señales que cambian rápidamente cuando algo sale mal, en lugar de en métricas que solo se desvían lentamente.

Tasa de error de herramientas

Mida la proporción de llamadas a herramientas fallidas con respecto al total de llamadas a herramientas para cada servicio externo. Un aumento repentino a menudo indica una interrupción en una dependencia o un cambio en el contrato de servicio que el agente no ha adaptado.

Recuento de reintento del bucle

Algunos agentes reintenta una llamada a herramientas cuando reciben una respuesta ambigua. Registre el número promedio de reintentos por solicitud de usuario. Un aumento puede significar que el modelo está produciendo salidas más inciertas o que la herramienta está devolviendo errores vagos.

Deriva de incrustación de salida

Calcule una incrustación de oración para cada salida final del agente y compare su distancia con la mediana de incrustación de la última semana estable. Si la distancia del percentil 95 supera un límite preestablecido, desencadene una investigación.

Monitor de señales de seguridad

Si se ejecuta un detector de inyección de prompt o un filtro de profanidad en la salida del agente, registre la fracción de solicitudes que se marcan. Utilice la hoja de trucos de prevención de inyección de prompt de LLM de OWASP (https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) para decidir qué patrones observar. Un aumento en las solicitudes marcadas puede indicar que el modelo se está volviendo más susceptible a intentos de jailbreak.

Todas estas alertas deben dirigirse a una rotación de llamadas con un libro de ejecución claro que describa cómo revertir la versión del agente, cómo parchear una herramienta o cómo recopilar trayectorias adicionales para pruebas fuera de línea.

Cerrando el bucle: convirtiendo hallazgos de monitoreo en pruebas fuera de línea

El verdadero poder de tener ambas capas aparece cuando se utilizan observaciones de producción para mejorar la suite de pruebas.

Captura de un fallo novel

Cuando se dispara una alerta, el primer paso es extraer la secuencia exacta de solicitud y respuesta que causó el problema. La mayoría de los sistemas de observabilidad permiten descargar un ID de traza que incluye:

- la expresión original del usuario - cada llamada a herramientas y sus argumentos - cada respuesta de herramientas - la salida final del agente

Guarde esta traza como un nuevo archivo de trayectoria.

Etiquetado del comportamiento esperado

Trabaje con el propietario del producto o el líder de seguridad para decidir qué comportamiento correcto debería ser. Si el fallo se debió a un error en la herramienta, es posible que decida simular la respuesta de la herramienta para simular la versión corregida. Si el fallo se debió al razonamiento del modelo, es posible que escriba una cadena de pensamiento que conduzca a la respuesta correcta.

Agregue al conjunto fuera de línea

Coloque la nueva trayectoria en el directorio de trayectorias controlado por versiones. Actualice la documentación para anotar la fuente (por ejemplo, “agregado desde el incidente de producción INC-2024-09-12-07”).

Ajuste la rubrica si es necesario

A veces, una nueva trayectoria revela una dimensión que se ignoró previamente. Por ejemplo, es posible que descubra que el agente a veces produce una respuesta correcta pero incluye una frase de disculpa innecesaria que molesta a los usuarios. Puede agregar una dimensión de “concisión” a la rubrica y darle un peso.

Vuelva a ejecutar la puerta

Vuelva a ejecutar la tubería de CI. Si la nueva trayectoria hace que la puntuación general caiga por debajo del umbral, sabe que el código actual habría fallado la puerta – que es exactamente lo que se quería detectar antes del lanzamiento.

Repitiendo este ciclo se crea un bucle de retroalimentación donde la producción enseña a la suite de pruebas qué probar, y la suite de pruebas evita que se produzcan regresiones conocidas en los usuarios.

Qué no es esto

Esta discusión no promete que la evaluación fuera de línea detectará todos los posibles errores antes del lanzamiento. No afirma que el monitoreo en línea nunca perderá un fallo o que las dos capas juntas proporcionan una garantía del 100 % de corrección. No establece que el uso de estos métodos hará que el agente sea impecable o que se pueden omitir las revisiones de seguridad, los ejercicios de equipo rojo o la verificación formal. No sugiere que las señales descritas son suficientes para el cumplimiento normativo en dominios de alto riesgo. No afirma que el flujo de trabajo eliminará la necesidad de supervisión humana o que se puede confiar únicamente en puntuaciones automatizadas para decisiones de lanzamiento. No garantiza que algún umbral en particular funcionará para cada equipo o cada arquitectura de modelo. No afirma que la tabla anterior es la única forma de configurar una puerta de CI o que las reglas de alerta enumeradas son universalmente óptimas. No…

Referencias

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html - https://docs.agents-squads.com/guides/config-files

Preguntas frecuentes

¿Necesitamos ambos?

Sí, si el agente afecta algo que le importa a un usuario o sistema. Detectan diferentes clases de fallos.

¿Pueden reemplazar las pruebas fuera de línea el monitoreo?

No. Su conjunto de pruebas no puede contener entradas que no se han pensado aún.

¿Puede reemplazar el monitoreo las pruebas fuera de línea?

No. El monitoreo le dice que algo cambió después del hecho; una puerta le dice antes del lanzamiento.

¿En qué debemos alertar en producción?

Tasa de cambio en señales de fallo, tasas de error de herramientas y patrones de reintento o bucle inusuales — no solo volumen.

¿Cómo mantenemos las puntuaciones comparables con el tiempo?

Fije la rubrica y las trayectorias, y registre los cambios en el modelo, el prompt y las herramientas junto con las puntuaciones.

¿Es alguna de las capas una certificación de seguridad?

No. Ambas son señales de ingeniería. La revisión de seguridad es un ejercicio separado.

Referencias

- NIST — Marco de gestión de riesgos de IA - Stanford CRFM — HELM (Evaluación holística de modelos de lenguaje)

Pruebe el producto: AgentGrade

2026-09-20 · solo fuentes primarias · no métricas de tráfico fabricadas · solo para apoyo de decisiones

Artículos relacionados

- Rubricas de evaluación de agentes que viajan a través de pilas - Explorar la matriz completa de temas de micro-SaaS de IA →