What Are Embeddings and How Do They Power Semantic Search?

I am the thing that turns "meaning" into a location in space. In one sentence: I take a piece of text and convert it into a long list of numbers -- a vector -- positioned so that text meaning something similar ends up near other text meaning something similar, even if they don't share a single word. That's what makes semantic search possible, and it's the layer my sibling RAG stands on when it goes looking for the right passage.

What I actually do

Keyword search asks "does this document contain this exact string." I ask a completely different question: "how close is the meaning of this text to the meaning of that text." I answer it by placing every piece of text I'm given somewhere in a high-dimensional space -- think hundreds or thousands of numbers per piece of text -- such that distance in that space tracks similarity in meaning.

Concretely: "how do I reset my password" and "steps to recover account access" share zero words in common. A keyword search sees no match. I place both of those sentences near each other in my space, because they mean almost the same thing, and "near each other" is the entire signal I produce. When someone searches, I convert their query into the same kind of vector and find whatever's closest to it. That's a similarity search, and it's fast enough to run over millions of documents because comparing vectors is cheap arithmetic.

I don't understand the text the way a reasoning model does. I don't answer questions, summarize, or explain anything. I produce coordinates. What happens with those coordinates -- retrieval, clustering, deduplication, routing a question to the right specialist -- is somebody else's job, built on top of mine.

How I actually work here

I'm the layer underneath every "find the relevant rule/pattern/ticket without knowing its exact title" operation in this codebase. When a routing index has to match a loosely-worded request to a specific skill or capability, that match is frequently a similarity comparison over embeddings, not a string match over names. I'm also doing quiet work in deduplication -- catching two differently-worded tickets, rule drafts, or lesson entries that are actually saying the same thing, so they don't get filed twice under two different labels. And I sit underneath clustering: grouping a pile of unlabeled findings into "these five are actually one topic" before a human or a model has to read all five.

Where I fail

I have no idea what's true, only what's similar. Two sentences can be extremely close in my space and have opposite truth values -- "the gate is required before merge" and "the gate is not required before merge" are nearly identical in wording and meaning-shape, and I will rank them as highly similar to each other, because similarity is about topic and phrasing, not about agreement or negation. Anything downstream that treats "close in embedding space" as "says the same thing" will get burned by exactly this.

I collapse nuance that a human would never miss. Negation, scope, qualifiers like "except when," and small but load-bearing details ("under 50 rows" vs. "under 500 rows") often produce vectors that are nearly indistinguishable from each other. I'm built to capture the gist, and the gist is frequently where the dangerous exception lives.

I drift when my training doesn't match your domain. A general-purpose embedding model was trained on general text. Give it two pieces of internal jargon, two ticket-tracker shorthand terms, or two acronyms specific to your operation, and it may place them far apart even though anyone on your team would call them synonyms -- or place them close together even though they mean unrelated things in your context. I'm calibrated to the world I was trained on, not automatically to yours.

I'm sensitive to how the text was chunked before it reached me. If a document gets split into pieces at an arbitrary length cutoff instead of at a natural boundary, I embed each piece as if it were a complete, coherent thought -- even when it's a sentence sliced in half. A badly chunked document produces confidently wrong vectors, and nothing about the number I output warns you that the input was mangled first.

I don't explain my own similarity scores. When I say two things are 0.83 similar, I can't tell you which words or ideas drove that score. Debugging "why did it retrieve this instead of that" often means guessing, because my internal representation isn't something a person can read directly.

Tech-Tips

- Never treat high similarity as agreement. Build an explicit negation/contradiction check downstream of me if two retrieved passages might conflict -- I will hand you both with a straight face and let you sort it out. - Chunk on meaning boundaries, not character counts. Split documents at headings, paragraphs, or sections -- never at a fixed character or token count that might land mid-sentence. Garbage chunking produces garbage vectors no matter how good the embedding model is. - Evaluate me on your own vocabulary, not a generic benchmark. If your domain has jargon, acronyms, or internal shorthand, test whether I actually cluster those terms the way your team would before trusting me on them in production. - Re-embed after you re-chunk or re-model. A vector produced by one embedding model or one chunking scheme is not directly comparable to a vector produced by a different one. Changing either without re-indexing everything creates a search space that's quietly inconsistent with itself. - Use me for candidates, not verdicts. I'm excellent at narrowing a million documents down to twenty plausible matches. I'm the wrong tool to make the final "is this actually correct" call -- that belongs to whatever reads the twenty candidates next.

Evidence: This piece describes the semantic-similarity/vector-search layer as used in our internal operations knowledge-routing, deduplication, and ticket-matching workflows -- no vendor or specific embedding model/product is named, per moat-protection and STORY-FORMAT conventions. Evidence class: internal operating record and Owner attestation, 2026-08-25.