Motorway mide su agente: del 87% al 98% al elegir herramientas

El 23 de julio de 2026, Motorway y AWS publicaron los resultados de un sistema de evaluación para el agente que ayuda a concesionarios británicos a buscar vehículos. La cifra más vistosa —pasar de una consulta incorrecta de cada ocho a una de cada 50— tiene un denominador concreto: el caso de Motorway y AWS atribuye el cambio a una precisión de selección de herramientas que subió del 87% al 98%.

No es una auditoría independiente. AWS vende parte de la infraestructura, participó en el desarrollo y publica los resultados junto con Motorway. Es, sin embargo, un caso técnicamente detallado que permite aprender algo más duradero que la mejora: un agente no se evalúa como una caja de texto. Hay que separar qué herramienta eligió, qué parámetros envió, qué trayectoria siguió, qué respuesta produjo y con qué consistencia repite el resultado.

La capacidad transferible consiste en construir una matriz donde cada fallo tenga su métrica, su conjunto de pruebas y su umbral. Una respuesta fluida puede ocultar una búsqueda equivocada; una herramienta correcta puede recibir filtros erróneos; una ejecución satisfactoria puede ser una excepción afortunada. Medir solo el texto final confunde esas causas.

Qué problema resuelve el agente de Motorway

Motorway opera una subasta diaria en la que, según las cifras publicadas por las dos organizaciones, hasta 8.000 concesionarios pujan por hasta 2.500 vehículos. El agente transforma consultas en lenguaje natural en búsquedas sobre el inventario. Expone ocho herramientas que combinan filtros estructurados sobre más de 89 atributos y búsqueda semántica.

Una petición como “SUV diésel por menos de 25.000 libras cerca de mi concesionario” contiene condiciones que deben convertirse en campos y valores correctos. “Algo deportivo y automático para una familia” mezcla filtros explícitos con conceptos más abiertos. El agente decide si usa búsqueda estructurada, búsqueda híbrida, distancia, perfil del concesionario u otra función, y después construye sus parámetros.

Ese recorrido crea varias oportunidades de error. Puede seleccionar búsqueda semántica cuando bastaba un filtro exacto, omitir el precio máximo, perder una restricción introducida en un turno anterior o resumir correctamente resultados que ya eran incorrectos. Con alrededor de 1.500 usuarios simultáneos en horas punta, otra cifra del caso, un porcentaje pequeño puede convertirse en muchas experiencias fallidas.

Primera capa: herramienta, parámetros y orden

La primera capa compara la trayectoria observada con la esperada. Para una consulta estructurada, un evaluador determinista puede verificar el nombre de la herramienta, campos como tipo de combustible y límites de precio, y el orden de llamadas cuando unas dependen de otras. El proyecto abierto Strands Evals organiza pruebas como experimentos, casos y evaluadores, y admite expectativas sobre salidas y trayectorias.

Motorway fijó para esta capa un umbral superior al 95%. El número es una decisión del caso, no una constante universal. Una búsqueda de inventario puede tolerar que el usuario corrija un resultado; un agente que autoriza pagos o modifica expedientes necesita controles más estrictos y quizá prohibiciones deterministas fuera del modelo. El umbral debe salir del daño posible y del coste de recuperación.

Tampoco conviene fundir selección y parámetros en una sola etiqueta. Elegir la función de distancia es correcto; enviar un código postal perteneciente a otro concesionario es un fallo distinto y potencialmente más grave. Separar ambos permite saber si hay que mejorar descripciones de herramientas, validación de esquemas, permisos o contexto.

Segunda y tercera capas: proceso y resultado

La segunda capa examina la coherencia del proceso y usa en el caso un umbral superior al 85%. La tercera valora si la respuesta es útil, precisa y accionable, con un umbral superior al 90%. Para preguntas abiertas, Motorway y AWS emplean modelos de lenguaje como jueces; para selección y parámetros prefieren comprobaciones deterministas.

Los dos resultados deben leerse juntos. Un agente puede llegar a una lista válida tras ignorar una restricción que no cambió casualmente el resultado. También puede seguir una trayectoria razonable y fracasar porque el inventario estaba desactualizado. El proceso ayuda a diagnosticar; la salida mide lo que recibió el usuario. Ninguno sustituye al otro.

Un juez basado en otro modelo aporta flexibilidad, pero no se convierte por ello en verdad de referencia. Su criterio depende de la rúbrica, del contexto que recibe y de su propia variabilidad. Hace falta calibrarlo con revisión humana, conservar ejemplos límite y vigilar desacuerdos. Cuando existe una respuesta o trayectoria inequívoca, el código determinista ofrece una señal más barata y reproducible.

Repetir: pass@k no es lo mismo que pass^k

Los agentes son no deterministas: la misma consulta puede activar recorridos distintos. El caso distingue dos preguntas. pass@k mide la probabilidad de obtener al menos un éxito entre varios intentos; sirve cuando basta encontrar una solución. pass^k exige éxito en todos los intentos consecutivos; se acerca más a la expectativa de un cliente que quiere resultados fiables cada vez.

La diferencia crece rápido. Con una tasa de éxito por intento del 75%, tres éxitos consecutivos tienen una probabilidad teórica de 0,75 × 0,75 × 0,75, aproximadamente el 42%, si los intentos son comparables e independientes. Un único resultado aprobado ocultaría esa fragilidad. En datos reales también hay correlaciones —una formulación problemática puede fallar siempre—, por lo que conviene publicar el número de casos, repeticiones, distribución y criterio de éxito, no solo una media.

El repositorio de referencia de AWS implementa la evaluación en tres capas y permite varias pruebas por caso. Es código de muestra, no un producto soportado ni una receta lista para producción: su propio aviso exige probarlo, protegerlo y adaptarlo antes de manejar cargas reales. Ese límite es tan relevante como su arquitectura.

Antes y después del despliegue son problemas distintos

Durante el desarrollo, un conjunto fijo de casos puede actuar como puerta: si una métrica baja del umbral, la versión no avanza. Los casos incluyen rutas habituales, lenguaje ambiguo, conversaciones de varios turnos, acciones que deben rechazarse y restricciones de dominio. Motorway afirma que su colección pasó de 50 a 150 casos en tres meses al convertir fallos reales en regresiones.

La producción aporta una distribución que el laboratorio no conoce: terminología rara, carga concurrente, datos incompletos, latencia y combinaciones inesperadas. AgentCore Evaluations documenta evaluaciones bajo demanda y configuraciones en línea que puntúan muestras de trazas. En la arquitectura descrita, esas señales alimentan métricas y alertas; no deben bloquear retrospectivamente una respuesta que el usuario ya recibió.

Entre ambos mundos aparece el modo sombra: una versión candidata procesa una copia de tráfico sin decidir lo que ve el cliente. Después puede pasar a una fracción de usuarios y, finalmente, al despliegue completo. Los porcentajes y horas que propone AWS son puntos de partida del ejemplo, no garantías. Cada organización necesita criterios de detención, privacidad para las trazas y un plan de reversión.

Qué mejoró y qué sigue sin saberse

Motorway y AWS declaran varias mejoras conjuntas: selección de herramientas del 87% al 98%, finalización de tareas del 82% al 96%, retención de contexto multivuelta del 71% al 94%, incidencias mensuales de 12 a 2 y detección desde una media de cuatro horas hasta pocos minutos. La equivalencia entre el 98% y un error de cada 50 procede de su propia definición de resultados incorrectos.

Las cifras no revelan en la publicación intervalos de confianza, composición exacta del conjunto de evaluación, volumen de consultas del periodo anterior y posterior ni una comparación controlada que aísle cada cambio. Tampoco consta una reproducción externa. Por eso demuestran lo que el equipo midió bajo su protocolo, no que la misma canalización produzca igual mejora en otro agente.

La lectura útil conserva ambos niveles: el resultado autodeclarado justifica estudiar el caso, y el método permite juzgar futuros agentes. Antes de aceptar “mejoró la precisión”, hay que pedir precisión de qué, sobre cuántos casos, con cuántas repeticiones, contra qué referencia y con qué consecuencia cuando falla. Ese denominador convierte una demostración convincente en evidencia que se puede discutir y mejorar.