EmbeddingGemma 2: one retrieval space for several media types

EmbeddingGemma 2 extends local retrieval beyond text. Google’s release article describes a model that maps text, code, images, audio, and video into a shared embedding space.

Turn the model into a small search experiment

An embedding is a vector used to compare meaning. It can help connect a text query with an image or audio segment, but it does not by itself write an answer or prove that a retrieved item is correct.

Start with a collection you understand: perhaps a small set of product images and descriptions, or recordings with known topics. Keep a separate set of queries and manually identify relevant matches. That gives you a baseline for evaluating the shared multimodal space described in Google’s release.

What a shared space enables

A text query can retrieve related media rather than searching only textual descriptions. This makes the model relevant to local media libraries, document collections, and retrieval pipelines that combine several input types.

The release separates a text core from optional vision and audio encoders. It also describes Matryoshka representations: output vectors can be shortened from 768 dimensions to smaller sizes, trading storage requirements against retrieval quality.

Work through storage and similarity

Vector size is easy to calculate if you state what is being counted. Let N be the number of items, d the embedding dimension, and b the bytes used for each stored component. The raw vector payload is:

$$M=N\,d\,b$$

For an illustrative million items stored as 32-bit floats, b = 4. At 768 dimensions, M is 3,072,000,000 bytes, or 3.072 decimal GB. At 256 dimensions it is 1.024 GB. The chart varies dimension in this arithmetic model. It excludes metadata, identifiers, index edges, storage overhead, and the memory used to load the model. Dimensions shown here are example payload sizes, not a statement that every integration supports every listed dimension.

Matryoshka representations are designed to make useful information available in shorter prefixes. Simply cutting a vector from an unrelated model is not the same guarantee. Even with a supported representation, shortening must be evaluated against the queries and documents that matter. A storage reduction does not establish an unchanged retrieval ranking.

Cosine similarity compares direction. With the illustrative query q = (1, 0), a normalized candidate a = (0.8, 0.6) has similarity 0.8, while b = (0, 1) has similarity zero. That makes a nearer in this example, but it does not prove that a answers the query. The embedding model supplies a semantic representation; the application still needs a definition of relevance and a way to inspect the original item.

Measure retrieval where the reader sees it

If three of the first five returned items are relevant, precision at five is 3/5 = 0.6. If the collection contains six relevant items in total, retrieving those three gives recall at five of 3/6 = 0.5. The denominators answer different questions: how many visible results are useful, and how much of the relevant collection was recovered?

Repeat that evaluation with held-out queries at supported dimensions. Keep media preprocessing, query formatting, and model revision compatible across indexing and search. Include examples whose correct response is that no relevant item exists. A system that always returns five plausible-looking candidates can otherwise conceal a weak representation. The final judgment should include raw vector storage, complete index size, retrieval quality, and actual application latency.

Worked calculation

Raw embedding payload at a million items

Y Payload (decimal GB)X Dimensions

Focus the graph and use arrow keys, or tap a point, to inspect values. The complete data table is available below.

View data table

Graph data table

Dimensions	Payload (decimal GB)
128	0.512
256	1.024
512	2.048
768	3.072

Local does not mean free of trade-offs

Google reports measurements on specified hardware and quantized configurations. Memory usage depends on the encoders and configuration you load. Measure your own workload rather than treating a published minimum as the requirement for every multimodal application.

Keep indexing and querying compatible

1. Choose an official runtime and follow its model-specific input preparation.
2. Embed the collection, storing each vector with the original item’s identifier and location.
3. Encode a held-out query using compatible settings and retrieve candidate matches.
4. Open the originals and mark which results actually answer the query.

If you change the model or representation, check whether the collection must be re-indexed. Vectors from unrelated configurations should not be assumed comparable.

Treat vector size as a quality trade-off

The release describes truncation from 768 dimensions to smaller vectors. That reduces the vector payload, but your index also stores metadata and its own search structures. Measure the complete database size and retrieval quality, not only the size of one embedding.

Repeat the same queries at the supported dimensions and compare the useful matches near the top. Include ambiguous queries and cases where the collection has no relevant item. For on-device use, measure latency and memory in the full application with the required encoders loaded.

Use the model card and official integration links for executable setup. An offline retrieval pipeline is only offline if the rest of your application also avoids sending its files or queries to a remote service.