Raft explica cómo evaluar agentes de IA antes de ponerlos en procesos de trabajo

Raft ha publicado un análisis práctico sobre cómo las empresas pueden comprobar la fiabilidad de los agentes de IA antes de confiarles procesos de negocio reales. La idea central del artículo es sencilla: no se puede creer en un agente por una demostración o por un porcentaje medio de éxito; hay que pasarlo con regularidad por evals con criterios claros.

Por qué la confianza no basta

A medida que los sistemas basados en agentes pasan de los experimentos a escenarios de trabajo, las empresas se plantean una pregunta perfectamente racional: ¿qué hacer si el agente se equivoca, infringe las reglas o empieza a actuar de forma extraña? Con una persona se puede analizar el incidente, cambiar la motivación e introducir controles. Con la IA eso no funciona. El modelo no tiene incentivos propios para comportarse «correctamente», así que la confianza en él no puede basarse en sensaciones, en promesas del proveedor ni en un solo piloto exitoso.

Los autores proponen entender la confianza como repetibilidad del resultado. Si un sistema recibe muchas veces datos de entrada similares y ofrece de forma estable el resultado esperado, se le pueden encargar tareas de esa clase. Si, en cambio, hay que revisar manualmente cada acción, el valor de la automatización desaparece enseguida. Por eso los evals no son aquí analítica adicional, sino el mecanismo básico para admitir a un agente en el trabajo.

Cómo montar un eval set

El punto de partida es un ground truth set: un conjunto de casos reales o lo más cercanos posible a la realidad, en el que los datos de entrada se vinculan con el resultado esperado. Normalmente se construye a partir de tareas históricas que el equipo ya procesó a mano. El artículo subraya que para los evals no hacen falta miles de ejemplos, como en el ajuste fino. Importa más que cada caso sea inequívoco: dos expertos independientes deberían responder igual sobre si el agente superó la prueba o no.

Un eval set típico consta de varias capas:

• tareas con datos de entrada concretos y un criterio de éxito
• una ejecución de prueba del agente con su resultado final
• uno o varios graders para distintos aspectos de la calidad
• una transcripción de los pasos: llamadas a herramientas, acciones intermedias y lógica de la ruta

Como ejemplo, Raft describe un agente de soporte de una tienda online que gestiona devoluciones. Un caso comprueba una devolución sencilla dentro de los 30 días; otro, el rechazo de una solicitud fuera de la política; y un tercero, una situación ambigua en la que no se puede ni devolver el dinero automáticamente ni rechazar sin pedir aclaraciones. Este diseño muestra algo importante: hay que evaluar no solo la respuesta final, sino también el comportamiento durante el proceso. A veces el mejor resultado no es una acción, sino una escalada correcta a un humano.

Para las comprobaciones se pueden combinar tres enfoques. Los graders deterministas sirven donde importan señales exactas, como el importe de la devolución o la llamada a la herramienta correcta. Los jueces LLM son útiles para valorar el tono, la exhaustividad y la claridad de la respuesta. Las personas hacen falta al principio para reunir datos de referencia y calibrar a los evaluadores automáticos; de lo contrario, el sistema empezará pronto a medir lo que resulta cómodo y no lo que de verdad importa al negocio.

Qué métricas mirar

El artículo hace especial hincapié en que los sistemas de agentes no son deterministas. Por eso carece de sentido comprobar de forma rígida cada paso: un mismo buen resultado puede alcanzarse por rutas distintas. Aun así, la ruta importa, porque consume tiempo, tokens y acceso a herramientas, y además puede infringir políticas internas. Un buen eval debe responder a dos preguntas a la vez: si el resultado es correcto y si el camino fue razonable.

Un 95% de aprobados suena estupendo, hasta que los errores se

concentran en los falsos positivos.

Por eso el pass rate por sí solo no basta. Para decisiones binarias conviene mirar la matriz de confusión, la precision, el recall y el F1, porque los distintos tipos de error cuestan al negocio de forma diferente. Un agente que aprueba devoluciones con demasiada facilidad crea una categoría de riesgo; uno que rechaza en masa solicitudes legítimas crea otra muy distinta.

Además, los autores recuerdan las trampas habituales: la ley de Goodhart, la obsolescencia del eval set y la ilusión del panel «en verde», cuando la métrica parece normal mientras crecen las quejas reales de los usuarios.

Qué significa

Para las empresas que quieren implantar agentes de IA en soporte, operaciones o desarrollo, la conclusión principal es una: primero hay que construir el sistema de verificación y solo después escalar la automatización. No ganan los equipos cuyo agente parece más inteligente en la demo, sino los que entienden el coste de sus errores, saben medir la calidad por escenarios y actualizan con regularidad los evals junto con el producto.