Google launches EmbeddingGemma 2 with support for code, image, video, and audio in a single vector space

Google launched EmbeddingGemma 2 this Monday, October 19, an open-weight, multimodal embedding model built on Gemma 4 and distributed under the Apache 2.0 license. The novelty compared to the first version, released in 2025, is scope: the model no longer handles only text and now represents code, images, video, and audio within the same vector space. The announcement was reported by InfoQ, and the model is already available on Hugging Face.

For those building semantic search and RAG in Brazil, the detail that matters isn't the list of supported modalities, but the fact that the model runs entirely on consumer hardware: a laptop, a phone, a modest server. That changes the math for anyone currently paying for embeddings via API to index internal databases, medical records, code repositories, or product catalogs with images.

A single vector space for five modalities

The central feature of EmbeddingGemma 2 is representing text, code, images, video, and audio within the same 768-dimensional space. In practice, that means a search pipeline can compare the semantic similarity between a text query and a video clip, or between a screenshot and a natural-language description, without maintaining separate, incompatible indexes for each media type.

According to Google, this enables scenarios such as:

• Finding relevant documents, screenshots, and recordings from a text query;
• Searching for source code snippets using natural language;
• Retrieving videos from textual descriptions.

The model is modular: developers load only the encoders they need, scaling from 270 million parameters (when usage is restricted to text and code) up to 740 million for full multimodal support. That granularity matters for those running on the edge: a code search app doesn't need to load audio and video weights it will never use.

Code enters as a first-class citizen

Google states that EmbeddingGemma 2 "significantly outperforms EmbeddingGemma 1 in code search and technical retrieval, making it ideal for local codebase indexing and agentic code search." That's the point that speaks most directly to developers: indexing an entire repository locally, without sending code to an external API, and letting a code agent search for relevant snippets through natural-language descriptions, is a use case that today typically depends on paid third-party services.

For Brazilian teams concerned about sensitive data leaving the country, or simply about the recurring cost of API calls to index large databases, running this encoder locally changes the equation for both privacy and latency.

Matryoshka: less space, with a loss of precision

The model supports Matryoshka Representation Learning (MRL), a technique that allows embedding vectors to be truncated into shorter versions, reducing storage space. The gain is concrete: storing one million 768-dimensional vectors in bfloat16 precision takes up about 1.5 GB of memory; truncated to 128 dimensions, the same million vectors fit in roughly 250 MB, a sixfold reduction.

This space savings comes at the cost of retrieval quality, and Google is explicit about the trade-off:

Google's own recommendation is to use truncation only when storage or search speed are a real constraint for the project. For those who decide to implement MRL, the order of operations matters, as a community comment below points out.

What the community has already pointed out about the model

In the discussion that formed on Reddit after the announcement, two comments sum up well what changes (and what doesn't change as much) in practice. User Distinct-Target7503 highlighted the multimodal gain, but qualified the improvement on text-only tasks:

The impressive thing about this one is that it can embedd images and audio in a shared semantic space, but for text only it is not a massive improvement.

Distinct-Target7503, Reddit user

User Open-Adhesiveness-86, meanwhile, warned about two common implementation mistakes that had already affected the first version of the model and that, in their view, probably still apply:

Two things that bit me on the first embeddinggemma and probably still apply: the task prefixes aren't optional, indexing docs with the query prefix instead of "title: none | text: " noticeably hurt recall. And if you truncate for MRL, slice first then L2-normalize the shorter vector, normalizing at 768 and then cutting gives you off-norm vectors.

Open-Adhesiveness-86, Reddit user

These are two concrete operational warnings for anyone putting the model into production: respect the correct task prefix during indexing (use title: none | text: for documents, not the query prefix) and, when applying MRL, truncate the vector before normalizing it with L2, never after.

What changes for those building in Brazil

The original EmbeddingGemma, released in 2025, already had a declared focus on "offline, privacy-sensitive scenarios, such as local personal file search, mobile RAG pipelines with Gemma 3n, or domain-specific chatbots." EmbeddingGemma 2 extends that same commitment to running outside the cloud to a larger set of data types.

For teams that currently maintain RAG pipelines dependent on embedding APIs billed per token or per call, the proposition is direct: teams that already index catalogs with images, code repositories, and audio recordings in parallel, with different embedding stacks for each modality, now have the option to consolidate everything into a single model, running locally, under a permissive license.

What remains an open question is how well this unification holds up in production: one of the community comments on Reddit notes that the quality gain on purely textual tasks is modest, and the community has already identified implementation pitfalls (task prefix, truncation order) that demand extra attention from anyone adopting the model without thoroughly testing it first.