When a source document is updated or deleted, update or remove only the vectors belonging to that document by id — don't rebuild the entire vector index from scratch every time. Most vector databases support CRUD by document id specifically to make this efficient (see Document Loaders for why a stable document id has to be assigned up front). At any real scale, this update process itself needs orchestration — a scheduled or event-triggered job (commonly built with a workflow orchestrator like Airflow, or a simpler queue-based pipeline) that watches source systems for changes, re-runs the loader/splitter/embedder steps only for changed documents, and reconciles the vector database, rather than a person manually re-running an indexing script.

A RAG system that retrieves from a shared corpus but serves multiple users with different permissions has a real risk: retrieval can surface a chunk from a document the current user isn't authorized to see, and once that text is in the prompt, it can leak into the answer regardless of what the application's UI otherwise restricts. The fix has to happen at the retrieval layer itself — every search should apply an access-control metadata filter (see Vector Databases → metadata filtering) scoped to the requesting user's actual permissions, not rely on the UI to hide results after the fact. This needs to be tested explicitly, the same way any authorization boundary would be, since a bypass here isn't a quality bug — it's a data leak.

Documents ingested into a RAG corpus can contain personal or sensitive information (names, contact details, health or financial data) that shouldn't be freely retrievable and re-surfaced by an LLM to an arbitrary user. Depending on the use case, this means detecting and redacting PII at ingestion time (before it's ever embedded and stored), tagging documents containing sensitive categories as metadata so access-control filtering can restrict them further, and auditing what a generation actually output against what it was allowed to expose — treating the retrieval corpus with the same data-governance discipline as any other system that stores personal data, because RAG doesn't automatically inherit compliance controls a source system already had.

Covered in depth in Generation Failure Modes, but worth restating as an operational responsibility: any RAG system ingesting content from untrusted or semi-trusted sources (user uploads, scraped web pages, external tickets) needs ingestion-time scanning for injection patterns and prompt-level delimiting of retrieved content as untrusted data — this is a standing operational control, not a one-time fix, since new documents keep entering the corpus.

Every advanced technique in this guide — MMR, MQR, hybrid search, reranking, HyDE, agentic RAG — adds some latency and/or cost: more embedding calls, more LLM calls, or more compute per query. None of them are free upgrades; always weigh whether the accuracy improvement is worth the added latency and cost for the specific use case. A useful discipline is to measure and budget latency per stage separately (embedding the query, vector search, reranking, generation) — it's common for one stage (often a reranker or an agentic loop) to dominate total latency while the rest of the pipeline is fast, and that's invisible without per-stage timing.

Cache answers not just for exact repeated questions, but for semantically similar past questions too — using embedding similarity to detect "this is basically the same question as one already answered" — to avoid redundant LLM and embedding calls and cut costs. This needs a cache-invalidation strategy tied to re-indexing: a cached answer becomes stale the moment its underlying source document changes, so a semantic cache has to be invalidated (fully, or by checking the source document's version) alongside the indexing pipeline above, not on a separate independent schedule.

Track metrics like retrieval hit-rate (how often relevant chunks are actually found), answer faithfulness drift over time, the rate of "insufficient context" flags (see Augmentation & Prompting → structured output), and per-stage latency, and flag low-confidence answers for human review. RAG systems can silently degrade as the underlying documents change — a source document going stale, a new document category never being ingested, an embedding model quietly deprecated by its provider — so ongoing monitoring matters just as much as initial setup. The tracing tools mentioned in Evaluation (TruLens, Langfuse, Arize Phoenix) are typically the same tools used for production monitoring, not a separate toolset — the trace collected in production becomes the next eval set.