Embeddings:
what they are and how vector search works

Embeddings represent the meaning of content as a list of numbers

An embedding is a vector, a long list of numbers, generated by a model trained so that content with similar meaning gets similar vectors. The content can be a sentence, a whole document, an image or a record described by its attributes, such as a product with a name, category and description.

The modern technique gained momentum in 2013, with the research paper that proposed architectures for learning vector representations of words from large volumes of text and gave rise to word2vec. Current models apply the same logic to whole passages.

Closeness in the vector space signals similar meaning

Each vector can be read as a point in a space with hundreds or thousands of dimensions. Texts about shipping sit in one region, texts about holidays in another, and duplicate charge sits close to payment posted twice.

The most common measure for comparing two vectors is cosine similarity. It looks at the angle between them: the smaller the angle, the closer the meanings.

Vector search compares the question with an already indexed base of vectors

The process has four steps:

1. indexing: each document, passage or record goes through the model, and the resulting vector is stored with metadata such as source and date;
2. query: the question is converted by the same model, because vectors from different models are not comparable;
3. comparison: the system calculates the similarity between the question's vector and the indexed vectors;
4. retrieval: the closest items come back ranked by similarity.

Comparing the question with every vector gets slow when the base is large. That is why systems use approximate nearest neighbour indexes, which examine only the most promising regions of the space. The search accepts a small loss of precision in exchange for fast answers.

The vector database is the system that stores these representations, maintains the approximate indexes and lets you filter the results by metadata.

Embeddings work well when the question is about meaning

The strongest applications make use of closeness in meaning:

• Semantic search: finds the right content even when the question uses different words, as in the duplicate charge case.
• Clustering: groups tickets by their real subject, regardless of the category chosen by whoever opened the ticket.
• Deduplication: flags product or supplier records with nearly identical descriptions as candidates for review.
• Recommendation: suggests articles, products or cases similar to the one under review.

Negation, numbers, identifiers and permissions are left out of embeddings

A vector captures the subject and tone of a piece of content. Details that change the fact while keeping the subject carry little weight in it:

• Negation: a clause that sets a termination penalty and another that waives it produce very close vectors.
• Numbers and dates: an order with an extra zero in the amount, or with a due date in another quarter, sits in practically the same place in the space.
• Identifiers: order codes that differ by one digit produce almost identical vectors, and exact matching depends on key lookup.
• Permissions: the vector records the meaning of the content and nothing about who may see it.
• Relationships between records: a ticket's vector records its subject, while the link to the customer, the contract and the order lives in another structure.

Every change of embedding model means reprocessing the whole base

The cost of a vector base shows up at three moments. The first is the initial indexing, when every item goes through the model. The second is updating, because each new version of a document or record needs a new vector.

The third is changing models. Vectors from different models occupy different spaces and cannot be compared. Adopting a more accurate embedding model means reprocessing the entire collection, recalculating indexes and revalidating search. Bases spread across several projects multiply that cost.

In the Company Brain, embeddings work alongside the graph and the ontology

In the Company Brain, vector representations are one of the tools of the semantic layer. When the question arrives in natural language, vectors help link the words of the person asking to the terms of the business ontology. Duplicate charge reaches the right ticket category without any words in common.

Vectors also support entity resolution. They suggest records that may represent the same supplier or the same product, and the final decision rests with deterministic rules and with human review in ambiguous cases.

The rest is handled by exact structures. The knowledge graph holds the relationships between records, the ontology defines what each term means and permissions are inherited from the source system. The model receives over MCP only the slice the question needs, with the source of each item, and the smaller prompt lowers the cost per answer. Because the vector base is kept in a single place, a change of embedding model happens once for every use case.

A good first use of embeddings is the base with the most varied vocabulary

The practical starting point is a text base where people look for the same thing using different words, such as the support knowledge base. The log of searches with no results shows where semantic search has the most to add.

From the first index on, each vector should be stored with its source, the content version, the source access rule and the name of the model that generated it. That metadata makes it possible to filter by permission, update only what changed and plan the next model change with a known cost.