RAG failure is silent failure

A broken API returns a 500. A broken query throws. A broken retrieval system returns the wrong five paragraphs, and the language model, which is professionally incapable of saying nothing, weaves them into a confident answer anyway. No error, no log line, no alert. Just a slightly wrong answer, delivered fluently, to a user who has no way of knowing.

This is the defining operational property of retrieval-augmented systems and it is under-discussed to a startling degree. The generation step gets all the attention because it is where the magic visibly happens. But in a RAG pipeline the generation is usually fine; the model is good at synthesizing whatever it is given. The question is what it was given, and that question fails silently.

The failure modes are mundane, which is exactly why they persist. The ingestion job dies quietly and the corpus goes stale; the assistant keeps answering from three months ago. Chunking splits a table from its header, so retrieval returns numbers with no meaning. A metadata filter is wrong and quietly excludes half the corpus for certain users. An embedding model gets upgraded and old vectors coexist with new ones in the same index, degrading similarity in ways no individual query makes obvious. Each of these produces the same symptom: answers get worse, and nothing tells you.

The discipline that fixes this is measuring retrieval separately from generation. Not one end-to-end eval, two evals. For retrieval, keep a set of questions with known source passages and score whether the right chunks appear in the top results; recall at k, roughly, on your own data. For generation, score whether the model's answer is faithful to the retrieved chunks it was given. The split matters because the remedies share nothing: a retrieval miss sends you to chunking, embeddings, or query rewriting, while an unfaithful answer sends you to the prompt or the model. An end-to-end score alone cannot tell you which direction to walk, so teams walk the wrong one for weeks.

Beyond the eval, RAG systems deserve production instrumentation the way payment flows deserve it. Log retrieval scores per query and alert when the average drifts. Track corpus freshness as a first-class metric with an alarm on stalled ingestion. Watch for spikes in queries where all retrieved chunks score badly, because that cluster is a map of what your users need and cannot find. Sample answered queries weekly and have a human check a handful against sources. None of this is sophisticated. All of it is the difference between finding drift on a dashboard and finding it in a churn interview.

There is a deeper point behind the tactics. Teams instinctively treat RAG as a model problem, and it is mostly a data engineering problem wearing an AI costume. Pipelines, freshness, indexing, relevance: the disciplines are twenty years old, they just need applying to a new index type. The teams that staff and instrument it that way build assistants that stay trustworthy. The teams that keep tuning the prompt while the corpus rots underneath learn that fluency and correctness are, in the end, entirely different products.