What Is Temporal RAG?
Temporal RAG is retrieval-augmented generation that accounts for when facts were true. Each retrievable fact or passage carries time information, such as the period it was valid or the date it was recorded, and retrieval filters or ranks by how well that time matches the question. A model asked about last quarter, or about right now, then receives evidence from that moment instead of the most similar text from any moment. Temporal RAG matters most when a corpus holds several versions of the same fact.
Updated
What is temporal RAG?
Standard RAG retrieves by meaning. That breaks when the corpus contains the same fact at different times: a price list from March and one from June, a policy before and after an amendment, a customer's address before and after a move. The two versions read almost identically, so they embed almost identically. A 2025 paper on the problem, RAG Meets Temporal Graphs, puts it directly: "Same facts of different time are difficult to distinguish with vector embeddings or conventional knowledge graphs." It also notes that "most RAG evaluations assume a static corpus."
Approaches fall into three groups:
- Time-filtered retrieval. Passages carry validity dates as metadata, and the query filters on them before ranking by similarity. This is the simplest form and covers many cases.
- Temporal knowledge graphs. Facts become timestamped edges, and retrieval walks only the edges valid for the question's time. The paper above models identical facts at different times "as distinct edges to avoid ambiguity," and STAR-RAG aims to "prioritize semantically relevant, time-consistent evidence."
- Bi-temporal memory. The system tracks both when a fact was true and when the system learned it. The Zep paper on agent memory tracks four timestamps per fact, two for "when facts are created or invalidated in the system" and two for "the temporal range during which facts held true."
How temporal RAG works
A time-filtered query in PostgreSQL with pgvector uses one range type column for when each passage was valid and another for when that version was on record:
-- "What did the refund policy say on March 31?" -- as known on April 1
SELECT passage_id, body
FROM policy_passages
WHERE valid_during @> timestamptz '2026-03-31 12:00+00' -- true at that moment
AND recorded_during @> timestamptz '2026-04-01 00:00+00' -- the version on record then
ORDER BY embedding <=> :question_embedding -- then rank by similarity
LIMIT 5;With an approximate index (HNSW or IVFFlat), pgvector applies these filters after the index scan, so a selective filter can return fewer than five rows unless iterative index scans are enabled.
The steps:
- 1.Resolve the question's time. Explicit ("on March 31") or implicit: most questions mean "now."
- 2.Filter by valid time. Keep only passages whose validity range contains that moment.
- 3.Optionally filter by recorded time. For audits ("what did the agent know when it answered?"), keep only the versions on record at that moment.
- 4.Rank by similarity within what remains.
- 5.Supersede, don't overwrite. When a new fact replaces an old one, don't edit or delete the old row. End its recorded range and insert two rows: the old fact with its validity closed where the new one starts, and the new fact. An "as known on April 1" query still finds the old version. Zep's Graphiti engine applies the same rule to validity: when it detects a contradiction, it sets the older fact's end of validity to the newer fact's start.
Why temporal RAG matters in real-time systems
Temporal filters fix questions about the past. Questions about now have a second requirement: the newest fact has to be in the index when the question arrives. If the source changes continuously and the retrieval index is rebuilt on its own schedule, a perfectly time-aware query still returns the last version the index saw. The answer is correctly dated and out of date. That is context lag, and no temporal model fixes it; only shortening the path from the source to the index does.
The opposite case matters as much. If the corpus changes slowly and the question doesn't depend on recency, such as product documentation or a policy archive, validity metadata on a standard vector index is enough, and pgvector in PostgreSQL handles it. The harder version is when facts change continuously, answers drive actions, and retrieved passages have to agree with the structured state the same decision reads. Why retrieval alone falls short there is covered in context-aware AI beyond RAG.
FAQ
Related terms
Memory supersession is how an AI agent's memory replaces facts that have changed, so the agent answers from the current value instead of an outdated one.
Point-in-time correctness means each training example gets feature values as they stood at the label's timestamp, never later ones, so no future data leaks.
Stale embeddings are stored vectors computed from an older version of their source: the row or document changed, but the embedding was not recomputed.
Context lag is the delay between a fact changing at its source and the system an automated decision reads from reflecting it. Also called stale context.
Semantic context is the meaning-bearing layer of decision context — aggregations, vector similarity, LLM-derived signals — computed from the same events.
Agent-ready data is data an AI agent can find, interpret and act on correctly when it acts: reachable, described, permissioned and current enough for the task.
Filtered vector search finds nearest neighbors among rows matching structured predicates. Pre-filtering, post-filtering and in-index filtering differ in recall.