La métrica de evaluación de agentes de AWS para conversaciones multiturno expone el primer paso en falso

AWS presentó su Métrica de Evaluación de Agentes para conversaciones multiturno el 10 de septiembre de 2026, orientada a un tipo de fallo que las puntuaciones de respuesta final suelen ocultar. Un agente puede tomar una mala decisión, arrastrar el estado resultante durante varios turnos y terminar con una respuesta incorrecta. Un evaluador a nivel de tarea registra una conversación fallida. No identifica dónde comenzó el fallo.

La distinción importa porque los turnos posteriores pueden parecer defectuosos de forma independiente cuando simplemente consumieron información corrupta. Tratar cada turno fallido como un problema separado lleva a los ingenieros hacia varios síntomas en lugar de una sola causa. También puede hacer que una actualización de modelo parezca peor de lo que realmente es.

AWS llama AEM a su marco propuesto. La primera dimensión publicada mide la corrección mediante la veracidad y la integridad en cada turno de respuesta o acción. El debate más amplio enfrenta la puntuación basada solo en resultados con una evaluación que preserva la estructura causal de la trayectoria de un agente.

Ese debate se extiende más allá de AWS. AgentBench evaluó anteriormente agentes en ocho entornos interactivos, mientras que el tau-bench original examinó conversaciones que involucraban a usuarios, agentes, herramientas y reglas de dominio. Ambos ayudaron a desplazar la evaluación más allá de pares aislados de prompt y respuesta. AEM lleva el argumento hacia el diagnóstico a nivel de turno dentro de cada conversación.

AWS convierte una conversación fallida en un mapa de errores

El cambio importante no es otra puntuación. Es un método para separar el primer error de cada fallo que le sigue.

El marco AEM comienza con conversaciones anotadas que contienen respuestas y llamadas a herramientas esperadas. Evalúa cada turno frente a esa referencia, asigna un resultado de aprobado o suspenso y registra una razón específica cuando un turno falla. Después, esos resultados se combinan en una puntuación a nivel de conversación.

AWS ilustra el problema con una solicitud de informe de ventas de cinco turnos. Durante el turno dos, el agente elige la acción pertinente, pero proporciona “profit” cuando el parámetro esperado es “revenue”. Los turnos tres a cinco operan sobre el resultado incorrecto.

Un recuento convencional de fallos ve cuatro turnos rotos. AEM identifica una causa raíz en el turno dos y tres fallos en cascada. Los turnos posteriores reciben la etiqueta prior_action_failed, lo que indica que sus resultados son incorrectos porque dependen de un error anterior.

Esta atribución cambia la interpretación de ingeniería. Cuatro fallos podrían sugerir debilidades en varios prompts, herramientas o pasos de razonamiento. Un error raíz apunta a un problema específico de selección de argumentos.

AEM evalúa dos tipos de turnos bajo la misma jerarquía. Un turno de respuesta contiene el texto presentado a un usuario. Un turno de acción contiene una selección de herramienta y sus argumentos.

Para los turnos de respuesta, la integridad pregunta si la respuesta cubre todo lo requerido por la solicitud. La veracidad pregunta si sus afirmaciones se mantienen coherentes desde el punto de vista factual con la referencia. Para los turnos de acción, la integridad comprueba si están presentes todas las claves de parámetros requeridas. La veracidad comprueba si los valores proporcionados son semánticamente correctos.

Los turnos de acción también requieren validación estructural. El evaluador debe determinar si el agente eligió la herramienta y la acción correctas antes de juzgar los campos que se les pasan. Un objeto de argumentos perfectamente formateado no salva una llamada a la API equivocada.

La versión publicada trata la corrección de cada turno como binaria. Cada turno aprueba o falla, aunque AWS afirma que la misma descomposición puede admitir una calificación continua de afirmaciones o campos individuales. La puntuación general predeterminada es la proporción no ponderada de turnos aprobados.

Esa puntuación es solo el resultado superficial. El material útil se encuentra debajo: la dimensión fallida, el campo afectado, el primer turno fallido, el recuento de causas raíz, el recuento de cascadas y la longitud de la cadena. Por tanto, un panel puede mostrar que la corrección disminuyó e identificar al mismo tiempo si la veracidad o la integridad causaron el cambio.

Esta es la inversión central detrás de la Métrica de Evaluación de Agentes para conversaciones multiturno. Una puntuación menor no significa necesariamente que el agente haya generado muchos errores independientes. Puede significar que una decisión temprana contaminó una larga cadena de dependencias.

Las puntuaciones de resultados ocultan el fallo que los ingenieros necesitan corregir

Una puntuación de resultado responde si el flujo de trabajo tuvo éxito, mientras que la atribución por turno responde por qué falló. Los equipos de producción necesitan ambas respuestas.

La evaluación del estado final sigue siendo valiosa. Un agente de soporte emitió el reembolso correcto o no lo hizo. Un agente de investigación produjo un informe fundamentado o no lo hizo. Un agente de programación modificó la entrada de calendario prevista o cambió otra cosa.

El problema comienza cuando ese veredicto se convierte en todo el diagnóstico. Un estado final fallido puede ser consecuencia de una herramienta equivocada, un argumento ausente, un valor incorrecto, una respuesta incompleta o una acción previa cuyo mal resultado contaminó todo lo que vino después. Esas causas exigen correcciones diferentes.

Una discrepancia de herramienta puede apuntar a instrucciones de enrutamiento o descripciones de herramientas. Un parámetro ausente puede revelar ambigüedad en el esquema. Un valor incorrecto puede indicar una selección débil de contexto, razonamiento o datos de referencia. Una respuesta de usuario incompleta puede revelar un fallo de presentación incluso cuando todas las llamadas a herramientas tuvieron éxito.

Una puntuación holística fusiona esos defectos. También ofrece poca ayuda a los equipos al comparar versiones. Supongamos que un modelo nuevo produce la misma tasa de éxito en tareas que la versión anterior. Aun así, puede haber cambiado menos errores de selección de herramientas por más respuestas incompletas.

Ese intercambio importa en producción. Omitir un detalle secundario en un borrador de informe difiere de enviar una cantidad errónea a un sistema financiero. Puntuaciones agregadas iguales pueden ocultar riesgos desiguales.

La necesidad de una evaluación por capas ya aparece en todo el ecosistema de agentes. Una descripción reciente de la arquitectura de evaluación divide las pruebas en ejecuciones, trazas e hilos. Las ejecuciones abarcan operaciones individuales de modelo o herramienta. Las trazas abarcan un turno completo del agente, mientras que los hilos abarcan conversaciones multiturno.

Esa estructura complementa el argumento de AEM. La evaluación a nivel de conversación revela si el objetivo del usuario sobrevivió a toda la interacción. La evidencia a nivel de turno revela el momento y la dimensión en que el comportamiento se desvió.

Los benchmarks anteriores establecieron por qué el comportamiento interactivo merece su propia superficie de evaluación. La investigación de AgentBench probó 27 modelos en ocho entornos y asoció los fallos con el razonamiento a largo plazo, la toma de decisiones y el seguimiento de instrucciones. Esas propiedades emergen mediante la interacción, no a partir de una sola respuesta pulida.

El artículo de tau-bench fue más allá al simular conversaciones entre usuarios y agentes en entornos de comercio minorista y aerolíneas. Evaluó el estado resultante de la base de datos frente a un estado objetivo anotado y midió la consistencia en ensayos repetidos. Sus experimentos originales informaron que los principales agentes de llamadas a funciones completaban menos de la mitad de las tareas.

Estos benchmarks y AEM responden preguntas diferentes. Los benchmarks de estado final prueban si un agente alcanzó el resultado requerido en condiciones realistas. AEM ofrece una forma de inspeccionar qué turno rompió primero la corrección y cómo se propagó el daño.

Ninguna perspectiva debería sustituir a la otra. Un agente podría tomar una ruta inesperada pero válida y aun así alcanzar el estado correcto. Una comparación rígida de trayectorias podría penalizar esa flexibilidad. A la inversa, una respuesta final correcta podría ocultar una ruta insegura o inestable que logró recuperarse por casualidad.

La respuesta práctica es una puntuación por capas. Los equipos pueden conservar las comprobaciones de resultados para las decisiones de lanzamiento y luego usar dimensiones y trazas a nivel de turno para el diagnóstico. El orden estricto de las acciones debería aplicarse solo cuando la secuencia afecte a la corrección o la seguridad.

Esto también cambia quién siente presión por la propuesta de AWS. Los proveedores de evaluación y los equipos internos de plataforma deben ir más allá de un único porcentaje de éxito. Los desarrolladores de agentes deben mantener datos de referencia más ricos. Los responsables de producto deben decidir qué dimensiones merecen barreras independientes en lugar de aceptar un único número combinado de calidad.

Cómo la métrica de evaluación de agentes para conversaciones multiturno encuentra la primera ruptura

AEM funciona comparando cada turno dentro de su trayectoria completa, asignando un fallo tipificado y preservando las dependencias entre acciones.

El proceso comienza con un conjunto de datos dorado, es decir, un conjunto revisado de conversaciones que define el comportamiento esperado. Cada ejemplo necesita más que una respuesta final. Debe incluir contenido de respuesta correcto, herramientas esperadas, parámetros requeridos, valores válidos y dependencias entre turnos.

AWS recomienda la anotación humana, o la revisión humana cuando un modelo más potente ayuda a iniciar las referencias. Este requisito es considerable. Un evaluador descomponible no puede producir diagnósticos significativos cuando el registro de referencia subyacente es vago o incorrecto.

El evaluador primero establece el tipo de turno. Un turno de respuesta se juzga por cobertura y consistencia factual. Un turno de acción se juzga por la selección de herramienta, las claves requeridas y los valores semánticamente correctos.

AEM usa comparación semántica donde la coincidencia exacta de cadenas sería demasiado frágil. “NYC” y “New York City” pueden representar el mismo valor. “Third quarter revenue figures for 2024” puede coincidir con “Q3 2024 revenue” sin compartir una cadena idéntica.

El ejemplo conceptual de AWS sitúa un evaluador semántico detrás de un umbral configurable, con la coincidencia exacta como vía rápida. Una puntuación por encima del umbral aprueba. Una puntuación por debajo produce un fallo de veracidad.

La selección del umbral se convierte en una decisión de producto y no en una constante universal. Un evaluador estricto genera falsos fallos cuando una redacción inocua difiere. Uno flexible acepta valores que parecen relacionados, pero cambian el significado de la tarea.

Un asistente de calendario podría tratar “mañana por la tarde” como un intervalo que requiere aclaración. Un sistema de informes podría necesitar un período fiscal exacto. Un flujo de trabajo de cumplimiento normativo puede requerir identificadores literales. Un único umbral semántico no puede expresar la tolerancia al riesgo de todos los dominios.

La integridad tiene una dependencia similar del contexto. Los parámetros opcionales no deberían convertirse en fallos simplemente porque la trayectoria dorada los utilizó. Los campos requeridos deben distinguirse de los convenientes. De lo contrario, el evaluador recompensa la imitación de la referencia en lugar de la ejecución exitosa.

La taxonomía de fallos hace que esos juicios sean inspeccionables. AWS enumera categorías para discrepancias de herramienta o acción, parámetros ausentes o adicionales, valores de parámetros inconsistentes, respuestas incompletas y respuestas inconsistentes. Cada etiqueta se corresponde con una comprobación estructural o una de las submétricas de corrección.

Después, la atribución de dependencias separa los fallos originales de los heredados. Un turno recibe prior_action_failed solo cuando habría aprobado con información previa correcta. Esa condición es importante. Un turno posterior puede contener un nuevo error independiente incluso después de un fallo anterior.

Consideremos un agente de investigación que recupera el documento equivocado en el turno dos. Luego resume correctamente ese documento en el turno tres. El turno tres es incorrecto respecto al objetivo del usuario, pero su transformación local puede ser válida. AEM debería marcar la decisión de recuperación como la causa raíz y el resumen como un fallo heredado.

Ahora supongamos que el cuarto turno inventa una estadística ausente del documento recuperado. Esa alucinación no es meramente heredada. Introduce otra causa raíz, aunque la trayectoria ya estuviera corrompida.

Por tanto, una atribución fiable requiere una lógica explícita de dependencias. Etiquetar simplemente cada turno posterior al primer error como una cascada subestimaría los fallos independientes. El valor de AEM depende de que los evaluadores puedan distinguir el estado heredado de los errores nuevos.

El marco también registra la longitud de la cadena de acciones. AWS agrupa las cadenas en llamadas únicas, secuencias de dos pasos y secuencias complejas de al menos tres pasos. Las cadenas más largas crean más oportunidades para que un defecto temprano influya en el trabajo posterior, lo que hace más útil la atribución de causas raíz.

Una vez calculada, la salida estructurada puede alimentar paneles y comprobaciones de regresión. Los equipos pueden comparar versiones de modelos según la tasa global de éxito, la dimensión de corrección, el tipo de causa raíz y la longitud de la cadena. Así, una versión puede fallar porque aumentaron las discrepancias en las herramientas, incluso si una puntuación combinada apenas se movió.

AWS presenta el método como independiente del marco de trabajo y, al mismo tiempo, muestra su integración con el SDK de evaluación de Strands Agents. La documentación del evaluador personalizado describe el sistema de evaluación circundante, que puede recopilar trazas y ejecutar evaluadores adicionales.

Esta portabilidad importa. La propuesta resulta más útil como patrón de medición que como funcionalidad específica de AWS. La secuencia central se mantiene estable: definir dimensiones, puntuar cada turno, atribuir dependencias, componer los resultados y supervisar los cambios.

La verdadera competencia es entre el diagnóstico y el comportamiento flexible de los agentes

Cuanto más precisamente define un evaluador una ruta correcta, mayor es el riesgo de que castigue una alternativa válida.

Los agentes se diferencian de los flujos de trabajo deterministas porque pueden llegar al mismo resultado mediante varias rutas aceptables. Un agente puede recuperar un registro de cliente antes de comprobar la política. Otro puede revisar primero la política y recuperar el registro solo cuando sea necesario. Ambas rutas pueden ser válidas.

Una trayectoria dorada puede convertir accidentalmente un ejemplo exitoso en el único comportamiento aceptado. Este problema se agudiza cuando los evaluadores comparan el orden de las acciones, los campos seleccionados o la redacción intermedia. Un marco de diagnóstico necesita estructura, pero un exceso de rigidez convierte la evaluación en una prueba de imitación.

AWS aborda parte de este riesgo al permitir comparaciones semánticas y pasos invariantes al orden. Los equipos pueden marcar acciones cuyo orden no importa, de modo que las secuencias alternativas reciban crédito. Este enfoque ayuda, pero no elimina el problema de diseño subyacente.

El conjunto de datos dorado debe codificar invariantes, no cada elección incidental realizada por un anotador. Los resultados obligatorios, las acciones prohibidas, los parámetros esenciales y las transiciones de estado son objetivos más sólidos que una única transcripción preferida. Describen lo que exige la corrección y dejan margen para variaciones legítimas.

Aquí es donde la puntuación basada únicamente en resultados conserva su utilidad. El estado de la base de datos, los artefactos generados y los efectos externos verificados pueden revelar el éxito sin prescribir una ruta. Un evaluador a nivel de turno debe explicar los fallos en torno a esas comprobaciones, no desplazarlas.

La Agent Evaluation Metric para conversaciones de varios turnos también parte de una definición deliberadamente acotada de la corrección. La veracidad y la completitud no cubren la seguridad, la retención de instrucciones, la calidad de la planificación, la eficiencia, la satisfacción del usuario ni el comportamiento de recuperación.

Un agente puede superar todas las comprobaciones de veracidad mientras expone datos confidenciales. Puede proporcionar una respuesta completa tras realizar llamadas innecesarias de alto riesgo. También puede obedecer la solicitud inmediata mientras olvida una restricción establecida cinco turnos antes.

AWS describe la corrección como la primera dimensión de un patrón extensible. Se espera que trabajos futuros apliquen el método a la seguridad, y más adelante se prevén evaluaciones multilingües y multimodales. Hasta que esas dimensiones lleguen y sean validadas, AEM no debe considerarse una medida completa de la calidad de los agentes.

Los jueces automatizados añaden otra incertidumbre. La puntuación semántica puede depender de modelos de embeddings, puntuadores entrenados o jueces basados en LLM. Cada uno puede introducir sensibilidad a los umbrales, puntos ciegos de dominio y deriva entre versiones.

Un juez también puede discrepar de los revisores humanos por razones fundamentadas. Los expertos del dominio pueden saber que dos frases similares tienen significados operativos distintos. En finanzas, medicina o cumplimiento normativo, un valor superficialmente equivalente puede cambiar la acción permitida.

AWS recomienda correlacionar las puntuaciones descompuestas con etiquetas humanas o doradas en los errores costosos. La correlación de Pearson o Spearman puede mostrar si las puntuaciones automatizadas siguen los juicios de los revisores. Esa validación debe realizarse para cada submétrica, no solo para el compuesto final.

La revisión humana sigue siendo necesaria en casos ambiguos y de gran trascendencia. El objetivo no es automatizar todos los juicios. Es dirigir la atención hacia las conversaciones en las que una decisión humana tiene mayor valor.

La guía más amplia para crear agentes también recomienda establecer líneas de base de evaluación antes de optimizar la elección del modelo. Asimismo, considera la intervención humana y las protecciones en capas como partes de una implementación fiable.

AEM puede hacer que esas líneas de base sean más informativas. No puede decidir qué errores puede tolerar una organización. Una respuesta veraz pero incompleta y una respuesta completa pero falsa fallan ambas en corrección, aunque sus consecuencias empresariales pueden diferir notablemente.

La media no ponderada introduce el mismo problema. Supone que cada turno aprobado contribuye por igual. Los responsables de producción podrían acabar necesitando ponderaciones para acciones riesgosas, campos críticos o cambios de estado irreversibles.

Los equipos deben resistirse a comprimir la evidencia descompuesta demasiado pronto. Un único número compuesto es útil para detectar tendencias, pero las decisiones de lanzamiento deben seguir examinando la combinación subyacente de fallos. La descomposición solo crea valor cuando las personas la conservan.

AEM cambia la conversación sobre las regresiones

La atribución a nivel de turno hace que las comparaciones entre modelos sean accionables porque conecta un descenso de calidad con una clase y ubicación de fallo específicas.

Los equipos de agentes cambian con frecuencia prompts, modelos, esquemas de herramientas, lógica de recuperación, sistemas de memoria y políticas. Cualquier modificación puede mejorar una parte de un flujo de trabajo mientras daña otra. Una tasa final de éxito suele carecer de la resolución necesaria para explicar ese intercambio.

Supongamos que un modelo más pequeño mantiene la misma puntuación global de conversación, pero genera más parámetros ausentes durante cadenas de tres pasos. Ese patrón sugiere que la aparente paridad quizá no sobreviva a solicitudes de producción más complejas. Los ingenieros pueden aislar esas cadenas antes de un despliegue amplio.

Otra versión podría reducir los errores de respuesta factual mientras aumenta las discrepancias de acción. Los responsables de producto se enfrentan entonces a una elección real. Un mejor redactor no es necesariamente un operador más seguro si selecciona la herramienta equivocada con mayor frecuencia.

Las submétricas nombradas de AEM crean puntos de comparación estables. La veracidad puede seguirse por separado de la completitud. Las causas raíz pueden agruparse por herramienta, acción, campo, longitud de conversación o versión del modelo.

El marco también respalda la clasificación operativa. Si muchos turnos fallidos comparten una causa previa, los equipos pueden priorizar la primera acción que falló. Corregir esa acción puede eliminar varios fallos posteriores de una sola vez.

Esto es más eficiente que leer cada traza marcada en rojo como un incidente independiente. También produce una asignación de responsabilidades más clara. Un equipo de esquemas puede investigar parámetros ausentes, mientras que un equipo de recuperación examina valores de origen incorrectos.

Para los agentes intensivos en conocimiento, el diagnóstico de trazas debe incluir la información disponible cuando ocurrió cada acción. Los equipos necesitan prompts versionados, pasajes recuperados, respuestas de herramientas y estado de conversación. Sin ese registro, un evaluador puede localizar un turno fallido sin revelar por qué el modelo lo eligió.

Ese requisito conecta la evaluación con la gestión del conocimiento. Una base de conocimiento de ingeniería consultable puede ayudar a los equipos a preservar especificaciones, hallazgos de incidentes y decisiones de evaluación junto a su evidencia de pruebas.

Los casos de producción deben ampliar continuamente el conjunto de datos dorado. Una solicitud de usuario inesperada, un fallo de herramienta o una corrección ambigua pueden convertirse en un caso de regresión revisado. Esto mantiene la evaluación alineada con el comportamiento real en lugar de con un guion estático de laboratorio.

Los equipos también deben almacenar rutas alternativas exitosas. Las trazas fallidas muestran qué debe evitarse, mientras que las diversas trazas exitosas revelan cuánta flexibilidad debe permitir el evaluador. Ambas son necesarias para evitar reglas de trayectoria frágiles.

El mayor cambio organizativo puede producirse en las revisiones de lanzamiento. En lugar de preguntar si el nuevo agente obtuvo una puntuación más alta, los revisores pueden preguntar qué dimensiones mejoraron, dónde aparecieron nuevas causas raíz y si las cadenas más largas se volvieron menos fiables.

Esa conversación es más difícil de resumir en una sola tarjeta de panel. También está más cerca de las decisiones que los equipos realmente necesitan tomar.

Tres señales mostrarán si AEM se extiende más allá de AWS

AEM solo cobra importancia si los equipos pueden reproducir su atribución, calibrar sus jueces y ampliarlo sin perder comparabilidad.

La primera señal es la validación pública de las etiquetas de causa raíz frente a trayectorias revisadas por humanos. El ejemplo desarrollado por AWS explica claramente el mecanismo, pero la publicación no informa cifras internas de producción de Amazon Quick Suite. La siguiente evidencia útil mediría el grado de acuerdo sobre los turnos del primer fallo y las etiquetas de cascada en dominios variados.

Un alto grado de acuerdo reforzaría la afirmación de que AEM acorta la depuración. Las discrepancias frecuentes revelarían que la atribución de dependencias es el eslabón más débil del marco. Los equipos deberían vigilar evaluaciones que separen cadenas lineales simples de flujos de trabajo ramificados, reintentos e intentos de recuperación.

La segunda señal es la adopción fuera de un único marco. AWS proporciona una integración con Strands Agents, pero la metodología se describe como portable. Las implementaciones en otros sistemas de trazado y evaluación pondrían a prueba si su taxonomía resiste distintas representaciones de turnos, llamadas a herramientas y estado.

La adopción entre marcos también fomentaría definiciones compartidas. Si cada plataforma interpreta de forma distinta la veracidad, la completitud y el fallo heredado, las puntuaciones seguirán siendo locales. Los esquemas comunes y los casos de referencia harían las comparaciones más creíbles.

La tercera señal es la expansión prometida más allá de la corrección. La seguridad será la prueba más importante porque un comportamiento seguro no siempre puede representarse como otra comparación de campos factuales. Una acción peligrosa puede usar parámetros correctos, seguir la solicitud del usuario y aun así infringir una política.

Una extensión de seguridad exitosa demostraría que el método de descomponer-evaluar-componer maneja dimensiones cualitativamente distintas. Una extensión débil sugeriría que AEM se entiende mejor como un depurador de corrección focalizado, no como una métrica general de calidad de agentes.

Los desarrolladores no deberían esperar a esa hoja de ruta antes de mejorar sus pruebas. Empiecen por elegir varias conversaciones relevantes y anotar los resultados, las acciones requeridas, los campos críticos y la estructura de dependencias. Ejecuten el agente repetidamente y, después, comparen el primer error genuino con los turnos posteriores que lo heredaron.

Mantengan las comprobaciones de estado final junto a los veredictos a nivel de turno. Revisen los casos semánticamente ambiguos con expertos del dominio. Registren rutas alternativas válidas para que el evaluador no confunda la flexibilidad con un fallo.

La métrica de evaluación de agentes para conversaciones de varios turnos plantea un caso convincente para cambiar la unidad de diagnóstico. Su valor duradero dependerá de que equipos independientes puedan acordar qué falló primero. La siguiente pregunta para cualquier equipo de agentes es concreta: cuando tu panel informa de una conversación fallida, ¿puede identificar la decisión que realmente la provocó?