Search RAG Generation
Search RAG - Generation
Generation is not the hard part. Grounded generation is.
Why this matters in production
The model can write fluently from bad evidence. That is exactly the problem. A beautiful answer from weak sources is worse than an awkward answer that exposes uncertainty.
This is usually a mistake: treating hallucination as a model personality flaw. In RAG, hallucination is often a system design failure: bad evidence, bad prompt contract, missing citations, or no refusal path.
What breaks
Models over-answer missing evidence, merge claims from multiple chunks, cite nearby but wrong sources, and hide contradictions. Users trust the prose, not the trace, unless you make the trace visible.
Correct-by-coincidence answers are failures. If the answer cannot be mapped to the retrieved evidence, the system did not work.
What works
Treat retrieved context as evidence, not truth. Require claim-level grounding. Allow partial answers. Make uncertainty explicit. Keep output structure predictable enough to evaluate.
Do not ask the model to be both creative and citation-strict in the same answer unless you have validation outside the model.
Practical guidance
A good generation layer says: here is what the evidence supports, here is what it does not support, here are the sources, and here is the confidence boundary.
What happened
A model answered a vendor-risk question with a clean summary but cited a chunk that only mentioned the vendor name, not the risk claim.
Why retrieval failed
Retrieval returned weak evidence, and the prompt did not force claim-to-source validation.
Why it was hard to detect
The answer looked professional. Citation existence was mistaken for citation support.
What fixed it
The fix was claim-level citation checking, unsupported-claim metrics, and a refusal path when evidence was too thin.
Practical Guidance
Separate fluency from grounding.
Measure citation support, not citation presence.
Allow safe partial answers.