RAG agentique : raisonnement documentaire souverain | Lexiane
RAG agentique on-premise avec boucle de raisonnement itérative. Analyse de corpus complexes, recoupement multi-sources, extraction à grande échelle. Architecture Rust, audit SHA-256, contrôle humain intégré.
Un RAG classique répond. Un RAG agentique raisonne avant de répondre — et sait reconnaître quand il doit chercher davantage avant de se prononcer.
Cette distinction, apparemment simple, change fondamentalement ce qu’un système documentaire peut accomplir. Elle déplace la frontière entre les questions auxquelles une IA peut répondre de façon fiable et celles qui lui échappent structurellement. Et elle pose des questions d’architecture — sur le contrôle, la traçabilité, la certification — que la plupart des implémentations agentiques ne traitent pas sérieusement.
Lexiane intègre une couche agentique conçue pour la production : fonctionnelle, maîtrisable, et architecturalement séparée du noyau certifié.
La limite structurelle du RAG classique
Un pipeline RAG linéaire fonctionne en une passe : la question de l’utilisateur est vectorisée, les passages les plus similaires sont récupérés, et le LLM génère une réponse à partir de ce contexte. Pour la majorité des requêtes documentaires directes, ce modèle est efficace et suffisant.
Mais il repose sur une hypothèse implicite rarement formulée : que la première récupération est suffisante pour produire une réponse fiable.
Cette hypothèse tient pour les questions simples et bien posées. Elle cède dans trois situations courantes.
La question est plus large que ce que la récupération initiale peut couvrir. “Synthétise les décisions prises sur le projet X entre janvier et mars” appelle des dizaines de passages éparpillés dans des comptes-rendus, des emails exportés, des notes de réunion. Une récupération par similarité sémantique retourne les passages les plus proches de la formulation de la question — pas nécessairement les plus pertinents sur l’ensemble de la période.
La question est ambiguë ou imprécise. L’utilisateur sait ce qu’il cherche, mais ne dispose pas du vocabulaire technique exact qui permettrait à la recherche vectorielle de cibler les bons passages. La première récupération retourne des résultats partiellement pertinents, mais pas ceux qui répondraient réellement à la question sous-jacente.
La réponse nécessite de croiser plusieurs sources. Les informations pertinentes sont présentes dans le corpus, mais éclatées sur des dizaines de documents qui ne se ressemblent pas sémantiquement. Aucune récupération en une passe ne peut les agréger.
Dans ces trois cas, le RAG classique produit une réponse — mais une réponse fondée sur un contexte insuffisant. Sans mécanisme d’évaluation de la qualité de la récupération, le système ne sait pas qu’il répond mal. Il répond avec la même apparente confiance, qu’il ait récupéré dix passages parfaitement pertinents ou trois passages vaguement liés.
Le RAG agentique résout ce problème en introduisant une boucle de raisonnement entre la récupération et la génération.
Ce qu’est réellement un agent RAG — et ce qu’il n’est pas
Avant de détailler l’architecture, une clarification s’impose. Le terme “agentique” est utilisé de façon très large dans le secteur de l’IA, souvent pour décrire des systèmes qui sont en réalité des workflows à étapes prédéfinies — une suite d’opérations codées en dur, exécutées séquentiellement, sans décision réelle à chaque étape.
Un vrai système agentique se distingue par une propriété fondamentale : il prend des décisions contextuelles à chaque itération, sur la base d’une évaluation de l’état courant — et ces décisions peuvent diverger selon le contenu récupéré, pas seulement selon la structure du workflow.
Ce n’est pas un chatbot. Un chatbot maintient un historique conversationnel et génère des réponses contextualisées — mais il ne cherche pas, n’évalue pas, et ne décide pas de reformuler sa recherche.
Ce n’est pas un moteur de recherche avancé. Un moteur de recherche retourne des résultats selon un algorithme de ranking. Il ne génère pas de réponse, n’évalue pas si les résultats sont suffisants, et ne prend pas de décision sur la suite.
Ce n’est pas un workflow à étapes fixes. Un workflow prédéfini exécute toujours les mêmes opérations dans le même ordre. Un agent peut parcourir des chemins différents selon ce qu’il trouve — reformuler deux fois si la première récupération est insuffisante, appeler un outil externe si le contexte documentaire est incomplet, s’abstenir si aucun chemin ne produit un contexte fiable.
Le RAG agentique de Lexiane est un orchestrateur de pipelines RAG dans une boucle de raisonnement. À chaque itération, il exécute un pipeline complet, évalue le résultat, et prend une décision sur la suite — selon des règles configurables et des gardes déterministes.
La boucle de raisonnement : anatomie d’une itération
Étape 1 — Transformation et récupération
Chaque itération commence par une phase de récupération. La requête courante — qui peut être la question initiale reformulée, une sous-question décomposée, ou une question enrichie par le contexte des itérations précédentes — passe par le pipeline de récupération complet.
La récupération n’est pas une simple recherche vectorielle. Lexiane implémente l’état de l’art de la récupération de production :
Transformation de requête. Avant toute recherche, le QueryTransformer peut appliquer plusieurs stratégies selon la configuration :
- Expansion de requête — enrichissement de la question avec des synonymes, des termes connexes, et des reformulations pour couvrir des passages qui n’utilisent pas les mêmes mots que la question.
- HyDE (Hypothetical Document Embeddings) — génération d’un document hypothétique qui répondrait à la question, vectorisation de ce document, et utilisation de son embedding pour la recherche. Cette stratégie améliore significativement la précision de la recherche sémantique sur des questions abstraites ou techniques.
- Décomposition en sous-questions — découpage de la question initiale en questions plus ciblées, chacune adressant une dimension spécifique de la réponse attendue.
Multi-query retrieval avec RRF. Le MultiQueryRetrievalStage génère N variantes de la requête, exécute une récupération indépendante pour chacune, et fusionne les résultats par Reciprocal Rank Fusion. La formule RRF — score(d) = Σ 1/(k + rang_i(d)) — produit un classement consolidé qui favorise les documents qui apparaissent en bonne position dans plusieurs listes indépendantes, sans être dominé par un seul signal de pertinence.
Recherche hybride. La récupération combine systématiquement la recherche dense (similarité vectorielle sémantique) et la recherche sparse (BM25, correspondance lexicale). Les documents pertinents par leur sens et les documents pertinents par leurs termes exacts sont tous récupérés — puis fusionnés et rerankés par un cross-encoder.
Étape 2 — Évaluation du contexte récupéré
Une fois la récupération effectuée, l’agent évalue la qualité du contexte obtenu selon plusieurs critères :
Pertinence globale. La porte de pertinence (RelevanceGateStage) calcule un score de confiance agrégé sur les passages récupérés. Ce score reflète dans quelle mesure le contexte est aligné avec la question posée.
Couverture thématique. L’agent évalue si les passages récupérés couvrent les dimensions de la question — ou si certaines dimensions sont absentes du contexte courant. Une question qui appelle une comparaison entre deux entités, dont une seule est représentée dans les passages récupérés, a un contexte incomplet.
Cohérence interne. Des passages contradictoires sur un même fait sont un signal que la récupération a ramené des informations conflictuelles — ce qui nécessite soit une récupération complémentaire pour arbitrer, soit un signalement explicite de la contradiction dans la réponse.
Étape 3 — Décision
Sur la base de cette évaluation, l’agent prend l’une de trois décisions :
Répondre. Le contexte est suffisamment pertinent, complet, et cohérent. Le pipeline de génération est déclenché avec le contexte consolidé des itérations successives. La réponse produite est ancrée dans des sources tracées, citées, et vérifiables.
Reformuler et relancer. Le contexte est insuffisant ou partiel. L’agent reformule la requête en utilisant les informations tirées des passages déjà récupérés pour orienter la nouvelle recherche. Cette reformulation peut prendre plusieurs formes : reformulation directe de la question, décomposition en sous-question ciblant la dimension manquante, ou reformulation par expansion vers le vocabulaire identifié dans les passages partiellement pertinents.
Appeler un outil externe. Le contexte documentaire est intrinsèquement incomplet pour cette requête — non pas parce que la récupération est imparfaite, mais parce que l’information n’est pas dans le corpus. L’agent peut appeler un outil externe configuré pour enrichir le contexte : consultation d’une API de données en temps réel, exécution d’un calcul, accès à une base de données relationnelle, ou appel à un service spécialisé.
Étape 4 — Contrôle de la boucle
Des gardes déterministes encadrent chaque itération et peuvent interrompre la boucle indépendamment du comportement du LLM :
- Nombre maximal d’itérations — la boucle s’arrête après N cycles, quels que soient les résultats obtenus.
- Délai maximal — une contrainte temporelle globale sur la session agentique.
- Score minimal de pertinence — si le contexte n’atteint pas le seuil requis après plusieurs reformulations, le système s’abstient plutôt que de générer une réponse mal fondée.
- Conditions de sécurité — les guardrails d’entrée et de sortie opèrent à chaque itération. Une injection de prompt détectée à l’itération N interrompt la boucle à ce stade.
Ces gardes sont des règles configurables, explicites, et inspectables. Ils ne dépendent pas d’un seuil de confiance interne du LLM — dont la calibration est opaque et variable selon les modèles.
La décision architecturale qui change tout
L’agentique hors du noyau certifié
La décision d’architecture la plus importante du module agentique de Lexiane n’est pas dans ce qu’il fait — c’est dans où il se trouve.
La boucle de raisonnement agentique n’est pas dans le noyau certifié. Elle orchestre le noyau de l’extérieur, via ses interfaces publiques, exactement comme un utilisateur humain orchestrerait des pipelines manuellement — mais à la vitesse d’un programme.
Cette séparation n’est pas un détail d’implémentation. C’est le principe qui rend le système simultanément capable et auditable.
Pourquoi la boucle agentique ne peut pas être dans le noyau certifié. Le noyau de Lexiane exécute des pipelines déterministes. Donnez-lui les mêmes entrées deux fois, il produit les mêmes sorties. C’est une propriété fondamentale d’un noyau certifiable — sans elle, les tests ne prouvent rien et l’audit ne peut rien vérifier.
La boucle agentique est non déterministe par nature. Le LLM qui décide de reformuler ou de répondre n’est pas un automate — ses décisions dépendent du contexte courant, de sa température, de l’historique de la session. Deux sessions avec la même question initiale peuvent prendre des chemins différents et aboutir par des routes différentes à des réponses équivalentes.
Mettre un comportement non déterministe dans un noyau certifié le rendrait incertifiable. Lexiane les sépare : le noyau reste déterministe, certifiable, auditable. La couche agentique reste non déterministe, mais bornée et contrôlée.
Ce que cette séparation garantit concrètement.
Les pipelines exécutés par l’agent sont exactement les mêmes que ceux du mode classique — mêmes stages, mêmes ports, même logique de validation à l’assemblage, même audit trail. L’agent n’a accès à aucune fonctionnalité du noyau qui ne soit exposée via ses interfaces publiques.
Chaque pipeline déclenché par l’agent — chaque itération de la boucle — produit ses propres enregistrements dans la chaîne SHA-256. La séquence complète de décisions est reconstituable : pourquoi l’agent a reformulé à l’itération 2, quels passages il a récupérés à l’itération 3, pourquoi il a finalement décidé de répondre à l’itération 4.
Le comportement non déterministe est contenu dans la couche agentique et borné par les gardes déterministes. Il ne peut pas contaminer le noyau ni altérer ses propriétés de sécurité.
Ce que le RAG agentique rend possible
Analyse de dossiers complexes et volumineux
Un dossier de réponse à appel d’offres, un dossier réglementaire de mise sur le marché, un dossier de contentieux juridique — ces ensembles documentaires sont volumineux, hétérogènes, et nécessitent de croiser des informations éparpillées sur des dizaines ou des centaines de documents.
Le RAG agentique peut décomposer automatiquement une demande d’analyse en sous-questions, les traiter itérativement, et synthétiser les résultats en une réponse structurée. Une question comme “Identifie les risques contractuels dans ce dossier fournisseur” devient une série de recherches ciblées : clauses de pénalité, conditions de résiliation, engagements de niveaux de service, historique des litiges — chacune traitée comme une itération distincte, dont les résultats sont consolidés avant la synthèse finale.
Recoupement de sources contradictoires
Deux rapports sur le même incident qui divergent sur les faits. Deux versions d’une procédure réglementaire qui se contredisent sur un point critique. Une norme et son décret d’application qui ne sont pas parfaitement cohérents.
Un pipeline classique choisit l’un ou l’autre contexte selon la proximité vectorielle. L’agent peut identifier la contradiction, requérir les deux contextes en parallèle, et formuler une réponse qui signale explicitement la divergence — avec les références précises aux documents source de chaque version. C’est une propriété qualitative fondamentale pour les contextes où une réponse qui masque une contradiction est pire qu’une absence de réponse.
Extraction et agrégation à grande échelle
Extraire toutes les dates d’échéance contractuelles d’un corpus de 500 contrats. Identifier tous les équipements mentionnés dans 10 000 fiches de maintenance avec leur dernière date d’intervention. Recenser toutes les décisions prises en comité de direction sur un sujet donné sur 24 mois.
Ces tâches nécessitent de nombreuses passes de récupération ciblée et une agrégation que la génération en une passe ne peut pas produire de façon fiable sur un corpus complet. L’agent peut traiter itérativement des sous-ensembles du corpus, consolider les résultats partiels, et produire un résultat agrégé cohérent.
Traversée du graphe de connaissances
En configuration GraphRAG, le RAG agentique dispose d’un outil supplémentaire : la traversée multi-hop du graphe de connaissances extrait des documents. Des questions relationnelles complexes — “Quels sont les liens entre ce projet, ses fournisseurs, et les incidents qualité documentés ?” — peuvent être résolues par une combinaison de récupération vectorielle et de traversée du graphe RDF, chaque itération enrichissant le contexte à partir d’un angle différent.
Sessions conversationnelles avec mémoire de raisonnement
Le serveur Lexiane maintient des sessions conversationnelles persistantes. Dans un contexte agentique, cette mémoire dépasse le simple historique des échanges : l’agent peut s’appuyer sur le contexte consolidé des questions précédentes pour orienter sa récupération sur les questions suivantes. Une session d’analyse de dossier peut s’étendre sur plusieurs échanges, chacun s’appuyant sur le raisonnement des échanges précédents — sans que l’utilisateur ait à recontextualiser à chaque question.
Quand utiliser le RAG agentique — et quand ne pas l’utiliser
Le RAG agentique n’est pas universellement supérieur au RAG classique. Il est plus puissant pour certaines tâches, plus coûteux pour toutes, et introduit une complexité opérationnelle supplémentaire. Le bon outil dépend de la nature des requêtes.
| Critère | RAG classique | RAG agentique |
|---|---|---|
| Questions directes, bien formulées | Optimal | Surcalibre |
| Questions ambiguës ou imprécises | Résultats variables | Amélioration significative |
| Sources multiples à croiser | Résultats partiels | Amélioration significative |
| Corpus < 10 000 documents bien structurés | Suffisant | Optionnel |
| Corpus volumineux, hétérogène | Peut manquer des passages | Recommandé |
| Extraction et agrégation à grande échelle | Difficile sur passage unique | Conçu pour ça |
| Contrainte de latence stricte (< 2s) | Adapté | Inadapté (plusieurs itérations) |
| Environnement certifié, comportement déterministe | Certifiable | Non certifiable (couche agentique) |
| Budget tokens contraint | Économique | Consommation multiple |
La règle pratique : si vos utilisateurs posent majoritairement des questions directes sur des sujets bien délimités, le RAG classique avec multi-query retrieval couvre l’essentiel des besoins. Si vos cas d’usage impliquent régulièrement des analyses complexes, des recoupements multi-sources, ou des extractions à grande échelle — le RAG agentique est le mode adapté.
Les deux modes coexistent dans Lexiane et utilisent exactement les mêmes pipelines sous-jacents. Le passage de l’un à l’autre est une décision de configuration par type de requête, pas une migration de système.
Le contrôle humain dans la boucle agentique
La question du contrôle humain sur les systèmes agentiques est centrale — à la fois pour les équipes de gouvernance IA et pour les référentiels réglementaires comme l’AI Act. Un système qui raisonne de façon autonome doit être observable, interruptible, et auditable.
Observabilité de chaque itération
Chaque itération de la boucle agentique est enregistrée dans la chaîne d’audit SHA-256 : question posée, stratégie de reformulation choisie, passages récupérés, décision prise (répondre / reformuler / outil), score de pertinence évalué. La séquence complète de raisonnement est consultable après coup — pas seulement la réponse finale.
Cette granularité d’audit permet à un superviseur de comprendre pourquoi le système a pris tel ou tel chemin — et d’identifier les cas où le raisonnement a été sous-optimal, pour ajuster les paramètres de la boucle.
Gardes déterministes comme mécanisme de contrôle
Les gardes qui encadrent la boucle agentique ne sont pas des paramètres du LLM. Ce sont des règles configurables appliquées par le code de l’orchestrateur, indépendamment des décisions du modèle de langage. Même si le LLM “décide” de continuer à reformuler, les gardes peuvent interrompre la boucle.
Ces gardes représentent la politique que votre organisation a définie sur l’utilisation du système : nombre maximal d’itérations, délai maximal, seuil de pertinence minimal pour déclencher la génération. Ils sont la matérialisation du contrôle humain dans la boucle.
Suivi de la consommation de ressources
Les statistiques de tokens consommés (UsageStats) sont accumulées sur l’ensemble de la session agentique et accessibles après exécution. En configuration cloud, ces données permettent de surveiller et de budgétiser la consommation API d’une session de raisonnement multi-itérations — et de détecter des sessions anormalement longues ou coûteuses.
Boucle de rétroaction
Le port FeedbackStore permet aux utilisateurs d’évaluer les réponses produites par le système agentique. Ces retours alimentent un registre exploitable pour l’amélioration continue : identification des types de requêtes où le raisonnement agentique est insuffisant, des domaines où la qualité de récupération est faible, des cas où la reformulation automatique aggrave les résultats plutôt que de les améliorer.
Considérations de performance et de coût
Le RAG agentique consomme plus de ressources qu’un pipeline classique — par définition, puisqu’il exécute plusieurs pipelines là où le mode classique en exécute un. Cette réalité doit être intégrée dans la conception du déploiement.
Consommation de tokens. Chaque itération de la boucle génère des embeddings pour la reformulation, récupère des passages, et sollicite le LLM pour la décision et éventuellement la génération. Sur un modèle cloud, cela se traduit par une multiplication des coûts API par rapport à un pipeline classique. Les gardes de limitation d’itérations sont le principal mécanisme de maîtrise de ces coûts.
Latence. Le temps de réponse d’une session agentique est la somme des temps de réponse de chaque itération. Une session à trois itérations prend trois fois plus de temps qu’un pipeline classique, plus le surcoût de l’évaluation inter-itérations. Le RAG agentique n’est pas adapté aux cas d’usage qui imposent une latence de réponse inférieure à quelques secondes.
Stratégies de maîtrise des coûts en production.
Routage par complexité. Le port QueryRouter de Lexiane permet de classifier chaque requête et de la diriger vers le mode adapté — classique pour les questions directes, agentique pour les questions complexes. Ce routage réduit significativement la consommation moyenne, en réservant le mode agentique aux requêtes qui en ont réellement besoin.
Modèle de décision léger. La décision de reformuler ou de répondre peut être confiée à un modèle de langage moins puissant (et moins coûteux) que le modèle de génération. Seule la génération finale sollicite le modèle de qualité maximale — les itérations intermédiaires utilisent un modèle de décision économique.
Cache sémantique. Le port SemanticCache permet de mettre en cache les réponses à des requêtes sémantiquement proches des requêtes précédentes. Une question déjà traitée — ou une question très similaire — ne déclenche pas une nouvelle session agentique : la réponse est retournée directement depuis le cache.
Questions fréquentes
Comment Lexiane détermine-t-il qu’une reformulation est meilleure que la précédente ?
L’évaluation de la qualité du contexte récupéré repose sur le score de la porte de pertinence (RelevanceGateStage) et sur les métriques de couverture. La décision de reformuler est prise quand ce score est inférieur au seuil configuré. La stratégie de reformulation — expansion, décomposition, HyDE — est déterminée par la configuration de la couche agentique et par l’analyse du contexte partiel récupéré.
L’agent peut-il modifier des données ou déclencher des actions dans des systèmes externes ? Uniquement les actions explicitement configurées comme outils disponibles. Le module agentique n’a pas accès à des fonctionnalités non définies dans sa configuration. Les outils disponibles, leurs paramètres, et leurs permissions sont définis à l’assemblage — pas dynamiquement par le LLM. L’agent ne peut pas s’auto-attribuer des capacités.
Comment garantir que l’agent ne part pas dans une direction indésirable sur des questions sensibles ? Les guardrails d’entrée et de sortie opèrent à chaque itération. Une requête sensible est bloquée par l’InputGuardrail dès sa détection — pas seulement sur la question initiale, mais sur chaque reformulation produite par l’agent. Une réponse qui franchit les politiques de contenu est interceptée par l’OutputGuardrail avant transmission. Les gardes déterministes de limitation d’itérations bornent la durée de tout raisonnement.
Le RAG agentique est-il compatible avec le RAG privé (air-gapped) ? Oui. En configuration air-gapped, la boucle agentique s’exécute entièrement en local — avec le LLM local (Mistral.rs) comme moteur de décision. La contrainte principale est la capacité de raisonnement du modèle local : un modèle 7B-13B est compétent pour la plupart des décisions de reformulation documentaire, mais peut montrer des limites sur des raisonnements très complexes. La configuration hybride — décision agentique déléguée à un LLM cloud sur des fragments anonymisés — offre un compromis entre puissance de raisonnement et souveraineté des données sources.
Peut-on limiter le RAG agentique à certains utilisateurs ou certains types de requêtes ?
Oui. Le routage par complexité (QueryRouter) permet d’activer le mode agentique sélectivement — selon le profil utilisateur, le type de requête, ou la collection documentaire interrogée. Un utilisateur standard peut être routé vers le pipeline classique, tandis qu’un analyste senior dispose du mode agentique pour ses requêtes complexes.
Comment déboguer une session agentique dont le résultat est insatisfaisant ? L’audit trail enregistre chaque itération avec ses paramètres : question reformulée, stratégie de transformation utilisée, passages récupérés, score de pertinence évalué, décision prise. La reconstruction complète du raisonnement est possible à partir de cette chaîne — ce qui permet d’identifier précisément l’itération où le raisonnement a divergé et d’ajuster les paramètres en conséquence.
Parlons de vos cas d’usage complexes.
Le RAG agentique apporte le plus de valeur sur des besoins documentaires précis : corpus volumineux et hétérogènes, questions transversales à de nombreuses sources, tâches d’extraction et d’agrégation à grande échelle. Ces besoins varient significativement selon les organisations.
Nous proposons un échange sur vos cas d’usage concrets — les questions que vos équipes posent aujourd’hui et auxquelles votre système documentaire répond mal, les analyses complexes qui requièrent encore une intervention manuelle, les corpus qui résistent à une recherche classique. Et une évaluation honnête de ce que le RAG agentique peut apporter — y compris si le mode classique avec multi-query retrieval couvre l’essentiel de votre besoin à moindre coût.
Ce que vous pouvez attendre :
- Une réponse sous 48h ouvrées
- Un interlocuteur technique qui connaît les cas d’usage agentiques en production et leurs limites réelles
- Une recommandation de configuration calibrée sur votre besoin — mode classique, agentique, ou hybride selon les types de requêtes
→ Prendre contact
Aucun engagement commercial. Une conversation sur vos cas d’usage.
Demander l'accès au Core Auditable
Inscrivez-vous pour être notifié de l'ouverture du programme d'audit de notre Core. Conformément à notre politique de confidentialité, votre adresse professionnelle sera exclusivement dédiée à cette communication technique, sans aucun usage marketing ultérieur. Accès distribué via registre privé sécurisé.
Nous contacter