Faire évoluer les clés d'un index avec les échecs de retrieval

L'index comme composant adaptable

Les clés d'index qui exposent un document ne sont pas également efficaces pour un corpus, un retriever ou une intention donnée. Self-Evolving Search Index propose que l'index diagnostique lui-même les requêtes mal servies au lieu d'attendre une nouvelle stratégie conçue manuellement.

Résultats rapportés

Self-Index boucle entre auto-diagnostic, révision sélective et validation des clés, puis ajoute une auto-exploration de requêtes produites à partir des documents. Sur BRIGHT, l'amélioration moyenne finale annoncée est de 40,4 % avec BM25, 57,0 % avec BGE et 38,8 % avec Qwen3-Embedding-8B, par rapport à l'index de base. Sur les jeux de tables, l'amélioration moyenne atteint 49,1 % avec BM25. Dans BrowseComp-Plus, les expériences rapportent des gains d'accuracy et de rappel des preuves, avec généralement moins d'appels de recherche. Sur LongMemEval-V2, l'accuracy globale progresse de 0,415 à 0,472 pour Query→Slice, de 0,448 à 0,503 pour Slice+Notes et de 0,532 à 0,581 pour AgentRunbook-R.

Interprétation éditoriale

Le point intéressant est la granularité : modifier les clés sans réécrire le corpus permet de traiter un défaut de récupération comme un problème local. En production, cela impose toutefois de versionner les clés, de conserver les requêtes qui ont déclenché une modification et de pouvoir revenir à un état antérieur.

Limites

Les performances dépendent des jeux BRIGHT, des tables, BrowseComp-Plus et LongMemEval-V2, ainsi que des backbone et juges LLM utilisés. Une auto-révision peut propager une erreur si le diagnostic ou la validation est mauvais. Le papier mesure l'efficacité expérimentale, pas une garantie d'absence de dérive ou de coût nul.

Sources

Résultats et protocoles : résumé ArXiv · PDF. Les recommandations de versionnage sont éditoriales.