Qué midió realmente BenchMIRT — y por qué duele
El hallazgo central de BenchMIRT es contundente: el rango de benchmark no predice el rango de razonamiento. La brecha no es pequeña. Un benchmark de modelo de lenguaje es una prueba estandarizada diseñada para evaluar el rendimiento de modelos de lenguaje en varias tareas de procesamiento del lenguaje natural—MMLU, GSM8K, HumanEval, los sospechosos habituales. Pero lo que realmente miden es la coincidencia de patrones en distribuciones estáticas y públicas. Un modelo que obtiene un 92% en MMLU ha memorizado estructuras similares a pruebas, no ha adquirido razonamiento.
La contaminación es real—la superposición de datos de entrenamiento con conjuntos de pruebas de benchmark infla las puntuaciones en 5–15 puntos. La sensibilidad al formato de indicación también importa: cambia la pregunta de "¿Cuál es la capital de Francia?" a "P: ¿Cuál es la capital de Francia? R:" y cambias el rendimiento en 3–8%. Los benchmarks recompensan la regularidad estadística superficial, no la selección de herramientas de múltiples pasos y la recuperación de errores que tus agentes necesitan en producción.
La brecha: lo que hacen los agentes de producción que los benchmarks nunca prueban
Los agentes de producción viven en un espacio que los benchmarks no tocan. Una llamada de herramienta tiene éxito o falla en 200ms o agota el tiempo en 29s. El LLM devuelve una respuesta JSON malformada y tu agente o se recupera con un reintento o bloquea la tarea del usuario. La deriva del esquema de herramientas importa—el bloque tool_use de Anthropic difiere de las llamadas de función de OpenAI, y el SDK de Vercel AI añade su propia abstracción. Un agente que se ejecuta contra tu propia API necesita claves de idempotencia y manejo de 429; un tomador de benchmark no.
La distribución de latencia da forma al costo real. P95 bajo carga concurrente supera la latencia promedio por mucho—tus usuarios experimentan la cola, no la media. Colas de letras muertas para tiempos de espera de herramientas, almacenes de sesiones Redis para mantener el estado entre turnos, costo por acción de agente exitosa en lugar de costo por token: estos son los ejes que determinan si un agente sobrevive el primer contacto con el tráfico de producción. El costo por acción de agente exitosa importa más que el costo por token porque un modelo más barato que falla en llamadas de herramientas no vale nada.
Por qué los cambios de clasificación sorprenden a los equipos a las 2am
El patrón es repetible: un equipo se actualiza al nuevo modelo SOTA anunciado el jueves, se despliega el viernes por la tarde, y a las 11pm el ingeniero de guardia está revirtiendo porque la precisión de las llamadas de herramientas se desplomó. El modelo obtuvo una puntuación más alta en los benchmarks. No maneja la adherencia de salida estructurada cuando ajustas la temperatura o el indicador del sistema. Devuelve JSON válido pero argumentos semánticamente incorrectos—fechas desviadas por un mes, IDs que no existen en tu base de datos.
Las actualizaciones silenciosas de pesos de proveedores empeoran esto. Los pesos de un modelo cambian sin un cambio de versión. Tus resultados de evaluación en caché ahora están obsoletos. Si enrutas a través de Vercel AI Gateway y confías solo en sus reglas, no tienes un disyuntor para este escenario. Las reglas de enrutamiento de Vercel son necesarias pero no suficientes para detectar regresiones en el comportamiento del agente porque las reglas no pueden saber cómo se ve tu gráfico de herramientas.
Construyendo el arnés de evaluación que deberías haber enviado en la primera semana
Comienza con casos semilla de trazas de producción reales. Expórtalos desde Langfuse o tu backend de OpenTelemetry como un accesorio—al menos 50 consultas de usuarios reales y sus resultados esperados. Puntúa cuatro ejes: éxito de la tarea (¿alcanzó el agente un estado terminal?), corrección de la llamada de herramienta (¿herramienta correcta, argumentos correctos?), comportamiento de recuperación (¿reintentó JSON malformado o falló en cascada?), y presupuesto de latencia (p95 bajo tu piso de SLA).
Construye casos adversariales: inyecta 500s desde tu capa de herramientas, trunca respuestas a mitad de flujo, alimenta entradas de usuario ambiguas que los usuarios reales envían. Accesorio la capa de herramientas con respuestas HTTP grabadas (estilo VCR con nock o responses) para que tus evaluaciones se ejecuten sin tocar la producción o incurrir en costos de herramientas. Conecta el arnés en CI en cada cambio de indicador y cambio de modelo. Bloquea la fusión en regresión—si la tasa de aprobación cae por debajo de tu umbral, reviertes en la capa de puerta de enlace, no en la capa de confirmación.
Presupuesta la infraestructura: costo de token por ejecución de evaluación (multiplica por casos × llamadas de modelo), cadencia (noche es más seguro que por PR pero más lento para detectar regresiones). Versiona tu conjunto de trazas doradas en git junto con indicadores y configuraciones de modelo para que las regresiones sean reproducibles.
Mide el bucle, no el modelo: latencia, recuperación y tiempo de reloj
El costo real de un agente no está en la llamada de LLM—está en el espacio entre llamadas de herramientas. Tiempo de reloj esperando respuestas de API, retroceso de reintento, viajes de disyuntor: estos son eventos puntuados en tu arnés, no registros de infraestructura que ignoras. Instrumenta cada decisión de reintento y retroceso. Registra registros de razón de caché: ¿por qué falló la recuperación, por qué falló la selección de herramientas? Usa IDs de correlación en tramos de LLM, tramos de herramientas y tramos de base de datos para que puedas reconstruir la cadena completa.
El tiempo de reloj entre llamadas de herramientas es la métrica de costo real, no la utilización de GPU. Tus SLOs para agentes deberían ser: tasa de éxito en techo de latencia p95 (por ejemplo, "95% de las tareas tienen éxito dentro de 3 segundos"), no latencia promedio. La observabilidad por paso con IDs de correlación significa que detectas dónde el agente pierde tiempo—inferencia de LLM, saltos de red de herramientas, búsquedas de almacén de estado—y optimizas en consecuencia.
Cómo usamos los benchmarks ahora (y cómo no)
Trata MMLU, HumanEval y otros leaderboards como filtros gruesos para la preselección de modelos. "¿Está este modelo en el rango?" Sí o no. Si no puede alcanzar el piso del benchmark, probablemente no se enviará. Pero un aprobado en el leaderboard no es una luz verde. Siempre sigue con un arnés específico del dominio de 50–200 casos reales antes de cualquier cambio de producción. Mantén tu conjunto de trazas doradas versionado en git. Vuelve a ejecutar el arnés en actualizaciones silenciosas del lado del proveedor; si la tasa de aprobación cae más de 2 puntos porcentuales, revierte inmediatamente.
Cuándo escalar a tu proveedor: si el arnés detecta una regresión que las evaluaciones internas del proveedor perdieron, eso es un error en su prueba, no en tu integración. Documéntalo. Si sucede dos veces, cambia de proveedor o negocia SLAs que penalicen regresiones silenciosas.
Elige tus 3 modos de fallo de producción principales de los registros del mes pasado—JSON malformado, cascadas de tiempo de espera de herramientas, entrada de usuario ambigua que lleva a la selección incorrecta de herramientas. Convierte cada uno en un caso de evaluación puntuado con salida esperada versus real. Conecta el arnés en CI antes de tu próximo cambio de modelo. Si necesitas ayuda para construir ese arnés, podemos ayudarte a enviarlo.