Filtres de métadonnées RAG pour chatbots IA : séparer langue, version et accès

Un chatbot IA peut trouver des passages de texte sémantiquement très proches et pourtant préparer une réponse erronée : le manuel en anglais au lieu du français, la documentation de la version précédente au lieu de l'actuelle, ou des consignes internes destinées à un utilisateur sans autorisations. Dans ce cas, le classement n'est pas forcément mauvais ; c'est le périmètre de recherche qui était incorrect.

Les filtres de métadonnées RAG résolvent exactement ce problème. Ils restreignent, avant ou pendant la recherche, les documents et chunks éligibles comme contexte. La pertinence répond ensuite à la question : « Quel contenu correspond le mieux ? ». Mais le filtre répond d'abord à : « Que peut-on et doit-on prendre en compte dans cette situation ? ».

Pourquoi la similitude seule n'est pas un périmètre fiable

La recherche vectorielle et hybride classe les contenus selon leur proximité linguistique ou sémantique. Un manuel pour la version 4 d'un produit peut sembler extrêmement similaire à une question sur la version 5. Une liste de prix pour un autre marché peut contenir les mêmes noms de produits. Et un document de support interne peut fournir une réponse plus précise que la FAQ publique, bien qu'il ne doive jamais apparaître dans un chat public.

C'est pourquoi le retriever doit distinguer deux types de conditions :

• Règles strictes : telles que le tenant, le rôle, le statut de publication ou le périmètre de données autorisé. En cas de valeur inconnue, la recherche doit rester fermée.
• Critères de sélection métier : tels que la langue, la famille de produits, la version, la région ou la période de validité. Ils augmentent la précision et évitent les contextes contradictoires.

Le panorama OWASP pour les applications LLM associe explicitement les risques vectoriels et d'embeddings à la limite de confiance d'une application IA. C'est une perspective essentielle : une vérification d'authentification avant le chat ne suffit pas si la recherche par similitude qui suit s'exécute sur un index trop large.

Un schéma de métadonnées adapté au quotidien

Un bon filtrage ne commence pas par une longue requête, mais par quelques champs canoniques. Pour de nombreux chatbots de sites web, six groupes suffisent :

• Langue et marché : par exemple locale et market, avec des valeurs strictement définies plutôt que du texte libre.
• Produit et version : identifiant produit stable, plage de versions et, en option, plateforme ou formule.
• Validité : statut de validation, valide à partir de, valide jusqu'à et une version de source unique.
• Public cible : public, client, partenaire ou équipe interne — séparé de la vérification effective des rôles.
• Périmètre d'accès : tenant, groupe ou principal, issu exclusivement d'un contexte serveur vérifié.
• Origine : identifiant source, URL, type de document et zone de contenu responsable pour la traçabilité.

Les métadonnées doivent se trouver au niveau où s'effectue la recherche. Si un document est découpé en chunks, les champs de périmètre déterminants doivent être associés de manière fiable à chaque chunk. Sinon, un document peut être correctement classé tandis que certains résultats de recherche perdent cette catégorisation. La documentation OpenAI sur File Search montre par exemple comment utiliser les attributs de fichier pour le filtrage des métadonnées. La référence Amazon Bedrock documente les opérateurs de comparaison, de liste et d'intervalle pour la même approche.

Ne jamais laisser le modèle de langage autoriser les filtres

Un modèle peut déduire de la question des indices tels que la langue ou la référence à un produit. Il ne doit cependant pas décider du tenant auquel appartient une personne ni des rôles qu'elle possède. Ces valeurs doivent provenir de la session, du système d'identité et des règles métier côté serveur. De même, une chaîne de filtrage générée par le modèle ne doit pas être transmise non vérifiée au service de recherche.

Un processus robuste ressemble à ceci :

1. Le serveur authentifie la requête et détermine le périmètre de données autorisé.
2. Des règles déterministes définissent les champs stricts comme le tenant, le rôle et le statut de publication.
3. Les caractéristiques détectées comme la langue ou le produit sont validées par rapport aux valeurs autorisées.
4. Le retriever n'exécute qu'une structure de filtre typée et paramétrée.
5. L'application vérifie à nouveau les sources retournées pour s'assurer du périmètre attendu.
6. En cas de contexte manquant ou contradictoire, le chatbot demande des précisions ou affiche une réponse de secours sécurisée.

La documentation Microsoft sur les filtres de sécurité établit une distinction utile : un principal dans le filtre n'est d'abord qu'une valeur. L'authentification et l'autorisation doivent avoir lieu de manière fiable en dehors de l'expression de recherche. Pour les portails clients, notre article sur la séparation entre chatbot IA public et authentifié approfondit cette limite.

Pré-filtrage ou post-filtrage ?

La position du filtre influence la qualité et le temps d'exécution. Un pré-filtre restreint les candidats dès la recherche vectorielle. Un post-filtre cherche d'abord de manière plus large puis supprime les résultats non autorisés. Selon la documentation Azure sur les filtres vectoriels, le post-filtrage peut manquer des résultats pertinents en cas de filtres très sélectifs et de faible valeur k ; le pré-filtrage privilégie le rappel dans le sous-ensemble autorisé, mais peut engendrer un coût de calcul plus élevé si les filtres sont très stricts.

Pour les limites d'accès strictes, « chercher large d'abord, masquer ensuite » n'est pas un schéma adapté. Le périmètre autorisé doit être imposé au sein de la requête de recherche. Pour les filtres purement métiers, une équipe peut comparer les variantes de pré- et post-filtrage. L'important n'est pas seulement le temps de réponse moyen, mais aussi la fréquence à laquelle un résultat autorisé présent est manqué en raison de l'ordre choisi.

Les filtres ne remplacent pas le classement. Au sein du corpus autorisé, la recherche hybride et le reranking peuvent continuer à prioriser les meilleures sources. L'ordre est donc : définir le périmètre, récupérer les candidats, évaluer la pertinence, vérifier les sources, générer la réponse.

Quatre cas typiques de filtrage

Langue avec secours intentionnel

Pour une question en français, la première recherche doit cibler du contenu validé en français. S'il n'y a aucun résultat, l'application ne doit pas mélanger plusieurs langues de manière silencieuse. Un second parcours explicite peut basculer sur une langue de base validée et le préciser dans la réponse. Un QA de locale pour bases de connaissances multilingues vérifie en outre si les variantes sont réellement équivalentes sur le plan du contenu.

Version du produit et validité temporelle

Une source ne doit pas sembler à jour simplement parce qu'elle a été indexée récemment. Ce qui compte, c'est la version métier et la validation. Marquez les contenus avec un ID produit stable, une plage de versions, valid_from, valid_until et un statut. En cas de validations chevauchantes, le pipeline doit signaler un conflit plutôt que d'intégrer les deux textes dans le même prompt. L'interaction entre cadence d'indexation et maintenance des sources est décrite dans le guide sur la mise à jour de la base de connaissances d'un chatbot IA.

Tenant et rôle

En cas d'index partagé, chaque requête doit contenir le tenant déterminé côté serveur et les principaux valides. L'absence de métadonnées ACL signifie « non accessible », et non « public ». Après un changement de rôle ou la révocation d'une autorisation, un test doit démontrer que les anciennes sessions n'accèdent plus aux chunks précédemment autorisés.

Support public et consignes internes

Une consigne d'escalade interne peut correspondre parfaitement sur le plan technique à la question d'un client. Cela n'en fait pas pour autant une source autorisée. Séparez le périmètre de publication et le type de document ; marquez par défaut les contenus non validés comme exclus. Un bot public doit, en cas de doute, basculer vers un parcours de contact ou de transfert humain plutôt que de deviner des détails internes.

Les erreurs d'implémentation les plus fréquentes

• Taxonomie en texte libre : des valeurs comme fr, FR et fr-FR créent involontairement trois groupes distincts.
• Ouverture par défaut (Default-open) : les chunks sans rôle, statut ou tenant se retrouvent dans tous les périmètres de recherche.
• Logique booléenne erronée : un OR entre le tenant et la langue annule en pratique la limite stricte.
• Décalage document-chunk : lors d'une réindexation, les nouvelles métadonnées ne sont pas appliquées à tous les chunks.
• Tests uniquement positifs : l'équipe vérifie si un document autorisé apparaît, mais pas si un document interdit au contenu similaire est bien exclu.
• Absence de résultats traitée comme un problème de modèle : un filtre strict ne retourne rien et l'application laisse le modèle répondre sans sources.

QA des filtres : tester les limites, pas seulement les résultats

Un jeu de test pertinent contient pour chaque réponse attendue au moins un contre-candidat proche : mauvaise langue, ancienne version, validation expirée, autre tenant ou public interne. Le test montre ainsi si le filtre sépare réellement les contenus et ne se contente pas de placer le bon résultat en haut par hasard.

Les indicateurs clés sont le taux de violation du périmètre, le rappel dans le sous-ensemble autorisé, la proportion de recherches vides, le nombre de valeurs de métadonnées inconnues, la latence des filtres au 95e percentile ainsi que la part de réponses de secours et de demandes de clarification. Pour les contenus restreints, le taux de violation du périmètre toléré doit être nul. Le framework NIST AI RMF Core recommande de tester les systèmes d'IA avant leur déploiement et régulièrement en production, tout en documentant les limites de sécurité, de fiabilité et de contexte.

Pour cela, ne conservez pas de contenus inutiles ou de questions utilisateurs complètes dans vos journaux. Le plus souvent, la version du filtre, le périmètre abstrait, le nombre de candidats, les ID des sources sélectionnées, le motif de rejet et le résultat du post-contrôle suffisent. Cela permet le débogage sans créer de deuxième fuite de données dans le système d'observabilité.

Check-list pratique avant le déploiement

1. Documenter les champs de métadonnées canoniques, les types de données, les valeurs autorisées et les responsables.
2. Séparer les limites d'accès strictes des champs de sélection métier.
3. Traiter systématiquement l'absence de valeurs liées à la sécurité comme non autorisée.
4. Construire les filtres à partir d'un contexte serveur vérifié et paramétrer les entrées.
5. Vérifier par échantillonnage les métadonnées après l'ingestion et le découpage en chunks.
6. Tester les cas positifs, négatifs, limites et de révocation sur l'index réel.
7. Mesurer le comportement des pré-/post-filtres avec un k réaliste et des périmètres sélectifs.
8. Rediriger les résultats vides vers une demande de clarification, une réponse de secours sécurisée ou un transfert humain.
9. Versionner les modifications de filtres et les déployer avec des tests de régression du retrieval.

Les filtres de métadonnées RAG sont donc bien plus qu'une fonctionnalité de confort pour la recherche. Ils font le lien entre modèle de contenu, identité, fraîcheur des données et qualité de récupération. Définir le périmètre de manière déterministe en premier lieu offre au classement et au modèle de langage une base de travail plus restreinte, plus propre et vérifiable.

Prochaine étape : choisissez une question de support réelle et créez cinq contre-sources très proches représentant une mauvaise langue, une version obsolète et des autorisations incorrectes. Ce n'est que si aucune d'entre elles ne dépasse le périmètre de recherche autorisé que le filtre pourra être intégré au flux de chat en production.

Sources

• OpenAI : File Search et filtrage de métadonnées
• Microsoft : Filtres dans les requêtes vectorielles
• Microsoft : Modèle de filtre de sécurité
• Amazon Bedrock : API RetrievalFilter
• NIST : AI Risk Management Framework Core
• OWASP : GenAI LLM Top 10 2026