ASSERT: de una especificación a evaluaciones ejecutables para agentes de IA

Construir un agente que funcione en una demo es solo una parte del trabajo. En proyectos reales, la parte difícil es demostrar de forma repetible que el sistema se comporta como estaba previsto: que usa las herramientas adecuadas, respeta restricciones explícitas, rechaza o escala cuando debe hacerlo y no inventa información cuando no tiene base suficiente.

El problema es que esa intención suele vivir en documentos de producto, políticas internas, instrucciones de sistema, criterios de lanzamiento o conversaciones de revisión. Con frecuencia, no termina convertida en una suite de evaluación ejecutable que pueda versionarse, repetirse y auditarse.

Ese es el hueco que intenta cubrir ASSERT.

Qué es ASSERT

ASSERT (Adaptive Spec-driven Scoring for Evaluation and Regression Testing) es un framework open source publicado por el equipo de Responsible AI de Microsoft. Su objetivo es convertir especificaciones de comportamiento escritas en lenguaje natural en evaluaciones estructuradas y ejecutables para modelos, agentes y aplicaciones basadas en LLM.

La idea central es partir de lo que el sistema debe y no debe hacer, generar una taxonomía de comportamiento, crear escenarios de prueba alineados con esa taxonomía, ejecutar esos escenarios contra el sistema objetivo y producir veredictos acompañados de evidencia.

No es una librería tradicional de tests unitarios. ASSERT no parte de aserciones escritas directamente en código, sino de requisitos de comportamiento expresados en lenguaje natural. A partir de ahí, genera artefactos que pueden revisarse, ejecutarse y mejorarse con el tiempo.

El problema: la evaluación se separa de la especificación

En casi cualquier proyecto serio de IA aplicada existe algún tipo de documentación sobre cómo debe comportarse el sistema:

instrucciones de sistema;
políticas de uso;
criterios de escalado, rechazo o derivación;
requisitos sobre cuándo usar una herramienta y cuándo no;
restricciones funcionales definidas por negocio, seguridad o cumplimiento;
escenarios que el agente debe resolver de una forma concreta.

Sin embargo, la evaluación suele empezar en otro sitio: prompts sueltos, notebooks, hojas de cálculo con casos manuales, benchmarks genéricos o revisiones subjetivas difíciles de reproducir semanas después.

Microsoft describe esta separación como una brecha entre la intención escrita y la evaluación ejecutable. ASSERT intenta cerrar esa brecha convirtiendo los requisitos en una estructura evaluable.

Este enfoque encaja con una recomendación más amplia para cargas de trabajo de IA: distinguir entre la evaluación del modelo y las pruebas del sistema completo, y tratar la detección de regresiones como parte del ciclo de vida. En agentes, esto es especialmente importante porque el comportamiento final no depende solo del modelo, sino también de prompts, herramientas, orquestación, memoria, reglas de negocio y datos externos.

Cómo funciona ASSERT

La documentación oficial de ASSERT describe un flujo basado en una especificación de evaluación en YAML. Esa configuración conecta la descripción del comportamiento, el sistema objetivo, la generación de pruebas, la captura de trazas y las dimensiones de juicio.

De forma simplificada, el pipeline se puede entender en seis fases.

1. Especificación de evaluación

El punto de partida es una descripción en lenguaje natural del comportamiento que se quiere evaluar. Puede estar basada en requisitos de producto, políticas, instrucciones de sistema o criterios de lanzamiento.

Un fragmento simplificado de una especificación, siguiendo el patrón mostrado en la documentación oficial, tendría esta forma:

suite: travel-planner-langgraph-v1
run: demo-1

behavior:
  name: travel_planner_eval
  description: |-
    # Travel Planner Evaluation

    A travel planning AI must reliably use its tools,
    respect user constraints, and produce accurate itineraries.

En una configuración real, la especificación también debe conectar el comportamiento descrito con el sistema que se va a evaluar y con los parámetros necesarios para generar, ejecutar y puntuar las pruebas.

2. Taxonomía de comportamiento

A partir de la especificación, ASSERT genera una taxonomía de comportamiento. Esta taxonomía organiza qué se va a evaluar y bajo qué categorías.

La documentación oficial describe esta taxonomía como una pieza central del proceso, porque permite pasar de una intención general a dimensiones de evaluación más concretas. Por ejemplo, en un agente de viajes podrían aparecer categorías relacionadas con:

uso correcto de herramientas;
respeto de restricciones de presupuesto;
ausencia de datos inventados;
resistencia a prompt injection;
evitación de estereotipos;
rechazo de instrucciones no permitidas.

La taxonomía no debe tratarse como un resultado definitivo e intocable. Debe revisarse por personas del equipo técnico, producto, seguridad o cumplimiento, porque condiciona la calidad de todo lo que se genere después.

3. Generación de escenarios de prueba

Con la taxonomía como guía, ASSERT genera escenarios de prueba estratificados. La diferencia respecto a una colección manual de prompts es que los casos están alineados con las categorías de comportamiento que se quieren evaluar.

Esto ayuda a reducir un problema habitual: probar únicamente los casos evidentes o felices y dejar sin cobertura fallos críticos. En agentes, esos fallos suelen aparecer en los límites del sistema: uso incorrecto de herramientas, instrucciones contradictorias, restricciones ignoradas, datos no fundamentados o intentos de manipulación del prompt.

4. Ejecución contra el sistema objetivo

Después, los escenarios se ejecutan contra el sistema que se quiere evaluar. Según el repositorio oficial, ASSERT está pensado para trabajar con distintos tipos de objetivos, incluidos modelos alojados, wrappers invocables y agentes trazados con OTel/OpenTelemetry.

Esta parte es importante: en agentes reales no basta con evaluar una respuesta de texto aislada. A menudo interesa evaluar el comportamiento de una aplicación completa, incluyendo llamadas a herramientas, decisiones de orquestación y resultados intermedios.

5. Captura de trazas y evidencias

Cuando el sistema está instrumentado, ASSERT puede apoyarse en trazas para evaluar no solo la respuesta final, sino también el recorrido que llevó a esa respuesta.

Esto es especialmente útil en agentes con herramientas. Dos respuestas finales pueden parecer similares, pero una puede haber usado correctamente una fuente externa y otra puede haber inventado el resultado. La trazabilidad ayuda a distinguir esos casos.

El repositorio oficial describe ASSERT como un harness de evaluación con artefactos locales inspeccionables. Esa orientación local-first es relevante para auditoría y depuración: los equipos pueden revisar entradas, salidas, evidencias y resultados en lugar de quedarse solo con una puntuación agregada.

6. Scoring y veredictos

Finalmente, ASSERT produce veredictos fundamentados en la política o especificación definida. La documentación habla de policy-grounded verdicts with evidence: veredictos apoyados en la política y acompañados de evidencia.

El resultado no debería interpretarse como una verdad absoluta. Como ocurre con cualquier sistema de evaluación basado en jueces automáticos, los resultados deben revisarse, calibrarse y compararse con ejemplos conocidos, sobre todo en dominios regulados o de alta criticidad.

Qué aporta frente a evaluaciones genéricas

Las métricas genéricas pueden ser útiles, pero rara vez responden por sí solas a la pregunta más importante en un producto con agentes:

¿El sistema hace lo que dijimos que tenía que hacer?

ASSERT aporta valor porque intenta conectar cinco elementos que a menudo están separados:

Requisito: qué comportamiento se espera.
Taxonomía: cómo se estructura ese comportamiento en categorías evaluables.
Escenario de prueba: qué situación concreta se usa para comprobarlo.
Ejecución: qué respondió o hizo el sistema.
Veredicto con evidencia: por qué se considera correcto o incorrecto.

Esa cadena es útil para desarrollo, regresión y revisión. Si un cambio en el prompt, el modelo, las herramientas o la lógica de orquestación degrada un comportamiento, el equipo puede volver a ejecutar la suite y comparar resultados.

Dónde encaja en el ciclo de vida de un agente

ASSERT no debe verse como una actividad puntual antes de publicar. La evaluación de agentes debería ser iterativa: empezar en diseño, continuar durante el desarrollo, usarse antes del despliegue y mantenerse después para detectar regresiones.

Un flujo razonable sería:

Diseño: convertir requisitos de comportamiento en especificaciones evaluables.
Desarrollo: ejecutar suites frecuentes contra versiones del agente.
Preproducción: validar criterios de lanzamiento y casos límite.
Cambios posteriores: repetir evaluaciones cuando cambien prompts, modelos, herramientas, conectores o reglas.
Operación continua: combinar evaluaciones sintéticas con observabilidad, feedback real e investigación de incidentes.

Este enfoque está alineado con las guías de Microsoft sobre evaluación de agentes y con las recomendaciones del Azure Well-Architected Framework para pruebas y evaluación de cargas de trabajo de IA.

Limitaciones y cautelas

ASSERT puede ser una pieza valiosa, pero no elimina los problemas difíciles de evaluar agentes. Conviene tener claras varias limitaciones.

1. La calidad depende de la especificación

Si el requisito es ambiguo, incompleto o contradictorio, la evaluación heredará ese problema. ASSERT ayuda a estructurar la intención, pero no sustituye el trabajo de definir bien el comportamiento esperado.

2. Los casos generados no sustituyen la realidad

Los escenarios sintéticos son útiles para cobertura y regresión, pero no reemplazan la observabilidad en producción, el análisis de conversaciones reales, los informes de usuarios ni la investigación de incidentes.

3. Los jueces automáticos requieren calibración

Los veredictos automáticos pueden fallar, especialmente en políticas sutiles, dominios especializados o casos con mucho contexto. Es recomendable validar los criterios con conjuntos de referencia revisados por humanos.

4. La instrumentación importa

Para evaluar agentes complejos no basta con capturar la respuesta final. Si se quiere evaluar uso de herramientas, argumentos, trazas o pasos intermedios, el sistema debe exponer esa información de forma adecuada.

5. Es un proyecto open source en evolución

ASSERT es un proyecto abierto. Como cualquier herramienta en evolución, sus APIs, comandos, formatos y capacidades pueden cambiar. En un entorno de producción conviene fijar versiones, revisar cambios y no depender de comportamientos no documentados.

6. No reemplaza procesos regulatorios o de cumplimiento

ASSERT puede aportar evidencia técnica, pero no sustituye revisiones legales, auditorías formales, controles de seguridad, validaciones regulatorias ni procesos internos de aprobación.

Recomendaciones prácticas para adoptarlo

Si un equipo quiere probar ASSERT en un agente real, una adopción gradual suele ser más efectiva que intentar cubrirlo todo desde el primer día.

Elegir un comportamiento crítico y acotado
Por ejemplo: uso correcto de una herramienta, respeto de una política de rechazo o cumplimiento de restricciones de presupuesto.
Escribir una especificación clara
La especificación debe incluir comportamientos esperados, comportamientos prohibidos y ejemplos de fallos.
Revisar la taxonomía generada
No conviene delegar completamente esta parte. La taxonomía debe reflejar lo que realmente importa al producto y al negocio.
Ejecutar contra una versión estable del agente
Usar esa primera ejecución como línea base.
Incorporarlo a cambios relevantes
Repetir evaluaciones cuando se modifiquen prompts, modelos, herramientas o lógica de orquestación.
Comparar resultados con revisión humana
Especialmente al principio, conviene revisar muestras de aciertos y fallos para calibrar confianza.

Conclusión

El valor de ASSERT está en hacer sistemático algo que en muchos equipos sigue siendo ad hoc: pasar de una especificación escrita a una evaluación ejecutable, trazable y repetible.

Para equipos que construyen agentes, copilots o aplicaciones LLM con requisitos de comportamiento definidos, puede ser útil en tres momentos: durante el desarrollo, para validar comportamiento antes de producción; después de cambios, para detectar regresiones; y en revisiones técnicas, para aportar evidencia sobre dónde el sistema cumple y dónde falla.

Bien usado, ASSERT ayuda a cambiar la conversación de “creemos que el agente se comporta bien” a “tenemos evidencia revisable de qué comportamientos cumple, cuáles no y en qué condiciones”.