Indexing Cadence: Defining Data Freshness in RAG
There's no single correct re-index cadence for every source. Freshness is a product SLA set by each data type's risk, not a fixed technical parameter.
Part of: The RAG Pipeline: 5 Decisions That Control Answer Quality
A RAG pipeline can nail chunking, retrieval, and grounding, and still hand a user a wrong answer for a reason none of those solve: the index is out of date. Deciding how often to re-index each source is a product decision with real consequences, not an infrastructure detail to set once and forget.
The Incremental Index Sync Flow
Why a Correct Pipeline Can Still Return a Stale Answer
Retrieval only ever surfaces what's already been indexed - if the underlying document changed an hour ago and the index hasn't caught up, a pipeline with flawless chunking, retrieval, and grounding will still confidently retrieve and cite the outdated version. This isn't a niche edge case. Every RAG system indexes a moving target - pricing pages, support tickets, product docs, inventory - and every one of those sources changes on its own schedule, independent of how well the rest of the pipeline is built.
Freshness Is a Product SLA, Not a Technical Constant
There's no single "correct" re-index cadence that applies across a RAG system. Kapa.ai's guidance on keeping a knowledge base in sync is direct about this: refresh cadence should vary by source type - minutes for fast-changing sources like support tickets or internal wikis, hours for code, daily for a full site crawl of marketing pages. The right cadence isn't a technical parameter you tune once for performance; it's a service-level agreement you set per data type, based on how much damage a stale answer in that category actually does.
Why the Same Cadence Is Wrong for Every Source
Treating every data source the same way fails in both directions. A cadence tuned for low-risk static content (daily, say) is too slow for pricing or inventory data, where a few hours of staleness can mean quoting a customer a price that no longer exists. Conversely, a cadence tuned for fast-changing operational data (every few minutes) is wasteful when applied to content that only changes with a quarterly release - it burns embedding API calls and pipeline compute for no accuracy gain, since nothing actually changed between most of those refresh cycles.
Cadence Mismatch Failure Inspector
The pricing page is updated at 9am (Pro plan drops from $49 to $39).
The full knowledge base is re-indexed once a day, on a fixed 2am schedule.
At 3pm the same day, the chatbot still quotes $49 to a customer deciding whether to buy.
The once-a-day, fixed-time cadence doesn't account for pricing being high-risk data — a price change directly affects a purchase decision, but it's treated like any other static page.
→ Set a dedicated threshold for pricing/inventory data: max staleness measured in minutes, not days
Reading Your Own Staleness Risk
The two failure directions above aren't symmetric in cost. A cadence that's too slow produces a wrong answer a user actually sees and acts on; a cadence that's too fast just burns compute with no accuracy upside. That asymmetry is the actual sorting rule: when you're unsure which way to round for a given source, err toward a tighter cadence only if getting it wrong would change a user's decision (a price, a status, an availability check) - not just because the data updates frequently in the abstract. A source that changes often but where staleness is harmless doesn't need the same urgency as one that changes rarely but where staleness is costly.
Re-indexing Everything Doesn't Scale - Incrementally Syncing Does
Even once you've picked the right cadence per source, re-embedding an entire corpus on every refresh cycle gets expensive and slow as the corpus grows. The fix used in production ingestion pipelines - documented in both LangChain's Record Manager and LlamaIndex's ingestion pipeline - is incremental sync: compute a content hash for each document or chunk, and only re-embed and re-index the ones whose hash actually changed since the last sync. A ticket whose status flips gets re-indexed in the next cycle; the other ten thousand tickets that didn't change get skipped entirely, at any cadence.
Freshness SLA by Data Type
Data type → maximum staleness threshold → risk if violated
A price change, stockout, or order status update directly affects a purchase decision — a few hours of index lag is enough for a bot to quote the wrong price to a customer mid-checkout.
Status changes frequently within a workday — a few hours of lag can make a bot report a closed ticket as still open, frustrating a customer who follows up.
Changes with releases or content edits — 1-2 days of lag usually just means slightly outdated instructions, rarely affecting an immediate decision.
There is no single 'correct re-index cadence' that applies to every source — each data type needs its own threshold based onrisk if violated, not rate of change
This table is derived from principles (the Kapa.ai blog plus LangChain Record Manager/LlamaIndex ingestion pipeline docs), not a benchmark measured from a specific dataset — no academic paper or vendor source (Anthropic/OpenAI/Google) publishes standard numbers for this topic. Use it to classify your own data sources by risk, not to copy these exact time thresholds into production without validating them against your actual product.
Setting Your Own Freshness Thresholds
Start by grouping your data sources by what happens when they're stale, not by how they're stored or where they live. A source where staleness causes a wrong purchase, refund, or compliance decision needs a tight threshold measured in minutes, checked via hash-based incremental sync running frequently. A source where staleness just means slightly outdated phrasing in a doc can run on a daily or weekly cadence without meaningful risk. The mistake to avoid is picking one cadence for the whole pipeline and applying it uniformly - it's guaranteed to be wrong for at least one of your source types.
Common Pitfalls in Indexing Cadence
The recurring mistakes: setting one global re-index schedule for every source instead of grouping by risk; assuming a fast cadence is always safer, when it mostly just adds cost with no accuracy benefit on slow-changing sources; re-embedding a full corpus on every cycle instead of using hash-based incremental sync, which becomes a real bottleneck as the corpus grows; and treating freshness as solved once a cadence is picked, rather than revisiting it when a source's actual rate of change shifts - a page that used to update quarterly can start updating weekly after a product changes shape, and the cadence set for its old behavior quietly becomes wrong.