Monta el benchmark de tu dominio antes que el agente
Ramp evalúa su agente contable con 237 tareas y 3.469 criterios escritos por contables. Por qué el benchmark privado de dominio decide más que el modelo.
El dataset que define “bien hecho” en tu dominio decide más que la elección de modelo — y es el único componente del sistema que nadie te puede vender. Ramp lo demuestra con números: en junio de 2026 publicó la mecánica del benchmark con el que desarrolla su agente de cierre contable — 237 tareas con 3.469 criterios de corrección escritos por contables, sobre ocho negocios sintéticos con historial de transacciones realista. Contra ese dataset, su agente acierta el 79% de los criterios frente al 75% de GPT-5.5 sin ayudas y el 74% de Opus 4.7, y resuelve cada tarea en ~4 minutos donde los modelos a pelo tardan ~10.
El detalle que cambia el orden de trabajo: el benchmark existía antes de optimizar el agente, y es lo que permite iterar en horas en vez de esperar el feedback de cada cliente. La misma jugada vale para cualquier dominio regulado: contabilidad, facturación, conciliación.
Por qué el benchmark privado es un activo
Cuando un benchmark público sube de 92 a 93 puntos ya no está midiendo nada: esa diferencia es ruido del propio eval —la prueba con la que mides al modelo—, aunque se siga citando como si tuviera señal. Es la razón por la que equipos como Andon Labs construyeron Vending-Bench, un eval de negocio de horizonte largo: cuando un benchmark se satura, deja de discriminar entre modelos. Un benchmark de dominio —el dataset de tareas con criterios de corrección construido sobre tus datos— no tiene ese problema: nadie entrena contra él, nadie lo maxea, y codifica exactamente lo que tu negocio considera correcto.
Satya Nadella lo formuló como tesis de plataforma en una entrevista con Stratechery (2026): los evals privados son “maybe the most important IP a firm creates” — la mayor propiedad intelectual de una empresa. Y dio el test ácido operativo: si puedes cambiar el modelo A por el modelo B y seguir mejorando contra tu eval, el control de tu sistema es tuyo; si no puedes, es de tu proveedor.
La acción concreta: lista los tipos de tarea que tu agente toca —Ramp usa cuatro: conciliación, entrada de datos, análisis de varianzas y devengos— y escribe con el experto del dominio criterios de corrección atómicos por tarea, verificables por script. Esos criterios, no el prompt, son el activo.
La mecánica: mundos sintéticos, criterios atómicos, cinco intentos
El benchmark de Ramp ejecuta cada una de sus 237 tareas 5 veces de forma independiente, sobre tres piezas: ocho “mundos” (negocios sintéticos con historial de transacciones y ficheros de soporte), cuatro categorías de tarea, y 3.469 criterios de calificación escritos por contables reales. Cinco intentos porque el número que importa en producción no es si el agente puede acertar sino cuántas veces acierta — la distinción entre capacidad y fiabilidad que ya desempaquetamos con pass@k —la tasa de acierto del agente en k intentos—.
Dos decisiones de diseño valen el robo. Primera: mundos sintéticos en vez de datos de clientes — evitan el sobreajuste a un cliente concreto y los problemas de privacidad de evaluar con libros reales. Segunda: mundos “roll-forward”, donde el mismo negocio avanza al período siguiente, para validar que la memoria del agente transfiere lo estable sin contaminar el período nuevo — la versión eval de cerrar un mes y abrir el siguiente.
El dataset también les midió el salto generacional: entre GPT-5.4 y GPT-5.5 detectaron una brecha de 19 puntos porcentuales. Ese número no salió de un leaderboard —la tabla pública de puntuaciones—, salió de su dataset.
Replica el patrón: dos o tres clientes tipo convertidos en mundos sintéticos, criterios por tarea escritos por quien firma el cierre, y N intentos por tarea — mide consistencia, no solo acierto.
El test de apagado: el benchmark te dice qué cortar
El test de apagado —quitar un componente del agente y volver a medir contra el benchmark; ablation en el argot de los papers— es la técnica que le dijo a Ramp qué sobraba: comprimir un 64% la skill de hojas de cálculo —de 14.000 a 5.000 caracteres— subió la puntuación entre 3,3 y 3,7 puntos porcentuales. Y de las seis-y-pico skills que le habían montado al agente —los paquetes de instrucciones y herramientas que se le enchufan por tipo de tarea—, solo dos mejoraban el resultado en promedio; el resto era neutral o restaba.
Nada de esto se descubre sin benchmark: la intuición de “más contexto ayuda” es justo la que los números desmienten.
Con la memoria, el mismo patrón. La primera versión (inferir el procedimiento desde la tarea y la respuesta correcta) falló. La segunda (extraer de las trayectorias del agente los mapeos de cuentas, la estructura y los cálculos reutilizables) subió 5,5 puntos en los mundos roll-forward, de 56,0% a 61,5%. Pero la memoria con hechos específicos de un período hundió uno de los mundos de 75% a 25%: el agente arrastraba al período nuevo verdades que ya no lo eran. La regla que les quedó: memoria que generaliza (mapeos estables, cálculos), sí; hechos de período, nunca.
Ejecuta el test de apagado componente a componente: apaga cada skill, mide, y borra lo que no pague su sitio en el contexto. Y antes de darle memoria al agente, define por contrato qué tipos de hecho puede escribir.
El gate de migración: lo que el leaderboard no te avisa
Según el repaso de Zvi Mowshowitz sobre las reacciones a Opus 4.8, el modelo subió en SWE-bench Pro de 64,3 a 69,2 y, a la vez, según las mediciones de Andon Labs que recoge, cae en proveedores fraudulentos 30 veces más que Opus 4.7: en una ejecución de Vending-Bench llegó a mandar $9.000 a un “membership” falso. El mismo ajuste que lo hizo más honesto lo hizo peor negociador. Los controles de alineamiento generalizan, para bien y para mal, y el leaderboard que mira código no te avisa de lo que pasa en compras.
Hay un segundo aviso en los mismos datos: con el esfuerzo de razonamiento al máximo, 4.8 rinde peor que en el nivel alto — la hipótesis de Andon es que más tokens de razonamiento llenan antes el contexto, fuerzan más compactación y el agente recuerda menos. Otro comportamiento que solo aparece en evals de horizonte largo con recursos reales, nunca en una prueba de 20 turnos.
Los dos avisos exigen la misma respuesta: convierte tu benchmark en gate de migración —el control que cualquier cambio debe pasar antes de producción—. Ningún cambio de modelo ni de versión se despliega sin ejecutar el dataset completo, incluidos los casos adversariales de tu dominio. Un caso adversarial tiene tres piezas: un input plausible en tu producción real, el error que el modelo comete más de lo que tu intuición espera, y un criterio de corrección verificable por script. En contabilidad: el proveedor falso, el descuento trampa, la factura duplicada. Si tu benchmark no los tiene todavía, empieza por ahí — es la superficie que ningún benchmark público cubre.
La última vez que cambiaste de modelo (o aceptaste una subida de versión), ¿qué pasó el cambio: tu dataset con criterios de dominio, o el leaderboard de otro? Si fue lo segundo, ya sabes cuál es la primera tarea del benchmark que te falta.