Les agents de recherche approfondie ont besoin de graphes de preuves

Le 15 mai 2026, Zhen Zhang et ses coauteurs ont publié Argus, un système d’agent de recherche approfondie qui traite la recherche comme un assemblage de preuves plutôt que comme une recherche parallèle menée en force brute.¹

Cette distinction compte.

Les agents de recherche approfondie peuvent lancer de nombreuses recherches, ouvrir de nombreuses pages et rédiger de longues réponses. Une longue réponse ne prouve pas que l’agent a trouvé les preuves manquantes. La recherche parallèle peut dupliquer le même groupe de sources, ajouter davantage d’extraits au contexte et laisser malgré tout la partie difficile sans appui.

Les agents de recherche approfondie ont besoin de graphes de preuves. L’agent doit savoir quelles affirmations ont besoin d’un appui, quels éléments de preuve existent déjà, lesquels manquent encore et quelles phrases finales dépendent de quelles sources.

TL;DR

Les agents de recherche approfondie ne devraient pas mesurer leur progression au nombre de recherches lancées ni à la quantité de contexte remplie. Ils devraient la mesurer à la couverture des preuves.

Argus donne au domaine une forme utile. Son Searcher recueille des traces de preuves pour des sous-requêtes, tandis que son Navigator maintient un graphe de preuves partagé, vérifie quels éléments manquent encore, répartit du travail de recherche supplémentaire et produit une réponse finale traçable jusqu’aux sources.¹ Cela éloigne la recherche approfondie de la logique « lancer plus d’agents » pour la rapprocher de « assembler la preuve manquante ».

Le même motif apparaît dans les recherches récentes sur les agents. paper.json donne aux articles des affirmations adressables et des limites de portée.² ACDL fournit un langage formel pour décrire le contexte des agents.³ Les travaux sur l’exploration soutiennent que les agents ont besoin de points de contrôle vérifiables avant d’agir.⁴ ARIS présente l’échec central de la recherche au long cours comme un succès plausible mais insuffisamment étayé.⁵ AgentForesight défend l’audit en ligne avant qu’une erreur décisive ne se propage dans une exécution multi-agent.⁶

La règle pratique est simple : toute réponse de recherche approfondie devrait s’accompagner d’un graphe de preuves ou d’un dossier de revue capable de montrer ce que l’agent a prouvé, ce qu’il a inféré et ce qui reste irrésolu.

Points clés

Pour les concepteurs d’agents : - Suivez les preuves sous forme de graphe reliant affirmations, sources, lacunes et dépendances. - Orientez le travail de recherche vers les preuves manquantes au lieu de répéter des requêtes larges.

Pour les équipes produit : - Montrez la couverture des sources, les affirmations non résolues et le gaspillage dû aux recherches dupliquées. - Permettez aux relecteurs d’inspecter pourquoi la réponse finale cite chaque source.

Pour les chercheurs : - Séparez la collecte de preuves de la synthèse de la réponse. - Évaluez la couverture et la traçabilité, pas seulement le score de la réponse finale.

Pour les opérateurs : - Considérez un long rapport assuré comme inachevé tant que le graphe de preuves n’a pas comblé ses lacunes importantes. - Demandez quelles affirmations manquent encore d’appui primaire avant d’accepter la réponse.

Pourquoi la recherche parallèle s’enlise-t-elle ?

La recherche parallèle donne une impression de progrès.

Confiez la même question de recherche à 10 agents, et le système produit du mouvement. Les agents cherchent, résument, comparent et renvoient des résultats partiels. La synthèse finale peut sembler approfondie parce que la transcription contient de nombreuses sources.

L’échec se cache dans la redondance.

Argus nomme directement ce problème. L’article soutient que les réponses de recherche approfondie combinent des éléments de preuve complémentaires, tandis que les déroulements parallèles dupliquent souvent ces éléments au lieu de les compléter.¹ Davantage de déroulements peuvent pousser le contexte d’agrégation vers sa limite sans combler les parties manquantes.¹

La leçon n’est pas « ne jamais paralléliser ». La leçon est : « paralléliser à partir d’une carte ».

Qu’apporte Argus ?

Argus divise la recherche approfondie en deux rôles.

Le Searcher collecte des traces de preuves pour une sous-requête au moyen d’une interaction de style ReAct.¹ Le Navigator maintient un graphe de preuves partagé, vérifie quels éléments manquent encore, envoie des Searchers recueillir ces éléments et raisonne sur le graphe complété pour produire une réponse finale traçable jusqu’aux sources.¹

Cette répartition des rôles change l’objet de travail.

Le Navigator donne à l’agent une mémoire de ce qui manque encore à la réponse. Sans cette couche, les travailleurs parallèles peuvent continuer à rapporter des preuves pour la même affirmation facile.

Argus rapporte aussi des gains de performance. Avec une base MoE 35B-A3B, l’article indique qu’Argus gagne 5,5 points avec un seul Searcher et 12,7 points avec 8 Searchers parallèles, en moyenne sur 8 benchmarks.¹ Le détail important n’est pas seulement le score. C’est l’architecture qui rend les Searchers supplémentaires utiles.

Les Searchers deviennent utiles parce que le Navigator les dirige vers les preuves manquantes.

Que doit suivre un graphe de preuves ?

Un graphe de preuves devrait représenter la réponse avant que la prose ne la fige.

Au minimum, il devrait suivre :

Les arêtes comptent plus que les nœuds.

Le graphe n’a pas besoin du cérémonial universitaire d’une base de données orientée graphe. Un objet JSON, une table de traces ou un dossier de revue peuvent suffire. La propriété essentielle est l’inspectabilité : un autre relecteur peut voir pourquoi la réponse dit ce qu’elle dit.

Pourquoi les graphes de preuves aident-ils les relecteurs ?

Les relecteurs ont besoin d’un objet plus petit que toute la transcription.

Une transcription de recherche approfondie peut inclure des dizaines d’appels d’outils, de sources, de résumés, de nouvelles tentatives et de notes. Le relecteur veut généralement des réponses à des questions plus précises :

• Quelles affirmations finales ont un appui direct ?
• Quelles affirmations dépendent d’une interprétation secondaire ?
• Quelle source apparaît plusieurs fois sous des résumés différents ?
• Quelle question manquante l’agent a-t-il cessé de poursuivre ?
• Quelle citation soutient seulement le contexte, et non l’affirmation clé ?
• Quelle limitation devrait restreindre la réponse finale ?

Un graphe de preuves offre cette surface.

Cette forme s’accorde naturellement avec les dossiers de revue. Une réponse finale ne devrait pas seulement fournir de la prose. Elle devrait fournir l’état des preuves qui a produit cette prose.

Où se place paper.json ?

Les graphes de preuves ont besoin de meilleurs objets source.

Si chaque article scientifique entre dans le graphe comme un PDF indifférencié, le graphe conserve des nœuds grossiers. Un nœud d’affirmation peut pointer vers un article, mais il ne peut pas facilement pointer vers une sous-affirmation, une limite de portée, une définition ou une commande de reproduction.

paper.json améliore la couche d’entrée. La proposition donne aux articles des identifiants d’affirmations stables, des listes explicites de ce qu’ils ne prétendent pas, des commandes shell par figure et des identifiants de définitions stables.² Un agent de recherche peut utiliser ces identifiants comme nœuds de graphe.

Ce lien compte pour la qualité des citations. La réponse peut citer C2 dans un article plutôt que de citer vaguement l’article entier. Le graphe peut aussi enregistrer que C2 porte une limitation issue de does_not_claim[].

Les graphes de preuves et les articles lisibles par les agents résolvent des problèmes voisins. Le fichier de l’article rend les preuves plus faciles à adresser. Le graphe rend les preuves plus faciles à assembler.

Où se place la description du contexte ?

Les agents de recherche approfondie doivent aussi savoir ce qui est entré dans le contexte, et à quel moment.

ACDL, l’Agentic Context Description Language, cible ce problème au niveau du prompt. L’article soutient que les systèmes d’agents manquent d’un moyen standard de décrire la composition des prompts et la dynamique du contexte, et s’appuient plutôt sur de la prose, des schémas ou l’inspection du code.³ ACDL fournit des constructions pour les séquences de messages par rôle, le contenu dynamique, les références indexées dans le temps et les structures conditionnelles ou itératives.³

Un graphe de preuves devrait se connecter à l’état du contexte.

La forme du contexte influence la forme des preuves. Une source ne peut pas soutenir la réponse si le synthétiseur n’a jamais vu le passage pertinent. Une limitation ne peut pas contraindre la réponse si personne ne l’a mise dans le contexte.

Les systèmes de recherche approfondie ont besoin des deux objets : une description du contexte et un graphe de preuves.

Pourquoi l’exploration compte-t-elle ?

Les agents de recherche peuvent exploiter trop tôt.

« Look Before You Leap » identifie l’exploitation prématurée comme un mode d’échec pour les agents LLM dans des environnements inconnus.⁴ L’article introduit l’Exploration Checkpoint Coverage comme métrique vérifiable pour déterminer si les agents découvrent les états, objets et possibilités clés avant l’exécution de la tâche.⁴

La recherche approfondie suit la même logique. Les agents peuvent trouver une piste plausible et commencer à répondre avant de comprendre l’espace des sources.

Un graphe de preuves devrait préserver une phase d’exploration :

1. Identifier les classes d’affirmations dont la réponse aura besoin.
2. Cartographier les types de sources probables.
3. Chercher des sources primaires avant les commentaires.
4. Enregistrer les classes de sources manquantes comme nœuds de lacune.
5. Envoyer des recherches ciblées pour combler les lacunes.
6. Ne synthétiser qu’après la fermeture des lacunes importantes ou l’ajout de réserves explicites.

Cette phase d’exploration empêche l’agent de traiter la première bonne source comme le centre de la réponse.

Le graphe donne à l’agent une raison de continuer à chercher : une lacune ouverte reste visible.

Que se passe-t-il sans graphe ?

Les agents de recherche au long cours peuvent échouer sans paraître défaillants.

ARIS présente l’échec central comme un succès plausible non étayé : un agent au long cours produit des affirmations dont l’appui probatoire reste incomplet, mal rapporté ou hérité de son propre cadrage.⁵ Cet échec peut passer une revue superficielle parce que le rapport final semble soigné.

AgentForesight attaque un problème voisin dans les systèmes multi-agents. Il soutient qu’une seule erreur décisive peut se propager dans une trajectoire longue, tandis que l’attribution a posteriori arrive trop tard pour intervenir.⁶ Son auditeur en ligne ne voit que le préfixe courant et doit décider s’il faut continuer ou déclencher une alerte avant la fin de la trajectoire complète.⁶

Les graphes de preuves aident dans les deux cas.

Le graphe ne garantit pas la vérité. Il donne à la vérité une structure que l’équipe peut auditer.

Que devraient montrer les produits de recherche approfondie ?

Les produits de recherche approfondie devraient exposer l’état des preuves.

Un utilisateur ne devrait pas seulement voir une réponse finale avec des notes de bas de page. L’interface devrait montrer :

Cette interface donne aux utilisateurs un moyen de piloter l’exécution. Ils peuvent demander à l’agent de combler une lacune précise au lieu de dire « approfondissez la recherche ». Ils peuvent rejeter une affirmation faible sans jeter toute la réponse. Ils peuvent voir quand l’agent dispose de suffisamment de preuves pour s’arrêter.

Une bonne UX de recherche approfondie devrait rendre les preuves manquantes visibles avant que la prose finale ne les dissimule.

Que devraient construire les équipes en premier ?

Commencez par une simple table de preuves avant de construire un moteur de graphe.

Ajoutez ensuite la répartition du travail :

1. Avant la synthèse, listez toutes les affirmations manquantes à forte valeur.
2. Envoyez chaque affirmation manquante à un Searcher avec une requête étroite.
3. Exigez du Searcher qu’il renvoie une preuve ou un échec explicite.
4. Mettez à jour le graphe.
5. Synthétisez uniquement à partir d’affirmations étayées et assorties de réserves.

Cette première version peut rester simple. Une table Markdown peut valoir mieux qu’une transcription invisible si elle force l’agent à montrer la couverture des preuves.

Le niveau d’exigence digne de confiance

Les agents de recherche approfondie devraient gagner la confiance en montrant la structure de leurs preuves.

Plus de recherches peuvent aider. Plus d’agents peuvent aider. Un contexte plus long peut aider. Aucune de ces entrées ne prouve que la réponse finale a couvert les éléments manquants.

Une exécution de recherche approfondie digne de confiance devrait répondre à 4 questions :

• Quelles affirmations l’agent a-t-il tenté de prouver ?
• Quelles sources soutiennent chaque affirmation ?
• Quelles lacunes ou conflits restent ouverts ?
• Quelles phrases finales dépendent de quelles preuves ?

Quand ces réponses restent visibles, les utilisateurs peuvent revoir le travail. Quand elles disparaissent dans une prose soignée, les utilisateurs doivent faire confiance à un résumé sans voir la forme de la preuve.

La recherche approfondie a besoin de graphes de preuves parce que la recherche n’est pas un problème de nombre de recherches. C’est un problème d’éléments manquants.

Résumé rapide

Les agents de recherche approfondie ont besoin de graphes de preuves parce que la recherche parallèle peut dupliquer des groupes de sources faciles tandis que des affirmations importantes restent sans appui. Argus fournit un modèle solide : un Searcher recueille des traces de preuves, tandis qu’un Navigator suit un graphe de preuves partagé, oriente le travail vers les éléments manquants et produit une réponse traçable jusqu’aux sources.¹

La même leçon rejoint des travaux voisins. paper.json améliore les objets source au niveau des articles.² ACDL décrit comment le contexte entre dans les systèmes d’agents.³ Les points de contrôle d’exploration rendent la collecte d’informations vérifiable.⁴ ARIS et AgentForesight montrent pourquoi les sorties longues et soignées ont besoin de preuves et d’une revue en ligne avant que les erreurs ne se propagent.⁵⁶

La règle opérationnelle est directe : ne demandez pas seulement une réponse à un agent de recherche approfondie. Demandez le graphe de preuves qui a rendu cette réponse possible.

FAQ

Qu’est-ce qu’un graphe de preuves pour agents de recherche approfondie ?

Un graphe de preuves relie les affirmations, sources, extraits, lacunes, conflits, limites de portée et phrases de réponse finale. Il permet aux relecteurs de voir quelles preuves soutiennent chaque partie d’une réponse de recherche approfondie.

Pourquoi la recherche parallèle ne suffit-elle pas ?

La recherche parallèle peut dupliquer les sources et remplir le contexte sans trouver les preuves manquantes. Les agents de recherche approfondie ont besoin d’une carte partagée de ce qui manque encore à la réponse.

Quelle a été la contribution d’Argus ?

Argus a divisé la recherche approfondie entre les rôles Searcher et Navigator. Le Searcher recueille des traces de preuves, tandis que le Navigator maintient un graphe de preuves partagé, lance des recherches pour les éléments manquants et produit une réponse finale traçable jusqu’aux sources.¹

Quel est le lien entre paper.json et les graphes de preuves ?

paper.json donne aux articles scientifiques des identifiants d’affirmations stables, des limites de portée, des définitions et des commandes de reproduction. Les graphes de preuves peuvent utiliser ces identifiants comme nœuds précis au lieu de citer vaguement tout un article.²

Que devrait montrer un produit aux utilisateurs ?

Un produit devrait montrer la couverture des affirmations, les liens vers les preuves, les lacunes non résolues, les groupes de recherches dupliquées, les conflits entre sources, les limites de portée et les décisions de revue avant de demander aux utilisateurs de faire confiance à la prose finale.

Références