Embedding and Vector Store Observability for RAG

When a retrieval-augmented system starts returning worse answers, the instinct is to look at the model or the prompt. But in most RAG failures the model did its job correctly on bad inputs: the retrieval step handed it the wrong context. That is a different failure class from the model decay covered in how model drift detection works. The embedding and vector-store layer is the least-instrumented part of the typical stack and one of the most failure-prone, because it has moving parts — an embedding model, an index, an ingestion pipeline — that each degrade in ways no LLM eval will catch.

The four failure modes worth monitoring

Embedding drift. The distribution of query or document embeddings shifts over time — new topics, new jargon, a different user population. The vectors are still valid; they just no longer sit where the index was tuned for them. The signal is a change in the distribution of embeddings (or of query-to-result distances), not anything visible at the text layer. Phoenix and Evidently both treat embedding-distribution comparison against a reference window as a first-class drift check, and it is the right primitive here.

Silent embedding-model change. Someone upgrades the embedding model or its version, but the existing index was built with the old model. Now queries are embedded in one space and documents in another. Cosine similarity still returns numbers, retrieval still “works,” and results are quietly nonsense. This is the embedding-layer analogue of training-serving skew, and it is depressingly common because the two embedding call sites — ingestion and query — are often in different services.

Index staleness and ingestion lag. Documents are added, changed, or deleted in the source of truth but the vector index has not caught up. Users get answers grounded in content that no longer exists or miss content that does. Without explicit lag monitoring this is invisible until someone notices the system citing a deleted document.

Recall decay under approximate search. Production vector search is approximate (HNSW, IVF). Approximate nearest-neighbor indexes trade recall for speed, and that recall depends on parameters (ef_search, number of probes) and on how the data has grown since the index was tuned. As the corpus changes, the same parameters can quietly return a less complete neighbor set — the ANN-Benchmarks literature exists precisely because this recall/throughput trade-off is real and parameter-sensitive.

What to instrument

• Log retrieval as spans, not as a black box. For each query, record the query embedding, the top-k document IDs, their similarity scores, and the embedding model + index version that served them. This single change converts most of the failures above from “unexplained quality drop” to “visible in the trace.” It also ties cleanly into end-to-end LLM tracing — the retrieval span is just one span in the request. The Trace Span Designer will generate the retrieval-span attribute set for a given pipeline shape.
• Track the score distribution, not just the top hit. Monitor the distribution of top-k similarity scores over time. A downward shift in best-match score, or a flattening (top-1 no longer clearly separated from top-10), is an early warning of drift or an embedding-space mismatch before answer quality visibly tanks.
• Pin and assert embedding-model identity end to end. Treat the embedding model name+version as part of the index’s identity. Refuse to query an index with an embedder that does not match the one it was built with, and alert loudly on mismatch. This eliminates the silent-model-change failure entirely.
• Measure ingestion lag explicitly. Emit a metric for the age of the oldest un-indexed change and the time from source write to index availability. Alert on lag, not just on pipeline errors — a pipeline can be “green” and hours behind.
• Run a periodic recall probe. Maintain a small labeled set of query → known-relevant-document pairs. On a schedule, run them through the live index and track recall@k. A decline is the most direct signal that approximate-search quality has degraded and parameters need re-tuning or the index needs a rebuild.
• Re-evaluate against an exact-search baseline after corpus growth. Periodically compare approximate results to a brute-force exact search on a sample. A widening gap quantifies exactly how much recall the speed trade-off is now costing.

Reading these signals together

None of these monitors is sufficient alone, and they fail in a characteristic order: an embedding-model mismatch breaks everything immediately and loudly if you assert identity; drift and recall decay degrade gradually and show up first in score distributions and recall probes; ingestion lag is intermittent and tracks deploys and traffic spikes. A RAG observability program that only evaluates final answer quality sees the symptom weeks after the layer that caused it started failing. The per-request view that catches it earlier comes from end-to-end tracing for LLM applications. Instrument the retrieval span, watch the score distribution and a recall probe, and assert embedder identity — and most “the RAG system got worse and we don’t know why” incidents become a five-minute trace read instead of a multi-day investigation.

This piece is about instrumentation: what to put in the trace and which signals to emit. It is the semantic layer of the four described in ML observability: layers, signals, and architecture. For turning those signals into pages rather than dashboards, see alerting for ML model drift. For the reliability-engineering side of the same layer, including reindex windows, version coverage, and the metrics set to alert on, see embedding store reliability on mlmonitoring.report.