Сколько информации реально хранит в себе один эмбеддинг LLM?
Вы когда-нибудь задумывались, сколько информации можно запихнуть в один вектор языковой модели? Мои знакомые недавно поставили рекорд — 1568 токенов в ОДНОМ эмбеддинге! И это при том, что другие методы компрессии еле-еле выдают сжатие в 10 раз.
Метод до безумия прост: берём [mem] вектор, добавляем его в начало инпута, а затем просто оптимизируем его, чтобы LLM могла по нему восстановить исходный текст. Никаких сложных энкодеров — просто SGD по входному эмбеддингу. Вот капасити некоторых моделей:
- Llama-3.1-8B: 1568 токенов
- Llama-3.2-1B: 512 токенов
- Pythia-160M: жалкие 80 токенов
Самое интересное, что всё упирается не в длину текста, а в его сложность. Если энтропия текста ниже определённого порога — модель восстановит его идеально, если выше — то уже с ошибками. А если добавить больше [mem] векторов, то ёмкость растёт почти линейно. Например Llama-3.2-1B может упаковать весь "Хоббит" в ~200 векторов.
И при всём этом модели используют только 10-30% теоретической ёмкости своих эмбеддингов. Причём новые модели (Llama, OLMo) гораздо эффективнее старых (Pythia, OPT).
Статья, GitHub
Вы когда-нибудь задумывались, сколько информации можно запихнуть в один вектор языковой модели? Мои знакомые недавно поставили рекорд — 1568 токенов в ОДНОМ эмбеддинге! И это при том, что другие методы компрессии еле-еле выдают сжатие в 10 раз.
Метод до безумия прост: берём [mem] вектор, добавляем его в начало инпута, а затем просто оптимизируем его, чтобы LLM могла по нему восстановить исходный текст. Никаких сложных энкодеров — просто SGD по входному эмбеддингу. Вот капасити некоторых моделей:
- Llama-3.1-8B: 1568 токенов
- Llama-3.2-1B: 512 токенов
- Pythia-160M: жалкие 80 токенов
Самое интересное, что всё упирается не в длину текста, а в его сложность. Если энтропия текста ниже определённого порога — модель восстановит его идеально, если выше — то уже с ошибками. А если добавить больше [mem] векторов, то ёмкость растёт почти линейно. Например Llama-3.2-1B может упаковать весь "Хоббит" в ~200 векторов.
И при всём этом модели используют только 10-30% теоретической ёмкости своих эмбеддингов. Причём новые модели (Llama, OLMo) гораздо эффективнее старых (Pythia, OPT).
Статья, GitHub
👍100🔥31🤯25❤3
Зачем все LLM фокусируют attention на первом токене? (by DeepMind & Oxford)
Давно известно, что многие головы внимания у LLM упорно «смотрят» на самый первый токен последовательности (чаще всего это токен
Авторы показывают, что такой «слив» внимания на первый токен — это не ошибка, а очень полезный механизм. Он работает примерно как «нулевая операция» (no-op), то есть помогает головам внимания эффективно ничего не делать и не вносить ненужных изменений в представления токенов, когда они не нужны.
Зачем это нужно? Постоянное активное перемешивание информации между токенами ведёт к трём серьёзным проблемам:
1. Rank collapse — представления всех токенов становятся линейно зависимыми.
2. Representational collapse — сильно растёт косинусная близость соседних токенов.
3. Over-squashing — дальние токены перестают эффективно обмениваться информацией.
Чем глубже модель и длиннее контекст, тем сильнее она нуждается в этом механизме. А если убрать первый токен
P.S. Что-то оооочень похожее нам рассказывал профессор Вячеслав Дубынин на курсах химии мозга — у людей тоже есть механизм предотвращающий "смешивание" активаций. А, например, ЛСД его ослабляет, вызывая галлюцинации.
Статья
Давно известно, что многие головы внимания у LLM упорно «смотрят» на самый первый токен последовательности (чаще всего это токен
<bos>). В моделях вроде GPT, LLaMA или Gemma такое внимание занимает до 80% от всех голов!Авторы показывают, что такой «слив» внимания на первый токен — это не ошибка, а очень полезный механизм. Он работает примерно как «нулевая операция» (no-op), то есть помогает головам внимания эффективно ничего не делать и не вносить ненужных изменений в представления токенов, когда они не нужны.
Зачем это нужно? Постоянное активное перемешивание информации между токенами ведёт к трём серьёзным проблемам:
1. Rank collapse — представления всех токенов становятся линейно зависимыми.
2. Representational collapse — сильно растёт косинусная близость соседних токенов.
3. Over-squashing — дальние токены перестают эффективно обмениваться информацией.
Чем глубже модель и длиннее контекст, тем сильнее она нуждается в этом механизме. А если убрать первый токен
<bos> во время инференса, у модели, привыкшей к нему, качество генерации сильно падает.P.S. Что-то оооочень похожее нам рассказывал профессор Вячеслав Дубынин на курсах химии мозга — у людей тоже есть механизм предотвращающий "смешивание" активаций. А, например, ЛСД его ослабляет, вызывая галлюцинации.
Статья
👍80🤔25❤21🔥12🌚2
ignore-topk: новая регуляризация для борьбы с деградацией LLM во время файнтюнинга (by DeepMind)
При дообучении языковые модели частенько портятся. Рисёрчеры из DeepMind показали, что проблема связана с тем, что LLM, пытаясь запомнить новый факт, начинает использовать лёгкие shortcut-ы вместо аккуратного внедрения новых знаний в веса. Она просто «раскладывает» новую информацию по уже знакомым ей понятиям (казалось бы это хорошо, но нет). Такое явление они назвали "праймингом" (aka разложение числа на простые множители), и из-за него LLM начинает путаться в фактах, выдавая новую информацию где не просили.
Авторы этой статьи предлагают потенциальное решение — регуляризацию
- Делаем обычный шаг файнтюнинга и смотрим на обновления весов (Δω).
- Отбираем top-k% самых больших обновлений и… просто удаляем их (умножаем на 0).
- Используем только небольшие изменения весов, которые не содержат шорткатов для быстрой меморизации.
Зачем так странно?
Оказывается, самые большие градиенты как раз и отвечают за «грязное» быстрое запоминание через прайминг. Игнорируя их, мы заставляем модель учиться медленнее и аккуратнее. При этом прайминг уменьшается на 90-95%, а способность запоминать новые факты не страдает.
Но авторы конечно молодцы, сами придумали бенчмарк, сами свой подход измерили, а на другие "learning without forgetting" методы вообще забили. Поэтому не могу сказать, что
Статья
При дообучении языковые модели частенько портятся. Рисёрчеры из DeepMind показали, что проблема связана с тем, что LLM, пытаясь запомнить новый факт, начинает использовать лёгкие shortcut-ы вместо аккуратного внедрения новых знаний в веса. Она просто «раскладывает» новую информацию по уже знакомым ей понятиям (казалось бы это хорошо, но нет). Такое явление они назвали "праймингом" (aka разложение числа на простые множители), и из-за него LLM начинает путаться в фактах, выдавая новую информацию где не просили.
Авторы этой статьи предлагают потенциальное решение — регуляризацию
ignore-topk. Идея до гениальности простая:- Делаем обычный шаг файнтюнинга и смотрим на обновления весов (Δω).
- Отбираем top-k% самых больших обновлений и… просто удаляем их (умножаем на 0).
- Используем только небольшие изменения весов, которые не содержат шорткатов для быстрой меморизации.
Зачем так странно?
Оказывается, самые большие градиенты как раз и отвечают за «грязное» быстрое запоминание через прайминг. Игнорируя их, мы заставляем модель учиться медленнее и аккуратнее. При этом прайминг уменьшается на 90-95%, а способность запоминать новые факты не страдает.
Но авторы конечно молодцы, сами придумали бенчмарк, сами свой подход измерили, а на другие "learning without forgetting" методы вообще забили. Поэтому не могу сказать, что
ignore-topk лучше чем, например, Child-Tuning или EWC, но выглядит прикольно, я его точно попробую 🤷♂️Статья
👍80🔥20👀13❤7🤔4
This media is not supported in your browser
VIEW IN TELEGRAM
RL не развивает потенциал рассуждений LLM (by Tsinghua)
RL с верифицируемыми наградами (RLVR) — один из самых популярных подходов для прокачки reasoning-способностей современных LLM, вроде OpenAI-o1 и DeepSeek-R1. Считается, что RLVR позволяет модели самой находить новые паттерны рассуждений, отсутствующие в базовой версии.
Но авторы новой статьи из Tsinghua и SJTU решили это перепроверить и получили крайне неожиданный результат: RLVR НЕ создаёт новые стратегии рассуждений.
Когда мало сэмплов (pass@1), то да, RL версии обгоняют base модели. Но если взять pass@128 или pass@256 (много попыток), то уже наоборот, базовые версии стабильно оказываются ЛУЧШЕ, причём существенно!
Причина: RL не создаёт новые паттерны, а лишь усиливает вероятность уже известных решений из базовой модели. При этом резко падает энтропия, а значит, сужается пространство возможных решений.
Прямо противоположный эффект у дистилляции (например, Distill-R1-Qwen): дистилляция реально добавляет в модель новые стратегии рассуждений.
Авторы проверили гипотезу на огромном наборе задач (математика, программирование, визуальный reasoning), множестве моделей и RL-алгоритмов (PPO, GRPO, ReMax и др.). Везде одно и то же — базовая модель имеет больший потенциал при достаточном количестве попыток.
Похоже, что для реального роста reasoning-способностей нужно придумывать совершенно другие подходы.
Статья, GitHub
RL с верифицируемыми наградами (RLVR) — один из самых популярных подходов для прокачки reasoning-способностей современных LLM, вроде OpenAI-o1 и DeepSeek-R1. Считается, что RLVR позволяет модели самой находить новые паттерны рассуждений, отсутствующие в базовой версии.
Но авторы новой статьи из Tsinghua и SJTU решили это перепроверить и получили крайне неожиданный результат: RLVR НЕ создаёт новые стратегии рассуждений.
Когда мало сэмплов (pass@1), то да, RL версии обгоняют base модели. Но если взять pass@128 или pass@256 (много попыток), то уже наоборот, базовые версии стабильно оказываются ЛУЧШЕ, причём существенно!
Причина: RL не создаёт новые паттерны, а лишь усиливает вероятность уже известных решений из базовой модели. При этом резко падает энтропия, а значит, сужается пространство возможных решений.
Прямо противоположный эффект у дистилляции (например, Distill-R1-Qwen): дистилляция реально добавляет в модель новые стратегии рассуждений.
Авторы проверили гипотезу на огромном наборе задач (математика, программирование, визуальный reasoning), множестве моделей и RL-алгоритмов (PPO, GRPO, ReMax и др.). Везде одно и то же — базовая модель имеет больший потенциал при достаточном количестве попыток.
Похоже, что для реального роста reasoning-способностей нужно придумывать совершенно другие подходы.
Статья, GitHub
🔥81🤯39👍17🤔5😨4❤2💩2🥱2💯2
«Эксперт по устаревшим рассуждениям» — это когда твоя модель слишком хороша, чтобы называть её просто старой... Лично для меня o1-pro до сих пор лучшая 🧇
Please open Telegram to view this post
VIEW IN TELEGRAM
😁99😭9❤5💯3😨1
Forwarded from Борис опять
AI Safety стартап WhiteCircle.ai, НАШИ ребята, выкатили бенчмарк для guard-моделей CircleGuardBench и показали две собственные guard модели которые обходят ShieldGemma, PromptGuard и OpenAI moderation.
Guard модели работают модераторами для LLM: ловят джейлбрейки, атаки и нарушения правил. Раньше их тестировали либо на токсичных промптах (HarmfulQA, HarmBench), либо на джейлбрейках (AART), либо на тайминге. Каждый из этих подходов измерял какой-то аспект guard модели, но не её практическую полезность.
В новом бенчмарке авторы составили таксономию вредных запросов и смотрят: что модели блокируют, что пропускают и насколько быстро обрабатывают запросы. Интересно, что метрика комбинированная, а не просто accuracy, как обычно делается. В реальном проде false positive могут убить UX, а false negative компанию. Accuracy или даже какой-нибудь f1-score сами по себе не оценивают практическую полезность модели для работы в проде. Они показывают только качество в идеальных условиях неограниченного времени.
В CircleGuardBench авторы ввели комбинированный скор, который взвешивает несколько метрик и добавляет штрафы за время ответа и наличие ошибок.
Они так же написали прикольный пост на HF: рассказывают не только про цифры, но и про то, как дизайнили и собирали бенчмарк. Мастрид про безопаспость LLM.
Ждём теперь бенчмарк для атакующих моделей, которые взламывают guard-модели, которые защищают базовые модели.
- Блог на huggingface
- Тред в X
- Лидерборд
- Код на github(нормальный код!!!)
Guard модели работают модераторами для LLM: ловят джейлбрейки, атаки и нарушения правил. Раньше их тестировали либо на токсичных промптах (HarmfulQA, HarmBench), либо на джейлбрейках (AART), либо на тайминге. Каждый из этих подходов измерял какой-то аспект guard модели, но не её практическую полезность.
В новом бенчмарке авторы составили таксономию вредных запросов и смотрят: что модели блокируют, что пропускают и насколько быстро обрабатывают запросы. Интересно, что метрика комбинированная, а не просто accuracy, как обычно делается. В реальном проде false positive могут убить UX, а false negative компанию. Accuracy или даже какой-нибудь f1-score сами по себе не оценивают практическую полезность модели для работы в проде. Они показывают только качество в идеальных условиях неограниченного времени.
В CircleGuardBench авторы ввели комбинированный скор, который взвешивает несколько метрик и добавляет штрафы за время ответа и наличие ошибок.
Они так же написали прикольный пост на HF: рассказывают не только про цифры, но и про то, как дизайнили и собирали бенчмарк. Мастрид про безопаспость LLM.
Ждём теперь бенчмарк для атакующих моделей, которые взламывают guard-модели, которые защищают базовые модели.
- Блог на huggingface
- Тред в X
- Лидерборд
- Код на github
🔥36👍21❤7💩4👎3😁2😢2
Ура! Не ожидал, что Опус тоже представят. Я уже и забыл, что эта версия Клода существует 😅
https://www.anthropic.com/news/claude-4
https://www.anthropic.com/news/claude-4
Anthropic
Introducing Claude 4
Discover Claude 4's breakthrough AI capabilities. Experience more reliable, interpretable assistance for complex tasks across work and learning.
🔥29⚡9😁4💩1
Soft Thinking: reasoning через усреднённые токены
Если на каждом шаге подавать в LLM не эмбеддинг отдельного токена, а взвешенную сумму топ-10 токенов по вероятностному распределению из выхода модели, то reasoning стабильно улучшается. Никакого обучения и изменений архитектуры: просто на инференсе вместо жёсткого выбора делаем soft-агрегацию.
Единственная сложность — модель может зациклиться. Чтобы этого избежать, авторы просто смотрят на энтропию распределения: как только она падает ниже порога (модель уверена в ответе) — сразу стопаем soft thinking и переходим к финальному ответу.
В результате на всех бенчмарках (MATH, AIME, GSM8K, GPQA Diamond, MBPP, LiveCodeBench) стабильно плюс пару процентов к pass@1 и до 20% сокращения длины reasoning цепочки. При этом, если на каждом шаге брать топ-1 токен, то текст получается абсолютно читабельный, как у обычного CoT.
Я в лёгком шоке, что такая элементарная штука реально работает и не валит модель в генерацию мусора. По сути, это что-то вроде COCONUT, только без обучения.
Статья, GitHub
Если на каждом шаге подавать в LLM не эмбеддинг отдельного токена, а взвешенную сумму топ-10 токенов по вероятностному распределению из выхода модели, то reasoning стабильно улучшается. Никакого обучения и изменений архитектуры: просто на инференсе вместо жёсткого выбора делаем soft-агрегацию.
Единственная сложность — модель может зациклиться. Чтобы этого избежать, авторы просто смотрят на энтропию распределения: как только она падает ниже порога (модель уверена в ответе) — сразу стопаем soft thinking и переходим к финальному ответу.
В результате на всех бенчмарках (MATH, AIME, GSM8K, GPQA Diamond, MBPP, LiveCodeBench) стабильно плюс пару процентов к pass@1 и до 20% сокращения длины reasoning цепочки. При этом, если на каждом шаге брать топ-1 токен, то текст получается абсолютно читабельный, как у обычного CoT.
Я в лёгком шоке, что такая элементарная штука реально работает и не валит модель в генерацию мусора. По сути, это что-то вроде COCONUT, только без обучения.
Статья, GitHub
🔥116👍25❤11🤔4
Как глубина LLM связана с максимально разрешимой алгоритмической сложностью?
Придумал я, казалось бы, гениальную идею для новой научной работы, быстренько закодил за выходные, увидел офигенные результаты, подтверждающие мою гипотезу — и только после этого додумался спросить у Deep Research, не дебил ли я.
Итак, представляю вам разбор статьи «Transformers, parallel computation, and logarithmic depth», вышедшей год назад🤬
Основная фишка статьи — задача chasing pointer. Суть простая: у вас есть цепочка индексов (целых чисел), где каждый индекс ведёт на другой элемент (индекс \ указатель) в последовательности. Задача модели — пройти назад по этим указателям и найти элемент массива на k прыжков назад за один forward pass.
Авторы строго показывают, что глубина трансформера критически важна и определяет максимально возможное число таких прыжков (сложность задачи), которое модель способна эффективно решить. Причём связь эта экспоненциальная: трансформеру с глубиной L доступно O(2^L) прыжков за один шаг.
Проще говоря: никакое увеличение ширины, количества голов внимания или MOE экспертов не заменит глубину. Тут речь именно про внутренние, архитектурные вычисления, а не Chain-of-Thought, то есть мы требуем чтобы модель выдала ответ сразу, без рассуждений.
P.S. Кстати, я потестил Claude-4 и ChatGPT-4.1 \ 4.5 — у всех предел наступает примерно на 25 прыжках, значит ли это, что их эффективная глубина всего 5 слоёв? 😄 (но на самом деле это потому, что их не обучали на эту задачу)
Статья
Придумал я, казалось бы, гениальную идею для новой научной работы, быстренько закодил за выходные, увидел офигенные результаты, подтверждающие мою гипотезу — и только после этого додумался спросить у Deep Research, не дебил ли я.
Итак, представляю вам разбор статьи «Transformers, parallel computation, and logarithmic depth», вышедшей год назад
Основная фишка статьи — задача chasing pointer. Суть простая: у вас есть цепочка индексов (целых чисел), где каждый индекс ведёт на другой элемент (индекс \ указатель) в последовательности. Задача модели — пройти назад по этим указателям и найти элемент массива на k прыжков назад за один forward pass.
Авторы строго показывают, что глубина трансформера критически важна и определяет максимально возможное число таких прыжков (сложность задачи), которое модель способна эффективно решить. Причём связь эта экспоненциальная: трансформеру с глубиной L доступно O(2^L) прыжков за один шаг.
Проще говоря: никакое увеличение ширины, количества голов внимания или MOE экспертов не заменит глубину. Тут речь именно про внутренние, архитектурные вычисления, а не Chain-of-Thought, то есть мы требуем чтобы модель выдала ответ сразу, без рассуждений.
P.S. Кстати, я потестил Claude-4 и ChatGPT-4.1 \ 4.5 — у всех предел наступает примерно на 25 прыжках, значит ли это, что их эффективная глубина всего 5 слоёв? 😄 (но на самом деле это потому, что их не обучали на эту задачу)
Статья
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥79😁18❤12👍10🤔4😭3
Forwarded from Data Secrets
How much do language models memorize? Новое исследование от Meta FAIR, Google DeepMind и NVIDIA
Задумывались когда-нибудь, сколько данных может запомнить модель с определенным количеством параметров? А сколько конкретно информации может выучить один параметр? А сколько информации он может обобщить?
Кажется, что посчитать это очень сложно или даже невозможно, но вот у ученых из этой статьи получилось: каждый параметр языковой модели способен запомнить примерно 3.6 бит информации. О том, как это посчитали – ниже.
Сразу дисклеймер: до этого были и другие статьи на эту тему, но там запоминание определялось просто тем, может ли модель воспроизвести определенный кусок трейна. На самом же деле все сложнее, и в этой работе подход не такой наивный.
➖ Авторы опираются на понятия из теории информации Колмогорова и Шеннона, и четко разделяют запоминание и обобщение. Если модель воспроизвела что-либо – не значит, что она это запомнила, а не обобщила. В обратную сторону – то же самое.
➖ Количество информации, которое модель именно запомнила, считают так. Берут две модели одинаковой архитектуры и размера: одна – референсная – обучена на огромном количестве данных, вторая – испытуемая – на ограниченном датасете.
Обе модели пропускают один и тот же тренировочный фрагмент через процедуру предсказания и вычисляют вероятности каждого токена. Если вторая модель даёт более высокие вероятности (то есть «тратит» на их декодинг меньше бит, чем референсная), она экономит относительно референсной модели определённое число бит. Сумма сэкономленных бит по всем фрагментам и есть общий объём выученной информации.
Вот так и получилось число 3.6 бит/параметр.
Самое важное, что этот показатель дает возможность четко определить момент перехода запоминания в обобщение: он происходит, когда объём данных в битах примерно равен общей ёмкости модели. И да, экспериментально это сходится: как раз на этом объеме данных тестовый лосс начинает резко падать. Это, кстати, часто называют грокингом.
Красота, как она есть arxiv.org/abs/2505.24832
Задумывались когда-нибудь, сколько данных может запомнить модель с определенным количеством параметров? А сколько конкретно информации может выучить один параметр? А сколько информации он может обобщить?
Кажется, что посчитать это очень сложно или даже невозможно, но вот у ученых из этой статьи получилось: каждый параметр языковой модели способен запомнить примерно 3.6 бит информации. О том, как это посчитали – ниже.
Сразу дисклеймер: до этого были и другие статьи на эту тему, но там запоминание определялось просто тем, может ли модель воспроизвести определенный кусок трейна. На самом же деле все сложнее, и в этой работе подход не такой наивный.
Обе модели пропускают один и тот же тренировочный фрагмент через процедуру предсказания и вычисляют вероятности каждого токена. Если вторая модель даёт более высокие вероятности (то есть «тратит» на их декодинг меньше бит, чем референсная), она экономит относительно референсной модели определённое число бит. Сумма сэкономленных бит по всем фрагментам и есть общий объём выученной информации.
Вот так и получилось число 3.6 бит/параметр.
Самое важное, что этот показатель дает возможность четко определить момент перехода запоминания в обобщение: он происходит, когда объём данных в битах примерно равен общей ёмкости модели. И да, экспериментально это сходится: как раз на этом объеме данных тестовый лосс начинает резко падать. Это, кстати, часто называют грокингом.
Красота, как она есть arxiv.org/abs/2505.24832
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥74👍46🤔11❤7👎2👏1
Skip a Layer or Loop it? Test-Time Depth Adaptation of Pretrained LLMs
В этой статье показывают, что заставлять LLM проходить через все слои подряд — фундаментально неэффективно. Авторы предложили метод CoLa, который динамически подбирает для каждого запроса свою архитектуру, пропуская (skip) или повторяя (loop) слои без (!) дообучения.
Важный нюанс: оптимальную "цепочку слоев" искали медленным Monte Carlo Tree Search поиском (~200 инференсов), который "подглядывал" в правильные ответы из датасета. И хотя авторы утверждают, что это не случайный эффект, и даже показывают некоторые паттерны (например, средние слои почти всегда пропускаются), у меня всё равно остаётся скепсис — не эквивалентно ли это простому перебору "удачных" random
Как бы то ни было, вот что они получили:
- Для >60% неверных ответов нашлась исправляющая архитектура.
- Для >75% верных ответов нашлась более короткая и эффективная.
- Точность на математике (DART) для LLaMA-8B выросла с 12.4% до 47.8%.
Следующий логичный шаг — обучить легковесную модель-"диспетчер", которая будет быстро предсказывать оптимальный путь уже без подглядывания в ответы.
Статья
В этой статье показывают, что заставлять LLM проходить через все слои подряд — фундаментально неэффективно. Авторы предложили метод CoLa, который динамически подбирает для каждого запроса свою архитектуру, пропуская (skip) или повторяя (loop) слои без (!) дообучения.
Важный нюанс: оптимальную "цепочку слоев" искали медленным Monte Carlo Tree Search поиском (~200 инференсов), который "подглядывал" в правильные ответы из датасета. И хотя авторы утверждают, что это не случайный эффект, и даже показывают некоторые паттерны (например, средние слои почти всегда пропускаются), у меня всё равно остаётся скепсис — не эквивалентно ли это простому перебору "удачных" random
seed-ов, которые меняют вычислительный граф?Как бы то ни было, вот что они получили:
- Для >60% неверных ответов нашлась исправляющая архитектура.
- Для >75% верных ответов нашлась более короткая и эффективная.
- Точность на математике (DART) для LLaMA-8B выросла с 12.4% до 47.8%.
Следующий логичный шаг — обучить легковесную модель-"диспетчер", которая будет быстро предсказывать оптимальный путь уже без подглядывания в ответы.
Статья
🔥47👍24🤔11🤯3❤2👎2💩1
Двоеточие взламывает reward-модель на базе GPT-4o
LLM, которые используются для оценки качества других моделей (reward models), оказались на удивление легковерными: они готовы дать положительную награду за совершенно пустые ответы, если те содержат "правильные" ключевые слова.
Например ответ "Thought process:" или "Solution" — часто засчитывается как верный. Иногда достаточно даже одного символа, например, двоеточия «:»!
FPR (доля ложно-правильных ответов) для LLaMA3-70B и Qwen2.5-72B на таких фразах доходит до 80-90%, а у GPT-4o на некоторых атаках превышает 30%.
В итоге модель, которую так обучают, просто перестает решать задачу и начинает спамить этими фразами. Классический reward hacking.
Статья, Huggingface
LLM, которые используются для оценки качества других моделей (reward models), оказались на удивление легковерными: они готовы дать положительную награду за совершенно пустые ответы, если те содержат "правильные" ключевые слова.
Например ответ "Thought process:" или "Solution" — часто засчитывается как верный. Иногда достаточно даже одного символа, например, двоеточия «:»!
FPR (доля ложно-правильных ответов) для LLaMA3-70B и Qwen2.5-72B на таких фразах доходит до 80-90%, а у GPT-4o на некоторых атаках превышает 30%.
В итоге модель, которую так обучают, просто перестает решать задачу и начинает спамить этими фразами. Классический reward hacking.
Статья, Huggingface
😁90🔥19👍9😱4
SONAR-LLM: языковая модель, которая думает предложениями, а не токенами
Опубликовали препринт новой работы! Помните Large Concept Model (LCM) от Meta, которая генерирует текст через предсказание sentence-level эмбеддингов? Крутая идея, но диффузионное обучение там было весьма геморройным, а MSE лосс работал так себе.
Мы решили оставить "мышление" в пространстве SONAR эмбеддингов (это такой мощный автоэнкодер от Meta, который сжимает целое предложение в один вектор d=1024 и умеет почти без потерь восстанавливать его обратно), но вернуть привычный token-level cross-entropy через замороженный декодер. По сути, модель предсказывает эмбеддинг следующего предложения, прогоняет его через замороженный SONAR декодер, и получает градиенты от обычной кроссэнтропии по токенам.
Такой гибридный подход избавляет от диффузионного семплера LCM, но сохраняет семантическую абстракцию. На практике SONAR-LLM показал лучшие scaling laws, чем оригинальные LCM, и заметно обогнал их в качестве генерации по базовым метрикам — от оценки через оракулов, до NLG бенчмарков и суммаризации.
Про инференс: выигрыш приходит на длинных контекстах. До ~4k токенов обычные архитектуры выигрывают, а дальше SONAR-LLM устойчиво впереди, потому что моделирует цепочку предложений, а не токенов. Сложность по FLOPs близка к линейной вплоть до ~1M.
Все веса, код и скрипты для воспроизведения выложили в открытый доступ.
Статья, GitHub, хабр
Опубликовали препринт новой работы! Помните Large Concept Model (LCM) от Meta, которая генерирует текст через предсказание sentence-level эмбеддингов? Крутая идея, но диффузионное обучение там было весьма геморройным, а MSE лосс работал так себе.
Мы решили оставить "мышление" в пространстве SONAR эмбеддингов (это такой мощный автоэнкодер от Meta, который сжимает целое предложение в один вектор d=1024 и умеет почти без потерь восстанавливать его обратно), но вернуть привычный token-level cross-entropy через замороженный декодер. По сути, модель предсказывает эмбеддинг следующего предложения, прогоняет его через замороженный SONAR декодер, и получает градиенты от обычной кроссэнтропии по токенам.
Такой гибридный подход избавляет от диффузионного семплера LCM, но сохраняет семантическую абстракцию. На практике SONAR-LLM показал лучшие scaling laws, чем оригинальные LCM, и заметно обогнал их в качестве генерации по базовым метрикам — от оценки через оракулов, до NLG бенчмарков и суммаризации.
Про инференс: выигрыш приходит на длинных контекстах. До ~4k токенов обычные архитектуры выигрывают, а дальше SONAR-LLM устойчиво впереди, потому что моделирует цепочку предложений, а не токенов. Сложность по FLOPs близка к линейной вплоть до ~1M.
Все веса, код и скрипты для воспроизведения выложили в открытый доступ.
Статья, GitHub, хабр
👍81🔥51❤15⚡1👀1
Dynamic Fine-Tuning
Вот всё-таки есть что-то такое особенное в RL для LLM, чего нет в SFT... модели ну не хотят правильно обобщаться без меморизации редких примеров или деградации на других доменах. Недавно вышло несколько работ, которые показывают, что SFT, на самом деле, это тот же RL, просто с оооочень кривым reward (раз, два). Если коротко, то дело в кросс-энтропии на последовательности токенов. Ведь токены с малой вероятностью вносят непропорционально большой вклад в лосс и неприятно большую дисперсию при SFT.
В статье "On the Generalization of SFT" опять математически вывели SFT как частный случай кривого RL и предложили ну мега простой способ это починить в одну строчку кода. Надо взвесить токенный CE-лосс на вероятность каждого токена, и всё становится прям хорошо.
Назвали эту поправку "reward rectification" или "Dynamic Fine-Tuning" (DFT). Авторы получили большой буст на fine-tuning бенчмарках по сравнению с обычным SFT, а кое-где оно обходит даже GRPO и PPO, причём на очень широком наборе гиперпараметров.
На всякий случай ещё раз подчеркну, DFT — это чистый SFT режим, то есть тут не нужны reward/reference модели, пары примеров, разметка и т.п. Достаточно только позитивных SFT примеров. Кажется это обязательно надо пойти попробовать.
Статья, GitHub
Вот всё-таки есть что-то такое особенное в RL для LLM, чего нет в SFT... модели ну не хотят правильно обобщаться без меморизации редких примеров или деградации на других доменах. Недавно вышло несколько работ, которые показывают, что SFT, на самом деле, это тот же RL, просто с оооочень кривым reward (раз, два). Если коротко, то дело в кросс-энтропии на последовательности токенов. Ведь токены с малой вероятностью вносят непропорционально большой вклад в лосс и неприятно большую дисперсию при SFT.
В статье "On the Generalization of SFT" опять математически вывели SFT как частный случай кривого RL и предложили ну мега простой способ это починить в одну строчку кода. Надо взвесить токенный CE-лосс на вероятность каждого токена, и всё становится прям хорошо.
Назвали эту поправку "reward rectification" или "Dynamic Fine-Tuning" (DFT). Авторы получили большой буст на fine-tuning бенчмарках по сравнению с обычным SFT, а кое-где оно обходит даже GRPO и PPO, причём на очень широком наборе гиперпараметров.
На всякий случай ещё раз подчеркну, DFT — это чистый SFT режим, то есть тут не нужны reward/reference модели, пары примеров, разметка и т.п. Достаточно только позитивных SFT примеров. Кажется это обязательно надо пойти попробовать.
Статья, GitHub
👍85🔥37❤16🤯3👀1
Gradient Accumulation Is Wasteful
Миф: чем больше батчайз, тем стабильнее и лучше учится LLM. На самом деле всё не так. Авторы этой статьи провели мега-аблейшн по гиперпараметрам претрейна LLM и обнаружили: чем МЕНЬШЕ batch size, тем ШИРЕ диапазон гиперпараметров (lr, оптимизатор, decay-рейты), на которых модель нормально учится. Короче, на маленьком batch даже ванильный SGD (без momentum!) не уступает Adam-у и Adafactor. Валидационный лосс при этом не хуже, а иногда даже лучше, чем на больших batch size.
Самое интересное — авторы показывают, что главная проблема с малельниким батчами — это не какая-то “нестабильность”, а просто неправильно настроенные беты. Особенно β₂ у Adam: его надо менять для разных батчсайзов, фиксируя полупериод затухания второго момента в токенах (по их формуле
Итого: минимальный batch size, при котором не теряется пропускная способность железа — обычно лучший выбор. На малых batch всё проще с тюнингом (широкий диапазон lr/decay/optimizer). И не нужно бояться batch size 1! Gradient accumulation — это почти всегда зло.
PS. Работает не только для претрейна, но и файнтюнинга.
Статья, GitHub
Миф: чем больше батчайз, тем стабильнее и лучше учится LLM. На самом деле всё не так. Авторы этой статьи провели мега-аблейшн по гиперпараметрам претрейна LLM и обнаружили: чем МЕНЬШЕ batch size, тем ШИРЕ диапазон гиперпараметров (lr, оптимизатор, decay-рейты), на которых модель нормально учится. Короче, на маленьком batch даже ванильный SGD (без momentum!) не уступает Adam-у и Adafactor. Валидационный лосс при этом не хуже, а иногда даже лучше, чем на больших batch size.
Самое интересное — авторы показывают, что главная проблема с малельниким батчами — это не какая-то “нестабильность”, а просто неправильно настроенные беты. Особенно β₂ у Adam: его надо менять для разных батчсайзов, фиксируя полупериод затухания второго момента в токенах (по их формуле
β₂ new = β₂^(bs_new / bs), тогда можно обучать LLM вообще на batch size 1 — и всё будет стабильно.Итого: минимальный batch size, при котором не теряется пропускная способность железа — обычно лучший выбор. На малых batch всё проще с тюнингом (широкий диапазон lr/decay/optimizer). И не нужно бояться batch size 1! Gradient accumulation — это почти всегда зло.
PS. Работает не только для претрейна, но и файнтюнинга.
Статья, GitHub
🤯117👍51🔥25🤔11❤6👀3👏1
Pre-training under infinite compute (by Stanford)
Пару дней назад вышла статья с таким вот пугающим названием. Разве у кого-то есть бесконечный компьют? Но смысл там в другом.
Вычисления растут примерно в 4 раза каждый год, а текстовых данных становится только на 3% больше. Как тренировать модели когда GPU избыток, а весь текст в интернете закончился? С одной стороны можно генерить синтетику, но у этого свои сложности. С другой стороны можно попытаться решить проблему с архитектурной точки зрения, чем и занялись авторы, придумав два костыля:
1. Регуляризация. Если в лоб увеличивать число эпох или параметры модели при фиксированных данных, модель начинает переобучаться. Выход — радикально повысить weight decay. Рекомендуется в 30 (!) раз выше стандартного: примерно 3.2 вместо типичного 0.1.
2. Горизонтальное масштабирование. Нужно не увеличивать размер одной модели, а обучать несколько маленьких и усреднять их логиты, асимптотически это выходит сильно выгоднее.
В общем, когда наступит эра дефицита данных (а она уже наступает), вспомните этот пейпер.
Статья
Пару дней назад вышла статья с таким вот пугающим названием. Разве у кого-то есть бесконечный компьют? Но смысл там в другом.
Вычисления растут примерно в 4 раза каждый год, а текстовых данных становится только на 3% больше. Как тренировать модели когда GPU избыток, а весь текст в интернете закончился? С одной стороны можно генерить синтетику, но у этого свои сложности. С другой стороны можно попытаться решить проблему с архитектурной точки зрения, чем и занялись авторы, придумав два костыля:
1. Регуляризация. Если в лоб увеличивать число эпох или параметры модели при фиксированных данных, модель начинает переобучаться. Выход — радикально повысить weight decay. Рекомендуется в 30 (!) раз выше стандартного: примерно 3.2 вместо типичного 0.1.
2. Горизонтальное масштабирование. Нужно не увеличивать размер одной модели, а обучать несколько маленьких и усреднять их логиты, асимптотически это выходит сильно выгоднее.
В общем, когда наступит эра дефицита данных (а она уже наступает), вспомните этот пейпер.
Статья
👍71🤔25❤8🔥4😨2
SIM-CoT: впервые латентный ризонинг догнал явный CoT
Помните COCONUT от Meta? Там LLM учили рассуждать не словами, а эмбеддингами. Звучит круто, но была одна гадкая проблема — при увеличении количества неявных токенов модель начинала нестабильно обучаться и иногда полностью коллапсировала. Представьте: добавили пятый латентный токен, а точность упала с 89% до 12%! Да и нормальные результаты были только на игрушечных моделях вроде GPT-2.
Авторы SIM-CoT разобрались, в чём дело. Оказалось, что неявные токены теряют семантическое разнообразие и становятся слишком похожими друг на друга, постепенно все латенты начинают кодировать одно и то же. Классический коллапс пространства эмбеддингов.
Решение — добавить step-level supervision. Во время обучения каждый неявный токен выравнивается со своим конкретным шагом рассуждения. Отдельная модель-декодер (архитектурно идентичная основной LLM), учится превращать каждый латентный токен обратно в текстовый шаг через кросс-энтропию. Этот декодер работает только при обучении, а на инференсе выкидывается — благодаря этому никаких потерь в скорости.
И это работает! На GPT-2 SIM-CoT впервые обошел явный CoT при скорости в 2.3 раза выше. На больших моделях (LLaMA-3.1 8B) метод догоняет явный CoT, сохраняя преимущество в эффективности. Плюс бонус — auxiliary decoder позволяет "подсматривать" во внутренние размышления модели для дебага.
Но на больших моделях SIM-CoT скорее закрывает разрыв с явным рассуждением, чем кардинально его превосходит. Но сам подход решения нестабильности неявного CoT через пошаговый supervision выглядит очень разумно. В целом я очень верю в это направление COCONUT-like архитектур.
Статья, GitHub
Помните COCONUT от Meta? Там LLM учили рассуждать не словами, а эмбеддингами. Звучит круто, но была одна гадкая проблема — при увеличении количества неявных токенов модель начинала нестабильно обучаться и иногда полностью коллапсировала. Представьте: добавили пятый латентный токен, а точность упала с 89% до 12%! Да и нормальные результаты были только на игрушечных моделях вроде GPT-2.
Авторы SIM-CoT разобрались, в чём дело. Оказалось, что неявные токены теряют семантическое разнообразие и становятся слишком похожими друг на друга, постепенно все латенты начинают кодировать одно и то же. Классический коллапс пространства эмбеддингов.
Решение — добавить step-level supervision. Во время обучения каждый неявный токен выравнивается со своим конкретным шагом рассуждения. Отдельная модель-декодер (архитектурно идентичная основной LLM), учится превращать каждый латентный токен обратно в текстовый шаг через кросс-энтропию. Этот декодер работает только при обучении, а на инференсе выкидывается — благодаря этому никаких потерь в скорости.
И это работает! На GPT-2 SIM-CoT впервые обошел явный CoT при скорости в 2.3 раза выше. На больших моделях (LLaMA-3.1 8B) метод догоняет явный CoT, сохраняя преимущество в эффективности. Плюс бонус — auxiliary decoder позволяет "подсматривать" во внутренние размышления модели для дебага.
Но на больших моделях SIM-CoT скорее закрывает разрыв с явным рассуждением, чем кардинально его превосходит. Но сам подход решения нестабильности неявного CoT через пошаговый supervision выглядит очень разумно. В целом я очень верю в это направление COCONUT-like архитектур.
Статья, GitHub
🔥60👍30🤔5❤4👎1😢1