La recherche IA la plus coûteuse a perdu sur des questions simples
Une étude évaluée par les pairs à KDD 2026 a soumis la recherche classique et la recherche par graphe aux mêmes tests. Le gagnant dépendait de la question, et le juge IA qui notait le duel a parfois inversé son verdict quand les réponses changeaient de place.
La recherche IA la plus coûteuse a perdu sur des questions de fait simples. Et le juge IA qui notait le duel a parfois inversé son verdict quand les réponses changeaient de place.
Pourquoi cela compte
La recherche IA classique fonctionne comme l’index d’un livre : trouver le passage qui contient vos mots. La recherche par graphe fonctionne comme une carte reliant personnes, lieux, événements et faits.
Une étude évaluée par les pairs à KDD 2026, la principale conférence de l’ACM en fouille de données, a soumis les deux approches aux mêmes tests. La carte l’emporte sur les questions qui enchaînent plusieurs faits. L’index l’emporte sur les questions en une étape et sur les questions de détail fin. Dans un test, les versions à carte ont demandé 41 à 57 fois plus de temps de construction.
Les résumés d’ensemble de la carte aident sur les questions larges du type « quels sont les thèmes ? ». Ils perdent aussi les détails fins dont les questions étroites ont besoin.
Vient ensuite le problème de notation. Un juge IA a noté les résumés. Inversez leur ordre, et certains verdicts basculent.
J’avais déjà inscrit cette règle dans mon système agentique : la note d’un juge IA ne compte comme preuve que si l’ordre des réponses est mélangé. Cette étude montre ce qui arrive sans cette précaution.
Je trie les questions avant de choisir l’outil, et je mélange l’ordre avant de croire une note.
Comment cela fonctionne
Han et ses coauteurs ont comparé RAG et GraphRAG sous un même protocole. RAG mène sur les questions-réponses en une étape et orientées détail (NQ, et les sous-ensembles de détail de NovelQA). Les méthodes GraphRAG mènent sur les questions à sauts multiples (HotPotQA, MultiHop-RAG).
La recherche globale par communautés, la conception GraphRAG de Microsoft, peut perdre les preuves fines. Cela s’est vu sur les questions de détail de NovelQA : le résumé qui rend un thème visible est le même que celui qui écarte le chiffre demandé.
Le coût est déséquilibré. Sur MultiHop-RAG, les deux variantes à graphe ont demandé 5 560 s et 7 702 s de construction, contre 135 s pour RAG. Pourtant la recherche par communautés s’est révélée plus rapide que RAG au moment de la requête. La dépense est dans la construction, pas dans la requête : ce n’est ni le même budget ni la même décision.
L’aiguillage est la solution, avec un compromis. Un classifieur LLM étiquette chaque requête comme factuelle ou de raisonnement, puis l’envoie vers RAG ou GraphRAG : 1,1 % au-dessus de la meilleure référence, Llama 3.1-70B. Lancer les deux et fusionner rapporte 6,4 % de plus, mais chaque requête paie alors les deux.
Mon choix pour une première version est l’aiguilleur. Il coûte moins cher, et chaque voie est notée séparément, si bien qu’une régression n’a qu’une seule origine possible. Je ne paierais les deux que là où l’écart mesuré le justifie, et je mélangerais l’ordre des réponses avant de les montrer à un juge LLM.
Ce que l’étude ne tranche pas, c’est votre corpus. Ce sont des jeux de test publics, dont les entités sont celles que le jeu contenait. Sur un corpus dont les entités sont les vôtres, fournisseurs, sinistres, pièces, la carte a bien plus à relier que NQ ne lui en donne, et le coût de construction se paie une fois contre un schéma qui bouge lentement.