GPT-6 Astra исправила веса Qwen и подняла результат MATH-500 до 48,1%

Модель пишет длинное рассуждение, повторяет один и тот же шаг и заканчивает ответ только потому, что кончился лимит токенов. Для разработчика это знакомая поломка: запрос оплачен, пользователь ждёт, полезного результата нет. Исследователи MIT CSAIL показали способ вмешаться в такую ошибку — поручить другой языковой модели изменить веса проблемной сети.

В их эксперименте GPT-6 Astra исправила Qwen3.5-0.8B, изменив 0,016% параметров. Результат на MATH-500 вырос с 7,9% до 48,1%. Практический интерес здесь — возможность искать конкретную причину сбоя внутри модели. Однако превращать этот опыт в обещание «любая нейросеть чинится одним запросом» рано.

Что именно исправила Astra

По отчёту исследователей, Astra получила доступ к весам через Python и могла проверять поведение Qwen на тренировочных задачах. Градиентное обучение было запрещено. Лучший результат получен при бюджете в 50 проверочных прогонов.

Astra связала повторения с определённым направлением в выходах двух внутренних слоёв и скорректировала соответствующие веса. Доля ответов MATH-500, упиравшихся в лимит длины, снизилась с 93% до 33,1%. Настройки генерации при сравнении сохранили одинаковыми.

Представьте калькулятор, который умеет выполнять вычисления, но после каждого действия снова запускает предыдущий шаг. Если убрать этот сбой, доля правильных завершённых ответов вырастет без добавления новых правил арифметики. Это полезная аналогия для понимания результата, хотя устройство языковой модели гораздо сложнее калькулятора.

Авторы отдельно проверили Gemma 3 270M, которая редко зацикливалась. Убедительно улучшить её математические результаты таким способом не удалось. Поэтому главный вывод исследования касается устранения помех уже существующей способности решать задачи.

Почему одного процента точности мало

Для команды, которая использует локальную модель, этот подход интересен прежде всего как способ диагностики. Прежде чем выбирать между сменой модели, новым промптом и дообучением, полезно понять, какие ошибки преобладают. Повторение текста, неверное вычисление и пропуск требования пользователя выглядят одинаково в итоговой метрике: задача провалена. Но исправления для них могут понадобиться разные.

Допустим, вы строите помощника для обработки обращений. Соберите примеры неудачных ответов и посмотрите, как именно они ломаются. В одних модель может ходить по кругу, в других — уверенно придумывать сведения, в третьих — терять нужный формат. Если смешать всё в один показатель качества, будет трудно объяснить даже удачное изменение.

Для повторов имеет смысл отдельно считать долю завершённых ответов, длину генерации и время ожидания. Для содержательных ошибок потребуется проверка правильности. Для формата — проверка структуры ответа. Такой разбор помогает сформулировать задачу ремонта и заранее определить, что считать успехом.

Это также меняет разговор с продактом. Рост тестового балла сам по себе ещё не показывает, стал ли помощник полезнее клиенту. Стоит заранее выбрать рабочий показатель: например, сколько обращений система обработала правильно и сколько из них потребовало повторного запуска.

Как проверять такой ремонт у себя

Если команда решит воспроизвести подход, разумно начать с отдельной копии модели и небольшого набора хорошо разобранных сбоев. Исходные веса, настройки генерации и результаты нужно сохранить: иначе сравнение быстро превратится в спор о впечатлениях.

Контрольные задания стоит отделить от примеров, на которых подбирается правка. Затем проверить не только проблемный сценарий, но и обычные рабочие запросы. Например, устранение повторов у помощника поддержки должно сопровождаться проверкой точности фактов, соблюдения инструкций и корректности отказов. Это предложенный порядок проверки, а не результат эксперимента MIT.

Для разработчика с доступом к весам новость даёт направление для эксперимента. Для команды, работающей через закрытый API, ближайшая польза — лучше разбирать собственные сбои и оценивать исправления поставщика. А основателю стоит удержаться от преждевременного пересчёта бюджета на обучение: сначала нужно показать, что конкретная правка устойчиво помогает именно его продукту.