Résumé technique : DISCOBENCH pour la recherche profonde sensible à la clarification

1. Énoncé du problème

Les agents de recherche alimentés par des modèles de langage de grande taille (LLM) sont de plus en plus déployés pour des tâches de recherche d'informations complexes et multi-étapes. Cependant, les benchmarks d'évaluation existants opèrent largement sous l'hypothèse que les requêtes des utilisateurs sont complètes, explicites et factuellement correctes. Cette hypothèse diverge considérablement des scénarios du monde réel où les utilisateurs fournissent fréquemment des requêtes vagues, sous-spécifiées ou factuellement incorrectes en raison de limitations de la mémoire ou de la charge cognitive.

Dans les scénarios de « recherche profonde » impliquant des chaînes de raisonnement complexes, l'ambiguïté initiale peut se propager à travers les étapes suivantes, entraînant les agents sur des trajectoires erronées et gaspillant des ressources de calcul. Bien que la communauté académique reconnaisse l'importance de l'ambiguïté des requêtes, les benchmarks actuels ne parviennent pas à évaluer de manière adéquate la capacité d'un agent à identifier proactivement l'ambiguïté, à poser des questions de clarification efficaces et à rétablir des chemins de raisonnement corrects par l'interaction. Les jeux de données existants se concentrent soit sur l'ambiguïté statique (ex. AmbigQA), soit manquent de la profondeur de la recherche web en domaine ouvert et des effets d'amplification de l'ambiguïté au sein de longues chaînes de raisonnement (ex. InteractComp).

2. Méthodologie

2.1 Construction de DISCOBENCH

Les auteurs introduisent DISCOBENCH (Deep Interactive Search with ClarificatiOn Benchmark), un jeu de données conçu pour modéliser l'ambiguïté comme un phénomène dynamique survenant lors de trajectoires de recherche multi-étapes. Le pipeline de construction comprend deux phases :

• Phase 1 : Préparation des données de base : L'équipe a collecté des sujets sources à partir de 11 domaines divers (ex. Cinéma/TV, Sport, Académique, Finance) en utilisant des ressources encyclopédiques et des résultats de moteurs de recherche. Ils ont construit des chaînes de raisonnement multi-sauts de haute qualité (211 échantillons) où les réponses sont objectivement vérifiables et nécessitent une récupération externe.
• Phase 2 : Construction des données ambiguës : Les chaînes de raisonnement déterministes ont été transformées en tâches interactives en injectant de l'ambiguïté. Les auteurs ont identifié des « points d'ambiguïté » où l'assouplissement des contraintes mène à plusieurs candidats plausibles. Ils ont remplacé les contraintes fortes par des attributs partagés entre les entités candidates, créant ainsi quatre types d'ambiguïté spécifiques :
  1. Entité : Plusieurs entités satisfont la même description.
  2. Version : Différents états temporels ou de version.
  3. Critères : Différents standards d'évaluation ou critères de classement.
  4. Inexactitude factuelle : Descriptions incohérentes avec les faits objectifs.

Le jeu de données contient 211 échantillons avec 463 instances d'ambiguïté. Pour chaque point d'ambiguïté, des faits discriminants (indices) ont été générés pour permettre à un simulateur d'utilisateur de fournir l'information nécessaire pour résoudre l'ambiguïté.

2.2 Cadre d'évaluation

L'évaluation simule une interaction multi-tours entre un agent et un simulateur d'utilisateur (implémenté via un LLM). L'agent navigue dans une séquence de Points de contrôle (Checkpoints - CPs) structurés. À chaque point de contrôle, l'agent doit choisir entre trois actions :

1. SEARCH (RECHERCHER) : Récupérer des informations.
2. ASK (DEMANDER) : Demander une clarification à l'utilisateur.
3. ANSWER (RÉPONDRE) : Soumettre une réponse finale.

Le cadre évalue les agents selon quatre perspectives :

• Utilité de la tâche : Précision de bout en bout et taux de réussite par point de contrôle.
• Détection d'ambiguïté : Précision de la détection et score F1 (identifier quand un point de contrôle est ambigu).
• Stratégie d'interaction : Efficacité de la clarification (précision de la question posée et si elle permet de faire progresser le point de contrôle).
• Efficacité des coûts : Consommation de tokens et nombre de tours d'utilisation d'outils.

Deux paramètres de prompting ont été utilisés : Neutre (aucune instruction explicite pour rechercher l'ambiguïté) et Guidé (rappel explicite à l'agent d'être conscient de l'ambiguïté potentielle).

3. Contributions clés

1. Benchmark DISCOBENCH : Un nouveau benchmark modélisant l'ambiguïté comme un problème dynamique et de propagation dans la recherche multi-étapes plutôt que comme une propriété statique d'une requête unique. Il couvre 11 domaines et quatre types d'ambiguïté.
2. Cadre d'évaluation sensible à l'ambiguïté : Un protocole unifié incluant un simulateur d'utilisateur qui révèle progressivement des indices discriminants, permettant d'évaluer simultanément la détection, la qualité de la clarification et le coût de l'interaction.
3. Aperçus empiriques : Des expériences approfondies révélant que la détection d'ambiguïté et la clarification efficace sont des capacités distinctes. Les auteurs identifient un mode de défaillance critique où les agents effectuent des recherches répétées au lieu de demander une clarification, performant souvent moins bien qu'une simple supposition directe.

4. Résultats expérimentaux

Les auteurs ont évalué 11 LLM de pointe (incluant GPT-5.4, Gemini-3.1-Pro, Claude-Opus-4.7 et divers modèles chinois) sur DISCOBENCH.

• Performance limitée : Sous le paramètre Neutre, le modèle le plus performant (Doubao-Seed-2.0-Pro) n'a atteint que 43,1 % de précision de bout en bout. La plupart des modèles restent en dessous de 40 %.
• Écart entre détection et clarification : Bien que le prompting « Guidé » ait amélioré la détection d'ambiguïté (le F1 passant d'environ 45 % à environ 65 %), il n'a pas amélioré proportionnellement la précision de bout en bout. Cela indique que reconnaître l'ambiguïté est distinct de la formulation de questions de clarification efficaces.
• Le mode de défaillance « Search-Heavy Guess » (Recherche excessive et supposition) : Une découverte significative est que les agents échouent souvent en effectuant une récupération excessive (Search-Heavy-Guess) plutôt qu'en demandant de l'aide. Ce comportement a produit des taux de réussite (51,9 %) inférieurs à la supposition directe (56,5 %). Les auteurs notent que la récupération répétée indique souvent que le modèle est conscient de plusieurs candidats mais échoue à transformer cette incertitude en une demande de clarification.
• Utilisation d'outils vs Performance : L'augmentation de l'utilisation des outils (plus d'appels de recherche) n'était pas corrélée à une meilleure performance. Les modèles qui cherchaient plus fréquemment n'atteignaient pas nécessairement une précision plus élevée, suggérant que l'allocation stratégique des actions de récupération est plus critique que le volume.
• Impact de l'ambiguïté : Supprimer l'ambiguïté des tâches a considérablement amélioré la précision pour tous les modèles (de 26,8 % à 40,2 %), confirmant que l'ambiguïté est une source primaire de difficulté dans la recherche profonde.

5. Signification et affirmations

L'article affirme que les agents de recherche actuels basés sur les LLM possèdent de fortes capacités de récupération et de raisonnement, mais manquent de conscience de l'ambiguïté et de stratégies d'interaction proactives. Les auteurs soutiennent que la recherche interactive profonde nécessite des mécanismes qui relient explicitement l'incertitude de la récupération à l'interaction avec l'utilisateur.

La portée de DISCOBENCH réside dans sa capacité à exposer une lacune dans les capacités actuelles des agents : l'incapacité à distinguer « chercher plus d'informations » et « demander une clarification ». Les auteurs concluent que les futurs agents de recherche doivent être développés non seulement avec un raisonnement plus fort, mais aussi avec de meilleures capacités à identifier les états sous-spécifiés et à solliciter stratégiquement l'apport de l'utilisateur pour rétablir les trajectoires de raisonnement correctes.

L'article maintient un ton modeste concernant ses limites, reconnaissant que le simulateur d'utilisateur est basé sur un LLM plutôt que sur un humain, et que le benchmark se concentre actuellement sur la réponse à des questions objectives, laissant l'ambiguïté des préférences subjectives aux travaux futurs.