Назад к блогу

EmbeddingGemma 2: единое векторное пространство для текста, кода, изображений, видео и аудио на устройстве

EmbeddingGemma 2: единое векторное пространство для текста, кода, изображений, видео и аудио на устройстве

Google выпустила EmbeddingGemma 2 — открытую модель эмбеддингов, которая впервые сводит текст, код, изображения, видео и аудио в одно векторное пространство, работая прямо на устройстве. Модульная архитектура позволяет подключать только нужные модальности, а благодаря MRL один и тот же индекс можно сжимать и постепенно расширять новыми типами данных без пересчёта. Разбираем, как это устроено и на что обратить внимание при локальном запуске.

6 октября 2026 года Google выпустила EmbeddingGemma 2 — открытую модель эмбеддингов под лицензией Apache 2.0. В отличие от предшественницы, работавшей только с текстом, новая модель нативно отображает комбинации текста, изображений, аудио и видео в единое пространство эмбеддингов. Полная модель содержит 740 млн параметров и построена на архитектуре Gemma 4.

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

Модульная архитектура и единое пространство

Базовая часть для текста и кода содержит 270 млн параметров. К ней опционально подключаются энкодеры для изображений и видео (170 млн) и для аудио (300 млн), так что разработчик загружает только те, что нужны его данным. Текст и код работают на базе в 270 млн параметров, которая, по измерениям Google, занимает около 191 МБ активной оперативной памяти на телефоне. С визуальным энкодером модель достигает 440 млн параметров, с аудиоэнкодером вместо него — 570 млн, с обоими — полных 740 млн.

Один вход может смешивать текст с изображениями, видео и аудио в общем контексте на 8192 токена. Позиция каждого медиаэлемента отмечается в тексте специальными токенами-заполнителями: <|image|> для изображения, <|video|> для видео, <|audio|> для аудио. Каждый заполнитель заполняется из соответствующего ключа по порядку, и вызов возвращает один эмбеддинг, представляющий текст, изображения и видео вместе, — его можно напрямую сравнивать с любым другим эмбеддингом EmbeddingGemma 2.

Все модальности расходуют общий бюджет контекста с фиксированной скоростью: текст — 1 токен на подcлово, изображение — 280 токенов по умолчанию, видео — 140 токенов на кадр, аудио — 25 токенов в секунду.

Усечение размерности через MRL

Matryoshka Representation Learning позволяет динамически усекать 768-мерный выходной вектор до 512, 256 или 128 измерений без переобучения. Это даёт до 6-кратного сокращения хранилища для локальных векторных баз и памяти.

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

query_emb = model.encode(
    query,
    truncate_dim=128,  # or 512, 256
    normalize_embeddings=True,
)

Префиксы инструкций и форматирование документов

Для текстовых входов рекомендуются короткие префиксы инструкций по задаче. Для асимметричных задач (например, поиска) к запросу добавляется query-префикс, а к документу — document-префикс. Для симметричных задач (классификация, кластеризация, сравнение похожести) один и тот же префикс применяется ко всем сравниваемым входам. Префиксы применяются только к тексту; изображения, видео и аудио передаются без префикса. Документы с реальным заголовком форматируются как title: {title} | text: {content}, при отсутствии заголовка используется title: none.

Числовая точность и запуск на устройстве

Для запуска на устройстве есть два пути: LiteRT — когда модель встраивают в приложение напрямую, и Google AI Edge MediaPipe — когда нужна готовая задача без собственной интеграции.

По числовой точности рекомендуется запускать вывод в bfloat16 или float32 и не использовать float16: диапазон активаций EmbeddingGemma 2 превышает динамический диапазон float16, и в float16 модель возвращает NaN или незаметно ухудшенные эмбеддинги без ошибки, поэтому сбой легко пропустить.

bfloat16 безопасен и имеет ту же 8-битную экспоненту, что и float32; это рекомендуемый вариант по умолчанию на оборудовании с нативной поддержкой, он вдвое уменьшает использование памяти по сравнению с float32. float32 следует использовать в остальных случаях, включая большинство CPU. В SentenceTransformers это задаётся через model_kwargs, а поддержку bfloat16 на своём оборудовании можно определить программно — соответствующей проверкой в библиотеке.

Предыстория

До EmbeddingGemma 2 использовалась EmbeddingGemma — лёгкая модель для качественных текстовых эмбеддингов, помогавшая приложениям организовывать, искать и связывать информацию прямо на потребительском оборудовании. Её применяли для инструментов поиска на устройстве и RAG-конвейеров с приоритетом приватности. Предыдущая версия набрала более 20 млн загрузок.

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

По сравнению с первой EmbeddingGemma контекстное окно увеличено в четыре раза — с 2048 до 8192 токенов, что покрывает до 5,5 минут аудио, 29 изображений или 58 видеокадров за один вход. Производительность на коде выросла на 9,92 пункта в MTEB Code — с 68,76 до 78,68.

Почему это сделали

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

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

Цена векторных индексов

На телефоне индекс конкурирует за место с самой моделью: миллион 768-мерных векторов в формате bfloat16 занимает примерно 1,5 ГБ. Для сравнения, текстовая и кодовая части EmbeddingGemma 2 требуют около 191 МБ активной RAM, а полная мультимодальная модель — примерно 567 МБ.

Усечение через MRL уменьшает индекс: при 256 измерениях тот же миллионный индекс падает примерно до 500 МБ. Но усечение снижает качество. На 256 измерениях сохраняется почти вся полноразмерная точность на тексте и коде и примерно 95% на изображениях, видео и речи. На 128 измерениях текст и код дают около 90%, а мультимодальный поиск — около 75%, и компания советует проверять этот режим на реальных данных. В документации Hugging Face указано, что качество почти не теряется вплоть до 256 измерений, а 128 измерений существенно ухудшают мультимодальное качество.

Что меняется на практике

Усечение размерности сокращает занимаемое индексом место и ускоряет поиск по сходству, но снижает качество. Разработчику доступны размерности 768, 512, 256 и 128.

На устройстве становятся возможными несколько сценариев:

  • Поиск по коду. Код обрабатывается на той же базе в 270 млн параметров, что и текст. Google сообщает MTEB Code score 78,68 для EmbeddingGemma 2 против 68,76 у оригинальной EmbeddingGemma. В агентном сценарии Google проиндексировала репозиторий Hugging Face Transformers текстовой конфигурацией и связала индекс с Gemma 4 26B A4B в Pi, где EmbeddingGemma 2 выполняла поиск по репозиторию, а большая модель управляла агентом.
  • RAG. EmbeddingGemma 2 заимствует текстовый токенизатор и архитектуру аудиоэнкодера у Gemma 4, поэтому двум моделям нужно меньше памяти при совместной работе на устройстве. Google показала мультимодальный поиск на своём флагманском телефоне.
  • Классификация. Та же модель может выполнять классификацию через MediaPipe Decision. В демо с шахматами на устройстве Google использовала это для оценки 500 вариантов за ход менее чем за 100 миллисекунд.
  • Мультимодальный поиск. Один вход может смешивать текст с изображениями, видео и аудио в едином контексте на 8192 токена.

Что ломается при переходе

При переходе на EmbeddingGemma 2 ломается совместимость по размерности векторов и по числовой точности. Векторы можно укорачивать с 768 до 512, 256 или 128 измерений, но после усечения вектор перестаёт быть единичной длины и его нужно заново L2-нормализовать, иначе ранжирование тихо ухудшается. Запрос и документы обязаны иметь одинаковую размерность. По точности вычислений нельзя использовать float16 — активации модели выходят за его динамический диапазон, и модель возвращает NaN или незаметно испорченные векторы; следует применять bfloat16 или float32.

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

Замеры качества по размерностям

При полной размерности 768d EmbeddingGemma 2 показывает следующие результаты: MIEB (lite) — 64,64, MMEB v2 - Image — 57,28, MMEB v2 - VisDoc — 67,84, MMEB v2 - Video — 50,67, MSEB (Retrieval) — 69,54, MAEB — 49,39, MTEB multilingual v2 — 61,36, MTEB eng v2 — 68,46, MTEB code v1 — 78,68, MMEB (v2) Overall — 59,01.

При усечении значения снижаются. MIEB (lite): 64,32 при 512d, 63,13 при 256d, 59,06 при 128d. MMEB (v2) Overall: 58,38 при 512d, 56,24 при 256d, 45,65 при 128d. MTEB code v1: 77,24 при 512d, 76,18 при 256d, 71,41 при 128d.

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

Ограничения и открытые вопросы

Авторы признают ограничение по точности на малых размерностях: качество почти без потерь вплоть до 256 измерений, а 128 измерений существенно ухудшает мультимодальное качество и требует проверки на собственной нагрузке.

По контексту указано, что окно было увеличено с 2048 до 8192 токенов, что покрывает до 5,5 минут аудио, 29 изображений или 58 видеокадров за один вход, при этом видео по умолчанию сэмплируется с частотой один кадр в секунду. По языкам заявлена поддержка более 100 языков.

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

Источники

Похожее