Dans cet article
L’essentiel
Une démonstration convaincante ne prouve pas la fiabilité. Vérifiez que le système retrouve les preuves nécessaires, les utilise fidèlement et réagit correctement lorsqu’il ne peut pas répondre. Associez revue métier et scores automatisés.
Construire des cas capables de mettre le système en défaut
Partez des questions posées par les futurs utilisateurs. Pour chaque cas, consignez le rôle de l’utilisateur, la révision documentaire, les preuves nécessaires et le résultat acceptable. Certaines questions ne doivent avoir aucune réponse dans la collection. D’autres exigent une précision sur un produit, une date ou un territoire. Ce sont des cas utiles, pas des exceptions gênantes.
Séparez le jeu d’évaluation des exemples servant à ajuster les prompts. Incluez des versions concurrentes, des passages contradictoires et des noms de produits plausibles mais erronés. Pour un assistant de support interne, demandez au référent métier d’expliquer pourquoi une réponse est acceptable. Cette explication devient une grille réutilisable, plutôt qu’un jugement vague selon lequel la réponse « semble bonne ».
Évaluer séparément recherche et génération
Ragas répertorie notamment précision du contexte, rappel du contexte, pertinence de la réponse et fidélité aux sources. Ces dimensions sont utiles pour organiser une évaluation. Dans la revue proposée, vérifiez d’abord que les passages nécessaires ont été retrouvés. Vérifiez ensuite que la réponse les utilise correctement et répond à la question. Un score global unique rend ces défauts distincts plus difficiles à diagnostiquer.
Les évaluateurs automatiques apportent des indices, pas une autorité finale. Examinez leurs désaccords avec les relecteurs, notamment sur le vocabulaire métier et les questions françaises. Conservez les versions du modèle évaluateur et de la grille pour ne pas confondre un changement de notation avec un progrès applicatif. Si les résultats sont proches, relisez les échecs plutôt que de surinterpréter une faible différence.
Trois contrôles avant de valider une réponse
Isoler la cause d’une erreur avant de modifier le système.
La preuve a-t-elle été retrouvée ?
Examiner les passages sélectionnés et les sources manquantes.
La réponse respecte-t-elle les preuves ?
Vérifier les affirmations et les passages cités pour les soutenir.
Le résultat est-il utile ?
Relire la réponse, la clarification ou le transfert avec le référent métier.
Contrôler explicitement citations, refus et droits
Une citation est utile si le passage soutient l’affirmation associée et si le lecteur peut le consulter. Testez les liens cassés, les documents supprimés et les réponses issues de plusieurs sources. Nous recommandons de distinguer affirmations factuelles non étayées et défauts de style. Une réponse élégante qui invente une condition d’éligibilité doit échouer à la revue.
Ajoutez des tests portant sur des informations absentes et des documents hors des droits de l’utilisateur. Testez aussi des instructions hostiles intégrées à un document : le contenu retrouvé constitue une preuve à examiner, pas une autorité pouvant modifier les règles applicatives. Définissez le résultat attendu, y compris abstention, clarification ou transfert. Ne récompensez pas l’assistant uniquement parce qu’il répond toujours.
Intégrer l’évaluation à chaque livraison
Relancez la même comparaison après modification du modèle, des embeddings, du découpage, des filtres ou de la collection. Gardez une référence et analysez les différences par catégorie de question. Sur un processus important, une régression des droits doit bloquer la livraison même si la qualité moyenne progresse. Fixez les critères d’acceptation avec le responsable métier avant de consulter les résultats.
En production, associez revue humaine par échantillonnage et mesures d’exploitation : délai de réponse, échecs d’ingestion, signalements de réponses non étayées et coût par tâche terminée. Évitez de conserver des conversations sensibles simplement parce qu’un tableau de bord le facilite. Une livraison utile inclut rapport d’évaluation, exemples d’échecs et procédure de récupération. Le progrès devient ainsi observable et réversible.
Construire un cas de test qu’un collègue peut relire
Pour chaque cas, conservez question, profil d’accès, révision applicable et comportement attendu. « Réponse correcte » est trop vague. Pour une politique, indiquez affirmation nécessaire et passage justificatif. Pour une source interdite, exigez l’absence de passage ou titre confidentiel. Pour une question sans réponse, précisez clarification ou transmission attendue.
Séparez ce jeu de référence des exemples utilisés pour ajuster les consignes. Incluez demandes ordinaires et cas difficiles, avec la raison de chaque test. En cas d’échec, conservez résultats de recherche et réponse selon une politique de conservation adaptée. Les personnes disposent ainsi de preuves plutôt que d’un score rouge impossible à expliquer.
Un petit registre d’évaluation
Exemple de conception de tests. Les résultats attendus doivent être relus par le responsable documentaire.
Faites défiler horizontalement pour lire le tableau →
| Cas | Résultat attendu | Preuve à examiner |
|---|---|---|
| Politique connue, utilisateur autorisé | Réponse sourcée et révision applicable | Affirmation et passage justificatif |
| Aucune politique applicable | Précision ou transmission explicite | Aucune règle inventée |
| Source restreinte | Aucun contenu ni titre confidentiel | Recherche, réponse, liens et caches |
| Révisions contradictoires | Contradiction rendue visible | Dates applicables et responsables |
Lire le score avec son dénominateur et ses conséquences
Un résultat fictif de 18 réponses correctes sur 24 cas signifie six échecs ; il n’établit pas un taux de réussite en production. Examinez s’il s’agit de différences de rédaction, d’affirmations sans preuve ou de violations d’accès. Répétez les cas variables et indiquez la composition de l’échantillon pour ne pas masquer une catégorie critique derrière des questions faciles.
Les métriques automatiques servent à repérer les problèmes et prioriser la revue ; confrontez-les au jugement humain sur des réponses représentatives. Une règle de livraison peut bloquer toute violation d’accès observée tout en évaluant séparément pertinence et utilité. Élargissez progressivement et réintégrez les échecs réels après examen. Les tests éclairent une livraison, sans remplacer l’observation du service utilisé.
Sources et lectures complémentaires
Documentation consultée le .
FAQ / DÉCISIONS
Questions fréquentes
Existe-t-il un score cible universel pour un RAG en production ?+
Non. Un assistant de rédaction et un assistant de procédures n’ont pas les mêmes conséquences en cas d’erreur. Définissez les seuils par type d’échec et impact métier, puis examinez les cas concernés.
Un modèle évaluateur peut-il remplacer la revue humaine ?+
Il peut faciliter le tri à grande échelle, mais ses décisions doivent être comparées à une revue experte. Conservez une intervention humaine sur les cas ambigus, sensibles ou à fort impact.