Embeddings for Retrieval Systems (September 2026)¶

Reviewed 2026-09-03. An embedding model maps a defined input representation into a numeric vector. Similar vectors can support retrieval, clustering, recommendation, and classification, but an embedding is not evidence by itself: the system must retain the original source and its revision.

Treat an Embedding as a Versioned Artifact¶

Vectors produced by different models—or by a changed preprocessing contract—should not be blended in a single nearest-neighbor result set unless that compatibility has been measured deliberately.

Retrieval Contract¶

source revision
    -> parse and normalize under a documented policy
    -> split into citation-preserving units
    -> embed and attach metadata
    -> index as an immutable generation
    -> retrieve candidates for a query
    -> validate source access and pass evidence to the answer step

The answer layer must receive a stable source locator, not only a vector-store record ID. This lets a reader inspect why a result was shown and lets the pipeline expire or replace stale evidence.

Minimal Record Shape¶

{
  "vector_id": "handbook:2026-09-03:sec-14",
  "source_revision": "sha256:...",
  "embedding_model": "provider/model-id",
  "preprocessing_revision": "normalize-v3",
  "chunking_revision": "section-aware-v2",
  "metadata": {
    "title": "Editorial policy",
    "locator": "policy.md#citations",
    "access_scope": "internal"
  }
}

Quality Evaluation¶

Evaluate retrieval independently from generation. A useful fixture contains a query, the allowed source identifiers, forbidden/stale sources, and the expected access scope. Measure recall and ranking on that fixture, then inspect failure categories such as wrong document, wrong section, obsolete revision, language mismatch, and authorization leakage.

Do not choose an embedding model solely from a public leaderboard. A useful retrieval stack also depends on chunk boundaries, query rewriting, metadata filters, distance metric, index configuration, and the real corpus.

Operating Changes Safely¶

1. Build a new vector generation beside the active one.
2. Run the retrieval evaluation against both generations and compare failures.
3. Validate document permissions and citations in the answer path.
4. Switch the read alias atomically only after the candidate generation is accepted.
5. Retain enough metadata to roll back to the prior generation and investigate drift.

Gotchas¶

• Issue: Re-embedding documents in place. Queries can see a mixed space while a job is incomplete. Fix: build a separate generation and atomically switch the reader.
• Issue: Using only raw chunk text as the retrieval result. Citations and access policy disappear. Fix: keep source revision, locator, and authorization metadata with every vector.
• Issue: Treating semantic similarity as factual support. A nearby passage can be outdated or contradict the question. Fix: validate evidence revision and show the source to the answer/evaluation layer.
• Issue: Comparing embedding scores across systems. Scores depend on model, normalization, and metric. Fix: use rankings and an evaluation set inside one explicitly versioned system.

See Also¶

• rag pipeline
• chunking strategies
• tokenization
• vector databases

Sources¶

• OpenAI vector embeddings guide
• LangChain retrieval overview