Embeddings turn text into numerical coordinates so software can compare meaning rather than rely only on matching words. That simple idea powers semantic search, recommendation systems and the retrieval step in many AI assistants.
An embedding is a dense vector: a list of numbers produced by a model. Google describes those numbers as a representation of semantic meaning. Texts that the model judges similar tend to land near one another in the same vector space, even when they do not use the same vocabulary.
That is why a search for “cancel a transfer” can retrieve a page titled “Reverse a bank payment.” A keyword system may miss the connection because the words differ. An embedding system compares the vectors and can rank the page as close in meaning.
From text to a vector
The application sends a passage, query or other item to one embedding model. The model returns a fixed-length vector such as [0.021, -0.118, …]. The individual coordinates are not human labels such as “banking” or “refund.” Meaning is distributed across the vector.
The same model and compatible settings must be used for items that will be compared. A vector from one model does not share a dependable coordinate system with a vector from another. Re-embedding a collection is therefore a migration job when a team changes models.
Many APIs also accept a task type. Google’s embedding documentation, for example, distinguishes retrieval queries from retrieval documents and other tasks. This gives the model context about how the vector will be used. Teams should record the model, version, dimensionality and task setting with the index rather than treat vectors as model-free data.
How semantic search ranks results
A search index stores a vector beside each document or chunk. At query time, it embeds the query and measures the distance or similarity between that vector and stored vectors.
Common measures include:
- Cosine similarity, which compares the angle between vectors.
- Dot product, which combines direction and magnitude.
- Euclidean distance, the straight-line distance between points.
Google notes that normalized vectors make cosine, dot-product and Euclidean rankings equivalent in common setups. That does not mean teams can swap metrics blindly: the model documentation and index configuration still need to agree.
The system then returns the nearest items. This is a ranking, not a statement that the first item is correct. A document can be semantically close but outdated, poorly sourced or outside the user’s intended context.
Exact search and approximate neighbors
One way to find the nearest items is to compare the query with every stored vector. Google BigQuery calls this brute-force vector search. It can provide exact results, but the work grows with the collection.
Larger systems often build an approximate nearest-neighbor index. The index narrows the candidates so searches run faster and use fewer resources. The tradeoff is recall: an approximate search may miss a true nearest neighbor. Index design therefore balances latency, cost and the proportion of relevant items retrieved.
That balance should be measured on real queries. A fast index that omits the documents people need is not an improvement, even if its infrastructure metrics look good.
Chunking changes what the index can find
Long documents are usually split into chunks before embedding. A whole manual represented by one vector can blur several subjects together. Smaller sections create more precise candidates, but chunks that are too short can lose the context needed to interpret a sentence.
Useful chunking follows the document’s structure: headings, paragraphs, table rows or code units. It also preserves metadata such as source URL, title, access permissions and last-updated time. Retrieval without that metadata makes it harder to filter results and show where an answer came from.
This is one of the main setup choices behind retrieval-augmented generation. The language model sees only the passages the retrieval system selects. Weak chunks or weak ranking can produce a confident answer from the wrong evidence.
Why hybrid search is common
Embeddings are good at paraphrases and broad concepts. Keywords are good at exact identifiers, product codes, error messages, names and rare terms. A search for ERR_CONNECTION_RESET should not depend on a model deciding what the string means.
Hybrid search runs semantic and lexical retrieval together, then combines or reranks the results. Filters can also restrict candidates by language, date, tenant or document type before ranking. This is often more robust than treating semantic search as a replacement for every keyword query.
What embeddings do not guarantee
Embeddings inherit their model’s training and limitations. Similarity can reflect unwanted associations. A model may perform unevenly across languages or specialized domains. Numbers that look precise do not provide a universal threshold for relevance.
They also do not verify truth, freshness or authority. Those checks require document provenance, dates, access controls and evaluation. The same caution applies to other AI labels: our guide to Content Credentials explains how a signed provenance record can be valid without proving that an image’s claim is true.
Teams should test retrieval with a labeled set of representative questions and expected sources. Measure whether the right passages appear in the top results, inspect misses, and repeat the test when the model, chunking or index changes. Include queries with no good answer so the system can learn when retrieval should return nothing.
