🧠 BERT жив. UltraBERT показал, что рецепт обучения может быть важнее дополнительных триллионов токенов. Вышли открытые энкодеры на 152 млн и 380 млн параметров с контекстом 32K. Для классификации текста, распознавания сущностей, поиска ответов, оценки качества и retrieval. Главная фишка обучения: • В одних примерах скрывают 5% токенов: это помогает классификации. • В других скрывают 50%: это помогает поиску. • Для каждого режима используют отдельную выходную голову. • Знания модели-учителя на 1,3 млрд параметров передают только примерам с 5% маскирования. Почему выборочно? В экспериментах дистилляция улучшала классификацию, но ухудшала поиск при высоком маскировании. Универсального «учитель всегда делает ученика лучше» не получилось. Ещё один показательный вывод: после 1–2 трлн токенов качество на прикладных задачах выходило на плато, хотя loss продолжал снижаться. По сравнению авторов, версия 380M лидирует на GLUE и BEIR среди сопоставимых энкодеров. Младшая модель достигает уровня RoBERTa-large в классификации при 2,3 раза меньшем числе параметров. Веса, код и лицензия Apache 2.0: https://huggingface.co/collections/dmis-lab/ultrabert Статья: https://arxiv.org/abs/2610.15028

DiarizationLM-Gemma-4-E4B Модель пост-обработки диаризации говорящих от Google. Тонкий дотюн 4B Gemma, который исправляет метки спикеров и снижает ошибки диаризации. Учит модель чинить короткие вставки (1-5 слов), сохраняя акустические якоря в длинных репликах. Статистически значимые улучшения WDER и cpWER на четырех бенчмарках. • Исправляет метки говорящих в расшифровке • Правит границы реплик и «backchannels» (короткие вставки) • Держит личность спикера в длинных монологах без дрейфа • Работает из коробки: подаёшь гипотезу с тегами, получаешь исправленную • 4B параметров (против 8B у старшей версии), Gemma 4 E4B • #GGUF Q4_K_M ~5.3 ГБ, статус — 2-4 битных квантизации • #SOTA на Fisher, Callhome, ICSI, AMI (p<0.0001) Гитхаб HF Демо #diarization #asr

🎤 Вышла на международный уровень вместе с магистратурой ИИ от ФКН ВШЭ Онлайн-магистратура ИИ выходит (а точнее даже возвращается) на международный уровень и вновь делает запуски для студентов со всего мира (спасибо @murr4a, что дравит эту вещь). Не могла пройти мимо этой инициативы и присоединилась к NLP-курсу, который в этом запуске читаем вместе с @greedisneutral и @awe_eu. Сегодня провела свою первую лекцию на курсе. На занятии были студенты со всего глобуса: Мексика, Бразилия, Индия. Читать на такую широкую аудиторию это отдельный вызов и отдельное удовольствие: возможность поделиться знаниями с ребятами со всего мира. А еще отдельный выброс эндорфинов это лекции на английском, по практике которого я сейчас так скучаю. @mashkka_ds #трудовыебудни #преподавание #вшэ #фкн #nlp #ai

Ну вот, подходящий конкурент Jev - GLiNER-2.5 Как уже писал выше их NER в GLiNER-2 я выбрал из десятка моделей для поиска и вычищения персональных данных. Это скорее 100% конкурент JEV, более под операционную часть. Передаешь текст и набор меток прямо в вызове – получаешь ответ. Без промпта, без генерации токенов, один проход. Если по кейсам, то можно прикинуть, что это например: – интент клиента (возврат, отмена подписки, проблема со входом) – роутинг тикетов и писем по отделам – сентимент, включая «mixed», и аспекты отзыва (батарея плохая, экран отличный) – срочность, severity инцидентов, спам, модерация – «нужно ли звать человека» и даже «закончил ли агент задачу» – несколько решений за один вызов: интент + приоритет + нужен ли человек + темы Можно дать метки с описаниями, если название само по себе неоднозначное, и шкалы типа 0–10 для оценок. Бенчмарки (свой датасет fast-decisions, 17 доменов, exact match): – GLiNER2.5-Decide 340M – 60.2% – GLiNER2.5-Decide 1B – 59.6% – Jev – 57.6% – мультиязычная версия 287M – 56.7% То есть обходит без проблем расхайпленный JEV, при этом работает на CPU, лицензия Apache 2.0, можно поставить на любую табуретку у себя. Короче, это уже можно в продакшене у себя использовать. Поставить перед LLM: первичная сортировка входящего потока, быстрое принятие решений, извлечение информации, заполнение метаданных, фильтрация. Гонять коммерческую модель еще и с задержкой до провайдера по интернету будет явно дороже и дольше. https://huggingface.co/fastino/GLiNER2.5-Decide

Технический отчёт DeepSeek-V4.1-Flash — часть 1/2 Разберём технический отчёт DeepSeek-V4.1-Flash. В первой части обсудим архитектуру модели. Главное достижение авторов — экстремальное сжатие KV-кеша. При стандартном для frontier-моделей максимальном контексте в миллион токенов глобальный KV-кеш на один токен составляет 890 байт, что делает инференс даже максимального числа токенов почти бесплатным (менее одного гигабайта в сумме).  В архитектуре DeepSeek-V4.1-Flash каузальные энкодер и декодер, у каждого по 20 слоёв. Энкодер-декодер-архитектура выбрана не случайно: это помогает экономить вычисления. Нижняя половина слоёв формирует глубокое представление префикса, на которое затем аттендится декодер. В случае короткого промпта это позволяет в среднем в два раза сократить стоимость вычислений.  DeepSeek-V4.1-Flash — MoE-модель на 552 миллиарда параметров, плюс 196 миллиардов в Engram. На префилле активируются 8 миллиардов параметров, а на декоде — 16 миллиардов. Размер скрытого представления — 5120; количество аттеншн-голов — 64. Есть sliding window attention, один shared-эксперт и 384 маршрутизируемых. На один токен активируются шесть экспертов.  Кроме того, с самого начала обучения использовались изображения, так что модель — нативно мультимодальная. Изображение проходит через DeepSeek-ViT (32 слоя, 2D-RoPE), далее применяется pixel unshuffle 3х3, MLP-проектор, и всё это перегоняется в текстовый эмбеддинг. Вместо привычной свёртки для отображения пикселей в токены применяется линейный слой, что даёт возможность использовать Muon.  Как работает каждый из компонентов. На префилле энкодер делает полный проход по префиксу. На декоде глобальный KV-кеш проецируется из скрытого представления последнего, двадцатого слоя энкодера. Хидден подаётся не напрямую, а отображается layer-specific-проекциями. Это позволяет экономить на кеше в декодере. Ещё одна важная особенность модели — Compressed Sparse Attention 2 (CSA2) в нескольких режимах, против CSA и Heavily Compressed Attention (HSA) в базовой DeepSeek-V4-Flash. О том, что такое CSA и HSA, мы писали вот тут, а в этом разборе сосредоточимся на режимах CSA2. Всего их три:  — Full Mode — вычисляем полный KV-кеш и делаем полный аттеншн, но оставляем возможность определять важные и неважные токены, имея некие индексы. На части хороших кандидатов аттендимся сразу, а часть — 16 тысяч — передаём дальше.  — Reindex Mode — аттендимся на KV-кеш из Full Mode, выбираем из переданного пула хороших токенов своих кандидатов. — Reuse Mode — переиспользуем Top-K-индексы от Full Mode. Самый частый блок: 15 из 20 и на префилле, и на декоде.  Во второй части продолжим разговор об архитектуре, а также затронем претрейн и посттрейн. Разбор подготовил ❣ Денис Кузнеделев Душный NLP

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

Loop the Loopies! Сегодня обсудим статью, которая посвящена моделям Loopies, построенным на шеринге параметров между разными слоями.  Обычно у трансформерных моделей и свёрточных нейросетей отдельные параметры на каждом блоке, благодаря чему объём вычислений и число параметров масштабируются с глубиной. Это даёт гибкость — каждый блок может выполнять специфические задачи. Но при этом с ростом числа слоёв растёт и количество параметров, а значит, модель становится дороже хранить.  Выходом из этой ситуации может стать переиспользование весов по несколько раз за форвард — шеринг параметров. Так не нужно хранить много параметров, однако блок может принимать распределение данных с разной глубины, что усложняет задачу оптимизации.  Перспективность шеринга первым доказал метод ALBERT. В нём было два механизма: факторизация матрицы эмбеддингов и переиспользование одного трансформенного блока несколько раз. На этом принципе работают looped-модели — hidden state в них прогоняется R раз через один и тот же блок. Число параметров становится меньше, а количество вычислений не меняется.  Рекуррентность имеет и другие преимущества: hidden state проходит несколько шагов улучшения, эффективная глубина растёт без увеличения размера модели. В перспективе число шагов можно адаптировать под сложность запроса — если он простой, то прогонять один раз, а если сложный, то больше. Рекуррентность хорошо показывает себя на алгебраических задачах и задачах, связанных с пазлами. Однако сравнения looped-моделей с не-looped-аналогами были не совсем честными. При том же размере модели делаются R прогонов, а, следовательно, в R раза больше вычислений. Соответственно, и обучать такую модель дольше. В плане оптимальности компьюта looped-модели уступали обычным трансформерам.  Авторы серии Loopie предлагают две модели: Loopie-20B-A2B и Loopie-6B-A0.6B. Архитектурно это Qwen3. В отличие от решений прошлого, здесь не вся модель прогоняется несколько раз, а каждый слой (верхняя схема на изображении 1). В пределах одного блока активации меняются не так сильно, к тому же это проще для чекпоинтинга. Также такой метод даёт потенциально большую гибкость: можно делать разное количество проходов на каждом слое.  Подход layer-loop проще для распределённого обучения, потому что повторения слоя остаются в одном pipeline stage, а параметры градиента могут использоваться локально. В то же время model-loop требует, чтобы вычисления синхронизировались внутри всей модели а первый блок должен уметь обрабатывать один или несколько полных проходов через модель.  Претрейн состоял из двух стадий. Сперва используют датасет Nemotron-CC-v2-HQ, а дальше дообучают на более качественных данных, делая упор на синтетику, STEM, код, математические рассуждения и веб-данные. Так получается базовая Loopie. На неё делают Supervised Pre-Training (SPT). Это похоже на SFT, лосс считается только по target-токенам, однако масштаб — как у претрейна: 2Т токенов. Контекст увеличивают и обучают довольно большими батчами примерно по 128М токенов. SPT, как отмечают авторы, улучшает способность модели к рассуждению.  На RL сначала делают математику, а потом программирование. Используют GSPO, ассиметричный клиппинг и динамическую фильтрацию промптов. Роллаут увеличивают с 32К до 64К.  По бенчам Loopie-20B примерно сопоставима с моделями вроде Qwen3, Nemotron 3 Nano и GPT-OSS (изображение 2). Казалось бы, не слишком большое достижение для 2026 года, однако стоит помнить, что у Loopie намного меньше параметров. Loopie-6B в своей «весовой категории» также показывает себя достойно — особенно в задачах, связанных с математикой (изображение 3). Разбор подготовил ❣ Денис Кузнеделев Душный NLP

Context-1 — поисковый агент, который умеет избавляться от лишнего. Часть 2/2 Продолжаем изучать агент Context-1. В первой части мы рассмотрели, что это вообще такое и какие задачи перед собой ставили авторы. А в этой части поговорим о метриках и обучении. Для оценки качества ответа авторы предлагают использовать четыре метрики: Final answer found (смогла ли модель найти документ с правильным ответом в выдаче), Recall (доля релевантных документов, которые выбрала модель, от общего числа релевантных документов), Precision (число релевантных документов, которые модель отвергла) и FB (среднее гармоническое Recall и Precision; идея авторов в том, чтобы штрафовать модель за отбор нерелевантных документов только под конец обучения). Также предлагают рассматривать Trajectory recall, оценивая качество траекторий и поощряя модель за отбор нужных документов и не награждая чрезмерно за случайное нахождение верного ответа.  На SFT авторы генерировали некоторое количество траекторий с помощью Kimi K2.5. Дальше заводили RLVR на модели gpt-oss-20b с LoRA. Вместо GRPO применяют CISPO — модификацию, которая позволяет лучше бороться с энтропийным коллапсом. Что касается реворда, то здесь на модель накладываются два штрафа: за уменьшение контекста несколько раз подряд и за количество шагов (если их больше 64). В результате модель научилась чаще работать с параллельным вызовом инструментов и лучшему прунингу в сравнении с базовой gpt-oss-20b. А число шагов в траекториях сократилось. С результатами по четырём доменам — веб, финансы, юридическая информация и электронная почта — можно ознакомиться в первой таблице.  Обратите внимание, что Context-1(4x) — это конфигурация, на которой запущено сразу четыре агента, а результаты их выдачи объединены с помощью метода Reciprocal Rank Fusion. Авторы отмечают, что даже в таком случае требуется меньше ресурсов, чем на запуск крупных моделей. Что же касается опенсорсных бенчмарков (таблица 2), то тут оценивалось, есть ли финальный ответ в документах, которые выбрала модель.  В финале авторы отмечают, что им не хватает разнообразия задач — все они представляют собой таски вида «найди что-то в ворохе документов». Также в работе говорится, что потенциально к используемым инструментам можно добавить и тулы для написания кода, и оркестратор. Наконец, предлагается поработать над менеджментом контекста: например, сохранять какое-то минимальное количество информации из выкинутых документов или суммаризировать большие страницы.  Разбор подготовил ❣ Владислав Пыж Душный NLP

Context-1 — поисковый агент, который умеет избавляться от лишнего. Часть 1/2 Авторы сегодняшней статьи заявляют следующую проблему. Когда агент ищет что-то в поиске, то нерелевантные страницы, выданные браузером, всё равно остаются в контексте агента. Чтобы справиться с этим, контекст можно обрезать или суммировать. Ещё одно весьма перспективное направление в этой области — self-editing context, при котором модель сама определяет, что ей нужно для решения задачи и может отбрасывать бесполезные документы. Этот подход авторы статьи и берут за основу своего субагента Context-1, построенного на модели в 20B параметров. В его арсенале есть четыре инструмента. Первый, search_corpus(query), позволяет оценивать релевантность документа: отбирается 50 документов, ранжируются, самые подходящие отправляются модели в рамках доступного бюджета токенов. Инструмент grep_corpus(pattern) проводит поиск с помощью регулярных выражений, read_document(doc_id) нужен, чтобы прочитать документ. Самый интересный из инструментов — prune_chunks(chunk_ids), который даёт модели возможность убрать какие-то фрагменты из контекста с сохранением траектории. После каждого шага модели сообщается, сколько токенов у неё осталось. Когда контекст заполнен наполовину, модель советуют освободить его, — но только на обучении, не на инференсе. После преодоления какого-то порога по токенам, модель начинает получать отбивку о необходимости почистить контекст на каждый запрос вызова инструментов для получения новых документов. В этом случае модель либо должна выдать ответ, либо запустить prune_chunks(chunk_ids). Авторы придумали, как генерировать синтетические данные для RL с возрастанием по сложности. Генерация происходит в пять стадий: Gather supporting documents — сбор сопутствующих документов, которые содержат уникальные факты на основе заданного сида. В статье приводится пример с сидом «Синагоги в Брюсселе», по которому модель собрала факты вроде «Синагоги выполнены в романо-византийском стиле». Generate clues (obfuscated references to facts) — собранные на первом этапе факты встраиваются в одну задачу, загадку, где разные сущности заменены фактами. Так, вместо, собственно, «синагога» в этом тексте будет сказано «религиозные сооружения в романо-византийском стиле». Verify that the task is valid — этап проверки, что в сопутствующих документах есть подсказки, ведущие к ответу. То есть в каком-то из документов должно быть прямо сказано, что «синагога — это религиозное сооружение в романо-византийском стиле». Проверка осуществляется не с помощью LLM, а просто кодом на Python. Optionally, collect distractors — опциональное добавление в базу документов-дистракторов. Важно, чтобы они не только вели модель по ложному пути, но и случайно не содержали правильных ответов. Optionally, recursively chain — опциональная генерация задач, которые связаны с прошлыми задачами. Так получается синта, которую нужно решать в несколько шагов. Во второй части поговорим об обучении и результатах. Разбор подготовил ❣ Владислав Пыж Душный NLP

AgentFold — метод управления контекстом для агентов на длинных задачах На длинных сценариях поиска и анализа веб-агенты либо хранят слишком много сырой информации, либо слишком часто её суммаризируют, что забивает контекст. Авторы сегодняшней статьи предлагают метод AgentFold (GitHub), призванный решить эту проблему, сделав память агента динамической и управляемой самим агентом. Сейчас в веб-поиске используются два подхода. Первый — это ReAct, при котором все действия и решения конкатенируются в конец контекста. Благодаря этому ничего не теряется, но и контекстное окно забивается очень быстро. Второй подход — суммаризация на каждом шаге, однако при этом какая-то часть информации неизменно теряется. Ключевая идея AgentFold — создание активного и динамически пересчитываемого контекста для каждого следующего шага. То есть агент самостоятельно выбирает, что нужно запомнить точно, а что можно суммаризовать. Авторы отмечают, что они вдохновлялись человеческой способностью к осмыслению собственного опыта. В статье предлагается модифицировать и контекст, и то, в каком формате выдается ответ. Контекст должен состоять из следующих элементов: • Question — исходный вопрос; • Tools — доступные инструменты; • Multi-Scale State Summaries — свёрнутые блоки прошлых шагов. Например, шаги с первого по третий представлены одним блоком. При этом свёрнутым может быть и один шаг; • Latest Interaction — последний полный шаг. Суть в том, что все предыдущие действия хранятся в сжатом виде, а последнее — в подробном. Это позволяет меньше загружать контекст. Что касается ответа, то тут модель должна сперва размышлять, а потом делать фолдинг шагов. Он может быть гранулярным (granular) или глубоким (deep). В первом случае схлопывается только последний шаг, а во втором — целая ветка (например, «шаги с четвёртого по девятый»). После фолдинга идёт этап, на котором модель объясняет, почему объединила шаги именно так, как объединила. Наконец, вызываются инструменты и совершаются какие-либо действия. Для обучения всему вышеописанному, авторы брали вопросы из WebSailor и отправляли их во внешние опенсорсные модели (GLM-4.5 и DeepSeek-V3.1), чтобы построить контекст конкретного шага. При этом о том, как генерируются данные, не сообщается. Далее авторы генерировали ответ, выполняли действие, получали ответ от среды и собирали следующий шаг траектории. Проблема в том, что LLM сами не умеют сжимать контекст, что ведёт к ошибкам, галлюцинациям и тому подобному. Неправильные решения авторы отбрасывали, но как — в статье не описывается. Итоговый датасет представляет собой не набор пар «вопрос-ответ», а выборочный набор пар взаимодействия (intersection pairs), удовлетворяющих определённым условиям. На эти пары делается SFT. Согласно результатам замеров, AgentFold помогает снизить нагрузку на контекст к сотому шагу на 91% по сравнению с ReAct. При этом с увеличением числа шагов точность, как сообщают авторы, только растёт. Разбор подготовил ❣ Антон Гырдымов Душный NLP

С тех пор, как я ещё в 2023 выкладывал тьюториал по дообучению моделей NLLB, я был уверен, что их токенайзер основан на алгоритме unigram (ибо так говорила и всё ещё говорит документация на huggingface). И подходил к модификации словаря токенов соответственно Оказалось — там всё-таки BPE. В чём принципиальная разница? Оба алгоритма сначала разделяют текст на «слова» регулярками, а потом каждое слово разбивают на subword tokens. Но Unigram при этом перебирает абсолютно все способы покрыть слово токенами из своего словаря, и выбирает самый вероятный (согласно собственной «недомарковской» вероятностной модели, где токены не зависят друг от друга — отсюда и название). А BPE идёт строго «снизу вверх»: разбивает слово на атомарные единицы (юникодные байты или буквы), а потом рекурсивно склеивает пары соседних токенов в один, если такая замена есть в его словаре. То есть словарь BPE состоит не только из мешка токенов, но и из графа попарных склеек (merges), выстраивающего эти токены из атомов. Это делает словарь BPE несколько расточительным: если там есть какой-то длинный токен, то должна быть и пара более коротких токенов, из которых он склеивается, даже если они не используются ни в каких других комбинациях. Если неаккуратно удалить такие «неиспользуемые» токены из словаря, то другие, полезные токены станут недостижимыми для алгоритма склейки. Если добавить новые токены, но не вывести их из уже используемого графа склеек, то они тоже будут недостижимы. Поэтому если просто пытаться складывать или вычитать словари, как в модели unigram, это может работать очень криво. К примеру: в варианте NLLB, куда я пытался добавлять токены для эрзянского, больше 2к новых токенов оказались недостижимыми и неиспользуемыми. Правильный подход к манипуляции со словарями BPE — работать с деревьями склеек напрямую. При сокращении такого словаря надо обрезать сразу целые ветки графа склеек (ну или только листья), а не произвольные токены. Ну а при его расширении надо делать continued BPE training, то есть образовывать новые токены, склеивая пары уже имеющихся, как мы это делали в проекте OMT (в случае с NLLB, где BPE делается не над байтами, а над буквами в качестве базовых единиц, бывает ещё нужно добавить в словарь новые буквы). Это несложно имплементировать самостоятельно, но если хочется готового решения, могу порекомендовать пакет tokenizer-extension и идущую с ним в комплекте статью Teaching Old Tokenizers New Words: Efficient Tokenizer Adaptation for Pre-trained Models