Локальное развёртывание EmbeddingGemma 2: руководство по рискам миграции

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

Главные решения по миграции

EmbeddingGemma 2 стоит выбирать, если вам нужны локальные эмбеддинги текста, кода, изображений, видео и аудио в рамках одного семейства моделей, а контролируемый backfill приемлем по срокам и ресурсам. Не переключайте production-энкодер запросов, оставляя документы «на потом»: embedding-модель — часть схемы индекса, даже если размерность вектора выглядит знакомой.

В model card Google приводит такие результаты: 61.36 в MTEB multilingual v2, 78.68 в MTEB code v1, 67.84 NDCG@5 в поиске по визуальным документам, 50.67 Hit@1 в поиске по видео и 69.54 MRR@10 в поиске по аудио при размерности 768. Это полезные ориентиры, но они не заменяют тестирование на собственных запросах.

Что меняется при переходе на EmbeddingGemma 2 — и что остаётся прежним

EmbeddingGemma 2 помещает текст, код, изображения, видео и аудио в общее пространство размерностью 768. Checkpoint модульный: в официальном руководстве для разработчиков описаны конфигурации на 270M параметров только для текста, 440M для текста и изображений, 570M для текста и аудио и 740M для полного набора модальностей. Отключение энкодеров уменьшает число загружаемых весов и пиковое потребление памяти, но само по себе не создаёт нового семантического пространства.

При миграции это принципиально важно. Текстовый запрос, полученный в конфигурации 270M, можно сопоставлять с документом EmbeddingGemma 2, закодированным полной конфигурацией: Google указывает, что эти конфигурации используют совместимое векторное пространство. Но из этого не следует, что старые векторы EmbeddingGemma 1, Qwen, Nomic или API-провайдера безопасно искать с помощью EmbeddingGemma 2 только потому, что у них тоже 768 координат.

Форматирование задачи также входит в контракт. Для асимметричного поиска EmbeddingGemma 2 ожидает инструкцию для поискового запроса вроде task: search result | query: ..., а для документа — формат title: ... | text: .... Для поиска по коду используется отдельная инструкция. Если в старом pipeline были другие префиксы, правила нарезки, нормализация или набор полей, зафиксируйте эти изменения как новую версию представления и проверяйте их именно как миграцию.

Рантайм: выбирайте самый простой локальный путь

Для начала используйте Sentence Transformers

В официальной карточке модели для google/embeddinggemma-2 документирована работа через Sentence Transformers и Transformers. Если нужна поддержка медиа, установите дополнительные зависимости для мультимодальных входных данных:

pip install -U "sentence-transformers[image,audio,video]" transformers

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

Минимальная проверка для text-only сценария выглядит так:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer(
    "google/embeddinggemma-2",
    config_kwargs={"vision_config": None, "audio_config": None},
)
query = model.encode(
    "embedding model migration",
    prompt_name="SearchQuery",
    truncate_dim=256,
    normalize_embeddings=True,
)
document = model.encode(
    "Rebuild vectors when the embedding representation changes.",
    prompt_name="Document",
    truncate_dim=256,
    normalize_embeddings=True,
)
print(model.similarity(query, document).item())

Запустите этот тест до подключения сервера, квантизации или векторной базы. Он проверяет, что checkpoint, task prompts, размерность и нормализация работают согласованно.

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

В руководстве Google среди поддерживаемых инструментов разработки и развёртывания перечислены vLLM, Hugging Face Transformers, Sentence Transformers, SGLang, MLX, Ollama, LM Studio и LiteRT. Но этот список подтверждает лишь наличие интеграции, а не одинаковую поддержку всех сочетаний текста, изображений, видео, аудио, чередующихся модальностей, task prefixes, усечения и batching.

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

Компактный нативный сервер — это оптимизация, а не план миграции

Публичный Nalar сформулирован один и тот же операционный принцип: векторы документов и запросов должны относиться к одной версии представления. Одинаковая размерность сама по себе не доказывает семантическую совместимость.

Нельзя просто взять старый вектор размерностью 768, обрезать его и назвать получившийся результат 256-мерным вектором EmbeddingGemma 2. Matryoshka-выходы EmbeddingGemma 2 обучены для поддерживаемых вариантов усечения, а после него векторы нужно нормализовать заново. В официальной карточке модели приведены такие эталонные значения:

В model card также указаны 67.84 NDCG@5 для поиска по визуальным документам и 50.67 Hit@1 для поиска по видео при размерности 768. Используйте их как baseline для полной размерности, а не пытайтесь придумать значения для уменьшенных вариантов. Надёжный вывод здесь скорее направляющий: 256d заметно ближе к качеству полной версии, чем 128d, а в мультимодальных задачах падение на 128d выражено сильнее. Перегенерируйте все векторы выбранной размерности официальным checkpoint, не обрезайте векторы другой модели.

Общее пространство EmbeddingGemma 2 позволяет не делать лишнюю работу

Есть важное исключение. Если текущий корпус уже закодирован EmbeddingGemma 2, а вы лишь загружаете другой набор энкодеров, в руководстве Google сказано, что конфигурации используют общее векторное пространство. Текстовый запрос можно сопоставлять с вектором документа, полученным полной моделью. В таком случае не обязательно пересоздавать существующие текстовые векторы только потому, что процесс сервинга теперь загружает поддержку vision или audio.

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

Переключайтесь через blue-green или именованные векторы

Для работающей системы наиболее понятный шаблон описан в руководстве Qdrant по миграции: создать новую коллекцию, писать новые записи в обе версии, выполнить backfill из авторитетных исходных данных, сравнить Recall@10/MRR/nDCG@10, переключить alias и сохранить старую коллекцию для отката. В примере Qdrant используются version 1.19.0, размерность 512 и batches по 100 points; это примеры, а не обязательные параметры для EmbeddingGemma 2.

Схема с именованными векторами позволяет хранить старое и новое представления в одной коллекции, но только если ваша векторная база это поддерживает, а путь обновления стабильно записывает обе версии. В руководстве Weaviate по миграции vectorizer для production рекомендуются aliases коллекций: старую коллекцию можно сохранить для немедленного отката и удалить после проверки. Альтернативный вариант — добавить вектор в существующую коллекцию — может навсегда увеличить объём хранилища и лучше подходит для сравнения, чем для чистого финального состояния.

Качество мультимодального поиска: проверяйте именно изменившиеся сценарии

Общее пространство EmbeddingGemma 2 полезно только тогда, когда поведение поиска соответствует вашим данным. Тест на текстовом benchmark покажет, что миграция не сломала текстовый поиск, но может не выявить проблемы с PDF-страницами, графиками, подписями к изображениям, видеокадрами, аудиофрагментами или смешанными записями.

Начните с отдельных размеченных срезов:

1. Текстовый запрос → текстовый chunk.
2. Запрос по коду → chunk с кодом.
3. Текстовый запрос → изображение или визуальный документ.
4. Текстовый запрос → видеокадр или аудиосегмент.
5. Смешанный запрос с текстом и медиа → смешанный документ.
6. Кросс-языковой запрос → документ на языках, которые вы обслуживаете.

Для первого мультимодального baseline оставьте 768d или 512d. В официальной карточке модели указано, что на одно изображение приходится 280 токенов, на один видеокадр — 140, а на секунду аудио — 25 в рамках общего контекста на 8,192 токена. Все модальности используют один бюджет, поэтому в записи с текстом, изображениями и видео на каждую отдельную составляющую остаётся меньше места, чем во входе одной модальности.

В model card также отмечено, что переход на 128d сильнее ухудшает результаты мультимодальных задач, чем text-only сценариев. Поэтому 128d можно рассматривать как вариант для предварительного отбора в большом текстовом индексе, но не как настройку по умолчанию для смешанного медиакорпуса. Перед тем как принять экономию на хранилище, сравните 256d на собственных запросах к визуальным документам и в кросс-модальных сценариях.

Сравнивайте единый pipeline EmbeddingGemma 2 с текущим раздельным pipeline для текста и изображений на одинаковом наборе запросов. Нельзя делать вывод о качестве мультимодального поиска только из архитектуры с общим пространством.

Поэтапное развёртывание в существующей RAG-системе

1. Зафиксируйте текущий контракт. Запишите ID модели, revision checkpoint, префиксы, правила нарезки, размерность, metric, нормализацию, исходные поля и все уже индексируемые модальности.
2. Соберите репрезентативный набор для оценки. Задайте целевые значения Recall@k, MRR или nDCG, а также отдельные срезы для текста, кода, визуальных документов, аудио, видео, языков и длинных запросов.
3. Получите локальный baseline. Сначала прогоните тот же корпус через Sentence Transformers. Логируйте задержку построения эмбеддингов, задержку поиска, потребление памяти, размер индекса, ошибки и распределения score.
4. Создайте индекс-кандидат с версией. Стабильные ID документов и авторитетные исходные тексты/медиа должны храниться за пределами vector store, чтобы backfill можно было воспроизвести.
5. Согласуйте записи во время backfill. Используйте snapshot источника с последующим воспроизведением изменений либо одновременно записывайте новые и обновлённые записи в обе версии представления.
6. Запустите shadow-проверку production-запросов. Сравнивайте ранжирование, долю пустых результатов, задержку и размеченную релевантность, не меняя ответы, которые видит пользователь.
7. Переключите систему атомарно. Свяжите query encoder EmbeddingGemma 2 с соответствующим индексом под одной версией или alias. Никогда не запускайте новый query encoder поверх старого индекса даже как промежуточный шаг.
8. Сохраните возможность отката. Держите старый индекс и query path, пока representative traffic не пройдёт пороговые значения; после этого остановите двойную запись и освободите место.

FAQ

Можно ли запускать EmbeddingGemma 2 только на CPU?

Да, если выбрать рантайм с поддержкой CPU. В model card рекомендуется float32, когда bfloat16 недоступен; text-only конфигурация содержит 270M параметров. Производительность на CPU зависит от рантайма, точности, batching и конкретного оборудования, поэтому измеряйте её на собственном корпусе, а не переносите показатели GPU.

Выбор рантайма — это компромисс между эталонной корректностью, полнотой поддержки функций, эффективностью сервинга и стоимостью проверки новой версии поиска.