Probar un agente de IA no es probar software ni evaluar un modelo con benchmarks. Un agente recorre un camino que cambia entre ejecuciones, asi que la unica medicion con sentido es una distribucion: la misma tarea, las mismas condiciones, veinte ejecuciones, cuantas terminaron correctamente. La aritmetica es simple y brutal: un agente con un 95% de precision en cada paso completa correctamente solo alrededor del 60% de las tareas de diez pasos. Un montaje de evaluacion que funciona tiene cuatro partes: un conjunto de casos tomado del mundo real, medicion en cuatro niveles, una ejecucion de regresion en cada cambio y monitorizacion en produccion.
Por que las pruebas de software habituales no sirven aqui
Las pruebas de software convencionales asumen determinismo: la misma entrada produce la misma salida, asi que basta con cubrir los caminos. En un agente esa suposicion no se sostiene. La misma entrada puede producir un camino distinto, un orden de herramientas distinto y un resultado distinto, no por un error sino por como funciona el modelo.
Asi que la pregunta de prueba cambia. En lugar de pasa o no pasa, la pregunta es con que frecuencia lo consigue y a que distancia esta el peor fallo de la media. Los equipos que se queman son los que vieron una demo exitosa, concluyeron que el sistema funciona y descubrieron en produccion que la demo era la mejor ejecucion de cinco.
La aritmetica que lo explica casi todo
Un agente ejecuta una tarea como una cadena de pasos. Si cada paso es independiente, la tasa de exito de la tarea es el producto de las probabilidades. Parece trivial hasta que pones numeros.
| Precision por paso | Tarea de 5 pasos | 10 pasos | 20 pasos |
|---|---|---|---|
| 90% | 59% | 35% | 12% |
| 95% | 77% | 60% | 36% |
| 98% | 90% | 82% | 67% |
| 99% | 95% | 90% | 82% |
De ahi se siguen dos conclusiones operativas. Primera: acortar la tarea vale mas que mejorar el modelo. Pasar de veinte pasos a diez con una precision del 95% casi duplica la tasa de exito, del 36% al 60%. Segunda: las cadenas largas exigen una precision por paso muy dificil de alcanzar, asi que las tareas largas piden puntos de control y validacion intermedia en lugar de un unico bucle continuo.
Esta es tambien la razon por la que las tareas inusualmente largas siguen fallando la mayor parte de las veces incluso con los mejores modelos disponibles. Dividir el trabajo en subtareas con validacion intermedia no es un compromiso de ingenieria: es la unica via que permiten las matematicas.
Como construir un conjunto de casos que ensene algo
Un conjunto de pruebas escrito por quien construyo el agente fallara en produccion, porque refleja lo que el desarrollador imagino. El conjunto correcto viene de tres fuentes.
| Tipo de caso | De donde sale | Cuanto |
|---|---|---|
| Camino feliz | Las ultimas veinte solicitudes atendidas manualmente | ~40% del conjunto |
| Casos limite reales | Reclamaciones, reembolsos, casos que exigieron escalado | ~40% del conjunto |
| Casos adversarios | Intentos de inyeccion, entrada faltante, contradicciones, peticiones fuera de alcance | ~20% del conjunto |
Cada caso necesita una condicion de exito definida de antemano. No una puntuacion subjetiva, sino una condicion comprobable: el campo se actualizo al valor correcto, el correo fue a la direccion correcta, el total coincide con el calculo manual, o el agente se nego a actuar y escalo. Un caso sin condicion de exito no es un caso de prueba, es una impresion.
Un tamano inicial razonable: de 40 a 80 casos, cada uno ejecutado entre cinco y diez veces. Suena a mucho, pero son unos minutos de ejecucion y unos pocos dolares de coste, frente a un cliente que recibio una respuesta equivocada.
Cuatro niveles de medicion
Medir solo el resultado oculta la causa. Un montaje util mide cuatro niveles en paralelo.
| Nivel | Que se mide | Que revela |
|---|---|---|
| Resultado | Si se cumplio la condicion de exito | Si el sistema supera el umbral de negocio |
| Camino | El orden de herramientas elegido y el numero de pasos | Donde empieza a desviarse el agente, antes de que se rompa el resultado |
| Herramienta | Tasa de llamadas con argumento erroneo o herramienta inadecuada | Que descripciones de herramientas hay que arreglar |
| Coste | Tokens, llamadas y tiempo por tarea | Si la solucion es economica a escala |
El nivel de camino es el mas importante para depurar. El error de un agente suele aparecer lejos de donde se creo, asi que sin un registro completo de cada llamada y cada resultado no hay forma de encontrar el paso que inicio la desviacion.
Regresion: que rompe un agente que nadie toco
Un agente es uno de los pocos sistemas que puede romperse sin que nadie cambie una linea dentro de el. Hay tres causas principales.
Actualizacion del modelo. El proveedor publica una version nueva y el comportamiento cambia, normalmente mejor en promedio y peor en casos concretos que estaban calibrados para la version anterior. Toda mejora de modelo exige, por tanto, una ejecucion completa del conjunto antes de cambiar.
Cambio en el esquema de una herramienta. Un campo anadido, un nombre cambiado, un valor por defecto nuevo. El agente no se caera: seguira llamando a la herramienta como era correcto ayer.
Deriva de los datos. La forma de las solicitudes entrantes cambia con el tiempo, aparecen productos nuevos, cambia la forma de expresarse de los clientes. Un conjunto de pruebas de hace un ano esta probando un mundo que ya no existe.
Una regla de trabajo simple: el conjunto se ejecuta automaticamente en cada cambio del prompt, de las herramientas o del modelo, y se refresca trimestralmente a partir del trafico real.
Monitorizacion en produccion: lo unico que mide la verdad
El conjunto mide lo que se te ocurrio probar. La produccion mide lo que ocurre. Con cuatro metricas basta para detectar a tiempo casi cualquier problema.
Tasa de finalizacion. La proporcion de tareas que terminaron sin intervencion humana y sin fallo.
Tasa de escalado. Con que frecuencia el agente se detuvo y pidio un humano. Una subida brusca senala un cambio en la entrada; una caida brusca senala exceso de confianza.
Tasa de correccion. Con que frecuencia una persona cambio lo que el agente propuso. Es la metrica mas cercana a la calidad real.
Coste por tarea exitosa. No coste por llamada. Las tareas que fallan y se vuelven a ejecutar son el coste real.
La tasa de correccion es tambien la senal mas clara de si el punto de aprobacion esta en el lugar correcto. Si casi nadie corrige nada, la aprobacion se ha convertido en un sello de goma.
Una lista de comprobacion antes de que el agente toque a un cliente
Cada caso del conjunto tiene una condicion de exito inequivoca escrita antes de la ejecucion. Cada caso se ejecuta al menos cinco veces, y la metrica reportada es la estabilidad y no la mejor ejecucion. El conjunto incluye casos adversarios, incluidos intentos de inyeccion por cada canal de entrada. Existe un registro completo de llamadas a herramientas y resultados para cada ejecucion, almacenado y consultable. Se ha definido un umbral numerico de negocio para salir a produccion, en lugar de una sensacion de que ya esta bien. Y se ha definido un escenario de repliegue: que pasa cuando el agente falla y quien recibe la tarea.
Preguntas frecuentes
Que son las evaluaciones de un agente de IA?
Un montaje de pruebas que mide el comportamiento del agente sobre un conjunto de casos predefinido, cada caso a lo largo de varias ejecuciones, y reporta la distribucion de resultados en lugar de un unico exito. Cubre el resultado, el camino, el uso de herramientas y el coste.
Cuantos casos de prueba hacen falta?
Un conjunto inicial de 40 a 80 casos cubre la mayor parte del comportamiento de un agente de tarea unica, siempre que este repartido entre camino feliz, casos limite reales y casos adversarios. Mas importante que el numero de casos es el numero de ejecuciones por caso, que deberia ser al menos cinco.
Por que un agente que funcionaba en la demo falla en produccion?
Porque la demo midio una ejecucion en condiciones comodas. En produccion la tarea es mas larga, la entrada esta mas sucia y los errores se acumulan entre pasos. Un agente con un 95% de precision por paso completa correctamente solo alrededor del 60% de las tareas de diez pasos.
Se puede usar un modelo para juzgar al agente?
Si, pero solo como capa complementaria. El juicio automatizado encaja con medidas cualitativas como el tono o la completitud de la respuesta, no con condiciones de exito que se pueden comprobar de forma determinista. Todo caso verificable comparando valores deberia verificarse asi.
Cuando se ejecuta el conjunto de pruebas?
En cada cambio del prompt, de las herramientas o de la version del modelo, mas un refresco periodico del conjunto a partir del trafico real. Un agente puede romperse aunque nadie lo haya tocado, sobre todo tras una actualizacion de modelo o un cambio de esquema en una herramienta.