EmbeddingGemma 2 — открытая модель от Google, представленная как лучшая в своём классе для нативно мультимодальных эмбеддингов. Она рассчитана на векторное представление данных сразу нескольких модальностей: это нужно для поиска, RAG и систем рекомендаций, включая мультимодальный поиск прямо на устройстве.
Если коротко: речь о модели, которая кодирует данные разных типов в одно векторное пространство. Ниже — подтверждённые факты из официальных материалов Google и разбор самого класса таких моделей. Формулировку о превосходстве в классе читайте как заявление разработчика: независимых сторонних оценок в открытых источниках пока нет.
Ниже: как устроены нативно мультимодальные эмбеддинги, чем они отличаются от пайплайна с объединением модальностей постфактум, где это даёт практический выигрыш и на что смотреть при выборе модели под свой RAG.
Что такое нативно мультимодальные эмбеддинги и зачем они нужны
Эмбеддинг — это вектор чисел, описывающий объект. Смысл в геометрии: близкие по содержанию объекты получают близкие векторы, а расстояние между ними (косинусная близость, скалярное произведение) работает как мера релевантности. На этом стоит семантический поиск, дедупликация, кластеризация и подбор контекста для LLM.
Нативно мультимодальные эмбеддинги означают, что одна модель с самого обучения отображает разные модальности в общее пространство. Текстовый запрос и изображение-кандидат оказываются в одной системе координат, и сравнение между ними имеет смысл без дополнительных надстроек.
Ценность проявляется там, где данные разнородны. Каталог товаров: фото, название, описание, характеристики. База знаний: статьи, скриншоты, схемы, PDF с таблицами. Лента контента: видео, превью, подписи. Эмбеддинги текст и изображения в едином пространстве позволяют искать по всему этому одним запросом.
Чем это отличается от подхода, где модальности объединяют постфактум
Типичный постфактум-пайплайн выглядит так: текст кодируется текстовой моделью, изображения — отдельной визуальной, каждая модальность получает свой индекс, а результаты поиска сливаются на уровне ранжирования (late fusion) либо векторы приводятся к общему виду через обученную проекцию. Схема рабочая, но у неё есть цена.
- Пространства обучены независимо, у них разная геометрия: косинус между текстовым и визуальным вектором сам по себе ничего не значит, пока вы не обучите отображение.
- Слияние результатов добавляет гиперпараметры: веса модальностей, нормализация оценок, порядок объединения. Их приходится подбирать и перепроверять на своих данных.
- Пайплайн растёт: две и больше моделей, два и больше индексов, отдельные этапы предобработки и версионирования.
- Мелкие типы контента страдают первыми. Изображение внутри PDF или скриншот интерфейса часто не попадают в индекс вообще, потому что под них не нашлось отдельной модели в пайплайне.
Нативный подход предполагает единое пространство с обучения. Это не гарантия, что конкретная модель снимет все перечисленные сложности, но сама архитектура убирает необходимость в промежуточном слиянии. Качество придётся проверять на своих данных: без бенчмарков и независимых сравнений выводы делать рано.
Почему это критично для мультимодального RAG
Мультимодальный RAG — это схема, где в генерацию ответа попадают фрагменты разных типов: текст, изображения, таблицы, иногда аудио. Как устроен обычный RAG, подробно разобрано в практическом руководстве по подключению документации к LLM: чанкинг, эмбеддинги, векторный поиск, передача найденного контекста модели.
Когда в базе лежат изображения, появляется отдельный вопрос: как найти картинку по текстовому запросу и как найти текст по картинке. Нативные мультимодальные эмбеддинги позволяют держать один индекс и один тип вектора на все модальности вместо связки «текстовый поиск плюс отдельный визуальный поиск плюс логика слияния». Архитектура упрощается, а качество извлечения зависит от того, насколько хорошо модель выучила общее пространство.
Второй момент: чанкинг для мультимодальных данных сложнее, чем для текста. Что считать фрагментом, если страница PDF содержит абзац и схему, связанные по смыслу? Разбор методов чанкинга и метрик вроде Recall@K есть в материале про устройство RAG-поиска в 2026 году.
Что известно об EmbeddingGemma 2: подтверждённые факты
По официальным материалам Google картина такая:
- Google DeepMind выпустила EmbeddingGemma 2 — открытую мультимодальную модель эмбеддингов с открытыми весами (open-weight), предназначенную для работы непосредственно на устройствах пользователей (блог Google, Investing.com).
- Модель нативно отображает текст, изображения, видеокадры и аудио в единое векторное пространство (Google Developers Blog).
- Она построена на архитектуре Gemma 4 и выпущена под коммерчески разрешительной лицензией Apache 2.0 (блог Google).
- Объём модели — 740 миллионов параметров (блог Google).
- Заявленные сценарии: поиск, retrieval-augmented generation (RAG), классификация и кластеризация, а также локальный поиск и извлечение медиа, семантический поиск и маршрутизация полностью на устройстве (карточка модели, блог Google).
- Google описывает модель как best-in-class для своего размера (Google Developers Blog).
Что стоит держать в голове: формулировка «лучшая в своём классе» — это заявление разработчика. Официальные бенчмарки в карточке модели и блоге Google приводятся, но независимых сторонних прогонов в открытых источниках на момент подготовки материала нет.
Почему «лучшая в своём классе» — пока только заявление
Google сообщает, что EmbeddingGemma 2 оценивалась на бенчмарках текстовых, кодовых, визуальных, визуально-документных, видео- и аудио-эмбеддингов: MTEB (multilingual, v2), MTEB (code, v1), MIEB (lite), MMEB v2 (Image, VisDoc, Video), MSEB (Retrieval) и MAEB (карточка модели, Ollama). По данным Google, модель сохраняет сильные мультиязычные текстовые результаты EmbeddingGemma и даёт прирост 9,92 пункта в MTEB Code (с 68,76 до 78,68) (блог Google).
Это официальные цифры, а не независимая проверка. Чтобы формулировка «лучшая в своём классе» стала измеренным результатом, нужны сторонние прогоны на воспроизводимых данных и на реальных задачах, а не только на синтетике. Проблема известна: лабораторные тесты расходятся с поведением на новых данных. Как раз об этом — анонс RTEB 2026, бенчмарка для embedding-моделей с гибридной оценкой на 20 языках, где отдельно обсуждается разрыв между статичными лидербордами и реальной производительностью. Пока таких замеров по EmbeddingGemma 2 нет, честная позиция одна: модель может оказаться сильной, а может и нет, и решать будет тест на ваших данных.
Где нативно мультимодальные эмбеддинги дают практический выигрыш
Три сценария из анонса — поиск, RAG и рекомендации — различаются механикой, но опираются на одну способность: сравнивать объекты разных типов в общем пространстве. Ниже про то, как это выглядит в работе. Речь о классе моделей, а не об измеренных результатах EmbeddingGemma 2.
Мультимодальный RAG: поиск по тексту и изображениям в одной системе
Базовая схема RAG: документы режутся на фрагменты, каждый фрагмент превращается в вектор, векторы складываются в индекс. На запросе система считает эмбеддинг вопроса, достаёт top-K похожих фрагментов, отправляет их в LLM как контекст. Модель эмбеддингов для RAG здесь узкое место: если она не различает нужное, генератор получит мусор, и качество ответа упадёт независимо от размера LLM.
В мультимодальном варианте в индекс попадают и изображения: скриншоты, схемы, фотографии товаров, кадры из видео. Пользователь спрашивает текстом «как выглядит блок питания на этой плате», и система должна найти и текстовый фрагмент, и картинку. С единым пространством это один поиск по одному индексу. С раздельными моделями — два поиска и логика слияния, плюс вопрос, как показать изображение в ответе. О том, почему богатый входной контекст меняет качество генерации, есть отдельный разбор граундинга в нейросетях.
Ограничение тоже понятное: единый индекс не означает единое качество. Изображения и текст отличаются плотностью информации и способом описания, и модели приходится балансировать между модальностями. Насколько хорошо это получилось у EmbeddingGemma 2, по анонсу судить нельзя.
Поиск и рекомендации: единое пространство для разных типов данных
В поиске единое пространство даёт обратный поиск: можно искать по текстовому запросу среди изображений и наоборот, по картинке находить тексты. Для каталогов это означает, что фотография товара и его описание индексируются одинаково, и оба находятся одним запросом. Для внутренних баз знаний — что скриншот из интерфейса и статья в wiki оказываются в одной выдаче.
В рекомендациях схема похожа, но сторона запроса другая. Профиль пользователя собирается из текста (история запросов, отзывы, теги), а объекты описаны изображениями, названиями и характеристиками. Мультимодальные эмбеддинги позволяют сравнивать профиль с объектом напрямую, без ручных признаков и отдельных моделей под каждую модальность. Для рекомендательных сервисов это сокращает число компонентов, которые нужно синхронизировать.
Оговорка та же: заявление о применении в рекомендациях описывает назначение модели, а не подтверждённый прирост метрик. A/B-тест на своём трафике никто не отменял.
Какие требования к инфраструктуре могут возникнуть
По официальным материалам Google картина такая:
- Модель имеет 740M общих параметров: 270M текстовая модель плюс модульные vision-энкодер (170M) и audio-энкодер (300M) (карточка модели, Hugging Face).
- С квантизацией на Google Pixel 11 Pro EmbeddingGemma 2 требует около 191 МБ активной RAM для текстовых весов и около 567 МБ для полной мультимодальной модели (блог Google).
- Vision- и audio-энкодеры — независимые компоненты. Неиспользуемые модальности можно отключить через SentenceTransformer, чтобы снизить потребление памяти в текстовых или одномодальных пайплайнах (Hugging Face, unsloth).
- Модель можно подавать через transformers, sentence-transformers, LMStudio и другие фреймворки (блог Google).
Важное ограничение: цифры по RAM относятся к квантизованной модели на конкретном устройстве (Google Pixel 11 Pro). Универсальные требования к VRAM для других устройств и конфигураций в официальных материалах не приводятся, поэтому переносить эти значения на серверный GPU-инференс напрямую нельзя.
Что проверить перед тем, как планировать локальный запуск
- Поддерживаемые модальности: текст, изображения, видеокадры, аудио. От этого зависит, какие данные вообще имеет смысл индексировать.
- Размер модели и точность. Для эмбеддингов важнее не число параметров, а качество векторов, но размер напрямую влияет на память.
- Требования к VRAM и GPU. Мультимодальные модели обычно тяжелее текстовых: визуальный и аудиоэнкодеры добавляют параметры и память под активации. Для инференса на CPU стоит заранее посмотреть, есть ли поддержка ONNX или других форматов и какие есть квантизованные сборки.
- Совместимость с фреймворками. Готовая интеграция в sentence-transformers, transformers, LMStudio или похожих инструментах сокращает путь до рабочего прототипа.
- Интеграция с векторной базой. Проверьте, поддерживает ли ваша БД нужную размерность и тип вектора, и как вы будете хранить связь вектора с исходным объектом.
- Пакетная обработка. Индексация каталога быстро упирается в пропускную способность: важно понять, сколько объектов в секунду выдаёт модель на вашем железе, а не только сколько памяти она занимает.
Практически: если план — держать модель рядом с приложением на ноутбуке или на локальном сервере, начинать стоит с оценки памяти под веса и под батч. Для серверных сценариев ориентируйтесь на собственные замеры: официальных цифр по VRAM вне мобильного устройства в переданных материалах нет.
Как выбрать модель эмбеддингов для RAG и когда смотреть на EmbeddingGemma 2
Сравнение моделей эмбеддингов почти никогда не сводится к строчке в лидерборде. Рабочий набор критериев выглядит так:
- Модальности, которые нужны именно вам. Если в базе только текст, мультимодальность становится лишним весом в пайплайне.
- Качество на ваших данных. Соберите небольшой набор пар «запрос — релевантный фрагмент» из своей предметной области и прогоните кандидатов на нём. Публичные метрики полезны как фильтр, но не как решение.
- Ресурсы. Размер весов, память под инференс, скорость на вашем железе, возможность работы без GPU.
- Лицензия. У EmbeddingGemma 2 это Apache 2.0 — коммерчески разрешительная лицензия, что снимает часть вопросов по использованию в продуктах.
- Интеграция. Поддержка в векторной базе, наличие готовых обёрток, простота обновления модели без переиндексации всего корпуса.
- Размерность векторов. От неё зависят память индекса и стоимость поиска; иногда полезны модели с настраиваемой размерностью.
EmbeddingGemma 2 в этой рамке попадает в категорию «интересно, если нужны нативно мультимодальные эмбеддинги и открытая модель от Google». Основания для интереса есть: открытые веса под Apache 2.0, 740M параметров, поддержка текста, изображений, видео и аудио в одном пространстве, локальный сценарий и опубликованные официальные бенчмарки. Оснований объявлять её победителем нет: независимых сторонних тестов пока не опубликовано, а универсальные требования к железу вне мобильных устройств не раскрыты.
Ограничения и неопределённости, которые стоит учитывать
Сводка того, что остаётся за рамками подтверждённого:
- Официальные бенчмарки есть, но они опубликованы самим разработчиком. Независимых прогонов на момент подготовки материала нет.
- Формулировка «лучшая в своём классе» исходит от Google и не подтверждена сторонними оценками.
- Требования к VRAM и железу вне квантизованного запуска на Google Pixel 11 Pro не раскрыты.
- Детали обучения и полный список поддерживаемых языков в переданных материалах не описаны.
Для продакшена этого достаточно, чтобы начать пилот, но не чтобы принимать окончательное решение без собственных замеров. Держите в голове простую вещь: смена модели эмбеддингов означает переиндексацию корпуса. Это часы или дни работы, поэтому решения по таким моделям лучше принимать до того, как база выросла до миллионов объектов.
Что делать дальше: практические шаги для читателя
Последовательность действий, которая не зависит от того, насколько удачной окажется конкретно эта модель:
- Следить за официальными каналами Google по семейству Gemma и карточкой модели на Hugging Face. Обновления спецификаций и независимые оценки появятся там.
- Сформулировать свой сценарий в терминах модальностей: какие типы данных лежат в вашей базе и какие запросы к ним приходят. Если картинок и аудио нет, вся ветка с мультимодальными эмбеддингами вам не нужна.
- Собрать небольшой оценочный набор из своей предметной области: 50–100 пар «запрос — правильный фрагмент» уже дают представление о разнице между кандидатами.
- Проверить, готова ли ваша архитектура принять мультимодальный индекс. Хранение связи между вектором и изображением, отдача картинок в интерфейс, обновление индекса — это отдельная работа.
- Дождаться независимых прогонов и тогда решать. Открытые веса под Apache 2.0 позволяют протестировать модель на своих данных, и такой тест даст больше, чем любой лидерборд.
Если вы уже строите мультимодальный RAG, к кандидатам стоит подходить с одним вопросом: сколько компонентов пайплайна исчезнет, если перейти на единое векторное пространство. Ответ обычно и определяет, есть ли смысл менять то, что работает.