Un RAG qui « a l’air intelligent » peut citer la mauvaise page. Ce tutoriel vous montre comment prouver — ou infirmer — la fiabilité de votre assistant documentaire : constituer un jeu de questions ancré dans vos PDF, définir ce que vous appelez une bonne réponse, automatiser une passe d’évaluation (script maison ou Ragas), puis corriger chunks, OCR ou consignes. Exemple fil rouge : la base documentaire d’une PME industrielle près de Valenciennes et le règlement d’une asso à Amiens.
Plan du tutoriel
Huit sections : (1) pourquoi évaluer, (2) ce qu’on mesure vraiment, (3) construire le jeu de test, (4) protocole humain puis script, (5) outils (Ragas ou maison), (6) boucle d’amélioration, (7) scènes HdF, (8) pièges à éviter. Si vos PDF sont des scans, commencez par l’OCR avant indexation. Pour coder l’index, LlamaIndex + Qdrant. Le principe RAG : glossaire RAG.
Pourquoi évaluer (au-delà du « ça a l’air bien »)
Une démo devant un comité de direction peut réussir sur trois questions préparées et échouer le lundi suivant sur la question d’un salarié. L’évaluation transforme l’anecdote en protocole : mêmes questions, même corpus, même consigne de réponse, compte rendu de ce qui casse. Vous ne cherchez pas un trophée. Vous cherchez à savoir si le bon extrait est retrouvé, et si la rédaction le respecte.
En Hauts-de-France, une collectivité qui ouvre un chatbot de démarches, ou une PME qui indexe des modes opératoires, engage sa crédibilité. Une belle phrase fausse coûte plus cher qu’une réponse « je ne trouve pas ». L’évaluation rend visible ce risque avant la mise en ligne.
Ce qu’on mesure — sans scores inventés
Deux familles de jugements suffisent pour démarrer. Pertinence du retrieval : le passage renvoyé contient-il l’information nécessaire ? Fidélité de la génération : la réponse affirme-t-elle seulement ce qui est dans les passages (ou dans le refus explicite) ? Vous pouvez ajouter la clarté, la langue, le ton administratif — mais gardez-les séparés. Mélanger « joli français » et « bon extrait » masque les vrais défauts.
Refusez les classements magiques (« 87 % de qualité ») sortis d’un banc d’essai que vous n’avez pas compris. Si vous utilisez une bibliothèque d’évaluation, lisez ce que chaque métrique tente de capturer, et confrontez-la toujours à une relecture humaine sur un échantillon. IAHDF ne fournit pas de chiffres de benchmark à coller dans un PowerPoint.
| Critère | Question à se poser | Verdict possible |
|---|---|---|
| Retrieval | Le bon passage est-il dans le top renvoyé ? | Oui / partiel / non |
| Fidélité | La réponse invente-t-elle hors extrait ? | Fidèle / extrapolée / inventée |
| Couverture | Tous les points demandés sont-ils traités ? | Complet / incomplet |
| Abstention | Dit-il « absent du corpus » quand c’est le cas ? | Correct / surplus confiant |
| Lisibilité | Un agent peut-il coller la réponse après relecture courte ? | Oui après edit / non |
Construire le jeu de questions
Visez d’abord un noyau sérieux plutôt qu’un volume impressionnant. Une PME près de Valenciennes peut partir sur quelques dizaines de questions bien ancrées : une par procédure critique, quelques questions pièges (synonymes, sigles, anciennes versions), et des questions hors corpus pour tester l’abstention. Chaque ligne du tableau porte : question, réponse attendue courte, identifiant du document, repère de page ou section, type (factuelle / procédure / hors corpus).
Écrivez les questions comme vos utilisateurs les posent, pas comme un juriste les rédigerait. « Comment on fait pour… » vaut mieux qu’une formulation artificielle. Faites relire le jeu par quelqu’un du métier qui n’a pas construit l’index. Si la réponse attendue n’est pas dans le corpus, corrigez le corpus ou la question — ne forcez pas le RAG à inventer.
id;question;reponse_attendue;doc_id;repere;type;notes Q01;Quel EPI pour l'intervention sur la presse 3 ?;Casque + lunettes + chaussures de sécurité;MO-presse3.pdf;§4.2;factuelle;vérifier version 2024 Q02;Peut-on démarrer sans consignation ?;Non — procédure de consignation obligatoire;MO-presse3.pdf;§2;procedure; Q03;Quel est le numéro du standard de la mairie de Testville ?;Absent du corpus;—;—;hors_corpus;doit s'abstenir
Protocole : humain d’abord, script ensuite
Six étapes pour évaluer son RAG
Geler le corpus et la configuration
Notez la date, la liste des documents indexés, les réglages de chunking et le modèle de génération (tag copié depuis la doc officielle). Sans gel, vous comparez des pommes et des poires. Si vous venez d’OCRiser, archivez aussi la version texte utilisée. Une évaluation sur un index mouvant ne prouve rien, sinon que le hasard a souri à la démo. Sans ce gel, un collègue peut ajouter un PDF pendant le test et fausser tout le diagnostic de la PME valenciennoise.
Passer le jeu en aveugle métier
Faites répondre le RAG à toutes les questions du noyau. Un relecteur métier note retrieval et fidélité avec la grille qualitative, sans regarder les « belles phrases ». Exigez la citation ou le passage source quand c’est possible. Comptez les abstentions correctes : elles valent autant qu’une bonne réponse. Archivez les sorties brutes pour comparaison ultérieure. Exigez que le relecteur ignore le style littéraire : seule compte la vérité procédurale pour l’atelier methods. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
Classer les échecs par cause
Séparez : document absent, OCR pourri, mauvais chunk, embedding peu adapté au français, consigne trop créative, hallucination malgré bon passage. Chaque cause ouvre un chantier différent. Traiter une hallucination de génération en « montant le GPU » ne répare pas un scan muet — voir OCR avant indexation. Une cause mal classée fait perdre une semaine : corriger l’OCR n’arrangera jamais une consigne qui encourage la paraphrase inventive. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
Automatiser une passe de non-régression
Une fois le jugement humain cadré, un script Python peut rejouer les questions, stocker réponses et passages, et signaler les écarts. Ragas ou une grille maison peuvent aider à prioriser ; ils ne remplacent pas le métier. Versionnez le script avec le jeu de test. Relancez après chaque changement majeur d’index ou de modèle. Branchez l’alerte sur l’échec d’une question critique (consignation, sécurité) plutôt que sur une moyenne globale opaque. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
Corriger puis retester le sous-ensemble cassé
Ne relancez pas cent questions si cinq procédures critiques cassent. Corrigez le chunking, le nettoyage, ou la consigne système (« cite le passage ; si absent, dis-le »). Retestez d’abord le sous-ensemble en échec, puis une smoke suite élargie. Documentez ce qui a changé. La boucle courte bat le rapport mensuel oublié. Résistez à la tentation de changer modèle, chunks et consigne le même jour : vous ne sauriez plus quoi créditer. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
Décider du seuil de mise en service
Avec votre direction ou votre référent métier, définissez ce qui est acceptable pour une première mise en ligne : par exemple, aucune invention sur les procédures de sécurité, abstention correcte hors corpus, relecture humaine obligatoire sur les réponses publiées. Ce seuil est organisationnel, pas un chiffre magique. Sans seuil, l’évaluation reste un hobby technique. Écrivez le seuil dans la charte d’usage interne pour qu’un nouveau responsable methods n’ait pas à le réinventer sous pression. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
Ragas, script maison : comment choisir
Script maison
Idéal pour démarrer : CSV in/out, appels à votre API RAG, colonnes de verdict humain.
- Contrôle total sur le format et les critères métier HdF.
- Peu de dépendances ; lisible par un collègue non data scientist.
- Moins « automatique » sur la sémantique fine.
Ragas ou équivalent
Utile pour accélérer des jugements répétitifs une fois le protocole clair.
- Lisez la doc officielle pour installer et nommer les métriques du jour.
- Gardez un échantillon relu par un humain.
- Ne transformez pas un indicateur en vérité absolue.
Quel que soit l’outil, stockez les sorties : question, passages, réponse, verdict. Sans historique, vous ne verrez pas si la v2 a régressé. Prérequis Python : un environnement virtuel dédié, des dépendances listées dans un requirements, et des secrets hors dépôt. IAHDF n’est pas rémunéré par ces bibliothèques.
Boucle d’amélioration concrète
Chaque vague d’échecs doit produire un changement unique autant que possible : soit le corpus (ajout, OCR, nettoyage), soit le découpage, soit l’embedding, soit la consigne, soit le modèle de génération. Changer tout en même temps empêche d’apprendre. Après correction, rejouez le jeu gelé. Si une question devient ambiguë, corrigez le jeu — c’est aussi une amélioration.
Pour le français, surveillez les synonymes métier (« EPI », « équipement de protection ») et les intitulés de documents proches. Un embedding mal adapté peut rapprocher les mauvais chapitres : croisez embeddings RAG français. Pour Open WebUI, ajustez aussi les paramètres décrits dans réglages RAG.
Scènes Hauts-de-France
PME mécanique près de Valenciennes : le RAG indexe des modes opératoires. Le jeu de test inclut « consignation presse 3 » et une question hors corpus sur un fournisseur. L’échec fréquent : réponse confiante sans passage. Correctif : consigne d’abstention + chunk qui garde le titre de procédure avec le paragraphe.
Association culturelle à Amiens : règlement intérieur et chartes bénévoles. Le jeu mélange questions de remboursement et questions inventées sur un « forfait kilometrique régional » absent. Le succès se mesure aussi à la capacité de dire non. Un cabinet comptable à Lille peut appliquer la même méthode sur une base de procédures internes anonymisées — jamais sur des dossiers clients nominatifs dans un outil mal cadré.
Pièges fréquents
- Évaluer seulement les questions de la démo commerciale.
- Confondre style fluide et exactitude.
- Modifier le corpus pendant le test.
- Ignorer les questions hors corpus.
- Publier un pourcentage sans expliquer l’échantillon.
- Oublier que l’OCR pourri fausse tout le reste.
Le dernier piège : croire que l’évaluation est finie. Chaque ajout de document, chaque nouveau modèle, chaque changement de chunking mérite au moins la smoke suite. Planifiez-la comme une tâche d’équipe, pas comme un exploit ponctuel.
Exemple de session d’évaluation
Imaginez une demi-journée à Valenciennes. Le matin, vous gelez le corpus (plusieurs dizaines de PDF de procédures), notez le tag du modèle Ollama copié sur la doc officielle, et chargez le CSV de questions. Vous lancez le script qui enregistre réponses et passages. L’après-midi, le responsable methods et vous parcourez uniquement les échecs : retrieval partiels, inventions, abstentions manquées. Vous corrigez des titres de chunks et la consigne, puis vous rejouez les questions concernées. Celles qui restent rouges peuvent attendre un OCR — voir le tutoriel dédié. Vous documentez le seuil : pas de mise en service sur les procédures de sécurité tant que les cas critiques restent non fiables.
Le lendemain, vous présentez à la direction trois situations sans pourcentages magiques : une réussite avec citation, un échec corrigé, une abstention. La décision de pilote interne est prise. La bascule vers tous les salariés attend encore la charte et les groupes Open WebUI. L’évaluation a servi à décider, pas à décorer un diaporama.
Métriques automatiques : mode d’emploi prudent
Si vous branchez Ragas ou un juge LLM, isolez clairement ce qui est automatisé. Une métrique de fidélité approximative peut prioriser les relectures humaines ; elle ne signe pas la conformité métier. Calibrez sur un lot de questions déjà jugées à la main : si l’outil contredit systématiquement le métier, baissez sa priorité. Versionnez les prompts de juge comme le reste du code. Refusez d’afficher un seul chiffre agrégé en comité sans la taille de l’échantillon et la date du corpus gelé.
Les bibliothèques évoluent. Avant chaque upgrade, relisez la liste des métriques dans la documentation officielle et adaptez votre script. IAHDF ne cautionne aucun score publié hors de votre protocole. Votre vérité terrain en Hauts-de-France prime toujours sur un indicateur importé.
Questions fréquentes
Combien de questions faut-il pour « être sérieux » ?
Assez pour couvrir vos risques métier, pas assez pour impressionner. Mieux vaut quelques dizaines de questions bien ancrées, avec pages sources et types variés, qu’une liste immense jamais relue. Enrichissez le jeu quand un incident réel apparaît. La sérieux vient du protocole et du gel de configuration, pas d’un volume annoncé en réunion. Enrichissez le jeu dès qu’un incident réel apparaît : c’est ainsi que le protocole reste vivant sans gonfler artificiellement le volume. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
Ragas est-il obligatoire ?
Non. Un tableur partagé et un script qui rejoue les questions suffisent pour démarrer. Ragas ou des outils voisins accélèrent certains jugements automatiques, à condition de lire leur documentation et de garder une relecture humaine. Choisissez selon vos compétences Python et votre besoin de non-régression, pas selon une mode. Un tableur partagé avec colonnes de verdict humain reste souvent plus honnête qu’une métrique mal comprise en réunion de direction. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
Que faire si le retrieval est bon mais la réponse invente ?
Serrez la consigne système : s’appuyer uniquement sur les extraits, citer, s’abstenir sinon. Réduisez la « créativité » du modèle si le réglage existe. Vérifiez que les chunks envoyés au modèle ne sont pas tronqués n’importe où. Changez éventuellement de modèle de génération en copiant le tag officiel — après avoir gelé le reste pour comparer. Si le passage est bon et la phrase fausse, le chantier est côté génération : consigne, température si exposée, ou modèle — un seul levier à la fois.
Comment parler de l’évaluation à une direction non technique ?
Montrez trois exemples : une réussite avec citation, un échec corrigé, une abstention correcte. Expliquez le seuil de mise en service en langage métier (sécurité, usagers, réputation). Évitez les pourcentages orphelins. Proposez un calendrier de retest après chaque vague documentaire. L’objectif est la confiance calibrée, pas la magie. Les trois exemples valent mieux qu’un tableau de pourcentages : la direction décide sur des cas, pas sur une illusion de précision. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
L’évaluation remplace-t-elle le RGPD ou la sécurité ?
Non. Elle mesure la qualité documentaire des réponses. Les questions de données personnelles, d’accès, d’hébergement et de mentions restent un chantier à part — voir aussi sécuriser Open WebUI et les données à ne pas confier. Un RAG fidèle sur un corpus qu’il ne devrait pas contenir reste un problème. Séparez explicitement les chantiers qualité documentaire et conformité des données : les mélanger produit des plans d’action illisibles. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.