Points clés
- La Directive sur la prise de décisions automatisée du Canada exige déjà des tests de biais avant le lancement (6.3.1) et une surveillance planifiée des résultats (6.3.2). La ligne directrice E-23 du BSIF étend la même discipline aux modèles d’IA des banques et des assureurs, avec des normes de surveillance qui entrent en vigueur le 1er mai 2027.
- Une mini-évaluation RAG réalisée à partir de textes réglementaires canadiens montre ce que la surveillance permet de détecter : un simple changement de segmentation et de top-k a fait passer la fidélité de 0,95 à 1,00 et la précision du contexte de 0,71 à 0,86 sur les mêmes 12 questions.
- Trois cadres ouverts couvrent le besoin : Ragas pour la profondeur des métriques, DeepEval pour les tests en intégration continue, TruLens pour le traçage en production. Le choix dépend du point faible de votre pipeline.
- Passez à l’action : ajoutez un jeu de 12 questions de référence et trois métriques Ragas à votre prochaine modification RAG, et relancez-les avant chaque déploiement.
Le contexte réglementaire
Deux instruments canadiens convergent vers une même exigence : si vous déployez un système d’IA, vous le testez avant le lancement et vous continuez de le tester ensuite.
La Directive sur la prise de décisions automatisée du Conseil du Trésor impose cette discipline aux ministères fédéraux depuis des années. L’article 6.3.1 exige que les données utilisées par les systèmes soient testées pour détecter les biais involontaires avant la mise en production. L’article 6.3.2 exige une surveillance planifiée des résultats pour repérer les effets non intentionnels et vérifier la conformité. Avec le droit à une explication significative de chaque décision (6.2.3), le portrait est clair : un système génératif non testé est autant un risque de conformité qu’un problème de qualité.
Le BSIF applique la même logique au secteur financier. Sa ligne directrice E-23 révisée sur la gestion du risque lié aux modèles entre en vigueur le 1er mai 2027 et vise les modèles d’IA et d’apprentissage automatique de toutes les institutions financières fédérales. Elle exige des normes documentées de surveillance assorties de critères d’évaluation, de mesures de suivi et de procédures d’escalade, ainsi qu’un examen indépendant visant à confirmer que les modèles fonctionnent comme prévu et conviennent à leur usage. Un assistant de génération augmentée par récupération (RAG) qui répond aux questions du personnel ou des clients sur les politiques est un modèle, et la discipline du cycle de vie d’E-23 s’y applique.
Aucun des deux instruments ne nomme d’outil. C’est une question de jugement d’ingénierie; j’ai donc construit un petit banc d’essai pour le savoir.
Le mini-banc d’essai
J’ai assemblé un corpus de 14 passages tirés de textes réglementaires publics : la Directive sur la prise de décisions automatisée du SCT (le PDF des publications fédérales) et un résumé professionnel des attentes de la ligne directrice E-23 du BSIF. J’ai ensuite rédigé 12 questions de test avec des réponses de référence écrites à la main, chacune liée au passage qui y répond, de « Quand la Directive est-elle entrée en vigueur? » à « Quelles étapes du cycle de vie les institutions fédérales doivent-elles gouverner en vertu d’E-23? ».
Le pipeline est volontairement ordinaire : récupération par TF-IDF sur des segments de caractères, et gemini-3.5-flash-lite qui génère des réponses de 2 à 3 phrases strictement à partir des passages récupérés. J’ai testé deux variantes sur les mêmes questions :
- Référence : segments de 400 caractères, sans chevauchement, récupération des 3 meilleurs passages.
- Améliorée : segments de 900 caractères avec chevauchement de 150 caractères, récupération des 6 meilleurs passages.
L’évaluation a utilisé Ragas 0.4.3 avec trois métriques : la fidélité (les affirmations de la réponse sont-elles appuyées par le contexte récupéré?), la précision du contexte (les passages récupérés sont-ils vraiment pertinents?) et la pertinence de la réponse (la réponse traite-t-elle la question?). Le juge LLM était gemini-3.5-flash-lite avec analyse de sorties structurées.
| Métrique | Référence (segments de 400 car., top-3) | Améliorée (segments de 900 car. + chevauchement, top-6) |
|---|---|---|
| Fidélité | 0,95 | 1,00 |
| Précision du contexte | 0,71 | 0,86 |
| Pertinence de la réponse | 0,29 | 0,28 |
Moyennes sur 12 questions. Ragas 0.4.3; fidélité et précision du contexte jugées par gemini-3.5-flash-lite, pertinence calculée avec des plongements TF-IDF locaux.
Le motif observé est la partie utile. La variante améliorée a fait passer la fidélité de 0,95 à 1,00 et la précision du contexte de 0,71 à 0,86 : des segments plus grands avec chevauchement gardent chaque passage récupéré autonome, si bien que les affirmations du générateur restent ancrées et que le top-6 contient moins de passages approximatifs que le top-3 de référence. La pertinence de la réponse est restée stable (0,29 contre 0,28), ce qui est en soi un constat : avec des plongements TF-IDF locaux, cette métrique récompense le chevauchement des mots plutôt que le sens, donc les différences de formulation la font varier. Deux métriques disent que le changement aide, une dit qu’il s’agit de bruit, et c’est à l’exploitant de trancher. Cet arbitrage, consigné et répété, est à quoi ressemble concrètement l’obligation de surveillance planifiée de la Directive (6.3.2) : un bon résultat isolé ne prouve rien; la tendance, si. L’important, c’est l’habitude : un jeu de référence, trois métriques et une comparaison avant/après à chaque changement.
Ragas, DeepEval et TruLens comparés
| Ragas | DeepEval | TruLens | |
|---|---|---|---|
| Idée centrale | Métriques LLM-juge avec ou sans référence pour le RAG | Cadre de tests de style pytest pour les applications LLM | Observabilité et traçage des applications LLM en production |
| Force | Jeu de métriques approfondi (fidélité, précision/rappel du contexte, pertinence de la réponse) avec intégrations LangChain/LlamaIndex | Cas de test, génération de données synthétiques et seuils de réussite compatibles avec l’intégration continue | Fonctions de rétroaction (ancrage, pertinence) calculées sur des traces réelles, avec tableaux de bord |
| Cas d’usage idéal | Diagnostiquer la dérive des réponses d’un pipeline RAG | Tester en régression les invites, les modèles et la récupération à chaque changement | Surveiller en continu un assistant déployé |
En pratique : des seuils de type DeepEval en CI, une rétroaction de type TruLens en production, des métriques Ragas en dessous. Les tests avant lancement et la surveillance planifiée correspondent aux seuils en CI et aux traces en production; les trois sont ouverts, et le vrai coût est celui des jetons du LLM juge.
Le point d’action
Inutile d’avoir un budget de recherche pour commencer à évaluer comme un organisme de réglementation s’y attend. Cette semaine : rédigez 12 questions auxquelles votre système RAG doit répondre, avec des réponses de référence d’une ligne. Calculez trois métriques Ragas sur une référence. Changez une chose, la segmentation ou le top-k, et relancez. Si les chiffres bougent comme les miens, vous venez de bâtir l’embryon du programme de surveillance que décrivent la Directive et E-23, et une réponse défendable pour la prochaine personne qui demandera comment vous savez que le système fonctionne toujours.
Note méthodologique : 12 questions, 14 passages de textes publics, récupération TF-IDF, génération et jugement par gemini-3.5-flash-lite, plongements TF-IDF locaux pour la métrique de pertinence. Les scores complets par question sont publiés avec le fichier de données de cet article. Échantillon réduit : considérez les écarts comme indicatifs, non définitifs.
Le corpus, le script du banc d’essai et les scores par question sont publics : movahedi-ca/rag-eval-demo.