DEV Community: mofuteq

Why “Please Don’t Make Recommendations” Is Not a Guardrail for RAG

mofuteq — Thu, 02 Jul 2026 12:16:14 +0000

You built a system to surface information so a person could decide. Somewhere it started deciding for them — the output stopped saying "here's what the documents show" and started saying "you should do X." Nobody designed that drift. An LLM, when asked a question, produces an answer-shaped thing, and an answer easily becomes a verdict.

What everyone tries

A prompt instruction: "Don't make recommendations." "Only state what's in the documents." People add the line and assume the boundary is enforced.

Why it doesn't work

A prompt instruction is a request, not a guardrail. The model follows it most of the time, then on the input that matters produces a confident recommendation anyway, because nothing structurally prevents it. "Please don't make recommendations" is to a guardrail what a sticky note saying "please don't enter" is to a locked door.

And the stakes are higher than they look. When output drifts from evidence to verdict, accountability moves. As long as the system returns evidence and a human decides, the human owns the decision. The moment the system returns a verdict and the human defers, the system is deciding things it was never validated to decide — and when one is wrong, accountability is a blank. High-stakes fields separate evidence extraction from judgment on purpose; most RAG systems erase that line by default.

The one shift

Decide what the output is and enforce it structurally. An output should declare itself: answer, evidence, missing facts, or out-of-scope. "Return decision material, not a decision" has to live in the output contract and in gates — not in a polite request to the model. The system supplies frames; the human supplies verdicts.

This is the output boundary — one of three places production RAG dies.

Read the full version on my blog, where this connects to the RAG Failure Diagnosis Kit for teams debugging production RAG.

Stop Sending the Raw User Prompt Straight to Your Retriever

mofuteq — Tue, 23 Jun 2026 12:43:10 +0000

A user types a question into your RAG system. Before anything is retrieved, something decides what string to actually search with. In a lot of systems, nobody decided that on purpose — the raw prompt goes straight to the retriever and whether it works is left to luck.

What everyone tries

Query rewriting: have an LLM expand or rephrase the question into better search strings. It's standard now, and it genuinely helps with vocabulary gaps — user says "login broken," docs say "authentication failure," a rewrite bridges them.

Why it doesn't fully work

A rewrite that improves retrieval can also quietly change the question. The user asked one thing; the rewritten query retrieves great documents for a slightly different thing; the answer is fluent, grounded, and not what they asked. Recall went up, fidelity went down, and nothing noticed because retrieval metrics improved.

The real issue: there are two languages in the room — the user's task language and the corpus's author language — and the retriever sits on the boundary. Treating it as "just rewrite the query" hides that you're making a translation decision with consequences.

The one shift

Treat the gap between user question and search query as an explicit interface boundary, not a hidden preprocessing step. Decide on purpose: what does the retriever search for, how is user language reconciled with document language, and does the rewritten query still answer what was asked? Make the translation visible and checkable, so "we rewrote the query" doesn't silently become "we answered a different question."

This is the query boundary — one of three places production RAG dies. Full version on my blog; the diagnostic questions for all three boundaries are in a RAG Failure Diagnosis Kit for teams debugging production RAG. Link in the canonical post.

Your RAG Retrieved the Right Documents but Still Gave the Wrong Answer

mofuteq — Fri, 19 Jun 2026 12:35:09 +0000

Your retriever returned the right documents. The similarity scores look fine. The answer is still wrong. If you've shipped RAG, you've seen this — and it's the failure that survives every retrieval upgrade.

What everyone tries

Reranker. Higher top-k. Hybrid search. A better embedding model. All of these chase the same goal: documents more similar to the query. They help when the right document wasn't being retrieved. They do nothing when the right document was retrieved and the answer is still wrong.

Why it doesn't work

Similarity answers "is this chunk about the same topic?" It does not answer "does this chunk contain the facts needed to support the answer?" Those come apart constantly. A chunk can be highly similar — same vocabulary, same subject — and contain nothing that actually grounds the answer. Hand the model a pile of on-topic text and it will produce a fluent, plausible, even cited-looking answer. The grounding is cosmetic: the text was nearby, not load-bearing.

High similarity with a wrong answer isn't a contradiction. You asked retrieval to find related text. It did. Nobody asked whether the text was enough.

The one shift

Stop treating retrieval output as evidence. Treat it as candidate material that has to pass an explicit evidence check before it can support an answer. Put a step between retrieval and generation: does the retrieved set actually contain the facts this answer requires? If not, abstain. When the documents don't contain the facts, the system should return nothing rather than a confident guess.

Relevant context in, only sufficient evidence allowed through. That's the line between a RAG demo and a RAG system you can trust in production.

I write about the three boundaries where production RAG dies — query, evidence, output — from the angle of shipping under security and model constraints. Read the full version on my blog, where this connects to the practical RAG Failure Diagnosis Kit for teams debugging production RAG.