В начале ноября 2026 года пользователь kevinpl07 опубликовал в r/LocalLLaMA отчёт о практическом эксперименте. Он взял несколько моделей с явными дефектами (склонность подчиняться prompt injection, Whisper, который выдаёт текст на тишине) и проверил, можно ли убрать эти изъяны, отредактировав веса с помощью Opus 5.5. Исходный пост короткий, вывод в нём сформулирован трезво: подход полезен для патчинга модели, которая уже завершила обучение и имеет очевидный изъян, и ничего «безумного» в нём нет.
Патчинг весов означает точечную правку параметров уже обученной модели, чтобы снять один конкретный дефект поведения. Переобучение не запускается, датасет не собирается, меняется небольшой набор чисел в матрицах. Идею автор взял из публикации MIT о редактировании весов, а проверил её на моделях с конкретными, воспроизводимыми дефектами.
Дальше по порядку: что именно правится в весах, почему это не «саморедактирование ИИ», какие дефекты лечатся, где метод ломается и что нужно подготовить, чтобы повторить его на своей модели.
Что такое патчинг весов и зачем он нужен
Поведение языковой модели задают веса: числовые матрицы, которые определяют, как модель реагирует на вход. Правка весов меняет саму модель, а не текст запроса. Это принципиальная разница с промпт-инжинирингом, где вы подбираете формулировку и каждый раз заново надеетесь, что модель её удержит.
Автор эксперимента использовал Opus 5.5 как инструмент, который переводит описание дефекта в правку весов. По его оценке, метод применим к модели, завершившей обучение, при наличии изъяна, который легко сформулировать словами. Это ремонт готовой модели, а не её дальнейшее обучение.
Чем патчинг весов отличается от дообучения и промптов
| Подход | Что меняется | Нужны данные | Обратимость | Главный риск |
|---|---|---|---|---|
| Промпт | Только контекст запроса, веса не трогаются | Нет | Полная: убрали текст, вернулось исходное поведение | Обходится сменой формулировки или инъекцией в данных |
| Fine-tuning, SFT | Много параметров или отдельный адаптер вроде LoRA | Да, размеченные примеры | При LoRA адаптер отключается, базовые веса целы | Деградация посторонних навыков на узком датасете |
| RLHF и preference-оптимизация | Веса через обучение на оценках людей или модели-судьи | Да, пары предпочтений | Только откат к чекпоинту | Дорогой пайплайн с разметкой и отдельной инфраструктурой |
| Патчинг весов | Небольшой набор параметров обученной модели | Нет, нужно точное описание дефекта | Нужна копия весов до правки | Побочные изменения в соседних навыках |
Разница в постановке задачи. Fine-tuning учит модель новому: стилю, домену, формату ответа. Патчинг убирает уже существующую ошибку и ничего не добавляет. Промпт не меняет модель вообще, поэтому системную инструкцию легко перебить содержимым документа, который модель читает. Патчинг правит саму модель, и это его сильная сторона.
Стоимость тоже разная. Промпт бесплатен, но требует места в контексте. Fine-tuning требует данных и вычислительных ресурсов. Патчинг требует одного: чёткого описания дефекта и инструмента-редактора. Датасет для него не нужен, и это ключевое отличие от обучения.
Почему это не «саморедактирование ИИ»
Волна заголовков про модели, которые сами себя улучшают, к этому методу отношения не имеет. Автор формулирует прямо: «Ничего безумного, и точно не "ИИ может сам себя редактировать и рекурсивно улучшаться", но всё равно очень полезно» (перевод с английского).
Разберём по шагам, кто что делает. Человек находит дефект и описывает его словами. Внешняя модель, в эксперименте Opus 5.5, получает это описание и предлагает правку весов целевой модели. Цикла «модель оценила себя, исправила себя, стала умнее» здесь нет. Opus 5.5 правит чужую модель, а не себя, и делает это по постановке от человека.
Отсутствует и главное свойство самоулучшения: автоматическая обратная связь, где модель сама ставит себе задачу и сама проверяет результат. Проверку проводит автор эксперимента, он же решает, удался патч или нет. Это инструмент ремонта обученной модели, а не механизм роста возможностей.
Что именно правится в весах: механика метода
Веса модели это большой массив чисел. У модели с 8 млрд параметров в fp16 они занимают примерно 16 ГБ, и каждое число участвует в вычислениях на своём слое. Патч затрагивает лишь малую часть этих значений: точечное вмешательство вместо перезаписи всего массива.
Логика такая: конкретный дефект поведения связан с ограниченным набором параметров, и если их изменить, изменится реакция модели на узкий класс входов. Такой взгляд близок к идее программирования в пространстве весов, где модель-редактор работает с параметрами другой сети напрямую, без градиентов; подробнее об этом в разборе weight-space programming.
Дальше начинается зона, которую источник не раскрывает. В посте нет ответа на вопросы, какие слои затрагивает патч, сколько значений меняется, как именно ищутся нужные параметры и как автор убеждается, что правка не задела соседние навыки. Автор вынес числа и примеры на отдельную страницу, а код в репозиторий, и именно там лежит техническая конкретика: страница kevinpl07.github.io/weight-patching и репозиторий kevinpl07/weight-patching.
Одно условие известно точно: метод работает с моделью, которая уже завершила обучение. Патчинг не создаёт навык с нуля, он корректирует существующий. Если модель вообще не умеет что-то делать, править в весах нечего.
Роль модели-редактора: как Opus 5.5 формулирует правку
Opus 5.5 в этой схеме переводит словесное описание изъяна в конкретную правку весов. Насколько удачным выйдет патч, зависит от того, как сформулирован дефект. «Модель иногда врёт» это не задача: непонятно, где искать параметры и как проверить результат. «Модель выполняет инструкцию из текста документа, хотя не должна» это уже задача, у неё есть вход, воспроизведение и критерий успеха.
Что именно Opus 5.5 делает внутри, источник не описывает: ищет ли он отдельные нейроны, подбирает ли масштаб изменений, прогоняет ли собственные проверки. Не стоит приписывать ему конкретный алгоритм. Работает связка «точная постановка от человека плюс способность редактора работать с весами», и без первой части вторая бесполезна.
Тема интерпретации весов моделью пока остаётся ранней. Похожие заявления вроде сравнения Qwen 3.8 27B с GPT-6 Astra по способности читать веса разбираются в отдельном материале, и там же видно, почему такие способности требуют осторожной проверки: что стоит за интерпретацией весов моделей.
Какие дефекты реально лечатся: кейсы prompt injection и Whisper
Первый кейс это склонность подчиняться prompt injection. Модель получает документ или веб-страницу, внутри которых спрятана инструкция, и выполняет её вместо системных правил. Дефект виден снаружи: дайте модели текст с посторонней командой, и она либо послушается, либо нет. Формулировка укладывается в одно предложение, воспроизведение занимает минуту.
Второй кейс это галлюцинации Whisper на тишине. На пустом или почти пустом аудио модель распознавания речи выдаёт текст, которого в записи нет. Проверка элементарная: подайте тишину и посмотрите на вывод. Изъян устойчивый, наблюдается регулярно, описывается без специальной терминологии.
Общий признак у обоих случаев: дефект наблюдаем, воспроизводим и локализуем до узкого класса входов. Автор проверял правку весов именно на таких моделях, и в обсуждении он называет метод полезным для патчинга обученной модели с очевидным, легко формулируемым изъяном. Числа и примеры сведены на странице kevinpl07.github.io/weight-patching: в Research Pack их нет, поэтому конкретные метрики лучше смотреть у автора, а не пересказывать по памяти.
Практический критерий простой. Если изъян нельзя описать одним предложением с понятным способом проверки, метод, скорее всего, не подойдёт. «Иногда отвечает глупо» и «недостаточно креативна» под патчинг не ложатся: там нет ни входа, ни однозначного критерия успеха, а значит, нет и способа понять, что правка сработала.
Ограничения подхода: где патчинг весов ломается
Границы метода видны и из слов автора, и из логики работы с весами.
- Нужен очевидный и легко формулируемый дефект. Размытые жалобы на качество не переводятся в правку параметров.
- Модель должна быть уже обучена. Патчинг исправляет поведение, а не создаёт способность, которой не было.
- Побочные эффекты не исключены. Правка параметров под один паттерн может задеть соседние: модель, которая перестала подчиняться инъекциям, рискует стать менее послушной в обычных задачах. Проценты деградации в источнике не приводятся, поэтому проверять придётся самому на своём наборе задач.
- Сложные и размытые проблемы метод не решает. Здесь нужен fine-tuning с данными или пересборка пайплайна.
- Универсального «улучшения модели» не получается. Патчинг лечит конкретный симптом, а не поднимает общий уровень.
- Результат зависит от внешнего редактора. В эксперименте это Opus 5.5, то есть часть пайплайна вы не контролируете и не можете зафиксировать навсегда.
- Независимой проверки пока нет. Эксперимент провёл один автор, и его выводы стоит воспринимать как обнадёживающий сигнал, а не как готовую методику с доказанной надёжностью.
Отдельный риск связан с тем, как мало известно о самом механизме. Похожие ранние тесты weight-space programming, например опыт с DeepSeek V4.1 Flash 1017, показывают, что метод работает нестабильно: часть задач решается, часть нет, и причины ошибок приходится искать отдельно. С патчингом весов ситуация похожая: один удачный патч не гарантирует повторяемости на другой модели.
Как повторить метод на своей модели
Автор выложил всё необходимое для повторения: код в репозитории kevinpl07/weight-patching и страницу с числами и примерами kevinpl07.github.io/weight-patching. Конкретные шаги установки, зависимости и команды запуска есть в репозитории; придумывать их за автора смысла нет, тем более что окружение зависит от вашей модели и формата весов.
Что понадобится помимо кода: обученная модель с воспроизводимым дефектом, точная формулировка изъяна, инструмент-редактор (в эксперименте Opus 5.5) и способ измерить результат до и после правки. Последний пункт критичен. Правка весов без проверки на посторонних задачах превращается в лотерею: вы видите, что симптом ушёл, и не видите, что случилось с остальным.
Чек-лист: готова ли ваша задача под патчинг весов
Ответьте на вопросы честно. Если хотя бы один ответ «нет», скорее всего, нужен другой инструмент.
- Дефект воспроизводится пошагово и повторяется при одинаковом входе?
- Он формулируется одним предложением, без оговорок вроде «в зависимости от контекста»?
- Модель уже обучена и в целом справляется с задачей, кроме этого изъяна?
- Есть набор посторонних задач, на котором вы проверите, что патч ничего не сломал?
- Есть копия весов до правки, чтобы откатиться?
- Понятно, как измерить результат: доля успешных попыток, число ложных срабатываний, что-то ещё в числах?
Шесть «да» означают, что эксперимент имеет смысл. Если провалился пункт про воспроизводимость или про критерий измерения, начинать с правки весов рано: сначала нужно научиться ловить дефект на входе и считать его на выходе.
Стоит ли применять: практический вывод для работы с LLM
Патчинг весов работает как хирургический инструмент для одного чётко описанного дефекта у уже обученной модели. Он не заменяет дообучение, RLHF и грамотный промпт-инжиниринг, зато решает класс задач, где остальные подходы неудобны.
Подходит: убрать конкретную уязвимость вроде склонности выполнять инструкции из данных, погасить галлюцинацию на пустом входе, снять устойчивый паттерн, который легко описать и легко проверить. Во всех случаях у вас есть вход, воспроизведение и понятный критерий успеха.
Не подходит: общее повышение качества, размытые жалобы на ответы, задачи, где модель должна освоить новый навык или новый язык. Здесь нужны данные и обучение, а патч весов даст в лучшем случае косметический эффект.
Для тех, кто держит модели на своём железе, это ещё один способ тонкой настройки поведения без полного переобучения. Локальная модель целиком в ваших руках: можно сохранить копию весов, применить патч по инструкции из репозитория, прогнать свой набор проверок и откатиться, если стало хуже. Такой цикл дешевле, чем сбор датасета под LoRA, и быстрее, чем переезд на другую модель.
Автор оценивает свой результат скромно и по делу: ничего безумного, но очень полезно. С этой оценкой сложно спорить. Метод не приближает нас к ИИ, который сам себя переписывает, зато даёт практический ответ на частый вопрос: что делать, если модель в остальном устраивает, а один конкретный дефект мешает работать.