Todo equipo que construye agentes choca con el mismo muro. El prototipo funciona en la laptop del ingeniero, falla en la demostración, falla de otra forma el lunes siguiente y el equipo termina discutiendo prompts en Slack. La solución no es glamorosa: un conjunto de evaluaciones automatizadas, escrito antes de que el agente haga algo útil.
Qué significa aquí «evaluaciones»
Una evaluación es un caso de prueba congelado que el agente debe superar: una entrada, el comportamiento esperado y un resultado calificado. Es la prueba unitaria de un sistema con LLM. La función de calificación puede ser de coincidencia exacta, de igualdad estructurada o de otro LLM como juez, la que mejor modele el resultado real que le importa.
- Conjunto de casos de referencia: entradas que representan la distribución real, tomadas de tráfico de producción siempre que sea posible.
- Calificador: una verificación determinista (preferible) o un LLM como juez con una rúbrica muy acotada.
- Umbral de regresión: la versión del agente que hoy está en producción. Nada que quede por debajo de ese umbral se despliega.
- Segmento: subconjuntos del conjunto de referencia que se califican por separado, por cliente, por tipo de documento o por idioma. Los promedios globales esconden los errores que importan.
Por qué importa el orden
Escribir las evaluaciones después del agente es la forma más cara de hacerlo. El equipo queda atado a una arquitectura específica, las métricas se acomodan para favorecerla y cada cambio de prompt se convierte en un debate sin datos. Escribir las evaluaciones primero invierte el ciclo: cada cambio recibe un número, el número es comparable entre corridas y el equipo discute con evidencia en lugar de preferencias.
Cómo se ve un conjunto de pruebas útil en la práctica
Nuestro conjunto de referencia son dos scripts y un CSV. Un script ejecuta el agente sobre todos los casos, captura la traza (prompt, herramientas invocadas, resultado, costo, latencia) y escribe una fila por caso. El segundo calcula aprobados y fallidos por segmento y en total, y publica la diferencia frente a la corrida anterior en un canal de Slack. El consumo de tokens, la latencia y el costo en dólares son métricas de primer nivel, y las regresiones del modelo aparecen ahí antes de aparecer en quejas de clientes.
Dónde poner el límite de cobertura
Más evaluaciones no siempre es mejor. Construya hasta que la tasa global de aprobación deje de ser una señal útil y entonces empiece a dividir en segmentos. El objetivo es detectar regresiones de forma confiable, no recorrer por fuerza bruta todo el espacio de entradas. La meta es un conjunto lo bastante rápido para correr con cada cambio de prompt, no un benchmark que tarda toda la noche.
Cómo cambia esto el proyecto
Cuando existen las evaluaciones, la ingeniería de agentes se vuelve ingeniería ordinaria. Las ediciones de prompt reciben una métrica. Los cambios de modelo reciben una métrica. Las nuevas integraciones de herramientas reciben una métrica. El equipo entrega más rápido porque cada cambio es reversible: si empeora en la evaluación, nunca llega a producción.
“Si no puede decirme si el prompt de la semana pasada era mejor que el de esta semana, no está construyendo un sistema, está retocando una demostración.”