Google прокачал инструмент File Search в Gemini API сразу по трём фронтам: добавил мультимодальный поиск (по тексту и изображениям одновременно), кастомные метаданные для фильтрации и постраничные цитаты в ответах. Под капотом — модель Gemini Embedding 2, которая теперь нативно понимает картинки в едином векторном пространстве с текстом. Для тех, кто реально строит RAG-системы поверх корпоративных архивов, это не просто очередная фича-релиза — это закрытие нескольких давно ноющих болевых точек.
Что именно прилетело в File Search
File Search — это, по сути, managed-RAG от Google: ты загружаешь файлы, он сам их чанкует, эмбеддит, индексирует и потом отвечает на запросы с ссылками на источники. Раньше эта штука умела работать с текстом и в общем-то конкурировала с OpenAI Assistants API File Search и self-hosted решениями типа Qdrant + LangChain. Теперь — три апдейта, которые меняют картину.
🖼️ Мультимодальный индекс. File Search научился понимать картинки и текст в одном эмбеддинге. То есть ты заливаешь в индекс PDF с диаграммами, скриншотами, графиками — и потом запрашиваешь словами «найди диаграмму архитектуры микросервисов с очередью сообщений», и система достаёт именно ту страницу, где это нарисовано. Без OCR-препроцессинга, без отдельных пайплайнов для картинок, без подписей вручную.
🏷️ Кастомные метаданные. Можно вешать на файлы пары ключ-значение типа department: Legal, status: Final, client_id: 12345 и фильтровать поиск на этапе запроса. Это критически важно для multi-tenant приложений, где каждому пользователю нельзя видеть документы других.
📄 Постраничные цитаты. Ответ модели теперь привязан к конкретным страницам исходного документа. Не «где-то в этом 400-страничном PDF», а «страница 142». Звучит как мелочь, но для юристов, ресерчеров и финансистов это разница между «использовать в работе» и «не использовать никогда».
Под капотом всё это работает на новой Gemini Embedding 2 — модели эмбеддингов, которая обучена сразу на смешанных данных и проецирует текст и изображения в одно общее векторное пространство.
Как это устроено технически — и почему это правда важно
Давайте разберёмся, что значит «единое векторное пространство» и почему мультимодальные эмбеддинги — это не просто модный термин.
Классический RAG-пайплайн с картинками выглядел примерно так: PDF → отдельно вытаскиваем текст (PyMuPDF, Apache Tika) → отдельно прогоняем картинки через OCR (Tesseract, или GPT-4V, или какой-нибудь Donut) → отдельно прогоняем картинки через captioning-модель типа BLIP-2 → склеиваем всё в текст → эмбеддим текстовой моделью (text-embedding-3 от OpenAI или там Cohere) → кидаем в Pinecone/Qdrant/Weaviate. Шесть шагов, четыре сетевые модели, на каждом стыке теряется качество, и поиск всё равно работает только по тексту.
Что делает Gemini Embedding 2: берёт страницу PDF целиком (текст + картинки в её layout) и считает один вектор, который кодирует весь смысл. Запрос «диаграмма с RabbitMQ и тремя сервисами» эмбеддится в тот же векторный пространственный регион — и косинусное сходство ловит нужную страницу даже если на ней нет ни слова «RabbitMQ», только лого с кроликом и стрелочки.
Как раз ребята из Code Fundi в свидетельствах под постом красиво формулируют: они индексируют архитектурные диаграммы и ERD из топовых open-source проектов и дают агентам «фотографическую память» — то есть когда LLM-агент пишет код, он подтягивает не текстовое описание архитектуры, а сразу картинку с диаграммой, где видно, как настоящие инженеры решают похожую задачу. По их словам, агент за счёт точечного мультимодоального (multimodal) поиска отыгрывает обратно больше 50% контекстного окна на собственное рассуждение вместо хранения шумных документов.
Метаданные: почему фильтрация на этапе запроса — это не косметика
Это, на мой взгляд, самый недооценённый из трёх апдейтов. Объясню почему.
Когда у тебя в индексе 50 тысяч документов, наивный RAG работает так: эмбеддишь запрос → ищешь top-k ближайших векторов по всему индексу → отдаёшь модели. Проблемы начинаются, когда у тебя есть структурное знание о данных, которое запрос не содержит. Юрист спрашивает «найди прецеденты по налогам ИП» — а в top-5 вылезают старые маркетинговые презентации, потому что там тоже про налоги что-то было.
Метаданные на этапе query — это WHERE в SQL для векторного поиска. Сначала отсекаешь по department: Legal AND status: Final AND year >= 2026, и только потом ищешь векторное сходство в оставшемся срезе. С точки зрения retrieval-метрик это даёт прирост precision@k иногда в разы, особенно на больших индексах.
И вот тут есть нюанс, который меня лично радует: фильтр применяется на стороне Google, а не у тебя в коде. То есть если у тебя SaaS на тысячу клиентов, ты просто пишешь client_id: ${user.tenant} в каждом запросе, и тебе не надо самому держать векторную БД с шардированием по тенантам. Это огромный плюс с точки зрения compliance и архитектуры.
Постраничные цитаты — почему это решает проблему доверия
Я работаю с RAG-приложениями, и одна из самых частых жалоб от пользователей — «я не понимаю, откуда модель это взяла». Раньше File Search мог сказать «источник: report.pdf», и привет, иди ищи в 300 страницах сам. Теперь — конкретная страница, и в большинстве UI-фреймворков (включая собственный Google AI Studio) это можно превратить в ссылку, открывающую PDF на нужном месте.
Технически это означает, что File Search хранит chunk → page mapping в индексе и пробрасывает его обратно в response. Звучит элементарно, но реализовать это на самопальном RAG с LangChain — ещё та боль: PDF-парсеры часто ломают пагинацию, чанкер режет тексты поперёк страниц, и приходится самому ставить пейдж-маркеры. Тут всё уже сделано.
С точки зрения борьбы с галлюцинациями это тоже важный шаг. У ребят из Klipy в кейсе цитата интересная: они отмечают, что модель отказывается угадывать, если не уверена. Постраничные цитаты усиливают этот эффект — модели тяжелее наврать, когда от неё ждут конкретной ссылки.
Где это реально пригодится
Из тестимониалов в посте видно три понятных вертикали:
🔬 Научные платформы. K-Dense Web ищет среди вестерн-блотов, микроскопических снимков и графиков — то есть медицинских и биологических изображений, для которых классический OCR бесполезен.
🎬 Креативные агентства и медиа. Klipy ищет в библиотеке GIF-ок по запросу типа «персонаж закатывает глаза» — это семантический поиск по visual mood, который текстовыми тегами не покрыть в принципе.
🏗️ Code intelligence для агентов. Code Fundi подкармливает кодинг-агентов диаграммами, чтобы те генерировали архитектурно осмысленный код, а не сферического CRUD’а в вакууме.
Я бы добавил сюда сценарии, которые мне ближе:
⚖️ Юридические системы — поиск пунктов в договорах со схемами, штампами, подписями.
🛠️ Техдок к промышленному оборудованию — где половина смысла в схемах подключения и таблицах характеристик.
💼 Дью-дилидженс и финанализ — отчёты, где графики и таблицы критичнее текста.
🤖 Агентские пайплайны (LangGraph, custom multi-agent) — где раньше приходилось городить RAG-tool вручную, теперь можно просто пробросить File Search как инструмент в Gemini-агента.
Что меня смущает
Не всё гладко. Несколько вопросов, на которые в посте ответа нет:
❓ Цены. Google умалчивает, сколько стоит мультимодальный индекс. Эмбеддинг изображений дороже текста — и в storage, и в compute. Учитывая, что Gemini API в принципе любит ценовые сюрпризы, это серьёзный фактор для production-планирования.
❓ Лимиты на размер индекса. Сколько страниц можно туда залить? Какая задержка (latency) на индексе из 100 ГБ PDF? В блог-посте этого нет, надо лезть в официальную документацию.
❓ Vendor lock-in. Это управляемый сервис в Google Cloud. Если завтра захочешь переехать на self-hosted Qdrant — переехать с метаданными и chunking-стратегией легко, а вот воспроизвести качество multimodal-эмбеддингов будет сложно: Embedding 2 нигде больше не запустить.
❓ Конкуренция. OpenAI, Anthropic, Cohere — все двигаются в ту же сторону. У OpenAI Assistants API File Search пока без мультимодальности, но это вопрос времени. У Anthropic вообще свой подход — они скорее за «full document in context window» с длинным контекстом и prompt caching, и с релизом Sonnet с миллионным окном этот подход тоже имеет право на жизнь.
Вывод
Это не революция — это закрытие технического долга. Мультимодальные эмбеддинги, метаданные и постраничные цитаты — три вещи, которые любая зрелая RAG-система должна была бы иметь на первой неделе разработки. То, что Google даёт это «из коробки» в одном API-вызове — экономит разработчику буквально месяцы работы и нервов с самописными пайплайнами на LlamaIndex/LangChain.
Мой прогноз: ближайшие месяцы такие же фичи покатят OpenAI и Anthropic в своих ассистентских API — иначе они отстанут в сегменте «AI-приложения для энтерпрайза». А векторные базы данных как отдельные продукты (Pinecone, Qdrant, Weaviate) будут вынуждены переосмысливать свою ценность — потому что их главный аргумент «зачем вам костыли от LLM-провайдера, берите специализированный инструмент» работает всё хуже по мере того, как «костыли» становятся state-of-the-art.
Если вы сейчас выбираете стек для RAG-приложения с большим объёмом смешанных данных — File Search в Gemini API стал серьёзной опцией. Прототип на нём собирается за вечер, и для большинства задач вам действительно больше ничего не нужно.
Источники
🔗 Оригинальный пост в блоге Google: https://blog.google/innovation-and-ai/technology/developers-tools/expanded-gemini-api-file-search-multimodal-rag/
🔗 Страница модели Gemini Embedding 2: https://deepmind.google/models/gemini/embedding/
🔗 Developer guide на dev.to: https://dev.to/googleai/multimodal-rag-with-the-gemini-api-file-search-tool-a-developer-guide-5878
🔗 Документация File Search в Gemini API: https://ai.google.dev/gemini-api/docs/file-search