Le Retrieval-Augmented Generation, ou RAG, est la technologie clé qui rend l’IA exploitable pour les secteurs réglementés. Alors que les modèles de langage généralistes se fient à leurs données d’entraînement et hallucinent, fournissent des informations obsolètes et n’indiquent pas de sources, le RAG ancre l’IA dans une base de connaissances vérifiée. Le résultat : des réponses fondées sur les sources, actuelles et traçables.
Cet article explique l’architecture technique d’un système RAG pour les secteurs réglementés. Il s’adresse aux professionnels qui souhaitent comprendre ce qui se passe sous le capot lorsqu’ils utilisent un tel système. Pas besoin d’un diplôme en informatique, mais un intérêt technique est supposé.
Le principe fondamental
Un système RAG se compose de deux composants principaux : un composant de retrieval (recherche) et un composant de génération (production de texte). Leur combinaison résout les trois problèmes principaux des modèles de langage généralistes.
Sans RAG. L’utilisateur pose une question. Le modèle de langage génère une réponse exclusivement sur la base de ce qu’il a appris durant l’entraînement. Pas de source de données externe, pas de vérification factuelle, pas de référence aux sources.
Avec RAG. L’utilisateur pose une question. Le système parcourt d’abord une base de connaissances à la recherche de documents pertinents. Ces documents sont transmis au modèle de langage comme contexte. Le modèle génère sa réponse sur la base des documents récupérés et cite les sources.
La différence est comparable à celle entre un expert qui répond de mémoire et un expert qui consulte d’abord les documents pertinents avant de répondre. La seconde approche est plus fiable, et ses réponses sont vérifiables.
Le pipeline de retrieval en détail
La qualité d’un système RAG repose entièrement sur le pipeline de retrieval. Plus le système trouve des documents pertinents, meilleure sera la réponse. Un pipeline de retrieval moderne pour les secteurs réglementés comprend plusieurs étapes.
Étape 1 : traitement et indexation des documents
Avant que le système puisse répondre à des questions, les documents sources doivent être traités et indexés. Pour les secteurs réglementés, c’est plus complexe que pour les applications générales.
Extraction structurée. Les lois, ordonnances et décisions de justice ne sont pas des textes non structurés. Ils possèdent une structure hiérarchique. Une loi fédérale se compose de parties, titres, chapitres, sections, articles et alinéas. Une décision de justice comprend les faits, les considérants et le dispositif. Cette structure doit être préservée lors du traitement afin que le système puisse effectuer des recherches au bon niveau de granularité.
Chunking. Les documents sont divisés en segments (chunks) suffisamment petits pour un retrieval efficace, mais suffisamment grands pour fournir un contexte adéquat. Pour les textes juridiques, la structure naturelle (article, alinéa, considérant) constitue souvent la meilleure frontière de segmentation. Un découpage arbitraire par nombre de caractères détruit la cohérence.
Embedding contextuel. Avant qu’un segment ne soit converti en vecteur, le système génère une description contextuelle : à quelle loi appartient cet article ? Dans quel chapitre se trouve-t-il ? De quoi traite-t-il ? Cette information contextuelle est ajoutée en préambule du segment et améliore considérablement la précision de la recherche. Un alinéa isolé « Le taux d’imposition est de 8% » est peu utile sans contexte. Le même alinéa avec le contexte « Art. 55 de la loi fiscale du canton de Zurich, section impôt sur le revenu des personnes physiques » est précisément identifiable.
Vectorisation. Chaque segment (avec son information contextuelle) est converti par un modèle d’embedding en un vecteur de haute dimension. Ce vecteur est une représentation mathématique du sens du texte. Des significations similaires produisent des vecteurs similaires. Cela permet la recherche sémantique : le système trouve des documents pertinents sur le fond, même s’ils utilisent d’autres termes.
Indexation BM25. Parallèlement à la vectorisation, chaque segment est indexé dans un index de recherche textuelle classique (BM25). Cet index est optimisé pour les termes exacts : numéros d’articles, numéros de dossier, termes techniques spécifiques, abréviations juridiques. Recherche sémantique et recherche exacte se complètent.
Étape 2 : recherche hybride
Lorsque l’utilisateur pose une question, deux recherches sont exécutées en parallèle.
Recherche vectorielle. La question est convertie en vecteur et comparée à la base vectorielle. Le système trouve les segments dont la signification est la plus proche de la question. Exemple : la question « Quelles sont les obligations du bailleur en cas de défauts ? » trouve les dispositions pertinentes du Code des obligations, même si celles-ci parlent de « garantie pour les défauts » et de « réparation ».
Recherche par mots-clés (BM25). Simultanément, le système parcourt l’index textuel à la recherche de correspondances exactes. C’est particulièrement important pour les références d’articles (« art. 259a CO »), les numéros de dossier des arrêts, les termes juridiques spécifiques et les abréviations.
Reciprocal Rank Fusion (RRF). Les résultats des deux recherches sont combinés par un algorithme qui priorise les documents bien classés dans les deux recherches. Un document à la fois sémantiquement pertinent et bien noté dans la recherche par mots-clés obtient le rang le plus élevé.
Étape 3 : reranking
La recherche initiale lance un filet large. Le reranking filtre les résultats.
Cross-Encoder. Un modèle spécialisé évalue chaque paire document-question en détail. Contrairement à la recherche vectorielle, qui encode documents et questions indépendamment puis les compare, le Cross-Encoder examine le document et la question conjointement. Cela permet une évaluation plus fine de la pertinence.
Optimisation de la fenêtre de contexte. Le nombre de documents transmis au modèle de langage est limité par la fenêtre de contexte. Le reranking garantit que les documents les plus pertinents occupent l’espace disponible. Les documents moins pertinents sont filtrés pour ne pas distraire le modèle.
Étape 4 : génération
Le modèle de langage reçoit la question de l’utilisateur accompagnée des documents récupérés comme contexte.
Instructions. Le modèle est enjoint de fonder sa réponse exclusivement sur les documents fournis. Si les documents ne contiennent pas d’information relative à la question, le modèle doit le communiquer de manière transparente, plutôt que d’inventer une réponse.
Attribution des sources. Le modèle renvoie dans sa réponse aux sources spécifiques qu’il a utilisées. Chaque assertion est associée à un document concret. L’utilisateur voit : cette information provient de l’art. 259a CO, celle-là de l’ATF 135 III 345.
Sortie structurée. Pour les applications réglementées, une sortie structurée est importante. Au lieu d’un texte libre non structuré, le système fournit la réponse organisée par base juridique, résumé et références aux sources.
Exigences particulières pour les secteurs réglementés
Le RAG standard, tel qu’il est utilisé dans les applications générales, ne suffit pas pour les secteurs réglementés. Les extensions suivantes sont nécessaires.
Multilinguisme. En Suisse, les lois fédérales existent en allemand, français et italien. Les trois versions linguistiques sont également contraignantes. Un système RAG pour le droit suisse doit pouvoir effectuer des recherches multilingues. Une question en allemand doit aussi trouver la version française de la loi si elle est plus pertinente. Les modèles d’embedding multilingues comme BGE-M3 le permettent en projetant des textes de différentes langues dans le même espace vectoriel.
Graphes de citations. Les textes juridiques n’existent pas de manière isolée. Un article de loi renvoie à d’autres articles. Les décisions de justice citent des lois et d’autres décisions. Les ordonnances précisent des lois. Ces relations forment un graphe. Un système RAG pour les secteurs réglementés doit connaître et exploiter ce graphe. Lorsqu’un utilisateur recherche un article de loi, le système devrait également trouver les décisions de justice pertinentes qui interprètent cet article et les ordonnances qui le précisent.
Versionnage. Les lois évoluent. Un article qui avait une certaine teneur en 2024 peut être différent en 2026. Le système doit gérer différentes versions. Il doit utiliser la version actuelle par défaut, mais pouvoir aussi récupérer les versions historiques. Pour les affaires portant sur un état juridique antérieur, c’est la version historique qui est pertinente.
Retrieval granulaire. Dans les systèmes RAG généraux, la recherche s’effectue souvent au niveau du document. Pour les secteurs réglementés, c’est trop grossier. Le système doit pouvoir chercher au niveau de l’article, de l’alinéa, voire de la phrase. Lorsqu’un utilisateur recherche le délai de prescription d’une créance précise, il a besoin de l’alinéa spécifique, pas de la loi entière.
Piste d’audit. Chaque interaction avec le système doit être consignée : la question, les documents récupérés, les réponses générées, les sources utilisées. Cette piste d’audit est essentielle pour le contrôle qualité, les exigences de conformité et la traçabilité vis-à-vis des clients et des autorités.
Mesure de la qualité
Un système RAG est seulement aussi bon que sa capacité à trouver les bons documents et à générer des réponses correctes. La qualité est mesurée selon plusieurs métriques.
Recall. Combien de documents pertinents le système trouve-t-il ? Un système qui trouve 8 articles pertinents sur 10 a un recall de 80%. Pour les secteurs réglementés, un recall élevé est critique. Un article pertinent manqué peut fausser l’ensemble de l’analyse.
Précision. Combien de documents trouvés sont effectivement pertinents ? Un système qui fournit 100 documents dont seulement 5 sont pertinents a une faible précision. Cela submerge l’utilisateur d’informations non pertinentes.
Fidélité. La réponse générée est-elle conforme aux documents récupérés ? Un système qui récupère correctement des documents mais s’écarte du contenu lors de la génération a un problème de fidélité.
Taux d’hallucination. À quelle fréquence la réponse contient-elle des informations qui ne figurent dans aucun des documents récupérés ? Pour les secteurs réglementés, ce taux doit tendre vers zéro.
Pourquoi l’architecture est déterminante
L’architecture technique d’un système RAG détermine s’il convient ou non aux secteurs réglementés. Un système avec des embeddings de mauvaise qualité, sans recherche BM25, sans reranking et sans attribution des sources peut fonctionner pour des questions générales. Pour la recherche juridique, la vérification de conformité ou l’analyse fiscale, il est insuffisant.
L’architecture détermine aussi où les données sont traitées. Pour les entreprises suisses des secteurs réglementés, l’ensemble du pipeline doit fonctionner en Suisse : calcul des embeddings, base vectorielle, modèle de langage, piste d’audit. Une architecture qui envoie les données à des serveurs à l’étranger n’est pas admissible pour de nombreux cas d’usage.
Enclava implémente cette architecture entièrement en Suisse. La plateforme comprend des données juridiques et réglementaires vérifiées, un retrieval multilingue, une attribution des sources granulaire et une auditabilité complète. La base de connaissances SwissLaw contient plus de 27 000 lois et 1,1 million de décisions de justice, structurées, versionnées et continuellement mises à jour.
Si vous souhaitez comprendre comment le RAG pour les secteurs réglementés fonctionne en pratique, rendez-vous sur enclava.ch ou contactez-nous à [email protected].