What is Embedding?

Why It Matters

Embeddings are how a machine compares meaning. Turn text into a vector of numbers, and “similar” becomes “close together in space”, which is what makes semantic retrieval possible at all. A query about “contract termination windows” can find a passage about “notice periods” without sharing a single word.

The catch is that the embedding model defines what “similar” means. Its blind spots become the system’s blind spots: distinctions it was never trained to draw are distinctions your retrieval cannot make.

How It Works

An embedding model maps each chunk of text to a point in a high-dimensional space, positioned so that semantically similar texts land near each other. At query time the same model embeds the query, and vector search finds the nearest chunk-vectors.

The whole pipeline is only as good as that mapping. Domain vocabulary, jargon, code, tables: whatever the embedding model handles poorly, retrieval handles poorly, and no amount of downstream tuning fixes a distinction that was never encoded.

Where It Breaks

The first break is domain mismatch: a general-purpose embedding model flattens the distinctions that matter in a specialized corpus, so legal clauses or internal identifiers cluster as if they were the same thing. The second is model drift: providers update embedding models, the vectors shift, and an index built under the old model silently degrades or must be rebuilt.

The structural break is treating embedding choice as a one-time decision made at kickoff and never revisited, while both the corpus and the model keep moving.

How Flytebit Handles It

Embedding selection in our RAG work is evaluated, not defaulted: candidate models are scored against eval questions from the client’s real corpus before the index is built. And because models drift, embeddings are part of the versioned manifest: a provider update is a version bump that goes through the eval gate like any other change.