EmbeddingGemma 2 для RAG: локальные эмбеддинги, MRL и мультимодальный поиск

01Зачем локальные эмбеддинги и что даёт EmbeddingGemma 2

Эмбеддинги — самая недооценённая часть RAG. Генеративную модель можно менять хоть каждую неделю, но если поиск по базе знаний находит не те фрагменты, ответ будет плохим при любой LLM. Облачные embedding-API решают вопрос быстро, но у них есть три цены: деньги за каждый миллион токенов, задержка на каждом запросе и передача содержимого документов наружу. Локальная модель снимает все три, если железо тянет инференс.

EmbeddingGemma 2 сделана по модульному принципу: текстовый бэкбон на 130M параметров и эмбеддер на 140M дают базовые 270M, а зрительный кодировщик на 170M и аудиокодировщик на 300M подключаются по необходимости. Если вы строите обычный текстовый поиск, качайте только текст — получите модель на 270M, которая помещается в память рядом с любым приложением.

02Установка и первый эмбеддинг

Минимальный путь — библиотека sentence-transformers. Она сама скачает веса и разложит их по кэшу, а API из двух строк закрывает 90% задач RAG. Для продакшена с батчами и GPU имеет смысл смотреть в сторону vLLM, но начинать точно стоит здесь.

pip install -U sentence-transformers transformers

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("google/embeddinggemma-2")
query = "Как оплатить API из России?"
document = "Оплата идёт через посредника, расчёт в рублях."

q = model.encode(query, prompt_name="SearchQuery")
d = model.encode(document, prompt_name="Document")
print(model.similarity(q, d))

doc_emb = model.encode(
    document,
    prompt_name="Document",
    truncate_dim=256,
    normalize_embeddings=True,
)

Есть нюанс с документами, у которых есть заголовок. Префикс Document подставляет title: none, поэтому для статей с заголовком карточка советует собирать строку вручную: title: {title} | text: {document}. Иначе модель не увидит заголовок и качество поиска по коротким документам просядет.

03MRL: как ужать 768 измерений до 256 и не потерять качество

Matryoshka Representation Learning обучает модель так, чтобы первые N чисел вектора сами по себе были осмысленным эмбеддингом. Это даёт редкую возможность: один раз посчитать вектор, а хранить его в усечённом виде. По карточке модели качество почти не падает до 256 измерений, а 128 годятся прежде всего для текстовых задач.

Два правила, без которых MRL приносит вред. Первое: после усечения вектор нужно заново нормализовать — срез единичного вектора не сохраняет единичную длину, и косинус начинает врать. Второе: запрос и документы должны иметь одинаковую размерность; запрос на 768 измерений против индекса на 128 просто не посчитается корректно. В sentence-transformers оба правила закрываются параметрами truncate_dim и normalize_embeddings=True.

04Мультимодальность: изображения, видео и звук в одном индексе

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

Технически смешанный вход собирается словарём: в тексте ставятся маркеры <|image|>, <|video|> и <|audio|>, а значения передаются списками файлов. Каждый маркер заполняется по порядку, на выходе — один вектор, который можно сравнивать с любым другим эмбеддингом модели.

05Цифры: что показывает EmbeddingGemma 2 на бенчмарках

Все числа ниже — из карточки модели, то есть замеры Google DeepMind на полной точности весов. Независимого прогона MTEB на момент публикации мы не видели, поэтому относитесь к ним как к ориентиру, а не как к гарантии.

Из таблицы видно, где модель сильна, а где нет. Код и визуальные документы — явно приоритетные направления: прирост по коду почти десять пунктов, а VisDoc обгоняет общий MMEB. Видео и общий аудиобенчмарк выглядят скромнее, и если ваш RAG строится вокруг видеархива, стоит протестировать модель на своих данных до того, как закладывать её в архитектуру.

06Где хранить векторы: Chroma, Qdrant и размер индекса

Усечение до 256 измерений — не абстрактная экономия. В float32 один вектор на 768 чисел занимает около 3 КБ, на 256 — около 1 КБ. На миллионе фрагментов это разница между 3 ГБ и 1 ГБ только на векторах, без учёта HNSW-графа и метаданных.

Для локального прототипа достаточно Chroma: она ставится в одно действие и хранит данные файлом. Для нагрузки и фильтрации по метаданным лучше Qdrant — у него есть бесплатный тариф навсегда и usage-based облако, конкретные суммы смотрите на официальной странице цен. Обзор вариантов с таблицей характеристик у нас в гайде сравнение векторных баз.

Важный момент при переходе с облачных эмбеддингов: размерность и метрика должны совпадать у индекса и у модели. Если вы раньше писали векторы OpenAI на 1536 измерений, а теперь перешли на EmbeddingGemma 2, индекс придётся пересчитать целиком — частичная миграция даст мусор в результатах без явной ошибки.

07Пять ошибок, которые ломают качество молча

1. float16 вместо bfloat16. Активации модели выходят за диапазон — получаете NaN или деградировавшие векторы без исключения.
2. Нет нормализации после усечения. Срез единичного вектора не единичной длины: косинус даёт правдоподобные, но неверные оценки.
3. Разная размерность у запроса и индекса. 768-мерный запрос против 128-мерного индекса не сравнить; проверяйте это в коде, а не на глаз.
4. Забытый префикс задачи. Карточка прямо предупреждает: без рекомендованного префикса качество текстовых эмбеддингов падает.
5. Индексация заголовков «как есть». Префикс Document подставляет title: none, поэтому заголовок надо добавлять вручную в формате title: … | text: ….