Lightfoot builds an AI retrieval graph designed to forget documents cleanly

What does it mean for a retrieval system to forget?

An AI assistant can search a document collection before answering, a technique called retrieval-augmented generation, or RAG. Graph-based versions connect entities and facts across passages, helping answer questions that require several pieces of evidence rather than one matching paragraph.

But what happens when a source must be removed? Deleting its original text may leave information in merged descriptions or summaries built from several documents.

In a November 2026 preprint, Uday Allu presents Lightfoot, a system designed so that deleting documents produces the same stored graph as indexing only the survivors. The work combines a mathematical argument about its bookkeeping with software benchmark experiments; it is not evidence of general-purpose machine unlearning.

Keeping each connection accountable

Lightfoot makes one large-language-model call per passage to extract entities and facts, including short supporting quotations. Each contribution retains a link to its source passage.

The system then builds shared entities and connections using fixed rules. For example, it links sufficiently similar names of the same entity type and groups connected name occurrences. Names, identifiers and synonym connections depend on the surviving records, not on the order in which documents arrived.

That distinction matters. If deleting a passage changes which names belong together, Lightfoot recomputes the affected groups. It does not ask a language model to rewrite a blended description.

The paper argues that these rules make deletion exact relative to the per-passage extractions. This does not make those extractions factually correct: an erroneous extracted statement can still be stored faithfully.

Retrieval combines graph traversal with a local reranker that scores question–passage pairs. It makes no generative language-model calls before answer generation, but still uses embedding and reranking models. “Model-free” deletion should therefore not be read as meaning the whole system operates without machine learning.

Testing deletion against a fresh build

The strongest deletion check used the study’s 11,402-passage MuSiQue corpus. After removing 1,140 documents, the researcher compared Lightfoot’s remaining database with a separate build from the surviving documents’ cached extractions.

The database fingerprints matched, including entities, aliases, mentions, facts, source associations and synonym edges. Reusing cached extractions is important: the test checks deterministic reconstruction from the same extraction records, rather than whether fresh language-model calls would produce identical outputs.

Deletion took Lightfoot 74 seconds without model calls. HippoRAG 2 also deleted without model calls and was faster, taking nine seconds, although its deletion exactness was not checked. LightRAG required 2,187 model calls and about 3.7 hours. The tested fast-graphrag implementation had no deletion API.

These results concern the retrieval index. They do not demonstrate erasure from model weights, previously generated answers, backups or other systems outside that index.

Lower costs, uneven accuracy

The comparison covered MuSiQue, 2WikiMultiHopQA and HotpotQA, all benchmarks requiring evidence from multiple passages. Systems shared extraction, embedding and answer models to make the comparison more controlled.

At fixed token prices, Lightfoot’s reported indexing costs were 26–31% below HippoRAG 2 and roughly three to six times lower than the other two baselines. Its MuSiQue index cost $1.64, versus $2.23 for HippoRAG 2 and approximately $9.50 for LightRAG. These are normalized model-call costs, not complete operating budgets; LightRAG’s MuSiQue figure was estimated.

Accuracy did not yield a universal winner. On held-out MuSiQue questions, Lightfoot improved recall among the top five retrieved passages by 2.8 percentage points over HippoRAG 2. Recall measures how much of the required supporting evidence was retrieved. On HotpotQA, exact-match answers improved by 7.7 points.

On 2WikiMultiHopQA, however, Lightfoot lost 3.9 points in top-two retrieval recall and 8.4 points in answer F1, which measures overlap with reference-answer words. The paper reports these differences as statistically significant using paired bootstrap intervals.

What remains uncertain

Lightfoot’s retrieval settings were tuned on half the MuSiQue questions. Answer evaluations used only 232–300 questions per dataset, and all systems shared one extraction model and one embedder. That improves experimental comparability but does not establish the best performance each competitor could achieve with its preferred configuration.

The study also did not test collection-wide summarization, an important use case for other graph systems. Its practical contribution is narrower: source-traceable graph construction can make deletion auditable and cheaper without consistently improving or sacrificing accuracy across every benchmark.