Зачем просить LLM менять веса другой модели?
В твиттере нашумела работа про Weight-Space Programming: LLM читает и меняет веса других нейросетей, а маленькие сети может писать с нуля.
Откуда столько энтузиазма? В демо авторов Astra исправляет зацикливание Qwen, изменяя небольшую часть весов. CTO Legora показывает, как Fable пишет веса маленькой сети для проверки юридических ссылок. Ну и, разумеется, без сингулярности рекурсивного самоулучшения не обошлось: модели меняют сами модели, вместо того чтобы только писать код для их обучения.
Ну, я не смог пройти мимо: захотелось понять, что это даёт прикладному AI инженеру. Например, можно ли настроить маленькую модель под outreach конкретного клиента, вместо того чтобы передавать инструкции в каждом запросе?
Сразу результат: в нашем тесте промпт с двумя примерами оказался лучше правок обоих агентов. Хотя поведение поменять всё-таки получилось.
Рассказываю:
1) Взяли локальную Qwen3-4B и задали 6 правил, как писать холодные сообщения: например, начинать сообщение с факта о получателе, не звать на созвон сразу и тп.
2) Попросил Astra и Fable независимо подготовить правки весов. У каждого было по три попытки с проверкой на валидации. Выбранные варианты зафиксировали и проверили на 24 новых вымышленных брифах. Вышеуказанные правила "отредактированным" моделям уже не передавали.
Два LLM-судьи проверяли соблюдение всех правил и опору на факты. Итого:
1) Если подаем промпт с 2мя примерами - 18 из 24 сообщений зачёт.
2) Обычный файнтюнинг LoRA - 6 из 24.
3) Правки весов от Astra и Fable - 0 из 24 :(
После правки Fable модель начинала с факта без приветствия в 19 из 24 случаев, до неё - ни в одном —> то есть правка точно сработала. Но весь набор правил так и не освоился. Вот пара примеров:
1) В одном письме «Hi Luca» превратилось в «Luka, I came across your recent update…». Приветствие ушло, но модель заодно перепутала Luca с Luka. Нужного вопроса и предложения чеклиста в письме не было.
2) В другом после правки оставалось «I’d be happy to connect if you’re open to a quick chat». Исходная Qwen с промптом на тот же бриф спрашивала «How do you currently assign ownership when a parts request is flagged for routing?» и предлагала «a three-point checklist».
В общем, мне пока не очень понятен восторг, но попробовал поразгонять с дружбаном про плюсы и минусы такой on the fly прошивки моделей:
Из плюсов:
1) Один раз настроить повторяющееся поведение и не таскать инструкции в каждом запросе. Меньше контекста, возможно, меньше latency и затрат — при условии сохранения качества.
2) Если данных мало для файнтюна, но задачу можно описать словами, то LLM может попробовать перенести свои знания в веса маленькой модели.
3) Попробовать починить конкретный сбой, с которым промпт не справляется, не дожидаясь следующего релиза модели.
4) (возможно) Правила не лежат открытым текстом в промпте. Хотя это не гарантия секретности: их можно попытаться восстановить по ответам или весам.
Из минусов:
1) Инструкции проще прочитать, поправить и обсудить с заказчиком. По диффу чисел гораздо сложнее понять, что именно поменяли.
2) Правка может задеть и другие задачи этой версии модели. Нужно проверять побочные эффекты, а не только нужное улучшение.
3) Под разных клиентов и новые версии базовой модели могут понадобиться отдельные правки и проверки. Всё это должно окупиться относительно обычного промпта или дообучения.
В общем, непонятно...
А у вас какие идеи зачем это нужно?