RAG in production: the evaluation harness nobody builds until it's too late

Most RAG demos work. That's not the hard part. The hard part is the pipeline still answering correctly six months later, after the underlying documents have been edited, restructured, and partially deleted a dozen times — and nobody noticed the retrieval quality had quietly degraded until a customer did.
An evaluation harness is what catches that before a user does. Concretely: a set of real questions with known-good answers, run against the pipeline automatically on every change, with a pass/fail threshold that blocks a deploy the same way a failing test suite would.
The set has to come from real usage, not a hypothetical. Synthetic test questions written by the team building the feature tend to test what the team assumes users will ask, which is rarely what they actually ask. Pull from real query logs once you have them; start with your best guess before you do.
Guardrails are the other half. An evaluation harness catches quality regressions; guardrails constrain what the system is allowed to do at all — which documents it can retrieve from, what actions an agent built on top of it can take, what it refuses outright. Trusting a model to "just behave" is not a strategy.
None of this shows up in a demo, which is exactly why it gets skipped. It's also exactly the difference between an AI feature that survives a quarter in production and one that gets quietly turned off after the first bad answer goes viral internally.
Have a question about this article — or your own project?
Ask us anything about the approach above, or tell us what you're building. You'll hear back from an engineer, not a sales script.