Технический отчёт DeepSeek-V4.1-Flash — часть 2/2 Продолжаем разбирать техрепорт DeepSeek-V4.1-Flash. Сегодня поговорим об архитектуре, а ещё речь пойдёт об обучении.  В SWA прогоняется не весь контекст, а только последние 128 токенов для построения начального SWA KV. Это не сильно влияет на качество, но позволяет уменьшать общий размер кеша в восемь раз по сравнению с тем, что было у DeepSeek-V4-Flash. Также в версии 4.1 используется Single-Pass mHC. mHC — Manifold-Constrained Hyper-Connections — вариант hyper-connection, в котором спектральная норма всех проекций равна единице. В варианте Single-Pass матрица смешивания вычисляется по прошлому слою и не зависит от текущих активаций. Благодаря этому, её можно зафьюзить в один кернел и получить ускорение, а также снизить трафик активаций.  Engram со 196 миллиардами параметров «лежит» в энкодере на первом и 14-м слоях, поделённый поровну. Для хранения N-грам используются восемь независимых кеш-голов, в каждой из которых примерно 16 миллионов записей. При этом «нагрузка» распределена неравномерно — чтобы уменьшить коллизии берутся простые числа, близкие к 16 миллионам. Сами N-грамы хранят в FP8. Из исходного Engram убрали каузальную свёртку, потому что она осложняла инференс.  В DeepSeek-V4.1-Flash вместо MTP используют DSpark. Он внедряется на этапе генерации роллаутов, и DSpark динамически обновляется под меняющуюся политику. KV-кеш хранят в формате NVFP4. Кеш квантуется после RoPE, потому что так удобнее инферить и это избавляет от необходимости накладывать RoPE на квантизованный кеш. Для SWA KV кеш делают в FP8, но он достаточно лёгкий, поэтому не сказывается на скорости работы.  Что касается инфраструктуры, то зрительный энкодер запускается отдельно, чтобы не тормозить языковой конвейер. Батчи накладывают так, чтобы они распределялись равномерно по числу токенов, ведь на входе могут быть изображения как высокого, так и низкого разрешения.  Декодирование почти не дорожает с ростом контекста — подорожание с 4К токенов до 1М составляет примерно 25%.  При сборе данных для обучения отфильтровывали слабый синтетический машинный перевод и старую информацию — старались брать свежие данные. В мультимодальный набор вошли пары изображения-текст и документы. В итоге вышло примерно семь токенов текста на один мультимодальный.  На претрейне было 45 триллионов мультимодальных токенов. Батч составлял 100,6 миллиона токенов, а контекст увеличивали с 64 тысяч до миллиона, снижая LR. По качеству рассуждений и выполнению задач, связанных с программированием, после претрейна 4.1-Flash сопоставим с V4-Pro-Base. На посттрейне — стандартный SFT, объемный RL с большим числом сред и синтетическими задачами. Для тренировки агентского поведения брали агентские задачи из открытых источников, а также генерировали синтетические — имитации корпоративных систем, их ошибок. Большее число RL-шагов позволило получить лучшие результаты в стандартных бенчмарках на кодинг вроде SWE-Bench Pro и DeepSWE. Сам RL — асинхронный. Роллауты генерируются независимо и подаются в модель по готовности. Токены с чрезмерной давностью маскируются в лоссе, чтобы избежать off-policy.  В финале посттрейна проводят On-policy-дистилляцию. Здесь более 40 моделей-учителей, каждая из которых отдельно проходила этап посттрейна. Учителя асинхронно генерируют траектории. Данные ученику подаются динамически от разных учителей, что позволяет получить лучшее качество.  По бенчмаркам DeepSeek-V4.1-Flash на агентских задачах примерно равен Opus-5. Однако авторы отмечают уязвимости сред оценки и сообщают, что модели могли произвести reward hacking. Результаты можно посмотреть в таблице выше.  Разбор подготовил ❣ Денис Кузнеделев Душный NLP

Казалось бы, зачем рекомендательной системе что-то генерировать? Нам же надо выбрать человеку существующий трек, а не сочинить новый. Но генерировать можно идентификатор этого трека. У Алексея Гусакова на deep tech night как раз был доклад про то, как Яндекс дошел до генеративных рекомендаций без ручного фичеинжиниринга. Начиналось все довольно привычно: BERT превращает историю прослушиваний в вектор пользователя, дальше ищем близкие векторы треков. В версии 2023 года модель учитывала историю из 128 треков. Потом появился Argus: идея была в том, чтобы предсказывать следующий трек примерно так же, как LLM предсказывает следующий токен. Обучение стало вычислительно эффективнее, историю удалось увеличить до 8000 треков. Но оставалась неприятная особенность: всю историю пользователя сжимали в один вектор, а подходящие треки искались через простую функцию близости, плюс еще был каскад отбора кандидатов. В итоге это приводило к тому, что если хороший трек потерялся на раннем этапе, можно сколько угодно улучшать финальный ранжировщик, но этот трек пользователь уже не увидит. В новой модели SONA трек представляют последовательностью из трех кодов, Semantic ID. Их получают из текста и аудио, причем коды сохраняют музыкальную семантику: у похожих треков могут совпадать первые компоненты. Дальше модель учится генерировать эту последовательность и одновременно ранжировать кандидатов по ожидаемому отклику пользователя. То есть next token prediction, только на выходе рекомендация, а не ответ в чатике. По данным команды, в A/B-тесте SONA дала около +4,5% к числу активных пользователей. Причем поверх предыдущих улучшений, а не относительно какого-нибудь древнего бейзлайна. Мне как человеку, успевшему позаниматься рекомендашками, и потому к ним неравнодушному, доклад понравился тем, что показывает как успешно прикручивать NLPшные методы к привычным задачам вроде построения рекомендательных систем. И, кстати, перетаскивание методов из NLP в RecSys и обратно всегда было рабочей идеей - есть много похожего в данных.

На этой неделе Яндекс опенсорснул Alice AI‑T5-35B‑A0.6B. Это обученная с нуля претрейн модель, которая отвечает за быстрые ответы на Поиске. Только что на Practical ML Conf мы слушали про этот релиз из первых рук: Артур Петросян, CTO Alice AI Search, рассказал о том, как команда обучила систему, которая дала +0.34% к продуктовой метрике Sessions Per User и в 56.7% случаев выигрывает в попарных сравнениях против Google AI Overview. — Одна из главных интересных особенностей этой модели – ее архитектура. Это Encoder‑Decoder + MoE. Последние такие модели выходили в 2021–2023 годах (не считая недавнего DeepSeek-V4.1-Flash, который вышел почти в один день с Alice AI‑T5), так что выбирать такую архитектуру было довольно необычным и рискованным решением. Не обошлось без сложностей при разработке: например, на претрейне сколлапсировал роутинг в энкодере, и пришлось сменить схему балансировки экспертов. Зато архитектура себя оправдала. Энкодер один раз читает длинный контекст из документов, а легкий декодер быстро пишет короткий ответ, что идеально для задачи «много на входе, мало на выходе». MoE при этом дает знания уровня 35B параметров при вычислениях как у 0.6B. — После претрейна с моделью также колдовали с помощью SFT и RLHF. На этих этапах модель училась писать ответ так, чтобы он был максимально полезен для живого пользователя. Интересно, что при этом команда обошлась без эталонных ответов, написанных людьми: на запрос генерировалось много ответов от разных систем, лучший отбирался автоматически по набору сигналов качества, а на этапе RL модель дополнительно училась на сигналах реального поведения пользователей Поиска. — Еще одна интересная деталь пайплайна – сжатие контекста. Чтобы не гонять через LLM огромные пачки документов, команда с нуля обучила маленькую BERT‑подобную модель на 80 млн параметров, которая занимается тем, что определяет релевантность каждого токена запросу. Далее поверх этого накладывается метод под названием Cross‑Entropy RL, и в итоге получается экстрактор, который понимает, какую именно информацию модель уже знает из весов, и какой минимальный контекст ей нужен для хорошего ответа. И да, все это – только некоторые детали работы. Про остальные нюансы обучения и строения системы можно почитать вот в этой статье на Хабр. Поздравляем команду с релизом!

Музыкальный датасет Яндекса – фаворит для мировых экспериментов в RecSys 😳 Исследователи Meta* предложили «генеративный верификатор» — маленькую модель, которая перепроверяет шорт-лист готовой системы отбора кандидатов и вытаскивает наверх то, что та задвинула вниз. Саму систему при этом не трогают: ни переобучения, ни пересборки индекса. Тестировали на двух бенчмарках — товарах Amazon и открытом YaMBDa от Яндекс Музыки (обезличенные прослушивания в трёх размерах: 50 млн, 500 млн и 5 млрд взаимодействий). И вот тут началось интересное:

🟢 Чем крупнее каталог, тем сильнее эффект: на максимальном масштабе — 5 млрд взаимодействий и 5,4 млн треков — Recall@10 у всех трёх моделей вырос на 25–30%. На Amazon, где каталог — пара тысяч товаров, прибавка куда скромнее: 6–15%. 🟢 Вывод Meta*: на гигантских каталогах стандартные ретриверы захлёбываются правдоподобным мусором в топе — и тут выручает дополнительная проверка кандидатов.

Такие дела: без наших датасетов никуда. Статья тут 😎 *запрещенная в РФ организация @xor_journal

Квантовое машинное обучение - крайне любопытная концепция, переносящая идею классических нейронных сетей на прототипы квантовых процессоров. Слева - типичная архитектура обычной нейронной сети. Вектор данных, обозначенный х, передается на вход функциям активации, выходы которых сворачиваются с вектором весов w - и так много раз, включая глубокие слои. Вектора весов подбираются для решения нужной задачи, что и составляет обучение сети. На выходе имеем вектор ответов o. Сходная по смыслу схема может быть реализована на квантовом процессоре, см. правую часть картинки. Здесь исходные данные нужно загрузить в кубиты, например, переводя их в углы поворота параметризованных однокубитных операций θ(x). Затем вместо фиксированных функций активации имеется много параметризуемых квантовых вентилей, причем "внутренних слоев" этих вентилей может быть много, и все они разной степени сложности. Параметры этих унитарных операций также подбираются исходя из желаемого поведения алгоритма. Получается, что внутренние квантовые вентили берут на себя роль как функций активаций, так и весов - но делают это сложным способом, специфичным для квантового устройства. В конце этого расчета ответ считается закодированным в амплитудах кубитов, поэтому проводя измерения над регистром, можно получать классический ответ. Это интересно по многим причинам: квантовые цепочки операций могут быть крайне выразительными даже при небольшом числе кубитов, поскольку доступное многообразие имеет сложную структуру. Кроме того, есть интересные способы вычисления градиентов и аналог обратного распространения ошибки, что делает обучение довольно понятным процессом, аналогичным обучению классической нейросети.

ML вообще работает? (эпизод 1) Давно не писал в канал. Понял, что сейчас сфокусирован на довольно больших историях, которые в формат одного поста не умещаются - ну что ж, готовьтесь к серии постов:) Заголовок конечно чуть кликбейтный для привлечения внимания "А персональные ленты товаров вообще работают? А для какого % пользователей - скорее нет?" -- Вот один из вопросов, который донимает меня последнее время. Подобное есть в любом ML-продукте от банковского скоринга до LLM-чатов, но ответить на этот вопрос не так-то просто На первый взгляд, элементерно: есть бизнес-метрики (продажи, CR и тп) и оффлайн-метрики (ndcg, recall@k). Если они достаточно хороши (vs бейзлайн и vs прод неделю назад), то все круто же? А вот и нет. Эти метрики (как и почти все другие классические в ML и продукте) показывают качество в среднем. В среднем, у нас может быть хороший продукт, но условно для 10% пользователей - плохим. Проблема чаще всего в том, что это важные 10%: новички, пред-отточники, пока еще малоактивные пользователи. Если не сделать для них качественный ML-продукт, то со временем они просто уйдут = долгосрочно это падение всех основных метрик, хотя в моменте может быть и особо не заметно. Ну и бонусом у вас постоянный поток негативного фидбека 😢 Поэтому хорошо бы мерить не только качество в среднем, но и долю плохих кейсов (дефектов) = defect rate. Пусть дефект - случай, когда пользователь сталкивается с чем-то очевидно стремным, что может привести к мгновенному окончании сессии в приложении или даже оттоку Посмотрите на свои ML-продукты. Особенно если они b2c - на экраны приложений с ними. Как часто вы видите дефекты и какие? Покидайте в комменты скрины с дефектами - может, что-то из них разберу. И поставьте лайк что ли, если эта тема интересна -- у меня там на очереди уже есть несколько эпизодов с деталями, как этот defect rate можно считать)

Mask Forcing (HKUST / LIGHTSPEED / UCLA) Прием для дистилляции авторегрессивных видеогенераторов. Проблема: при дистилляции из двунаправленной модели в каузальную, видео часто получаются перенасыщенными и сглаженными. Mask Forcing это лечит, ничего не меняя в архитектуре. Эффекты: - Быстрее сходится и выше качество - Больше динамики в движении, лучше следование инструкциям - Чинится перенасыщение и сглаживание - Работает и для длинных видео (30 сек в тесте с LongLive) - Монтируется в любые существующие пайплайны AR дистилляции, chunk-wise и frame-wise - Не требует реального видео, дополнительных стадий пост-трейна, изменений архитектуры или инференса На видео слева Self-forcing, справа Mask forcing Гитхаб #optimization VK | MAX

Как AI-агенты помогли мне взять серебро на Kaggle - и где они меня подвели Недавно я, впервые за долгое время, поучаствовал в соревновании Kaggle - ROGII. Задача - geosteering: по гамма-каротажу и траектории понять, где буровое долото находится внутри геологического слоя. Мы заняли 93 место из 6000+ команд, серебро. Главное отличие от прошлых соревнований: агенты написали практически весь мой код. Я выбирал направления и решал, чему верить; ChatGPT Deep Research искал статьи и подходы; Claude Code делал имплементацию, а ближе к концу я всё чаще переключался на Codex. Работало весьма хорошо. Раньше bottleneck часто был в реализации идей, а теперь мог сказать "добавь эти пять фич и перезапусти тренировку" и получить результат. Агенты присылали апдейты по тренировке в Telegram; и через remote connection можно было направлять следующие шаги. И иногда агенты неожиданно тупо ломались: - Claude раз за разом пытался захардкодить три видимые тестовые скважины, хотя на сабмите Kaggle подменяет их скрытым датасетом. Пришлось заводить отдельное правило и заставлять проверять его каждый раз. - Codex решил, что несколько сложных сэмплов "плохие", и выкинул их из OOF. Локально стало красивее, а при мерже с тимейтами выяснилось, что у меня не хватает строк. - Claude любил запускать "быстрый дешёвый smoke run", после которого идея объявляется нерабочей, хотя эксперимент имел мало общего с тем, что я хотел. - неправильные выводы записывались в память и влияли на следующие эксперименты, приходилось чистить руками. - Opus 4.6 выполнял инструкции надёжнее, чем 4.8 и 5.0: дал пять задач - сделает пять, а более новые версии иногда брали одну-две и игнорировали остальное. Главный вывод: агент оптимизирует ту метрику, которую видит. Приватный лидерборд он оптимизировать не может, поэтому работает через прокси - локальный CV, паблик, время выполнения или просто "выглядит ли задача сделанной". И очень способный агент может стать очень хорош в оптимизации чего-то, что слабо связано с тем, что тебе нужно. Ещё показательно: победители переформулировали задачу - вместо построчной регрессии 2D alignment и декодирование связного пути через всю скважину. Агенты отлично искали итеративные улучшения имеющихся идей, но не могли придумать что-то принципиально новое. Так что агенты не отменяют экспертизу. Они её усиливают: если ты в теме, то можешь проверить много идей; если просто просишь агентов работать за тебя - они уйдут в неправильном направлении быстрее, чем ты сам. Блог Medium Ycombinator #ai #kaggle

Снятся ли трансформерам электроовцы? В 2015 Google выкатила DeepDream, и картинки, где облака прорастают собачьими мордами, разошлись по Интернету как отдельный визуальный стиль. Но за этими картинками исследователей занимало другое — возможность заглянуть внутрь нейросети и понять, что происходит между входной фотографией и списком вероятностей на выходе. Метод усиливает те участки изображения, на которые сильнее реагируют внутренние сигналы модели. И когда так визуализировали класс «гантель», рядом с ней раз за разом появлялись человеческие руки. Сеть фактически выучила гантель вместе с рукой, которая её держит, потому что на обучающих фото гантели почти всегда держат руками. Рука не часть гантели, но для модели связь оказалась полезной. И это тот самый случай, когда высокая точность ещё не говорит, что задача решена так, как задумал человек. Разберёмся, что видит сеть в облаках и почему её внутреннее устройство так тяжело читать.