Un benchmark es un conjunto de escenarios de evaluación reproducidos automáticamente contra un pipeline. Es la herramienta para medir objetivamente la calidad de un agente y detectar las regresiones antes de que lleguen a producción.
Por qué
Un agente que «parecía funcionar» puede sufrir una regresión silenciosa tras:
- un cambio de misión;
- un cambio de modelo LLM;
- la incorporación de un nuevo tool.
Sin benchmark, lo descubres en producción. Con un benchmark, lo ves en la siguiente ejecución — antes que tus usuarios.
Anatomía de un escenario
Un escenario contiene:
- Un estímulo — la entrada que recibe el pipeline (mensaje o secuencia de turnos, fixtures de datos).
- Checks — aserciones explícitas evaluadas en cada turno: la salida producida, la forma de la respuesta, la cadena de llamadas a tools, el coste de las acciones.
Catálogo de checks
| Check | Verifica |
|---|---|
pipeline_output_match | Una clave del flujo de salida corresponde al valor esperado (ruta + aserción) |
response_shape | La forma de la respuesta del agente (longitud, estructura), medida sin juez |
llm_rubric | El fondo de la respuesta, puntuado por un juez LLM según una rúbrica de criterios verificables |
tool_chain_analysis | La secuencia de llamadas a tools sigue la estrategia esperada |
tool_cost | El presupuesto de acciones: cada llamada tiene un coste, alcanzar el objetivo otorga un bonus |
static / tests / diff_quality | Checks orientados a archivos y código (salida de un pipeline de desarrollo) |
El catálogo es extensible del lado de la plataforma: cada check es un plugin registrado del lado del servidor.
Crear un benchmark
- Aplicaciones → Évaluation → Scénarios.
- Crea los escenarios (estímulo, checks, fixtures de datos); cada escenario está dedicado a un modelo (el pipeline de destino). Las fixtures se gestionan en la pestaña Fixtures.
Un escenario también puede crearse o modificarse mediante una propuesta desde el servidor MCP (benchmark_create / benchmark_update), que queda pendiente hasta su aceptación.
Un buen benchmark incluye una mezcla: caso nominal, casos límite, casos adversariales (intentos de manipulación, ambigüedad, datos ausentes).
Ejecutar un benchmark
Desde el panel de administración, lanza una ejecución (run): se pone en una cola duradera y la ejecuta un worker dedicado, fuera del servidor web. Si ese worker se detiene en mitad de una ejecución, esta se marca fallida al reiniciar (no se reanuda automáticamente): vuelve a lanzarla. Un drawer da el detalle por escenario.
El informe muestra:
- Tasa de éxito por check
- Evolución de las puntuaciones entre ejecuciones (pestañas Historique y Évolution)
- Lista de los escenarios fallidos, con el detalle de cada check
Buenas prácticas
- Empieza pequeño — 5 escenarios bien orientados valen más que 50 escenarios aproximados.
- Haz benchmark antes de cada publicación, y compara con la ejecución anterior antes de desplegar.
- Versiona las misiones. No solo los pipelines: las misiones también evolucionan.
- Mantén los checks legibles. Un check que requiere 20 líneas de explicación para entenderse es un check que hay que descomponer.