SheetA-07
Added2026-08
Source1 blueprint diagram
MethodStage-by-stage review
RAG, End to End — the Honest Map
Most "how RAG works" graphics stop at embed → search → answer. The one that crossed our desk doesn't: it draws ingestion quality, hybrid retrieval, the post-retrieval stage almost everyone skips, and two rails — security and observability — that separate demos from systems. This series exists to catch hype; honesty requires the opposite verdict here. We verify the map, then add the three places even a good map compresses too far.
01 — What the map gets rightFour stages and two rails
- Ingestion decides everything. Cleaning, deduplication, structure and table extraction, PII masking, chunking with overlap, metadata enrichment — and the diagram's own caption, "garbage in → garbage out (data quality)," is the true center of gravity of every failed RAG project we've seen described.
- Storage is plural. Vector database plus keyword/BM25 index, hybrid indexes, graph stores, caches. Pure vector search is a common beginner ceiling; the map refuses it. Correct.
- Post-retrieval is where quality lives. Reranking, deduplication, recency and permission filtering, context compression. The margin note — "most people skip this → reranking" — is expert-grade advice hiding in a social graphic.
- The two rails. Security/governance (RBAC, ACL filtering, tenant isolation) and observability/evaluation (traces, logs, feedback loops) drawn as full-height columns, not afterthoughts. And the sharpest single line on the sheet: permissions must be enforced at retrieval — filter after generation and the model has already read what the user wasn't allowed to see.
02 — Where it compresses too farThree additions
- Evaluation needs a definition. The map draws a feedback loop but not what to measure: retrieval hit rate and answer groundedness, scored on a fixed question set before each pipeline change. Without that, "tuning" is superstition.
- Chunking is a product decision, not a preprocessing detail. Chunk size and boundaries encode what "an answer" is for your corpus — contracts, tickets and manuals want different cuts. The map lists options; the choice deserves an owner.
- Long-context models moved the goalposts. With million-token contexts, the question is no longer only "how do I retrieve the right chunk" but "when is retrieval worth it at all versus loading the document." RAG remains right for large, permissioned, changing corpora — which is exactly when the map's rails matter most.
03 — The ledgerChecked 2026-08-06
| Claim | Verdict | The record |
|---|---|---|
| Ingestion → embedding/storage → retrieval → generation pipeline | VERIFIED | The canonical architecture, completely drawn. |
| Hybrid retrieval (vector + keyword + metadata + graph) | VERIFIED | Matches production practice. |
| Reranking as the most-skipped, highest-value step | VERIFIED | Consistent with practitioner consensus. |
| Permissions enforced at retrieval, not after | VERIFIED | The security-critical detail most diagrams omit. |
| "Context window = bottleneck" | NUANCE | True for assembly budgeting; softened by long-context models — see addition three. |
| Grounded generation with citations and low-confidence refusal | VERIFIED | Right target behavior; needs the evaluation harness the map only gestures at. |
A-07 · RAG, END TO END — THE HONEST MAP · ADDED 2026-08 · ORIGINAL WORK, SOURCES CHECKED 2026-08-06 · VERIFIED SERIES No. 11
PRIMARY SOURCES · production RAG architecture practice (hybrid retrieval, reranking, retrieval-time authorization) as documented across major vendor and framework references · companion sheet A-06 (memory taxonomy)
BLUEPRINT SOURCE · one third-party end-to-end RAG diagram, on file in the private register — analyzed, not reproduced; among the most accurate specimens this series has checked