L’évaluation du RAG doit vérifier comment les documents récupérés façonnent les réponses
Un système d’IA peut avoir à disposition le bon état financier et pourtant répondre à partir d’un état d’une autre année. Cela crée un problème d’évaluation pour les équipes qui développent des systèmes de retrieval-augmented generation, ou RAG, qui récupèrent des documents qu’un modèle utilise ensuite pour répondre. Confirmer que le fichier visé est bien parvenu au modèle permet d’établir l’accès. Les équipes doivent aussi vérifier la fidélité à la source : si la réponse reflète bien l’enregistrement visé.
L’étude de Seekr sur la manière dont les grands modèles de langage utilisent les documents récupérés examine cet écart. L’entreprise a constaté que des enregistrements presque identiques peuvent entrer en concurrence pour façonner une réponse, produisant une réponse claire et assurée fondée sur la mauvaise version. Seekr a un intérêt commercial à ce que les entreprises investissent dans l’IA et son évaluation ; les lecteurs doivent donc apprécier ses constats et ses recommandations en gardant cet intérêt à l’esprit.
Seekr a testé deux modèles dans trois conditions documentaires
Pour examiner comment des enregistrements similaires influencent les réponses, Seekr a utilisé dans son étude des états financiers du Trésor US, publiée sous le titre « Study finds AI can use wrong document despite retrieval. » Seekr a choisi ces états parce qu’ils sont publics, permettent de vérifier les réponses de manière objective et ressemblent à des enregistrements étroitement liés dans des collections d’entreprise et d’administration. Ben Faircloth, l’auteur de l’article et responsable de la stratégie et de la recherche en IA chez Seekr, était indiqué dans l’annonce de l’entreprise comme disponible pour discuter de la méthodologie.
À partir de ces états, Seekr a constitué 80 questions et testé Llama-3.3-70B et Qwen2.5-72B, désignés ici par Llama et Qwen. Chaque modèle a été confronté à trois conditions documentaires : l’état correct seul ; cet état accompagné d’états similaires d’autres années ; et un paramétrage de retrieval plus large recherchant dans l’ensemble des états. Cela a permis à Seekr de comparer une tâche simple d’utilisation de document avec des conditions dans lesquelles des enregistrements concurrents pouvaient influencer la sélection ou la réponse.
Pour distinguer ces effets, Seekr a mesuré l’exactitude des réponses et utilisé l’attribution, une méthode permettant de suivre quel document a façonné une réponse. L’exactitude indiquait si la réponse était correcte, tandis que l’attribution aidait à repérer les cas où un enregistrement concurrent l’avait influencée. Ensemble, ces mesures ont permis à Seekr d’étudier les défaillances pendant le retrieval et les défaillances après que le document visé a atteint le modèle.
Un projet en tête ?
Planifiez un appel de 30 minutes avec nous.
Des experts senior pour vous aider à avancer plus vite : produit, tech, cloud & IA.
Des états similaires ont réduit l’exactitude alors que l’enregistrement correct restait disponible
La première condition a établi comment les modèles se comportaient avec le seul état visé. Seekr a indiqué une exactitude de 95,0 % pour Llama et de 92,5 % pour Qwen, montrant que les deux répondaient correctement à la plupart des questions. Ces résultats ont fourni la référence pour mesurer ce qui changeait lorsque des enregistrements similaires apparaissaient à côté du bon.
L’ajout d’états d’autres années a réduit l’exactitude alors même que l’enregistrement visé restait disponible. Seekr a indiqué que l’exactitude de Llama tombait à 85,0 %, tandis que celle de Qwen tombait à 87,5 %. L’entreprise a décrit ce recul comme une baisse de 5 à 10 points de pourcentage dans une condition où le retrieval avait déjà réussi. L’exactitude a baissé pour les deux familles de modèles, mais dans des proportions différentes.
Comme l’état correct était présent dans les deux conditions, son absence ne peut pas expliquer cette baisse. Une vérification de l’accès au document aurait été validée dans chaque cas, et pourtant les réponses sont devenues moins exactes lorsque des états concurrents ont été ajoutés. La comparaison contrôlée établit donc un risque de réponses incorrectes après un retrieval réussi, tout en laissant la cause de chaque erreur à des investigations complémentaires.
L’attribution a aidé Seekr à examiner ces causes en repérant les cas où un modèle semblait s’appuyer sur un document concurrent alors qu’il avait bien le bon à disposition. Un état d’une autre année peut contenir des informations financières plausibles tout en décrivant la mauvaise période de reporting. Cela explique comment une réponse peut rester fluide tout en s’appuyant sur un enregistrement inadapté, sans supposer que toutes les erreurs de la deuxième condition avaient la même cause.
Un retrieval plus large a introduit un problème plus important de sélection d’enregistrement
La comparaison contrôlée maintenait l’état visé disponible, mais la condition de retrieval plus large obligeait d’abord le système à le trouver. Lorsque le système recherchait dans l’ensemble des états, Seekr a indiqué une exactitude sur les questions ayant reçu une réponse de 37,1 % pour Llama et de 30,4 % pour Qwen. Seekr a attribué l’essentiel de l’écart de performance sur l’ensemble du pipeline, c’est-à-dire la baisse observée entre la récupération des documents et la génération de la réponse, au fait que le retrieval sélectionnait le mauvais enregistrement. La sélection d’enregistrement était donc le principal problème signalé dans ce paramétrage.
Comme la condition plus large combinait retrieval et réponse, ses chiffres ne peuvent pas mesurer directement la confusion après un retrieval réussi. Une erreur peut commencer lorsque le système sélectionne un enregistrement ou survenir plus tard lorsque le modèle utilise les éléments disponibles. La deuxième condition isolait plus clairement ce second risque en maintenant l’état correct présent ; les comparaisons aident donc à diagnostiquer des problèmes différents.
Cette distinction compte lorsqu’il s’agit de décider quoi améliorer. Seekr soutient qu’un score de réponse juste ou fausse ne permet pas d’établir si une erreur provient du retrieval, du raisonnement ou de l’appui sur le mauvais document parmi des enregistrements similaires. Chaque explication renvoie à une partie différente du système à examiner. Améliorer le retrieval traite le principal problème signalé dans le test plus large, tandis que les résultats contrôlés donnent aux équipes une raison distincte d’examiner comment les modèles utilisent les documents qu’ils ont déjà.
L’évaluation doit suivre l’accès, l’usage de la source et l’exactitude
Pour étudier ces différentes façons dont un système peut échouer, les équipes d’ingénierie peuvent poser trois questions : l’enregistrement visé a-t-il été récupéré ? La réponse reflète-t-elle cet enregistrement ? La réponse est-elle correcte ? Garder ces questions séparées permet de préserver des éléments probants sur l’endroit où la défaillance s’est produite.
Séparer ces vérifications prolonge l’évaluation centrée sur l’exactitude que, selon Seekr, de nombreuses entreprises ont utilisée pour les systèmes d’IA. L’exactitude établit si une réponse est juste, tandis qu’une vérification du retrieval établit si le contenu visé était disponible. L’attribution peut ensuite aider à examiner quel contenu a façonné la réponse. Consigner séparément ces observations aide les évaluateurs à distinguer une erreur de sélection d’une erreur d’usage de la source ou d’une erreur de raisonnement.
Ces distinctions deviennent plus nettes dans des collections comportant plusieurs versions d’un enregistrement. Seekr situe le problème dans l’évaluation des systèmes utilisant des données propriétaires ou réglementées, en particulier dans la finance, le juridique, la conformité et le secteur public. De telles collections peuvent ressembler aux documents du Trésor, car des documents étroitement liés contiennent de petites différences qui déterminent quelle réponse correspond à la question. Le test pertinent consiste à vérifier si la réponse utilise la révision ou la période de reporting visée.
Pour une équipe juridique, cela peut signifier distinguer des révisions de contrat et des contrats modifiés ; pour une équipe financière, cela peut signifier distinguer des dépôts trimestriels, des dépôts mis à jour et des états annuels. Les équipes gouvernementales et de conformité font face à un problème similaire avec les documents réglementaires. Lorsque ces enregistrements coexistent, une évaluation doit identifier la version visée et examiner si la réponse la reflète, car des informations plausibles provenant d’un document voisin peuvent malgré tout répondre à la mauvaise question.
Points clés à retenir pour les décideurs
- Tester des versions concurrentes de documents : Seekr a testé deux modèles sur 80 questions dans trois conditions documentaires. Les responsables de l’évaluation de l’IA peuvent utiliser cette structure pour comparer les performances avec le seul enregistrement visé, avec des enregistrements similaires à ses côtés et dans un pipeline de retrieval plus large.
- Vérifier quelle source façonne la réponse : L’ajout d’états similaires a réduit l’exactitude de 5 à 10 points de pourcentage alors même que l’enregistrement correct restait disponible. Les équipes d’ingénierie ont besoin de vérifications de l’usage de la source pour repérer quand des versions concurrentes influencent les réponses.
- Donner la priorité à la sélection d’enregistrement dans le retrieval : L’exactitude sur les questions ayant reçu une réponse est tombée à 37,1 % pour Llama et à 30,4 % pour Qwen dans le test de retrieval plus large. Seekr a attribué l’essentiel de cet écart de performance à la sélection du mauvais enregistrement, ce qui fait de la sélection dans le retrieval le premier domaine à examiner dans ce paramétrage.
- Séparer les signaux d’évaluation : Les équipes plateforme ont besoin de vérifications distinctes pour la récupération de l’enregistrement visé, l’usage de la source et l’exactitude de la réponse. Consigner ces signaux séparément aide à déterminer si les améliorations relèvent du retrieval, du traitement des documents ou du raisonnement.
Un projet en tête ?
Planifiez un appel de 30 minutes avec nous.
Des experts senior pour vous aider à avancer plus vite : produit, tech, cloud & IA.
