ML Underhood

Исследователи Яндекса выложили в опенсорс Yambda — датасет на 5 млрд событий

В открытом доступе появился Yandex Music Billion-Interactions Dataset (Yambda) — один из крупнейших в мире датасетов в области рекомендательных систем. В этом посте рассказываем, зачем он нужен и какие у него ключевые особенности.

В последние годы рекомендации вышли на плато по сравнению с более быстро развивающимся областями, такими как LLM. Исследователям недоступны терабайты данных, которые нужны для развития рекомендательных систем, а коммерческие платформы редко делятся данными. Поэтому приходится использовать устаревшие и маленькие наборы. Модели, обученные на таких данных, теряют эффективность при масштабировании.

Существующие доступные датасеты, такие как MovieLens, Netflix Prize dataset, Amazon Reviews, Music4All-Onion, Steam и несколько других имеют ряд недостатков. Например, сравнительно небольшой размер делает их нерепрезентативным для коммерческих масштабов, а фокус на явных сигналах ограничивает полезность для моделирования реальных последовательных взаимодействий.

Чтобы решить эти проблемы и дать исследователям больше возможностей для разработки и тестирования новых гипотез в рекомендациях, исследователи Яндекса выложили в опенсорс свой датасет Yambda.

Ключевые особенности Yambda:

— Содержит 4,79 млрд обезличенных взаимодействий пользователей с музыкальными треками в Яндекс Музыке.
— Есть три версии: полная (5 млрд событий) и уменьшенные (500 млн и 50 млн
событий).
— Включает два основных типа взаимодействий: неявную обратную связь (прослушивания) и явную обратную связь (лайки, дизлайки, анлайки и андизлайки).
— Для большинства треков есть нейросетевые вектора, сгенерированные с помощью свёрточной нейронной сети (CNN), что позволяет учитывать некоторые характеристики музыкальных треков.
— Включены анонимизированные признаки метаданных треков, такие как длительность, содержание вложений, исполнитель и альбом.
— Каждое событие помечено флагом is_organic, который позволяет различать органические действия пользователей и действия, вызванные рекомендациями алгоритма.
— Все события имеют временные метки, что позволяет проводить анализ временных последовательностей и оценивать алгоритмы в условиях, приближённых к реальным.
— Данные распределены в формате Apache Parquet, что обеспечивает совместимость с распределёнными системами обработки данных (например, Hadoop, Spark) и современными аналитическими инструментами (например, Polars, Pandas).

Методы оценки

В отличие от метода Leave-One-Out (LOO), который исключает последнее положительное взаимодействие пользователя из обучающей выборки для предсказания, Yambda-5B использует глобальный временной сплит (Global Temporal Split, GTS). Преимущество GTS в том, что он сохраняет временную последовательность событий, предотвращая нарушение временных зависимостей между тренировочным и тестовым наборами данных. Это позволяет более точно оценить, как модель будет работать в реальных условиях, когда доступ к будущим данным ограничен или невозможен.

Вместе с датасетом представлены baseline-алгоритмы (MostPop, DecayPop, ItemKNN, iALS, BPR, SANSA, SASRec). Они служат отправной точкой для сравнения эффективности новых подходов в области рекомендательных систем.

Используются следующие метрики:

— NDCG@k (Normalized Discounted Cumulative Gain) — оценивает качество ранжирования рекомендаций.
— Recall@k — измеряет способность алгоритма генерировать релевантные рекомендации из общего набора возможных рекомендаций.
— Coverage@k — показывает, насколько широко представлен каталог элементов в рекомендации.

Датасет и код для оценочных бейзлайнов уже доступны на Hugging Face, а статья — на arXiv.

Статью подготовили ❣ Александр Плошкин, Владислав Тыцкий, Алексей Письменный, Владимир Байкалов, Евгений Тайчинов, Артём Пермяков, Даниил Бурлаков, Евгений Крофто, Николай Савушкин

@RecSysChannel

В опенсорсе появился датасет Yambda, который поможет исследователям и разработчикам по всему миру тестировать и совершенствовать новые алгоритмы рекомендаций. Все подробности читайте в посте.

Как Яндекс Браузер извлекает контент веб-страниц для пересказа? Часть I

Представьте, что вам нужно быстро проанализировать текст с десятка веб-страниц. На помощь придет функция краткого пересказа в Яндекс Браузере. Здесь — и не только здесь — работает суммаризация текста. Но возникает вопрос: что попадает в качестве входных данных в LLM, занимающуюся суммаризацией? На него в двух постах ответит Михаил Катунькин, старший ML-разработчик в Яндекс Браузере. В первой части речь пойдёт об общей идее и реализации, а во второй — об обучении модели.

Общая идея

Самое очевидное решение — взять HTML-код страницы. Его проблема в том, что верстка содержит в себе много лишней текстовой информации, которая «засорит» и сильно увеличит контекст модели: теги, скрипты, стили. Всё это приведёт к ухудшению качества пересказа, большему времени работы модели и удорожанию инференса.

Значит, следующий шаг — извлечь только текстовую информацию. Это улучшит ситуацию, но в контекст модели по-прежнему будет проникать много лишнего: реклама, меню, комментарии. А из-за того, что модель потеряет информацию о структуре страницы, в пересказ начнёт попадать, например, содержание статей из блока рекомендаций похожего контента.

Можно использовать разные эвристики, чтобы извлекать не весь текст страницы, а только полезный. Такой подход, например, используется в режиме чтения в браузере Однако из-за разнообразия верстки сайтов эта техника не является универсальной, нуждается в переподборе эвристик с течением времени, даёт плохое качество извлечения текста на определённых доменах.

Мы решили извлекать основной контент страницы при помощи ML-модели. А затем использовать информацию из HTML-кода для задания структуры текста: заголовков, подзаголовков, ссылок, выделений.

Важный нюанс: пересказ должен работать быстро даже при медленном интернете. Передавать тяжелые HTML-страницы целиком на серверы Яндекса было бы плохим решением. Поэтому модель следовало сделать легковесной, чтобы она работала непосредственно на устройстве пользователей.

Реализация

HTML представляет собой дерево тегов. Блоки с текстом на странице — это листья в дереве. Будем для каждого листа принимать решение: брать его или нет в конечный текст. В качестве бинарного классификатора возьмем Catboost.

Классификация осуществляется на основе множества статистик, посчитанных при обходе дерева: по тегам, атрибутам тегов, текстам. Существенное улучшение качества даёт следующий трюк: блоки с текстом классифицируется не независимо, а группами с одинаковым путём из тегов и атрибутов от блока до корня. При этом для хорошего качества извлечения текста модели достаточно информации о структуре разметки и базовых статистик по текстам.

Использование семантических вектор-признаков, посчитанных по текстам, заметного улучшения качества суммаризации не даёт. Поэтому в продакшен-версии от них решили отказаться ради скорости работы модели.

Было важно оптимизировать код подсчёта признаков для модели, из-за того, что деревья тегов могут содержать сотни тысяч узлов. В итоговой версии код реализовали на C++. Он работает 40 мс на одно извлечение в 90 перцентили. Для сравнения, код на JS с эвристиками из режима чтения в Mozilla работает 1,125 с в 90 перцентили. Для достижения этого результата, в частности, мы оптимизировали динамические выделения памяти, а также удалили из набора признаков сложные в вычислении, но не столь значимые.

Из HTML-дерева с проклассифицироваными листьями уже можно получить очищенный текст в формате markdown. Для этого по дереву идёт обход в глубину, собирающий текст из листьев, прошедших порог классификации, и учитывающий наличие тегов с заголовками, ссылками, выделениями и прочим.

ML Underhood

Как LLM помогают анализировать ответы в опросах

Вы когда-нибудь задумывались, как исследователи анализируют результаты опросов? С закрытыми вопросами, у которых есть несколько вариантов ответа, всё достаточно просто — алгоритмы суммаризации существуют давно. Но что насчёт анализа открытых вопросов, на которые респонденты отвечают в свободной форме? Это кропотливый и изнурительный труд, ведь приходится вручную обрабатывать сотни, а то и тысячи ответов.

К счастью, LLM может помочь и здесь. Ведущий исследователь интеграции ИИ и UX в Поиске Яндекса Алексей Шипулин рассказал нашему каналу о созданном им телеграм-боте, который помогает анализировать ответы на открытые вопросы и экономит массу времени.

«Под капотом» у бота сразу несколько моделей. Первая — помощнее — читает все ответы, ищет близкие по смыслу и составляет некоторое количество категорий. Дальше в дело вступает модель послабее, которая тоже знакомится с ответами и распределяет их по созданным ранее категориям. Чтобы процесс был прозрачнее для исследователя, модель комментирует каждый ответ, объясняя, почему он попал в ту или иную группу. Тут важно ещё и то, что LLM знают не только ответы, но и вопросы — это положительно сказывается на категоризации.

Казалось бы, на этом можно и заканчивать, но нет. Вторая модель может совершать ошибки, относя ответ не к той категории, где ему следует быть. Проверкой занимается третья LLM — она оценивает ответы на соответствие категории по трёхбалльной шкале. Те ответы, которые получили оценку «два» или ниже, снова проходят через второй этап и распределяются по другим категориям. Потом опять проверка и опять перераспределение, если нужно.

На финальном этапе ответы распределяются по частотности. Самые редкие алгоритм предлагает не относить в отдельные категории, чтобы не размывать статистику. А делать это или нет — решает исследователь.

Весь процесс, на который человек мог бы убить целый день, занимает не более трёх минут — и на выходе получается наглядный график и таблица с ответами. Всего же с момента запуска в октябре телеграм-бот сэкономил исследователям Яндекса уже 12 лет!

ML Underhood

Как LLM помогает быстрее находить товары на складе Маркета

Часто на складских полках рядом оказываются очень похожие товары. Это приводит к тому, что при сборке заказов товары приходится долго искать: сборщик берёт не то, смотрит, кладёт обратно, продолжает искать нужное. На таких «плохих» полках, где лежат визуально похожие товары (например, шторки одного цвета, но разных моделей) шанс вытащить искомое с первого раза не самый большой. В среднем на поиск нужной позиции теряется 4 секунды. А если таких операций полмиллиона в день, масштабы становятся внушительными.

Екатерина Трофимова, менеджер продуктов в команде логистики Маркета, рассказала, как с помощью LLM получилось оптимизировать хранение товаров на складе с учётом их похожести для более быстрого поиска.

До начала эксперимента у команды не было системного признака схожести товаров — их просто складывали, как придётся. Попробовали сформулировать фановую гипотезу: если системно понимать, какие товары похожи, можно оптимизировать процесс.

Мы применили технологию векторизации текста к названиям товаров, чтобы получить уникальный вектор, описывающий каждый товар. С её помощью считается и сравнивается похожесть того, что кладётся на полку, и того, что уже лежит на ней. Все наименования и метаданные товаров прогнали через YandexGPT и получили вектора, которые легко сравнить и посмотреть косинусную близость между ними. Если значение выше порогового — считаем, что товары слишком похожи и не даём класть их рядом. Если ниже — можно класть на одну полку.

Пример на картинке. Органайзеры для специй разных производителей мы не дадим положить вместе, потому что их вектора очень близки друг к другу. Сменный блок и тетрадь можно положить рядом, потому что у них безопасное пороговое значение, хоть эти вектора тоже находятся относительно близко друг к другу. Каша с черникой могут отправиться как к органайзерам, так и к бумажной продукции.

Помимо LLM, пробовали использовать другие решения, например расстояние Левенштейна (метрика для измерения различий между двумя строками) — но это не сработало. В нашем случае названия товаров могут сильно различаться по форме, даже если они описывают один и тот же продукт, поэтому расстояние Левенштейна будет большим для схожих товаров. GPT справляется с задачей лучше: вектора для таких товаров близки, даже если названия выглядят совсем по-разному.

В среднем, новый подход даёт выигрыш в 2,5 секунды на поиск товара, что приводит к экономии около 2 миллионов рублей в месяц на масштабе всех фулфилментов Маркета. Точность применения метода мы субъективно оцениваем в 7 из 10 — можно было выиграть ещё 1,5 секунды, за счет более агрессивного значения схожести товаров, но чтобы не ловить упячки в духе «кастрюля схожа с вилкой, не клади их вместе», мы ограничились безопасным значением.

Проект работает в проде с июня 2024 года. Мы внедрили его на бэкенде WMS (системы управления складом), и в течение 30 дней после внедрения увидели, что эффект стабильно сохраняется.

Вся реализация решения от проверки гипотезы до внедрения в прод заняла один человеко-месяц разработки. Это подтверждает гипотезу, что не всегда нужно строить космолет — иногда можно сделать быстро, просто и полезно.

Можно сделать вывод, что LLM — это не только генерация, классификация и другие привычные задачи. Иногда стоит взглянуть на модель под другим углом — например, в этом случае её использовали как числовой преобразователь и нашли решение бизнес-задачи.

ML Underhood

Как Алиса видит мир

Недавно Алиса научилась распознавать объекты, показанные через камеру смартфона. В основе этой фичи лежит мультимодальная нейросеть (Visual Language Model, VLM), которая уже используется в Поиске по картинкам, Умной камере и Нейроэксперте. На Хабре вышла большая статья о том, как создавали эту модель, а здесь мы кратко расскажем главное.

VLM основана на семействе YandexGPT 5. Она состоит из LLM и картиночного энкодера. VLM получает на вход изображение и произвольную текстовую инструкцию и предсказывает текст — ответ на пользовательский запрос.

Датасет для претрейна мультимодальной модели состоял из документов, содержащих изображения, текстовых документов, пар «картинка-текст» и OCR-данных. Далее в обучении шла стадия SFT, а за ней — DPO.

VLM адаптировали в Алисы. Её зрение работает в двух режимах: можно загрузить изображение в чат, а можно включить камеру и показывать ассистенту то, что вы видите. Когда Алиса получает изображение и запрос, последний отправляется в рефразер, который адаптирует вопрос для поиска в интернете. Например, если пользователь просто показывает Алисе булгур и спрашивает «Сколько варить?», рефразер превращает вопрос в «сколько варить булгур».

Далее запрос отправляется в интернет. Модель собирает всю нужную информацию и выдаёт пользователю ответ (15 минут, если что).

А более подробно о том, как устроена VLM, а также об экспериментах и трудностях, которые возникали по ходу обучения, читайте на Хабре.

ML Underhood

Синхронный перевод видео в Яндекс Браузере

Перевод видео в Яндекс Браузере появился ещё в 2021 году. Сегодня компания представляет новую версию этой технологии, способную сохранять тембр и интонации оригинального голоса. А сам перевод стал точнее благодаря YandexGPT. В статье на Хабре вы можете почитать все подробности о том, как устроен инструмент, а здесь расскажем коротко.

В основе технологии синтеза речи лежит модифицированная опенсорс-модель Tortoise-TTS. Сама по себе она выдаёт результаты хорошего качества, почти неотличимые от человеческой речи. Однако есть несколько проблем, которые не позволяют использовать модель в продакшене.

Одна из них связана с качеством zero-shot-синтеза, то есть генерации аудио тем же голосом, что и в аудиопромпте. Результат может быть не похожим на исходник, а при переносе тембра с английского на русский появляется акцент.

Чтобы исправить это, в Яндексе использовали фонемное представление текста и создали общий алфавит для английских и русских фонем. Благодаря этому произношение модели стало более правильным. Для моделирования тембра голоса внедрили биометрические эмбеддинги и контролировали качество речи с помощью метрики UTMOS. А проблему акцента при переводе с английского на русский решили с помощью синтетического датасета, где голос одного и того же человека представлен на двух языках.

Ещё один недостаток Tortoise-TTS — низкая скорость инференса, из-за которой модель и получила своё название. В Яндексе оптимизировали её архитектуру, уменьшили количество итераций в диффузионной модели и применили технику дистилляции знаний. Благодаря этому, генерация ответа происходит в реальном времени.

SBS-тестирование показало, что новый перевод видео в Яндекс Браузере значительно превосходит решение ElevenLabs: 62% побед против 34%. Что касается исключительно озвучивания, то есть превращения текста в речь, то здесь система Яндекса также впереди: 46% против 42%.

Speech Info

В Яндекс Браузере запустилась новая версия синхронного перевода видео. А мы в канале Speech Info кратко рассказали, как она работает.

Что-то кончается, что-то начинается

Так писал Анджей Сапковский. У нас заканчивается конференция ICLR и начинается — череда подробных обзоров по следам мероприятия. А сегодня — несколько вайбовых видео и все материалы, которые мы писали об ICLR 2025:

— Постеры, на которые стоит обратить внимание. Часть I.
— Постеры, на которые стоит обратить внимание. Часть II.
— Лучший постер второго дня с котиками.
— Пляшущие роботы и статьи от команды Yandex Research.

Оставайтесь с нами! А ещё больше материалов с ICLR вы найдёте в других наших каналах:

— Душный NLP
— Speech Info
— Рекомендательная
— CV Time

#YaICLR

ML Underhood

Подборка постеров с ICLR 2025

Продолжаем рассказывать о самых интересных статьях с конференции и показываем один весьма экстравагантный стенд.

Revisiting Nearest Neighbor for Tabular Data: A Deep Tabular Baseline Two Decades Later

Авторы улучшили NCA (непараметрический метод на основе nearest neighbour) простыми нейросетями и обогнали бустинги и TabularDL на многих задачах.

Результаты:
— На наборе задач мульти-классификации их метод оказался лучшим на 20% задач, что на 7 процентных пункта больше, чем с Топ-2 подходом (у TabR 13%)
— Для бинарной классификации и регрессии результаты, скорее, сравнимы с текущими SOTA.
— Применялись на задачах с сотнями (но не тысячами) фичей.

Приёмы:
— Отказ от LBFGS в NCA в пользу SGD для обучения проектора.
— Стохастика и по батчам, и по соседям — сэмплируются случайные группы соседей одного класса/
— Заменили линейную проекцию из NCA на нелинейную. Используют простую нейросеть (2-3 слоя, BN, ReLU)/
— От предсказания жёстких меток класса перешли к вероятностям за счёт softmax, чтобы сгладить задачу оптимизации.

AnoLLM: Large Language Models for Tabular Anomaly Detection

Ищем аномалии в табличных данных.

— Составляем из данных корпус текстов вида «фича Х равна Y, ...».
— Файнтюним.
— Оцениваем вероятность встретить значение фичи при условии значений других фичей, считаем NLL.

Достаточно маленьких моделей (130М — 1,7B).

FreDF: Learning to Forecast in Frequency Domain

Для прогноза временных рядов авторы предлагают дополнительно к предсказанной и GT-последовательностям применять FFT и считать ещё один лосс между ними. Говорят, что получается неплохо.

А на последнем изображении тот самый экстравагантный стенд. Выглядит душевно!

Постеры заметили ❣ Кирилл Никоров, Пётр Вытовтов, Константин Бабалян

#YaICLR

ML Underhood

Танцуем в предвкушении, как этот милый робот-пёс

Уже завтра на полях ICLR два постера от команды Yandex Research!

C 10:00 по Сингапурскому времени можно будет ознакомиться со статьёй TabReD (Hall 3 + Hall 2B #348).

С 15:00 — пообщаться с авторами TabM (Hall 3 + Hall 2B #323).

Приходите посмотреть и познакомиться!

⚡️Внимание!

Обнаружен лучший постер второго дня ICLR 2025!

Крутые постеры с конференции ICLR 2025

Наши инженеры вовсю изучают постеры на мероприятии и делятся самыми любопытными статьями.

TempMe: Video Temporal Token Merging for Efficient Text-Video Retrieval

Авторы предлагают хитро дообучить Clip для ускорения поиска по видео. Результаты:

— в 1,5-3 раза снижается количество вычислений для инференса, в зависимости от базового метода;
— качество ранжирования в сером плюсе

Приёмы:

— Используется LoRA для дообучения энкодера.
— Применяется специальная процедура усреднения похожих токенов, как по временной, так и по пространственной размерностям.
— Для улучшения такого усреднения используются дополнительные позишн-эмбеды.
— За счёт этого снижается количество обрабатываемых токенов и возникают более явные зависимости между кадрами по времени.

LeanVec: Searching vectors faster by making them fit

Авторы предлагают решение для ускорения процедуры поиска. Идея очень понятная и, возможно, много где реализована.

Собираем выборку запрос-документ, вычисляем матрицы A и B, преобразующие данные в меньшую размерность.
2. На этапе построения базы вычисляем Bx — получаем базу документов меньшей размерности и строим ANN (quant).
В процессе поиска делаем Aq, на основе которой из графа ищем ближайшие документы, а после уточняем кандидатов на этапе реранкинга по оригинальным векторам.

В статье приводят результаты экспериментов показывающие, что меньшая размерность может быть в 3-4 раза меньше исходной без значимой потери качества поиска. Плюс, полученное преобразование устойчиво к OOD.

Странно, что авторы не сравнили своё решение с подходом, использующимся при обучении многих SOTA-эмбеддингов: Matryoshka Representation Learning. В таком случае в модель уже встроены низкие размерности и не нужно ничего дополнительно обучать. По словам авторов, SOTA-библиотека от Intel, в которую они встроились, всё еще имеет всего 150 звезд на Github, так что теоретически идеи хорошие, а вот использовать ли их на практике — об этом стоит 10 раз подумать и самому оценить.

DeLLMa: Decision Making Under Uncertainty with Large Language Models

Авторы учат LLM принимать решения в условиях неопределённости. Они предлагают ввести лист состояний мира, который можно вывести из контекста и к которому, попарно для каждого state-action выводится функция полезности.

Постеры заметили ❣ Кирилл Никоров, Алексей Спасёнов, Александр Воронцов

#YaICLR

ML Underhood

Вот-вот стартует конференция ICLR 2025, и ML-инженеры из Яндекса, которые будут освещать мероприятие для вас, уже высадились в Сингапуре. Следите за новостями!

От PyTorch к MONAI: опыт команды Yandex Cloud и ШАДа в медицинском AI

Разбираем интересный кейс из области медицины. В проекте по распознаванию редкой патологии spina bifida на УЗИ команда ML-инженеров из Школы анализа данных и Yandex Cloud приняла неожиданное решение. За неделю до релиза они полностью переписали пайплайн на MONAI — библиотеке для медицинского AI от NVIDIA. Дмитрий Сошников, выступивший ментором проектной команды, рассказал, почему стандартных инструментов PyTorch оказалось недостаточно, как MONAI упростила работу и какие модели команда планирует выложить в опенсорс.

Для обучения нейросети инженеры использовали датасет из 6 тысяч обезличенных УЗИ-снимков беременных женщин. Данные собрали и разметили специалисты НМИЦ имени Кулакова. Команда Yandex Cloud и студенты ШАДа построили архитектуру решения, включающую несколько нейросетей для поиска и классификации патологий. С помощью датасета студенты обучили модели и создали веб-интерфейс для врачей. Проект реализовали на платформе Yandex Cloud с использованием инструмента машинного обучения полного цикла Yandex DataSphere.

Выше можно сравнить два снимка (слева — без патологии, справа — с вероятностью патологии 83%) и получить представление о том, как сложно увидеть различия невооружённым глазом.

Изначально проект написали на «голом» PyTorch без специализированных медицинских библиотек. Пайплайн состоял из стандартных этапов:

— предобработки изображений;
— детекции области интереса с помощью нейросети YOLO;
— фильтрации снимков по качеству;
— поиска признаков патологии на хороших изображениях.

Подход работал, но оказался сложным для поддержки: разобраться в кастомных скриптах было непросто — особенно новым участникам команды или внешним специалистам. Поэтому когда стало ясно, что проект будет опубликован в опенсорсе и получит развитие, решили перейти на MONAI.

Переписывание всех частей пайплайна заняло неделю: сначала перенесли загрузку данных, затем — аугментации, потом — обучение и валидацию моделей. Особенно полезной оказалась аугментация для ухудшения качества снимков, которая имитировала реальные особенности УЗИ-аппаратов. Также пригодились готовые функции потерь для борьбы с дисбалансом классов и стандартные медицинские метрики. Кроме того, в MONAI есть встроенные инструменты интерпретации моделей, такие как Grad-CAM, что особенно важно для медицины: сегодня интерпретируемость моделей обязательна по этическим нормам.

Переход дал прирост сразу по нескольким направлениям. В первую очередь, улучшилось качество моделей — за счёт более разнообразных и реалистичных аугментаций. То же ухудшение изображений дало прирост точности на 2–3 процентных пункта. Также сократился объём кода и повысилась его читаемость: любые действия можно отследить через документацию MONAI, а не разбираться в кастомных скриптах.

Команда планирует выложить обученные модели в опенсорс в рамках MONAI Model Zoo — библиотеки предобученных моделей для медицины. Сейчас в разделе нет решений для ультразвука, и команда хочет закрыть этот пробел. Также разработчики готовят пайплайн для сбора новых данных, их разметки и дообучения моделей, чтобы специалисты НМИЦ Кулакова могли сами обновлять решение в будущем. Благодаря этому наработки можно будет использовать и в других медицинских задачах.

В заключение ещё раз напомним, что проект реализовывали выпускники ШАДа. Набор в Школу анализа данных Яндекса открыт до 5 мая. Если хочется своими руками создавать проекты, которые меняют индустрию и мир, — самое время подать заявку.

В подготовке поста участвовали: главный разработчик проекта Владимир Корсунов и руководитель проекта со стороны Yandex Cloud Евгений Попов.

ML Underhood

Как устроена модель исправления ошибок в нейроредакторе Яндекс Браузера — часть II

Продолжаем говорить о модели исправления ошибок, которая работает «под капотом» нейроредактора в Яндекс Браузере. В прошлой части ML-разработчик Никита Авдосев рассказал о качестве исправления и работы с промптом, а сегодня речь пойдёт о перфомансе.

Для ускорения генерации в компании прибегли к методу спекулятивного декодирования. Суть его заключается в использовании компактной «черновой» (draft) модели, которая предлагает варианты продолжения цепочек токенов. Основная модель проверяет их и выбирает одну с помощью стохастического алгоритма выборки.

Существует несколько подходов к спекулятивному декодированию, а в Яндексе остановились на одном из самых популярных — EAGLE. Он предполагает дообучение небольших голов поверх основой модели. Гипотезы при этом генерируются в виде дерева, а не списка, благодаря чему повышается точность принятия токенов.

В качестве эксперимента инженеры Яндекса решили попробовать метод на модели исправления грамматических ошибок в русскоязычных текстах. Выбор был сделан не случайно — это одна из самых широко используемых моделей в Браузере, ежедневно к ней обращаются более 50 тысяч человек.

Чтобы обучить EAGLE предсказывать токены быстрее, чем их придумает оригинальная модель, требуется много текстов. В Яндексе использовали 250 тысяч текстов из логов пользователей. Позже попробовали обучить на более чем миллионе текстов, но, к сожалению, это не улучшило результат.

Затем начали тестировать новую конфигурацию для инференса: подбирать количество предсказываемых токенов перебором. Остановились на предсказании четырёх токенов. Это золотая середина, после которой ускорения не происходило, а местами даже увеличивалась задержка.

Благодаря EAGLE время генерации текста сократилось более чем в два раза. Теперь она в среднем занимает меньше секунды, что в контексте LLM — почти моментально.

Для ускорения моделей, которые работают с промптами пользователей, применяли FP8-квантизацию. Её отличительная особенность — квантизация не в целые, а в вещественные числа. Подход позволил добиться ускорения на 15% по сравнению с методом SmoothQuant, использованным ранее.

ML Underhood

Алиса теперь понимает английский — и делает это без ущерба для русского. В колонках и чате заработал билингвальный ASR, а вместе с ним — сценарии для практики английского.

В нашем новом канале @speechinfo — подробности от команды, которая это реализовала. Подписывайтесь, чтобы быть в курсе свежих разборов на тему аудио и ML!

Билингвальный ASR — уже в станциях и чате с Алисой

Мы с хорошими новостями — теперь Алиса знает два языкаа: русский и английский! При этом распознавание русского не пострадало, а стало даже лучше. Обновлённая Алиса и поддержит диалог с носителем, и поможет улучшить навыки новичка. Мы ликуем, пользователи в восторге, а вот репетиторы и всем известная сова немного грустят.

Евгений Ганкович, руководитель группы ASR, рассказал, с какими вызовами столкнулась команда:

— Необходимо было обучить модель, которая способна работать с новым языком, при этом критически важно было не просадить качество на русском.
— Домен английского для русскоговорящих пользователей специфичен и не решается с помощью открытых данных.
— End-of-utterance (EOU) по многим причинам работает у англоговорящих пользователей иначе.
Разберём, почему нужно было создавать билингвальную модель, а не обучать две отдельные.

Сложность решения в том, что заранее неизвестно, на каком языке поступит запрос: пользователь может начать на русском, а продолжить на английском или наоборот.

В теории можно использовать классификатор: задан запрос, система определяет язык и направляет его в соответствующую модель. Но чтобы точно определить язык, придётся подождать несколько секунд. К тому же такая система сложнее в поддержке и плохо справляется со смешанными языками (см. «смотря какой fabric, смотря сколько details»).

Выходит, что разумный путь — развивать текущий русскоязычный стек до двуязычного и использовать одну модель, которая инкапсулирует логику выбора языка.

Однако и здесь есть подводные камни. Даже незначительное ухудшение распознавания на русском негативно скажется на пользовательском опыте. Поэтому новую логику в модель нужно добавлять осторожно. Причём улучшения вносятся в две ключевые части голосового стека:

- End-of-utterance (EOU) — модель на основе аудио и паршального распознавания, которая определяет, когда пользователь закончил говорить.
- E2E Seq2Seq на базе трансформеров — модель распознаёт завершённый фрагмент речи на русском или английском языках.

Чтобы улучшить эти две компоненты, нужны данные. Начать можно с открытых — но это другой домен: и акустика, и пользователи отличаются. Поэтому мы привлекли отдельных людей для создания более подходящих нам данных. Так собрали рабочее решение, но не сразу получили нужное качество.

Следующим шагом провели тесты на сотрудниках Яндекса, которые использовали колонку с раскатанной технологии. На этой стадии смогли собрать ошибки, необходимые для улучшения модели. Группы, на которые раскатывали технологию, росли по мере улучшения модели, а мы всё тоньше настраивали модель.

По мере появления данных мы проводили эксперименты с обеими моделями, подбирая датамиксы и гиперпараметры тренировок. И в какой-то момент достигли качества для полноценного распознавания целевых запросов на английском. Интересно, что в этих экспериментах получилось немного улучшить качество русского, так что исходную задачу даже перевыполнили.

Оставалось разобраться с EOU. Здесь были сложности из-за режима «тьютора», в котором можно вести диалог с Алисой. Пользователи сценария могут делать паузы, растягивать слова, и в таких случаях обычная модель может преждевременно обрезать речь. Дослушивать мы тоже не можем — это может повлиять на другие компоненты и ответы Алисы сильно замедлятся.

Решение крылось в добавлении в пайплайн EoU более робастной и стабильной модели, способной учитывать паузы и длительность речи. Хотелось бы рассказать о технологии подробнее, но для этого потребуется описать весь пайплайн распознавания — если вам интересно, дайте знать в комментариях.

В итоге мы получили результат, который стал важной частью большого релиза:

— Голосовой набор сообщений на английском языке в чате и колонке;
— Сценарий «тьютор» на колонке: пользователи могут вести диалог с Алисой, получать фидбек и переводить текст голосом.

Зовём протестировать, что у нас получилось: попробуйте поговорить с Алисой на английском или скажите: «Алиса, давай практиковать английский».

Евгений Ганкович ❣ Специально для Speech Info

Как устроена модель исправления ошибок в нейроредакторе Яндекс Браузера — часть I

В конце сентября в Яндекс Браузере запустили нейроредактор — это инструмент, который исправляет ошибки в тексте, делает его более читабельным и грамотным. С момента релиза функциями нейроредактирования в Браузере воспользовались с 18 миллионов устройств.

Сегодня ML-разработчик в Яндексе Никита Авдосев расскажет о модели исправления ошибок, которая работает «под капотом» нейроредактора. В первой части разбора поговорим о качестве исправления ошибок и работы с промптом. А во второй — о перфомансе.

Качество исправления ошибок

Предполагалось, что модель для исправления будут использовать с целыми текстами или их фрагментами. Сценарий такой: вы выделяете текст, а на выходе получаете скорректированный вариант без опечаток, с правильными окончаниями и корректно расставленными знаками препинания. Поэтому модель обучали на целых текстах, в исправлении которых LLM показывала себя хорошо.

Однако на практике оказалось, что весьма популярен и другой сценарий — выделить только одно слово с ошибкой и отправить его. Это логично, если слово подчеркнул браузер, но изначально инженеры не учли такого варианта.

Проведенные инженерами проверки показали, что в 41% случаев модель исправляла слово неверно либо не исправила вовсе, потому что у неё не было контекста. Результат весьма сомнительный, поэтому инженеры решили исправить эту недоработку. После всех улучшений модели доля ошибок в коррекции коротких текстов и отдельных слов сократилась до 16%.

Можно задаться вопросом: «А 16% — это много или мало?» Для сравнения, в Яндексе замерили, как хорошо срабатывает «опечаточник» — отдельный механизм внутри Браузера, который отвечает за подсветку неправильно написанных слов, когда вы печатаете, и предлагает варианты исправления (если достаточно в них уверен). Это не LLM, а алгоритм, который обращается к словарю. Задача непростая, но сейчас «опечаточник» отлично справляется с 75% ошибок. Значит, в этом плане модель превосходит решение, которое давно себя зарекомендовало.

Качество работы с промптом

В момент выхода нейроредактора наиболее важной новой фичой для разработчиков была возможность работы с промптами. Чтобы можно было поставить какую-то задачу — например, переписать текст так, как будто его автор бандит или сократить текст до двух абзацев — и нейросеть постарается её выполнить, в значительной мере опираясь на предложенный текст.

После релиза в Яндексе учли реальные пользовательские сценарии и обновили модель, сделали больший акцент на популярные задачи. Для этого пришлось обновить датасеты для обучения и замеров.

Однако при таком подходе, когда упор только на популярное, из виду пропадает «хвост» — редкие, нечастотные запросы, которые составляют 15-20% от общего числа. Однако и на таких важно фокусироваться, потому что именно на их основе можно почувствовать реальную «умность» моделей

И если способ измерения качества на «хвосте» более-менее понятен, то с вопросом дообучения дела обстоят сложнее. Ведь задачи в большинстве своем уникальные, креативные и не всегда очевидно сформулированы — вдобавок их мало. Научить модель чему-то на основе одного примера почти невозможно. Да, она увидит пример, но вероятность того что в будущем она начнёт решать подобные задачи хорошо крайне мала.

Поэтому инженеры компании сфокусировались на двух направлениях:

— генерализация — способность модели решать разные задачи, в том числе те которые раньше не видела. Для этого нужно увеличивать разнообразие задач и их формулировок;
— создание синтетических данных. Речь об обучающих примерах, сгенерированных более крупными моделями.

За счёт синтетики инженеры сумели количественно и качественно расширить хвост креативных запросов. В датасет из текстов и промптов добавили примерно 5 тысяч примеров. И теперь запросы вроде «перепиши как гопник» стали работать креативнее, чем раньше.

ML Underhood

YandexGPT 5 Lite Instruct теперь в опенсорсе 🎉

В феврале в открытый доступ вышла Pretrain-версия, а сейчас очередь дошла и до YandexGPT 5 Lite Instruct. Это модель на 8 миллиардов параметров с размером контекстного окна в 32К токенов.

О претрейне мы уже писали вот тут, а алайнмент аналогичен тому, через который проходит YandexGPT 5 Pro. На этапе SFT концентрировались на сложных запросах, а также методах фильтрации и ранжирования данных. В рамках RLHF комбинировали RL-подходы, которые дают лучшие результаты: DPO, LogDPO и PPO. Подробнее об этом читайте на Хабре.

По результатам внутреннего слепого попарного сравнения (side-by-side) новая модель YandexGPT 5 Lite превосходит Qwen-2.5-7B-instruct в 62% случаев и не уступает GPT-4o mini в решении стандартных задач сервисов Яндекса. Показатели бенчмарков можно посмотреть в таблице.

А ещё обновили лицензию: теперь можно использовать модель не только в некоммерческих целях, но и в коммерческих до 10 миллионов выходных токенов в месяц. Если ваши объёмы выше, напишите на почту, указанную в тексте лицензии.

Модель доступна на Hugging Face. Там же есть и квантизованная версия с поддержкой GGUF. YandexGPT 5 Lite Instruct совместима с llama.cpp и Ollama.

ML Underhood

Как ML рассаживает деревья в Яндекс Картах

Год назад в Яндекс Картах в Москве и Петербурге появились трёхмерные деревья, которые добавляют реалистичности и помогают пользователям лучше ориентироваться на местности. В этом посте Стас Лебедев, разработчик группы AI-картографирования, рассказывает, как устроен ML, который рассаживает деревья в Картах.

Разработанная модель умеет три вещи: определять деревья на аэросъёмке, отличать лиственные породы от хвойных и оценивать размеры деревьев. Каждому дереву подбирается подходящая 3D-модель, которую размещают на карте. Фактически моделей всего две: лиственная или еловая, а для эффекта разнообразия они масштабируются и немного поворачиваются.

Работа с данными

Основная сложность была в том, чтобы собрать и правильно обработать данные. Нашли несколько источников разметки — каждый со своими нюансами. В итоге использовали два:

— разметку от сообщества картографов «Народная карта» — она содержала несколько тысяч деревьев с достаточной точностью, но этого было мало для обучения модели;
— один из публичных датасетов геоданных — показал хорошую точность, но низкую полноту; немного уступал данным от картографов и отличался по параметрам съёмки.

Обучение

Модель предобучили на публичном датасете и разметке картографов. Она смогла базово отличать деревья, но качество предсказаний было низким, особенно по полноте. Помогла доразметка с «активным обучением»: прицельно размечали изображения, на которых модель часто сомневалась и возвращала предсказания рядом с порогом принятия решения.

За два месяца дополнительно разметили около 60 тысяч деревьев в Москве, Петербурге и Калининграде. При этом модель определила 4 миллиона деревьев за два дня — это показывает, как автоматизация сокращает трудозатраты на разметку данных.

Архитектура

В основе архитектуры — классическая UNet-модель с ResNet в качестве бэкбона. Нейросеть предсказывала попиксельную карту вероятностей наличия дерева в каждой точке. Изначально поиск деревьев был тесно связан с поиском точечной дорожной разметки (стрелочки на асфальте). На абстрактном уровне — это очень похожие вещи. Поэтому разработанные решения базируются на одних и тех же идеях, почерпнутых из этой статьи.

Проблему с недооценкой количества деревьев решали с помощью focal loss — модифицированной кросс-энтропийной функции, которая увеличивает влияние сложных для локализации объектов. Дополнительно повысили вес ошибок, связанных с пропусками, чтобы модель не игнорировала малозаметные деревья. Без такого перераспределения потерь предсказания смещались в сторону фона — то есть модель чаще выбирала класс «нет дерева», чем «есть дерево».

Модель научилась хорошо определять, где находится дерево, но также ей нужно было понимать, какого оно типа и какая 3D-модель для него нужна. А для этого надо понять ширину и высоту. Мы обратили внимание на модель DeepForest, которая плохо находила центры, но хорошо предсказывала ширину. Решили объединить усилия: нашей моделькой находили локализацию деревьев, а DeepForest просили сказать, какой они ширины. В результате получили данные, на которых смогли обучить модель предсказывать ширину по локализации: где находится дерево и как выглядит этот маленький кусочек снимка.

Благодаря картографам у нас также были данные вида: «это дерево, и оно имеет ширину Х и высоту Y». Мы уже научились находить дерево и определять его ширину. Осталось взять имеющиеся данные и научиться с их помощью предсказывать высоту. Вуаля — мы получили модель, которая умеет локализовывать (находить местоположение) + вычислять ширину (по локализации) + вычислять высоту (по ширине и тому, как дерево выглядит).

Результаты и планы

В итоге модель помогла разметить для Москвы почти 3 млн деревьев, а для Петербурга — 1,1 млн деревьев.
Сейчас система работает на аэросъемке, но в будущем есть планы перевести её на спутниковые снимки. Это ускорило бы обновление карт, поскольку спутниковая съёмка дешевле и проводится чаще. Однако разрешение спутниковых снимков ниже, и для такого перехода нужны дополнительные исследования и более сложные модели.

ML Underhood

Личный опыт инженеров Яндекса — Никита Киселёв

Сотрудники компании продолжают рассказывать нашему каналу о своей работе, успехах и вызовах. Сегодня на очереди Никита Киселёв, руководитель службы любви к дискавери в Яндекс Картах.

#YaMLpeople

ML Underhood

Как и зачем Алису учат понимать интонации

Алису учат откликаться не только на её имя, но и на определённые команды и даже интонации. Причём вторая задача — на порядок сложнее. В этом посте Дмитрий Солодуха, руководитель команды голосовой активации, рассказал, как она решается.

Голосовая активация — это распознавание фраз в потоке звука, поступающих на микрофоны умного устройства. А модель, которая решает задачу голосовой активации, называют споттером. В Яндексе работают над командными и интонационными споттерами. И если первые в проде уже какое-то время, то вторые — только с 27 февраля этого года и пока только на Станции Миди.

Как устроен споттер в целом:

1. На вход поступает сырой сигнал с частотой 16 кГц.
2. Преобразуем его в спектрограммы с помощью оконного преобразования Фурье. Это позволяет перейти от временной размерности к частотной.
3. Затем уменьшаем размерность, используя мел-шкалу и логарифмирование.

После этого можно подавать данные в свёрточную сеть. Мы используем свёрточную сеть до 1 млн параметров, похожую на MobileNet, но с одномерными DepthwiseSeparable свёртками вместо двумерных. Линейные слои заменяем их низкоранговым приближением, а вместо Swish берём Hard-Swish — его адаптацию, которую удобно вычислять на железе.

Идея интонационного споттера

В какой-то момент базовый споттер улучшили настолько, что он стал отличать произнесённое в девайс слово «Алиса» от обращённого к человеку. Мы подумали, что можно пойти дальше и обучить другой споттер понимать по интонации, что нужно активироваться и отправить запрос на сервер. Это упростит жизнь пользователям и позволит нам сэкономить на произносимых «Алисах».

Пользователи часто забывают произносить «Алиса» перед запросом, то есть ожидают от неё диалога. Умение активироваться на интонацию становится точкой входа в общение ассистента с пользователем.

Но здесь столкнулись с проблемами: неочевидно, откуда брать данные, нет готовой разметки, а также непонятно, в какой момент устройство должно активироваться.

Сначала попробовали использовать данные, которые наговорили асессоры, но из-за того, что люди использовали неестественные интонации, датасет выходил плохим.

Тогда решили взять данные от ASR — не только из активаций, но и из дослушиваний — режима, в котором колонка проактивно продолжает диалог. Например, если я спрашиваю: «Алиса, какая погода в Минске?», она отвечает и уточняет: «А хотите узнать погоду в Белграде?». При этом пользователь не говорит «Алиса» повторно. Это уже похоже на естественный диалог, хотя и не лишено ограничений, которых не будет у интонационного споттера: дослушивания работают не на каждый запрос и ждут пользователя только в коротком интервале около 3–5 секунд.

Мы пересэмплировали полученные данные, чтобы убрать смещение в сторону популярных запросов, и получили нужный датасет.

Для разметки использовали решение соседней команды ASR — классификацию на side-speech. Суть в том, что ASR пытается на последнем этапе своей работы понять, действительно ли речь имела полезный смысл. Мы немного доработали исходные метки и получили для себя псевдолейблы, которые буквально говорят нам, подходящая интонация для активации или нет.

На видео показано, как интонационный споттер работает и решает более сложные задачи, чем стандартная активация на имя. В итоге это позволяет Алисе быть более человечной в диалоге.

ML Underhood

Личный опыт инженеров Яндекса — Петр Вытовтов

Погода в доме, конечно, важна, но нужно и на улицу выходить. А чтобы дождь или снег не застали вас врасплох, стоит ознакомиться с прогнозом.

В его создании сегодня ключевую роль играют нейросети, которые анализируют огромные массивы данных. О том, как эти технологии преобразили сервис Яндекс Погода, а также о своих профессиональных достижениях и вызовах нашему каналу рассказал Петр Вытовтов — руководитель группы машинного обучения направления.

#YaMLpeople

ML Underhood

YandexGPT 5 уже в опенсорсе и Алисе

Сегодня Яндекс показал миру новое поколение больших языковых моделей — YandexGPT 5. Старшая модель YandexGPT 5 Pro доступна в чате с Алисой и Yandex Cloud через API. Ну а претрейн-версия младшей модели YandexGPT 5 Lite Pretrain — уже лежит на Hugging Face.

Все подробности о процессе обучения можно прочитать в статье на Хабре. А в этом посте — главные факты о свежей опенсорсной модели Яндекса.

YandexGPT 5 Lite Pretrain — модель на 8 миллиардов параметров с длиной контекста 32 тысячи токенов. Претрейн проходил в два этапа: сначала модель обучили на 15 триллионах токенов текста на русском и английском языках, а потом использовали 320 миллиардов токенов высококачественных данных, включая образовательный контент.

На первом этапе датасет больше чем на половину состоял из веб-документов, остальное — код, математика и специфичные данные. Под последними подразумеваются синтетика (сгенерированные YandexGPT 4 вопросы на основе проверенных источников) и внутренние наработки компании (например, внутренняя база Яндекса Fact Snippet и новый корпус данных Переводчика).

На втором этапе датасет на четверть состоял из веб-страниц и почти в равных пропорциях содержал математику, код и образовательные данные. Также была небольшая часть аугментаций фактовых документов, другой синтетики и датасетов сервисов.

По сравнению с моделью предыдущего поколения, YandexGPT 4 Lite Pretrain, новая модель показывает ощутимый рост качества в решении математических задач и написании кода. А в сравнении с зарубежными аналогами, такими как LLaMa3.1-8B и Qwen-2.5-7B-base, она лидирует почти во всех типах задач.

Ещё раз приглашаем пощупать модель, почитать статью на Хабре с деталями обучения и не забыть поделиться впечатлениями в комментариях!


ML Underhood

Документный LLM-переводчик в Яндексе

Яндекс запустил новую модель для документного перевода на основе YandexGPT. Она уже работает в Поиске, Умной камере и Нейропереводчике Яндекс Браузера, а также заняла первое место в бенчмарке DiBiMT по переводу с английского на русский. Обо всех нюансах работы переводчика и о том, как его создавали, на Хабре рассказал руководитель группы базового качества перевода Николай Карпачёв. А здесь — кратко о главном.

Документный перевод предполагает адаптацию на другой язык не каждого отдельного предложения, а всего текста. Почему это важно? Причин несколько. Например, английское «you» может означать как «ты», так и «вы», но без контекста модель не понимает, какой вариант выбрать. Термины и стилистика могут «прыгать» внутри текста, а пропущенные элементы, понятные носителю языка, в переводе превращаются в бессмысленный набор слов. Люди воспринимают текст иначе: мы читаем книги, статьи, субтитры — всё целиком. Значит, и машинный перевод должен работать так же.

Инженеры Яндекса попробовали перевести тексты LLM-моделью «из коробки», без дообучения, но столкнулись с типичными ошибками: пропущенные фрагменты, лишние добавления, галлюцинации. Чтобы этого избежать, модель пришлось адаптировать. На первом этапе подготовили данные, включая не только классические парные предложения, но и переводы документов, полученные автоматическим выравниванием и с помощью синтетики. Дообучение проходило в форматах LoRA и P-Tuning.

На следующем этапе модель дообучалась с помощью технологии alignment. Разные варианты переводов сравнивались редакторами-профессионалами. Полученные оценки использовали для оптимизации методом Contrastive Preference Optimization (CPO). На этой стадии происходит исправление существующих ошибок и проблем LLM-модели, найденных редакторами. Это позволило минимизировать ошибки, связанные с потерей информации и несогласованностью.

В итоге по метрике MQM новая модель переводит тексты почти так же хорошо, как человек. Количество грубых ошибок сократилось в два раза по сравнению с предыдущей версией, а финальный результат оказался даже лучше GPT-4o.

ML Underhood

Личные итоги года инженеров Яндекса — Максим Спорышев

Середина февраля 2025-го — не помеха для подведения итогов 2024-го. Тем более, если они такие интересные, как сегодняшние. Ими поделился руководитель группы алайнмента модели планирования движения в Яндексе Максим Спорышев. Он рассказал о собственных успехах и о том, чем ему запомнился прошлый год.

#YaMLpeople

ML Underhood

Как в Яндексе заменили сложную разметку на LLM

В конце прошлой осени Команда качества поиска одной из первых в Яндексе смогла существенно удешевить сложную асессорскую разметку за счёт генеративной модели. Татьяна Климук, руководитель Службы исследований и качества ранжирования, рассказала, как работали над технологией.

Яндекс использует услуги тысяч асессоров, которые каждый день выполняют десятки тысяч заданий по оценке выдачи с точки зрения качества и релевантности. Это дорогой, долгий и сложный процесс.

Идея проекта в том, чтобы отдать рутинную работу по разметке сильной нейронке. При этом мы не отказываемся от асессоров, а переключаем их на разметку более важных и сложных кейсов, а также поручаем контролировать корректность работы модели.

Архитектура

Мы начали с экспериментов с базовым претрейном от YandexGPT. На вход подавали сжатую инструкцию, запрос и контент документа, на выходе получали решение о принадлежности к одной из категорий релевантности.

Однако промптинг даже SoTA-моделей пока не даёт нужного качества на нестандартных кейсах. Инструкция оказывается для них настолько сложной, что без дообучения ни одна модель не справляется с ней. Поэтому на старте получилось выжать только 55% качества асессоров.

Тогда мы сделали ряд улучшений:

— Взяли претрейн от Нейро, который лучше понимает поисковый домен и легче обучается решать поисковые задачи.
— Обучались не просто на метку класса, но и на подготовленные Chain-of-Thoughts, чтобы научить модель больше думать перед тем, как она даёт ответ.
— Добавили внешние данные — знания, необходимые для понимания контекста, которые нельзя извлечь из текста. Пример таких знаний — то, какие страницы в сети официальные, а какие — нет.
— Подавали данные для обучения в нужном порядке — от более мусорных к более качественным.

Так мы добились качества 102% относительно разметки асессоров, что уже было неплохо. Но оставался риск «сломать» Поиск — поэтому нужно было проверить модель на разных классах запросов, исключить риск деградации со временем и учесть другие нюансы.

Решение

В итоге мы придумали решение, которое использует оценку как от людей, так и от нейросети. Мы стали извлекать из неё не только ответ по инструкции, но ещё и уверенность в этом предсказании. В зависимости от степени уверенности мы принимали решение, использовать ли в задаче человеческий ресурс.

— Если модель уверена в ответе, скорее всего, задача простая и не требует помощи асессоров. С этими кейсами она нередко справляется даже лучше людей. Таких задач оказалось около половины от общей массы.
— Если модель не до конца уверена в ответе, привлекаем её вместо одного из трёх асессоров. Размер этой зоны — около 30%.
— Когда модель говорит, что совсем не уверена в решении, отдаём задачу трём сильным асессорам — как это происходит в стандартном процессе. Таких задач порядка 20%.

Результаты и планы

С помощью этого решения мы получили 105% качества и 60% экономии денег.

Мы уже используем его экспериментально в разметке обучающих и валидационных пулов для моделей ранжирования, но конечный мониторинг интегрального качества поиска пока остаётся на людях.

Планируем продолжать наращивать качество и запускаться на новых разметках. Также в долгосрочных планах — свести процесс к промптингу, когда ты не обучаешь модель, а описываешь задачу текстом. Так мы сможем более гибко менять инструкции разметок без переобучения модели.

Мы рассчитываем, что решение поможет нам перекинуть рутину на нейронки, а людям давать более интересные и сложные задачи.

ML Underhood

Как создаются трейлеры в Яндекс Музыке

Трейлеры дают возможность быстро познакомиться с новой музыкой, чтобы решить, стоит ли погружаться в неё дальше. Трейлеры в Яндекс Музыке есть у треков, альбомов, плейлистов и исполнителей. Фрагмент для трейлера каждого трека выбирается на основе предсказаний нейросети. И в ваших итогах 2024 года тоже играл трейлер из любимых треков. О том, как создаются такие трейлеры, нашему каналу рассказал старший разработчик из команды Музыки Николай Глазырин.

Чтобы сделать трейлер для трека, нужно совсем немного: определить его начало и конец 🙂 Мы хотим, чтобы в трейлер попал самый яркий и узнаваемый законченный фрагмент трека. А ещё — чтобы фрагменты разных композиций могли плавно перетекать друг в друга.

Мы обучили модель, которая умеет предсказывать в треке одновременно границы тактов, позиции битов (по-русски их обычно называют тактовыми долями) и наилучшие моменты для начала трейлера. Это небольшой encoder-only-трансформер на 0,5М параметров, который принимает на вход аудио с частотой дискретизации 22050 Гц, а на выходе с шагом в 1/75 секунды предсказывает три числа: вероятность найти в этот момент бит, границу такта и начало подходящего для трейлера фрагмента. Для обучения мы используем нашу нейромузыку, несколько открытых датасетов с границами тактов и тактовых долей, а также небольшой собственный датасет с размеченными вручную позициями начала трейлера.

При обучении модель осваивает одновременное решение этих трёх задач. Можно заметить, что вся разметка состоит из каких-то позиций внутри трека и привязана к его темпу. Поэтому очень помогает во время обучения аугментировать данные путем ускорения-замедления аудио, чтобы модель не привязывалась к каким-то более популярным темпам.

Выходы модели мы сглаживаем полосовыми фильтрами, чтобы избавиться от лишнего шума. Диапазон частот для каждого выхода подобран отдельно, чтобы соответствовать разумному. Например, темп музыки обычно находится в диапазоне 50–200 ударов в минуту, поэтому и тактовые доли должны встречаться с примерно такой же частотой. В сглаженных выходах уже очень просто определить локальные максимумы, которые и отмечают интересующие нас моменты времени.

Для начала трейлера мы выбираем момент с максимальным значением на соответствующем выходе модели. Если в треке есть вокал (что проверяется другой моделью), то выбираем такой момент, чтобы в трейлере тоже был вокал. Конец трейлера ставим ровно через 8 тактов после начала. А чтобы трейлеры можно было красиво смиксовать, добавляем ещё небольшой фрагмент трека (1 такт) прямо перед началом. На этом фрагменте во время воспроизведения громкость плавно поднимается, а на последнем такте — наоборот, плавно затухает, что даёт плавный переход между трейлерами разных треков.

Наша модель маленькая, и поэтому достаточно быстрая, и при необходимости может работать даже на CPU. Это важно, поскольку в нашем каталоге десятки миллионов треков и ещё десятки тысяч добавляются каждый день.

ML Underhood

Личные итоги года инженеров Яндекса — Александр Шишеня

2025 год вступил в свои права, поэтому можно хорошенько осмыслить, что произошло в 2024-м. Мы попросили ML-специалистов из Яндекса рассказать, какими были для них минувшие 12 месяцев. Первый на очереди — ведущий разработчик службы компьютерного зрения Александр Шишеня. Он рассказал о своих профессиональных успехах и планах.

Александр упоминает статью Physics of Language Models.

А в канале CV Time вы сможете почитать о лучших статьях по мнению Александра. Там, кстати, ещё много интересного — подписывайтесь!

#YaMLpeople

ML Underhood