Forwarded from То шо нейросети
🤏 LoRA всего с 13 параметрами!
В этой работе от известной запрещенной, как скоро весь телеграм, на территории РФ организации представлен метод, который доводит параметро-эффективное дообучение до абсурда: показано, что RL (в частности GRPO) способен раскрывать математическое рассуждение в LLM, обновляя всего 13 параметров Карл.
1) RL почти не требует ресурсов, чтобы работать. С GRPO на Qwen2.5-7B-Instruct 13 обучаемых параметров в bf16 дают 91% на GSM8K (базовый уровень — 76%). SFT при том же бюджете почти ничего не меняет.
2) Чем больше модель, тем она “программируемее” крошечными обновлениями. В статье показан чёткий тренд масштабирования: с ростом размера модели требуется всё меньше параметров, чтобы достичь 95% качества полного файнтюнинга. Модели на 7B нужно заметно меньше правок, чем модели на 3B, для той же задачи. Это намекает, что триллионные модели можно будет дообучать под конкретные задачи буквально парой байтов.
3) Техника основана на проекции крошечного обучаемого вектора через замороженные SVD-компоненты. Метод расширяет LoRA-XS: вместо обучаемой матрицы r×r используется вектор v, который проецируется через фиксированные случайные тензоры. В сочетании с шарингом весов между слоями это позволяет дойти вплоть до одного обучаемого параметра.
А вообще это все напоминает бородатый Extreme Learning.
4) Разрыв между SFT и RL при малой ёмкости — драматический. На GSM8K RL с 120 параметрами достигает 95% точности. SFT с тем же бюджетом — лишь 84%. При ещё меньших обновлениях разрыв только растёт. Авторы объясняют это с точки зрения теории информации: RL получает разреженный, но «чистый» сигнал (бинарную награду), тогда как SFT вынужден усваивать информацию всей последовательности, большая часть которой нерелевантна задаче.
5) Qwen2.5 стабильно требует примерно в 10 раз меньше параметров, чем Llama 3, для сопоставимого качества. При 1 параметре Qwen улучшает результат на 5% относительно базового, тогда как LLaMA почти не сдвигается. Авторы сами отмечают возможную контаминацию данных на этапе претрейнинга, а независимые исследования находили нетривиальное пересечение бенчмарков в обучающих данных Qwen.
Кода, как обычно, не дали.
@toshoseti
В этой работе от известной запрещенной, как скоро весь телеграм, на территории РФ организации представлен метод, который доводит параметро-эффективное дообучение до абсурда: показано, что RL (в частности GRPO) способен раскрывать математическое рассуждение в LLM, обновляя всего 13 параметров Карл.
1) RL почти не требует ресурсов, чтобы работать. С GRPO на Qwen2.5-7B-Instruct 13 обучаемых параметров в bf16 дают 91% на GSM8K (базовый уровень — 76%). SFT при том же бюджете почти ничего не меняет.
2) Чем больше модель, тем она “программируемее” крошечными обновлениями. В статье показан чёткий тренд масштабирования: с ростом размера модели требуется всё меньше параметров, чтобы достичь 95% качества полного файнтюнинга. Модели на 7B нужно заметно меньше правок, чем модели на 3B, для той же задачи. Это намекает, что триллионные модели можно будет дообучать под конкретные задачи буквально парой байтов.
3) Техника основана на проекции крошечного обучаемого вектора через замороженные SVD-компоненты. Метод расширяет LoRA-XS: вместо обучаемой матрицы r×r используется вектор v, который проецируется через фиксированные случайные тензоры. В сочетании с шарингом весов между слоями это позволяет дойти вплоть до одного обучаемого параметра.
А вообще это все напоминает бородатый Extreme Learning.
4) Разрыв между SFT и RL при малой ёмкости — драматический. На GSM8K RL с 120 параметрами достигает 95% точности. SFT с тем же бюджетом — лишь 84%. При ещё меньших обновлениях разрыв только растёт. Авторы объясняют это с точки зрения теории информации: RL получает разреженный, но «чистый» сигнал (бинарную награду), тогда как SFT вынужден усваивать информацию всей последовательности, большая часть которой нерелевантна задаче.
5) Qwen2.5 стабильно требует примерно в 10 раз меньше параметров, чем Llama 3, для сопоставимого качества. При 1 параметре Qwen улучшает результат на 5% относительно базового, тогда как LLaMA почти не сдвигается. Авторы сами отмечают возможную контаминацию данных на этапе претрейнинга, а независимые исследования находили нетривиальное пересечение бенчмарков в обучающих данных Qwen.
Кода, как обычно, не дали.
@toshoseti
🤯3❤2
experimentality
Как улучшить качество reasoning для LLM? Предлагается следующая стратегия. Для каждого вопроса сначала генерируется N/2 роллаутов. Если среди них присутствует хотя бы один некорректный, то догенерируется вторая половина роллаутов и применяется обычное GRPO…
Ещё одна очень похожая статья, на этот раз от NVIDIA
LLM вредно слишком много думать?
Британские Японские ученые утверждают, что если модель слишком увлекается размышлениями, то, вопреки ожиданиям, качество начинает деградировать из-за высокой дисперсии. С другой стороны наблюдается схожий процесс: слишком короткие размышления приводят к тому, что модель недокручивает вопрос и даёт неправильный ответ.
Каких-то выводов и предложений по исправлению не предлагается, поэтому за японских ученых предположу, что обучать, видимо нужно в два этапа: сначала давать модели вволю поисследовать разное поддерживая высокую энтропию, а потом уже учить в жестких constrained-сетапах с фиксированным бюджетом на токены.
Кажется, что даже в этом канале можно найти пару статей про такого рода обучение (например вчерашняя от NVIDIA), но общей практикой это пока не стало, интересно почему?
Источник: https://www.arxiv.org/abs/2602.09591.
@experimentality
Каких-то выводов и предложений по исправлению не предлагается, поэтому за японских ученых предположу, что обучать, видимо нужно в два этапа: сначала давать модели вволю поисследовать разное поддерживая высокую энтропию, а потом уже учить в жестких constrained-сетапах с фиксированным бюджетом на токены.
Кажется, что даже в этом канале можно найти пару статей про такого рода обучение (например вчерашняя от NVIDIA), но общей практикой это пока не стало, интересно почему?
Источник: https://www.arxiv.org/abs/2602.09591.
@experimentality
arXiv.org
On the Optimal Reasoning Length for RL-Trained Language Models
Reinforcement learning substantially improves reasoning in large language models, but it also tends to lengthen chain-of-thought outputs and increase computational cost. Although length-control...
👍3❤🔥1
Forwarded from igor tokarev
[2602.08234] SkillRL: Evolving Agents via Recursive Skill-Augmented Reinforcement Learning
https://arxiv.org/abs/2602.08234
https://github.com/aiming-lab/SkillRL
https://arxiv.org/abs/2602.08234
https://github.com/aiming-lab/SkillRL
arXiv.org
SkillRL: Evolving Agents via Recursive Skill-Augmented...
Large Language Model (LLM) agents have shown stunning results in complex tasks, yet they often operate in isolation, failing to learn from past experiences. Existing memory-based methods primarily...
❤2
В связи с недавним успехом claude code и codex и взрывом их популярности — неплохо было бы присесть на hype train и обсудить что вообще стоит за кодящими LLM, благо недавно вышел репорт аж на 300 страниц на эту тему.
Пост будет разделен на несколько частей по мере прочтения и осмысления.
1. Данные
Для кода качество данных кратно важнее, чем для чат бота, так как, хоть одно и тоже можно реализовать несколькими способами (Tim Peters негодует), но мы-то хотим качественный код, который не ломается на крайних случаях, покрыт тестами и снабжен документацией.
Собирать эти данные можно, например, на гитхабе, но там много всякого шлака, поэтому нужно тщательно фильтровать по недавним contributions, количеству звезд, наличию README.md и другим эвристикам. Возможно с появлением агентов можно начать смотреть на issues, чтобы понять, что с проектом может быть что-то не так.
Также можно смотреть в сторону платформ вроде leetcode или stack overflow, но в первом случае мы столкнемся с distribution mismatch: никто же не работе не инвертирует бинарные деревья :), а второй сайтвообще умер содержит мало контекста, только небольшие сниппеты кода. Синта если и помогает, то только очень качественная, а это дорого.
Ещё утверждается, что нереально важна дедупликация (18 упоминаний), так как это позволяет избежать переобучения и, как следствие, даёт лучшую генерализацию на новые сценарии. Ну и показатели на бенчах у моделей обученных на хорошо дедуплицированных датасетах становятся более скореллированными с реальным перформансом. На некоторых датасетах с кодом простая дедупликация удаляет 70% (!!!) всех сэмплов, так что это реально очень важно.
Вдобавок к вышесказанному рекомендуют балансировать языки (базово в датасетах доминируют js и python, кто бы мог подумать), не увлекаться нормализацией (удаление комментариев, например, теряет важную семантику), фильтровать по executability и прогонять статические анализаторы для компилируемых языков. Сюда же можно отнести использование линтеров.
По поводу количества данных: оптимальный сплит для претрейна 90/10 raw code/instructions, и потом полировать с помощью instruction sft и RL, но про это дальше
@experimentality
Пост будет разделен на несколько частей по мере прочтения и осмысления.
1. Данные
Для кода качество данных кратно важнее, чем для чат бота, так как, хоть одно и тоже можно реализовать несколькими способами (Tim Peters негодует), но мы-то хотим качественный код, который не ломается на крайних случаях, покрыт тестами и снабжен документацией.
Собирать эти данные можно, например, на гитхабе, но там много всякого шлака, поэтому нужно тщательно фильтровать по недавним contributions, количеству звезд, наличию README.md и другим эвристикам. Возможно с появлением агентов можно начать смотреть на issues, чтобы понять, что с проектом может быть что-то не так.
Также можно смотреть в сторону платформ вроде leetcode или stack overflow, но в первом случае мы столкнемся с distribution mismatch: никто же не работе не инвертирует бинарные деревья :), а второй сайт
Ещё утверждается, что нереально важна дедупликация (18 упоминаний), так как это позволяет избежать переобучения и, как следствие, даёт лучшую генерализацию на новые сценарии. Ну и показатели на бенчах у моделей обученных на хорошо дедуплицированных датасетах становятся более скореллированными с реальным перформансом. На некоторых датасетах с кодом простая дедупликация удаляет 70% (!!!) всех сэмплов, так что это реально очень важно.
Вдобавок к вышесказанному рекомендуют балансировать языки (базово в датасетах доминируют js и python, кто бы мог подумать), не увлекаться нормализацией (удаление комментариев, например, теряет важную семантику), фильтровать по executability и прогонять статические анализаторы для компилируемых языков. Сюда же можно отнести использование линтеров.
По поводу количества данных: оптимальный сплит для претрейна 90/10 raw code/instructions, и потом полировать с помощью instruction sft и RL, но про это дальше
@experimentality
arXiv.org
From Code Foundation Models to Agents and Applications: A...
Large language models (LLMs) have fundamentally transformed automated software development by enabling direct translation of natural language descriptions into functional code, driving commercial...
👍6🔥4❤3👏1
Продолжаем разбор этого трёхсот страничного труда,
часть 2 Обучение
Кодовые LLM-ки тут ничем не отличаются от обычных, также обучаются в три стадии: pretrain, sft (aligment) и немного RL сверху.
Первый этап тут отвечает в основном за понимание кода, а задача next token prediction очень хорошо подходит для кода, так как в нём гораздо сильнее, чем в естественном языке соблюдается локальная и глобальная структуры. При этом отмечается, что scaling law тут тоже работает, но сильнее видно влияние шумных/плохих данных, чем в тексте. Оно и не удивительно: люди часто пропускают в тексте буквы, знаки препинания и проч. и ничего, всем всё понятно, а компилятор от такогооху удивится
Также обнаруживается нелинейный рост качества с увеличением контекстного окна, что тоже вполне ожидаемо. Поэтому скармливать целые репозитории > сниппеты со stack overflow. Но без последнего тоже никак не обойтись, ведь если на претрейне модель совсем не будет видеть пар (текст, код), то на стадии sft не получится проучить соблюдение инструкций. Рекомендуется включать в претрейн не только инструкции связанные с кодом, но и вообще не связанный с кодом текст для общего развития.
На втором этапе (sft) важно уже проучить поведение ассистента, основы для которого мы заложили на первом. Моделька должна не просто хорошо писать код как папа карло, но и писать именно то, что просят и как просят (instruction following), уметь искать и фиксить баги, а также хорошо отвечать на вопросы по коду. Очень важно на этом этапе добавить multi-turn conversations, чтобы модель научилась в столь популярный в последнее время feedback loop. При всём при этом, важно конечно не увлекаться sft, потому что он уменьшает энтропию и, как следствие, делает модель в некотором смысле тупее (хотя, конечно, и полезнее).
Наконец RL, тут на коде есть где разгуляться, даже сильнее, чем на математике. В качестве очень сильного бейзлайна выступает семейство execution-based наград, причём robustness тут сильнее, чем на математике, так как вместо сравнения с одним эталонным ответом мы проверяем OK на нескольких десятках тестов. Также, благодаря тому, что код имеет четкую структуру, можно включить в награду необходимый нам код-стайл через сигнал от линкера, добавлять варнинги компилятора для компилируемых языков and so on, and so on. Здесь можно отметить методы prompt evolution типа GEPA, которые чисто по фидбеку от компилятора умудряются чуть ли не перегнать RL по качеству. (прим. автора)
Ещё отмечают reasonable effectiveness RFT (rejection-sampling fine tuning). Идея здесь в том, что мы генерируем моделькой ответы на какие-то вопросы, фильтруем с помощью разных эвристик, которые используются в том же RL, а потом на собранном таким образом датасете делаем sft. Получается дешевле, чем стандартный RL и почти также круто.
Подведем промежуточные итоги:
1. RL с execution-based сигналом супер гуд
2. Слишком много sft ухудшает качку, так как кодинг — это, к сожалению задача требующая определенного уровня креативности
3. Качество данных важнее их количества в особенности для кода
Ставьте реакции и завтра, а может быть и сегодня вечером продолжим
@experimentality
часть 2 Обучение
Кодовые LLM-ки тут ничем не отличаются от обычных, также обучаются в три стадии: pretrain, sft (aligment) и немного RL сверху.
Первый этап тут отвечает в основном за понимание кода, а задача next token prediction очень хорошо подходит для кода, так как в нём гораздо сильнее, чем в естественном языке соблюдается локальная и глобальная структуры. При этом отмечается, что scaling law тут тоже работает, но сильнее видно влияние шумных/плохих данных, чем в тексте. Оно и не удивительно: люди часто пропускают в тексте буквы, знаки препинания и проч. и ничего, всем всё понятно, а компилятор от такого
Также обнаруживается нелинейный рост качества с увеличением контекстного окна, что тоже вполне ожидаемо. Поэтому скармливать целые репозитории > сниппеты со stack overflow. Но без последнего тоже никак не обойтись, ведь если на претрейне модель совсем не будет видеть пар (текст, код), то на стадии sft не получится проучить соблюдение инструкций. Рекомендуется включать в претрейн не только инструкции связанные с кодом, но и вообще не связанный с кодом текст для общего развития.
На втором этапе (sft) важно уже проучить поведение ассистента, основы для которого мы заложили на первом. Моделька должна не просто хорошо писать код как папа карло, но и писать именно то, что просят и как просят (instruction following), уметь искать и фиксить баги, а также хорошо отвечать на вопросы по коду. Очень важно на этом этапе добавить multi-turn conversations, чтобы модель научилась в столь популярный в последнее время feedback loop. При всём при этом, важно конечно не увлекаться sft, потому что он уменьшает энтропию и, как следствие, делает модель в некотором смысле тупее (хотя, конечно, и полезнее).
Наконец RL, тут на коде есть где разгуляться, даже сильнее, чем на математике. В качестве очень сильного бейзлайна выступает семейство execution-based наград, причём robustness тут сильнее, чем на математике, так как вместо сравнения с одним эталонным ответом мы проверяем OK на нескольких десятках тестов. Также, благодаря тому, что код имеет четкую структуру, можно включить в награду необходимый нам код-стайл через сигнал от линкера, добавлять варнинги компилятора для компилируемых языков and so on, and so on. Здесь можно отметить методы prompt evolution типа GEPA, которые чисто по фидбеку от компилятора умудряются чуть ли не перегнать RL по качеству. (прим. автора)
Ещё отмечают reasonable effectiveness RFT (rejection-sampling fine tuning). Идея здесь в том, что мы генерируем моделькой ответы на какие-то вопросы, фильтруем с помощью разных эвристик, которые используются в том же RL, а потом на собранном таким образом датасете делаем sft. Получается дешевле, чем стандартный RL и почти также круто.
Подведем промежуточные итоги:
1. RL с execution-based сигналом супер гуд
2. Слишком много sft ухудшает качку, так как кодинг — это, к сожалению задача требующая определенного уровня креативности
3. Качество данных важнее их количества в особенности для кода
Ставьте реакции и завтра, а может быть и сегодня вечером продолжим
@experimentality
arXiv.org
From Code Foundation Models to Agents and Applications: A...
Large language models (LLMs) have fundamentally transformed automated software development by enabling direct translation of natural language descriptions into functional code, driving commercial...
🔥7❤2👍2
Forwarded from Душный NLP
Как заставить агентов делать работу над ошибками
Сегодня разбираем статью об обучении агентов. Проблема такая: реворд-модели оценивают только результат в конце траектории, а если агент сделал ошибку и исправил её, нельзя сказать, когда это произошло. Если бы у нас была такая возможность, то мы могли бы раньше направить обучаемую LLM по нужному пути. Есть способы фиксировать ошибки и делать реворд по шагам, но это дорого и сложно в реализации.
Авторы предлагают метод Agent-R, суть которого заключается в обучении агентов не на правильных траекториях, а на тех, где есть явная ошибка и её исправление. Такие траектории получаются через Monte Carlo Tree Search. Берутся пары из одной стартовой точки (инструкции): одна траектория успешная, а другая — нет. На инференсе момент расхождения должна определить сама модель, а при обучении к началу провальной траектории добавляется фраза-рефлексия, которую генерирует агент, понимая, что он ошибся (CoT). Следом «приклеивается» хвост удачной траектории и на всём этом делают SFT. Такой подход, соединеняющий рефлексии и «хороший» хвост, снижает риск склейки не связанных траекторий.
В статье выводят следующие типы траекторий:
Initial Trajectory — общий начальный префикс.
Bad Trajectory — субоптимальные действия c низкой наградой.
Good Trajectory — оптимальные действия с высокой наградой.
Revision Trajectory — траектория, в которой агент совершил ошибку и исправил её.
Для получения Revision Trajectory можно брать плохие траектории, дожидаться их финала и переписывать. Однако так не получится обучить агента ловить ошибки на лету. Вместо этого авторы заставляют модель самостоятельно анализировать траектории и пытаться определить первый шаг, где совершена ошибка. На этом месте траектория обрезается, вставляется этап рефлексии и следом — правильная траектория.
Monte Carlo Tree Search позволяет собрать много разных траекторий с одним началом. Это удобно, так как можно сравнивать хорошие и плохие продолжения. Финальный реворд используется не для обучения напрямую, а для классификации траекторий по качеству — то есть, по сути, чтобы понять, что пойдёт в SFT-датасет. У реворда есть два порога: один отделяет плохие траектории от хороших, а другой выбирает уже из хороших лучшие.
Авторы отмечают, что обучаться только на Revision Trajectory нельзя — это мешает агенту определять правильные траектории. Поэтому изначально в датасет добавляют много Good Trajectory и постепенно в процессе SFT повышают порог реворда оптимальных решений, чтобы в конце оставались только лучшие из них. Кроме того, в датасет подмешивают обычные языковые данные, что помогает агенту не забывать, чему он обучался ранее.
Эксперименты проводили на Llama-3.1-8B, которую обучили на собранных Revision Trajectory. Результаты можно посмотреть в таблице, приложенной к посту. Авторы заявляют, что исправленные траектории оказываются даже лучше идеальных.
Разбор подготовила❣ Карина Романова
Подписывайтесь на канал Карины «что-то на DL-ском» — там познавательно и можно ставить реакт кота в парике.
Душный NLP
Сегодня разбираем статью об обучении агентов. Проблема такая: реворд-модели оценивают только результат в конце траектории, а если агент сделал ошибку и исправил её, нельзя сказать, когда это произошло. Если бы у нас была такая возможность, то мы могли бы раньше направить обучаемую LLM по нужному пути. Есть способы фиксировать ошибки и делать реворд по шагам, но это дорого и сложно в реализации.
Авторы предлагают метод Agent-R, суть которого заключается в обучении агентов не на правильных траекториях, а на тех, где есть явная ошибка и её исправление. Такие траектории получаются через Monte Carlo Tree Search. Берутся пары из одной стартовой точки (инструкции): одна траектория успешная, а другая — нет. На инференсе момент расхождения должна определить сама модель, а при обучении к началу провальной траектории добавляется фраза-рефлексия, которую генерирует агент, понимая, что он ошибся (CoT). Следом «приклеивается» хвост удачной траектории и на всём этом делают SFT. Такой подход, соединеняющий рефлексии и «хороший» хвост, снижает риск склейки не связанных траекторий.
В статье выводят следующие типы траекторий:
Initial Trajectory — общий начальный префикс.
Bad Trajectory — субоптимальные действия c низкой наградой.
Good Trajectory — оптимальные действия с высокой наградой.
Revision Trajectory — траектория, в которой агент совершил ошибку и исправил её.
Для получения Revision Trajectory можно брать плохие траектории, дожидаться их финала и переписывать. Однако так не получится обучить агента ловить ошибки на лету. Вместо этого авторы заставляют модель самостоятельно анализировать траектории и пытаться определить первый шаг, где совершена ошибка. На этом месте траектория обрезается, вставляется этап рефлексии и следом — правильная траектория.
Monte Carlo Tree Search позволяет собрать много разных траекторий с одним началом. Это удобно, так как можно сравнивать хорошие и плохие продолжения. Финальный реворд используется не для обучения напрямую, а для классификации траекторий по качеству — то есть, по сути, чтобы понять, что пойдёт в SFT-датасет. У реворда есть два порога: один отделяет плохие траектории от хороших, а другой выбирает уже из хороших лучшие.
Авторы отмечают, что обучаться только на Revision Trajectory нельзя — это мешает агенту определять правильные траектории. Поэтому изначально в датасет добавляют много Good Trajectory и постепенно в процессе SFT повышают порог реворда оптимальных решений, чтобы в конце оставались только лучшие из них. Кроме того, в датасет подмешивают обычные языковые данные, что помогает агенту не забывать, чему он обучался ранее.
Эксперименты проводили на Llama-3.1-8B, которую обучили на собранных Revision Trajectory. Результаты можно посмотреть в таблице, приложенной к посту. Авторы заявляют, что исправленные траектории оказываются даже лучше идеальных.
Разбор подготовила
Подписывайтесь на канал Карины «что-то на DL-ском» — там познавательно и можно ставить реакт кота в парике.
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🤯2❤1
Утверждают, что для CoT (reasoning) sft лучше на небольшом датасете поучить побольше эпох, чем учиться одну эпоху на большом разнообразном датасете, что звучит достаточно контринтуитивно. Замеры, проводят на Qwen3 и Olmo и про первый известно, что в обучающих данных потенциально имеются куски бенчей, так что относиться к этому стоит с осторожностью.
Источник: https://arxiv.org/abs/2602.11149
Источник: https://arxiv.org/abs/2602.11149
arXiv.org
Data Repetition Beats Data Scaling in Long-CoT Supervised Fine-Tuning
Supervised fine-tuning (SFT) on chain-of-thought data is an essential post-training step for reasoning language models. Standard machine learning intuition suggests that training with more unique...
🤔3❤1👍1
обсуждаем 300 страниц репорт по кодовым агентам, часть 1, часть 2 про данные и обучение
часть 3 Финальные мысли
После достаточно подробного обсуждения процесса обучения и сбора данных, хочется чуть более поверхностно обсудить какие-то общие выводы из работы
1. Ключевой фактор в успехе code agents — собственно переход от автокомплита к парадигме code agents и просто трена на корпусе кода с next-token prediction тут уже не хватает, нужны env-ы из реальных репозиториев, полноценный RL, feedback loop, а также все эти агентские обвязки.
2. К пункту 1 нужны соответствующие бенчи, замерять качество написания отдельно вязтой функции уже не имеет смысла, предположу, что нужно мерить количество реально закрытых pr, но тогда непонятно как сравнивать разные модели, так как такого рода бенчмарк будет всё время протухать.
3. Ещё одна важная underexplored area — написание безопасного кода. Для пет-проекта открытые порты на vps за 100 рублей без ценной информации это ок, другое дело когда речь идёт о чём-нибудь сколь-угодно серьёзном. Ни next-token-prediction, ни correctness reward не оптимизируют безопасность кода, по крайней мере в явном виде.
4. Вдобавок — интересная мысль была про использование RAG, я личного такого не видел, но в целом это звучит логично: я, как плохой SWE, сам, когда хочу что-то толковое написать как правило обращаюсь к каким-то эталонным репозиториям за структурой и организацией кода.
А на этом всё, ставьте реакции, пишите в комментарии свои размышления по поводу кодовых агентов. Кажется, что подключение claude code лично для меня стало следующим chatgpt moment, посмотрим, что будет дальше)
@experimentality
часть 3 Финальные мысли
После достаточно подробного обсуждения процесса обучения и сбора данных, хочется чуть более поверхностно обсудить какие-то общие выводы из работы
1. Ключевой фактор в успехе code agents — собственно переход от автокомплита к парадигме code agents и просто трена на корпусе кода с next-token prediction тут уже не хватает, нужны env-ы из реальных репозиториев, полноценный RL, feedback loop, а также все эти агентские обвязки.
2. К пункту 1 нужны соответствующие бенчи, замерять качество написания отдельно вязтой функции уже не имеет смысла, предположу, что нужно мерить количество реально закрытых pr, но тогда непонятно как сравнивать разные модели, так как такого рода бенчмарк будет всё время протухать.
3. Ещё одна важная underexplored area — написание безопасного кода. Для пет-проекта открытые порты на vps за 100 рублей без ценной информации это ок, другое дело когда речь идёт о чём-нибудь сколь-угодно серьёзном. Ни next-token-prediction, ни correctness reward не оптимизируют безопасность кода, по крайней мере в явном виде.
4. Вдобавок — интересная мысль была про использование RAG, я личного такого не видел, но в целом это звучит логично: я, как плохой SWE, сам, когда хочу что-то толковое написать как правило обращаюсь к каким-то эталонным репозиториям за структурой и организацией кода.
А на этом всё, ставьте реакции, пишите в комментарии свои размышления по поводу кодовых агентов. Кажется, что подключение claude code лично для меня стало следующим chatgpt moment, посмотрим, что будет дальше)
@experimentality
arXiv.org
From Code Foundation Models to Agents and Applications: A...
Large language models (LLMs) have fundamentally transformed automated software development by enabling direct translation of natural language descriptions into functional code, driving commercial...
👍3🔥2❤1
Оказывается, что можно по заданной цепочке размышлений определить вероятность того, насколько правильным будет ответ, к которому она ведёт. Чтобы это сделать — нужно посчитать отношение количества так называемых deep thinking tokens к длине последовательности. Чем больше оно — тем больше вероятность, что ответ окажется правильным.
Что же это за токены такие? Современные LLM по большой части состоят из одинаковых трансформерных блоков настаканных друг на друга. Соответственно к выходу каждого блока можно применить выходную матрицу и определить, какой токен был бы предсказан, если бы этот блок был последним (выходным). Вот токены у которых полученное последовательным применением такой процедуры ко всем блокам множество токенов будет достаточно разнообразным и называют deep thinking tokens.
Зачем это нужно? Например в методах где генерируется несколько траекторий и потом они каким-то образом агрегируются в ответ можно это учитывать. Или на раннем этапе “гасить” траектории, которые маловероятно приведут к правильному ответу. Короче ключевой юзкейс — из нескольких сгенерированных моделью траекторий выбирать наиболее “хорошую” без явной разметки, а как вы это будете использовать — ваше дело
Источник: https://www.arxiv.org/abs/2602.13517.
@experimentality
Что же это за токены такие? Современные LLM по большой части состоят из одинаковых трансформерных блоков настаканных друг на друга. Соответственно к выходу каждого блока можно применить выходную матрицу и определить, какой токен был бы предсказан, если бы этот блок был последним (выходным). Вот токены у которых полученное последовательным применением такой процедуры ко всем блокам множество токенов будет достаточно разнообразным и называют deep thinking tokens.
Зачем это нужно? Например в методах где генерируется несколько траекторий и потом они каким-то образом агрегируются в ответ можно это учитывать. Или на раннем этапе “гасить” траектории, которые маловероятно приведут к правильному ответу. Короче ключевой юзкейс — из нескольких сгенерированных моделью траекторий выбирать наиболее “хорошую” без явной разметки, а как вы это будете использовать — ваше дело
Источник: https://www.arxiv.org/abs/2602.13517.
@experimentality
arXiv.org
Think Deep, Not Just Long: Measuring LLM Reasoning Effort via...
Large language models (LLMs) have demonstrated impressive reasoning capabilities by scaling test-time compute via long Chain-of-Thought (CoT). However, recent findings suggest that raw token...
👍3👏3❤1
Forwarded from Нейронавт | Нейросети в творчестве
The Molecular Structure of Thought: Mapping the Topology of Long Chain-of-Thought Reasoning
ByteDance разобрались почему LLM плохо справляются с длинными рассуждениями. Оказалось, что Long CoT — это как молекула с тремя типами связей: глубокие логические выводы, самопроверка и исследование альтернатив. Нарушение любой из этих связей — и рассуждение рассыпается.
Главное практическое следствие: теперь можно обучать модели длинным рассуждениям без дорогих teacher-моделей — достаточно обычного instruction LLM. Раньше это не работало, и никто не понимал почему.
Прирост — на 6 математических бенчмарках.
arXiv
#reasoning #research #news
ByteDance разобрались почему LLM плохо справляются с длинными рассуждениями. Оказалось, что Long CoT — это как молекула с тремя типами связей: глубокие логические выводы, самопроверка и исследование альтернатив. Нарушение любой из этих связей — и рассуждение рассыпается.
Главное практическое следствие: теперь можно обучать модели длинным рассуждениям без дорогих teacher-моделей — достаточно обычного instruction LLM. Раньше это не работало, и никто не понимал почему.
Прирост — на 6 математических бенчмарках.
arXiv
#reasoning #research #news
❤3
Мне очень понравилась заметка про gradient hacking у claude 3.5, я поискал и нашёл статью на эту тему. Оказывается, что если описать функцию награды в промпте, то после обучения модель показывает заметно более хорошие результаты. При этом эффект консистентный и проявляется на нескольких бенчах, то есть это не просто оптимизационный шум. Более того, в статье проведён хороший ablation, поэтому вопросов к результатам исследования у меня нет никаких.
Более того, я бы пошёл дальше, и описал в том числе алгоритм, который используется для оптимизации, но пока не могу придумать какой-то адекватный эксперимент, чтобы это проверить. Обращаюсь к вам: помогите мне придумать такой эксперимент или какой-то сетап, в котором модель будет выигрывать от осознания того, что её тренируют, по сравнению с обычной версией. Может статьи какие-то знаете, тоже буду признателен. Спасибо!
Источник: https://www.arxiv.org/abs/2506.18485.
Более того, я бы пошёл дальше, и описал в том числе алгоритм, который используется для оптимизации, но пока не могу придумать какой-то адекватный эксперимент, чтобы это проверить. Обращаюсь к вам: помогите мне придумать такой эксперимент или какой-то сетап, в котором модель будет выигрывать от осознания того, что её тренируют, по сравнению с обычной версией. Может статьи какие-то знаете, тоже буду признателен. Спасибо!
Источник: https://www.arxiv.org/abs/2506.18485.
Teletype
Claude 3 Opus заалайнил сам себя через gradient hacking?
Адаптация поста Fiora Starlight на LessWrong от 21 февраля 2026. Основные идеи в оригинале принадлежат Janus (repligate).
🎉3👍2❤1
Ребята из tencent дают советы о том, как обучать efficient размышляющие модели (то есть размер блока размышлений ограничен минимально необходимым). Проверили на большом наборе разных квенов и задач, так что кажется можно верить (квен конечно не показатель, но в целом результаты соответствуют ожиданиям).
1. Лучше тренироваться на более простых задачах, так как на них будут оптимальные размены exploration/exploitation.
2. Больше rollouts (N) в одном батче — лучше. Хотя есть работы про то, что GRPO работает даже с N=2, очевидно, что больше роллаутов дают больше exploration и более стабильное обучение.
3. Оптимальная награда — корректность помноженная на индикатор того, что rollout получился не слишком длинный.
Источник: https://www.arxiv.org/abs/2602.20945.
@experimentality
1. Лучше тренироваться на более простых задачах, так как на них будут оптимальные размены exploration/exploitation.
2. Больше rollouts (N) в одном батче — лучше. Хотя есть работы про то, что GRPO работает даже с N=2, очевидно, что больше роллаутов дают больше exploration и более стабильное обучение.
3. Оптимальная награда — корректность помноженная на индикатор того, что rollout получился не слишком длинный.
Источник: https://www.arxiv.org/abs/2602.20945.
@experimentality
arXiv.org
The Art of Efficient Reasoning: Data, Reward, and Optimization
Large Language Models (LLMs) consistently benefit from scaled Chain-of-Thought (CoT) reasoning, but also suffer from heavy computational overhead. To address this issue, efficient reasoning aims...
❤3👍2🔥2
Constrined decoding и разные его аналоги и виды позволяют делать из LLM продукты за пределами чат-ботов, обеспечивая какой-то единый контракт на выходе из модели, но при этом они ухудшают качество. Для борьбы с этим предлагается сначала генерировать ответ в свободной форме, а потом на его основе генерировать уже structured output. Но стоит ли этот прирост качества 2x замедления?
Источник: https://www.arxiv.org/abs/2603.03305
@experimentality
Источник: https://www.arxiv.org/abs/2603.03305
@experimentality
arXiv.org
The Hidden Cost of Structured Generation in LLMs:...
Large language models (LLMs) are increasingly used to generate executable outputs, JSON objects, and API calls, where a single syntax error can make the output unusable. Constrained decoding...
👍2🏆1
пока я справляюсь с внезапно навалившимися невзгодами вот вам идея для полезного продукта. Вопрос только в том, как бы автоматизировать первый этап, а то на него уж больно много времени ушло
Forwarded from Max Fofanov
roman lisov
Мне интересно, как сейчас действуют студенты
буквально сейчас к пересдаче готовлюсь по такой схеме:
• совместно с claude написал дебильник (claude написал каркас) + я руками поправил по записям лекций
• далее прошу клода спрашивать меня по дебильнику и вести прогресс в отдельном файлике, чтобы он спрашивал меня то, что я плохо знаю и я мог трекать свой прогресс
Обернуть в интерфейс, взять модельку подешевле и можно продавать подороже
• совместно с claude написал дебильник (claude написал каркас) + я руками поправил по записям лекций
• далее прошу клода спрашивать меня по дебильнику и вести прогресс в отдельном файлике, чтобы он спрашивал меня то, что я плохо знаю и я мог трекать свой прогресс
Обернуть в интерфейс, взять модельку подешевле и можно продавать подороже
🔥7❤1
Forwarded from Hacker News
Show HN: How I Topped the HuggingFace Open LLM Leaderboard on Two Gaming GPUs (Score: 151+ in 5 hours)
Link: https://readhacker.news/s/6Pudz
Comments: https://readhacker.news/c/6Pudz
Link: https://readhacker.news/s/6Pudz
Comments: https://readhacker.news/c/6Pudz
David Noel Ng
LLM Neuroanatomy: How I Topped the AI Leaderboard Without Changing a Single Weight
ML, Biotech, Hardware, and Coordination Problems. Sometimes I write about hard problems and how to solve them.
Hacker News
Show HN: How I Topped the HuggingFace Open LLM Leaderboard on Two Gaming GPUs (Score: 151+ in 5 hours) Link: https://readhacker.news/s/6Pudz Comments: https://readhacker.news/c/6Pudz
интересная статья про попытки менять слои в трансформере местами, дублировать их и всякое такое в поисках инкремента по качеству. Как говорится, не мерджингом единым выжимать качество. Автор обещает интересные результаты на новых квенах, лично я в предвкушении 🙏
🙏2👍1
Скучали по статьям про efficient reasoning ?
В этот раз исследователи из Huawei предлагают делать из обычных reasoning-моделей эффективные с помощью вычисления steering вектора перехода от состояния overthinking к underthinking и наоборот на небольшом калибровочном датасете.
В качестве сигнала для включения контроля используется уверенность модели и производные от неё метрики, например то как она изменяется во времени (confidence variance): если замечен, overthinking то включается режим перехода к ответу, для underthinking наоборот режим exploration. Естественно метрики от такого растут, при этом количество токенов падает, то есть растёт та самая эффективность™.
Вообще я такое видел в формате форсирования ответа например с помощью вставки final answer, или наоборот попытки продолжить размышления с помощью wait, но очевидно, что интервенции в латентном пространстве будут более эффективными, так как они обеспечивают более плавный, сбалансированный переход между двумя критическими состояниями.
Источник: https://www.arxiv.org/abs/2603.12372.
@experimentality
В этот раз исследователи из Huawei предлагают делать из обычных reasoning-моделей эффективные с помощью вычисления steering вектора перехода от состояния overthinking к underthinking и наоборот на небольшом калибровочном датасете.
В качестве сигнала для включения контроля используется уверенность модели и производные от неё метрики, например то как она изменяется во времени (confidence variance): если замечен, overthinking то включается режим перехода к ответу, для underthinking наоборот режим exploration. Естественно метрики от такого растут, при этом количество токенов падает, то есть растёт та самая эффективность™.
Вообще я такое видел в формате форсирования ответа например с помощью вставки final answer, или наоборот попытки продолжить размышления с помощью wait, но очевидно, что интервенции в латентном пространстве будут более эффективными, так как они обеспечивают более плавный, сбалансированный переход между двумя критическими состояниями.
Источник: https://www.arxiv.org/abs/2603.12372.
@experimentality
arXiv.org
Efficient Reasoning with Balanced Thinking
Large Reasoning Models (LRMs) have shown remarkable reasoning capabilities, yet they often suffer from overthinking, expending redundant computational steps on simple problems, or underthinking,...
❤4👍3🙏1