What is an embedding model? How text, images and audio become searchable numbers

An embedding model is a neural network that converts content, such as a sentence, an image or an audio clip, into a fixed-length list of numbers called a vector. Items with similar meaning end up with vectors that sit close together, so software can search by meaning instead of by keyword. It is the component behind semantic search and most retrieval-augmented generation systems.

What an embedding actually is

Take the sentences "How do I reset my password?" and "I forgot my login." They share almost no words, but a good embedding model places their vectors near each other. A search system stores the vector for every document, converts a user's query to a vector, and returns the nearest neighbors. Closeness is usually measured with cosine similarity or a dot product.

The vector has a fixed number of dimensions. Google's EmbeddingGemma 2 model card describes a 768-dimensional space. The number has no meaning one dimension at a time. What matters is that distances between vectors carry meaning. For where those vectors are stored and searched, see our explainer on what a vector database is.

An embedding model is not a chatbot. It does not generate text. It is typically far smaller than a chat model, runs fast, and is called once per document at indexing time and once per query at search time.

A current example: EmbeddingGemma 2

Google DeepMind's October 6, 2026 post introduced EmbeddingGemma 2 as an open, lightweight multimodal embedding model. The model card and blog give a concrete picture of what a modern one looks like:

• 740M parameters in total: a 270M text backbone, a 170M vision encoder and a 300M audio encoder that can be loaded selectively
• Text, code, images, video and audio mapped into one shared 768-dimensional space
• A context of 8,192 tokens shared across modalities, with audio at about 25 tokens per second and images defaulting to 280 tokens each
• An Apache 2.0 license listed on the card, though the linked terms point to a Gemma 4 license document, so read both
• Weights on Hugging Face and Kaggle

Google reports that its MTEB Code score rose from 68.76 to 78.68, a gain of 9.92 points over the earlier model. The card lists scores at 768 dimensions: 61.36 on multilingual text (MTEB v2), 78.68 on code, 64.64 on image retrieval (MIEB lite), and 69.54 on audio retrieval (MSEB). These are Google's reported numbers.

The size trade-off: Matryoshka truncation

Large vectors cost storage and search time. EmbeddingGemma 2 uses Matryoshka representation learning, which lets you cut the vector to a shorter prefix. The model supports 512, 256 and 128 dimensions. Google says this brings up to a 6x storage reduction. The card says quality stays close to full at 256 dimensions, but warns that 128 degrades multimodal performance substantially. If you truncate, re-normalize the vectors.

For a team indexing millions of documents, that is a direct cost lever. It is also a place to get it wrong: a savings figure measured on one dataset may not hold on yours.

Small enough for a phone

The blog reports quantized memory use on a Pixel 11 Pro of about 191MB active RAM for text-only weights and about 567MB for the full multimodal model. That makes on-device search plausible: your notes, photos and voice memos indexed without leaving the phone. The deployment options listed include MediaPipe, LiteRT, transformers.js, WebGPU, Ollama, llama.cpp and Qdrant.

How to choose one without being fooled

The standard comparison is the Massive Text Embedding Benchmark. Its paper, by Muennighoff, Tazi, Magne and Reimers, first submitted on October 13, 2022 and revised in March 2023, covered 8 embedding task types, 58 datasets and 112 languages, and benchmarked 33 models. Its central finding: "no particular text embedding method dominates across all tasks."

That finding still shapes how to read a leaderboard. A model that leads retrieval may trail on clustering or classification. Newer variants add image, audio and code. Practical advice:

• Build a small test set from your own documents and real queries, then measure recall at the top few results
• Compare at the dimension you will actually use, not the default
• Check the language mix: the card warns performance may vary across its 100-plus languages
• Check the license, since the card's Apache 2.0 label and the linked Gemma 4 terms need reconciling

Our piece on the context window is relevant here too, because an embedding model has its own, usually shorter, input limit. Long documents must be split into chunks before they are embedded.

Pitfalls that catch teams

Switching models means re-embedding everything. Vectors from different models are not comparable. If you change models, you rebuild the index.

Precision matters. The card says to run in bfloat16 or float32, because float16 can produce NaN or degraded embeddings. Prompts matter as well: the card says to use task prefixes on text inputs and warns that omitting them can reduce quality.

No safety layer. The card states that as a pre-trained embedding model it has no safety tuning or output moderation. Anything you index and retrieve passes through unfiltered, so sensitive content and access control are your job.

Our take

Embedding models are unglamorous and consequential. A weak one makes a retrieval system miss the right passage no matter how good the chat model on top is. Pick based on a test of your own data, truncate only after measuring, and plan for the re-embedding cost of any later switch. EmbeddingGemma 2 is a useful reference point because its card is candid about limits, which is the standard to ask of any model you adopt.