⚡️Внимание!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Speech Info

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

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

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

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

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

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

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

ML Underhood

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

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

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

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

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

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

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

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

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

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

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

ML Underhood

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

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

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

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

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

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

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

ML Underhood

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

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

Общая идея

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

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

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

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

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

Реализация

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

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

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

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

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

ML Underhood