RAG That Survives Production
RAG is not one component. It is a chain of decisions about content, identity, indexing, retrieval, ranking, context and evaluation, and a good model cannot repair missing, stale or unauthorised evidence. This eight-part series covers why vector search alone falls short, hybrid search in plain language, the end-to-end retrieval pipeline, chunking as a business decision, permission-aware retrieval, reranking and context budgets, evaluating retrieval separately from the answer, and operating RAG after launch. One fictional South African engineering firm and its bid library carry the examples.
8 articles
- Part 1Why vector search alone is not enoughA vector-only RAG pilot can feel brilliant in a demo and fail on the first question that contains a bid number. Part 1 explains what semantic search is good at, where it is blind, and why a knowledge assistant needs more than one way to find evidence.7 min read
- Part 2Hybrid search in plain languageHybrid search runs keyword and semantic search side by side and merges the results. Part 2 explains how the merge works, why rank fusion beats adding scores together, what a reranker adds, and why hybrid search is a retrieval pattern rather than a complete architecture.7 min read
- Part 3The retrieval pipeline, end to endRAG is not one component. It is a chain of decisions about content, identity, indexing, retrieval, ranking, checks, context and evidence, and a weak link anywhere reaches the user as a bad answer. Part 3 walks the whole pipeline and shows where answers actually go wrong.7 min read
- Part 4Chunking is a business decisionMost RAG pilots split every document into fixed-size pieces and move on. Contract clauses, rate tables, procedures and meeting notes do not share a structure, and cutting them the same way returns half a rule. Part 4 explains why chunking should follow meaning, not a character count.7 min read
- Part 5Permission-aware retrieval: the same rules as the source systemAn employee should never see information they are not entitled to because an embedding happened to sit nearby. Part 5 covers filtering before ranking, why post-filtering fails twice, derived documents that lose their permissions, the lag between a source change and the index, and how to prove isolation with tests.8 min read
- Part 6Reranking, context budgets and costMore retrieved text is not automatically better. Sending forty chunks to a model costs more, runs slower and often answers worse than sending eight good ones. Part 6 covers candidate counts, reranking, cut-offs, context budgets and how to find the balance from evidence.7 min read
- Part 7Evaluate what was retrieved before what was writtenMost RAG evaluation asks whether the answer looked right. That blends five different failures into one score and points the fix at the model. Part 7 shows how to measure retrieval on its own, then the answer, then leakage, and how to diagnose a wrong answer from the top down.7 min read
- Part 8Operating RAG after launchA RAG system is accurate on launch day and starts decaying the next morning. Documents change, permissions move, people ask new questions and copies of withdrawn content linger. Part 8 covers re-indexing, deletion, ownership, drift, feedback, incidents and cost: the operating work that decides whether the assistant is still trusted a year later.7 min read
Working through any of this in your own organisation?
These articles come out of delivery work rather than theory. If the problems in this series look familiar, a short scoping conversation is usually the quickest way to work out what is worth doing first.
Talk to CloudNala