Thinking
Summary
Mistral Agentic Search fournit des résultats de recherche plus précis tout en réduisant le nombre de tours, l’utilisation de tokens et la latence sur les benchmarks FinanceBench et OfficeQA Pro. Agentic Search est la couche de récupération qui permet aux systèmes d’IA de parcourir, lire et vérifier l’information au sein des documents, même les plus complexes. Disponible via Mistral Search Toolkit et Libraries.

Mistral Agentic Search aide les entreprises à obtenir de meilleurs résultats avec leurs systèmes d'IA en permettant aux modèles de rechercher et de parcourir les données et documents les plus complexes de leur organisation. Agentic Search introduit une boucle de récupération multi-étapes pour trouver, inspecter et vérifier les informations dans plusieurs sources de données, quel que soit leur emplacement. Agentic Search est disponible via Mistral Search Toolkit, intégré aux Bibliothèques dans Studio et Vibe, et vous offre :
Une prise en charge de données sensibles propres à un domaine. Les outils portables et ouverts de Mistral vous aident à utiliser vos données sans franchir vos cloisonnements, dans le cloud ou sur site.
Des résultats de recherche améliorés. Vos modèles peuvent rechercher et parcourir vos données au-delà des fragments récupérés, dans des documents longs et denses ou entre plusieurs sources.
Un accès aux index existants. Agentic Search s'appuie sur votre index de recherche existant avec cinq outils :
search,open,navigate,readetgrep.Une précision accrue. Agentic Search atteint jusqu'à 3 fois plus de réponses correctes sur les documents financiers réglementaires, de 26,7 % à 86 %, d'après FinanceBench. Sur les questions multi-documents centrées sur des tableaux dans le benchmark OfficeQA Pro, nous mesurons un gain de +45,6 points (de 6,3 % à 51,9 %).
Une latence et consommation de tokens réduites. La navigation ciblée permet à Agentic Search de réduire la latence p90 jusqu'à 39,6 %. Moins de recherches répétées réduisent la consommation de tokens jusqu'à un tiers.
Les données créent un avantage concurrentiel
Un avantage concurrentiel se construit au fil d'années d'opérations sur le terrain : vos données, vos processus et votre expertise métier. Les connaissances propriétaires sont à la fois essentielles à votre réussite et hautement confidentielles. Elles restent donc derrière des cloisonnements, des déploiements segmentés et des plateformes auto-hébergées. Elles s'accumulent dans des documents financiers réglementaires, des contrats juridiques, des ressources internes et des archives publiques : des documents longs et denses que les méthodes de recherche traditionnelles ne parcourent pas efficacement.
Les agents qui apprennent et s'améliorent en continu peuvent vous aider à renforcer votre avantage concurrentiel, mais ces agents sont souvent séparés des données confidentielles et des connaissances propriétaires pour des raisons de sécurité. Obtenir un impact réel avec l'IA implique d'associer un raisonnement de pointe à des outils de récupération capables d'accéder en sécurité à vos ressources les plus sensibles.
Le RAG traditionnel montre ses limites
Le RAG traditionnel en un seul passage récupère un ensemble fixe de fragments de texte et demande à un modèle de répondre en une seule passe. Cette approche fonctionne lorsque la réponse apparaît dans l'un des premiers résultats, mais elle échoue lorsque le modèle doit parcourir un long rapport, suivre des références, comparer plusieurs documents ou vérifier les preuves sous-jacentes.
La limite est plus nette avec des données et des documents denses et complexes. Les informations nécessaires pour répondre à une question peuvent être réparties entre plusieurs documents ou enfouies dans un tableau, une note numérotée ou une clause précise. La recherche fondée sur un RAG en un seul passage n'utilise pas toute la puissance de l'IA de pointe et ne fournit pas de réponses fiables pour trois raisons :
Récupération sans raisonnement : le modèle doit répondre à partir des fragments sélectionnés lors de la récupération initiale, même s'ils sont incomplets ou non pertinents. Il ne peut pas décider qu'il lui faut un autre document, une autre section ou plus de contexte avant de répondre, ce qui limite l'impact du raisonnement du modèle.
Limite au niveau du fragment : les données critiques se trouvent souvent dans des documents multimodaux complexes. À la question « Quel était le taux d'imposition effectif de l'entreprise au T3 ? », un index peut trouver le bon document, mais il ne peut pas l'ouvrir, accéder au tableau, lire le contexte adjacent ni vérifier la réponse.
Aucune itération : de nombreuses questions nécessitent plus d'une passe de récupération pour obtenir la bonne réponse. Le modèle peut devoir affiner sa recherche, inspecter un document prometteur, suivre une référence, comparer plusieurs sources, garder la trace de ce qu'il a déjà consulté et essayer une autre voie lorsque les premiers résultats sont insuffisants. Le RAG en un seul passage ne permet pas d'effectuer ces étapes suivantes.
Using specifically only the reported values for all individual calendar months in 1953, what is the total sum of these values of expenditures for U.S. national defense and associated activities (in millions of nominal dollars)?
Trajectory 1 tool_call (search only)
search("national defense expenditures monthly 1953") → 10 hits: a scatter of monthly bulletins (Table 3), each framed fiscal-year, covering only part of 1953.
I found January–June 1953 data. But I need July–December 1953 monthly values to compute an answer.
Using specifically only the reported values for all individual calendar months in 1953, what is the total sum of these values of expenditures for U.S. national defense and associated activities (in millions of nominal dollars)?
Trajectory 3 tool_calls (2× search → read)
search("national defense expenditures monthly 1953") → per-month bulletins (partial year)
search("…1953 November December 1954 to date") → surfaces treasury_bulletin_1954_02.pdfp.15 (Table 3, all 12 months of 1953)
read(treasury_bulletin_1954_02.pdf, p.15) → pulls the complete Table 3
Monthly Values for 1953
Table 3, in $millions
| Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov | Dec |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 3,632 | 3,501 | 3,789 | 3,891 | 3,746 | 4,056 | 3,890 | 3,519 | 3,787 | 3,647 | 3,540 | 3,465 |
Sum = 44,463.
Fonctionnement d'Agentic Search
Mistral Search Toolkit fournit des modules ouverts pour ingérer, vectoriser et indexer des données critiques et complexes dans le cloud ou sur site. Agentic Search s'appuie sur cet index en donnant au modèle cinq outils qui ressemblent à des opérations de système de fichiers familières :
searchtrouve les documents pertinents dans le corpus à l'aide de l'index existant.openouvre un document précis.navigatese déplace vers une page, une section ou une zone du document.readrécupère le contenu à cet emplacement.greptrouve un motif dans un document ouvert.
Au lieu de répondre uniquement à partir des premiers résultats top-k initiaux, le modèle peut inspecter ce qu'il trouve, affiner sa recherche, ouvrir les documents pertinents, accéder à des sections précises et lire les sources avant de répondre. L'index identifie les sources probables ; Agentic Search détermine ce qu'il faut inspecter dans ces sources et entre elles.
RAG en un seul passage

Agentic Search

Ces outils ne nécessitent ni fine-tuning ni entraînement propre à un modèle. À mesure que les modèles progressent en raisonnement et en utilisation d'outils, les récupérations s'améliorent sans changement d'infrastructure. C'est une propriété clé : la qualité de récupération suit les capacités du modèle au lieu d'être limitée par votre stratégie de découpage en fragments.
Utilisez Agentic Search pour
Les documents longs. Documents réglementaires, contrats, manuels, spécifications techniques et rapports où la réponse peut apparaître sur une page précise ou dans un tableau, une clause, une figure ou une note numérotée spécifique.
Les questions sur plusieurs sources. Recherches qui nécessitent que le modèle trouve, compare ou rapproche des preuves issues de plusieurs documents avant de produire une réponse.
Les réponses à vérifier. Chiffres financiers, clauses juridiques, références réglementaires et données opérationnelles, lorsque la réponse peut renvoyer à un emplacement stable et précis dans un document.
Les tableaux et documents structurés. États financiers, archives publiques et PDF scannés où le sens dépend des lignes, des colonnes, de la position sur la page ou du contexte adjacent, et pas seulement du texte narratif.
La récupération indexée est le bon point de départ pour
Des recherches directes. Documents courts et propres où la réponse est susceptible d'apparaître dans l'un des premiers fragments récupérés.
Une recherche à grand volume. Recherches par mots-clés ou sémantiques qui doivent renvoyer des passages pertinents sans raisonner dessus ni les parcourir.
Des questions simples et prévisibles. Cas d'usage où la source et l'emplacement probables de la réponse sont connus à l'avance, et où des étapes de récupération supplémentaires ont peu de chances d'améliorer le résultat.
Le RAG en un seul passage suffit souvent pour ces recherches. Ajoutez Agentic Search lorsque les questions nécessitent que le modèle dépasse les premiers résultats et examine les sources. Un index bien configuré reste la bonne base dans les deux cas.
Des résultats plus pertinents, plus vite
Nous avons évalué Agentic Search sur deux benchmarks standards du secteur, avec la stack Mistral Search Toolkit prête à l'emploi : découpage en fragments par défaut, classement par défaut, aucun réglage. Ces résultats sont des planchers, pas des plafonds, ce qui signifie que vous pouvez encore améliorer la qualité des résultats avec des réglages propres à votre cas d'usage.
Avec ces benchmarks, nous avons testé deux modèles avec Mistral Search Toolkit : Mistral Medium 3.5 (MM 3.5) et Z.ai GLM-5.2 (GLM-5.2), afin de montrer les performances d'un modèle plus petit (MM 3.5) et d'un modèle plus grand (GLM-5.2).
Les résultats de benchmark sont cohérents : la boucle agentique apporte des gains de qualité importants, et les outils de navigation augmentent la précision tout en réduisant les tokens, les tours et la latence inutiles. Nous observons les mêmes schémas de performance entre modèles internes et modèles tiers, ce qui indique qu'Agentic Search est indépendant du modèle et que la qualité de recherche devrait progresser avec les nouveaux modèles.
FinanceBench : 368 documents SEC, 150 questions
FinanceBench (Islam et al., 2023) teste la réponse à des questions financières sur 368 documents SEC (10-K / 10-Q / 8-K), avec une moyenne d'environ 147 pages chacun, soit environ 53 900 pages au total : des documents financiers longs et riches en tableaux. Les réponses sont évaluées par un juge LLM calibré sur des annotations humaines.
Nous avons constaté ceci :
La boucle agentique limitée à la recherche est le principal levier de qualité. Le passage d’un RAG en un seul appel à une boucle limitée à la recherche améliore la précision de +47,3 points pour MM 3.5 et de +52,6 points pour GLM-5.2, soit une amélioration d’environ 3× pour les deux modèles. Comme les modèles peuvent rechercher de manière itérative, ils peuvent compenser de premiers résultats faibles, affiner les requêtes et utiliser l’index comme outil actif.
La navigation améliore la précision. L’ajout des actions open, navigate, read et grep améliore encore la précision (+8,7 points pour MM 3.5, +6,7 points pour GLM-5.2). Cela signifie qu’une recherche ciblée avec exploration progressive dépasse les recherches larges répétées dans les documents complexes.
De meilleurs outils de retrieval améliorent l’efficacité en tokens et les performances. La boucle complète avec navigation répond correctement à davantage de questions tout en utilisant moins de tokens que la boucle limitée à la recherche (MM 3.5 : -23,9 % d’utilisation des tokens, GLM-5.2 : -33,7 %). Les outils de retrieval n’ajoutent pas de surcharge : ils remplacent les nouvelles tentatives de recherche inutiles par une navigation précise.
La latence diminue là où c’est important. Sur FinanceBench, l’ajout d’outils de retrieval par navigation améliore la latence : le p90 passe de 255 s → 154 s et la latence moyenne passe de 108 s → 71 s. En général, nous observons que les boucles limitées à la recherche effectuent des recherches larges répétées, tandis que la navigation aide le modèle à identifier les preuves plus rapidement.
OfficeQA Pro : 696 bulletins du Trésor, 133 questions
OfficeQA Pro est un benchmark numérique vérifiable basé sur des Treasury Bulletins historiques des États-Unis : des PDF financiers gouvernementaux scannés, riches en tableaux, couvrant un corpus de 696 documents et d’environ 89 000 pages. Nous présentons le premier passage pour le sous-ensemble « pro » de 133 questions.
Nous avons constaté ceci :
La recherche agentique et la boucle agentique + navigation réussissent sur un benchmark plus difficile et vérifiable. OfficeQA Pro comporte des réponses numériques, des PDF scannés et des recherches approfondies dans des tableaux. Même dans ce contexte, la boucle agentique complète améliore nettement la précision par rapport au RAG en un seul appel, avec 51,9 % pour GLM-5.2 (+45,6 points) et une hausse de +27,1 points pour MM 3.5.
La navigation améliore la qualité tout en réduisant le gaspillage. L’utilisation de la boucle complète (boucle agentique + navigation) améliore la précision de jusqu’à 35,6 % (+7,5 points, MM 3.5 ; +8,3 points, 19,0 % GLM-5.2), tout en réduisant la consommation de tokens. Le nombre de tours diminue de jusqu’à 7,0 % (MM 3.5, 2,3 % GLM-5.2).
Plus le benchmark est difficile, plus la boucle de retrieval devient importante. OfficeQA Pro repose sur des réponses numériques dans des documents scannés et riches en tableaux. Le RAG en un seul appel obtient à peine des résultats, tandis que la boucle agentique permet au modèle de rechercher de manière itérative, d’examiner les preuves et d’obtenir des gains de précision substantiels.
La stack d’outils a un impact important sur la document intelligence et les performances de recherche. Selon les travaux de recherche de Kimi, GLM-5.2 obtient 41,4 % sur OfficeQA Pro avec le harness Claude Code, contre 51,9 % avec le harness Mistral, soit +10,5 points sur le même modèle sous-jacent.
Commencer
En savoir plus sur la recherche agentique dans la documentation. Vous pouvez démarrer sur des déploiements cloud ou on-premises avec l’une des options suivantes :
Mistral Search Toolkit. Intégrez la recherche agentique à vos propres agents, workflows et déploiements client.
Bibliothèques. Utilisez la recherche agentique prête à l’emploi dans Studio et Vibe, sans développer vous-même le système de retrieval.
Le moyen le plus rapide de tester Search Toolkit consiste à utiliser Search Starter App. Elle crée un index local pour votre propre corpus avec une configuration par défaut. Vous pouvez ainsi essayer la recherche agentique sans être spécialiste de la recherche. Lorsque vous êtes prêt à configurer votre cas d’usage, vous pouvez :
Configurer l’ingestion. Sélectionnez les parseurs, les stratégies de fragmentation, les modèles d’embedding et les extracteurs adaptés à vos données et types de fichiers.
Ajuster l’indexation et le classement. Gérez les schémas Vespa, le comportement d’indexation et les profils de pertinence.
Étendre le retrieval. Ajoutez la réécriture de requêtes, le reranking ou le retrieval hybride au pipeline de recherche.




