Article · IA & agents
Recherche augmentée et récupération d'information
Quatorze preprints sur le RAG: scores classiques, limites des embeddings, découpage de corpus, graphes de preuves, budgets d'accès et traçabilité.
Ce dossier rassemble quatorze prépublications consacrées à la récupération d'information et à la génération augmentée par recherche. Elles ne parlent pas du même objet technique, mais elles posent toutes la même question sous des angles différents : qu'est-ce qu'un système de recherche est réellement capable de prouver sur ce qu'il renvoie. Certaines travaillent sur le score de pertinence lui-même, d'autres sur la découpe du corpus, d'autres sur l'ordre des opérations entre recherche et génération, d'autres encore sur l'interface qui expose la trace de recherche à un humain.
Lues ensemble, ces études dessinent un pipeline RAG en couches, où chaque couche a ses propres modes d'échec et ses propres métriques. Un bon rappel ne garantit pas une bonne réponse. Un passage correctement classé ne contient pas forcément la valeur demandée. Une réponse fluide ne dit pas quels documents l'ont soutenue. Plusieurs des travaux réunis ici consistent précisément à rendre ces écarts mesurables au lieu de les laisser se compenser dans une moyenne d'exactitude.
Le lecteur en retire une grille de diagnostic : où placer un budget, quoi journaliser, quelles relations tester explicitement, et quelles affirmations de performance restent liées au protocole qui les a produites. Les chiffres cités proviennent des prépublications correspondantes. Rien ici n'a été reproduit, et plusieurs résultats sont présentés par leurs auteurs comme directionnels.
TF-IDF et BM25 relus comme des divergences d'information
TF-IDF et BM25 s'apprennent généralement comme des recettes : fréquence du terme, rareté dans le corpus, correction de longueur. Le preprint TF-IDF and BM25 Are Exact KL Divergences propose une lecture probabiliste unifiée, où les deux scores s'écrivent exactement comme des divergences de Kullback-Leibler entre des modèles construits pour décrire la présence de mots-clés.
Pour TF-IDF, les auteurs définissent un index de document, un token, un événement indiquant qu'un token est considéré comme clé et un événement représentant sa fréquence dans le corpus. La probabilité conditionnelle attachée au document reproduit la fréquence du terme, la probabilité de référence utilise sa fréquence documentaire, et la divergence conditionnelle obtenue correspond au produit TF × IDF. Pour BM25, le même cadre ajoute la saturation de fréquence et la normalisation de longueur. La variante étudiée est celle qui contient la correction +1 dans l'IDF, courante dans les implémentations pratiques, les paramètres k₁ et b entrant dans le modèle probabiliste par un modèle auxiliaire. La version historique sans correction est traitée séparément comme une différence entre deux divergences. Le papier montre aussi qu'une requête peut être vue comme une distribution de tokens, le score devenant une somme pondérée de contributions.
Le résultat principal est une dérivation exacte, pas une nouvelle mesure évaluée en classement. Les auteurs précisent que « mot-clé », « mot courant » et document « verbeux » restent des interprétations choisies pour donner un sens aux variables. Le cadre ne traite pas la synonymie, l'ordre des mots, les langues morphologiquement riches, et il ne démontre aucune supériorité universelle de ces scores.
Quand un embedding confond conversion et proximité
Un espace d'embeddings est souvent utilisé comme un espace de proximité : deux textes voisins devraient donner des vecteurs voisins. Juri Opitz et Andrianos Michail testent cette intuition sur un cas où la relation à préserver est nette, les mesures physiques. « 1 mètre » et « 100 centimètres » désignent la même quantité, et « 15 kilomètres » est plus éloigné de « 1 mètre » que « 105 centimètres ».
Les auteurs évaluent 24 modèles d'embeddings sur des expressions de masse, de distance, de temps et de volume, comparent les proximités observées à la structure attendue d'une mesure physique, testent la compréhension des conversions et construisent un petit benchmark dédié. Le résultat rapporté est peu flatteur : l'alignement avec les relations physiques est faible et les motifs observés sont parfois irréguliers. Les artefacts apparaissent à travers les modèles testés, sans dépendre clairement de l'architecture, de la date de sortie ou de la dimension annoncée. Une partie du comportement est reliée à la similarité de surface des chaînes, des expressions partageant des caractères se retrouvant rapprochées alors que leur relation numérique est fausse. Une simple recalibration des scores n'améliore pas substantiellement l'alignement dans les expériences rapportées.
Le papier est un preprint, et son protocole porte sur un sous-ensemble de modèles et de formulations. Il ne permet pas de conclure que toutes les tâches de recherche échouent, ni qu'une autre représentation résoudrait la conversion. Les effets dépendent aussi du tokenizer, du texte d'entrée et de la métrique de similarité. La lecture éditoriale qu'on peut en tirer est plus modeste : une équipe qui indexe des prix, des versions, des tailles ou des seuils devrait tester explicitement ces relations, avec des conversions équivalentes et des variantes de formatage, et vérifier la valeur réellement présente dans le passage récupéré.
Pourquoi un Top-K ne fixe pas le coût d'un retrieval hybride
Un moteur hybride fusionne souvent les listes d'un retriever dense et d'un retriever lexical avec Reciprocal Rank Fusion. On choisit une profondeur L par liste et un Top-K à retourner. Cette convention donne une taille de sortie, pas une borne fiable sur le nombre d'éléments à lire : un document peut apparaître plus loin dans une liste et changer l'ordre fusionné. Le preprint Top-K Is Not a Budget for Hybrid Retrieval présente DiBud, pour « Direct Budgeting », qui reçoit directement un budget d'accès, lit progressivement les listes, borne les contributions encore inconnues et renvoie le préfixe de classement qu'il peut certifier comme exact lorsque le budget est atteint.
Pour chaque document observé, DiBud conserve une borne inférieure et une borne supérieure de score RRF, et borne une contribution non lue par la contribution maximale qu'elle pourrait encore apporter. Un document est émis seulement si sa borne inférieure dépasse les bornes de tous les concurrents, y compris non vus. La sortie n'est donc pas toujours un Top-20 complet : elle peut être un préfixe exact plus court.
Les expériences rejouent 770 requêtes sur cinq ensembles, avec un RRF de contribution 1/(59 + r). Pour TREC-DL 2019, le coût pour terminer un Top-20 a une médiane de 311 accès, un 95ᵉ percentile de 196 410 et un maximum de 3 533 518. Avec un budget de 2048 accès, la lecture sélective certifie en moyenne 45,05 positions parmi les 100 premières contre 41,77 pour une lecture équilibrée, soit +7,86 %. Après calibration pour conserver 95 % de la qualité, les requêtes de test gardent entre 95,05 % et 97,68 % du nDCG@20 moyen, avec 65,92 % à 99,53 % d'accès en moins selon l'ensemble. DiBud est étudié sur deux canaux et un score RRF déterministe ; une certification de rang ne prouve pas la pertinence pour l'utilisateur.
Découper un corpus autour des entités utiles
Dans un pipeline RAG, on discute du modèle d'embeddings ou du générateur avant de regarder la découpe du corpus, alors que la frontière des unités récupérables détermine ce que le retriever peut présenter. Le preprint EAR: Entity-Aware Partitioning Approach for Retrieval-Augmented Generation Development teste une alternative aux chunks uniformes sur des questions à choix multiple. EAR extrait des ancres de surface dans la question, les réponses et le corpus, puis indexe des fenêtres locales autour des ancres correspondantes. Une variante parent-expanded ajoute le passage parent et un petit résumé extractif quand le contexte local ne suffit pas.
L'« entité » d'EAR n'est pas la sortie d'un système général de reconnaissance d'entités : c'est une ancre textuelle normalisée, année, groupe capitalisé, expression d'événement ou option courte. Les pages sont nettoyées et découpées en parents de 260 mots avec 60 mots de recouvrement, une fenêtre enfant allant jusqu'à 80 mots de chaque côté de l'ancre. Les fenêtres sont classées par correspondance d'ancres, chevauchement lexical et correspondance de date, puis dédupliquées.
L'évaluation porte sur 153 questions soutenues par le corpus, issues d'un protocole de type MMLU et de quatre fichiers de manuels scolaires nettoyés. Le corpus final comprend 1108 pages, dont 772 avec du texte narratif, 3955 blocs conservés et 4429 blocs supprimés. À top-3 et top-8, les fenêtres EAR réduisent le nombre de mots récupérés de 37,5 à 40,2 % par rapport aux chunks. Les variations d'exactitude vont de +5,2 à -3,9 points au top-3 et de +5,9 à -4,6 au top-8 selon le modèle, et aucune différence de fenêtre n'est statistiquement significative dans le protocole. L'étude trouve un ancrage exact pour 151 des 153 questions, couverture opérationnelle et non mesure de précision d'un NER. Les auteurs demandent eux-mêmes une validation séparée avant transfert à un autre domaine.
Un tableur n'est pas une suite de paragraphes
Une question posée sur un tableur dépend rarement d'une cellule isolée. L'en-tête, l'unité, la période, la formule et la relation entre lignes font partie de la réponse. Zofia Smoleń étudie ce goulot d'étranglement pour les systèmes RAG pilotés par LLM, dans un preprint ArXiv consacré à l'interprétation de la structure de grille.
Le framework proposé découpe le tableur en chunks interprétables après avoir attribué un rôle aux cellules. L'enrichissement améliore la compréhension du contexte et la génération des réponses, sans nécessairement améliorer la récupération elle-même. La distinction compte : un retriever peut trouver la bonne zone sans que le générateur comprenne la structure qui relie les cellules, et inversement un gain de génération ne corrige pas un index mal construit.
Le résumé souligne une limite structurelle. Les feuilles sont des données bidimensionnelles peu structurées, avec des relations continues et un nombre potentiellement illimité de rôles. Une liste de classes finie ne peut donc pas représenter parfaitement toutes les nuances, même avec des annotations humaines. Les auteurs défendent une piste qui dépasse la classification discrète : réduire la dimension de la grille pour la transformer en texte linéaire tout en conservant ses relations pertinentes.
Les résultats dépendent de l'annotation des rôles, du framework et des jeux de tableurs retenus, et l'aplatissement proposé peut perdre des relations si sa représentation n'est pas contrôlée. Le document est un preprint. Pour un agent qui interroge des feuilles, la conséquence éditoriale est de conserver coordonnées, formules et unités à côté du texte récupéré, et de demander à l'agent de citer la plage utilisée plutôt qu'un extrait nu.
Faire évoluer les clés d'un index avec ses échecs
Les clés d'index qui exposent un document ne sont pas également efficaces selon le corpus, le retriever ou l'intention. 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 à la main. 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.
Le point notable est la granularité : modifier les clés sans réécrire le corpus traite un défaut de récupération comme un problème local. En production, cela suppose de versionner les clés, de garder les requêtes qui ont déclenché une modification et de pouvoir revenir à un état antérieur, ce qui relève de la lecture éditoriale et non des mesures du papier.
Les performances dépendent des jeux BRIGHT, des tables, de BrowseComp-Plus et de 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 une efficacité expérimentale, pas une absence de dérive ni un coût nul.
G3RAG : des preuves multi-hop sans graphe construit par LLM
Pour une question multi-hop, les passages les plus proches lexicalement ne mènent pas toujours au document qui porte la réponse. Les graphes construits par extraction d'entités coûtent beaucoup de tokens et peuvent propager du bruit. G3RAG choisit un graphe composé uniquement de documents.
Les arêtes utilisent le produit cos(theta) × sin(theta), qui favorise à la fois une cohérence directionnelle et une nouveauté orthogonale. Une pénalité de densité réduit le poids des hubs, et une diffusion contrôlée part de quelques graines filtrées par un LLM. Le mécanisme règle donc explicitement le compromis entre rester dans le sujet et sortir d'un voisinage redondant, ce qui rejoint les questions de structure abordées dans le dossier graphes, causalité et raisonnement.
Sur MuSiQue, 2WikiMultiHopQA et HotpotQA, avec Nv-embed-v2 et Qwen3-8B-embed, les auteurs rapportent le meilleur F1 moyen et le meilleur taux de hit du document-réponse parmi les graphes comparés. Le gain atteint 4,26 points de F1 en moyenne et 5,76 points sur MuSiQue. La construction du graphe n'utilise pas de tokens générés, contrairement aux méthodes d'extraction d'entités évaluées.
Les seuils de similarité et la pénalité sont réglés sur des corpus précis, et le papier indique lui-même qu'un seuil universel reste difficile à établir. Les résultats portent sur trois benchmarks multi-hop et deux modèles d'embedding. La suppression du coût LLM concerne la construction du graphe, pas toute l'inférence RAG. Un meilleur chemin de preuves ne remplace pas la validation du contexte final par le générateur.
Pourquoi un RAG de dépannage doit mémoriser l'état du cas
Une réponse de dépannage dépend rarement d'un seul paragraphe. L'état initial, les symptômes, les vérifications déjà faites et les actions qui ont échoué changent la prochaine étape utile. Mingxuan Zhang et ses coauteurs reprochent aux RAG classiques de traiter ces dossiers comme des documents statiques. RAFT, pour Retrieval-Augmented Framework for Troubleshooting Agents, extrait chaque dossier clôturé sous forme de chaîne d'entrées temporelles. La récupération peut viser une étape intermédiaire qui ressemble à l'état courant, puis restituer la trajectoire du dossier parent autour de ce point.
Le système indexe des états et des transitions : symptôme observé, action menée, résultat obtenu, évolution du diagnostic. Un graphe optionnel relie des cas selon une représentation de similarité configurable. Le traitement des nouveaux dossiers peut rester incrémental, l'ajout ou la correction d'un cas ne demandant pas de reconstruire tout le corpus.
Les expériences utilisent un benchmark synthétique construit à partir de documentation Microsoft Learn et un ensemble de tickets Apache Jira portant des liens de doublon audités. Le résumé indique que RAFT améliore le Case Hit par rapport au RAG classique et à des variantes GraphRAG, à plusieurs moments de progression du cas. Les résultats Jira sont présentés comme une preuve directionnelle de transfert, avec 30 groupes audités et 570 distracteurs.
Le preprint évalue d'abord la couche de récupération, sans déployer un agent de support complet, ce qui ne mesure pas la qualité de la résolution finale. Le benchmark synthétique ne remplace pas des incidents réels et les liens Jira ne constituent pas tous des négatifs certifiés. RAFT est un preprint annoncé comme accepté à EMNLP 2026 Industry Track dans son fulltext, ce qui ne vaut pas validation indépendante.
DUPAR : accélérer la recherche vocale avec un cache de preuves
Un assistant vocal qui cherche dans une base textuelle passe souvent par la reconnaissance automatique de la parole, puis par un encodeur de texte. Une erreur sur un nom propre ou un terme technique contamine alors le retrieval. Le preprint DUPAR: Dual-Path Conversational Retrieval via Speech Retriever with Cross-Turn Evidence Caching fait de la conversation précédente une source de contexte, sans supprimer le fallback classique. Un chemin rapide encode directement la parole et cherche dans un cache de preuves issu du tour précédent ; si la confiance est insuffisante, un chemin lent combine la recherche audio et la recherche sur le transcript ASR. Les éléments retenus et leurs voisins à un saut dans un graphe de chunks alimentent le cache suivant.
Le cache initial est vide, donc le premier tour emprunte le chemin lent. Pour un tour suivant, le score de confiance est la similarité maximale entre l'embedding audio et les chunks du cache.
Sur une base de 1890 chunks et 1000 requêtes vocales propres, l'encodeur audio atteint Recall@1 de 67,6 % contre 67,7 % pour le pipeline ASR + texte, et Recall@10 de 88,6 % contre 89,2 %. Les auteurs rapportent un gain de vitesse côté requête de 3,75×. Sous bruit synthétique, la moyenne Recall@10 est de 0,875 contre 0,771, et à 5 dB de 0,862 contre 0,608. Sur une cohorte de styles de parole, Recall@1 progresse de 65,40 % à 69,60 %. Dans une analyse conditionnelle de 31 suivis provenant de 21 sessions, la restriction au cache passe de 35,48 % à 67,74 % en Recall@1 lorsque le bon chunk précédent est déjà présent et connecté, condition qui ne décrit pas tous les dialogues. L'étude utilise de la parole synthétique et une base spécialisée ; seuil, graphe et fallback restent à réévaluer sur de vrais dialogues.
Sélectionner les preuves avant d'étendre une requête
Une expansion de requête par LLM est souvent traitée comme un problème de génération : produire des mots-clés, un pseudo-document ou une réponse hypothétique. Dans un pipeline corpus-aware, le modèle lit pourtant déjà des passages récupérés, et la qualité de l'expansion dépend de la sélection de ces passages. Le preprint EviQE: Evidence Selection for LLM-Based Query Expansion traite cette sélection comme une décision distincte. Plusieurs reformulateurs tournent indépendamment, leurs résultats sont réunis dans un pool dédupliqué, un sélecteur choisit un petit budget de documents, et le générateur produit une seule expansion à partir de la requête initiale et de ce sous-ensemble.
Le papier compare un signal d'accord entre reformulateurs, une fusion tenant compte du rang et un score de pertinence attribué par un LLM juge. Tous les candidats sont évalués par rapport à la requête originale, ce qui évite que le reformulateur ayant trouvé un passage impose aussi la définition de sa pertinence. Le protocole utilise jusqu'à dix passages par source et sélectionne dix passages pour la génération.
Sur trois jeux TREC DL et cinq collections BEIR, les reformulateurs récupèrent souvent des documents différents pour une même requête. La couverture au niveau de la requête reste élevée, tandis que la couverture documentaire de chaque source est beaucoup plus basse. Le pool apporte des gains de rappel par rapport à une source individuelle, mais sa densité varie selon les collections. Le sélecteur fondé sur le score de pertinence est présenté comme le plus régulier. Les gains moyens diminuent ou disparaissent quand on ajoute des tours supplémentaires après avoir déjà sélectionné de bonnes preuves. Les résultats dépendent des reformulateurs, des juges, du BM25, du budget et des collections ; le papier n'établit pas que chaque document sélectionné soit une preuve suffisante.
DRAG : router recherche et génération, avec un seuil à clarifier
DRAG part d'un constat expérimental : une configuration de recherche et de génération plus complexe ne domine pas toutes les autres pour chaque question. Le bon compromis dépend de la requête, des documents récupérés et de l'effort demandé au générateur. Les auteurs proposent une variante fondée sur des signaux de prédiction de performance, et une variante supervisée qui apprend à sélectionner une configuration. La première choisit d'abord un moteur, puis un générateur en tenant compte du contexte obtenu. Pour éviter d'exécuter tous les moteurs, le routage de recherche utilise des caractéristiques de la requête et du corpus disponibles avant récupération, et le choix du générateur s'appuie notamment sur la perplexité du contexte. Une faible perplexité indique un accord avec la distribution du modèle, pas la présence du fait demandé.
Une ambiguïté subsiste dans le texte officiel. La section GPP décrit l'envoi d'un contexte à faible perplexité vers un générateur léger, et l'équation de sélection utilise une condition « inférieure ou égale au seuil ». Plus bas, le paragraphe opérationnel indique de sélectionner le générateur courant lorsque la perplexité dépasse le seuil, puis d'escalader sinon. Ces formulations donnent des directions opposées, et la source lue ne tranche pas à la place des auteurs : une vérification du code ou une clarification est nécessaire avant toute implémentation fidèle.
Les évaluations portent sur TriviaQA, HotpotQA, MuSiQue et FRAMES. La variante supervisée améliore le compromis rapporté, mais l'oracle conserve un avantage, oracle qui utilise des informations connues après coup et n'est donc pas une politique déployable. La section des résultats précise que les améliorations hors distribution ne sont pas toujours statistiquement significatives. Les questions de routage et de budget d'effort recoupent celles du dossier agents, architecture et outils.
Rendre le contexte RAG inspectable avant la génération
Dans une exploration scientifique, l'utilisateur reçoit souvent un résumé sans voir les requêtes dérivées, les passages retenus ou les éléments écartés. FootprintRAG traite ce contexte de preuves comme un objet de travail explicite, manipulable avant l'appel au générateur.
Le système découpe les articles en unités textuelles et en unités liées aux figures, génère plusieurs directions de requête, récupère et évalue les preuves sur plusieurs tours, puis propose des candidats supplémentaires classés par ERS. Ses vues coordonnées relient les trajectoires de retrieval, les révisions de l'état des preuves et un résumé dont la provenance remonte aux unités confirmées. Le contrôle humain se déplace ainsi vers le moment de la construction du contexte, plutôt qu'un bouton de régénération placé après coup.
Dans une étude de 10 participants sur un corpus de 16 articles, les évaluations moyennes atteignent 4,9/5 pour la révision des preuves et la confirmation du contexte, 4,8/5 pour juger l'utilité des preuves et 4,6/5 pour voir les expansions de requêtes. Les participants ont réalisé en moyenne 25,1 opérations au niveau des preuves.
Les études utilisent des corpus bornés de 10 à 48 articles et une tâche de littérature en visualisation bioinformatique. Les figures sont représentées par leurs légendes, leur texte voisin et des descriptions générées, sans embedding visuel complet. Les scores de satisfaction sont subjectifs et ne prouvent pas une amélioration générale de la qualité scientifique. L'affirmation reste donc limitée à une préférence déclarée d'utilisateurs sur une tâche précise, et non à un gain de justesse mesuré.
Rendre une recherche traçable dans des archives bruitées
Les archives numérisées cumulent OCR imparfait, genres documentaires hétérogènes et références difficiles à suivre. Une réponse plausible n'y suffit pas : le chercheur doit savoir quels passages ont été retenus et pourquoi. Le preprint « TRACE: Accountable Agentic Retrieval for Source Discovery in Digital Archives » propose une chaîne dédiée à la découverte de sources. Il a été développé dans le projet DECIDON, autour de débats parlementaires et de presse de la Troisième République, et reste un prototype interne, pas un service public de la Bibliothèque nationale de France.
TRACE décompose la question en sous-questions orientées par le corpus, combine plusieurs canaux de recherche, puis décide d'accepter, de rejeter ou de mettre en attente un document. Le classement final s'appuie sur la confirmation entre sous-questions. Un document peut donc être conservé comme piste sans être présenté comme preuve suffisante, et une question multi-hop peut déclencher une nouvelle recherche au lieu de forcer une réponse sur un seul extrait.
Sur HistoriQA-ThirdRepublic, benchmark de 1 752 questions historiques françaises portant sur des journaux et débats de 1887, TRACE atteint R@10 = 0,856 et MRR = 0,653 dans le résumé. Les auteurs rapportent un avantage sur des bases sparse, denses, graphiques et agentiques, en particulier pour les questions multi-hop et inter-corpus. Le système est annoncé à environ 0,02 dollar par question dans sa configuration d'inférence hébergée. Le prototype est accessible à 24 chercheurs de six institutions partenaires et a servi à plusieurs centaines de requêtes exploratoires, selon la section de discussion.
Le benchmark couvre une seule année et des corpus historiques français. Les auteurs signalent qu'un petit nombre de questions multi-hop est mal décomposé et que l'évaluation de l'adoption et de la charge de lecture reste à faire.
COMPASS : le routage par clusters à 100 000 nœuds
Ce travail ne relève pas du RAG mais de l'optimisation combinatoire, et il figure ici parce qu'il traite une autre forme de décision de recherche sous contrainte d'échelle. Dans un Ordered Clustered TSP, les nœuds sont répartis en clusters visités dans un ordre imposé. Résoudre chaque cluster séparément puis relier les sous-tours peut produire des frontières incompatibles et enfermer la solution dans un mauvais compromis global.
Ido Greenberg et ses coauteurs proposent COMPASS, qui traite le problème comme une sélection globale des frontières. La méthode génère des candidats d'entrée et de sortie par cluster, les évalue avec un sous-solveur, puis construit un graphe acyclique dont le plus court chemin choisit une combinaison globale. Un agent de reinforcement learning et une programmation dynamique contribuent à sélectionner et relier les candidats.
Les expériences couvrent des instances synthétiques à 10 000 et 100 000 nœuds ainsi qu'un benchmark de commandes Olist à São Paulo. COMPASS obtient les meilleurs coûts dans les benchmarks rapportés et continue de s'améliorer avec le temps, alors que plusieurs méthodes plafonnent. Dans les tableaux, la variante étendue atteint l'écart nul au meilleur connu sur les instances synthétiques 100K et São Paulo 28,5K étudiées.
Les résultats dépendent de la structure en clusters, des candidats conservés et du sous-solveur. Un écart nul au meilleur connu n'est pas une preuve d'optimalité pour toutes les instances, sauf dans les cas où la construction le permet. Les grands tests utilisent du matériel et des budgets précis, et ne constituent pas une garantie de latence sur un autre réseau. Le document est un preprint. Des rapprochements avec les méthodes d'apprentissage pour l'optimisation se trouvent dans le dossier optimisation et théorie de l'apprentissage.
Ce qui se recoupe et ce qui reste ouvert
Le recoupement le plus net est la dissociation entre récupérer et prouver. DiBud certifie un rang sans certifier la pertinence. EAR réduit de 37,5 à 40,2 % les mots récupérés sans variation d'exactitude statistiquement significative dans son protocole. Le travail sur les tableurs constate que l'enrichissement des rôles de cellule améliore la compréhension et la génération sans nécessairement améliorer la récupération. Trois protocoles différents arrivent au même endroit : une métrique de retrieval et une métrique de réponse ne bougent pas ensemble, et une équipe qui n'en suit qu'une se prive du diagnostic.
Deuxième point commun, le budget devient une variable de premier plan plutôt qu'un effet secondaire. DiBud le reçoit en entrée, EviQE fixe dix passages pour la génération alors que son pool peut être bien plus large, DRAG route vers un générateur plus ou moins coûteux, DUPAR substitue un cache à une recherche complète, TRACE annonce environ 0,02 dollar par question. G3RAG et Self-Index déplacent le coût en amont, le premier en construisant son graphe sans tokens générés, le second en révisant des clés plutôt que le corpus. Aucun de ces travaux ne prétend que le budget soit gratuit : il est déplacé, et les auteurs le disent.
Troisième convergence, la trace. FootprintRAG expose les preuves avant la génération, TRACE attribue un statut accepté, rejeté ou en attente à chaque document, RAFT indexe des transitions pour que l'agent voie pourquoi une action avait été tentée. Ces trois systèmes considèrent que la sortie utile n'est pas seulement un texte, mais un texte accompagné de sa provenance.
Les tensions sont tout aussi instructives. Plusieurs travaux misent sur la proximité vectorielle, alors que l'étude des mesures physiques montre un alignement faible sur 24 modèles d'embeddings, en partie attribué à la similarité de surface des chaînes. La relecture de TF-IDF et BM25 comme divergences exactes n'évalue aucun classement, et rappelle qu'une interprétation élégante ne valide pas un réglage. DUPAR et G3RAG s'appuient sur des graphes de chunks, mais G3RAG reconnaît qu'un seuil universel reste difficile à établir, et DUPAR que la proximité de graphe n'est pas une preuve d'intention. EviQE observe que des tours supplémentaires n'ajoutent rien après une bonne sélection, quand Self-Index tire son gain d'une boucle répétée : les deux ne mesurent pas la même boucle, et on ne sait pas laquelle se généralise.
Reste ouvert ce que personne ici ne tranche. Aucun de ces travaux ne mesure la qualité d'une résolution de bout en bout : RAFT évalue sa couche de récupération, FootprintRAG recueille des scores subjectifs, DRAG conserve une incohérence de seuil non résolue dans le texte lu. Les questions de calibration et de confiance déclarée rejoignent celles du dossier évaluation des LLM et incertitude. Ce qui manque, c'est un protocole partagé reliant budget d'accès, certification de rang, structure de corpus et fidélité de la réponse finale.
Sources
- arXiv:2609.14016v1 — TF-IDF and BM25 Are Exact KL Divergences
- arXiv:2609.20821v1 — Embedding Models Measure in Peculiar Ways
- arXiv:2609.15143v1 — Top-K Is Not a Budget for Hybrid Retrieval (DiBud)
- arXiv:2609.12268v1 — EAR: Entity-Aware Partitioning Approach for Retrieval-Augmented Generation Development
- arXiv:2609.20732v1 — Q&A on Any Spreadsheet Requires Interpreting Its Grid Structure
- arXiv:2609.19656v1 — Self-Evolving Search Index
- arXiv:2609.19622v1 — G3RAG
- arXiv:2609.20754v1 — RAFT: A Stateful Retrieval-Augmented Framework for Troubleshooting Agents
- arXiv:2609.18042v1 — DUPAR: Dual-Path Conversational Retrieval via Speech Retriever with Cross-Turn Evidence Caching
- arXiv:2609.14875v1 — EviQE: Evidence Selection for LLM-Based Query Expansion
- arXiv:2609.17709v1 — One Size Does Not Fit All! Dynamic Retriever and Generator Selection for RAG
- arXiv:2609.19601v1 — FootprintRAG
- arXiv:2609.19897v1 — TRACE: Accountable Agentic Retrieval for Source Discovery in Digital Archives
- arXiv:2609.20352v1 — COMPASS: Ordered Clustered Routing at 100K Scale