
Most teams building retrieval augmented generation systems for high stakes classification make the same architectural bet: Route every ambiguous case straight to the language model and trust the retrieved context to sort it out. This approach falls apart when the system has to survive an audit or a regulator asking why a specific decision was made.
The author has spent the last year building RAG based classification systems in regulated enterprise settings, where the cost of a wrong answer is not a bad chatbot reply, but a decision that has to hold up to scrutiny long after the model produced it.
The appeal of routing everything through a large language model is obvious: Fewer moving parts, faster iteration, the model handles unanticipated edge cases.
However, this approach has several problems, including auditability, cost at scale, and model drift on easy cases. For instance, if a system processes tens of thousands of cases a day and every one hits an LLM call with several retrieved documents in context, the inference bill and latency both scale with volume in a way that rule-based logic does not.
Moreover, LLMs are inconsistent on cases that should have a deterministic answer, which can lead to incorrect decisions. They are not suitable for every decision.
The fix is to stop treating the LLM as the front line and start treating it as the escalation path. This means a three-stage pipeline, where the first stage is deterministic, the second stage is retrieval-based, and the third stage is the LLM call.
In practice, this means that exact matches, structured field comparisons, and anything with a clear rule get resolved in the first stage with no model call at all. The second stage is where retrieval earns its keep, pulling the specific evidence relevant to the ambiguity, such as prior reviewer decisions on similar cases or contextual documents that explain an apparent conflict.
Related: Evaluation reveals AI confidence peaks on errors
The third stage is the LLM call, and it should only see the residue that stages one and two could not resolve. In one system, routing only the genuinely ambiguous 10 to 15% of cases to the LLM cut inference cost by roughly 6X compared to an all LLM baseline, while improving consistency on the deterministic majority to effectively perfect.
Once a case reaches the LLM stage, most teams default to a neutral prompt, which is wrong for high stakes classification because the cost of the two error types is not symmetric.
Standard RAG evaluation metrics were not built with this use case in mind, and using them without adaptation will give a false sense of confidence. A few adjustments that matter include measuring retrieval quality separately from final classification accuracy and deliberate oversampling of the cases that reach stage three.
It’s also important to build a feedback loop from confirmed outcomes back into the retrieval corpus, so that when a human reviewer overturns a model decision, that case and its correct resolution become retrievable context for future similar cases, which is essential for compliance in modern organizations.
The system’s handling of ambiguous cases never improves without this feedback loop, it just keeps making the same category of mistake at the same rate.
The broader lesson is that the instinct to reach for the most capable model for every decision is understandable, but in domains where wrong answers have real consequences, the more valuable engineering work is deciding what should never touch the model at all.
Cascade architecture is not a workaround for LLM limitations, it’s what a mature RAG system looks like once you have actually had to defend its decisions to someone whose job is to find the flaw in your logic.


