NERVE: как приглушить «SQL-нейроны» в Qwen 27B и починить запросы 1С без дообучения

Знакомая боль: вы дообучили открытую модель на узкой предметной области, а она всё равно регулярно ошибается в одном и том же месте. Новые датасеты почти не помогают, а каждый круг сбора данных стоит недель. Автор статьи на Habr столкнулся ровно с этим на Qwen 3.8 27B, дообученной под 1С:Предприятие. Код на встроенном языке модель пишет сносно, а вот язык запросов 1С путает с SQL: смешивает виртуальные таблицы, ставит параметры не туда, тащит конструкции, которых в 1С нет. Дополнительные датасеты дали меньше 1% прироста accuracy.

Гипотеза: мешает SQL

Лексемы у двух языков похожи: SELECT, JOIN, WITH. Автор предположил, что знания о настоящем SQL тянут модель к неверному ответу. Тогда вместо переобучения можно найти конкретные нейроны, которые это делают, и ослабить их. Так появился конвейер NERVE.

Нейроном здесь называется одна компонента промежуточного вектора MLP-блока (в Qwen 3.8 27B их 17 408 на слой) вместе со столбцом матрицы W_down, в который она пишет. Умножить столбец на m значит умножить активацию нейрона на m на каждом токене. Значение 0 выключает нейрон, 0,5 ослабляет вдвое. Архитектура не меняется, правка переживает квантизацию и экспорт в GGUF. Всего кандидатов около 1,1 млн (64 слоя), так что перебор вслепую бессмыслен.

Как устроен конвейер

1. Берутся пары «правильный / ошибочный запрос», как для DPO, около двух тысяч штук. Так как ответы совпадают на 90–95%, сравниваются только отличающиеся токены, которые находит difflib. Усреднение по всему ответу размыло бы сигнал.
2. Хуки на входе каждого down_proj собирают среднюю активацию нейронов на этих токенах. По всем парам считаются среднее, t-статистика и согласованность знака. Ранжирование идёт по |t|, чтобы две-три аномальные пары не создавали ложных лидеров.
3. Градиентная атрибуция («градиент × вход») прогнозирует, как изменится margin, то есть насколько модель предпочитает правильный ответ ошибочному, если нейрон приглушить. Нейрон с отрицательным вкладом считается «ошибочным». Атрибуция дорогая, поэтому строится на 512 парах.
4. Жадный отбор пробует кандидатов по одному поверх уже принятых. Правка остаётся, если margin вырос минимум на 0,002 на токен, а nll на правильных ответах просел не более чем на 2%. Если откатывать неудачные, суммарные линейные прогнозы перестают быть нужны.

Главная защита от переобучения: val делится на две половины по хешу запроса. Решения принимаются на одной, итог проверяется на другой. Набор считается подтверждённым, только если на контроле margin вырос, а nll не ухудшился сверх допуска. Подтверждённые правки копятся в JSON-файле рядом с картой и исключаются из будущих кандидатов.

Что поймали по дороге

Первая ошибка: карту строили по отличающимся токенам, а качество мерили по всему ответу. Эффект разбавлялся примерно в 25 раз. Исправление: одна и та же diff-маска для карты и проверки. Вторая находка: усиление «хороших» нейронов чаще ломало nll, а подавление ошибочных давало устойчивый рост margin, поэтому режим suppress стал основным. Ещё один наблюдаемый факт: возбуждение на ошибочных ответах есть почти в каждом слое, то есть SQL-подобное поведение размазано по всей глубине сети.

Ограничения и вывод

В доступном тексте нет итоговых чисел: насколько вырос accuracy на контроле, мы не знаем. Это одна модель и один датасет, метод основан на линейном приближении, которое при взаимодействии правок ломается, поэтому нужен жадный отбор. Для практиков идея всё равно полезна: если у дообученной модели устойчивая ошибка «подмешивания» соседнего домена, есть дешёвая альтернатива очередному кругу SFT. Нужны preference-пары, один forward-backward по выборке и честная контрольная половина. Ключевой урок: считайте метрику на тех же токенах, по которым строили карту, и всегда проверяйте на данных, не участвовавших в отборе.