Amazon Science: por qué los agentes ML no se sobreajustan

Por qué los benchmarks de ML no se sobreajustan: el rompecabezas de hace una década

En machine learning, la diferencia entre un modelo que aprende y uno que memoriza se llama generalización. Un modelo que gana en su set de entrenamiento pero pierde en datos nuevos no aprendió nada: solo se aprendió las respuestas. Ese fallo tiene nombre: overfitting.

La defensa clásica, la que se enseña en cualquier curso introductorio, es reservar un conjunto de validación que el modelo nunca ve durante el entrenamiento, y un conjunto de test que se toca una sola vez al final. Si el rendimiento en el test es alto, hay garantías de que funcionará con datos nuevos.

El problema es que esa garantía se rompe en cuanto se mira el test, se ajusta el modelo, se vuelve a mirar y se itera. Repetido suficientes veces, el set «no visto» se vuelve parte del procedimiento y se sobreajusta igual que el set de entrenamiento.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Eso es exactamente lo que hace la comunidad de investigación en ML. Durante años, grupos enteros —publish or perish mediante— iteran sobre los mismos benchmarks: evalúan, ajustan, vuelven a evaluar, publican y dejan que el siguiente equipo arañe otra mejora. Por la lógica del libro de texto, las leaderboards deberían estar saturadas de modelos que brillan en el benchmark y fallan en cualquier otro lado.

Y, sin embargo, no es lo que pasa. Estudios que construyen sets de test frescos para benchmarks viejos y muy reutilizados muestran que las mejoras sí transfieren: en datos nuevos, los modelos muestran las mismas ganancias que en el benchmark viejo. El progreso guiado por benchmarks, contra el pronóstico del libro de texto, ha producido un avance rápido y, en gran medida, real.

La hipótesis: lo que cabe en pocos tokens no se sobreajusta

Un equipo de Amazon Science —el brazo de investigación científica de Amazon— propone una explicación formal en el paper «What fits (into few tokens) doesn’t overfit: Compression and generalization in ML research agents». La idea es una versión precisa de la navaja de Occam: si puedes describir tu hipótesis (tu modelo, tu estrategia) en muy pocos bits, y esa descripción compacta rinde muy bien en los datos de entrenamiento, entonces también rendirá bien en datos nuevos.

El razonamiento es un argumento de conteo. Hay pocas cadenas cortas — pocas hipótesis candidatas —, así que es improbable que alguna te haya engañado por suerte. O, dicho al revés: si tu descripción comprimida es demasiado pequeña como para haber memorizado los datos, cuando rinde bien en entrenamiento no puede ser porque memorizó: tiene que haber capturado estructura real.

El salto clave es que los LLM modernos son decodificadores de compresión extraordinarios. Llevan tal cantidad de conocimiento del mundo (cómo funcionan las herramientas de ML, los optimizadores estándar, los hiperparámetros convencionales) que un mensaje críptico de experto a experto basta para que reconstruyan el procedimiento completo. La navaja de Occam cuenta bits: el conocimiento del modelo no cuenta en contra, porque podrías haberlo escrito sin mirar el set de entrenamiento.

El experimento: exprimir una estrategia por un cuello de botella

El equipo convirtió la hipótesis en un experimento limpio. Montó tres agentes:

Explorador: tiene acceso completo al set de validación e itera libremente, persiguiendo mejor rendimiento ronda tras ronda.
Compresor: lee todo el transcript del explorador y trata de destilar la estrategia ganadora en un prompt muy corto (un puñado de tokens).
Reproductor: recibe solo ese prompt corto y los datos de entrenamiento. Sin acceso a la validación, al código del explorador ni a su transcript. Implementa la estrategia desde cero.

Si el reproductor, partiendo de cero y armado solo con unos pocos tokens, iguala al explorador, entonces toda la información dependiente de la validación que se necesita para especificar la estrategia pasó por ese canal minúsculo. La estrategia era comprimible. A esa prueba la llaman certificate of output compression.

Lo poderoso es que el reproductor se puede reiniciar una y otra vez — algo imposible con una comunidad humana. El compresor puede intentar muchas compresiones y comprobar cuáles decodifican bien, porque cada intento aterriza en un reproductor nuevo sin memoria del anterior. El paper detalla que el compresor y el reproductor son, en este estudio, modelos Claude.

Lo que salió del otro lado

En ocho datasets distintos —clasificación tabular, clasificación de imágenes, modelado de lenguaje, modelado de difusión y reward modeling—, prompts de 32 tokens bastaron para que un reproductor fresco igualara al explorador optimizado en la mayoría de problemas. Una estrategia de modelado de lenguaje sobrevivió la compresión a 16 tokens sin perder rendimiento en held-out.

Los prompts resultantes son crípticos para un humano pero precisos para otro agente de ML. En un experimento de modelado de lenguaje, el explorador descubrió una receta estilo GPT que bajo un presupuesto de 16 tokens se codifica como:

QKn 12L768 Mu .1 R² b2M 4x

Donde QKn es normalización QK, 12L768 un transformer de 12 capas y 768 dimensiones, Mu .1 el optimizador Muon con learning rate 0,1, R² activaciones squared-ReLU, b2M batch de dos millones de tokens y 4x un bloque feed-forward cuatro veces más ancho. Si el presupuesto baja a 8 tokens, el prompt se reduce a 12L768 Mu .1 R² y el reproductor ya no iguala al explorador: las piezas que faltan codificaban elecciones reales dependientes de los datos, no defaults obvios.

El equipo también cerró el cuello de botella por el otro lado: en lugar de comprimir la salida, comprimió la entrada. Devolvió al explorador un solo bit por consulta — ¿este modelo supera al mejor actual, sí o no? — y aún así encontró estrategias tan buenas como con puntajes numéricos completos. La versión de un bit viene incluso con garantía matemática de generalización.

¿Y si los agentes sí se sobreajustan? Detector incluido

Una buena teoría debe ser falsable, y esta lo es. Para forzar el sobreajuste, los investigadores dieron a los agentes acceso directo al set de validación y los empujaron a maximizar el rendimiento de validación a cualquier costo. Picaron el anzuelo: en 38 de 102 corridas, la accuracy de validación superó en más de 10 puntos a la accuracy real en held-out.

La teoría predice que esas ganancias no deberían sobrevivir el cuello de botella de compresión, porque codifican idiosyncrasias de ejemplos específicos, no estructura transferible. Y no sobrevivieron: cuando se pasaron por un prompt corto a un reproductor fresco, las ventajas de validación desaparecieron. La compresión separó las estrategias legítimas de las que sobreajustaban con precisión muy alta.

Qué significa esto para tu startup

Para founders construyendo sobre ML e IA, el estudio deja tres acciones concretas que podés implementar ya.

Mide la compresibilidad antes de confiar en una leaderboard. Si tu pipeline ganador se puede describir en unas pocas frases que otro modelo ejecuta desde cero con resultados similares, probablemente estás ante señal real. Si necesitás un transcript largo y específico para reproducirlo, sospecha: el procedimiento puede estar memorizando particularidades del set que no transferirán a producción. Un smoke test interno es simple: entrenar dos veces la misma pipeline desde prompts de distinta longitud y comparar el rendimiento en un set held-out fresco.
Diseña benchmarks con diversidad, no solo con tamaño. El hallazgo refuerza que los benchmarks reusados durante años sí transfieren — pero transfieren porque las recetas ganadoras son simples y reutilizables. Si estás construyendo un benchmark privado para tu producto (por ejemplo, para evaluar generación de código en tu vertical), invertí en variety de ejemplos más que en volumen: la compresión que el paper describe funciona mejor cuando los ejemplos cubren estructura real, no cuando repiten patrones memorizables.
Usa la compresión como detector de overfitting en producción. La capacidad de los prompts cortos de separar estrategias legítimas de sobreajustadas abre una puerta para auditoría. Si desplegás un agente de ML en un flujo crítico — scoring de créditos, moderación, predicción de churn — podés correr una versión «comprimida» como prueba de stress: si su rendimiento cae respecto al agente completo, tenés una señal cuantitativa de cuánto dependía de particularidades del set de entrenamiento.

El paper lleva un asterisco importante: todo el marco asume que el único camino entre los datos de validación y el modelo final pasa por el prompt. Si el modelo base memorizó el set durante el preentrenamiento, hay un canal lateral. Los autores no creen que eso explique sus resultados — los agentes mejoran gradualmente por búsqueda real, no arrancan ya optimizados, y el rendimiento cae a presupuestos muy bajos — pero resolverlo del todo requerirá datos nuevos creados después del cutoff de los modelos, lo cual no hicieron.

El mensaje general, sin embargo, queda firme: cuando una receta ganadora cabe en pocas palabras, probablemente sea real.