How Semantic Search Works: Embeddings, Vectors & SBERT

Every time Google ships a new AI feature, a client shows up shortly after wanting the one trick. The genuinely interesting part sits one level deeper – in a mechanism that has been quietly working in the background for years and that hardly anyone explains cleanly: how does a machine even know that “dog” and “puppy” are closer together than “dog” and “car”?

The answer is embeddings. And once you understand how text turns into numbers and how you measure the similarity of those numbers, the whole fog around “semantic search”, “entities” and “meaning instead of keywords” collapses. It is math. Surprisingly accessible math, in fact.

In this article I go bottom-up: from the raw word to the vector, from the vector to cosine similarity, from there to SBERT (the model that made semantic search practical), and finally to what it means for your SEO – including a recent Google paper that uses exactly this technique against AI spam. I deliberately moved the knowledge graph and entities part elsewhere; you will find it in detail in my article on semantic search and the knowledge graph. This one is about the vector mechanics underneath.

Computers compute, they do not read. For a model to handle language, text first has to be turned into numbers. The naive route would be to give each word an ID: dog = 1, puppy = 2, car = 3. The problem: those numbers carry no meaning. 2 is not “more similar” to 1 than 3, even though puppy is closer in meaning to dog than car.

Embeddings solve exactly that. Instead of a single number, each piece of text gets a whole list of numbers – a vector with many dimensions. Modern embedding models use, depending on architecture, typically 384, 768 or 1,536 dimensions. You can loosely picture each dimension as a learned axis of meaning: one axis maybe for “living vs. inanimate”, one for “large vs. small”, one for “formal vs. colloquial”. The model does not set these axes by hand, it learns them from huge amounts of text.

The process in three steps:

1. Tokenization: The text is split into smaller units (tokens) – often word parts, not whole words. “Puppyfood” might become “puppy” + “food”.
2. Model pass: A neural network (for semantic search usually a transformer) processes the tokens in context and produces a vector per token.
3. Pooling: The token vectors are combined into a single vector per sentence or document, usually via the average (mean pooling).

The result: a single vector that represents the meaning of the whole text fragment. Two texts that mean the same thing get similar vectors – even if they share not a single word. “How old is the lead actor from Titanic” and “Leonardo DiCaprio’s age” sit close together in vector space. That is exactly the jump from keyword search to meaning search.

We now have vectors. But how do you measure whether two vectors are “similar”? By far the most common answer in semantic search is cosine similarity. It does not look at how long the vectors are, but in which direction they point. Two vectors pointing the same way are similar, no matter how long they are.

The formula is manageable:

cos(θ) = (A · B) / (‖A‖ × ‖B‖)

The numerator is the dot product (each component of A times the matching component of B, all summed up). The denominator is the lengths of the two vectors multiplied. Sounds abstract, so let us work through it completely. I take three tiny, simplified “embeddings” in just three dimensions:

• Dog = [2, 1, 0]
• Puppy = [2, 2, 0]
• Car = [0, 1, 3]

For Dog vs. Puppy: dot product = (2×2) + (1×2) + (0×0) = 6. Length of Dog = √(2²+1²+0²) = √5 ≈ 2.236. Length of Puppy = √(2²+2²+0²) = √8 ≈ 2.828. So cos(θ) = 6 / (2.236 × 2.828) ≈ 0.949.

For Dog vs. Car: dot product = (2×0) + (1×1) + (0×3) = 1. Length of Car = √(0²+1²+3²) = √10 ≈ 3.162. So cos(θ) = 1 / (2.236 × 3.162) ≈ 0.141.

The numbers speak for themselves:

This single value – a number between 0 and 1 – is the heart of every semantic search. A search engine turns your query into a vector, compares it via cosine similarity against millions of document vectors, and returns those with the highest similarity. No magic, just geometry.

You could also measure similarity via the straight-line distance between two points (Euclidean distance – the “as the crow flies” distance). So why has cosine prevailed for text?

The reason is length. A long guide and a short paragraph can cover exactly the same topic, but their vectors come out at different lengths. Euclidean distance would then rate the two as further apart, even though they are identical in content. Cosine does not care: it measures only the angle, that is, the direction of the meaning. Length out, meaning in.

A practical side note: many embedding models already output normalized vectors (all scaled to length 1). For normalized vectors, the denominator of the cosine formula drops out, and cosine similarity becomes mathematically identical to the dot product. That is why you often see “dot product” as the distance metric in vector databases – for normalized embeddings it is simply the faster variant of the same thing.

BERT, introduced by Google in 2018, was a breakthrough in language understanding. But for similarity comparisons it had a fundamental catch: to assess how similar two sentences are, you had to push both together through the model. That is accurate and expensive.

Just how expensive was laid out by Nils Reimers and Iryna Gurevych in their 2019 paper “Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks” (EMNLP 2019): finding the most similar sentence in a collection of 10,000 required, with classic BERT, around 50 million computations according to the authors – roughly 65 hours. With SBERT the same task shrinks to about 5 seconds, at comparable quality.

The trick is in the architecture. SBERT retrains BERT in a so-called Siamese network so that each sentence is translated on its own into a meaningful vector. That changes everything: you can compute all document vectors once in advance and store them. At search time you only need to turn the query into a vector and compare via cosine. “Recompute everything every time” becomes “precompute once, then compare at lightning speed”.

Bi-Encoder vs. Cross-Encoder

The difference is often described via two terms:

In practice you combine both: the bi-encoder (SBERT) quickly pulls the best candidates from a huge set, a cross-encoder then sorts the few finalists precisely. The original SBERT, by the way, grew into the sentence-transformers library – by its own description the “go-to Python module” for embedding models, originally built by the UKP Lab and now maintained by Hugging Face, with over 10,000 pretrained models.

The nice thing about embeddings: you do not have to believe them, you can try them. A minimal, reproducible mini-workflow with the standard model all-MiniLM-L6-v2 looks like this:

from sentence_transformers import SentenceTransformer, util

model = SentenceTransformer("all-MiniLM-L6-v2")

docs = ["Raising puppies the right way", "Dog food review", "Buying a used car"]
query = "Tips for young dogs"

doc_emb = model.encode(docs)
q_emb = model.encode(query)

scores = util.cos_sim(q_emb, doc_emb)
print(scores)

The model turns each text into a vector, util.cos_sim computes the cosine similarity, and you get a similarity score per document. “Tips for young dogs” will rank far higher against “Raising puppies the right way” than against “Buying a used car” – even though the query contains neither the word “puppy” nor “raising”. That is semantic search in ten lines.

In production one more stage comes in. With three documents you can compare each vector individually; with millions that would be too slow. So the vectors land in a vector database that works with an approximate search (Approximate Nearest Neighbor, ANN) – instead of checking every vector exactly, it finds the most likely hits via a clever index. A widely used index type for this is HNSW.

This is exactly the setup I use for my own SEO platform, Complex. There, every crawled page of a domain is broken down into embeddings – not just one vector per page, but additionally at the paragraph level (chunks), so that individual passages can be found too. The vectors sit in an HNSW index, and a hybrid search combines classic keyword search with this vector search. What surprised me most while building it: how often the vector search finds documents that fit topically perfectly but share not a single search term. That is the moment when “meaning instead of keywords” turns from a buzzword into a mechanism you can actually feel.

Embeddings and SBERT are no longer an academic niche topic. How concretely the technique arrives in the anti-spam field is shown by a recent paper from the Google Research orbit: “Scalable Detection of Adversarial Synthetic Slop and Coordinated Media Abuse: A LoRA-Enabled Multimodal Defense System” by Abhinav Mathur, Claire Liu, Kelvin Tan and Yifei Liu (Google), covered among others by Search Engine Journal on June 19, 2026.

The system described (Scalable Cluster Termination System, S-CTS for short) takes a different approach than the usual content-by-content check. Instead of evaluating individual posts, it identifies networks of coordinated accounts that mass-produce functionally identical spam in endless variations. The paper states verbatim: “Traditional content-centric moderation fails against this coordinated, adversarial generation strategy.” Translated: checking every single piece of content loses against adversaries who produce endless slightly modified versions.

And this is where Sentence-BERT comes in. For text analysis, the authors write: “For text-based content, methods like text embeddings generated by models like Sentence-BERT are used to detect scripted AI narratives.” The assumption behind it: machine-generated text leaves a measurable mathematical footprint in the embeddings. Added to that is rapid adaptation to new generators via Low-Rank Adaptation (LoRA) and automatic prompt optimization.

What remains as a solid takeaway? Embeddings are demonstrably part of the toolkit Google researchers use to classify AI content. That fits what I describe in more detail elsewhere – namely how Google evaluates AI texts and that the meaning layer plays a central role in it. How BERT-like models contribute to understanding search queries in general I broke down in the article on query processing, and the larger ranking architecture around it in the overview of Google’s AI ranking system.

A few sober consequences follow from the mechanics – deliberately without promises of success, because rankings depend on many factors:

• Clarity beats keyword repetition. If your text is topically clear, its vector points cleanly in one direction. A text that jumps between five topics produces a washed-out average vector that fits nothing well.
• Synonyms and concepts instead of word repetition. Since meaning matters, not word identity, you do not need a keyword 20 times. Cover the concept with its related terms, sub-questions and entities.
• Passages count individually. Because embeddings are often formed at the chunk level, a single strong paragraph can be found. Each section should answer a clear sub-question on its own.
• Thin AI boilerplate is risky. If machine text has a mathematical footprint and mass spam gets caught via similarity clusters, interchangeable content is, in my assessment, the weaker bet – regardless of whether a human or an AI typed it.

None of these recommendations is new, but the vector perspective finally explains the why behind them. Good SEO and good embedding hygiene amount to the same thing: treat a topic clearly, deeply and distinctly.

The whole mystique around “meaning instead of keywords” dissolves once you know the mechanics. Embeddings translate language into geometry, cosine similarity measures closeness in meaning space, and SBERT pushed that comparison from hours to seconds. The same technique I run my own search pipeline on now shows up in Google research against AI spam – a good sign that understanding it pays off.

For your SEO it changes the rationale more than the tactics: depth, clarity and distinct content win because they are clearly located in vector space. The further look at entities and the knowledge graph is in my article on semantic search and the knowledge graph.