Embeddings and Vector Databases

An embedding represents an input as a numeric vector that can be compared with other vectors from a compatible embedding space. A vector database or search service stores those representations and retrieves nearby candidates. Neither component decides which business record is authoritative or whether the retrieved material answers the question.

For an enterprise integration, the useful design unit is a versioned retrieval index: source content, preparation rules, embedding configuration, metadata and query behaviour. This guide helps data and application teams make that unit maintainable within AI integration and delivery, rather than choosing a database from a feature list alone.

Define the retrieval job before the vector store

Consider an illustrative spare-part evidence finder. A technician asks for documentation associated with bearing kit BK-204. The corpus contains Arabic maintenance notes, English parts catalogues and similar codes such as BK-240. The retrieval task is to find applicable documentation and show its identity; it does not authorise part substitution or establish mechanical compatibility by semantic similarity.

Write the expected evidence for representative questions. Some queries need exact code matching, some use descriptions such as “the bearing kit for the older assembly”, and some contain insufficient identifiers. This distinction determines whether the design needs lexical search, vector search, metadata lookup or a combination.

For a complete answer pipeline, use enterprise RAG architecture. The narrower concern here is how the retrieval representation is built, evaluated, updated and retired. Keeping that boundary clear helps diagnose a retrieval failure before changing the answer-generation model.

Keep query and document embeddings compatible

Record the embedding model identity and version, supported input preparation, output dimensions and the similarity metric used by the index. Microsoft’s vector-index documentation describes matching vector fields and configuration to the embedding implementation. Vectors with the same number of dimensions are not necessarily semantically compatible when produced by different models.

Use the documented query and document input conventions for the selected model. Some implementations distinguish their intended roles, so avoid assuming that an identical raw string is always the complete embedding input. Record any prefixes, normalisation or truncation used and evaluate them as part of the retrieval configuration.

Preserve original identifiers alongside normalised searchable forms. If punctuation is removed from BK-204 for matching, keep the original code visible and ensure it cannot collide silently with another identifier. Do not treat Arabic text normalisation as harmless by default: test the terms and distinctions present in your corpus.

Use a versioned index contract

Minimum retrieval-index contract

Contract area	What to record	Why it matters
Source lineage	Document identity, revision, source location and extraction version	Supports correction, deletion and reproducibility
Chunk identity	Stable chunk reference and parent-document relationship	Prevents orphaned or duplicate searchable fragments
Representation	Embedding model, dimensions, preparation and metric	Prevents incompatible query/index combinations
Business metadata	Part code, language, effective status and relevant scope	Separates semantic similarity from applicability
Access metadata	Enforced resource scope and permission version where used	Limits which candidates may reach the requester
Index release	Build identity, corpus snapshot, evaluation and activation decision	Makes migration and rollback reviewable

Store enough information to rebuild the index without relying on a worker's memory or an undocumented notebook. Decide whether chunk identities remain stable across a correction or receive a new version. Either choice needs a predictable way to remove the superseded representation.

Evaluate chunk boundaries before increasing index complexity. A chunk that combines several unrelated parts can retrieve the right general topic while obscuring the specific code. A chunk that is too narrow can lose the heading or qualification needed to interpret a row. Compare candidate chunking rules on the same questions, preserving source locations and relevant parent context. Record the chosen rule in the index release so a later rebuild does not change the retrieval unit silently. This experiment can reveal a representation problem that database tuning alone cannot fix.

Choose exact or approximate search with a measured trade-off

Exact nearest-neighbour search compares against the relevant vector population, while approximate methods reduce the search work at the cost of potentially missing some neighbours. Microsoft’s vector-ranking guidance explains this trade-off and the use of exhaustive search as a reference when evaluating approximate retrieval.

Distinguish two kinds of recall. Neighbour recall asks whether the approximate index finds the neighbours returned by the exact algorithm. Business evidence recall asks whether the required document appears in the result set. A high neighbour-recall score cannot rescue an embedding model that places the wrong documents nearby for your task.

Measure latency, memory, build time and business recall together. Test realistic metadata filters and corpus sizes. A fast benchmark on an unfiltered public corpus may not represent a private parts library where only a small authorised subset is eligible for each query.

Test filters and hybrid retrieval as part of the index

Permission and applicability filters affect which candidates can be returned. The stage at which a filter is applied can also affect recall and performance; Microsoft documents these considerations in its vector-query filtering guidance. Verify the actual behaviour of the selected product and configuration rather than assuming all “metadata filtering” works identically.

For BK-204, exact code search should remain available even when a vector query finds conceptually similar maintenance text. A hybrid approach can combine lexical and semantic candidates, but the final ranking still needs evaluation. Do not compare raw scores from unrelated ranking methods as if they were calibrated probabilities.

Test an authorised exact match, an unauthorised exact match, a description without a code, a mistyped code and a document with an obsolete status. The correct answer for an unauthorised or unresolved query may be no sufficient evidence. A nearest-neighbour algorithm will generally find something nearby; the application must decide whether that is useful enough to return.

Size raw vectors without confusing them with total capacity

Use an explicit storage calculation. For an illustrative 100,000 chunks, 768 dimensions per chunk and four bytes per stored scalar, raw vectors require 100,000 × 768 × 4 = 307,200,000 bytes, or 307.2 MB in decimal units. This is approximately 293 MiB. These are invented sizing inputs, not a recommended model dimension or a product quota.

The figure excludes index structures, text, metadata, replication, backups, deleted-entry overhead and temporary space during rebuilds. If you maintain old and new indexes during migration, capacity must support that overlap. A vector-size calculation is therefore a useful lower-level component of planning, not the complete database bill.

Compression or quantisation may change storage and retrieval behaviour where supported. Evaluate the actual implementation against your evidence set and precision needs. Do not assume a smaller representation has no quality cost, or that more dimensions automatically improve the business task.

Migrate embeddings with parallel evidence, not mixed spaces

A new embedding model normally requires a new compatible representation of the corpus. Do not query old vectors with an unrelated new model merely because the dimensions match. Build a separate candidate index, preserve the old release and compare both against the same held-out questions.

1. Freeze the candidate preparation and embedding configuration.
2. Build from a traceable source snapshot and reconcile document and chunk counts.
3. Apply incremental source changes while the build is in progress.
4. Evaluate relevance, filtering, latency and source-removal behaviour.
5. Switch query routing through a controlled configuration change.
6. Keep a defined rollback window and retire the old index when the agreed conditions are met.

Reconcile deletions as carefully as additions. A removed parts notice should not remain accessible through an old index alias or a cached answer. Connect the release to cache invalidation and the source permission model. If a reindex cannot complete within the required freshness window, adjust the migration method before switching traffic.

Select the database from operating requirements

Compare your current database with vector capability, a search platform and a dedicated vector store against the same workload. Assess supported filters, lexical search, update and delete behaviour, backup and restore, hosting, access controls, observability and the team's operating skills. A separate product is justified when it provides capabilities that matter enough to offset another operational dependency.

Ask vendors to demonstrate a source correction, permission removal, partial bulk-import failure and recovery from a failed index build. These exercises reveal maintenance behaviour that a nearest-neighbour demo does not. Keep product edition, deployment mode and current supported features explicit in any procurement comparison.

Use integration tests to prove the application boundary, including identifier mapping and result permissions. Track source-to-index delay and retrieval quality through monitoring. Keep index changes connected to LLMOps when they alter the evidence supplied to a language model.

Make retrieval quality an owned capability

Assign owners for source preparation, embedding configuration, permissions, index operations and relevance labels. Maintain examples of known failures so a future optimisation does not reintroduce them. Treat embeddings and derived indexes according to the sensitivity of their source and actual use; their numeric form is not a reason to ignore data handling.

Trusted Data's RAG and vector-search guide provides related commercial reading. Discuss an embedding and vector-index integration with the retrieval questions, exact identifiers, source-update pattern and evidence needed to compare candidate designs.