Raft muestra cómo las empresas pueden evaluar agentes de IA antes de implementar en flujos de trabajo

Raft publicó un análisis práctico de cómo las empresas pueden verificar la confiabilidad de agentes de IA antes de confiarles procesos comerciales reales. La idea principal del artículo es simple: un agente no puede ser confiado por una demostración o una tasa promedio de éxito — necesita ser ejecutado regularmente a través de evals con criterios claros.

Por qué hay poca confianza

Conforme los sistemas de agentes transicionan de experimentos a escenarios de trabajo, el negocio enfrenta una pregunta racional: qué hacer si el agente comete errores, viola reglas o comienza a comportarse de forma extraña. Con un humano, puedes analizar el incidente, cambiar la motivación e introducir controles. Con IA, esto no funciona.

Un modelo no tiene incentivos inherentes para comportarse "correctamente", por lo que la confianza en él no puede construirse en sentimientos, promesas del proveedor o un único piloto exitoso. Los autores proponen ver la confianza como reproducibilidad de resultados. Si un sistema recibe consistentemente datos de entrada similares y produce de forma confiable el resultado esperado, puede ser confiado con esa clase de tareas.

Si toda acción requiere verificación manual, el valor de la automatización desaparece rápidamente. Por lo tanto, evals aquí actúan no como análisis adicional, sino como mecanismo básico de autorización de un agente para trabajar.

Cómo construir un eval set

El punto de partida es un ground truth set: una colección de casos reales o lo más cercanos posible a la realidad, donde los datos de entrada están vinculados al resultado esperado. Normalmente tal conjunto se compila a partir de tarefas históricas que el equipo ya ha procesado manualmente. El artículo enfatiza específicamente que evals no requieren miles de ejemplos como el fine-tuning requiere. Lo que importa más es que cada caso sea inequívoco: dos expertos independientes deben responder de la misma forma si el agente pasó la verificación o no. Un eval set típico consta de varias capas:

• tareas con datos de entrada específicos y criterios de éxito
• ejecuciones de prueba del agente con resultados finales
• uno o más graders para diferentes aspectos de calidad
• transcripción de pasos: llamadas de herramientas, acciones intermedias y lógica de enrutamiento

Como ejemplo, Raft describe un agente de soporte de comercio electrónico que procesa devoluciones. Un caso prueba una devolución simple dentro de 30 días, otro prueba un rechazo para una solicitud fuera de política, un tercero prueba una situación ambigua donde no puedes ni reembolsar automáticamente ni simplemente rechazar sin aclaración. Este diseño muestra algo importante: necesitas evaluar no solo la respuesta final, sino también el comportamiento en el camino hacia ella.

A veces el mejor resultado no es una acción, sino escalación correcta a un humano. Para las propias verificaciones, se pueden mezclar tres enfoques. Los graders determinísticos funcionan donde importan señales precisas, como montos de reembolso o invocaciones de herramientas.

Los jueces de LLM son útiles para evaluar tono, completitud y claridad de la respuesta. Los humanos son necesarios al inicio para recopilar datos de referencia y calibrar evaluadores automatizados, de lo contrario el sistema rápidamente comenzará a medir lo que es conveniente en lugar de lo que realmente importa al negocio.

Qué métricas observar

Un énfasis separado en el artículo es el hecho de que los sistemas de agentes son no-determinísticos. Por lo tanto, verificar rígidamente cada paso no tiene sentido: el mismo buen resultado puede lograrse a través de diferentes caminos. Pero el camino aún importa porque consume tiempo, tokens y acceso a herramientas, y también puede violar políticas internas.

Un buen eval debe responder dos preguntas a la vez: ¿es correcto el resultado y fue el camino hacia él razonable? Una tasa de éxito del 95% suena genial — hasta que los errores sean false positives. Por eso solo pass rate es insuficiente.

Para decisiones binarias, es útil mirar confusion matrix, precision, recall y F1, porque diferentes tipos de errores cuestan al negocio de formas diferentes. Un agente que aprueba devoluciones demasiado fácilmente crea una categoría de riesgo; un agente que rechaza masivamente solicitudes legítimas crea una completamente diferente. Además, los autores recuerdan sobre trampas típicas: ley de Goodhart, obsolescencia de eval set e ilusión de un dashboard "verde", cuando la métrica se ve bien pero quejas reales de usuarios crecen.

Qué significa

Para empresas que desean desplegar agentes de IA en soporte, operaciones o desarrollo, la conclusión principal es una: primero necesitas construir un sistema de verificación, y solo después escalar automatización. Los equipos ganadores no son aquellos cuyo agente se ve más inteligente en una demostración, sino aquellos que entienden el costo de sus errores, pueden medir calidad contra escenarios y regularmente actualizan evals junto con el producto.