GPT-6 Astra corrigió los bucles de Qwen: la precisión subió del 7,9% al 48,1%

Un modelo local recibe un problema matemático, empieza a razonar y se atasca en repeticiones. Los tokens se consumen, el usuario espera y la respuesta completa no llega. Un equipo del MIT CSAIL ha mostrado una forma experimental de corregir este fallo: encargar a otro modelo de lenguaje que localice el origen del bucle y ajuste los parámetros numéricos de la red afectada. Para los desarrolladores, ofrece una pista útil: a veces, la baja precisión se debe a que el modelo no termina de resolver el problema.

En el experimento publicado, GPT-6 Astra editó Qwen3.5-0.8B. Tras la intervención, su resultado en la prueba matemática MATH-500 pasó del 7,9% al 48,1%. Los autores denominaron al enfoque weight-space programming: programación a través de los pesos del modelo. Los resultados y las condiciones del experimento se detallan en la publicación de los investigadores.

Qué se corrigió exactamente

Los pesos son los números que determinan cómo procesa una red neuronal los datos de entrada. Normalmente se modifican durante el entrenamiento. En este caso, el agente recibió acceso a los parámetros y la posibilidad de poner a prueba hipótesis, pero se le prohibió el ajuste fino convencional mediante el cálculo de gradientes.

Un ejemplo sencillo ilustra el problema: el modelo ya ha obtenido la fórmula necesaria, pero vuelve a explicar el paso anterior y regresa a él una vez más. La respuesta se interrumpe cuando se agota el número de tokens permitido. En una evaluación, esa ejecución puede considerarse fallida aunque la parte útil de la solución ya haya aparecido.

Según los investigadores, el agente encontró en dos capas de Qwen un componente que sostenía las repeticiones y redujo su contribución. El cambio afectó a solo el 0,016% de los parámetros. El proceso se asemeja a la búsqueda de una avería concreta: primero se identifica dónde surge el comportamiento no deseado y después se comprueba si una pequeña intervención ayuda.

El interés práctico reside en la propia secuencia de trabajo. El agente analiza la arquitectura de la red, propone una explicación del fallo, modifica parámetros y recibe información sobre el resultado. Para un equipo que mantiene su propio modelo, podría ser una herramienta adicional de diagnóstico. El experimento todavía no ofrece una receta universal para corregir cualquier repetición.

Por qué la mejora de precisión exige matices

Los autores vinculan expresamente la mejora con la eliminación de los bucles. Por tanto, el resultado no puede interpretarse automáticamente como la adquisición de nuevos conocimientos matemáticos. Si antes el modelo no llegaba a la respuesta final, eliminar ese obstáculo puede bastar para elevar drásticamente su puntuación.

La diferencia es importante para un producto. El usuario necesita un resultado completo, y corregir las repeticiones puede ser muy útil. Pero un responsable de producto que prometa, tras esta intervención, una mayor capacidad de razonamiento matemático en general deberá comprobar esa promesa por separado con las tareas de su servicio.

El trabajo incluye una prueba reveladora con otro modelo pequeño, Gemma 3 270M. Los investigadores no lograron una mejora comparable. Este resultado negativo limita la conclusión: corregir con éxito un fallo muy marcado no significa que el agente haya aprendido a mejorar de forma fiable cualquier red.

Además, prescindir del entrenamiento adicional no hace que el procedimiento sea gratuito. El análisis, las ejecuciones de prueba y la evaluación de los resultados requieren cómputo. Al comparar este enfoque con otras formas de corregir el problema, el equipo tendrá que tener en cuenta todos esos costes. También importa el coste de equivocarse: incluso un pequeño cambio en los parámetros debe evaluarse en el comportamiento global del modelo, incluidas las tareas para las que se eligió originalmente.

Qué comprobar en tu propio modelo

Conviene empezar por los registros de respuestas fallidas. ¿Con qué frecuencia se repite el modelo? ¿Cuántas solicitudes terminan al alcanzar el límite? ¿Se diferencian estos casos de los errores habituales de cálculo o de datos? Etiquetarlos de esta manera ayuda a entender qué problema hay que resolver realmente.

Después hace falta un conjunto de pruebas que el agente no utilice al seleccionar los cambios. Debe servir para comparar la calidad de las respuestas, la longitud de la generación y el tiempo de espera antes y después de la intervención. También conviene comprobar por separado los flujos de trabajo habituales: una mejora en una prueba puede ir acompañada de un empeoramiento en otra.

Para los equipos que trabajan mediante una API cerrada, la edición directa de los pesos no suele estar disponible. Pero la lección de diagnóstico también se aplica en ese caso: hay que distinguir entre errores de conocimiento, errores de razonamiento y respuestas incompletas. De ello depende el siguiente paso: cambiar el modelo, los ajustes de generación o el diseño de la propia aplicación. El experimento del MIT da motivos para examinar más de cerca las causas de los fallos antes de reservar presupuesto para un nuevo entrenamiento.