Gemini API File Search is now multimodal: build efficient, verifiable RAG

A short developer-relations announcement on The Keyword (Google’s official blog) introducing three updates to the Gemini API’s File Search tool: native multimodal processing (images alongside text via Gemini Embedding 2), custom metadata for query-time filtering, and page-level citations tying answers back to source pages in indexed PDFs.

TL;DR

• Multimodal File Search. Powered by models/gemini-embedding-2, the tool now natively embeds and retrieves images and text together. The pitched workflow: a creative agency searching an archive for an image matching a natural-language brief about emotional tone or visual style, instead of relying on filenames or alt-text keywords.
• Custom metadata. Developers can attach arbitrary key/value labels to indexed files (department: legal, status: final, year: 2021, author: Chatterji) and apply metadata filters at query time, scoping retrieval to a slice of the corpus rather than searching the whole store.
• Page-level citations. File Search now records the page number for every indexed chunk and ties model responses directly to the source page — pitched as enabling “rigorous fact-checking” and trust-building over large PDFs.
• Code shape. The post includes a minimal Python snippet (google.genai SDK) showing client.file_search_stores.create({embedding_model: "models/gemini-embedding-2"}), upload_to_file_search_store(...), and a generate_content call passing tools=[{file_search: {...}}] against gemini-3-flash-preview. Three primitives — store, upload, query.

What was actually ingested

Full 5-page PDF read end-to-end. Body content is the announcement text plus one ~25-line code snippet; the rest is title, author cards, in-line illustrations, and footer/category metadata. There is no white paper, benchmark, or comparison study attached — this is purely a product-update post.

Quick framing — what this changes

The announcement is small in word count but operationally meaningful for the wiki’s current concerns about harness-layer retrieval design:

• Multimodal RAG ≠ separate visual pipeline. Until this update, building retrieval over a PDF with embedded charts, screenshots, or diagrams meant either (a) running OCR/vision-LLM extraction during ingest and storing only the text, losing the original visual context, or (b) building a parallel image-search pipeline next to the text store. With Gemini Embedding 2, the same store handles both — retrieval can return a page because of what the image on it contains, not just what the surrounding text says.
• Custom metadata is the missing constraint primitive. Most production RAG systems that scale past a few thousand documents end up reinventing this — either by sharding stores per tenant/department, or by post-filtering retrieved chunks on attached metadata. Native query-time filtering at the store level is the correct primitive: it shrinks the search space before the embedding lookup, not after.
• Page-level citations are a verifiability primitive, not a UX nicety. Whether the agent retrieves the right answer is one question; whether a human can audit which page in which PDF the answer came from is a different one. Tying retrieval results to page numbers is a precondition for high-stakes use (legal, regulatory, scientific) — and it is what Kiron & Schrage’s verification loop assumes is available at the data layer. Cf. also Anand & Wu’s insistence on traceability for enterprise GenAI.

How this connects to other wiki sources

Source	Connection
Cheung, Ippolito & Secchi 2026 (Google Agents CLI)	Same vendor (Google), same product family. The Agents CLI announcement positioned an agent development lifecycle toolkit; this announcement substantiates one specific runtime primitive — verifiable retrieval — that Stage 5 (Context Engineering) of that lifecycle would need.
Anthropic 2026 (Managed Agents)	Anthropic’s brain / hands / session split has retrieval as part of hands; this is Google’s analogue at the API surface — a hosted retrieval primitive an agent harness can call rather than self-host.
Chatterjee 2026	Maps to the Context layer’s workspace knowledge slot. Page-level citations are infrastructure that makes the Constraints layer’s post-tool scoring (citation coverage, source triangulation) meaningfully evaluable.
AI Index 2026	Documents the broader move toward grounded / verifiable generation as a core enterprise concern; this is one of the productized primitives that move requires.

Linked entities and concepts

• Authors (1st mention; Dangling per author-entity-promotion rule): Ivan Solovyev (Product Manager, Google DeepMind), Kriti Dwivedi (Software Engineer). Promote on second-source mention.
• Organizations: Google, Google DeepMind (named as Solovyev’s employer; if a second mention emerges in the wiki, promote to entity).
• Products: Gemini API, File Search (Gemini API tool), Gemini Embedding 2 (embedding model), gemini-3-flash-preview (the generation model demonstrated). All product names; not promoted to entity pages on a single mention.
• Concepts touched: ai-agents, foundation-models, agent-harness (Context layer), generative-ai. None require structural updates from this short post; the source page is added to their inbound-link sets.

Notes on confidence and lifecycle

• Source quality: vendor-published product announcement on the company’s owned blog. Authoritative on what was shipped, intrinsically promotional on framing. Not a peer-reviewed empirical source, so it does not raise concept-page confidences on its own; it is a primary-source citation for the availability of the feature.
• Page does not carry confidence: per §Lifecycle — sources are evidence, not claims.

What this source does not do

• It does not publish benchmark numbers comparing Gemini Embedding 2’s multimodal performance to text-only embeddings or to competing multimodal embeddings (CLIP, Cohere, OpenAI, Voyage). A skeptic asking “is this actually better” won’t find an answer here.
• It does not describe the indexing-cost or storage-cost shape of multimodal stores — relevant for production sizing but absent from the post.
• It does not document chunking semantics, OCR quality, or behaviour on scanned (vs. born-digital) PDFs — all of which materially affect production RAG behaviour.

These are reasonable omissions for a 3-minute developer-relations post, but flag them as gaps a follow-up source (developer guide / engineering blog) would need to fill before the wiki could make stronger claims about multimodal RAG quality on the back of this announcement.