RAGOps

WHAT IT IS RAGOps is the operational discipline for retrieval-augmented systems: ingesting and refreshing a corpus, versioning the chunking and embedding strategy, rebuilding and reindexing without downtime, measuring whether the retrieved context actually contains the answer, enforcing the user's permissions at retrieval time, and verifying that citations support the claims made. **Not this:** RAGOps is not LLMOps: it owns the corpus, the index and what gets retrieved — the failures that look like model failures but are actually retrieval failures. WHY IT EXISTS Most bad answers from a grounded system are retrieval failures wearing a model's clothes. The generation step can only work with the context it was given; when the right document was never retrieved, no amount of prompt tuning fixes it, and teams routinely spend weeks on the wrong half of the system. The second reason is sharper: retrieval is where an authorization bug becomes a data breach, because an index that ignores permissions will happily ground a fluent, well-cited answer in a document the user was never allowed to read. WHEN TO USE IT Adopt it whenever a system answers from your own content. The permission question applies from day one if the corpus contains anything not already public — retrofitting access control onto an index built without it is substantially harder than building it in. WHO OWNS IT The engineering team owns the ingestion pipeline, the index and the retrieval path. The content owners own corpus quality and currency — retrieval over stale documents produces confidently outdated answers, and no engineering control fixes a wrong source. Security owns the access model enforced at query time, overlapping directly with /secops. Whoever owns the feature owns the retrieval quality bar. WHAT GOOD LOOKS LIKE Corpus freshness is measured, and documents have a known ingestion lag. Chunking and embedding configuration is versioned, and changing either triggers a full reindex rather than a silently mixed index — mixed embedding versions are a subtle and common defect. Retrieval quality is measured on a labelled set, so you know how often the right passage is actually retrieved. Permissions are enforced at retrieval time against the requesting user, not filtered afterwards. Citations are checked to support what was said, and reindexing happens without serving stale or partial results. HOW TO IMPLEMENT Start by measuring retrieval in isolation: take real questions, label which documents should be found, and measure how often they are. That number tells you whether to work on retrieval or generation, and most teams are surprised. Version the chunking and embedding configuration explicitly and record it alongside the index. Enforce permissions in the query path before any optimisation work. Establish a documented reindex procedure and rehearse it, treating it like any other production data migration — the runbook discipline in /runbooks applies. Add citation verification and corpus freshness monitoring once the basics hold. HOW TO ASSESS YOURSELF Ask how often the correct document is retrieved for a real question, and whether anyone has measured it. Ask what happens if a user asks about a document they cannot access. Ask when the corpus was last refreshed and how you would know if ingestion stopped. Take the scored self-assessment at /assess and turn the findings into a plan with /roadmaps.