Forwarded from Data Blog
Activation Oracles
[paper]
Каждый раз, просто каждый раз, когда я читаю статью от Antropic хочется замирать от гениальности. Кому отдать душу, чтобы быть таким же креативным?
19 декабря у них вышла работа про Activation Oracles — подход, который позволяет читать скрытые состояния языковой модели, не анализируя веса и используя естественный язык. И если вы уже на этом месте подумали, что они просто используют для этого другую LLM — вы правы! Но зато как они это делают!
Основная гипотеза работы, как я вижу состоит в том, что:
если две модели имеют сходные представления, то одна модель может интерпретировать внутренние активации другой.
Эта мысль круто ложится на Platonic representation hyphothesis — Neural networks, trained with different objectives on different data and modalities, are converging to a shared statistical model of reality in their representation spaces.
Что делаем(это могли бы быть мы с тобой, но мы не такие умные):
Берём:
* целевую модель M,
* модель-оракул AO, которая изначально является её ctrl-C-копией,
* извлекаем активации M (из residual stream),
* и прокидываем их, используя steering, в граф оракула AO — тоже как направленное возмущение residual stream.
Дальше просто задаём промт-вопрос, вроде «О чём сейчас думает модель?», «Какова её цель?», «Есть ли здесь скрытое знание?». И оракул отвечает, причем хорошо — например, может вытащить секретное слово модели, даже если она сама не отдала его в ответе.
Идея засунуть активации в LLM не нова:
Был (есть) LatentQA, где активации подаются внешне — как дополнительный вход. Но здесь же активации встраиваются внутрь forward-pass, влияя на дальнейшие вычисления. И это же просто гениально.
Что ещё вкусного — всё, что я словами отдала как output, можно потыкать в приложенном к статье коде.
Туториал:
[collab]
Я перевела его с некоторой отсебятиной и постановкой задачи. Перевела только основной текст, комментарии коду уж оставлены родными. В нем можно увидеть:
1. Многошаговое рассуждение
Оракул по токенам извлекает цепочку Socrates → Plato → Aristotle на активациях модели.
2. Извлечение секретного слова
Модель дообучена скрывать слово — напрямую она его не называет.
Оракул извлекает его только из активаций (репликация Figure 1 из статьи).
3. Обнаружение мисалайнмента
Можно выявить, что модель обучена давать манипулятивные или вредные советы.
4. Трекинг эмоций модели (и у нее они есть)
По одному вектору на токен оракул отслеживает Disappointment, Anger, Frustration, Sadness на протяжении диалога.
Ограничения:
После радостного восторга, холодной головой также важно понимать, что оракул может додумывать и не может показать то, чего мы не спрашиваем. Кроме того, это не самая вычислительно оптимальная вещь — чтобы ответить на один вопрос об активации, AO требуется несколько forward-pass’ов и полноценная генерация текста.
Но красиво. Тыкайте на здоровье и делитесь впечатлениями!
[paper]
Каждый раз, просто каждый раз, когда я читаю статью от Antropic хочется замирать от гениальности. Кому отдать душу, чтобы быть таким же креативным?
19 декабря у них вышла работа про Activation Oracles — подход, который позволяет читать скрытые состояния языковой модели, не анализируя веса и используя естественный язык. И если вы уже на этом месте подумали, что они просто используют для этого другую LLM — вы правы! Но зато как они это делают!
Основная гипотеза работы, как я вижу состоит в том, что:
если две модели имеют сходные представления, то одна модель может интерпретировать внутренние активации другой.
Эта мысль круто ложится на Platonic representation hyphothesis — Neural networks, trained with different objectives on different data and modalities, are converging to a shared statistical model of reality in their representation spaces.
Что делаем
Берём:
* целевую модель M,
* модель-оракул AO, которая изначально является её ctrl-C-копией,
* извлекаем активации M (из residual stream),
* и прокидываем их, используя steering, в граф оракула AO — тоже как направленное возмущение residual stream.
Дальше просто задаём промт-вопрос, вроде «О чём сейчас думает модель?», «Какова её цель?», «Есть ли здесь скрытое знание?». И оракул отвечает, причем хорошо — например, может вытащить секретное слово модели, даже если она сама не отдала его в ответе.
Идея засунуть активации в LLM не нова:
Был (есть) LatentQA, где активации подаются внешне — как дополнительный вход. Но здесь же активации встраиваются внутрь forward-pass, влияя на дальнейшие вычисления. И это же просто гениально.
Что ещё вкусного — всё, что я словами отдала как output, можно потыкать в приложенном к статье коде.
Туториал:
[collab]
Я перевела его с некоторой отсебятиной и постановкой задачи. Перевела только основной текст, комментарии коду уж оставлены родными. В нем можно увидеть:
1. Многошаговое рассуждение
Оракул по токенам извлекает цепочку Socrates → Plato → Aristotle на активациях модели.
2. Извлечение секретного слова
Модель дообучена скрывать слово — напрямую она его не называет.
Оракул извлекает его только из активаций (репликация Figure 1 из статьи).
3. Обнаружение мисалайнмента
Можно выявить, что модель обучена давать манипулятивные или вредные советы.
4. Трекинг эмоций модели (и у нее они есть)
По одному вектору на токен оракул отслеживает Disappointment, Anger, Frustration, Sadness на протяжении диалога.
Ограничения:
После радостного восторга, холодной головой также важно понимать, что оракул может додумывать и не может показать то, чего мы не спрашиваем. Кроме того, это не самая вычислительно оптимальная вещь — чтобы ответить на один вопрос об активации, AO требуется несколько forward-pass’ов и полноценная генерация текста.
Но красиво. Тыкайте на здоровье и делитесь впечатлениями!
🔥4
Вашим моделям нужно тренироваться на тесте
Как поступает усердный школьник, если у него не получается решить задачу?Гуглит решение Разбирает задачки на ту же тему, но попроще, пока не поймёт какие-то ключевые идеи необходимые для решения оригинальной задачи. Вот тоже самое предлагается делать во время test-time.
В обычном Test Time RL (TTRL) LLM обучают сразу на задачах из бенча, для которых в качестве ответа берётся вариант, наиболее часто встречающийся в ответах модели. Но для сложных задач такой подход, очевидно, не работает, так как псевдо-метки часто оказываются неправильными.
Здесь же предлагается на основе задач из бенча синтезировать ряд задач попроще и дообучаться в той же парадигме уже на них. Логика следующая: на простых задачах majority voting чаще будет давать правильные ответы и это выльется в нормальный сигнал для обучения.
При этом модель для синтеза вопросов также проходит через несколько итераций улучшений, что приводит к ещё лучшему качеству вопросов и, как следствие, качеству финальной модели солвера.
На бенчах, конечно, метод рвёт всё, с чем сравнивается, но и вычислительные затраты на это все не хилые. Однако это всё может оказаться worth-it, если получится с помощью заскейленной версии такого обучения решить какую-нибудь действительно сложную задачу, которая не поддаётся людям.
Источник: https://www.arxiv.org/abs/2601.22628.
@experimentality
Как поступает усердный школьник, если у него не получается решить задачу?
В обычном Test Time RL (TTRL) LLM обучают сразу на задачах из бенча, для которых в качестве ответа берётся вариант, наиболее часто встречающийся в ответах модели. Но для сложных задач такой подход, очевидно, не работает, так как псевдо-метки часто оказываются неправильными.
Здесь же предлагается на основе задач из бенча синтезировать ряд задач попроще и дообучаться в той же парадигме уже на них. Логика следующая: на простых задачах majority voting чаще будет давать правильные ответы и это выльется в нормальный сигнал для обучения.
При этом модель для синтеза вопросов также проходит через несколько итераций улучшений, что приводит к ещё лучшему качеству вопросов и, как следствие, качеству финальной модели солвера.
На бенчах, конечно, метод рвёт всё, с чем сравнивается, но и вычислительные затраты на это все не хилые. Однако это всё может оказаться worth-it, если получится с помощью заскейленной версии такого обучения решить какую-нибудь действительно сложную задачу, которая не поддаётся людям.
Источник: https://www.arxiv.org/abs/2601.22628.
@experimentality
arXiv.org
TTCS: Test-Time Curriculum Synthesis for Self-Evolving
Test-Time Training offers a promising way to improve the reasoning ability of large language models (LLMs) by adapting the model using only the test questions. However, existing methods struggle...
🔥4
Forwarded from Нейронавт | Нейросети в творчестве
PaperBanana: Automating Academic Illustration for AI Scientists
Генерилка иллюстрации для научных работ от Гугл, конкурент опенсорсного SciGenBench
Работает как команда из пяти агентов: один ищет примеры, другой планирует содержание, третий задаёт стиль, четвёртый превращает текст в картинки, а пятый проверяет и улучшает результат
Гитхаб - вот гитхаб пустой, он предмет простой
#text2image
Генерилка иллюстрации для научных работ от Гугл, конкурент опенсорсного SciGenBench
Работает как команда из пяти агентов: один ищет примеры, другой планирует содержание, третий задаёт стиль, четвёртый превращает текст в картинки, а пятый проверяет и улучшает результат
Гитхаб - вот гитхаб пустой, он предмет простой
#text2image
🤣4
Forwarded from gonzo-обзоры ML статей
Фильтрация на уровне токенов при обучении даёт сильно более безопасные модели, чем другие способы.
Shaping capabilities with token-level data filtering
Neil Rathi, Alec Radford
Статья: https://arxiv.org/abs/2601.21571
Ревью: https://arxiviq.substack.com/p/shaping-capabilities-with-token-level
Код: https://github.com/neilrathi/token-filtering
Модель: Custom Transformers (up to 1.8B)
# TL;DR
ЧТО сделали: Предложили метод потокенной фильтрации данных (token-level data filtering) для хирургического удаления конкретных способностей модели (на примере медицинских знаний) на этапе предобучения. Обучая легковесные классификаторы находить и маскировать специфические токены, авторы не дают модели выучивать опасные концепты, сохраняя при этом соседние общие знания.
ПОЧЕМУ это важно: Это сдвиг парадигмы от безопасности "постфактум" (RLHF/Unlearning) к безопасности "ab initio" (изначальной). Результаты впечатляют: потокенная фильтрация масштабируется значительно лучше, чем удаление целых документов, создавая замедление в 7000 раз (по вычислительным затратам), необходимое модели для повторного обретения забытых знаний на масштабе 1.8B параметров. Кроме того, среди авторов — Алек Рэдфорд (создатель GPT-2 и GPT-3), что сигнализирует о серьезном повороте индустрии в сторону курирования данных как главного рычага безопасности.
Подробнее: https://t.me/gonzo_ML_podcasts/2319
Shaping capabilities with token-level data filtering
Neil Rathi, Alec Radford
Статья: https://arxiv.org/abs/2601.21571
Ревью: https://arxiviq.substack.com/p/shaping-capabilities-with-token-level
Код: https://github.com/neilrathi/token-filtering
Модель: Custom Transformers (up to 1.8B)
# TL;DR
ЧТО сделали: Предложили метод потокенной фильтрации данных (token-level data filtering) для хирургического удаления конкретных способностей модели (на примере медицинских знаний) на этапе предобучения. Обучая легковесные классификаторы находить и маскировать специфические токены, авторы не дают модели выучивать опасные концепты, сохраняя при этом соседние общие знания.
ПОЧЕМУ это важно: Это сдвиг парадигмы от безопасности "постфактум" (RLHF/Unlearning) к безопасности "ab initio" (изначальной). Результаты впечатляют: потокенная фильтрация масштабируется значительно лучше, чем удаление целых документов, создавая замедление в 7000 раз (по вычислительным затратам), необходимое модели для повторного обретения забытых знаний на масштабе 1.8B параметров. Кроме того, среди авторов — Алек Рэдфорд (создатель GPT-2 и GPT-3), что сигнализирует о серьезном повороте индустрии в сторону курирования данных как главного рычага безопасности.
Подробнее: https://t.me/gonzo_ML_podcasts/2319
arXiv.org
Shaping capabilities with token-level data filtering
Current approaches to reducing undesired capabilities in language models are largely post hoc, and can thus be easily bypassed by adversaries. A natural alternative is to shape capabilities during...
🔥5
Оказывается, что если добавить tie-breaker в GRPO для ответов с одинаковыми значениями correctness reward (например выбирать ответ с наименьшей длиной), то метод будет работать лучше. Ну и в целом рекомендуют переходить на relative оценку (первое, второе, третье место и тд) вместо абсолютных значений награды, так как это делает обучение стабильнее, хотя это.
Источник: https://www.arxiv.org/abs/2601.23058.
@experimentality
Источник: https://www.arxiv.org/abs/2601.23058.
@experimentality
arXiv.org
From Absolute to Relative: Rethinking Reward Shaping in...
Reinforcement learning has become a cornerstone for enhancing the reasoning capabilities of Large Language Models, where group-based approaches such as GRPO have emerged as efficient paradigms...
👍3🤯3
Forwarded from Just links
BabyVision: Visual Reasoning Beyond Language https://unipat.ai/blog/BabyVision
UniPat AI
BabyVision: Visual Reasoning Beyond Language
State-of-the-art MLLMs achieve PhD-level language reasoning but struggle with visual tasks that 3-year-olds solve effortlessly. We introduce BabyVision, a benchmark revealing the infancy of AI vision.
😢2
Как использовать текстовый фидбек в RL?
RLVR выглядит неинтуитивно с человеческой точки зрения: если человек ошибается, ему обычно объясняют почему, тогда как в RLVR модель получает лишь бинарный сигнал (1 бит информации) — верно или неверно. Авторы предлагают заменить этот минимальный сигнал на текстовый фидбек.
Процесс устроен так: сначала модель генерирует rollout, затем LLM-критик выдаёт текстовое объяснение ошибок, после чего на основе исходного решения и критики строится улучшенный rollout. Далее возможны два варианта обучения: либо использовать RL непосредственно на улучшенном решении, либо применять SFT и учить модель предсказывать фидбек критика.
Проверяли, конечно, на математике, в зависимости от бенча получается либо лучше, либо на уровне с проверенными бейзлайнами (GRPO, DAPO, какие-то фидбек методы). Что интересно, в качестве фидбека в формальных системах можно брать не только LLM, но и ошибки компилятора, линтера и так далее. Короче просто для дальнейших исследований невероятный.
Источник: https://www.arxiv.org/abs/2602.02482.
@experimentality
RLVR выглядит неинтуитивно с человеческой точки зрения: если человек ошибается, ему обычно объясняют почему, тогда как в RLVR модель получает лишь бинарный сигнал (1 бит информации) — верно или неверно. Авторы предлагают заменить этот минимальный сигнал на текстовый фидбек.
Процесс устроен так: сначала модель генерирует rollout, затем LLM-критик выдаёт текстовое объяснение ошибок, после чего на основе исходного решения и критики строится улучшенный rollout. Далее возможны два варианта обучения: либо использовать RL непосредственно на улучшенном решении, либо применять SFT и учить модель предсказывать фидбек критика.
Проверяли, конечно, на математике, в зависимости от бенча получается либо лучше, либо на уровне с проверенными бейзлайнами (GRPO, DAPO, какие-то фидбек методы). Что интересно, в качестве фидбека в формальных системах можно брать не только LLM, но и ошибки компилятора, линтера и так далее. Короче просто для дальнейших исследований невероятный.
Источник: https://www.arxiv.org/abs/2602.02482.
@experimentality
arXiv.org
Expanding the Capabilities of Reinforcement Learning via Text Feedback
The success of RL for LLM post-training stems from an unreasonably uninformative source: a single bit of information per rollout as binary reward or preference label. At the other extreme,...
❤3👍2
Forwarded from что-то на DL-ском
А ЧТО БУДЕТ ЕСЛИ ДАТЬ АГЕНТУ ПОДУМАТЬ ПОДОЛЬШЕ?
Scaling Test-time Compute for LLM Agents
Первое систематическое исследование test-time scaling для языковых агентов. Не для LLM на задачках по математике, а прям для агентов с тулами, мультистепами и тд. Тестировали на GAIA бенчмарке (165 задач, 3 уровня сложности), базовая модель GPT-4.1
Суть проблемы в том, что обычные LLM BoN работают тривиально (сгенерил N ответов, выбрал лучший). В агентах всё сложнее. У нас есть цепочка шагов, ошибки накапливаются, и если ты рандомно генеришь N ответов на каждом шагу, можешь только навредить
Что пробовали и что нашли:
✨ Parallel sampling
BoN, BoN-wise (посттеповый), Beam Search, DVTS. BoN победил всех с 63.03 (baseline 55.76). НО на самых сложных задачах (level 3) лучше всех оказался BoN-wise (38.46), потому что он расширяет пространство поиска на каждом шаге решения, а не просто перезапускает всю траекторию. Beam Search и DVTS почти не дали прироста потому что зависят от точности верификатора при прунинге
✨ Рефлексия
вот тут самое вкусное. Сделали модель RefM, которая суммаризирует предыдущие шаги и подсказывает агенту. Рефлексия НА КАЖДОМ ШАГЕ слегка УХУДШИЛА результат (55.15 vs 55.76). Модель сбивается с мысли от постоянного самоанализа. Но если рефлексировать только на плохих шагах (score < 2) результат растёт до 56.36.
Цитата из статьи, которую я выделила, пока читала: knowing when to reflect is more important than reflecting at every step.
✨ Мерджинг результатов
Тестили три подхода: voting (голосовалка большинством), scoring (верификатор ставит оценку каждому), list-wise (LLM видит все варианты сразу и выбирает лучший). List-wise уверенно победил и в мерджинге финальных ответов, и в верификации промежуточных шагов. Прямое сравнение вариантов оказалось эффективнее, чем независимая оценка каждого
✨ Multi-agent diversity
микс из разных SOTA моделей (GPT-4.1 + Claude-3.5 + Claude-3.7 + Gemini-2.5-PRO) даёт Pass@4 = 74.55, что выше open-source SOTA. Разные модели хороши в разном. Кто-то лучше кодит, кто-то лучше с тулами, и в итоге ансамбль разнородных моделей покрывает больше кейсов, чем 4 копии одной модели
Статья разъеб. Пару моментиков есть чтобы забрать в экспы + пересекается с тем, что я буду рассказать на OpenTalks в конце февраля (об этом в следующем посте). Схожесть в проблематике и ее решении. Авторы по сути нашли, что credit assignment в мультистеповых агентах это ключевая проблема, и решают её на инференсе через selective reflection и list-wise verification. То же самое мы в команде решали на трене через умную группировку наград
📖 Папир
🖥 Код
Scaling Test-time Compute for LLM Agents
Первое систематическое исследование test-time scaling для языковых агентов. Не для LLM на задачках по математике, а прям для агентов с тулами, мультистепами и тд. Тестировали на GAIA бенчмарке (165 задач, 3 уровня сложности), базовая модель GPT-4.1
Суть проблемы в том, что обычные LLM BoN работают тривиально (сгенерил N ответов, выбрал лучший). В агентах всё сложнее. У нас есть цепочка шагов, ошибки накапливаются, и если ты рандомно генеришь N ответов на каждом шагу, можешь только навредить
Что пробовали и что нашли:
BoN, BoN-wise (посттеповый), Beam Search, DVTS. BoN победил всех с 63.03 (baseline 55.76). НО на самых сложных задачах (level 3) лучше всех оказался BoN-wise (38.46), потому что он расширяет пространство поиска на каждом шаге решения, а не просто перезапускает всю траекторию. Beam Search и DVTS почти не дали прироста потому что зависят от точности верификатора при прунинге
вот тут самое вкусное. Сделали модель RefM, которая суммаризирует предыдущие шаги и подсказывает агенту. Рефлексия НА КАЖДОМ ШАГЕ слегка УХУДШИЛА результат (55.15 vs 55.76). Модель сбивается с мысли от постоянного самоанализа. Но если рефлексировать только на плохих шагах (score < 2) результат растёт до 56.36.
Цитата из статьи, которую я выделила, пока читала: knowing when to reflect is more important than reflecting at every step.
Тестили три подхода: voting (голосовалка большинством), scoring (верификатор ставит оценку каждому), list-wise (LLM видит все варианты сразу и выбирает лучший). List-wise уверенно победил и в мерджинге финальных ответов, и в верификации промежуточных шагов. Прямое сравнение вариантов оказалось эффективнее, чем независимая оценка каждого
микс из разных SOTA моделей (GPT-4.1 + Claude-3.5 + Claude-3.7 + Gemini-2.5-PRO) даёт Pass@4 = 74.55, что выше open-source SOTA. Разные модели хороши в разном. Кто-то лучше кодит, кто-то лучше с тулами, и в итоге ансамбль разнородных моделей покрывает больше кейсов, чем 4 копии одной модели
Статья разъеб. Пару моментиков есть чтобы забрать в экспы + пересекается с тем, что я буду рассказать на OpenTalks в конце февраля (об этом в следующем посте). Схожесть в проблематике и ее решении. Авторы по сути нашли, что credit assignment в мультистеповых агентах это ключевая проблема, и решают её на инференсе через selective reflection и list-wise verification. То же самое мы в команде решали на трене через умную группировку наград
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
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