Forwarded from Душный NLP
В Вене проходит 63-я ежегодная конференция ассоциации компьютерной лингвистики — ACL 2025
А мы как всегда следим 👀 и делимся с вами самым интересным. Мы уже публиковали занимательную статистику c конференции в канале ML Underhood (кстати, подписывайтесь!), а теперь настало время поговорить о статьях.
Конференцию открыл часовой кейноут Люка Зеттлемойера, профессора Paul G. Allen School of Computer Science & Engineering в Университете Вашингтона, старшего научного руководителя Meta* и президента ACL. Он рассказал о том, как стандартный пайплайн обучения LLM: токенизация, претрейн и элаймент, несмотря на невероятный успех, почти наверняка имеет множество возможностей улучшения, которые мы упускаем. Доклад был построен вокруг трех векторов исследования:
— повышения эффективности обработки данных после обучения;
— новых методов извлечения большего количества сигналов из данных претрейна, включая новые иерархические архитектуры для языковых моделей байтового уровня (BLT), которые не требуют использования токенизаторов и масштабируются лучше, чем традиционные методы на основе BPE;
— одного из подходов к MoE — FlexOLMo.
Все три темы были интересными! А вот ещё н несколько докладов, которые отметили яндексоиды:
Human-LLM Coevolution: Evidence from Academic Writing
Довольно ожидаемо авторы утверждают, что с появлением Chat GPT частотность употребления некоторых слов в научных статьях резко изменилась. Затем исследователи делают ещё один шажок и говорят, что это не обязательно означает, что LLM пишут статьи. Скорее мы наблюдаем, как люди, много взаимодействующие с LLM, оказываются под их влиянием и изменяют свои паттерны словоупотребления.
From Words to Worlds: NLP for Game Creation and Interaction
Индустриальный рассказ об Epic Games об использовании LLM для NPC в играх. Пользователь, играя, может задать произвольный вопрос и персонаж будет отвечать (естественно, со своим характером и т. п.). Это выглядит здорово и меняет опыт взаимодействия с игровым миром. Решение внедрили в Fortnite пару месяцев назад, она работает поверх чужих API и позволяет поговорить с Дартом Вейдером. Также они делают свой code completion и анимацию персонажей с помощью AI.
Understanding Impact of Human Feedback via Influence Functions
Исследователи оценили влияние фидбека человека, введя понятие функции влияния, и пришли к выводам, что это влияние превосходит показатели базовой LLM. Ещё более сильным негативным влиянием обладает ошибочный фидбек. Авторы разработали подход, который позволяет это детектировать и, следовательно, убирать или исправлять.
* Компания Meta признана экстремистской организацией в России.
Наблюдениями делились❣ Алексей Березникер и Александр Николайчик
#YaACL25
Душный NLP
А мы как всегда следим 👀 и делимся с вами самым интересным. Мы уже публиковали занимательную статистику c конференции в канале ML Underhood (кстати, подписывайтесь!), а теперь настало время поговорить о статьях.
Конференцию открыл часовой кейноут Люка Зеттлемойера, профессора Paul G. Allen School of Computer Science & Engineering в Университете Вашингтона, старшего научного руководителя Meta* и президента ACL. Он рассказал о том, как стандартный пайплайн обучения LLM: токенизация, претрейн и элаймент, несмотря на невероятный успех, почти наверняка имеет множество возможностей улучшения, которые мы упускаем. Доклад был построен вокруг трех векторов исследования:
— повышения эффективности обработки данных после обучения;
— новых методов извлечения большего количества сигналов из данных претрейна, включая новые иерархические архитектуры для языковых моделей байтового уровня (BLT), которые не требуют использования токенизаторов и масштабируются лучше, чем традиционные методы на основе BPE;
— одного из подходов к MoE — FlexOLMo.
Все три темы были интересными! А вот ещё н несколько докладов, которые отметили яндексоиды:
Human-LLM Coevolution: Evidence from Academic Writing
Довольно ожидаемо авторы утверждают, что с появлением Chat GPT частотность употребления некоторых слов в научных статьях резко изменилась. Затем исследователи делают ещё один шажок и говорят, что это не обязательно означает, что LLM пишут статьи. Скорее мы наблюдаем, как люди, много взаимодействующие с LLM, оказываются под их влиянием и изменяют свои паттерны словоупотребления.
From Words to Worlds: NLP for Game Creation and Interaction
Индустриальный рассказ об Epic Games об использовании LLM для NPC в играх. Пользователь, играя, может задать произвольный вопрос и персонаж будет отвечать (естественно, со своим характером и т. п.). Это выглядит здорово и меняет опыт взаимодействия с игровым миром. Решение внедрили в Fortnite пару месяцев назад, она работает поверх чужих API и позволяет поговорить с Дартом Вейдером. Также они делают свой code completion и анимацию персонажей с помощью AI.
Understanding Impact of Human Feedback via Influence Functions
Исследователи оценили влияние фидбека человека, введя понятие функции влияния, и пришли к выводам, что это влияние превосходит показатели базовой LLM. Ещё более сильным негативным влиянием обладает ошибочный фидбек. Авторы разработали подход, который позволяет это детектировать и, следовательно, убирать или исправлять.
* Компания Meta признана экстремистской организацией в России.
Наблюдениями делились
#YaACL25
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from BOGDANISSSIMO
При разработке приложения я нахожу удобным визуализировать карту приложения, которая является одновременно и todo-листом (буквально):
колонки - фичи, примерно в порядке онбординга / user journey / логики экранов в меню внизу
строки - слои приложения, от того что пользователь видит (UI), логики (UX) - и до сети, бекенда, LLM штук
Будучи фуллстеком, мне удобнее не закапываться в отдельные части, а работать вертикально, *вдоль*. Взял какую-то фичу, и прогрызаешь всю её имплементацию (часто начинаю с того, что видит пользователь, с UI и потом UX)
Мне лично так сразу понятно, что сделано, что от чего зависит, куда дальше продвинуть экспансию "области того, что уже сделано", какой следующий самый важный кусок приложения
Намного легче ориентироваться в приоритетах и объеме работы, чем безликие текстовые буллеты в каком-либо таск-трекере. В принципе, фреймворк подходит и для любых web-сервисов
А как вы декомпозируете новые проекты?
колонки - фичи, примерно в порядке онбординга / user journey / логики экранов в меню внизу
строки - слои приложения, от того что пользователь видит (UI), логики (UX) - и до сети, бекенда, LLM штук
Будучи фуллстеком, мне удобнее не закапываться в отдельные части, а работать вертикально, *вдоль*. Взял какую-то фичу, и прогрызаешь всю её имплементацию (часто начинаю с того, что видит пользователь, с UI и потом UX)
Мне лично так сразу понятно, что сделано, что от чего зависит, куда дальше продвинуть экспансию "области того, что уже сделано", какой следующий самый важный кусок приложения
Намного легче ориентироваться в приоритетах и объеме работы, чем безликие текстовые буллеты в каком-либо таск-трекере. В принципе, фреймворк подходит и для любых web-сервисов
А как вы декомпозируете новые проекты?
Forwarded from BOGDANISSSIMO
1/2. Как не терять фокус, когда много проектов?
Буду потихоньку нарезать вебинар на посты
Поступил вопрос "как не терять фокус и не распыляться, если много проектов?". У меня на пике было 4 проекта (основная работа, книга, 2 курса). Сейчас у меня проектов, требующих моего внимания тоже больше одного (мы не берём в расчёт консультации). Чтобы за всем успевать, я тогда и сейчас распределяю проекты по дням недели, кажется, это называется Day Theming.
Идея в чём: когда ты Maker, т.е. работаешь руками (разработчик, дизайнер, контент-creator), ты продуктивен, когда у тебя есть большое количество часов (4-6 подряд или больше), во время которых ты можешь заниматься одной задачей, погрузиться в нирвану Deep Work✨. Тебе важно не отвлекаться, иметь один контекст. Тебе клёво видеть в календаре пустой день или половину дня – ты можешь заняться своим делом и сделать его хорошо
Когда ты Manager, ты по-другому смотришь на свой календарь. Тебе ок созваниваться, переключаться между десятью контекстами. Каждые незаполненные полчасика в календаре для тебя впустую потраченное время. Для Maker наоборот, свободные полчаса-час-два – это настолько мало для того, чтобы что-то сделать полезное, что за важные задачи лучше и не браться, максимум, пофиксить баги, почитать статьи
Подробнее про Maker Schedule vs Manager Schedule в знаменитом эссе Пола Грэма, также есть классный видос от Алекса Хормози If You Struggle with Focus, Try My Productivity System с более бизнесовым пересказом Пола Грэма
Я инженер, поэтому мой контрибьюшн – почти всегда через deep work. Мне важно иметь Maker Schedule, когда есть большие куски времени без отвлечений. Если у меня больше одного проекта, которые конкурируют за мое внимание каждый день, каждый час, мне нужно придумать, как предотвратить context switching, переключение контекста
Буду потихоньку нарезать вебинар на посты
Поступил вопрос "как не терять фокус и не распыляться, если много проектов?". У меня на пике было 4 проекта (основная работа, книга, 2 курса). Сейчас у меня проектов, требующих моего внимания тоже больше одного (мы не берём в расчёт консультации). Чтобы за всем успевать, я тогда и сейчас распределяю проекты по дням недели, кажется, это называется Day Theming.
Идея в чём: когда ты Maker, т.е. работаешь руками (разработчик, дизайнер, контент-creator), ты продуктивен, когда у тебя есть большое количество часов (4-6 подряд или больше), во время которых ты можешь заниматься одной задачей, погрузиться в нирвану Deep Work✨. Тебе важно не отвлекаться, иметь один контекст. Тебе клёво видеть в календаре пустой день или половину дня – ты можешь заняться своим делом и сделать его хорошо
Когда ты Manager, ты по-другому смотришь на свой календарь. Тебе ок созваниваться, переключаться между десятью контекстами. Каждые незаполненные полчасика в календаре для тебя впустую потраченное время. Для Maker наоборот, свободные полчаса-час-два – это настолько мало для того, чтобы что-то сделать полезное, что за важные задачи лучше и не браться, максимум, пофиксить баги, почитать статьи
Подробнее про Maker Schedule vs Manager Schedule в знаменитом эссе Пола Грэма, также есть классный видос от Алекса Хормози If You Struggle with Focus, Try My Productivity System с более бизнесовым пересказом Пола Грэма
Я инженер, поэтому мой контрибьюшн – почти всегда через deep work. Мне важно иметь Maker Schedule, когда есть большие куски времени без отвлечений. Если у меня больше одного проекта, которые конкурируют за мое внимание каждый день, каждый час, мне нужно придумать, как предотвратить context switching, переключение контекста
Forwarded from BOGDANISSSIMO
2/2. Как не терять фокус, когда много проектов?
Решение: оба этих вводных приводят нас к логичной идее выделять целые дни под тот или иной контекст, кажется, это называется Day Theming. Я коммуницирую, мол, такие-то дни недели я занимаюсь таким-то проектом, в остальные дни по этому проекту я недоступен (максимум, могу в конце дня посмотреть, прочитать, отписаться). У меня в календарике прям заведены регулярные Full Day ивенты под каждый. Важно что это эксплицитно проговаривается, чтобы контролировать ожидания всех, с кем работаешь (например, мои последние начальники и кого я консультирую подтвердят, что все созвоны я ставлю на понедельники, чтобы все остальные дни я мог фокусироваться на deep work)
Если, когда я не занят каким-то проектом что-то ломается, случается какой-то пожар – это подождёт как минимум до конца дня, как максимум, несколько дней, пока я не вернусь обратно к этому проекту (чаще всего "пожары", если внимательно на них посмотреть, не такие критичные и срочные, какими кажутся на первый взгляд)
В крайнем случае, если это действительно необходимо, можно бить дни на пополам (4-6 часов первая половина дня на один проект, зал/обед, 4-6 часов половина дня на другой проект) или выделять 1-2 часа в начале или в конце дня на какую-то определённую активность (контент/книга/курс)
P.S. Знаю, такой стратегии придерживается Илон у которого 5+ компаний (SpaceX, Tesla, X, xAI, DOGE, Neurolink). Львиная доля времени у него выделена под SpaceX, Tesla, где пока он ими занимается, он прилетает на завод, погружается в текущие дела, находит главный боттлнек прямо сейчас и в считанные дни его решает (крайне советую посмотреть https://www.youtube.com/watch?v=FQ4wBv0w9ew), после чего он переключается на другие компании и не мешает гениальным инженерам продолжать работу
Решение: оба этих вводных приводят нас к логичной идее выделять целые дни под тот или иной контекст, кажется, это называется Day Theming. Я коммуницирую, мол, такие-то дни недели я занимаюсь таким-то проектом, в остальные дни по этому проекту я недоступен (максимум, могу в конце дня посмотреть, прочитать, отписаться). У меня в календарике прям заведены регулярные Full Day ивенты под каждый. Важно что это эксплицитно проговаривается, чтобы контролировать ожидания всех, с кем работаешь (например, мои последние начальники и кого я консультирую подтвердят, что все созвоны я ставлю на понедельники, чтобы все остальные дни я мог фокусироваться на deep work)
Если, когда я не занят каким-то проектом что-то ломается, случается какой-то пожар – это подождёт как минимум до конца дня, как максимум, несколько дней, пока я не вернусь обратно к этому проекту (чаще всего "пожары", если внимательно на них посмотреть, не такие критичные и срочные, какими кажутся на первый взгляд)
В крайнем случае, если это действительно необходимо, можно бить дни на пополам (4-6 часов первая половина дня на один проект, зал/обед, 4-6 часов половина дня на другой проект) или выделять 1-2 часа в начале или в конце дня на какую-то определённую активность (контент/книга/курс)
P.S. Знаю, такой стратегии придерживается Илон у которого 5+ компаний (SpaceX, Tesla, X, xAI, DOGE, Neurolink). Львиная доля времени у него выделена под SpaceX, Tesla, где пока он ими занимается, он прилетает на завод, погружается в текущие дела, находит главный боттлнек прямо сейчас и в считанные дни его решает (крайне советую посмотреть https://www.youtube.com/watch?v=FQ4wBv0w9ew), после чего он переключается на другие компании и не мешает гениальным инженерам продолжать работу
Forwarded from Tensor Banana
T-one STT (распознавание речи на русском) под виндой (без WSL и докера) на CPU
- размер очень маленький - 71M параметров (whisper large - 1500M), поэтому быстрый.
- по первым ощущениям, уровень ошибок на уровне whisper-large.
- но по метрикам превосходит все существующие модули распознавания речи для русского.
- по умолчанию работает на CPU и довольно быстро. Намного быстрее виспера на cpu
- на ГПУ запускать лень, надо triton-inference-server поднимать. Пишут, что для GPU нужно 8 GB vram
- не ставит знаки препинания (а виспер ставит)
- обычное голосовое сообщение умеренного качества, записанное на улице, длиной 74 секунды он распознал за 12 секунд на CPU. Работает потоково. Первая фраза появилась уже через 1 секунду. Итого: 10 ошибок, в основном, пропуск слов, которые плохо слышно, иногда неверные окончания.
Установка под виндой
(для linux или wsl - используйте официальную инструкцию)
По умолчанию демо работает на CPU. Чтобы запустить на GPU нужно ставить TensorRT и triton-inference-server. Там свои сложности, под винду есть только некоторые версии сервера. Официальная инструкция (я не тестил) https://github.com/voicekit-team/T-one/blob/main/docs/triton_inference_server.ru.md
гитхаб: https://github.com/voicekit-team/T-one
HF: https://huggingface.co/t-tech/T-one
- размер очень маленький - 71M параметров (whisper large - 1500M), поэтому быстрый.
- по первым ощущениям, уровень ошибок на уровне whisper-large.
- но по метрикам превосходит все существующие модули распознавания речи для русского.
- по умолчанию работает на CPU и довольно быстро. Намного быстрее виспера на cpu
- на ГПУ запускать лень, надо triton-inference-server поднимать. Пишут, что для GPU нужно 8 GB vram
- не ставит знаки препинания (а виспер ставит)
- обычное голосовое сообщение умеренного качества, записанное на улице, длиной 74 секунды он распознал за 12 секунд на CPU. Работает потоково. Первая фраза появилась уже через 1 секунду. Итого: 10 ошибок, в основном, пропуск слов, которые плохо слышно, иногда неверные окончания.
Установка под виндой
(для linux или wsl - используйте официальную инструкцию)
git clone https://github.com/voicekit-team/T-one.git
cd T-one
python -m venv .venv
.venv\Scripts\activate
в файле pyproject.toml удаляем или комментируем (#) строчку 16:
"kenlm (>=0.2.0,<1.0.0)",
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
bootstrap-vcpkg.sh
vcpkg integrate install
vcpkg install kenlm
cd ..
pip install poetry
poetry lock
poetry install -E demo
pip install kenlm
uvicorn --host 127.0.0.1 --port 8081 tone.demo.website:app --reload
открываем 127.0.0.1:8081 в браузере
По умолчанию демо работает на CPU. Чтобы запустить на GPU нужно ставить TensorRT и triton-inference-server. Там свои сложности, под винду есть только некоторые версии сервера. Официальная инструкция (я не тестил) https://github.com/voicekit-team/T-one/blob/main/docs/triton_inference_server.ru.md
гитхаб: https://github.com/voicekit-team/T-one
HF: https://huggingface.co/t-tech/T-one
Forwarded from Start Career in DS
👩💼 Как развить бизнес видение?
Бесспорно, для аналитиков любого грейда крайне важно помимо хард скиллов, также и бизнес видение. Не зря бигтехи проверяют и то, и другое на разных этапах собеса. Поэтому прокачивать его так же нужно, как и нарешивать литкод или задачки по терверу.
Небольшой список общих советов:
👉 Ходите на конференции, где разбираются реальные кейсы: матемаркетинг, aha!, датафест
👉 Читайте каналы по интересующей вас тематике, а еще полезно почитать разные каналы с отчетностями компаний, чтобы понять, на чем они зарабатывают и на какие метрики смотрят, например, @businessincognita и @expertosphere
👉 Читайте книги, которые развивают бизнес-видение, например, The Data Detective и How To Measure Anything. Отдельно рекомендуем "Спроси маму" Роба Фитцпатрика, она научит вас правильно задавать вопросы клиенту и понимать, что реально он хочет, а в чем вообще не заинтересован. Саммари есть на хабре, но админы читали целиком и вам советуют
А теперь подборка, если вам нужно все и сразу за короткий срок перед собесом:
🔎 Школа менеджеров Яндекса: возможность заглянуть в закулисье яндекса, построения продукта и принятия решений в нем
🔎 Платформа growth.design, на которой в формате комиксов разбираются различные продуктовые кейсы мировых топ-компаний. Узнали про нее от Макса из Заскуль Питона, оч советуем подробнее про эту крутую платформу прочитать у него.
🔎 Блог GoPractice – много классных бесплатных статей про продуктовый менеджмент, маркетинг и аналитику. А если понравится, то у них есть и платные симуляторы
🔎 Блоги компаний. Например, Авито, Яндекса, Альфа-банка. Выбирайте статьи, относящиеся к бизнес-части и прокачивайте насмотренность по принятию решений, которые влияют на то, что вы видите в своем смартфоне. Отдельно рекомендуем читать блоки компаний, куда вы планируете собеседоваться в ближайшее время. Проверенно повышает успешность прохождения собеседований, тк вы становитесь не просто аналитиком, а аналитиком, знакомым с целями, вызовами и последними решениями компаний
Ставьте лайки 👍, если было полезно, и давайте добьем каналу следующий уровень, осталось совсем немного!
Бесспорно, для аналитиков любого грейда крайне важно помимо хард скиллов, также и бизнес видение. Не зря бигтехи проверяют и то, и другое на разных этапах собеса. Поэтому прокачивать его так же нужно, как и нарешивать литкод или задачки по терверу.
Небольшой список общих советов:
👉 Ходите на конференции, где разбираются реальные кейсы: матемаркетинг, aha!, датафест
👉 Читайте каналы по интересующей вас тематике, а еще полезно почитать разные каналы с отчетностями компаний, чтобы понять, на чем они зарабатывают и на какие метрики смотрят, например, @businessincognita и @expertosphere
👉 Читайте книги, которые развивают бизнес-видение, например, The Data Detective и How To Measure Anything. Отдельно рекомендуем "Спроси маму" Роба Фитцпатрика, она научит вас правильно задавать вопросы клиенту и понимать, что реально он хочет, а в чем вообще не заинтересован. Саммари есть на хабре, но админы читали целиком и вам советуют
А теперь подборка, если вам нужно все и сразу за короткий срок перед собесом:
🔎 Школа менеджеров Яндекса: возможность заглянуть в закулисье яндекса, построения продукта и принятия решений в нем
🔎 Платформа growth.design, на которой в формате комиксов разбираются различные продуктовые кейсы мировых топ-компаний. Узнали про нее от Макса из Заскуль Питона, оч советуем подробнее про эту крутую платформу прочитать у него.
🔎 Блог GoPractice – много классных бесплатных статей про продуктовый менеджмент, маркетинг и аналитику. А если понравится, то у них есть и платные симуляторы
🔎 Блоги компаний. Например, Авито, Яндекса, Альфа-банка. Выбирайте статьи, относящиеся к бизнес-части и прокачивайте насмотренность по принятию решений, которые влияют на то, что вы видите в своем смартфоне. Отдельно рекомендуем читать блоки компаний, куда вы планируете собеседоваться в ближайшее время. Проверенно повышает успешность прохождения собеседований, тк вы становитесь не просто аналитиком, а аналитиком, знакомым с целями, вызовами и последними решениями компаний
Ставьте лайки 👍, если было полезно, и давайте добьем каналу следующий уровень, осталось совсем немного!
Forwarded from max.sh
Искал статьи / работы рисерчеров, участвовавших в разработке Deep Research и наткнулся на блог одного из ключевых авторов технологии — Джейсона Вэя (Jason Wei). Ссылка на блог. Джейсон является первым автором статьи про Chain of Thought ещё со времён работы в Google Brain (теперь часть Дип Майнда).
В блоге Джейсон интересно пишет свои мысли про рисерч, как его вести, как строить карьерный путь и немного рефлексии на тему своих же научных статей.
Из интересного про RL — Асимметрия верификации. Ссылка
Множество задач требуют значительных усилий для генерации решения, но при этом легко поддаются проверке. Взять судоку или кроссворд. А вот написание эссе на заданную тему — напротив: сгенерировать его для модели несложно, а вот провести факт-чекинг и оценить содержание гораздо труднее. В этом и заключается асимметрия верификации: есть задачи, которые можно быстро и дёшево проверить на корректность (при наличии эталонного ответа), но при этом неясно, как к этому ответу прийти; а есть такие, к которым можно сгенерировать тысячи вариантов, но трудно определить, какие из них действительно правильные.
Тут и начинается самое интересное — поиск способов уменьшения асимметрии. Для большого класса сложных задач это действительно возможно. Например, асимметрию можно значительно снизить для задач по математике и программированию (Картинка к посту). Как? Если для задачи есть эталонное решение или тесты на корректность, то в процессе эволюции, какой бы сложной она ни была, генерация правильного ответа становится задачей RL-оптимизации.
Путём таких рассуждений автор приходит к формулировке условного "закона":
И дальше выделяет пять свойств, которыми должна обладать задача, чтобы быть "легко" решённой LLM:
⚫️ Быстрота верификации — можно за секунды определить, правильно ли решена задача
⚫️ Скейлинг верификации — можно проверять одновременно множество решений
⚫️ Согласованность корректности — все (люди) легко могут придти к консенсусу о том, какое решение хорошее, а какое нет
⚫️ Ранжирование качества решений — можно упорядочить варианты по степени качества
⚫️ Устойчивость к шуму — верификация коррелирует с качеством решения и ложно-положительные срабатывания минимальны
Автор вполне логично считает, что большинство задач, которые можно свести к быстрой верификации, будут решены в ближайшие годы.
Отдельно можно заметить, что большинство популярных бенчмарков как раз обладают всеми свойствами задачи для верификаци (MMLU, SWE bench, GSM8K, тот же Humanity's Last Exam). Потому эти бенчмарки и популярны, и потому в тех аспектах, что они проверяют (код, общие знания, математику) LLM-ы развиваются активнее всего.
В блоге Джейсон интересно пишет свои мысли про рисерч, как его вести, как строить карьерный путь и немного рефлексии на тему своих же научных статей.
Из интересного про RL — Асимметрия верификации. Ссылка
Множество задач требуют значительных усилий для генерации решения, но при этом легко поддаются проверке. Взять судоку или кроссворд. А вот написание эссе на заданную тему — напротив: сгенерировать его для модели несложно, а вот провести факт-чекинг и оценить содержание гораздо труднее. В этом и заключается асимметрия верификации: есть задачи, которые можно быстро и дёшево проверить на корректность (при наличии эталонного ответа), но при этом неясно, как к этому ответу прийти; а есть такие, к которым можно сгенерировать тысячи вариантов, но трудно определить, какие из них действительно правильные.
Тут и начинается самое интересное — поиск способов уменьшения асимметрии. Для большого класса сложных задач это действительно возможно. Например, асимметрию можно значительно снизить для задач по математике и программированию (Картинка к посту). Как? Если для задачи есть эталонное решение или тесты на корректность, то в процессе эволюции, какой бы сложной она ни была, генерация правильного ответа становится задачей RL-оптимизации.
Путём таких рассуждений автор приходит к формулировке условного "закона":
Verifier’s law: The ease of training AI to solve a task is proportional to how verifiable the task is. All tasks that are possible to solve and easy to verify will be solved by AI.
И дальше выделяет пять свойств, которыми должна обладать задача, чтобы быть "легко" решённой LLM:
Автор вполне логично считает, что большинство задач, которые можно свести к быстрой верификации, будут решены в ближайшие годы.
Отдельно можно заметить, что большинство популярных бенчмарков как раз обладают всеми свойствами задачи для верификаци (MMLU, SWE bench, GSM8K, тот же Humanity's Last Exam). Потому эти бенчмарки и популярны, и потому в тех аспектах, что они проверяют (код, общие знания, математику) LLM-ы развиваются активнее всего.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from эйай ньюз
GLM 4.5 — китайский опенсорс продолжает доминировать
Очередная очень сильная открытая MoE модель от китайцев, с очень хорошими результатами на бенчах. Гибридний ризонер, с упором на тулюз. Доступна по MIT лицензии, 128к контекста, нативный function calling, из коробки работают стриминг и batching, есть FP8‑инференс и совместимость с vLLM/SGLang.
Как и Kimi K2 модельку тренировали с Muon, но в отличие от Kimi авторы использовали QK норму вместо клиппинга — Kimi такой трюк не позволило провернуть использование MLA, из-за чего им пришлось придумывать свою версию оптимайзера. Для спекулятивного декодинга получше модельку тренировали с MTP. Она заметно глубже чем другие открытые китайские MoE — это повышает перформанс, за счёт роста размера KV-кэша. Вместе с этим они используют заметно больше attention heads. Это хоть и не помогает лоссу, но заметно улучшает ризонинг бенчмарки.
Модель идёт в двух размерах — 355B (32B active) и 106B (12B active). Претрейн был на 22 триллионах токенов — 15 триллионов токенов обычных данных, а после них 7 триллионов кода с ризонингом. На мидтрейне в модель запихнули по 500 миллиардов токенов кода и ризонинг данных с контекстом расширенным до 32к, а после этого 100 миллиардов long context и агентных данных при контексте уже в 128к.
Посттрейн двухэтапный — сначала из базовой модели через cold‑start+RL тренируют три эксперта (reasoning модель, agentic модель, и для общих тасков) и сводят их знания в одну модель через self‑distillation. Затем идёт объединённое обучение: общий SFT → Reasoning RL → Agentic RL → General RL.
Для ризонинга применяют одноступенчатый RL на полном 64K‑контексте с curriculum по сложности, динамическими температурами и адаптивным клиппингом. Агентные навыки тренируют на верифицируемых треках — поиск информации и программирование с обратной связью по исполнению. Полученные улучшения помогают и deep search и общему tool‑use. Кстати, их посттрейн фреймворк открытый и лежит на гитхабе.
Веса
Демо
Блогпост
Посттрейн фреймворк
@ai_newz
Очередная очень сильная открытая MoE модель от китайцев, с очень хорошими результатами на бенчах. Гибридний ризонер, с упором на тулюз. Доступна по MIT лицензии, 128к контекста, нативный function calling, из коробки работают стриминг и batching, есть FP8‑инференс и совместимость с vLLM/SGLang.
Как и Kimi K2 модельку тренировали с Muon, но в отличие от Kimi авторы использовали QK норму вместо клиппинга — Kimi такой трюк не позволило провернуть использование MLA, из-за чего им пришлось придумывать свою версию оптимайзера. Для спекулятивного декодинга получше модельку тренировали с MTP. Она заметно глубже чем другие открытые китайские MoE — это повышает перформанс, за счёт роста размера KV-кэша. Вместе с этим они используют заметно больше attention heads. Это хоть и не помогает лоссу, но заметно улучшает ризонинг бенчмарки.
Модель идёт в двух размерах — 355B (32B active) и 106B (12B active). Претрейн был на 22 триллионах токенов — 15 триллионов токенов обычных данных, а после них 7 триллионов кода с ризонингом. На мидтрейне в модель запихнули по 500 миллиардов токенов кода и ризонинг данных с контекстом расширенным до 32к, а после этого 100 миллиардов long context и агентных данных при контексте уже в 128к.
Посттрейн двухэтапный — сначала из базовой модели через cold‑start+RL тренируют три эксперта (reasoning модель, agentic модель, и для общих тасков) и сводят их знания в одну модель через self‑distillation. Затем идёт объединённое обучение: общий SFT → Reasoning RL → Agentic RL → General RL.
Для ризонинга применяют одноступенчатый RL на полном 64K‑контексте с curriculum по сложности, динамическими температурами и адаптивным клиппингом. Агентные навыки тренируют на верифицируемых треках — поиск информации и программирование с обратной связью по исполнению. Полученные улучшения помогают и deep search и общему tool‑use. Кстати, их посттрейн фреймворк открытый и лежит на гитхабе.
Веса
Демо
Блогпост
Посттрейн фреймворк
@ai_newz