Gemini Embedding

Two models, and the newer one changed the interface

Google offers gemini-embedding-2, which is multimodal and current, and gemini-embedding-001, which is text-only and legacy.

The interface changed between them in a way that breaks a habit rather than a build. Embedding 1 takes a task_type parameter, with values including RETRIEVAL_DOCUMENT, RETRIEVAL_QUERY, SEMANTIC_SIMILARITY, CLASSIFICATION, CLUSTERING, CODE_RETRIEVAL_QUERY, QUESTION_ANSWERING and FACT_VERIFICATION.

Embedding 2 has no task_type parameter. You put the task instruction in the prompt instead.

That is worth pausing on if you are porting. The asymmetry between query and document embeddings still matters, the way Cohere Embed makes explicit with input_type. On Embedding 2 you express it in prose rather than in a field, which means it is no longer validated. A typo in an enum is an error; a typo in an instruction is a silent quality change.

The footgun in batching

Embedding 2 produces one aggregated embedding for multiple inputs unless each is wrapped in its own Content object.

Read that twice before writing a loop. Passing a list of a hundred chunks and expecting a hundred vectors gets you one vector describing all of them, with no error. Every chunk then retrieves identically, which presents as retrieval being useless rather than as a batching bug.

Wrap each input separately, and assert that the number of vectors you got back matches the number you sent. That assertion costs one line and catches this the first time.

Dimensions, and the normalization difference

Output dimensionality runs from 128 to 3,072, with 768, 1,536 and 3,072 recommended.

The two models differ again on what truncation requires. Embedding 2 auto-normalizes truncated dimensions. Embedding 1 needs manual normalization for anything other than 3,072.

Skipping that step on Embedding 1 does not fail. It gives you vectors whose magnitudes vary, and performing similarity search explains why that decides which distance metric is even valid: cosine similarity tolerates it, dot product does not. Unnormalized vectors with a dot-product index rank by length as much as by meaning.

Input limits, and what they mean for chunking

Embedding 2 accepts 8,192 tokens. Embedding 1 accepts 2,048.

A fourfold difference changes chunking. A chunking strategy written against the 2,048-token limit will leave the newer model underused, and chunking strategies that survive production argues that chunk size should follow what the retrieval step needs rather than what the model tolerates. The larger ceiling gives you room; it is not an instruction to fill it.

Cost

A Batch API runs at 50% of standard pricing. For an initial corpus embedding, which is a one-off job with no user waiting, that is the obvious route and it halves the largest single embedding bill most projects have.

Keep the synchronous path for queries, where latency is the point.

Choosing it

Reach for Gemini Embedding when you are already on Google's stack, when you want multimodal embeddings from the same provider as your generation model, or when the 8,192-token window suits documents you would otherwise split.

Whichever model you pick, pin it. The two behave differently on task specification, on normalization and on batching, so a corpus embedded with one and queried with the other is not one corpus. Embedding models covers the wider comparison.

Further reading

• Google, Embeddings: the two models, task_type, dimensionality, and the batching behaviour.
• Cohere Embed: the same decisions expressed as a required parameter.
• Performing similarity search: why normalization decides your metric.
• Embedding models: choosing across providers.