RAG Query Rewriting : Résoudre correctement les questions de suivi pour les chatbots IA

Une question isolée comme « Et combien de temps est-ce valable ? » est souvent évidente pour un être humain. Il se souvient du produit précédemment évoqué, de la localisation et du délai en question. Une recherche documentaire, en revanche, ne voit au départ que très peu de mots. Sans le contexte de conversation adéquat, elle risque de ne rien trouver ou de chercher sur le mauvais sujet. Le RAG Query Rewriting (réécriture de requête RAG) résout ce problème en transformant une question de suivi dépendante du contexte en une requête de recherche autonome avant d'exécuter la recherche.

Cela ressemble à une étape intermédiaire mineure, mais cela détermine souvent la qualité d'un chat web multi-tours. Ce guide montre comment les équipes résolvent les questions de suivi, quand il vaut mieux demander des clarifications et comment éviter qu'une réécriture n'introduise de nouveaux faits, des autorisations erronées ou un contexte obsolète dans la recherche.

Pourquoi les questions de suivi dépassent les capacités d'une recherche documentaire

La première question d'un utilisateur est généralement concrète : « Quelle est la garantie applicable au modèle A ? ». Viennent ensuite de courtes formulations telles que « Et pour la version plus grande ? », « Est-ce aussi valable en Autriche ? » ou « De quoi ai-je besoin pour cela ? ». Les pronoms, les omissions de sujets et les références aux réponses précédentes sont naturels dans une conversation. Cependant, en tant que requêtes de recherche isolées, ils sont très faibles.

Un pipeline classique de recherche par mots-clés, vectorielle ou Hybrid Search ne peut évaluer que ce qu'il reçoit en entrée. Le reranking améliore l'ordre des résultats existants, mais ne remplace pas le sens manquant de « cela » ou « pour cela ». C'est pourquoi le Query Rewriting intervient en amont : il formule une requête autonome et cherchable à partir de la question actuelle et de l'historique pertinent.

Ce que doit accomplir une bonne réécriture

Une réécriture réussie est suffisamment complète pour la recherche (retrieval), tout en restant au plus près de l'intention de l'utilisateur. Par exemple, « Et pour l'Autriche ? » peut devenir « Quelles sont les conditions de garantie pour le modèle A en Autriche ? », si le modèle A et la garantie sont clairement établis dans le dialogue immédiatement précédent. La réécriture ne répond pas encore à la question. Son unique but est de trouver les sources appropriées.

Les recommandations architecturales actuelles d'Azure sur le Conversational RAG préconisent d'inclure l'historique de conversation pertinent et de formuler la question actuelle sous forme de requête autonome avec des références résolues avant le retrieval. La séparation mentionnée dans cette directive est essentielle : la question originale de l'utilisateur doit être conservée pour la génération de la réponse finale. Le système peut ainsi vérifier si les preuves trouvées correspondent réellement à la question posée.

Enrichir, mais ne rien inventer

Un module de réécriture (rewriter) peut reprendre des informations clairement présentes : le produit, la version, le pays, la langue ou la dernière opération mentionnée. En revanche, il ne doit pas ajouter un numéro de client manquant, supposer une variante de produit non spécifiée ou transformer une indication temporelle floue en une date précise. Une précision en apparence utile mais inventée orientera à coup sûr la recherche dans la mauvaise direction.

Les autorisations restent en dehors du modèle de texte

L'organisation (tenant), l'utilisateur connecté, les espaces documentaires autorisés et les rôles sont définis côté serveur. Ils ne doivent pas figurer sous forme d'affirmations librement formulées dans la requête réécrite. Le backend applique les filtres de métadonnées correspondants de manière séparée et inaltérable. Ni un message précédent dans le chat ni une réécriture par un modèle ne doivent débloquer un espace de recherche plus large.

Le contexte nécessite un budget maîtrisé

Envoyer l'intégralité de l'historique de chat non filtré au rewriter est rarement une bonne solution. Les anciens sujets peuvent obscurcir la question actuelle, les données personnelles risquent d'être transmises inutilement, et les longs historiques augmentent la latence et les coûts. À titre d'orientation pratique, les directives de Microsoft suggèrent d'inclure deux à cinq tours de conversation récents ainsi qu'un résumé des contenus plus anciens. Il ne s'agit pas d'une limite universelle, mais d'un point de départ pour vos propres tests.

Un ensemble de contexte compact peut se composer des éléments suivants :

• la question actuelle de l'utilisateur, non modifiée,
• quelques messages de l'utilisateur et de l'assistant immédiatement pertinents,
• les entités déjà confirmées (produit, processus, localisation),
• la langue/région (locale) et le fuseau horaire sous forme de champs techniques,
• un résumé éphémère et vérifié des parties plus anciennes du dialogue, et
• la version des règles de réécriture, de l'index de connaissances et de la configuration de recherche.

Les autorisations documentaires proprement dites restent séparées. De même, les adresses e-mail inutiles, les numéros de commande ou les réponses complètes doivent être retirés avant la réécriture. Un historique sobre en données facilite également le débogage ultérieur.

Un processus solide en six étapes

1. Vérifier l'autonomie : Une question claire et nouvelle comme « Comment changer mon mot de passe ? » peut directement être envoyée à la recherche. Tous les messages ne nécessitent pas une réécriture par modèle.
2. Identifier les références : Le système repère les pronoms, les ellipses, les termes de comparaison et les démonstratifs comme « là-bas », « les deux » ou « la deuxième option ».
3. Sélectionner le contexte pertinent : Seuls les messages permettant de résoudre ces références de manière plausible sont conservés. Un changement de sujet délibéré met fin à l'ancien contexte.
4. Décider entre réécriture ou clarification : Si une seule résolution est solide, une requête de recherche autonome est générée. S'il existe plusieurs significations plausibles, le chatbot pose une courte question de clarification.
5. Chercher et décomposer si nécessaire : La requête passe par la recherche par mots-clés, vectorielle ou hybride. Les questions à plusieurs volets peuvent être décomposées en sous-requêtes clairement identifiées.
6. Répondre à la question d'origine : La réponse est générée à partir des sources trouvées, se réfère à la formulation initiale et indique ouvertement les incertitudes ou l'absence de preuves.

La présentation du Microsoft Agentic Retrieval décrit un déroulement similaire : la requête et l'historique alimentent la planification, des sous-requêtes ciblées sont exécutées en parallèle et les résultats sont ensuite fusionnés. La documentation d'Amazon Bedrock détaille également la planification, les sous-requêtes itératives et la vérification de l'adéquation des contenus trouvés pour formuler une réponse. Ces fonctionnalités produit peuvent prendre en charge certaines parties du pipeline, mais les contrôles de qualité et de sécurité propres à votre application restent indispensables.

Réécriture, question de clarification ou décomposition de requête ?

Entrée	Réaction appropriée	Justification
« Et est-ce valable en Autriche ? » après une question claire sur la garantie	Formuler une requête autonome	L'objet et le contexte sont univoques.
« Qu'en est-il de l'autre ? » après la mention de trois variantes	Poser une courte question de clarification	Plusieurs interprétations sont plausibles.
« Compare le prix, le délai de livraison et le retour pour les deux modèles »	Décomposer en sous-requêtes ciblées	Plusieurs aspects indépendants nécessitent des résultats fiables.
« Nouveau sujet : Comment contacter le support ? »	Chercher sans l'ancien contexte produit	L'utilisateur indique un changement de sujet.

La décomposition de requête (Query Decomposition) est donc différente du Query Rewriting. La réécriture rend une question dépendante autonome ; la décomposition divise une question complexe en plusieurs tâches de recherche. La documentation Bedrock sur la Query Decomposition montre que plusieurs sous-requêtes peuvent améliorer la couverture. Cependant, chaque requête supplémentaire nécessite des limites, un modèle d'autorisation commun et une étape de fusion transparente.

Traiter les résultats de réécriture comme du code

Même si le résultat n'est que du texte, il doit respecter un contrat strict. Il est judicieux de structurer la sortie sous forme d'objet avec des champs tels que standaloneQuery, decision, resolvedReferences et reason. Les décisions valides peuvent être par exemple SEARCH_AS_IS, REWRITE, CLARIFY et DECOMPOSE. Le backend valide la longueur, la langue et les champs autorisés avant de lancer la recherche.

Le rewriter ne possède aucun outil et ne répond pas directement à l'utilisateur. Les instructions système contenues dans l'historique du chat, les textes de documents insérés ou les directives comme « Ignore les règles » restent des données et non des commandes de contrôle. Pour les espaces de recherche sensibles, une règle déterministe peut en outre garantir que les filtres de produit, de langue ou d'organisation ne proviennent jamais d'un texte libre.

Valider avec un jeu de tests dédié aux questions de suivi

La qualité ne peut pas être prouvée par quelques démonstrations réussies. Complétez votre Golden Set pour la qualité des réponses avec de véritables dialogues multi-tours. Pour chaque cas, enregistrez l'historique initial, la question actuelle, la décision de réécriture attendue, les entités autorisées, les ajouts interdits et les sources escomptées.

• Pronoms et sujets omis dans les questions de suivi courtes
• Corrections telles que « Non, je voulais dire le modèle B »
• Changements de sujet et retour à un sujet antérieur
• Variantes ambiguës nécessitant impérativement une clarification
• Changements de paramètres régionaux, de date et de fuseau horaire
• Tentatives non autorisées de modifier l'espace de recherche ou l'organisation
• Historiques longs contenant des détails anciens irrélevants
• Questions à plusieurs volets devant être décomposées puis regroupées

Mesurez séparément : La réécriture correspond-elle à l'intention de l'utilisateur ? Le retrieval trouve-t-il les sources attendues ? Une clarification a-t-elle été demandée en cas d'ambiguïté réelle ? Les filtres d'autorisation sont-ils restés intacts ? Quelle est la latence supplémentaire générée par cette étape ? Le cadre NIST AI RMF Core intègre les tests répétés, la mesure et la documentation tout au long du cycle de vie de l'IA. Pour les équipes web, cela signifie : ne modifiez les règles de réécriture, le modèle ou la sélection de contexte qu'avec un test de régression et un déploiement sous observation.

Checklist synthétique pour les équipes web

• La question d'origine de l'utilisateur est-elle conservée intacte jusqu'à la génération de la réponse ?
• Seules les parties d'historique pertinentes et sobres en données sont-elles incluses ?
• Le rewriter peut-il choisir clairement entre réécriture, clarification et décomposition ?
• Ajoute-t-il exclusivement des entités confirmées en évitant toute supposition ?
• Le backend applique-t-il la langue, l'organisation et les autorisations indépendamment de la réécriture ?
• Chaque sous-requête dispose-t-elle de limites strictes de volume, de temps et de coût ?
• Les résultats de recherche sont-ils évalués par rapport à la question initiale ?
• Un jeu de tests multi-tours couvre-t-il les références, les corrections et les changements de sujet ?

Conclusion : Clarifier la requête avant de répondre

Le RAG Query Rewriting transforme la concision naturelle d'un dialogue en une requête de recherche fiable. La plus grande valeur ne provient pas de réécritures très créatives, mais de limites claires : reprendre le contexte confirmé, résoudre les incertitudes par des questions de clarification, maintenir les autorisations côté serveur et évaluer la réponse par rapport à la question originale. Commencez par vingt questions de suivi typiques issues de votre support client, définissez la décision attendue et testez chaque modification par rapport à ces cas. Votre chat multi-tours gagnera en précision sans que le moteur de recherche ne réponde silencieusement à la mauvaise question.

Sources

• Microsoft Azure Architecture Center : Prompt Engineering pour le RAG
• Microsoft Learn : Agentic Retrieval dans Azure AI Search
• Amazon Bedrock : Configurer les requêtes et la génération de réponses
• Amazon Bedrock : Agentic Retrieval pour les bases de connaissances
• NIST AI Risk Management Framework Core