Los agentes de ventas de AWS estaban sanos y financieramente equivocados. La solución: evaluar en cada release

A un agente de AWS se le pidieron los ingresos de un cliente durante tres meses. La cifra en los datos era $410.08. El agente la reportó como “$410.08 Million”.

No se disparó ninguna alerta. El agente respondió, la latencia era normal y todos los dashboards seguían en verde, porque los dashboards medían si el agente respondía, no si la respuesta era correcta.

Ese ejemplo abre un relato de ingeniería inusualmente sincero que AWS publicó el 16 de octubre sobre el sistema multiagente que su equipo de operaciones de Sales, Marketing and Global Services construyó para vendedores de campo. Los vendedores hacen preguntas en inglés sencillo a través de Amazon Quick; los subagentes gestionan insights de rendimiento, insights de clientes y text-to-SQL sobre datos de ventas, con respuestas acotadas al territorio y al rol de cada usuario. El post enumera los otros fallos que originaron el trabajo: Sales Revenue etiquetado como Sales Revenue excluding Adjustments, una estimación de ingresos recurrentes anuales que no aparecía en ningún lugar de los datos, y los cálculos del propio agente presentados como hechos con fuente.

Lo útil no es que AWS evalúe a sus agentes. Es dónde se sitúa cada control.

«Correcto» se define antes de probar nada

La primera de las nueve etapas de AWS define la calidad: resultados de negocio mapeados a métricas y umbrales, presupuestos de latencia y costo, y seis tipos concretos de fallo de precisión. Las plantillas de evaluador integradas en Amazon Bedrock AgentCore no cubrían esos tipos de fallo, así que el equipo escribió evaluadores personalizados para ellos.

El orden importa. Muchos equipos empiezan con un juez LLM genérico que puntúa la utilidad y luego descubren que los fallos que cuestan dinero, como un error de unidades en los ingresos, no son lo que el juez buscaba. La taxonomía de fallos es el diseño de la evaluación; las herramientas vienen después.

Comprobaciones deterministas donde la respuesta se conoce, jueces donde no

Las comprobaciones deterministas verifican hechos con respuestas conocidas: ingresos, fechas de renovación, estado del contrato, si se resolvió la entidad de cliente correcta. Un juez LLM puntúa lo que no tiene una única respuesta correcta, como la relevancia, la fidelidad y la calidad del razonamiento. AWS también ejecuta evaluadores de terceros de DeepEval y AutoEval.

Esa división es la correcta. Un modelo juez al que se le pregunta si “$410.08 Million” es fiel a una tabla puede notar el problema o no; una comparación con el data warehouse sí lo hará. Como mostró la investigación de Anthropic sobre recompensar a los auditores de IA, un evaluador modelo es un componente con su propia tasa de error.

1. Fundamento: definir la calidad y los tipos de fallo
2. Experimento: comparar versiones
3. Merge: conjunto centinela en cada despliegue en staging
4. Gate: conjunto golden completo con respuestas de herramientas congeladas
5. Canario: evaluación programada en producción
6. Adversario: guardrails en entradas y salidas
7. Deriva: muestrear tráfico real, A/B antes del despliegue gradual
8. Pulso: trazas, alarmas, dashboards
9. Feedback: los fallos se convierten en casos de prueba

• Antes del release: Fundamento: definir la calidad y los tipos de fallo · Experimento: comparar versiones · Merge: conjunto centinela en cada despliegue en staging · Gate: conjunto golden completo con respuestas de herramientas congeladas
• En producción: Canario: evaluación programada en producción · Adversario: guardrails en entradas y salidas · Deriva: muestrear tráfico real, A/B antes del despliegue gradual · Pulso: trazas, alarmas, dashboards
• De vuelta al desarrollo: Feedback: los fallos se convierten en casos de prueba

Donde la mayoría de los equipos invierte de menosLo que atrapa fallos que nadie envió

La ventana del 38%

Un hallazgo merece un lugar en la pared de cada equipo de plataforma. En una prueba de preproducción, un cambio de datos, un cambio de herramienta y una actualización de prompt correspondiente debían salir juntos y, en cambio, llegaron en momentos distintos. Durante el desajuste, la tasa de aprobación cayó del 78% al 38%. Ningún componente estaba roto. La combinación sí.

Un release de agente no es un prompt. Es el prompt, las definiciones de herramientas, el código de las herramientas, los datos que leen las herramientas y el modelo, y tienen que versionarse y promoverse como una sola unidad. Si su proceso permite que el equipo de prompt despliegue el martes y el equipo de datos el jueves, la ventana del 38% está incorporada.

Canarios que alertan por persistencia, no por ruido

En producción, la evaluación se ejecuta en ventanas de 30 minutos que recorren el conjunto golden a lo largo de unas 24 horas, con una ejecución diaria completa como scorecard oficial. El equipo probó 15 y 60 minutos antes de quedarse con 30. Solo se alerta al equipo de guardia tras tres ventanas consecutivas que incumplen, porque las alertas de una sola ventana erosionaban la confianza.

Los canarios atrapan lo que la preproducción no puede: una tabla upstream cambia su definición y un agente que ayer pasó todas las puertas hoy está equivocado. Es la misma razón por la que un agente puede devolver un 200 y seguir estando equivocado. El conjunto golden se alimenta de tres lugares: consultas de producción muestreadas, incluidas sesiones en vivo con baja puntuación; casos de regresión de fallos pasados; y casos límite sintéticos. Cada fallo se convierte en una prueba.

Lo que dicen los números y lo que no

AWS reporta que su tasa de aprobación subió del 93% a un 96% estable en tres meses, que las alucinaciones puras cayeron de 138 a menos de 52 por cada 10,000 respuestas, que los cálculos no autorizados cayeron de 59 a menos de 44, y que el tiempo medio de detección bajó de días o semanas a menos de cuatro horas. Son cifras de AWS para su propio sistema, y el post marca varios de sus gráficos como ilustrativos.

Lea el 96% con cuidado: cuatro respuestas de cada cien siguen fallando una comprobación. El pipeline no hace que el agente sea correcto; hace que los errores sean visibles en horas y convierte cada uno en una prueba. Para un asistente de analítica cuyas respuestas lee un vendedor antes de actuar, eso puede ser aceptable. Para un agente que escribe en un sistema de registro, la misma tasa de aprobación necesita un control distinto delante de la escritura: aprobación.

Nada de esto requiere AgentCore. Requiere a alguien que sea dueño de lo “correcto” como métrica operativa, igual que alguien ya es dueño del uptime, y un proceso de release que se niegue a enviar medio agente.