GPT-6 Astra corrigió los pesos de Qwen y elevó su resultado en MATH-500 al 48,1 %

Un modelo escribe un razonamiento largo, repite el mismo paso una y otra vez y termina su respuesta solo porque se agotó el límite de tokens. Para un desarrollador es una avería conocida: la solicitud está pagada, el usuario espera y no hay un resultado útil. Investigadores del MIT CSAIL han mostrado una forma de intervenir en este error: encargar a otro modelo de lenguaje que modifique los pesos de la red problemática.

En su experimento, GPT-6 Astra corrigió Qwen3.5-0.8B al modificar el 0,016 % de los parámetros. El resultado en MATH-500 subió del 7,9 % al 48,1 %. El interés práctico está en la posibilidad de buscar una causa concreta del fallo dentro del modelo. Sin embargo, aún es pronto para convertir esta experiencia en la promesa de que «cualquier red neuronal se arregla con una sola consulta».

Qué corrigió exactamente Astra

Según el informe de los investigadores, Astra obtuvo acceso a los pesos mediante Python y podía comprobar el comportamiento de Qwen en tareas de entrenamiento. El entrenamiento por gradiente estaba prohibido. El mejor resultado se logró con un presupuesto de 50 ejecuciones de verificación.

Astra vinculó las repeticiones con una dirección determinada en las salidas de dos capas internas y ajustó los pesos correspondientes. La proporción de respuestas de MATH-500 que alcanzaban el límite de longitud bajó del 93 % al 33,1 %. Los ajustes de generación se mantuvieron idénticos en la comparación.

Imagine una calculadora que sabe hacer cálculos, pero tras cada operación vuelve a ejecutar el paso anterior. Si se elimina ese fallo, la proporción de respuestas correctas y completas aumentará sin añadir nuevas reglas de aritmética. Es una analogía útil para entender el resultado, aunque un modelo de lenguaje es mucho más complejo que una calculadora.

Los autores probaron por separado Gemma 3 270M, que rara vez entraba en bucle. No lograron mejorar de forma convincente sus resultados matemáticos con este método. Por ello, la conclusión principal del estudio se refiere a eliminar los obstáculos a una capacidad ya existente para resolver problemas.

Por qué un punto porcentual de precisión no basta

Para un equipo que usa un modelo local, este enfoque es interesante ante todo como método de diagnóstico. Antes de elegir entre cambiar de modelo, un nuevo prompt y el ajuste fino, conviene entender qué errores predominan. La repetición de texto, un cálculo incorrecto y la omisión de un requisito del usuario se ven igual en la métrica final: la tarea fracasó. Pero pueden requerir correcciones distintas.

Supongamos que construye un asistente para gestionar solicitudes de clientes. Reúna ejemplos de respuestas fallidas y observe exactamente cómo se rompen. En unos casos el modelo puede dar vueltas en círculo, en otros inventar datos con aplomo y en otros perder el formato necesario. Si se mezcla todo en un único indicador de calidad, será difícil explicar incluso un cambio exitoso.

Para las repeticiones tiene sentido medir por separado la proporción de respuestas completas, la longitud de la generación y el tiempo de espera. Los errores de contenido requieren una comprobación de corrección. Para el formato, una verificación de la estructura de la respuesta. Este análisis ayuda a formular la tarea de reparación y a definir de antemano qué se considera éxito.

Esto también cambia la conversación con el responsable de producto. Un aumento de la puntuación en una prueba no demuestra por sí solo que el asistente sea más útil para el cliente. Conviene elegir de antemano un indicador de trabajo: por ejemplo, cuántas solicitudes procesó correctamente el sistema y cuántas de ellas requirieron una nueva ejecución.

Cómo verificar una reparación así en su caso

Si un equipo decide reproducir el enfoque, es razonable empezar con una copia separada del modelo y un pequeño conjunto de fallos bien analizados. Hay que conservar los pesos originales, los ajustes de generación y los resultados: de lo contrario, la comparación se convertirá pronto en una discusión de impresiones.

Las tareas de control conviene separarlas de los ejemplos con los que se elige la corrección. Después hay que comprobar no solo el escenario problemático, sino también las solicitudes habituales de trabajo. Por ejemplo, eliminar las repeticiones en un asistente de soporte debe ir acompañado de comprobaciones de precisión de los hechos, cumplimiento de instrucciones y corrección de las negativas. Este es un orden de verificación propuesto, no un resultado del experimento del MIT.

Para un desarrollador con acceso a los pesos, la noticia ofrece una dirección para experimentar. Para un equipo que trabaja mediante una API cerrada, el beneficio más cercano es analizar mejor sus propios fallos y evaluar las correcciones del proveedor. Y un fundador debería abstenerse de recalcular prematuramente el presupuesto de entrenamiento: primero hay que demostrar que una corrección concreta ayuda de forma estable precisamente a su producto.