De qué trata este experimento (y por qué importa a un founder)
Mike Vakde (publica como mvakde en GitHub) afirma haber entrenado un transformer pequeño desde cero en 1,5 horas sobre una sola GPU 5090 y alcanzar 44% en ARC-AGI-1 con un costo total declarado de 67 centavos de dólar. Es la tercera entrega de una serie de posts sobre ARC-AGI del mismo autor, según la fuente original mvakde.github.io.
El resultado importa por dos razones prácticas. Primero, iguala el puntaje que obtienen modelos mucho más grandes y costosos como TRM y HRM, que se han publicitado como avances por su estructura recursiva. Segundo, lo logra sin depender de LLMs de frontera ni de grandes volúmenes de datos sintéticos, dos de los atajos más habituales en el estado del arte. Para un founder, el dato clave no es el porcentaje, sino que el experimento entero cuesta lo que cuesta un café y corre en hardware accesible.
Qué es ARC-AGI y por qué se usa como prueba de fuego
ARC-AGI es el benchmark creado por François Chollet para medir inteligencia fluida: la capacidad de resolver problemas visuales nuevos a partir de muy pocos ejemplos. Cada puzzle presenta varias parejas input-output y un único input de prueba cuya salida debe deducirse.
🤖 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 comunidadLa fuente original destaca cinco propiedades del benchmark que lo hacen útil como campo de pruebas: pocas muestras (alrededor de 1.000 puzzles) en un espacio de alta dimensión; es un benchmark de metalearning (cada puzzle usa una regla distinta); requiere muy pocos sesgos inductivos; es accesible incluso para investigadores con poco presupuesto; y sigue sin estar saturado en lo que a eficiencia de datos se refiere.
En términos prácticos, ARC-AGI es una de las contadas pruebas donde el preentrenamiento masivo de los LLMs no confiere capacidades de razonamiento general. De hecho, según la fuente, cuando salió ARC-2, los modelos de razonamiento tipo o1 retrocedieron a casi cero, lo que sugiere que estaban aprendiendo a resolver puzzles tipo ARC, no a razonar en abstracto.
Qué cambió respecto al experimento anterior del mismo autor
El autor ya había publicado antes una versión previa del mismo enfoque, que se volvió viral en X y generó debate entre investigadores como Lucas Beyer, Jeremy Howard y Rohan Anil, según recoge la fuente. Esta nueva entrega es una mejora en cuatro dimensiones explícitas: más rápido, mejor, más barato y sigue siendo open source.
Los cambios principales que reporta mvakde.github.io son:
- Arquitectura modernizada: SwiGLU en lugar de GELU, RMSNorm en lugar de LayerNorm y 8 capas en lugar de 4.
- Más diversidad de datos y mejor barajado durante el entrenamiento.
- Menos aumentaciones por epoch (más eficiencia de muestras).
- Cambio de optimizador de AdamW a NorMuon, con un AdamW auxiliar.
- Flash attention con varlen training y kernels de flex attention para inferencia.
- La función de pérdida ahora cubre solo los tokens de salida (estilo supervisado), lo que subió el puntaje de 40% a 44%.
La parte contraintuitiva: menor loss de test, peor generalización
Uno de los hallazgos más interesantes que señala el autor es que ya no entrenar sobre los tokens de entrada (estilo supervisado puro) empeora la pérdida en el set de test, pero mejora el puntaje en el benchmark. Es decir, perseguir el menor val loss en un dataset pequeño puede ser una trampa metodológica, porque la métrica que bajas no siempre es la métrica que te importa en producción.
Para un founder que itera modelos propios, la lectura es directa: mide contra la tarea de negocio, no contra la loss académica. Optimizar el surrogate equivocado es probablemente el error más caro en proyectos de IA aplicada.
Ablaciones: qué aporta cada pieza al resultado final
La fuente incluye una tabla de ablaciones que vale la pena reproducir porque muestra cuánto pesa cada componente:
- Entrenar también sobre los inputs baja el score a aproximadamente 39%.
- Restringir el train solo a ARC-1 + ConceptARC rinde alrededor de 40%.
- Cambiar de 3D RoPE a 1D RoPE derrumba el score a cerca de 24%.
- Quitar los embeddings por tarea lo baja también a cerca de 24%.
- Estilo CompressARC (entrenar desde cero en cada tarea por separado, no supervisado) cae a cerca de 18%.
- CompressARC supervisado se queda en cerca de 15%.
La conclusión operativa del autor: la mayor parte del rendimiento viene de buenas representaciones (3D RoPE + embedding por tarea), no de cambios exóticos.
Críticas que recibió el enfoque (y por qué el autor las rebate)
El post original enumera y responde a las críticas más repetidas en X y en foros de investigadores:
- «Entrenar sobre los puzzles de evaluación es trampa». Falso: ARC es un benchmark de metalearning; las etiquetas del test nunca se entrenan, solo los inputs.
- «Entrenar sobre los inputs del eval filtra información». Falso: se llama razonamiento transductivo y está estudiado desde Vapnik. La propia release nueva elimina incluso esa práctica y el score baja solo a 39%.
- «Va contra la política del benchmark». Falso: la política prohíbe que el diseñador humano use el eval set para crear sesgos, no que el modelo entrene sobre él.
- «El costo por tarea no es comparable». Parcialmente válido: el autor ahora muestra costo total de por vida y se compara solo con TRM, HRM y CompressARC, no contra LLMs.
El autor también cuestiona que TRM se publicite como un modelo de 7M de parámetros cuando entrena O(100M+) de embeddings, lo que considera marketing engañoso.
Qué significa esto para tu startup
La conclusión para founders que construyen producto con IA no es «corre a entrenar tu propio modelo pequeño en ARC», sino tres lecturas tácticas:
- El techo de hardware accesible subió. Un experimento serio de fine-tuning o entrenamiento desde cero cabe en una sola 5090 por unas pocas horas. Eso cambia los cálculos de POC para equipos chicos en LATAM y España: ya no hace falta reservar un cluster para validar hipótesis de arquitectura.
- Sample efficiency es el cuello de botella real. Si tu modelo necesita miles de ejemplos por tarea para producción, el cuello de botella no es el algoritmo, son los datos. Invertir en mejor representación y en datos limpios suele rendir más que escalar parámetros.
- Mide contra la tarea, no contra la loss. La evidencia de que menor val loss puede coincidir con peor puntaje en la métrica real debería ser un mantra en tus tableros de evaluación.
Dos acciones concretas que podés implementar esta semana:
- Audita tus pipelines de evaluación: ¿estás optimizando el surrogate correcto? Si tu métrica de negocio (tasa de resolución, NPS, conversión) no está en el dashboard, empezá por ahí.
- Corré una prueba de entrenamiento desde cero en una tarea acotada con una sola GPU de gama alta para medir tu propia sample efficiency. El resultado te dirá cuánto vale realmente tu data pipeline actual.
Fuentes
🤖 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
