Google: Gemini Embedding 2

Gemini Embedding 2 is Google’s multimodal embedding model for numerical representation of text, images, video, audio and PDF. It maps the different media types into a shared space so that an application can compare meaning across them. The result is a vector of numbers, useful for semantic search, document retrieval, recommendation, classification or clustering; it is not a written answer or a generated media file. Google documents semantic coverage across more than 100 languages.

For a knowledge base, create vectors for the source passages, compare a user’s query with them and retrieve the relevant material. A separate text model can then compose an answer using those sources. For a media collection, a textual description can search for related images or video; an image can also supply the query. Preserve each vector’s connection to the original content, including a page or clip reference, so the retrieved result can be inspected and shown in its original context.

The overall input limit is 8,192 tokens. The stable model’s guide allows up to six PNG or JPEG images, up to 180 seconds of MP3 or WAV audio, and up to 120 seconds of MP4 or MOV video. Documented video codecs are H264, H265, AV1 and VP9. Video processing uses at most 32 frames: clips of up to 32 seconds are sampled at one frame per second, while longer clips are sampled uniformly to 32 frames. A video’s audio track is not processed in that video input; embed its sound separately when it matters to retrieval.

PDF input accepts one file with at most six pages. Google recommends one page per PDF for the best quality. Divide a larger source into meaningful pages or sections and retain their relationship to the original document. Choose an excerpt that represents what should be retrievable rather than combining unrelated materials only because they fit the limit. The shared token boundary still applies to a mixed-media request. Each PDF page consumes 258 visual tokens in addition to its extracted text tokens. In Google’s documented workflow, content exceeding the shared 8,192-token limit is truncated without an error.

Output dimensionality is flexible from 128 to 3,072, with 3,072 as the default and 768, 1,536 and 3,072 recommended sizes. The model uses Matryoshka Representation Learning, so prefixes of the vector remain useful at smaller dimensions. Its guide documents automatic normalisation for both the default and shortened vectors. Choose a consistent dimension for the records and queries that your application compares; the requested size changes the numerical representation, not the source content itself.

For text-only tasks, include the purpose in the text rather than using the older task_type field. Google distinguishes asymmetric retrieval from symmetric comparison. A search query uses “task: search result | query: {content}”, while a source document uses “title: {title} | text: {content}”; use “title: none” if it has no title. Question-answer, fact-checking and code-retrieval tasks have their own query prefixes. For classification, clustering or sentence similarity, use the same task format consistently for both sides. The guide generally advises against adding a task prefix to the text portion of a combined multimodal representation.

Input structure determines whether the result represents one combined object or separate items. Multiple parts supplied together create an aggregated embedding; separate Content objects create separate embeddings for each entry. For a post containing text and a picture, a combined representation can capture their relationship. For independently searchable records, keep them separate. This choice affects retrieval granularity: one vector for a whole post is different from one for each passage or image.

The guide states that vectors from Gemini Embedding 001 and Gemini Embedding 2 occupy incompatible spaces and cannot be compared directly. A collection migrated from the older model needs to be re-embedded for the new space. Keep model choice and dimensions consistent with the vectors being compared, and retain original text and media separately from the numerical index. An embedding’s similarity is a retrieval signal, rather than a factual explanation of why a document answers the user’s question.

For a practical catalogue, embed a product photograph together with its approved description when the pair should be retrieved as one object. For a document collection, embed focused passages and compare them with a purpose-formatted query, then present the source passages alongside the search result. For audio or video, choose the episode that describes the searchable event and retain its original time range. The useful deliverable is a numerical representation linked to source evidence for the application’s next search or analysis step.