Choisir une reformulation plutôt que chercher la reformulation parfaite

La meilleure reformulation dépend de la requête

Une stratégie de reformulation peut améliorer une requête et échouer sur la suivante. Comparer seulement la moyenne d’un reformulateur masque alors une décision plus opérationnelle : parmi plusieurs variantes déjà disponibles, laquelle faut-il envoyer au retriever pour cette requête et ce moteur précis ?

Le preprint Route Me If You Can: A Benchmark for Query Reformulation Selection introduit QueryRoute. Le benchmark gèle les requêtes, les variantes générées, les listes classées, les scores et les labels oracle. Un sélecteur peut ainsi être évalué sans régénérer les variantes ni reconstruire toute la chaîne de jugement.

Une matrice action-résultat

Pour chaque requête, le benchmark conserve la requête originale et dix systèmes candidats. Chaque variante produit une liste avec BM25, SPLADE et BGE. La collection couvre TREC DL, six jeux BEIR et sept sous-ensembles BRIGHT. Le label oracle identifie la ou les variantes qui maximisent la métrique sur la requête, mais reste une borne de comparaison et non une information disponible en production.

Le protocole compare des classifieurs, des routeurs par similarité, de la factorisation, des prédicteurs de performance de requête et des juges LLM. Il mesure aussi le taux de sélection proche de l’oracle, les requêtes aidées et les requêtes dégradées.

Ce que rapportent les auteurs

QueryRoute contient 3757 requêtes, 11 systèmes candidats, cinq backbones de reformulation et trois retrievers, soit 619 905 résultats de retrieval. Sous BM25, le score nDCG@10 moyen TREC DL passe de 0,424 pour la requête originale à 0,559 pour le meilleur reformulateur fixe et 0,666 pour l’oracle par requête. Le meilleur sélecteur non oracle, un juge LLM, atteint 0,588 dans ce régime.

Les classements changent cependant avec le retriever. Sous BGE ou SPLADE, les routeurs appris ne dépassent pas toujours les baselines fixes. Les auteurs montrent aussi que deux méthodes de moyenne comparable peuvent avoir des profils « help/hurt » très différents : une moyenne unique ne décrit pas le risque de dégrader certaines requêtes.

Lecture éditoriale

Le benchmark propose une façon saine de tester un routeur : séparer la qualité des variantes de la qualité du choix. Dans un système réel, il faut conserver la variante choisie, le retriever ciblé, le signal de décision et le résultat obtenu. Le taux de requêtes aidées peut être plus actionnable qu’une seule moyenne, surtout si une dégradation coûte plus cher qu’un gain marginal.

L’oracle est utile pour mesurer le potentiel, mais il ne doit pas devenir une promesse. Il est calculé avec les jugements de test ; un système de production doit estimer la valeur sans connaître la réponse. La sélection doit donc être évaluée avec une politique de repli et un budget explicite.

Limites à garder

Le benchmark est borné à son pool de variantes, ses collections, ses retrievers et ses métriques. Les résultats ne disent pas quelle stratégie sera meilleure dans un corpus privé ou multilingue. Un juge LLM ajoute aussi coût, variance et dépendance de modèle.

Source et périmètre

Source principale : arXiv:2609.14885v1 · PDF. Les chiffres de benchmark sont ceux des auteurs ; les conseils de routage sont une interprétation éditoriale.