AWS muestra cómo evaluar agentes de IA en 3 modos: de la depuración a producción

Un cliente pidió el reembolso de un pedido y una explicación de cómo cancelar su suscripción. El agente tramitó el reembolso, se despidió con cortesía y se olvidó de la suscripción. La velocidad de respuesta era buena, al igual que el tono. Pero, para el cliente, la tarea seguía sin resolverse por completo. En un nuevo artículo, AWS explica cómo detectar estos fallos con Amazon Bedrock AgentCore Evaluations: evaluar las acciones individuales del agente y el resultado de toda la conversación, y después utilizar esas comprobaciones antes del lanzamiento y con tráfico real.

Se trata de un análisis práctico de las capacidades del servicio. Su valor está en vincular la evaluación del agente con el trabajo concreto por el que paga una empresa. El propio artículo no ofrece fundamentos para afirmar que las comprobaciones descritas mejoren la calidad en un porcentaje determinado o garanticen la prevención de errores.

Primero, define qué se considera un trabajo terminado

AWS propone empezar por el resultado de negocio. En soporte, puede ser resolver una consulta en un solo contacto. Para un agente de investigación, una respuesta completa con fuentes y basada en los documentos encontrados. Después, hay que desglosar ese resultado en acciones observables: el agente atendió todas las peticiones, conservó los detalles importantes de la conversación, eligió la herramienta adecuada y le pasó los parámetros correctos.

Volvamos al reembolso. Aquí resultan útiles tres comprobaciones independientes. GoalSuccessRate evalúa si se alcanzó el objetivo a lo largo de toda la sesión. ConversationCompleteness, de DeepEval, ayuda a detectar la pregunta olvidada sobre la suscripción. PIILeakage comprueba si el agente reveló datos personales. Que el reembolso se haya completado correctamente no dice nada, por sí solo, sobre los otros dos resultados.

El alcance de la evaluación también importa. La corrección de los argumentos de una llamada a una herramienta puede evaluarse en una acción concreta. Para saber si el agente respondió a todas las preguntas, hace falta toda la conversación. Si solo se examina la última respuesta, algunos errores quedan fuera de vista.

Un conjunto de comprobaciones para tres modos

AgentCore ofrece evaluadores integrados de AWS, comprobaciones gestionadas de DeepEval y AutoEval, y opciones personalizadas. Los evaluadores integrados cubren la calidad de las respuestas, la ejecución de tareas, el uso de herramientas y otros comportamientos. En el modo gestionado de comprobaciones de terceros, el servicio aloja el código, selecciona el modelo evaluador y ejecuta las solicitudes en su propia infraestructura. Las opciones personalizadas permiten cambiar el modelo, las instrucciones y los criterios de evaluación.

Se pueden ejecutar de tres maneras. Durante la depuración, el desarrollador envía una sesión registrada a la API y recibe una evaluación con una explicación. Antes del lanzamiento, el equipo ejecuta un conjunto fijo de conversaciones para observar los efectos de cambiar el prompt o el modelo. En producción, el servicio evalúa una proporción determinada del tráfico real. En los tres modos se utilizan los mismos identificadores de evaluadores.

También es posible evaluar varios criterios con una sola llamada al modelo. Por ejemplo, comprobar por separado la resolución de la consulta, el cumplimiento de las reglas de reembolso y el tono profesional. Los resultados se devuelven para cada criterio, sin una puntuación global agregada. Esto permite establecer requisitos de lanzamiento independientes: una mejora del tono no debe compensar una infracción de las políticas.

Conviene combinar comprobaciones cuando necesitan los mismos datos y el mismo modelo. Si un criterio requiere una respuesta de referencia y otro puede evaluarse a partir de una conversación real, resulta más práctico mantenerlos separados.

Dónde están los límites de la evaluación automática

Algunas comprobaciones requieren una respuesta correcta conocida de antemano o una secuencia esperada de llamadas a herramientas. Según la descripción de AWS, estas comprobaciones están disponibles en el modo por lotes: en el tráfico real normalmente no existe una respuesta de referencia. Por eso, el conjunto de pruebas previo al lanzamiento y la monitorización en producción cumplen funciones distintas, aunque utilicen un catálogo común.

Otra limitación es el propio modelo evaluador. Su puntuación debe contrastarse con lo que el equipo considera un éxito. En el caso de los reembolsos, resulta útil comparar la evaluación de la conversación con el resultado real de la operación en el sistema de pedidos. Una buena explicación del modelo no confirma que el dinero se haya devuelto realmente.

Un punto de partida práctico para el equipo es elegir dos o tres tipos de fallos relevantes y recopilar conversaciones en las que se manifiesten. Después, comprobar si los evaluadores los detectan y, solo entonces, activar la monitorización del tráfico. AWS no incluye cálculos de costes ni de ahorro en este artículo. Cada equipo tendrá que evaluar el presupuesto de las comprobaciones y la confianza que merece su resultado a partir de sus propias sesiones.