Métricas de agentes de IA: éxito y cobertura

Elige la unidad antes de calcular una tasa

Una traza es una interacción registrada. Un resultado de prueba evalúa un escenario frente a una ejecución. Una aserción comprueba una expectativa dentro de esa prueba. Una traza puede coincidir con varios escenarios y una prueba puede contener varias aserciones. Estos recuentos no son intercambiables.

Los cálculos siguientes son ejemplos sintéticos para tu informe de evaluación, no resultados medidos de Mibo ni una promesa de que cada métrica tenga un widget en el panel. Mantén los resultados de comportamiento, la aplicabilidad y la calidad de la evidencia en columnas separadas.

Calcula la tasa de aprobación de aserciones sin contar las omisiones como aprobados

Supongamos que un informe contiene 50 registros de aserciones: 15 aprobados, 5 fallidos y 30 omitidos porque una dependencia impidió evaluarlos. La población puntuada contiene 20 aserciones.

• Tasa de aprobación: 15 / (15 + 5) = 75%.
• Tasa de fallo: 5 / (15 + 5) = 25%.
• Omitidas: 30 / 50 = 60% de los registros. Investiga por qué nunca se evaluaron estas comprobaciones.

Presentar 5 / 50 = 10% como tasa de fallo diluiría los fallos con comprobaciones no evaluadas. Indica «15 aprobadas, 5 fallidas, 30 omitidas» junto a la puntuación. Una comprobación dependiente omitida también es distinta de un escenario que no era aplicable.

La puntuación de ejecución de Mibo divide las aserciones aprobadas entre las puntuables y excluye las omitidas por dependencias. Su métrica de calidad agregada promedia las puntuaciones de los resultados registrados. Son agregaciones distintas: un resultado con 1/1 aprobada y otro con 1/9 aprobada dan una media del 55,6%, mientras que agrupar sus aserciones da 2/10 = 20%. Especifica qué agregación usas.

Cuando no hay aserciones puntuables, el evaluador actual devuelve una puntuación de 1,0. Esto también ocurre si se omiten todas las aserciones. Revisa los recuentos de aprobadas, fallidas y omitidas antes de interpretar la puntuación como evidencia de una evaluación satisfactoria.

Define las métricas de resultados y herramientas con contratos explícitos

• Tasa de éxito del escenario: ejecuciones que cumplen todos los resultados obligatorios / ejecuciones aplicables con evidencia suficiente. Define de antemano los resultados obligatorios e informa por separado de las ejecuciones excluidas. Una puntuación media de aserciones no equivale automáticamente a esta tasa.
• Precisión del enrutamiento: solicitudes enrutadas correctamente / solicitudes etiquetadas con enrutamiento observable. Etiqueta las rutas esperadas a partir de la entrada; seleccionar solo trazas que ya están en la ruta correcta oculta los fallos de enrutamiento.
• Corrección de argumentos de herramientas: llamadas con los argumentos obligatorios validados / llamadas inspeccionadas que requieren esos argumentos. Cuenta también las ejecuciones en las que nunca se produjo la llamada obligatoria; estas desaparecen de un denominador basado solo en llamadas.
• Tasa de afirmaciones de finalización sin respaldo: respuestas evaluadas que afirman que una acción tuvo éxito sin evidencia que lo respalde / respuestas evaluadas que afirman haber completado una acción. Usa criterios semánticos explícitos y revisa los juicios discutidos.
• Recuento de acciones no autorizadas: modificaciones de estado prohibidas observadas, agrupadas por escenario y gravedad. Mantén este dato visible incluso cuando la tasa global de aprobación sea alta.

Usa el flujo de pruebas de seis casos para definir estos contratos antes de recopilar puntuaciones. Un estado HTTP de éxito no demuestra por sí solo ninguno de ellos.

Mide la cobertura de escenarios por separado de la calidad

Imagina 100 trazas de producción capturadas: 60 coinciden con al menos un escenario configurado, 25 no coinciden con ninguno, 10 carecen de una entrada utilizable y 5 no se pueden clasificar. En este ejemplo, son grupos de trazas mutuamente excluyentes.

• Proporción de coincidencias entre las trazas capturadas: 60 / 100 = 60%. Describe la muestra capturada, no todo el tráfico de producción si la exportación o el muestreo omitieron interacciones.
• Proporción de coincidencias entre las trazas clasificables: 60 / (60 + 25) = 70,6%. Indica explícitamente este denominador más reducido.
• Sin coincidencia: inspecciona las 25 solicitudes para detectar escenarios ausentes o errores de clasificación. No son 25 pruebas exitosas.
• No clasificables: investiga por separado las 10 trazas sin entrada y las 5 con clasificación no disponible. No las conviertas en aprobados ni las elimines sin indicarlo.

Mibo distingue los resultados de clasificación matched, no_match, empty_input y unavailable. Las comprobaciones invariantes pueden ejecutarse aunque no haya coincidencia con un escenario condicional. Como una traza puede coincidir con varios escenarios, sumar los recuentos por escenario puede contar trazas más de una vez; elimina duplicados antes de informar de la cobertura del tráfico.

Trata la falta de evidencia y los errores del evaluador como problemas separados

Un span ausente puede significar que una acción nunca ocurrió o que la instrumentación no la registró. Determina si la traza está completa antes de interpretar aserciones negativas. El tratamiento de datos ausentes varía según la comprobación; un campo ausente no siempre recibe un estado de instrumentación separado.

Para las comprobaciones semánticas, conserva un pequeño conjunto de ejemplos etiquetados por ingenieros como aceptables o inaceptables. Compara el evaluador con esas etiquetas, inspecciona los desacuerdos y actualiza los criterios cuando sean ambiguos. Revisa esta calibración cuando cambie el modelo o el prompt del evaluador.

La tasa de alucinaciones de Mibo se basa en los fallos de las aserciones hallucination_check configuradas. Sin esas aserciones, no hay una tasa medida. No mide todas las posibles afirmaciones sin respaldo de todo el tráfico.

Compara latencia y coste con la misma carga de trabajo

Informa de la latencia de extremo a extremo por separado de las duraciones del modelo y las herramientas. Elige una convención de percentiles, incluye el tamaño de la muestra e indica los tiempos de espera agotados y las mediciones de tiempo ausentes. Un p95 menor no es una mejora de calidad si el agente ahora omite herramientas obligatorias.

Los tokens miden consumo, no un importe monetario. Las estimaciones de coste necesitan los precios aplicables del modelo, las categorías de tokens, los reintentos y los cargos de herramientas. Compara por tarea completada cuando tu objetivo sea completar tareas y mantén visibles los costes de intentos fallidos.

Al comparar versiones, mantén constantes, cuando sea posible, la combinación de escenarios, los datos de prueba, el evaluador y el periodo de medición. De lo contrario, un cambio hacia solicitudes más fáciles puede parecer una mejora. Inspecciona los resultados por escenario antes de aceptar una ganancia agregada.

Escribe un informe de publicación que respalde una decisión

• Alcance: versiones del agente, la suite y el evaluador, escenarios, número de ejecuciones y condiciones de los datos de prueba.
• Comportamiento: recuentos de aprobados y fallos, regla de agregación, fallos críticos y enlaces a la evidencia de trazas relevante.
• Puntos ciegos: comprobaciones omitidas, trazas incompletas, tráfico sin coincidencias y clasificación no disponible.
• Operaciones: distribución de latencia, tiempos de espera agotados, supuestos de consumo o coste y tamaños de muestra.
• Decisión: qué escenario bloquea la publicación, qué debe corregirse y qué necesita más ejecuciones o revisión humana.

Cinco ejecuciones exitosas no demuestran una probabilidad de éxito del 100% en producción. Indica «5/5 con estos datos de prueba» y amplía las pruebas en torno a los fallos importantes. Elige los umbrales según las consecuencias de un error, no según una puntuación arbitraria del sector.

Conecta las métricas con una prueba que puedas inspeccionar

Empieza con un escenario de la biblioteca de casos de prueba de agentes, define sus comprobaciones e inspecciona una ejecución aprobada y otra fallida. El flujo de evaluación de Mibo conecta las comprobaciones configuradas con la evidencia de ejecución para que el resultado permita una corrección concreta.

Para los detalles de implementación, usa la referencia de aserciones y la guía de ingesta de OpenTelemetry. Elige las métricas solo después de confirmar que tu instrumentación proporciona los campos que necesitan.