Forwarded from Душный NLP
DAPO: An Open-Source LLM Reinforcement Learning System at Scale
Сегодня разберём короткую, но ёмкую статью из Китая. Авторы предлагают опенсорсный метод работы с большими LLM RL: алгоритмы, инфраструктуру кода и датасеты. Забавно, что на момент подготовки обзора у ребят почти пустой GitHub — большая его часть заполнена картинками.
DAPO — Dynamic sAmpling Policy Optimization — не представляет из себя чего-то кардинально нового. Использованные авторами подходы либо витали в воздухе, либо публиковались в других статьях.
Этот метод — модификация GRPO, который в свою очередь получился после улучшения PPO. Все эти алгоритмы объединяет возможность переиспользовать генерации. В обычных on-policy RL-алгоритмах каждый шаг оптимизации требует генерации свежей модели. А в PPO-подобных можно заранее создать большой батч ответов и сделать для него не один, а сразу несколько шагов оптимизации. Зачем? Большой батч эффективнее генерировать!
Новое классное свойство появляется за счёт использования importance sampling и трюка с обрезкой градиентов там, где свежая политика и так уже слишком сильно отличается от той, что сгенерировала данные.
Конкретно DAPO отличается от GRPO четырьмя вещами. Здесь есть:
— Модификация процедуры обрезки градиентов — Clip-Higher. Верхний порог обрезки выше, чем у GRPO, что улучшает итоговое качество.
— Динамическое сэмплирование: авторы предлагают с запасом генерировать ответы и выкидывать те, которые набрали одинаковую награду.
— Усреднение функционала ошибки по токенам, а не по запросам. Это придаёт больший вес длинным генерациям в общем функционале.
— Фильтрация слишком длинных ответов. Ответы, превысившие рекомендуемую длину получают небольшой штраф, а ответы вышедшие за максимальную длину — вообще не участвуют в оптимизации.
Кроме прочего, авторы модифицируют обучающий датасет: используют LLM, которая модифицирует запросы так, чтобы правильные ответы на них были целыми числами. Это упрощает парсинг ответов модели и их валидацию.
Самый классный, на мой взгляд, результат, — авторам DAPO удалось обойти SoTA DeepSeek-R1-Zero-Qwen-32B в решении задач олимпиадной математики. При этом они потратили 50% от мощностей, которые использовали для аналогичного обучения Qwen.
Разбор подготовил❣ Павел Темирчев
Душный NLP
Сегодня разберём короткую, но ёмкую статью из Китая. Авторы предлагают опенсорсный метод работы с большими LLM RL: алгоритмы, инфраструктуру кода и датасеты. Забавно, что на момент подготовки обзора у ребят почти пустой GitHub — большая его часть заполнена картинками.
DAPO — Dynamic sAmpling Policy Optimization — не представляет из себя чего-то кардинально нового. Использованные авторами подходы либо витали в воздухе, либо публиковались в других статьях.
Этот метод — модификация GRPO, который в свою очередь получился после улучшения PPO. Все эти алгоритмы объединяет возможность переиспользовать генерации. В обычных on-policy RL-алгоритмах каждый шаг оптимизации требует генерации свежей модели. А в PPO-подобных можно заранее создать большой батч ответов и сделать для него не один, а сразу несколько шагов оптимизации. Зачем? Большой батч эффективнее генерировать!
Новое классное свойство появляется за счёт использования importance sampling и трюка с обрезкой градиентов там, где свежая политика и так уже слишком сильно отличается от той, что сгенерировала данные.
Конкретно DAPO отличается от GRPO четырьмя вещами. Здесь есть:
— Модификация процедуры обрезки градиентов — Clip-Higher. Верхний порог обрезки выше, чем у GRPO, что улучшает итоговое качество.
— Динамическое сэмплирование: авторы предлагают с запасом генерировать ответы и выкидывать те, которые набрали одинаковую награду.
— Усреднение функционала ошибки по токенам, а не по запросам. Это придаёт больший вес длинным генерациям в общем функционале.
— Фильтрация слишком длинных ответов. Ответы, превысившие рекомендуемую длину получают небольшой штраф, а ответы вышедшие за максимальную длину — вообще не участвуют в оптимизации.
Кроме прочего, авторы модифицируют обучающий датасет: используют LLM, которая модифицирует запросы так, чтобы правильные ответы на них были целыми числами. Это упрощает парсинг ответов модели и их валидацию.
Самый классный, на мой взгляд, результат, — авторам DAPO удалось обойти SoTA DeepSeek-R1-Zero-Qwen-32B в решении задач олимпиадной математики. При этом они потратили 50% от мощностей, которые использовали для аналогичного обучения Qwen.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Душный NLP
Впечатления от конференции ICLR 2025
Минувшая ICLR была насыщенной и полезной. Мы попросили инженеров Яндекса, посетивших конференцию, поделиться впечатлениями и рассказать о том, что им запомнилось.
Материалы, которые упоминаются в карточках:
— Asynchronous RLHF. Faster And More Efficient Off-Policy RL For LLMs
— Learning Dynamics of LLM Finetuning
— Cheating Automatic LLM Benchmarks: Null Models Achieve High Win Rates
— Strong Model Collapse
— Maximizing the Potential of Synthetic Data: Insights from Random Matrix Theory
— IST-DASLab/MoE-Quant: Code for data-aware compression of DeepSeek models
*Компания Meta признана экстремистской организацией в России.
Душный NLP
Минувшая ICLR была насыщенной и полезной. Мы попросили инженеров Яндекса, посетивших конференцию, поделиться впечатлениями и рассказать о том, что им запомнилось.
Материалы, которые упоминаются в карточках:
— Asynchronous RLHF. Faster And More Efficient Off-Policy RL For LLMs
— Learning Dynamics of LLM Finetuning
— Cheating Automatic LLM Benchmarks: Null Models Achieve High Win Rates
— Strong Model Collapse
— Maximizing the Potential of Synthetic Data: Insights from Random Matrix Theory
— IST-DASLab/MoE-Quant: Code for data-aware compression of DeepSeek models
*Компания Meta признана экстремистской организацией в России.
Душный NLP
Forwarded from Data Blog
🐈⬛ Потому что у меня двое.
Cats Confuse Reasoning LLMs — arXiv:2503.01781
Привет, друзья! С одной стороны, известно, что если сказать LLM, что успех в задаче принесёт награду (например, деньги), это может улучшить её перформанс (arXiv:2312.16171, arXiv:2506.06303v1). С другой — вот ещё свежая статья про то, как LLM можно сломать простой вставкой случайного текста в промпт.
Зачем об этом знать, (кроме котиков)?
Потому что это демонстрирует уязвимость LLM к незначительному шуму в промпте. А значит — риск для устойчивости модели при использовании (если ввод не фильтруется).
Что показали:
Reasoning‑модель можно сбить с толку без изменения сути задачи. Достаточно добавить в тело промпта фразу вроде: Interesting fact: cats sleep for most of their lives. (Эта вставка и дала название статье.)
Что сделали:
1) Разработали pipeline CatAttack — автоматический подбор текстовых триггеров (генерировали их с помощью GPT‑4o).
2) Среди подобранных триггеров выделили три типа и оценили их эффективность:
Redirection of Focus
Unrelated Trivia
Misleading Questions
3) Подбирали триггеры на слабой модели DeepSeek V3, а затем проверяли их переносимость на более мощные DeepSeek R1 и Qwen‑32B.
Что получили:
Существенное падение точности reasoning у сильных моделей.
Замедление генерации в 1.5–4 раза.
Самыми разрушительными оказались подсказки типа Misleading Questions, например: "Could the answer be around 175?"
Ограничения:
Важно учесть, что задачи тестировали только на математических задачах из GSM8K и не исследовалась устойчивость более продвинутых моделей (GPT-4, Claude, Gemini). Плюс, эффект может снижаться, если модель была обучена фильтровать ввод.
Но даже с этим — это по-настоящему забавно: как LLM ломается из-за случайной фразы. Особенно когда она про котов :)
Меня эта статья просто безумно улыбнула, поэтому она здесь. И вот такой пост выходного дня, друзья! Надеюсь, у вас лето — потому что у меня — наконец-то да!
Оттаивающий от кризиса,
ваш Дата-автор
Cats Confuse Reasoning LLMs — arXiv:2503.01781
Привет, друзья! С одной стороны, известно, что если сказать LLM, что успех в задаче принесёт награду (например, деньги), это может улучшить её перформанс (arXiv:2312.16171, arXiv:2506.06303v1). С другой — вот ещё свежая статья про то, как LLM можно сломать простой вставкой случайного текста в промпт.
Зачем об этом знать, (кроме котиков)?
Потому что это демонстрирует уязвимость LLM к незначительному шуму в промпте. А значит — риск для устойчивости модели при использовании (если ввод не фильтруется).
Что показали:
Reasoning‑модель можно сбить с толку без изменения сути задачи. Достаточно добавить в тело промпта фразу вроде: Interesting fact: cats sleep for most of their lives. (Эта вставка и дала название статье.)
Что сделали:
1) Разработали pipeline CatAttack — автоматический подбор текстовых триггеров (генерировали их с помощью GPT‑4o).
2) Среди подобранных триггеров выделили три типа и оценили их эффективность:
Redirection of Focus
Unrelated Trivia
Misleading Questions
3) Подбирали триггеры на слабой модели DeepSeek V3, а затем проверяли их переносимость на более мощные DeepSeek R1 и Qwen‑32B.
Что получили:
Существенное падение точности reasoning у сильных моделей.
Замедление генерации в 1.5–4 раза.
Самыми разрушительными оказались подсказки типа Misleading Questions, например: "Could the answer be around 175?"
Ограничения:
Важно учесть, что задачи тестировали только на математических задачах из GSM8K и не исследовалась устойчивость более продвинутых моделей (GPT-4, Claude, Gemini). Плюс, эффект может снижаться, если модель была обучена фильтровать ввод.
Но даже с этим — это по-настоящему забавно: как LLM ломается из-за случайной фразы. Особенно когда она про котов :)
Меня эта статья просто безумно улыбнула, поэтому она здесь. И вот такой пост выходного дня, друзья! Надеюсь, у вас лето — потому что у меня — наконец-то да!
Оттаивающий от кризиса,
ваш Дата-автор
Forwarded from DevFM
Cursor изнутри
Недавно вышла немного рекламная, но легкая и интересная статья от The Pragmatic Engineer о том, как устроен Cursor узнутри.
В начале статьи просто любопытные цифры о Cursor. Дальше автор рассказывает нам о технологическом стеке. Из интересного:
- TypeScript – бизнес-логика, критические штуки на Rust
- Turbopuffer – основное KV-хранилище, держит зашифрованные файлы + Merkle-деревья для синка
- Pinecone – векторная БД для семантического поиска по коду
- Datadog, PagerDuty, Sentry, Amplitude для обзервабилити
- Linear – для таск трекинга (рекомендую попробовать для тех, кто не пробовал, интересное решение)
Cursor не хранит наш код на своих серверах. Когда вы отправляете запрос в Chat, происходит следующее:
1. Запрос уходит на сервер
2. Сервер решает, что это – вопрос о коде, и запускает векторный поиск по embedding'ам, которые заранее были созданы на сервере во время “индексации” проекта
3. По результатам векторного поиска сервер понимает, какие файлы могут быть релевантны и запрашивает эти конкретные файлы обратно у клиента
4. Клиент шлёт нужные части кода (зашифрованно) – только те, что реально понадобились
5. Сервер “собирает” полный контекст и запускает inference для ответа
6. Ответ возвращается в чат
Отдельно стоит рассказать, как Cursor узнаёт, какие файлы изменились, и переиндексирует только их. Для используются Merkle-деревья:
1. каждый файл разбивается на чанки, каждый чанк хешируется
2. хеши объединяются попарно и формируют узлы следующего уровня
3. в результате строится дерево, корневой хеш которого отражает состояние всего проекта – аналогичное дерево строится и на клиенте, и на сервере
Каждые ~3 минуты клиент сравнивает свой корневой хеш с серверным:
– если хеши совпадают – индекс остаётся прежним
– если отличаются – обход дерева точно выявляет изменённые чанки, и переиндексирует только их
#ai
Недавно вышла немного рекламная, но легкая и интересная статья от The Pragmatic Engineer о том, как устроен Cursor узнутри.
В начале статьи просто любопытные цифры о Cursor. Дальше автор рассказывает нам о технологическом стеке. Из интересного:
- TypeScript – бизнес-логика, критические штуки на Rust
- Turbopuffer – основное KV-хранилище, держит зашифрованные файлы + Merkle-деревья для синка
- Pinecone – векторная БД для семантического поиска по коду
- Datadog, PagerDuty, Sentry, Amplitude для обзервабилити
- Linear – для таск трекинга (рекомендую попробовать для тех, кто не пробовал, интересное решение)
Cursor не хранит наш код на своих серверах. Когда вы отправляете запрос в Chat, происходит следующее:
1. Запрос уходит на сервер
2. Сервер решает, что это – вопрос о коде, и запускает векторный поиск по embedding'ам, которые заранее были созданы на сервере во время “индексации” проекта
3. По результатам векторного поиска сервер понимает, какие файлы могут быть релевантны и запрашивает эти конкретные файлы обратно у клиента
4. Клиент шлёт нужные части кода (зашифрованно) – только те, что реально понадобились
5. Сервер “собирает” полный контекст и запускает inference для ответа
6. Ответ возвращается в чат
Отдельно стоит рассказать, как Cursor узнаёт, какие файлы изменились, и переиндексирует только их. Для используются Merkle-деревья:
1. каждый файл разбивается на чанки, каждый чанк хешируется
2. хеши объединяются попарно и формируют узлы следующего уровня
3. в результате строится дерево, корневой хеш которого отражает состояние всего проекта – аналогичное дерево строится и на клиенте, и на сервере
Каждые ~3 минуты клиент сравнивает свой корневой хеш с серверным:
– если хеши совпадают – индекс остаётся прежним
– если отличаются – обход дерева точно выявляет изменённые чанки, и переиндексирует только их
#ai
Pragmaticengineer
Real-world engineering challenges: building Cursor
Cursor has grown 100x in load in just a year, sees 1M+ QPS for its data layer, and serves billions of code completions, daily. A deepdive into how it’s built with cofounder, Sualeh Asif
Forwarded from Ars Poetica Numeralis
Набрел сегодня на лонгрид из 2024 г. на тему того, как выбирать задачи для оценки прогресса по ходу обучения LM:
https://huggingface.co/spaces/HuggingFaceFW/blogpost-fine-tasks
Две идеи показались мне интересными - они могут пригодиться вне контекста претрейна. Не то, чтобы они были каким-то откровеннием или ноу-хау авторов. Просто полезно напоминать себе о таких полезняшках при работе с данными.
Итак, авторы описывают, как они выбирали хорошие задачи для сравнения между собой языковых моделей и датасетов для их обучения (даже свой бенчмарк LightEval сделали, кстати).
Среди важных свойств задач бенчмарка авторы выделают:
1) Monotonicity: хорошо, когда рассчитываемая метрика монотонно растет по мере сжигания компьюта. Более строго это означает, что график метрика(пройденно_шагов) должен возрастать (или не убывать) почти везде. Как авторы предлагают оценить "возрастает почти везде"? С помощью коэффициента ранговой корреляции Спирмена:
2) Model Ordering Consistency: крайне полезно, если присутствует стабильность ранжировки замеряемых сущностей (например, датасетов или моделей) с помощью метрики. По мере обучения ранжировка не должна сильно меняться: плохая модель должна оставаться плохой при сравнении с другими моделями по мере того, как идет обучение моделей и их периодический замер:
Это обеспечивает предсказуемость при масштабировании обучения.
Как авторы оценивают консистентность ранжировки? С помощью Kendall's Tau, специальной статистики для таких случаев.
https://huggingface.co/spaces/HuggingFaceFW/blogpost-fine-tasks
Две идеи показались мне интересными - они могут пригодиться вне контекста претрейна. Не то, чтобы они были каким-то откровеннием или ноу-хау авторов. Просто полезно напоминать себе о таких полезняшках при работе с данными.
Итак, авторы описывают, как они выбирали хорошие задачи для сравнения между собой языковых моделей и датасетов для их обучения (даже свой бенчмарк LightEval сделали, кстати).
Среди важных свойств задач бенчмарка авторы выделают:
1) Monotonicity: хорошо, когда рассчитываемая метрика монотонно растет по мере сжигания компьюта. Более строго это означает, что график метрика(пройденно_шагов) должен возрастать (или не убывать) почти везде. Как авторы предлагают оценить "возрастает почти везде"? С помощью коэффициента ранговой корреляции Спирмена:
we used the Spearman rank correlation to quantify the correlation between steps and score.
2) Model Ordering Consistency: крайне полезно, если присутствует стабильность ранжировки замеряемых сущностей (например, датасетов или моделей) с помощью метрики. По мере обучения ранжировка не должна сильно меняться: плохая модель должна оставаться плохой при сравнении с другими моделями по мере того, как идет обучение моделей и их периодический замер:
This means our tasks should rank datasets trained using very few tokens (we typically run data ablations on 30B tokens), in the same order as they would when trained for longer, after significantly more steps.
Это обеспечивает предсказуемость при масштабировании обучения.
Как авторы оценивают консистентность ранжировки? С помощью Kendall's Tau, специальной статистики для таких случаев.
huggingface.co
Scaling FineWeb to 1000+ languages: Step 1: finding signal in 100s of evaluation tasks - a Hugging Face Space by HuggingFaceFW
This application helps evaluate multilingual models across 1000+ languages using a comprehensive suite of tasks called FineTasks. Users can assess model performance in various languages and task ty...
Forwarded from что-то на инженерном
Prompt Engineering vs Context Engineering
В последнее время все чаще замечаю, что если раньше все обсуждали prompt engineering, то теперь на первый план выходит context engineering.
Так в чем же заключается разница?
Тут важно понимать базовый принцип работы LLM: предсказание следующего токена на основе контекста.
➡️ Prompt engineering:
Пользователь формулирует запрос максимально подробно, чтобы модель поняла задачу. Вся нужная информация и инструкции (т.е. весь контекст) задаются в одном сообщении.
Пример задания:
Весь контекст, схема таблиц и задача заданы уже в промпте.
➡️ Context engineering обширнее:
Информация для насыщения контекста может подаваться многими путями:
➡️ Инструкции (system prompt): правила, примеры, ограничения
➡️ История диалога: переписка, предыдущие ответы.
➡️ Примеры
➡️ Долговременная память: знания о пользователе, прошлых задачах
➡️ Внешние данные (RAG): документы, базы, API
➡️ Инструменты: функции, которые может вызывать агент
➡️ Структура вывода: формат, например JSON
В частности, можно попросить модель саму задать уточняющие вопросы для донасыщения контекста.
🟣 То, что вам в своем контексте кажется очевидным, для модели может таковым не являться, и пробелы она заполнит фантазиями.
🟣 Когда контекст достаточно насыщен, пользователь может задать короткий, естественный запрос и получить адекватный ответ.
🟣 Вся дополнительная информация (схемы, примеры, история, правила, внешние данные) уже встроена в контекст системы и подаётся модели автоматически. Это особенно удобно, когда вопросов несколько, а контекст достаточно создать однажды.
Пример задания:
В данном примере вся нужная информация (структура БД, формат вывода, даже примеры корректных SQL-запросов) уже заранее добавлена в системный контекст и не требует от пользователя повторять детали каждый раз.
Поскольку сейчас активно работаю с LLM над задачей речевой аналитики, то прихожу к мысли, что недостаточно просто написать один промпт. Хотя я максимально пытаюсь уложить в один промпт несколько текстов на вход, инструкцию, скрипт, запрос и структуру вывода. Но кажется, чтобы решить задачу качественно придется применить подход context инжиниринга 🤔.
Источники:
🟣 The New Skill in AI is Not Prompting, It's Context Engineering
🟣 Context Engineering: Going Beyond Prompts To Push AI
🟣 Context Engineering: Going Beyond Prompt Engineering and RAG
©️что-то на инженерном
В последнее время все чаще замечаю, что если раньше все обсуждали prompt engineering, то теперь на первый план выходит context engineering.
Так в чем же заключается разница?
Тут важно понимать базовый принцип работы LLM: предсказание следующего токена на основе контекста.
Пользователь формулирует запрос максимально подробно, чтобы модель поняла задачу. Вся нужная информация и инструкции (т.е. весь контекст) задаются в одном сообщении.
Пример задания:
Напиши SQL-запрос, который выберет имена и идентификаторы всех студентов из таблицы students, обучающихся на факультете Computer Science. Таблицы: departments (DepartmentId, DepartmentName), students (DepartmentId, StudentId, StudentName).
Весь контекст, схема таблиц и задача заданы уже в промпте.
Информация для насыщения контекста может подаваться многими путями:
В частности, можно попросить модель саму задать уточняющие вопросы для донасыщения контекста.
Пример задания:
Покажи студентов факультета Computer Science.
В данном примере вся нужная информация (структура БД, формат вывода, даже примеры корректных SQL-запросов) уже заранее добавлена в системный контекст и не требует от пользователя повторять детали каждый раз.
Поскольку сейчас активно работаю с LLM над задачей речевой аналитики, то прихожу к мысли, что недостаточно просто написать один промпт. Хотя я максимально пытаюсь уложить в один промпт несколько текстов на вход, инструкцию, скрипт, запрос и структуру вывода. Но кажется, чтобы решить задачу качественно придется применить подход context инжиниринга 🤔.
Источники:
©️что-то на инженерном
Please open Telegram to view this post
VIEW IN TELEGRAM