Недавно пользователям приложения «Алиса» стал доступен Live-режим, который работает на базе мультимодальной нейросети (VLM), созданной в Яндексе. В этом режиме Алиса распознаёт объекты, показанные ей через камеру смартфона, и рассказывает о них пользователю. А ещё раньше наша VLM стала применяться в Поиске по картинкам, Умной камере и Нейроэксперте. Всё это время технология не стояла на месте и продолжала совершенствоваться. Пожалуй, пришло время поделиться опытом.
На связи Роман Исаченко из команды компьютерного зрения в Яндексе. Сегодня я расскажу, какой путь наша VLM прошла за полгода. А Дарья @dara-orange Виноградова, которая работает со мной в той же команде, поделится описанием пайплайна зрения в Алисе. Мы опишем весь путь формирования новой модели: от архитектуры и сбора данных до финальных замеров качества и скорости.
Что представляет собой наша VLM
В прошлой статье я подробно рассказывал, какие задачи решает наша VLM, как она устроена архитектурно и как проходит её обучение. Здесь же напомню основные моменты для полноты рассказа.
VLM, или Visual Language Model, — это обобщение LLM на домен изображений. Эти модели принимают на вход картинку, а также произвольный текстовый инстракт, и предсказывают текст — ответ на пользовательский запрос. Схематично архитектуру нашей модели можно представить следующим образом:
Поясню, что происходит на схеме:
LLM — текстовая модель (в нашем случае — YandexGPT), которая ничего не знает про картинки.
Image encoder — картиночная модель (ViT), которая ничего не знает про тексты.
Adapter — модель, которая, как кот Леопольд, пытается сделать так, чтобы LLM и картиночный энкодер жили дружно (MLP).
Яндекс совсем недавно представил новое поколение YandexGPT 5 (которое включает в себя в том числе опенсорс-модель YandexGPT 5 Lite). И наша новая VLM основана на этом семействе моделей.
Обучение
Поговорим про то, как обучается мультимодальная нейросеть Яндекса. Как я уже упомянул выше, мы берём за основу претрейн от YandexGPT, и далее модель проходит через несколько стадий обучения на мультимодальных данных. На каждом из этапов обучения мы учим все веса нашей модели.
Раньше наши модели базировались на модели YandexGPT 4. И один лишь переход на YandexGPT 5 уже показал довольно хороший рост качества. Но помимо этого мы сделали довольно много улучшений и в процессе обучения самой модели.
Претрейн
Первый этап — это претрейн. В предыдущей статье я рассказывал, какие виды претрейна VLM существуют. За эти полгода (с октября 2024 года по апрель 2025 года) мы довольно плотно над ним работали и в итоге научились готовить датасет хорошего качества, который представляет собой смесь разных источников:
Interleaved-данные — это веб-документы, которые обычно используются для обучения LLM, но в которых содержатся изображения. Здесь нам пришлось построить довольно сложный пайплайн обработки мультимодальных документов, который включает несколько стадий фильтраций: текстовых, картиночных и текстово-картиночных.
Пары image-text — картинки и их подробное описание. При построении этого датасета мы очень плотно поработали с командой YandexART, для которой пары image-text — топливо модели. Наш итоговый пайплайн состоит из многостадийной генерации синтетических описаний нашими прошлыми версиями моделей, а также последующей стадии валидации каждого факта в сгенерированном описании.
OCR-данные — преимущественно логи нашего OCR-сервиса. Для добавления этих данных мы провели кропотливую работу по фильтрации персональных и чувствительных данных.
Данные text-only — отобранные текстовые документы высокого качества. Здесь мы взяли срез веб-документов, который позволяет нам сохранять у нашей VLM способность генерировать текст с качеством не хуже, чем у изначальной YandexGPT.
Итоговый датасет содержит 400 млрд токенов, и у него следующее распределение источников:
SFT
Теперь поговорим про SFT. Пожалуй, опущу бо́льшую часть технического описания того, что происходит на этой стадии, остановлюсь на нескольких основных пунктах.
В последней итерации нашей модели мы смогли добиться такого качества VLM, что оно не уступало качеству LLM. С учётом того, что мы обучаем все веса нашей модели, в ранних версиях VLM способности модели на текстовом домене были ниже, чем у YandexGPT — у нас появилось разумное желание их вырастить, ведь это полезно в диалоговых сценариях. Здесь пришлось довольно долго и кропотливо выверять пропорции текстовых и мультимодальных данных, которые приведут к общей модели, которая хороша и как VLM, и как LLM.
Помимо этого мы поработали над многими OCR-срезами. Например, сильно забустили срез работы с таблицами.
RL
Ну и вишенка на торте — стадия RL. Здесь мы используем DPO-метод для обучения на парах «хороший ответ — плохой ответ». Для этого мы собираем ответы нескольких VLM и просим людей выбрать лучший из них согласно нашим критериям для разметки. Далее обучаем модель на этой разметке.
Причём мы обнаружили, что наша модель довольно быстро насыщается: достаточно порядка 20к пар ответов для такого обучения. Здесь намного важнее не количество, а качество ответов, а также распределение исходных картинок и пользовательских промптов.
Замеры и оценка качества
А теперь поговорим про самое интересное: про числа!
Во-первых, определимся с тем, как мы сравниваем модели. Вот две основные метрики:
SbS (side-by-side). Мы просим асессоров оценить по довольно подробной инструкции два ответа модели и выбрать из них лучший. Делаем мы это на тщательно собранной корзине картинок и пользовательских запросов.
Опенсорс-бенчмарки. Здесь приведём агрегированную метрику — средний скор, который мы получаем при замере более чем на 30 опенсорсных бенчмарках. Примеры таких бенчмарков можно посмотреть тут или тут. Важно отметить, что все бенчмарки англоязычные. При этом основной домен применения модели — всё-таки русский язык.
Для нас SbS — самая важная метрика, так как в этом случае мы ориентируемся на реальные пользовательские задачи, а не на абстрактные свойства модели.
Во-вторых, не менее важно определиться, с кем мы сравниваемся. Мы стараемся замерять все известные нам VLM на наших основных метриках. По нашим замерам, самая сильная на текущий момент опенсорс-модель — Qwen2.5-VL, поэтому ниже приведу числа относительно неё.
Итак, начнём с SbS.
Модель A | Модель B | Результат |
YandexVLM Lite | Qwen2.5-VL-7B | 56,6% : 43,4% (p_value = 1e-4) |
YandexVLM Pro | Qwen2.5-VL-72B | 53,3% : 46,7% (p_value = 4e-2) |
По замерам обе наши модели статистически значимо побеждают модели Qwen2.5-VL (с p_value = 0,05).
А теперь посмотрим на опенсорс-бенчмарки.
Модель | Опенсорс-бенчмарки |
YandexVLM Lite | 65,8 |
Qwen2.5-VL-7B | 68,1 |
YandexVLM Pro | 70,4 |
Qwen2.5-VL-72B | 75 |
Здесь наши модели уступают опенсорс-моделям. Однако повторюсь: мы не видим большого смысла в гонке на синтетических бенчмарках, так как основная наша цель — создание продуктов для пользователей. И эти задачи далеко не всегда коррелируют.
В итоге наша новая модель статистически значимо выигрывает по сравнению с лучшей известной нам опенсорс-моделью в двух весовых категориях на пользовательских задачах.
VLM в Алисе
Теперь вы знаете, как изменилась наша VLM с октября прошлого года. Самое время перейти к тому, как мы её адаптировали для Алисы.
Зрение Алисы работает в двух режимах:
Работа с изображением в чате. Это привычный чат, но с возможностью добавлять изображение в виде файла. Алиса даст развёрнутый ответ на вопрос пользователя и даже отформатирует текст, чтобы его было удобно воспринимать. В модель отправляются изображения, которые прислал пользователь вместе с текстовым запросом.
Live-режим. Это живой голосовой диалог, когда можно направить камеру на интересующий объект и спросить про него всё что угодно. Здесь мы целимся в краткий, ёмкий и эмпатичный ответ, больше похожий на слова реального собеседника. В модель отправляются кадры видеопотока с камеры.
Чтобы было понятнее, как это выглядит, покажу примеры работы этих режимов.
Ниже приведены примеры загрузки изображений в чат с Алисой:
А здесь ролики, демонстрирующие работу Live-режима:
Информационный запрос
Поиск рецепта
Вид картинок в этих режимах разный. В Live-режим приходят менее качественные кадры с камеры телефона. А в чат чаще всего пользователи загружают изображения хорошего качества, часто взятые из интернета.
Мы добились того, чтобы в обоих режимах финальный ответ генерировала одна и та же VLM. Это позволяет упростить архитектуру сервиса и сэкономить вычислительный GPU-ресурс.
Пайплайн
Общий вид
Теперь предлагаю рассмотреть детально, как наша мультимодальная нейросеть встроена в Алису. Весь пайплайн можно изобразить следующей схемой.
Как вы можете заметить, он довольно похож на пайплайн в Поиске с Нейро, который мы описывали ранее. Давайте вспомним, как он устроен, а также поговорим про то, какую специфику Алисы мы учли.
Итак, наши входные данные:
Изображение. Для чата изображение загружается напрямую, а в Live-режиме это будет кадр из видеопотока.
Пользовательский запрос. Собственно то, что хочет узнать пользователь.
Тег режима. То есть [PHOTO] или [LIVE]. Именно он позволяет нам сделать одну модель для двух режимов.
История диалога. Пользователи часто предпочитают общаться с Алисой в формате диалога.
Внешняя информация и рефразер
Очень важная особенность нашего пайплайна состоит в том, что он не решается end-2-end-моделью. И в Поиске, и в Алисе мы используем RAG-based подход. Его суть заключается в том, что перед тем, как дать финальный ответ, пайплайн идёт в интернет, собирает необходимую релевантную информацию, и уже на её основе VLM даёт ответ. Это довольно общий подход, который используют разработчики нейросетевых моделей: такой режим есть у OpenAI, DeepSeek, Anthropic, xAI.
Но для начала мы должны понять, с каким запросом нам идти в интернет. Здесь на помощь приходит первая часть нашего пайплайна — рефразер. Эта модель, опираясь на выход визуального поиска (теги, распознанный текст, объектный ответ и т. д.), формулирует запрос, который передаётся в текстовый поиск.
В нашем примере запрос «Что кушает?» превратится во что-то вроде «Чем питается детёныш белого гренландского тюленя». Рефразер модели для Алисы практически идентичен тому, который работает в Поиске с Нейро, но мы дообучили его на примерах диалогов с ассистентом. Так рефразер стал лучше справляться на более специфичных для Алисы запросах.
Суммаризатор
После того как мы нашли источники в интернете, которые содержат релевантную информацию для ответа, мы отправляем в финальный VLM-суммаризатор всю имеющуюся информацию. Эта модель формирует финальный ответ, не забывая учесть обозначенный в начале стиль. Его Алиса озвучит или напишет в чате.
По своей сути VLM-суммаризатор — это наша дообученная VLM. Дообучаем мы её как раз на задачу работы с внешней информацией, а также на специфику ответов Алисы — так называемую персонажность.
Немного об экспериментах
Основных сложностей в обучении было две:
добиться хорошего качества на релевантных сценариях (используя SbS-замеры);
сделать пайплайн достаточно быстрым для использования в Live-режиме.
Основной профит нам принесло SFT-дообучение базовой VLM. Поэтому поговорим про данные. Прежде всего хочется отметить, что появление визуального поиска в Нейро нам очень облегчило жизнь, так как с его помощью мы получили примеры реальных пользовательских задач.
Обсудим основные эксперименты, которые помогли нам получить финальную модель.
Диалоговость
Для генерации датасета разнообразных диалогов высокого качества нам пришлось попробовать довольно много эвристических идей. Приведу пример некоторых из них:
Зум-диалоги. Мы брали какую-то картинку и детектировали на ней все объекты. Диалог строили так: сначала задаём вопрос про кроп первого объекта (например, «Что это?»), потом подаём общий кроп первого и второго объектов, как бы «отзумливаясь», и задаём следующий вопрос (например, «Что нового появилось в кадре?»). Так — шаг за шагом — мы строим диалог.
Диалоги с объединением. Такие диалоги мы строили на парах картинок. Сначала спрашивали что-то про первую (например, «Что тут изображено?»), потом аналогично про вторую, а третьей репликой просили объединить эти изображения (например, «Придумай историю про все показанные объекты»).
Диалоги-дозапросы. Это вопросы про похожие объекты. Например, на первой картинке цветок, и мы спрашиваем: «Как правильно удобрять?». На второй картинке уже другой цветок, и мы задаём вопрос: «А этот?».
Лайки и дизлайки из Поиска
В интерфейсе Поиска с Нейро пользователи могут ставить ответу лайки и дизлайки. Сначала мы пробовали взять залайканные примеры в свою выборку, переписав ответы соответственно нашим стилям, но это не вырастило качество. Парадоксально, ведь мы брали какие-то примеры, где задача пользователя была выполнена хорошо.
Поэтому мы решили пойти в другую сторону и взяли примеры с дизлайками, переписав ответы не только соответственно стилям, но ещё и правильно, ведь пользователи дизлайкают ошибочные варианты. Это дало буст в качестве, и мы включили этот срез в дальнейшие эксперименты. Что интересно, в основном он состоял из школьных заданий и примеров на распознавание текста, причём в нестандартных разрешениях. Можно предположить, что такие примеры помогли модели усвоить базовые знания о мире.
Обучение единой модели
Довольно большая неопределённость состояла в том, что мы не до конца понимали, получится ли объединить модель из чата и модель из Live-режима в единую модель. Сначала мы сделали отдельный пайплайн для режима чата, который мы пробовали промптить под Live-режим. Это давало весьма средние результаты: зачастую модель игнорировала какие-то требования к стилю, которых было довольно много.
После нескольких экспериментов мы решили сделать общий датасет для режима чата и Live-режима. И уже с помощью тегов в промпте ([LIVE], [PHOTO]) контролировать, какому режиму соответствует текущий семпл. В итоге мы получили единую модель, которая по качеству не уступает отдельным моделям для каждого из режимов.
Логика выбора кадра в Live-режиме
В процессе разработки продукта возник вопрос: какие именно кадры и каким образом следует извлекать из видеопотока. Захват абсолютно всех кадров — технически сложная задача, которая негативно влияет на производительность модели и может привести к быстрому переполнению контекста.
На первом этапе мы сосредоточились на выборе одного оптимального кадра. Но оставался вопрос — в какой именно момент его выбирать? Первоначальная гипотеза заключалась в том, чтобы брать кадр в момент завершения голосового запроса, то есть когда пользователь перестаёт говорить. Несмотря на свою простоту, такой подход оказался весьма эффективным в UX-тестах раннего прототипа: более чем в 90% случаев пользователи удерживали камеру направленной на интересующий объект и стабилизировали её именно во время голосового запроса. Остальные 10% пользователей, которые убирали камеру до окончания вопроса, быстро адаптировались и осваивали эту механику работы.
Однако одного лишь фиксированного выбора кадра недостаточно для стабильной и качественной работы продукта, поскольку возможны ситуации, когда кадр оказывается размытым из-за дрожания руки или временной потери фокуса. Чтобы предотвратить такие ситуации и гарантировать подачу чёткого изображения на вход VLM-пайплайна, мы реализовали алгоритм оценки резкости изображения непосредственно на устройстве. Этот алгоритм анализирует небольшую временную ε-окрестность вокруг выбранного момента и автоматически выбирает наиболее чёткий кадр для дальнейшей обработки.
Схема работы представлена ниже:
Время работы
Время работы пайплайна зрения в Алисе включает две основные части:
Подготовка и доставка данных. Сюда, например, входит работа ASR (automatic speech recognition), то есть перевод пользовательского аудиозапроса в текст, а также передача изображения по сети.
VLM-пайплайн.
Сейчас на генерацию ответа у нас уходит примерно 3,5 секунды, из которых около 2 секунд — на VLM-пайплайн. Вот из чего складывается время работы нашего пайплайна:
В нашей власти была оптимизация VLM — то есть мы могли поработать над рефразером и суммаризатором. Обратите внимание, что для рефразера нам нужно сгенерировать ответ целиком, поскольку от него зависит поход в поиск и получение инфоконтекста, а результат суммаризатора мы можем начинать озвучивать стримингово — то есть сразу же, с первого токена.
По этой причине в суммаризаторе у нас используется большая VLM, а в рефразере маленькая. Такое решение было принято ещё и по той причине, что суммаризатор генерирует финальный ответ, и для этого ему нужно больше знаний, чем рефразеру, который решает только локальную задачу.
Кроме того, ответ рефразера мы ограничиваем по длине, ведь слишком длинный поисковый запрос вряд ли будет полезен. Обе модели квантизованы в int8, что помогло ускориться примерно на 30% по сравнению с fp16-версией.
Замеры качества
Когда появлялся очередной чекпоинт, мы первым делом проводили SbS с предыдущим лучшим кандидатом. Если видели статистически значимое улучшение, то сравнивались с ответами Qwen2.5-VL-72B, а также нашей VLM, которые работали в RAG-режиме суммаризатора с помощью промпта. Выбор таких референсов был вполне естественен: сравниваемся с лучшим опенсорсным и своим же решением, но запромченными под нашу задачу.
Замер проводился на срезах, релевантных для потенциальных пользователей. Для их выявления мы проводили несколько UХ-исследований, чтобы выделить «жизненные» сценарии, которые близки нашим пользователям.
Для оценки качества мы используем сравнение Side-by-Side, похожее на то, что мы используем при обучении нашей основной VLM. Однако тут мы дополнительно просили асессоров оценивать ответы с точки зрения персонажности и соответствия характеру Алисы. В итоге мы получили следующие результаты:
vs Qwen2.5-VL-72B | vs YandexVLM | |
Режим чата | 57,3% : 42,7% (p_value = 5e-6) | 53,7% : 46,3% (p_value = 3e-2) |
Live-режим | 53,8% : 46,2% (p_value = 2e-2) | 55,8% : 44,2% (p_value = 4e-4) |
Наш пайплайн работает статистически значимо лучше как опенсорса, так и нашей основной VLM — это ровно то, куда мы и целились.
Наши VLM уже использовались в Поиске по картинкам, Умной камере и Нейроэксперте, помогая людям решать задачи, связанные с анализом текста и изображений. А теперь они помогли Алисе обрести зрение и стать ещё более полезной в роли ассистента.
Будем рады обратной связи, предложениям и пожеланиям!
