Un programa lineal iguala a Astra editando 8x menos pesos

Un programa lineal reemplaza 8 horas de búsqueda por un minuto

MIT CSAIL mostró que GPT-6 Astra, un modelo de lenguaje de frontera, puede editar los pesos de otra red neuronal sin gradientes ni bucle de entrenamiento: modificando el 0,016% de los pesos de Qwen3.5-0.8B, la precisión en MATH-500 pasó del 7,9% al 48,1%. Ahora el investigador Nathan Barry replicó esa misma edición con dos programas lineales (LP, la técnica clásica de optimización con restricciones) de alrededor de un minuto cada uno, y obtuvo resultados equivalentes cambiando 8 veces menos pesos.

Para un founder que entrena o ajusta modelos, la pregunta deja de ser solo «¿cuánta GPU necesito?» y pasa a ser «¿cuánto de este problema es búsqueda que se puede resolver con optimización clásica?».

¿Qué hizo MIT CSAIL con Astra?

El paper Sparks of Weight-Space Programming, firmado por Rikiya Takehi, Jayden Teoh, Alex Zhang y Omar Khattab, propone tratar los pesos como un objeto que un modelo grande puede leer y reescribir. Según el repaso del paper que publicó el medio especializado Big Data Digest, Astra identificó con solo mirar los pesos qué juego había aprendido a jugar una red pequeña, y generó desde cero los pesos de redes que superaron a otras entrenadas con 100 millones de pasos de PPO.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El caso más llamativo fue Qwen3.5-0.8B. Con el modo de razonamiento activado, ese modelo entra en bucles: repite las mismas líneas y nunca llega a la respuesta. El 93% de sus respuestas en MATH-500 agotaban el límite de 32.768 tokens. Astra diagnosticó que no le faltaban conocimientos de matemáticas, sino que un circuito de repetición interfería con el razonamiento, y editó dos capas del MLP. El resultado: MATH-500 del 7,9% al 48,1%, GSM8K del 13,8% al 67,1% e IFEval del 21% al 62,3%.

En Gemma 3 270M, que casi no entra en bucles, Astra no logró mejoras relevantes: según Big Data Digest, la mejora en MATH-500 no superó aproximadamente un punto porcentual. La conclusión de los autores es que editar pesos puede quitar un obstáculo que escondía una capacidad, pero no añadir una que el modelo no tenía.

¿Por qué elegir qué pesos editar es un problema lineal?

Los transformers usan conexiones residuales: cada capa suma su salida a la entrada en lugar de reemplazarla. Ese vector compartido, el residual stream, tiene 1.024 dimensiones en este modelo. Cuando el modelo entra en bucle, ese vector se desplaza siempre en la misma dirección.

Astra encontró esa dirección u comparando el promedio del residual stream en textos de razonamiento productivo contra textos que entraban en bucle. Después editó la matriz down_proj de las capas 15 y 19 para que sus columnas dejaran de empujar hacia u: una resta del componente de cada columna a lo largo de esa dirección. Como todas las columnas cambian en múltiplos del mismo vector, el resultado es un cambio de rango 1.

Lo que queda por decidir es cuánto editar y en qué columnas. Y ahí está el punto: el empuje que recibe un token es lineal en ese vector de ajuste. Pedir «aleja los tokens que están en bucle» y «no toques los tokens productivos» son dos conjuntos de desigualdades lineales. Eso es, literalmente, un programa lineal.

Barry lo resolvió minimizando la norma L1, que tiende a producir soluciones dispersas: el LP elige las columnas y los montos al mismo tiempo. Astra había llegado a un resultado parecido probando a mano: 8 horas de búsqueda, dentro de un presupuesto de 50 pasadas hacia adelante, para encontrar ese vector. Encontrar la dirección u le había llevado 15 minutos.

Un detalle técnico que importa si quieres reproducirlo: el solver estándar HiGHS tardaba más de 20 minutos por resolución con estas restricciones, así que Barry escribió un solver en GPU basado en PDHG que llega a menos del 0,2% del óptimo en alrededor de un minuto.

¿Cuánto se gana con 8 veces menos pesos editados?

Estos son los números del test, medidos sobre datos que no se usaron para ajustar ni afinar nada:

	Pesos cambiados	GSM8K	MATH-500	IFEval
Modelo base	0	14,1	7,0	22,9
Edición de Astra	130.188	68,2	50,9	61,9
LP con dirección de Astra	16.291	69,6	51,7	59,7
LP con dirección heurística	16.271	65,4	47,8	60,4

Con la dirección de Astra, el LP iguala a la edición del agente en todos los benchmarks, dentro del margen de ruido, tocando 8 veces menos pesos. Con una dirección obtenida por un detector de repeticiones simple —sin ningún LLM involucrado— llega a cerca del 93% del resultado.

Dos hallazgos más que vale la pena retener. Primero: las 8 columnas que elige el LP comparten apenas 3 con las 64 de Astra en la capa 15 y 1 en la capa 19. Es decir, hay muchas soluciones dispersas válidas; lo que importa es el empuje total a lo largo de u. Segundo: la búsqueda sí importaba. Reutilizar la receta de Astra sobre la dirección heurística, sin volver a buscar, daba 44,5 en el dev set; el LP daba 54,7.

¿Editar los pesos o solo empujar la activación?

Hay un resultado que simplifica todo. Las 8 columnas del LP en la capa 15 están activas en el 89% de los tokens y el empuje que añaden apenas varía de un token a otro. O sea: la edición se parece mucho a un empuje constante a lo largo de u.

Y un empuje constante no necesita editar pesos. Se puede inyectar directamente en el residual stream en cada token, como vector de dirección (steering vector). A 1× de la fuerza promedio del LP, el vector recupera prácticamente todo el arreglo: 57,8 en el dev set y 50,8 en MATH-500, contra 62,5 y 53,2 del LP. La ventana es estrecha: a 0,5× vuelven los bucles y a 2× el razonamiento se rompe.

La diferencia práctica es solo de entrega: la edición del LP es un checkpoint normal, mientras que el vector necesita código extra en inferencia.

Qué significa esto para tu startup

Mide el bucle antes de gastar en fine-tuning. Si tu modelo pequeño falla, cuenta qué porcentaje de respuestas agota el límite de tokens repitiendo texto. En Qwen3.5-0.8B era el 93%. Si el número es alto, el problema puede ser un obstáculo removible y no una falta de conocimiento.
Prueba la vía barata primero. Un vector de dirección se testea en inferencia, sin tocar el checkpoint. Si a la fuerza correcta recupera el desempeño, te ahorras el pipeline de edición completo.
Antes de pagar horas de agente, prueba un LP. La búsqueda que a Astra le llevó 8 horas se resolvió con dos programas lineales de un minuto. Es determinista, reproducible y auditable.
Valida en un dev set separado. Barry ajustó los parámetros del LP en 128 problemas aparte y reportó todo lo demás sobre datos nunca usados para el ajuste. Sin esa separación, los números no significan nada.

¿Qué no prueba este experimento?

Es un solo modelo. El LP sigue dependiendo de Astra para elegir las capas, y los mejores resultados usan también su dirección. La dirección heurística llega lejos sin LLM, pero no del todo.

Además, como los bucles se arreglaban con un empuje constante, las restricciones por token del LP no terminaron importando demasiado. Un comportamiento que sí necesite cambiar unos tokens y dejar otros intactos sería una prueba mejor. Y todo esto se probó solo eliminando bucles: comportamientos como el rechazo o la adulación también se pueden dirigir con una sola dirección, pero llevarlo a los pesos sigue sin testearse.

Para un equipo con recursos limitados, la lectura es prudente: esto no reemplaza el entrenamiento. Pero abre una pregunta útil antes de comprar GPUs: ¿cuánto de tu problema es capacidad y cuánto es un bug de dirección?