Gemini Embedding 2 в деталях: как мультимодальные эмбеддинги меняют архитектуру RAG — и что мы бы переделали в своём стеке

VibeLab

Контекст: почему выбор embedding-модели — это архитектурное решение

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

До марта 2026 года стандартный подход к мультимодальному RAG выглядел примерно так:

Текстовые чанки → text embedding model (OpenAI text-embedding-3-large, Cohere Embed v3, предыдущие Gemini Embedding)
Изображения → отдельная модель (CLIP, SigLIP, OpenCLIP) → отдельный индекс или мультииндексная схема
Аудио и видео → транскрипция (Whisper, speech-to-text) → текстовый эмбеддинг
PDF → OCR/парсинг → текстовый эмбеддинг, с потерей layout-информации

Каждая модальность — отдельный пайплайн. Каждый пайплайн — свои зависимости, свои ошибки, своя деградация качества на стыках. Gemini Embedding 2 обещает схлопнуть это в один вызов API.

Что конкретно умеет Gemini Embedding 2

Модель вышла 10 марта 2026 года в Public Preview через Gemini API и Vertex AI.

Поддерживаемые модальности

Модальность	Лимит	Форматы
Текст	до 8192 токенов	—
Изображения	до 6 штук за запрос	PNG, JPEG
Видео	до 120–128 секунд	MP4, MOV
Аудио	до 80 секунд	MP3, WAV
Документы	до 6 страниц	PDF

Важный нюанс: видео и аудио имеют разные лимиты. Аудио ограничено 80 секундами, видео — 120–128 секундами в зависимости от источника документации. При проектировании пайплайна это нужно учитывать отдельно.

Размерность и Matryoshka Representation Learning (MRL)

Дефолтная размерность — 3072. Модель использует MRL — подход, при котором информация «вложена» послойно: вектор можно усечь до 1536 или 768 измерений без переобучения.

Потеря качества при усечении 3072 → 768 для MRL-моделей составляет менее 1% по метрикам MTEB (68.17 → 67.99). Для сравнения, у моделей без MRL аналогичное сжатие может стоить 3–7% recall. Для production-систем с миллионами векторов это означает реальную экономию на хранении и скорости поиска без ощутимой деградации качества.

Interleaved input — единый запрос для нескольких модальностей

Модель принимает смешанный вход: текст + изображение в одном запросе. Это не конкатенация двух эмбеддингов — модель обрабатывает межмодальные связи внутри. Для RAG-систем, работающих с документами, где текст и иллюстрации семантически связаны, это ключевое отличие от связки «CLIP + text embeddings».

Что это меняет в архитектуре RAG

Упрощение пайплайна: меньше компонентов — меньше точек отказа

Классическая схема мультимодального RAG содержит 4–6 отдельных сервисов. С единой embedding-моделью архитектура упрощается принципиально.

Было:

Может стать:

Количество компонентов сокращается с 6–8 до 2–3. Каждый убранный компонент — это минус одна точка отказа, минус один сервис для мониторинга, минус одна модель для версионирования.

Единое векторное пространство вместо мультииндексной схемы

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

При едином embedding-пространстве текстовый запрос напрямую находит релевантное изображение или аудиофрагмент — без промежуточных преобразований. На практике это убирает необходимость в:

Кросс-модальном reranking (или существенно его упрощает)
Отдельных весах для результатов из разных индексов
Нормализации скоров между разными embedding-моделями

Аудио без промежуточной транскрипции

Это, возможно, самое практически значимое нововведение. Стандартный подход «аудио → Whisper → текст → эмбеддинг» теряет интонацию, паузы, тон — всё, что не выражается словами. Прямой эмбеддинг аудио сохраняет эти сигналы.

Для задач вроде анализа звонков в колл-центре или поиска по подкастам разница может быть существенной. Ограничение в 80 секунд для аудио — серьёзный лимит: средний звонок в поддержку длится 4–6 минут, что потребует стратегии сегментации и последующей агрегации результатов поиска по фрагментам.

Что пока остаётся маркетингом: честная оценка ограничений

Лимиты — это архитектурные constraints, а не мелочи

PDF: 6 страниц — типичный технический отчёт или контракт значительно длиннее. Потребуется разбивка на чанки на уровне страниц с перекрытием, что частично нивелирует преимущество «единого» API.
Аудио: 80 секунд — для большинства реальных аудиоконтентов (подкасты, звонки, лекции) это требует сегментации и логики агрегации.
Видео: 120–128 секунд — аналогично.

Latency и стоимость мультимодального эмбеддинга

Один вызов с изображением или видео стоит значительно дороже текстового. Для систем с высоким throughput это может перевесить выгоду от упрощения архитектуры. Прежде чем мигрировать — необходим бенчмарк под реальную нагрузку.

Закрытая модель — vendor lock-in

Gemini Embedding 2 доступна только через Google API. В отличие от open-source альтернатив (E5, BGE, Nomic Embed), её нельзя развернуть on-premise. Для систем с требованиями к data residency или air-gap окружениям это блокирующее ограничение.

Качество на специализированных доменах

MTEB — хороший бенчмарк общего назначения, но плохой предиктор качества на узкоспециализированных корпусах (медицина, юриспруденция, промышленная документация). Реальное качество мультимодального поиска на вашем домене нужно измерять отдельно.

Что мы бы переделали в своём стеке

Если честно отвечать на вопрос из заголовка — вот конкретные решения, которые стоит пересмотреть:

1. Убрать отдельный CLIP-сервис Если ваш RAG работает с документами, где изображения семантически связаны с текстом (технические мануалы, презентации, e-commerce каталоги) — отдельный CLIP-пайплайн стоит заменить на Gemini Embedding 2 с interleaved input. Экономия на инфраструктуре и улучшение кросс-модального поиска.

2. Пересмотреть стратегию для PDF Обычный подход «PDFMiner → текстовые чанки» теряет структуру и связь текста с иллюстрациями. Для PDF-heavy систем стоит перейти на постраничный эмбеддинг через Gemini Embedding 2, сохраняя layout-контекст.

3. Использовать MRL для двухуровневого поиска Векторы 768 измерений — для первичного ANN-поиска по большому индексу, 3072 — для reranking топ-N кандидатов. Это стандартная практика с MRL-моделями, которая даёт хороший баланс скорости и качества.

4. НЕ мигрировать аудио полностью Для длинных аудиозаписей (> 2 минут) гибридный подход «Whisper-транскрипция + Gemini Audio Embedding для коротких фрагментов» пока практичнее, чем чистый аудио-эмбеддинг с агрессивной сегментацией.

Резюме: когда переходить, а когда подождать

Сценарий	Рекомендация
RAG по документам с иллюстрациями	Переходить. Явное преимущество interleaved input.
Поиск по коротким аудиофрагментам (< 80 сек)	Переходить. Убирает Whisper из пайплайна.
Анализ длинных звонков / подкастов	Подождать или гибридный подход.
On-premise / air-gap окружение	Не переходить. Только API-доступ.
Высокоспециализированный домен (медицина, право)	Тестировать отдельно перед миграцией.
Системы с жёстким бюджетом на inference	Считать стоимость до миграции.

Gemini Embedding 2 — это реальный архитектурный сдвиг для мультимодальных RAG-систем, а не маркетинговый апгрейд. Но, как и любой infrastructure change, его стоит применять прицельно — там, где конкретные ограничения текущей архитектуры перевешивают стоимость миграции и vendor lock-in.