Self-Evolving Search Index
Sangam Lee, Wonjae Lee, Sunghwan Kim, Deogyong Kim, Jaehoon Kim, Daye Nam, SeongKu Kang, Dongha Lee
cs.IR, cs.AI
2026-09-17
Self-Index rewrites failing index keys and simulates extra queries. On BRIGHT with BGE, nDCG@10 rises from 13.9 to 21.8 (+57%); search agents also answer better with fewer calls.
Retrieval quality is capped by how index keys present each document. Doc2Query, SPIKE, EnrichIndex, and RL-Index all pick a rewrite strategy in advance, or learn one from labeled pairs, then reprocess the whole collection. Change the corpus type (natural language, code, tables) or the retriever (BM25, BGE, Qwen3-Embedding) and the same strategy can help or hurt. When the environment shifts, people diagnose failures, revise the strategy, and rebuild. That loop is expensive, and it does not keep up with the query mix agents produce.
Yonsei University, with a co-first author at Samsung Research, turns that human loop into a self-evolving index.
Each document has a set of keys. The retriever scores a document by the best key-query relevance in that set. Self-Index never edits source text; it only revises keys.
An Optimizer built on Qwen3.6-35B-A3B runs a three-stage loop over a query batch. Self-Diagnosis calls the current retriever and builds a co-retrieval profile for each hit key: which keys from other documents appear with it, and how often. Together with the source document, that profile is used to say whether the key exposes the information that actually distinguishes the document. Self-Revision rewrites the whole key set for a flagged document, so a one-key edit does not duplicate content already covered by siblings. Self-Validation admits a new key only if it is faithful to the source, specific to that document, and better separated from competing keys. The original-text key is always kept. Fail the checks and the index stays put.
Reacting only to observed queries under-covers the demand space. A Query Simulator samples documents, writes plausible unseen queries, filters them with Jaccard dissimilarity against queries already used, and hands the rest to the Optimizer. In the main experiments the index evolves only on simulated queries; evaluation queries stay hidden.
BRIGHT nDCG@10, three-run means:
| Retriever | Base | Self-Index | Relative |
| BM25 | 14.5 | 20.4 | +40.4% |
| BGE | 13.9 | 21.8 | +57.0% |
| Qwen3-Emb-8B | 18.8 | 26.1 | +38.8% |
Self-Index holds the best domain average for natural language, code, and math under every retriever. Doc2Query drops in some settings (BGE -6.2%). SPIKE and RL-Index mostly post single-digit relative gains. On table retrieval (Spider2, FIBEN, BEAVER), BM25 moves from 33.2 to 49.5 (+49.1%) and Qwen3-Emb-8B from 49.0 to 57.0 (+16.2%), above EnrichIndex, which was built for tables.
Downstream on BrowseComp-Plus, GPT-OSS-120B with BM25 rises from 31.08 to 58.92 accuracy and search calls fall from 21.16 to 16.62; GPT-5.4-nano with BM25 rises from 36.51 to 64.94. Expanding the corpus to 400K documents, Self-Index keeps accuracy while SPIKE and index-free direct corpus interaction degrade more. On LongMemEval-V2, three memory systems gain 13.9%, 12.4%, and 9.2% relative overall; the gotchas slice, which depends more on how memories are written than on how they are fetched, barely moves.
Ablations: drop validation and the natural-language average falls from 26.6 to 16.1, below the base index. Each of the three checks hurts when removed. Drop co-retrieval profiles and natural language falls 6.9. Drop query dissimilarity and all three corpus types fall.
Index optimization has been "pick a rewrite, rebuild the collection." Self-Index closes diagnose, local rewrite, gate, and blind-spot exploration in one loop, and the same procedure works for BM25 and dense retrievers, tables and code. For search agents, higher accuracy with fewer search calls is a joint win on quality and online cost. Because only keys change, it can sit on top of an existing memory store.
The bill is offline: every round spends an LLM on diagnosis and rewrite. This is not free. It replaces a human ops loop with a model ops loop.
There is no dedicated limitations section. The Optimizer is a 35B-class MoE, so the offline token bill is unlikely to be small, and the main text barely reports tokens or wall-clock. Evaluation queries are held out, but simulated queries are still sampled from the same corpus, so the generalization claim is "unseen queries," not "unseen collections." Some subsets recede under a rising average: BM25 on LeetCode falls from 24.4 to 22.4. Gotchas in the memory study do not improve, so Self-Index cannot fix badly written memory contents. The corpus-scale study uses BM25 and one agent backbone; dense retrievers at million-document scale are untested.