Self-Evolving Search Index: letting the index diagnose its own retrieval failures

Date ingested: 2026-09-19 Source: HuggingFace Daily Papers (7 upvotes) · Yonsei, Samsung Research, UC Irvine, Korea University Links: arXiv 2609.19656 · alphaXiv overview Raw: raw/huggingface/2026-09-19-self-evolving-search-index.md

TL;DR

Retrieval systems represent each document with index keys: the raw text, a summary, generated queries, propositions, scenarios. Doc2Query generates likely queries for a document; SPIKE and EnrichIndex build scenario-based or multi-view representations; RL-Index and AutoIndex learn a representation strategy from relevance labels. All of them commit to one fixed strategy for the whole corpus, chosen by hand or learned once, and none of them can tell you which specific documents their strategy is failing on. This paper moves the self-evolution idea, familiar from self-improving models and agents, onto the index itself: the system diagnoses its own retrieval failures and rewrites only the representations responsible for them, leaving the rest of the corpus alone.

The two limitations it names

1. A strategy that works on one corpus or one retriever fails on another. Prose, code, mathematical text and database schemas break retrieval in different ways, and sparse and dense retrievers respond differently to the same representation. A single global strategy is a compromise against all of them.
2. Existing systems cannot localise blame. They either reprocess the whole corpus or nothing. Targeted repair requires knowing which documents were responsible for which failed queries, and that diagnosis step is what is missing.

The cost argument follows from the second point and is the reason this belongs in the wiki's efficiency thread as much as its retrieval thread. Broad reprocessing of a corpus is the expensive operation, and it is what every prior method requires in order to improve. If failures are sparse and localisable, selective repair is cheaper by roughly the sparsity factor, and it can be run continuously rather than as a periodic reindex.

How this relates to prior wiki state

This is the same structural move the wiki has now seen four times in four different subsystems, and that is worth naming. The recurring claim is: uniform treatment of a corpus, a token stream, or a parameter set is wasteful, because the signal is concentrated and the system can be taught to find where. The training-side instances are already on record; this is the retrieval-side instance. The index is not uniformly bad, it is bad in specific places, and the win comes from spending the repair budget only there.

It also sits against parametric context internalization as the opposite bet on the same problem. That page tracks methods that remove the retrieval step entirely by predicting a LoRA adapter from a document in a single hypernetwork pass, so query time carries zero context tokens. Self-Evolving Search Index bets the other way, that retrieval is worth keeping and the fix is a better index. The two are cleanly distinguished by amortization: internalization wins when an item is queried many times, index repair wins when the corpus is large and each item is queried rarely. Nobody has plotted the crossover, and it is a straightforward experiment.

Gaps

• The diagnosis step is the whole contribution and its precision is what determines whether targeted repair beats global reprocessing. A diagnoser that blames the wrong documents is worse than no diagnoser.
• Self-evolution without held-out validation risks overfitting the index to the observed query distribution, which is exactly the distribution that will shift.
• No cost accounting against a periodic full reindex, which is the baseline an operator actually runs.