Votre application RAG peut-elle ingérer les documents que vous utilisez réellement ? Liste de contrôle pour l’évaluer
Une liste de types de fichiers ne permet pas de savoir si une application RAG extrait correctement les documents que vous utilisez réellement. Constituez un jeu de test représentatif, examinez le contenu ingéré et vérifiez la gestion des mises à jour, des suppressions et des échecs.
Pourquoi la prise en charge annoncée des formats de fichiers ne suffit pas
Une liste de compatibilité répond à une question précise : l’application peut-elle accepter un fichier portant une extension particulière ? Elle ne vous indique pas si le contenu dont votre équipe a besoin sera extrait intégralement et sous une forme exploitable par l’application.
Un PDF peut contenir du texte sélectionnable, des images de pages numérisées, des tableaux complexes ou un mélange de ces éléments. Deux fichiers portant la même extension peuvent donc donner lieu à des tests d’ingestion très différents. Considérez la mention « pris en charge » comme une raison de tester un format, et non comme la preuve que vos documents sont prêts à être utilisés pour la recherche.
Concentrez cette évaluation sur le processus d’ingestion : quels contenus et métadonnées entrent dans le système, ce qui est omis ou modifié, et ce qui se passe lorsque les fichiers sources changent. Évaluez séparément la qualité des réponses et l’attribution des sources.
- Testez de vrais documents issus des équipes et des référentiels que vous prévoyez d’utiliser.
- Distinguez « téléversement accepté » et « contenu correctement extrait ».
- Indiquez pour chaque test s’il porte sur l’acceptation du fichier, l’extraction, les métadonnées ou la gestion du cycle de vie du fichier.
Constituez un petit jeu de test représentatif
Commencez par un petit échantillon représentatif des sources de vos documents, plutôt que par une vaste collection de fichiers d’exemple faciles à trouver. Incluez des exemples ordinaires, mais aussi les fichiers difficiles sur lesquels le personnel s’appuie réellement. Un jeu de test ciblé facilite l’examen des résultats et la répétition des mêmes vérifications après une modification de configuration.
Incluez des documents de structures et d’origines variées. Pour les pages numérisées, utilisez des fichiers dont le texte n’existe que sous forme d’image. Pour les tableaux, choisissez des exemples où le lien entre les en-têtes, les lignes et les valeurs est important. Incluez des documents longs et des documents comportant plusieurs sections, afin de vérifier si du contenu est perdu ou présenté dans un ordre inattendu.
Conservez un inventaire simple avec les fichiers. Pour chacun, indiquez le contenu attendu, les champs importants, la langue, la structure et les particularités connues. Les personnes chargées de la vérification disposeront ainsi d’un point de référence pour examiner le résultat ingéré.
- Des fichiers courants provenant de chaque source importante et correspondant aux types de fichiers les plus fréquents.
- Des pages numérisées, des documents riches en images et des PDF mêlant texte et images.
- Des tableaux, des formulaires, des en-têtes, des pieds de page, des mises en page sur plusieurs colonnes et des documents avec des listes.
- Des documents courts et longs, notamment des exemples comportant plusieurs sections.
- Les langues, conventions de nommage et modèles de métadonnées présents dans votre véritable collection.
Vérifiez la qualité de l’extraction : texte, structure, métadonnées et OCR
Pour chaque fichier de test, comparez le contenu ingéré au document d’origine. Vérifiez que les textes importants sont présents, que l’ordre de lecture est logique et que les titres et les limites entre les sections restent reconnaissables. Examinez attentivement les valeurs dont le sens dépend des libellés voisins, comme une donnée de tableau placée sous un en-tête de colonne précis.
Pour les documents numérisés, vérifiez si le texte est extrait et si des erreurs de reconnaissance modifient les noms, les dates, les identifiants ou les chiffres. Ne partez pas du principe qu’un téléversement réussi implique que l’OCR a été effectué. Vérifiez-le dans la documentation de l’application ou en inspectant le contenu obtenu.
Vérifiez les métadonnées séparément du corps du texte. Selon votre cas d’utilisation, les champs utiles peuvent inclure le nom du fichier, son emplacement source, la date du document, la langue ou un identifiant interne. Déterminez quels champs sont conservés, lesquels peuvent être renseignés ou modifiés et lesquels ne sont pas disponibles. Ne supposez pas qu’un champ est conservé simplement parce qu’il apparaît dans les propriétés du fichier d’origine.
- Pouvez-vous examiner ou exporter le contenu extrait d’un fichier de test ?
- Les paragraphes importants sont-ils présents, lisibles et dans un ordre logique ?
- Les en-têtes de tableau restent-ils associés aux bonnes valeurs ?
- L’OCR reconnaît-il les noms, les dates, les nombres et les identifiants critiques avec une précision suffisante pour votre usage ?
- Quels champs de métadonnées sont conservés après l’ingestion, et pouvez-vous ensuite distinguer les fichiers similaires ?
Testez les doublons, les mises à jour et les suppressions
Les collections de documents évoluent. Testez explicitement le cycle de vie des fichiers au lieu de considérer l’ingestion comme un téléversement ponctuel. Utilisez une copie de test sans risque et notez ce que l’application affiche avant et après chaque action.
Essayez d’ingérer deux fois le même fichier, puis testez deux fichiers différents portant des noms similaires ou dont le contenu se recoupe. L’application peut traiter ces situations différemment ; votre objectif est d’établir son comportement, et non de supposer que les doublons sont détectés ou fusionnés.
Modifiez ensuite une phrase ou une valeur distinctive dans un document de test et ingérez le fichier révisé. Vérifiez si l’ancien contenu reste présent, si le nouveau apparaît et si vous pouvez identifier la version active. Enfin, supprimez le fichier source selon la procédure documentée et vérifiez si le contenu ingéré est également supprimé ou traité comme l’exige votre politique.
- Téléversez deux fois exactement le même fichier et notez si cela crée un ou plusieurs éléments ingérés.
- Testez un fichier révisé portant le même nom, puis un fichier révisé portant un nom différent.
- Vérifiez comment l’application distingue deux documents aux noms similaires.
- Après une mise à jour, vérifiez que l’ancien texte ne subsiste pas de manière inattendue à côté du nouveau.
- Après une suppression, vérifiez ce qu’il advient du contenu ingéré et des métadonnées associées.
Observez les échecs, les nouvelles tentatives et les traitements partiels
Incluez au moins un fichier susceptible de poser problème, comme un fichier endommagé ou une variante inattendue d’un format courant, si vous pouvez le faire sans risque. Observez l’ensemble du processus au lieu de vérifier uniquement si l’écran de téléversement a accepté le fichier.
Notez ce que l’application affiche lorsque l’ingestion échoue ou semble incomplète. Les indicateurs utiles peuvent inclure un statut, un message d’erreur, une entrée de journal ou un signal indiquant que le traitement est toujours en cours ; leur disponibilité et leur niveau de détail varient selon l’application. Vérifiez donc leur présence lors d’un test au lieu de supposer qu’ils existent.
Si l’application propose une nouvelle tentative ou une action de retraitement, testez-la sur une copie et notez si elle reprend le traitement, le recommence depuis le début ou crée un second élément. Déterminez également si un traitement par lot peut réussir partiellement et comment repérer les fichiers nécessitant une intervention.
- Pouvez-vous distinguer les éléments en file d’attente, en cours de traitement, terminés et en échec, si ces statuts sont disponibles ?
- Le message d’erreur identifie-t-il le fichier et fournit-il assez de détails pour décider de la suite ?
- Pouvez-vous relancer le traitement d’un élément en échec, et le résultat est-il clair ?
- Si un traitement par lot n’aboutit que partiellement, pouvez-vous repérer les fichiers traités et ceux qui ne le sont pas ?
- Les administrateurs peuvent-ils consulter les journaux pertinents ou d’autres informations de diagnostic ?
Comparez le contenu extrait avant d’évaluer la recherche
Lorsqu’un résultat de recherche semble incorrect, la cause peut être un problème d’ingestion, un problème de configuration de la recherche ou autre chose. Examiner d’abord le contenu ingéré aide à distinguer ces possibilités. Si un paragraphe important ou une valeur de tableau n’a jamais été intégré au contenu indexé, modifier les paramètres de réponse ne fera pas réapparaître le texte source manquant.
Pour chaque document de test, sélectionnez à l’avance quelques passages ou valeurs distinctifs. Après l’ingestion, recherchez ces éléments dans le contenu extrait ou dans le mécanisme d’inspection le plus proche proposé par l’application. Notez les omissions, les textes dupliqués, les problèmes d’ordre de lecture et les caractères modifiés.
Le tutoriel LangChain sur [l’évaluation d’une application RAG](https://docs.langchain.com/langsmith/evaluate-rag-tutorial) explique comment créer des jeux de données de test et y exécuter une application RAG. Ce type d’évaluation est distinct de la vérification de la façon dont une application particulière analyse les documents ou gère les modifications de fichiers. Faites donc de l’ingestion une étape de test à part entière.
- Avant le téléversement, établissez pour chaque fichier d’exemple une courte liste du contenu attendu.
- Comparez le contenu source au contenu extrait avant de lancer les tests de recherche ou de réponse.
- Consignez séparément les défauts d’extraction et les défauts de recherche ou de réponse.
- Si le contenu extrait n’est pas consultable, demandez au fournisseur quels éléments de preuve ou quelles méthodes de diagnostic sont disponibles.
Consignez les résultats et définissez des critères d’acceptation
Un compte rendu d’évaluation utile est succinct, mais reproductible. Pour chaque fichier, notez sa source, son format, ses caractéristiques pertinentes, le résultat de l’ingestion, vos observations sur l’extraction, le résultat concernant les métadonnées, les tests du cycle de vie et les solutions de contournement éventuelles. Consignez également la configuration de l’application et la date du test afin de pouvoir comparer équitablement avec un essai ultérieur.
Définissez des critères d’acceptation en fonction de vos risques réels. Par exemple, une équipe peut exiger la conservation exacte de certains identifiants, l’extraction d’un texte exploitable à partir d’une catégorie définie de pages numérisées ou une procédure claire de suppression du contenu lorsqu’un fichier source est supprimé. Énoncez explicitement le niveau attendu au lieu de qualifier simplement un résultat d’ingestion de « bon » ou de « mauvais ».
Décidez de la marche à suivre lorsqu’un fichier ne réussit pas le test. Vous pourriez exclure cette source, préparer une copie normalisée, ajouter une étape de vérification manuelle ou choisir une autre application. Si une solution de contournement est nécessaire, indiquez qui en est responsable et comment elle sera maintenue.
- Fichier de test et source
- Contenu et métadonnées attendus
- Résultat de l’extraction et omissions ou déformations éventuelles
- Comportement des doublons, des mises à jour et des suppressions
- Visibilité des échecs, résultat des nouvelles tentatives et intervention manuelle
- Réussite, réussite sous conditions ou échec au regard d’une exigence écrite
Questions à vérifier dans la documentation ou par un test direct
Le comportement d’ingestion dépend de l’application. Consultez la documentation officielle à jour et confirmez les exigences importantes avec votre propre jeu de test.
Ne vous contentez pas de demander quels formats sont répertoriés : renseignez-vous sur les traitements effectués et leurs limites. Vérifiez si l’OCR est disponible, s’il s’exécute dans votre environnement ou s’il fait appel à un service externe, et quelles données peuvent être envoyées en dehors de votre déploiement. Ne déduisez pas ces détails d’une simple liste de formats.
Pour les déploiements auto-hébergés, le fait d’héberger vous-même l’application ne résout pas automatiquement toutes les questions relatives au traitement des données. Vérifiez le processus de traitement et ses dépendances, puis prenez des décisions concernant l’accès, la conservation et la gouvernance adaptées à votre organisation.
- Quels types de fichiers et quelles structures de documents précises sont indiqués comme pris en charge dans la documentation ?
- Existe-t-il des limites concernant la taille des fichiers, le nombre de pages, la taille des lots, le temps de traitement ou la taille de la collection ?
- L’OCR est-il inclus, facultatif ou dépendant d’un autre composant ou service ?
- L’analyse, l’OCR ou un autre traitement envoie-t-il le contenu des documents vers un service externe ?
- Pouvez-vous examiner le texte extrait et les métadonnées, et quelles informations de diagnostic sont disponibles ?
- Que conserve l’application après la suppression d’un fichier source, et quelles étapes faut-il suivre pour supprimer ces données ?
Questions fréquentes
Quelle est la différence entre la prise en charge d’un format de fichier et l’ingestion réussie d’un document ?
La prise en charge d’un format indique généralement que l’application accepte ce type de fichier. Une ingestion réussie signifie que le contenu et la structure pertinente dont votre équipe a besoin ont été extraits et rendus exploitables. Testez ces deux aspects avec des exemples réels, y compris des documents difficiles.
Combien de documents un jeu de test d’ingestion RAG doit-il contenir ?
Il n’existe pas de nombre universel. Commencez par un échantillon de taille raisonnable qui couvre les sources, les formats, les langues et les cas limites importants de votre collection. L’objectif est d’obtenir une couverture représentative et de procéder à un examen attentif, et non de constituer un vaste échantillon pour lui-même.
Comment tester l’OCR sans confondre l’ingestion avec la qualité des réponses ?
Choisissez des pages numérisées et établissez une courte liste des noms, dates, chiffres ou expressions attendus. Examinez le contenu extrait, s’il est disponible, ou utilisez la méthode de diagnostic indiquée par le fournisseur. Vérifiez directement la reconnaissance avant d’évaluer les résultats de recherche ou les réponses générées.
Dois-je supposer qu’un fichier source mis à jour ou supprimé met automatiquement à jour le contenu ingéré ?
Non. Le comportement peut varier selon l’application et sa configuration. Testez les fichiers révisés et supprimés en suivant la procédure documentée, puis vérifiez ce qu’il advient du contenu ingéré avant de vous y fier pour des informations importantes.
L’auto-hébergement garantit-il que le traitement des documents reste dans mon environnement ?
L’auto-hébergement seul ne permet pas de tirer cette conclusion. Vérifiez si l’analyse, l’OCR ou d’autres traitements dépendent de services externes, et confirmez quelles données des documents sont envoyées et conservées.
Sources et lectures complémentaires
- Evaluate a RAG application — LangChain
- A complete guide to RAG evaluation — Evidently AI