🛠️ Метод Сначала определяют, какие слои лучше всего отображаются из одной модели в другую. Для этого обучают гребневую регрессию (Ridge Regression) между всеми парами слоёв source- и target-модели и находят те, где R² самый большой. При этом важно фитировать pre-RoPE-ключи. Так и ошибка выходит меньше, и на другие контексты экстраполируется лучше. Замечают, что ключи предсказываются лучше, чем значения. Впрочем, это было известно и из прошлой литературы. После определения самых важных source-слоёв для данного target-слоя признаки из них конкатенируют в один тензор и снова обучают на этом гребневую регрессию. Показывают, что важно брать не один, а несколько — 4–8 — слоёв из source-модели для приемлемого R². ⏱️ Занимает это час-полтора на ноде из 8×H100. 🧪 Эксперименты Валидируют подход на моделях семейств Qwen3, Llama-3.1, Ministral и на задачах с коротким ответом: ARC-C, HellaSwag, Winogrande, MMLU. На паре Qwen3 14B → 32B работает неплохо, на Qwen3 8B → 32B — уже хуже, а на Llama 3.1 и Ministral 3. В ablation показывают для Qwen, что pre-RoPE важен и что k = 1 — брать один самый важный слой — недостаточно. Для Ministral 3 можно вытянуть качество, если заменить линейную модель на MLP. Для Qwen3 это не помогает. Утверждается, что оверхед от маппера из source в target небольшой — в 3–25 раз меньше, чем prefill. 💡 Выводы Интересное исследование и идея, но будто бы до практического использования ещё далеко. Тесты — на простых бенчах, и будто бы подход не универсален. Для качественного отображения между разными моделями, скорее всего, потребуется более выразительная модель, и здесь возникает сложный trade-off между потенциальным выигрышем, стоимостью работы и обучения этой прокладки.

Еще немного интересных наблюдений из RL для MoE. В нем есть одна проблема, которая делает обучение гораздо более склонным к нестабильностям. В любом современном RL есть train-inference mismatch, обычно вызванный двумя вещами: 1) из-за асинхронности инференс отстает от трейнера и 2) из-за разной имплементации кернелов/разного железа/неассоциативности сложения (у одной версии dense чекпоинта pi_train(tok) / pi_inference(tok) отличается обычно в четвертом знаке). Однако, в MoE появляется еще один очень неприятный источник такого расхождения: routed experts. Проблема в том, что во время инференса могут активироваться одни эксперты, а во время forward_pass на стороне трейнера – другие, и незначительное изменение в скорах роутера (но достаточное для того, чтобы topK изменился) могут значительно изменить итоговый результат. Основные решения такие: - Просто фризим роутер и уменьшаем асинк ⇒ роутер реже пересекает границу, при которой меняется topK - R2/R3, они же Routing Replays: сохраняем экспертов, активируемых версией модели для инференса и форсируем forward pass через них в трейнере. В статье https://arxiv.org/abs/2512.01374 можно почитать про разницу R2 vs R3 и всякие доп детали. Но проблема в том, что экспертов-то мы форсируем, но скоры роутера меняются, и это может быть проблемой (можно порассуждать на тему, что будет, если инференс версия дала i-ому эксперту высокий скор, а трейнер – низкий) И на самом деле у всех результаты смешанные: у кого-то работает одно, у других – другое. Вчера прочитал https://kiddyboots216.github.io/mismatch/#conclusion-router-replay и увидел еще один способ: Total Router Recall – сохраняем не только экспертов, но и их скоры, а в трейнере фризим роутер. Интересно, что можно предложить способ, при котором мы будем роутер учить, используя скоры и экспертов с инференса, правда работать это будет плохо. В общем, для всех интересующихся RL-ем рекомендую полистать блогпост, там много чего интересно помимо реплеев

QUASAR: Lowering the Loss Floor of Quantization-Aware Training with Loss-Aware Reconstruction 📄 Статья 💻 Кода нет Когда PTQ (Post-Training Quantization) не выдает желаемого качества при целевой степени сжатия или модель нужно адаптировать по ходу дела, неизбежно приходится переходить к QAT (Quantization-Aware Training). Наивный STE (проброс градиента) может работать сносно, но расходится на низких битностях и вообще не очень стабилен. По факту градиент считается не из той точки, где в данный момент находится вес. Кроме того, существующие техники не учитывают кривизну при оптимизации в STE. И данная работа предлагает сравнительно недорогой способ сделать STE точнее и более адаптивным под геометрию.

Фазовый переход в использовании памяти: что это открытие значит для AI-разработчиков? 🟪 Вы когда-нибудь замечали, что в одних задачах LSTM или Transformer с памятью работают идеально, а в других – только жгут ресурсы без улучшения качества? Оказывается, выбор между «хранить историю» и «действовать по текущему моменту» – это не плавная настройка, а настоящий фазовый переход первого рода (как таяние льда). И его можно предсказать аналитически. 🪨 Новая статья в Physical Review Letters (плюс 19 страниц матана в Supplemental) даёт чёткие критерии, когда память выгодна, когда нет, а когда возможен гистерезис. Гистерезис – это когда состояние системы зависит не только от текущих параметров, но и от того, как вы к ним пришли (от истории изменения). Модель в двух словах. Попытался 📦 всю жесть из материала сублимировать 😐, вышло, как вышло. Не обессудьте. Итак... Есть скрытое состояние x(t) – например, концентрация питательного вещества. Вы получаете зашумлённое наблюдение: y(t) = x(t) + шум. У вас есть внутренняя переменная z(t) – память, которая эволюционирует по закону: z = v(t) + шум памяти, где v(t) – это управление: вы сами решаете, как менять память. За использование управления вы платите штраф Mv^2, прям как кинетическая энергия, чем больше вы «дёргаете» память, тем дороже. Одновременно вы хотите минимизировать ошибку оценки E[(x - x') ^2] с весом Q. Итоговая функция потерь: J = Q×ошибка + M×затраты на управление. Задача – выбрать стратегию v(y,z), которая минимизирует J в стационарном режиме. В машинном обучении мы часто добавляем L2-регуляризацию: loss = ошибка + lambda*|w|^2. При увеличении lambda веса плавно стремятся к нулю. Здесь параметр M играет роль lambda: чем больше M, тем дороже использовать память, и казалось бы, при больших M коэффициент при памяти должен плавно уменьшаться до нуля. Но здесь есть две связанные переменные (текущее наблюдение и как память на себя же влияет), которые влияют на поведение системы и друг на друга. Они не независимы. Оптимизация потерь J по этим двум переменным приводит к тому, что на их плоскости, могут существовать два локальных минимума – с памятью и без. Между ними – горный хребет (седловая точка). Когда параметры (например, M) меняются, один из минимумов может исчезнуть или стать глобальным. В момент исчезновения система скачком перескакивает из одной ямы в другую – это и есть фазовый переход. Суть открытия на пальцах. Представьте агента, который наблюдает за шумным сигналом и может хранить внутреннее состояние z. Обновление z стоит ресурсов (штраф M). Задача – минимизировать ошибку оценки при ограниченном бюджете. Авторы доказали: · Существуют два порога Thet_Q и Theta_M: · Если Theta_Q < 1 — память точно бесполезна (даже локально). · Если Theta_M >=1 — память всегда выгодна (глобальный оптимум). · Между ними – бистабильность: обе стратегии локально оптимальны, выбор зависит от истории (гистерезис). А теперь разбираем, что из этого можно вынести для AI. 🥴 1. Оптимизация архитектур с памятью (LSTM, Transformer, RNN) Современные модели с памятью, например, трансформеры с окном внимания или LSTM, всегда используют память, даже когда она не нужна. Результаты подсказывают: · При высоком шуме в данных память становится бесполезной – лучше полагаться только на текущий вход. Это объясняет, почему в некоторых задачах обрезка контекста (например, короткое окно внимания) не ухудшает качество. · При быстро меняющейся среде прошлая информация устаревает – нужно динамически уменьшать размер буфера или использовать забывание, как в LSTM, но с адаптивным коэффициентом. 2. Регуляризация и штраф за сложность в RL. В RL агент часто хранит внутреннее состояние например, в PPO. Штраф Mv^2 в статье – аналог штрафа за изменение скрытого состояния. Это можно использовать: · Как регуляризатор в функциях потерь, чтобы поощрять агента использовать память только когда это действительно выгодно. · Аналитические пороги Theta_Q,Theta_M помогают автоматически подбирать коэффициент регуляризации M без дорогой сетки гиперпараметров – просто по статистике шумов среды. Это особенно полезно в Meta-RL, где среда меняется между эпизодами. 3. Continuous Learning и катастрофическое забывание. В задачах continual learning модели должны сохранять знания о прошлых задачах, но обновление памяти (весов) стоит ресурсов. Аналогия: · Параметр M – штраф за изменение весов. · Фазовый переход означает, что при превышении порога штрафа модель перестаёт обновлять веса вообще – т.е. замораживает их. Это даёт критерий, когда лучше полностью остановить обучение (если среда не меняется) или, наоборот, разморозить (если волатильность растёт). На практике это позволяет строить адаптивные стратегии обновления – не тратить ресурсы на веса, которые не нужны. Вот такое интересное исследование. Читайте полную версию, применяйте открытие, и stay tuned 🦾

​​Talk: breaking into machine learning - recording Пару дне назад я уже писал, что я буду делать доклад для пакистанских студентов. В общем получилось так, что на него зарегистрировалось 450+ человек, несмотря на то, что это был праздник - день независимости. Встреча была в google meets, но там лимит в 100 человек, так что все желащие не влезли. В результате делали трансляцию в linkedin, запись можно посмотреть тут https://www.linkedin.com/events/liveaugust147494045235434594306/ Вопросы были в основном про карьеру - как её начинать, что делать в текущей ситуации с засилием AI, как вкатываться в сферу и так далее. Думаю, скоро напишу блогпост про это, чтобы мысли были не только в записи. Сам доклад шёл 40 минут, потом я ещё 40 минут отвечал на вопросы. #career #ai #datascience

Вышел технический репорт о Sona – модели, которая заменила весь рекомендательный стек Яндекс Музыки https://arxiv.org/abs/2608.11015 Эта модель – итог целого года работы. И это лучшее внедрение трансформеров в истории А/B-тестов в Яндекс Музыке. Но главное здесь, что Sona – это одна модель. До этого продакшн-каскад рекомендаций Яндекс Музыки включал в себя 15+ генераторов кандидатов плюс ранжирование на сотнях ручных фич. И это все заменили единой моделью, обучаемой end-to-end. Это даже звучит сложно, а на деле несет за собой еще больше проблем и нюансов, чем может показаться на первый взгляд. Вот три центральных момента: 1️⃣ Раньше, в подходах типа OneRec, ранжирование считала отдельная модель на ручных фичах. Sona же должна была стать единым рецептом обучения и инференса, то есть декодер (который генерирует кандидатов) и ранкер (который их ранжирует) должны использовать один и тот же энкодер user-эмбеддингов, которые рассчитываются один раз за запрос. А значит – надо обходиться без ручных фич. Но проблема в том, что явный сигнал (лайки, репиты) довольно редок, чтобы выучить ранжирование напрямую. Поэтому тут встроена дистилляция. Сначала обучали Teacher Ranker. Это большая, медленная, но очень умная модель, которую тренили аж на годе логов. Она не используется в проде и нужна для того, чтобы научить шустрый Ranking Module воспроизводить ее скоры. 2️⃣ Так как Sona – это encoder-decoder, обучаемый хронологически на Next Token Prediction, каждый трек нужно представить в виде токенов. Это называется Semantic ID. И тут кроется парадокс: чем больше растет словарь токенов, тем модель должна быть умнее, но на самом деле она просто не успевала эффективно использовать возросшее пространство и деградировала. Поэтому одной из самых сложных частей было сделать рецепт токенизации, который бы обеспечивал рост качества при росте словаря. Дьявол кроется в деталях. 3️⃣ Ну и, конечно же, инфраструктура. Переход на одну модель потребовал фактически нового движка рекомендаций, включая сложный online learning pipeline. Кроме того, авторегрессивная генерация с длинными историями – это дорого, и поэтому пришлось прорабатывать отдельные архитектурные трюки (History Compression, кастомные CUDA-кернелы, radix top-k), просто чтобы уложиться в приемлемую латентность. Ради чего была вся эта огромная работа? На этот вопрос хорошо отвечают метрики. Sona принесла: +4,53% Active Users, +6,30% Total Listening Time и +11,42% Likes. Причем это прирост поверх улучшений от предыдущих внедрений, которые оставались в контрольной выборке в продакшне. В планах у команды – масштабирование, добавление RL и, конечно, раскачивание Sona на полный трафик. Поздравляем ребят с грандиозными результатами!

KDD’26, день первый. На конференции собралась индустриальная тусовка — приехали ключевые рекомендательные команды из вообще ВСЕХ больших компаний. 1. Сходил на первую половину Tutorial on Generative Recommendation: Foundations and Frontiers от Kuaishou и City University of Hong Kong. Выделили два (будущих?) тренда: * если изначально все использовали encoder-decoder модели для генеративного ретривала, потому что в них было удобно впихивать богатый контекст; то сейчас двигаются в сторону decoder-only моделей, которые лучше скейлятся * диффузионные подходы, при которых мы предсказываем сразу все семантические токены целевого айтема — очень перспективное направление, которое позволяет избавиться от аккумуляции ошибок при авторегрессивной генерации токенов После кофе-брейка я на туториал не вернулся, потому что: * были супер энциклопедические слайды, на которых просто перечислялось много статей по паре минуток каждая, очень поверхностно, без инсайтов, с неточностями * при этом не было живого рассказа - весь текст просто зачитывался. Надеюсь, потом выпустят с этим текстом техрепорт)) Ну а если серьезно, то проще потом слайды полистать, наверняка какие-то инсайты все-таки будут ближе к концу рассказа 2. Пообщались с Федором Борисюком. Когда возле него осталась только наша русская компашка, Федор сам первый перешел на русский язык :) Что рассказывал: * если я все правильно понял, он сейчас руководит тремя командами. Что-то возле поиска и рекомендаций * статьи пишут по выходным. К процессу привлекается большое количество коллег. Федору просто нравится писать статьи и прокачивать репутацию, а у коллег есть мотивация участвовать как минимум чтобы получить грин-карту)) * сам Федор сторонник того, чтобы на работе со всеми уважительно и дружелюбно обращаться, налаживать хорошие отношения. И максимально коллаборироваться, делать совместные проекты. Но говорит, что это иногда приводит к плохим последствиям, во время политических игрищ * у него всегда часть проектов долгосрочные, а часть краткосрочные. Долгосрочным как правило занимается небольшая команда из 2-3 человек. Если проект планируется на год-полтора (больше бизнес вряд ли вытерпит), то расставляются майлстоуны на каждые полгода с оффлайн-метриками * если попался плохой руководитель, то надо просто ротироваться и не мучаться :) * через полтора месяца должен быть дроп крутой новой статьи от Линкедина 3. Воркшоп Two-sided Marketplace Optimization: Search, Discovery, Matching, Pricing & Growth. Было выступление от Director of Research @ Spotify, Paul Bennett — From User Needs to Ecosystem Design: How AI Is Reshaping Discovery. Рассказывал про разные сценарии, в которых применяют LLM: * steerable recommendations — тюнят модель с помощью контрольных токенов выдавать familiar (пользователь уже взаимодействовал с подкастом >10 минут за последний месяц) и unfamiliar (обратная ситуация) контент в рекомендациях. Похоже на мою идею с обуславливанием, про которую рассказывал на Turbo ML Conf 2025 * Intent-aware search — в поиске есть разные сценарии; иногда нужно просто включить рекомендации с какими-то настройками, иногда запустить реальный поиск, иногда просто найти артиста, иногда что-то еще. LLM можно использовать как router, который определяет в какой api (recs/search/etc) нужно отправлять запрос * Conversational discovery — часто пользователь сначала сам не понимает какие ему нужны рекомендации; и только в процессе взаимодействия с рекомендательной системой начинает понимать чего все-таки хочет. И для этого как раз multi-turn диалог, в котором он может и промежуточные рекомендации получить, и пообщаться с рексистемой 4. Что еще: * на конференции 70+ русскоговорящих участников, это очень много. Много людей со статьями, а еще есть студенты с ИИ360 программы. Жутко им завидую, меня бы кто на первом-втором курсе на конференцию отправил! Говорят, что ничего непонятно, но все очень вдохновляет) * все офигевают от джетлага * даже в Линкедине (!) разработчики слушают наш DeepRecsys курс :)

🍏 MLX: как Apple меня купила и почему я переплатил за 32 GB MacBooka Вы могли заметить последнее время, что абсолютно все в интернете сошли с ума с этими mac mini и мне кажется, что нам стоит поговорить почему. Как уже понятно из названия имя этому почему MLX — фреймворк для машинного обучения, разработанный командой Apple Machine Learning Research 🧠 В чем магия? Если вы когда-нибудь работали с PyTorch на NVIDIA, вы знаете про вечную боль: .to('cuda'). Вы постоянно перекладываете данные из оперативной памяти (RAM) в видеопамять (VRAM). Шина PCIe — это узкое горлышко. В Apple Silicon архитектура объединенная (Unified Memory Architecture). И MLX — это первый фреймворк, который использует её «нативно»: 1. Zero-copy: В MLX нет копирования данных. Массив (mlx.core.array) просто лежит в памяти, и CPU, и GPU работают с одними и теми же байтами по одному адресу. Это убирает огромный оверхед на передачу данных. 2. Lazy Evaluation: Как и JAX (the Google Python library for machine learning and array computing, хз почему именно такая аббревиатура), MLX «ленив». Он не считает ничего, пока вы не попросите результат. Он строит граф вычислений и оптимизирует его: например, объединяет несколько операций в одно ядро (kernel fusion), чтобы лишний раз не дергать память. 3. Metal-First: Библиотека написана на C++ специально под Metal API. Она умеет выжимать максимум из AMX (Apple Matrix Extensions) — секретных блоков внутри чипа, которые созданы исключительно для перемножения матриц. Так что даже я, как былой адепт запускания чего угодно на чем угодно и потом кручения моделек на этом был просто вынужден купить мак на 32 гб, так как убежден, что это прожиточный минимум, а по цене более мощных мини я уже могу себе на тенсоррентах побаловаться #AI @techn0danya

​​Time Series with PyTorch — Graeme Davidson, Lei Ma Мне прислали очередную книжку от Packt на прочтение и ревью - на этот раз про time series forecasting на PyTorch. Тема мне близкая: временные ряды — одна из самых сложных для меня областей ML, и при этом большинство книг по deep learning относятся к ним как к чему-то второстепенному после CV и NLP. Книга идёт начинает с базовых вещей (что делает временные ряды сложными, как правильно оценивать модели, PyTorch с нуля), демонстрирует современные архитектуры (RNN, transformers, N-BEATS, N-HiTS, foundation models, diffusion) и выходит за пределы точечного прогноза — классификация, кластеризация, anomaly detection, self-supervised learning. Мне понравилось, что тема правильного качества моделей разбирается в деталях: например, показывают как заведомо худшая модель выигрывает по MAPE, и есть целая глава про data leakage. Отдельно порадовали объяснения через физику: один из авторов физик, и он объясняет RNN через качели на детской площадке, а diffusion — через каплю чернил, которая расплывается в воде, пока не превратится в гауссиану. Ещё мне понравилось, что примеры построены вокруг соревнования M5 на Kaggle. Я в нём когда-то участвовал и зафейлился, так что было интересно посмотреть на разные модели и подходы к оценке на данных, с которыми в своё время намучился. Из минусов — про time series foundation models (Lag-Llama, TabPFN, Chronos, TimeGPT) рассказывают, но не запускают их на практике, а это как раз то, что хотелось бы попробовать руками. Amazon Author's website Code Мои обзоры: Personal blog Medium #bookreview

Где-то два с половиной года назад на конференции по рексистемам в Вышке, куда я пришел слушателем (так появилась секция кулуары, которой, кстати, давно не было), мне задали вопрос — почему у нас нет научных публикаций. Я ответил, что у ребят в Яндексе, занимающихся рексистемами, нет KPI на статьи — только KPI на внедрения. При этом я, конечно, не воспринимал вопрос лично, но сам уже долгое время горел идеей писать статьи, публиковаться на конференциях, участвовать в жизни научного сообщества. Через год я съездил на свою первую большую конференцию ACM RecSys’24. Про эту поездку есть целая серия постов; нетрудно понять, что мне очень понравилось)) Был даже маленький забавный моментик, когда я во время выступления Эда Чи что-то спросил, а он ответил “А может, вы про это статью и напишете” :) После всего этого я еще больше укрепился в решимости начать писать статьи. KPI не то чтобы после этого поменялся, но как будто подвернулся хороший момент, чтобы попробовать. Мы разработали и внедрили в Яндекс Музыку большую рекомендательную трансформерную модель (тот самый Аргус); и казалось логичным превратить это внедрение в статью. Затем, при подготовке лекции для ШАДа про LogQ коррекцию для двухбашенных моделей, я обнаружил ошибку в широко используемой по всему миру формуле. Когда я принес своим ребятам выкладки, далеко не все сразу поверили, что такое вообще возможно)) Было крайне нетривиально одновременно работать фуллтайм, преподавать новый курс в ШАДе и при этом еще и писать сразу две статьи. Но каким-то образом все получилось, и примерно год назад у нас сначала приняли на ACM RecSys’25 статью про LogQ коррекцию, а затем спустя еще полгода приняли на ACM KDD'26 статью про Аргуса. И вот я радостный стою уже 7 часов возле постера на рексисе и рассказываю всем окружающим про LogQ коррекцию)) А потом ночью в караоке пою Radiohead Creep в толпе рексисоидов И самое крутое, что мы на этом не остановились: * на тот же ACM RecSys’25 была принята работа про датасет Yambda, в которой я лично не участвовал, но поучаствовали ребята из нашей команды — Влад Тыцкий и Владимир Байкалов * на ACM SIGIR приняли статью Владимира Байкалова и его студентов из ИТМО про дообучение семантических айдишников * туда же на ACM SIGIR приняли статью от ребят из нашей (бывшей) команды — Артёма Матвеева, Влада Тыцкого, Сережи Макеева и Сережи Лямаева, про улучшение архитектуры энкодер-декодера для generative retrieval Ну и вот сейчас у нас приняли статью на воркшоп ACM KDD’26, продолжающую линию ресерча из статьи Top-K REINFORCE (я периодически шучу, что надо было её назвать "Correcting the Off-Policy Correction" в духе нашей LogQ статьи) и скрещивающую ее с generative retrieval. Про нее я написал в прошлом посте. Кроме того, на архиве появились препринты, про которые смею надеяться, что они дойдут до публикации: * мой Variable-Length Semantic IDs * Gryphon от ребят из Яндекса, в котором поучаствовали Олег Сорокин и Влад Додонов из нашей бывшей команды (читайте подробности про статью на канале Даши @redrecsys) И все это произошло только за последний год! Хочется верить, что мы только в начале нашего пути и нас всех ждет еще миллиард параметров приключений и публикаций :)

Подборка методов улучшения LLM На этот раз собрали несколько статей на тему обучения и инференса LLM. Ожидаемо, эта область на ICML 2026 — самая популярная и обсуждаемая. Rethinking the Trust Region in LLM Reinforcement Learning Сингапурские учёные рассматривают проблему нестабильности GRPO-like-алгоритмов. Авторы связывают её с асимметричностью применяемого клиппинга относительно абсолютного значения правдоподобия сгенерированной траектории. Разброс значений IS (очень шумной оценки trust region в PPO) снижается с ростом вероятности, вследствие чего клиппинг чаще срабатывает на высокоэнтропийных генерациях. Эту проблему уже частично лечили в DAPO, повышая правую границу клиппинга. Здесь же предлагают перейти к более точным оценкам trust region: через KL-отклонение по полному словарю, по top-K или через альтернативную, но более подходящую односемпловую оценку. В экспериментах показывают более стабильное обучение. Кроме того, в статье много аблейшнов и интересных выводов. Don't Force the Fit: Bounded Log-Likelihood Loss for Enhanced Reasoning in Large Language Models Очный доклад о модификации SFT-лосса для обучения на ризонинг-задачах. Предлагают перейти от классической кросс-энтропии L = - log p к ограниченной в нуле: L = log (2 - p). На высоковероятных токенах градиент нового лосса приближается к классическому CE, а вот на низковероятных — не улетает в бесконечность, а ограничен небольшим значением. Мотивация такого подхода в том, что в ризонинг-цепочках есть множество высокоэнтропийных токенов, которые отвечают скорее за «стиль» рассуждения, но не влияют на его качество. При этом они отбирают значимую часть обучения, не давая как следует обучиться действительно важным токенам. Приросты на графиках выглядят неправдоподобно большими. Sparser Block-Sparse Attention via Token Permutation Ресёрчеры решают проблему long-context-префилла: full attention дорогой, а обычный block-sparse attention не всегда хорошо работает, потому что важные key-токены размазаны по разным блокам. Идея PBS-Attn: перед block-sparse attention переставить K/V-токены так, чтобы важные токены оказались рядом. Аттеншн не меняется при одинаковой перестановке K/V, зато sparse-блоки становятся более плотными и полезными. Из-за каузальной маски нельзя перемешивать всё подряд, поэтому авторы делают перестановку внутри сегментов. Это сохраняет авторегрессивность, но всё ещё позволяет «дефрагментировать» матрицу аттеншна. Плюс в том, что это не новая архитектура. Можно взять предобученную модель, добавить permutation и block-sparse-кернел и ускорить long-context-инференс. На LongBench качество почти такое же, как у full attention, и лучше, чем у других бейзлайнов. По скорости заявляют до 2,75× ускорения на long-context-префилле. Critique-GRPO: Advancing LLM Reasoning with Natural Language and Numerical Feedback Ещё один подход к тому, как делать критику в GRPO. На сложных бенчах обучение в какой-то момент начинает стагнировать. Авторы предлагают добавить reward-модель, которая будет писать критику ответа актора. Затем эта критика подаётся модели вместе со старым ответом, и модель пишет ответ лучше. После этого даунсемплят такие аугментированные примеры и конкатят их с обычными. На сете семплов с критикой модель учат сразу на улучшенный ответ — без промежуточной критики и первого ответа, как будто это изначально была такая генерация. На математических и научных бенчах (AIME, MATH, GPQA) получают приросты от 7 до 12 пунктов. Спросил автора, как бы он внедрял это в агентный RL. Он сказал, что, по его мнению, у модели должна быть тула «покритикуй мою текущую траекторию». Интересный подход. Личное мнение: непонятно, насколько вообще критика в RL полезна. Как будто правильнее решать проблемы, которые она пытается закрыть, другими способами. Увидели интересное ❣ Алексей Зотов, Влад Тыцкий и Тимофей Смирнов #YaICML2026 Душный NLP