Recherche agentique : Mistral triple la précision du RAG

Sur un jeu de 368 documents financiers réels, un RAG classique répond correctement à une question sur quatre. La même architecture, transformée en agent capable de chercher, ouvrir et naviguer dans les documents comme le ferait un analyste humain, répond correctement à plus de huit questions sur dix. Mistral AI a publié le 20 août 2026 les résultats de cette expérience sous le nom de recherche agentique (« Agentic Search »), et les chiffres méritent qu'on s'y arrête : ce n'est pas un gain marginal, c'est un changement de méthode.

Le contexte

Le RAG (Retrieval-Augmented Generation) classique fonctionne en une seule passe : le système découpe les documents en fragments (chunks), en récupère quelques-uns par similarité vectorielle, et demande au modèle de répondre à partir de ce seul lot. C'est rapide et peu coûteux, mais la qualité de la réponse plafonne à la qualité du découpage initial. Si la bonne information est répartie sur trois pages différentes, ou si le fragment pertinent n'a pas été récupéré au premier essai, le modèle répond à côté — et rien dans l'architecture ne lui permet de s'en apercevoir et de recommencer.

La recherche agentique change cette mécanique en donnant au modèle des outils plutôt qu'un lot de fragments figé. Il peut décider lui-même d'affiner sa recherche, de vérifier une source avant de conclure, ou de naviguer vers la bonne section d'un document long — exactement la démarche d'un analyste qui ne s'arrête pas au premier paragraphe venu.

Ce n'est pas la première tentative pour dépasser les limites du RAG à une passe. Les équipes MLOps ont déjà exploré la recherche hybride (combiner similarité vectorielle et recherche par mots-clés BM25), le reranking après récupération, ou l'augmentation du nombre de fragments récupérés. Ces approches améliorent la précision du premier lot de résultats, mais restent fondamentalement des méthodes en une passe : le modèle répond toujours à partir de ce qui a été récupéré une fois, sans possibilité de revenir chercher davantage s'il juge l'information insuffisante. La recherche agentique déplace le curseur : au lieu d'optimiser la qualité d'une seule récupération, elle donne au modèle la capacité de décider lui-même quand une recherche supplémentaire est nécessaire.

Cinq outils, pas un pipeline figé

Mistral structure la recherche agentique autour de cinq primitives, qui ressemblent moins à un pipeline RAG traditionnel qu'à des commandes de système de fichiers : search localise les documents pertinents dans le corpus via un index existant, open ouvre un document précis, navigate déplace le point de lecture vers une page, une section ou une région du document, read récupère le contenu à cet endroit, et grep cherche un motif précis dans les documents déjà ouverts.

Le modèle enchaîne ces opérations en boucle, autant de fois que nécessaire, jusqu'à ce qu'il ait de quoi répondre avec une source vérifiée à l'appui. Point important : le système ne demande aucun fine-tuning ni entraînement spécifique au modèle. Il s'appuie sur les capacités d'appel d'outils déjà présentes dans les modèles actuels, et fonctionne avec un index de recherche existant — pas besoin de reconstruire sa base vectorielle pour l'adopter.

Pourquoi la qualité de récupération cesse d'être plafonnée par le découpage

C'est la phrase clé du billet de Mistral : avec la recherche agentique, « la qualité de récupération évolue avec la capacité du modèle plutôt que d'être plafonnée par votre stratégie de découpage ». En RAG classique, un modèle plus puissant ne compense pas un mauvais chunking — il répond toujours à partir des mêmes fragments limités. En recherche agentique, un modèle plus capable navigue mieux, pose de meilleures requêtes de recherche intermédiaires, et vérifie davantage ses sources : la performance de bout en bout progresse avec le modèle, pas seulement avec l'index.

Les chiffres : deux benchmarks, deux natures de documents difficiles

Mistral a testé l'approche sur deux jeux de données choisis pour leur difficulté réelle, pas pour favoriser la démonstration.

FinanceBench rassemble 368 dépôts réglementaires SEC (environ 53 900 pages), avec 150 questions à réponse précise. Sur Mistral Medium 3.5, le RAG classique en une passe atteint 26,7 % de bonnes réponses. Ajouter la seule capacité de recherche itérative fait grimper le score de 47,3 points ; ajouter la navigation complète (ouverture, déplacement dans le document, vérification) ajoute encore 8,7 points, pour un total avoisinant 82,7 %. Sur GLM-5.2, l'effet est comparable : +52,6 points avec la recherche seule, +6,7 points supplémentaires avec la navigation complète. Mistral résume l'ensemble à une amélioration « 3x » de la justesse, de 26,7 % à 86 % sur l'expérience complète. Autre effet notable, souvent oublié dans ce genre de comparaison : la latence baisse aussi. Le p90 passe de 255 secondes à 154 secondes, la latence moyenne de 108 à 71 secondes, et la consommation de tokens diminue de 23,9 % sur Mistral Medium 3.5.

OfficeQA Pro est plus dur encore : 696 bulletins du Trésor américain (environ 89 000 pages), scannés, denses en tableaux, avec des réponses numériques précises à extraire. C'est le terrain où le RAG classique s'effondre le plus nettement : GLM-5.2 démarre à 6,3 % de bonnes réponses en une passe. La boucle complète de recherche agentique porte ce score à 51,9 %, soit +45,6 points, dont 8,3 points apportés par la seule navigation. Sur Mistral Medium 3.5, le gain atteint +27,1 points en recherche, puis +7,5 points supplémentaires avec la navigation, pour environ 35,6 % au total.

Un détail qui compte pour qui évalue un harnais d'agent, pas seulement un modèle

Mistral signale un écart révélateur : le même modèle GLM-5.2 obtient 41,4 % sur OfficeQA Pro avec le harnais Claude Code, contre 51,9 % avec le harnais de recherche de Mistral — un écart de 10,5 points sur le même modèle. La conclusion à en tirer n'est pas que Mistral triche sur la mesure, mais que l'orchestration autour du modèle (comment les outils sont exposés, dans quel ordre, avec quelles instructions) pèse presque autant que le modèle lui-même sur un cas d'usage documentaire dense. C'est un rappel utile pour toute équipe qui benchmarke des LLM sans tenir compte du harnais qui les entoure.

Ce que ça change pour les équipes IA

Pour une équipe qui exploite un pipeline RAG en production — support documentaire, recherche juridique interne, analyse de rapports financiers, FAQ sur une base de connaissance volumineuse — cette étude a trois implications concrètes.

D'abord, un plafond de qualité qu'on pensait structurel (« le RAG répond mal aux questions transversales à plusieurs documents ») peut en réalité être un plafond d'architecture, pas de modèle. Avant d'investir dans un modèle plus gros ou un ré-entraînement, la question à se poser est : le pipeline actuel donne-t-il au modèle un moyen de vérifier et d'affiner sa réponse, ou seulement un lot de fragments figé sur lequel il doit faire au mieux ? Les gains mesurés ici (+45 à +55 points sur la seule capacité de recherche itérative, avant même d'ajouter la navigation) suggèrent que l'architecture de récupération mérite d'être auditée en premier.

Ensuite, le gain de latence est contre-intuitif et vaut d'être vérifié sur son propre cas d'usage plutôt que supposé impossible. On imagine spontanément qu'une boucle de recherche itérative coûte plus cher en temps qu'un aller-retour unique — c'est vrai à l'échelle d'une seule requête de recherche, mais faux à l'échelle de la tâche complète : un agent qui trouve la bonne information en trois recherches ciblées peut être plus rapide qu'un pipeline RAG qui produit une réponse fausse, oblige l'utilisateur à reformuler, et relance tout le processus.

Enfin, l'écart mesuré entre deux harnais sur le même modèle rappelle qu'un benchmark de modèle seul ne dit rien de la performance réelle d'un système documentaire. Une équipe qui évalue des fournisseurs de modèles pour un cas d'usage RAG doit tester l'orchestration complète — outils, prompts système, logique de boucle — pas seulement interroger le modèle nu sur un jeu de questions génériques.

Un dernier point mérite d'être anticipé avant d'adopter cette approche en production : une boucle de recherche itérative multiplie les appels au modèle, donc les coûts par requête peuvent augmenter même quand la consommation totale de tokens baisse (ce qui a été le cas ici, avec une réduction de 23,9 % sur FinanceBench). Le bon indicateur à suivre n'est donc pas le coût par appel isolé, mais le coût par tâche correctement résolue — une réponse fausse obtenue en un seul appel coûte souvent plus cher au bout du compte, une fois comptée la reformulation de l'utilisateur et le second essai.

En bref

• Mistral publie la « recherche agentique » : cinq outils (search, open, navigate, read, grep) permettant à un modèle de naviguer itérativement dans des documents plutôt que de répondre à partir d'un lot de fragments figé.
• Sur FinanceBench (368 dépôts SEC), la précision passe de 26,7 % à environ 86 %, avec une baisse de latence (p90 : 255s → 154s) et une réduction de tokens de 23,9 %.
• Sur OfficeQA Pro (696 documents scannés denses en tableaux), la précision de GLM-5.2 passe de 6,3 % à 51,9 %.
• Aucun fine-tuning requis : la méthode s'appuie sur les capacités d'appel d'outils existantes et un index de recherche déjà en place.
• Un même modèle peut varier de plus de 10 points de précision selon le harnais d'orchestration utilisé — l'architecture compte autant que le modèle.
• Disponible via le Mistral Search Toolkit (auto-hébergeable), intégré aux Libraries de Studio et Vibe, avec une Search Starter App pour démarrer.

Vous industrialisez vos agents IA ? SeedVision propose des audits IA en 3-5 jours et des forfaits de mise en production de 15 à 30 jours. Voir les packages ou réserver un appel de 30 min.

Photo de couverture : Photo by Agence Olloweb on Unsplash.