Évaluation de bout en bout du modèle de langage volumineux
Dans cette phase, vous évaluez votre solution Retrieval-Augmented Generation (RAG) en examinant les invites utilisateur attendues qui contiennent les données de base récupérées par rapport au modèle de langage. Avant d’atteindre cette phase, vous devez effectuer les phases précédentes. Vous devez collecter vos documents et requêtes de test, segmenter vos documents de test, enrichir les blocs, incorporer les blocs, créer un index de recherche et implémenter une stratégie de recherche. Ensuite, vous devez évaluer chacune de ces phases et vous assurer que les résultats répondent à vos attentes. À ce stade, vous devez être sûr que votre solution retourne des données de base pertinentes pour une requête utilisateur.
Ces données de base forment le contexte de l’invite que vous envoyez au modèle de langage pour traiter la requête de l’utilisateur. Les stratégies d'ingénierie de la requête sortent de l'étendue de cet article. Cet article traite de l'évaluation de l'appel généré au modèle de langage du point de vue des données de référence. Cet article traite des métriques d’évaluation des modèles de langage courants et des métriques de similarité et d’évaluation spécifiques que vous pouvez utiliser dans les calculs d’évaluation du modèle ou en tant que métriques autonomes.
Cet article ne tente pas de fournir une liste exhaustive de métriques de modèle de langage ou de métriques de similarité et d’évaluation. Ce qui est important pour vous de retirer de cet article est qu’il existe différentes métriques qui ont chacun des cas d’usage distincts. Vous n’avez qu’une compréhension holistique de votre charge de travail. Vous et vos scientifiques des données devez déterminer ce que vous souhaitez mesurer et quelles métriques sont appropriées.
Cet article fait partie d’une série. Lisez d’abord l’introduction .
Métriques d’évaluation du modèle de langage
Il existe plusieurs métriques que vous devez utiliser pour évaluer la réponse du modèle de langage, notamment l’importance, l’exhaustivité, l’utilisation, la pertinence et la justesse du modèle de langage. Étant donné que l’objectif global du modèle RAG est de fournir des données pertinentes en tant que contexte à un modèle de langage lors de la génération d’une réponse, idéalement, chacune des métriques ci-dessus doit noter fortement. Toutefois, selon votre charge de travail, vous devrez peut-être hiérarchiser l’un par rapport à l’autre.
Important
Les réponses du modèle de langage sont non déterministes, ce qui signifie que la même invite à un modèle de langage retourne souvent des résultats différents. Ce concept est important de comprendre quand vous utilisez un modèle de langage dans le cadre de votre processus d’évaluation. Envisagez d’utiliser une plage cible au lieu d’une seule cible lorsque vous évaluez l’utilisation du modèle de langage.
Fondement
L'ancrage, parfois appelé fidélité, mesure si la réponse est entièrement basée sur le contexte. Elle vérifie que la réponse n’utilise pas d’informations autres que celles qui existent dans le contexte. Une métrique de faible ancrage indique que le modèle de langage peut sortir des réponses inexactes ou absurdes.
Calculer le groundedness
Utilisez les méthodes suivantes pour calculer la base des réponses :
- Le groundedness basé sur Azure AI Content Safety est un modèle personnalisé qui utilise l'inférence du langage naturel pour déterminer si les affirmations, ou dans ce cas les segments, sont basées sur le contexte dans le document source.
- Le groundedness basé sur un grand modèle de langage utilise un modèle de langage pour déterminer le niveau de groundedness de la réponse.
- Bibliothèque de fidélité Ragas.
- Calcul de fidélité MLflow.
Évaluer la pertinence
Un calcul de faible ancrage indique que le modèle de langage ne considère pas les segments comme pertinents. Vous devez évaluer si vous avez besoin d'ajouter des données à votre collection, d'ajuster votre stratégie de découpage en segments ou la taille des segments, ou d'affiner votre requête.
Complétude
Completeness mesure si la réponse répond à toutes les parties de la requête. L’exhaustivité vous aide à comprendre si les blocs dans le contexte sont pertinents, directement liés à la requête et fournissent une réponse complète.
Calcul de l'exhaustivité
Utilisez les méthodes suivantes pour calculer l’exhaustivité des réponses :
- Les requêtes de score de récupération assistée par l'IA.
- Un modèle de langage peut vous aider à mesurer la qualité de la réponse du modèle de langage. Vous avez besoin de la question, du contexte et de la réponse générée pour prendre cette mesure. Les étapes suivantes décrivent le processus de haut niveau :
- Utilisez le modèle de langage pour reformuler, résumer ou simplifier la question. Cette étape identifie l’intention.
- Demandez au modèle de vérifier si l’intention ou la réponse à l’intention est trouvée ou peut être dérivée des documents récupérés. La réponse peut être « oui » ou « non » pour chaque document. Les réponses qui commencent par « oui » indiquent que les documents récupérés sont pertinents pour l’intention ou la réponse à l’intention.
- Calculez le ratio des intentions qui ont une réponse commençant par « oui ».
- Carré le score pour mettre en évidence les erreurs.
Évaluer l’exhaustivité
Si l’exhaustivité est faible, commencez à l’augmenter en évaluant votre modèle d’incorporation. Comparez le vocabulaire de votre contenu au vocabulaire de votre modèle d’incorporation. Déterminez si vous avez besoin d’un modèle d’incorporation spécifique à un domaine ou si vous devez affiner un modèle existant. L’étape suivante consiste à évaluer votre stratégie de segmentation. Si vous utilisez un découpage de taille fixe, envisagez d’augmenter la taille de votre morceau. Vous pouvez également évaluer si vos données de test disposent de suffisamment de données pour répondre complètement à la question.
Utilisation
L'utilisation mesure la mesure dans laquelle la réponse est constituée d'informations provenant des segments du contexte. L’objectif est de déterminer la mesure dans laquelle chaque bloc fait partie de la réponse. Une faible utilisation indique que vos résultats peuvent ne pas être pertinents pour la requête. Vous devez évaluer l’utilisation en même temps que l’exhaustivité.
Calculer l’utilisation
Utilisez un modèle de langage pour calculer l’utilisation. Vous pouvez transmettre la réponse et le contexte qui contient les blocs au modèle de langage. Vous pouvez demander au modèle de langage de déterminer le nombre de blocs qui impliquent la réponse.
Évaluer l’utilisation
Le tableau suivant fournit des conseils sur la façon d’évaluer l’exhaustivité et l’utilisation.
Utilisation élevée | Faible utilisation | |
---|---|---|
Complétude élevée | Aucune action n’est nécessaire. | Dans ce cas, les données retournées traitent la question, mais retournent également des blocs non pertinents. Envisagez de réduire la valeur du paramètre top-k pour produire des résultats plus probables ou déterministes. |
faible niveau de complétude | Dans ce cas, le modèle de langage utilise les blocs que vous fournissez, mais ils ne répondent pas entièrement à la question. Envisagez d’effectuer les étapes suivantes :
|
Dans ce cas, les données retournées ne répondent pas entièrement à la question et les blocs que vous fournissez ne sont pas utilisés complètement. Envisagez d’effectuer les étapes suivantes :
|
Pertinence
Pertinence mesure la mesure dans laquelle la réponse du modèle de langage est pertinente et liée à la requête.
Calculer la pertinence
Utilisez les méthodes suivantes pour calculer la pertinence des réponses :
- Assisté par l'IA : Pertinence dans Azure AI Foundry
- Bibliothèque de pertinence des réponses Ragas
- Calcul de pertinence MLflow
Remarque
Vous pouvez utiliser le portail Azure AI Foundry pour effectuer les calculs ou utiliser les conseils de cet article pour calculer vous-même la pertinence.
Évaluer la pertinence
Lorsque la pertinence est faible, effectuez les tâches suivantes :
- Vérifiez que les blocs fournis au modèle de langage sont pertinents.
- Déterminez si les blocs pertinents et viables ne sont pas retournés. Si vous découvrez ces blocs, évaluez votre modèle d’incorporation.
- S’il n’existe pas de blocs viables, recherchez si des données pertinentes existent. Si c’est le cas, évaluez votre stratégie de segmentation.
- Si des segments pertinents sont renvoyés, évaluez votre requête.
Les scores que les méthodes d'évaluation comme la complétude produisent devraient donner des résultats similaires au score de pertinence.
Exactitude
l’exactitude mesure le degré auquel la réponse est précise et factuelle.
Calcul de l'exactitude
Il existe plusieurs façons d’évaluer l’exactitude, notamment :
- modèle de langage : utilisez un modèle de langage pour calculer l’exactitude. Vous pouvez transmettre la réponse au modèle de langage, idéalement un modèle de langage différent de celui utilisé pour générer le résultat. Vous pouvez demander au modèle de langage de déterminer si la réponse est factuelle ou non.
- source approuvée externe : utilisez une source approuvée externe pour valider l’exactitude de la réponse. Selon l’API de votre source approuvée, vous pouvez utiliser la source approuvée seule ou avec un modèle de langage.
Évaluer l’exactitude
Lorsque l'exactitude est faible, effectuez les tâches suivantes :
- Assurez-vous que les blocs fournis au modèle de langage sont factuelment corrects et qu’il n’existe aucun biais de données. Vous devrez peut-être corriger les problèmes dans les documents sources ou le contenu.
- Si les segments sont corrects, évaluez votre requête.
- Évaluez s’il existe des imprécisions dans le modèle qui doivent être surmontées avec des données de base factuels supplémentaires ou un réglage précis.
Métriques de similarité et d’évaluation
Il existe des centaines de métriques de similarité et d’évaluation que vous pouvez utiliser dans la science des données. Certains algorithmes sont spécifiques à un domaine, tel que la traduction de reconnaissance vocale ou de langue à langue. Chaque algorithme a une stratégie unique pour calculer sa métrique.
Les scientifiques des données déterminent ce que vous souhaitez mesurer et quelle mesure ou combinaison de métriques vous pouvez l’utiliser pour la mesurer. Par exemple, pour la traduction linguistique, la métrique d’évaluation bilingue (BLEU) vérifie le nombre de n-grammes qui apparaissent à la fois dans la traduction automatique et la traduction humaine pour mesurer la similarité selon que les traductions utilisent les mêmes mots. La similarité cosinus utilise des incorporations entre la machine et les traductions humaines pour mesurer la similarité sémantique. Si votre objectif est d’avoir une similarité sémantique élevée et d’utiliser des mots similaires à la traduction humaine, vous souhaitez un score BLEU élevé avec une similarité cosinus élevée. Si vous vous souciez uniquement de la similarité sémantique, concentrez-vous sur la similarité cosinus.
La liste suivante contient un exemple de métriques courantes de similarité et d’évaluation. Notez que les métriques de similarité répertoriées sont décrites comme étant basées sur des jetons, basées sur des séquences ou basées sur des modifications. Ces descriptions illustrent l’approche utilisée par les métriques pour calculer la similarité. La liste contient également trois algorithmes pour évaluer la qualité de la traduction de texte d’une langue à une autre.
- sous-chaîne commune la plus longue est un algorithme basé sur des séquences qui trouve la sous-chaîne commune la plus longue entre deux chaînes. Le pourcentage de sous-chaîne commune le plus long prend la sous-chaîne commune la plus longue et le divise par le nombre de caractères de la plus petite ou de la plus grande chaîne d'entrée.
- sous-séquence commune la plus longue (LCS) est un algorithme basé sur des séquences qui trouve la sous-séquence la plus longue entre deux chaînes. LCS ne nécessite pas que les sous-séquences soient dans l’ordre consécutif.
- similarité cosinus est un algorithme basé sur des jetons qui calcule le cosinus de l’angle entre les deux vecteurs.
- Jaro-Winkler distance est un algorithme basé sur les modifications qui compte le nombre minimal d’étapes pour transformer une chaîne en une autre.
- La distance de Hamming est un algorithme basé sur l'édition qui mesure le nombre minimum de substitutions nécessaires pour transformer une chaîne de caractères en une autre.
- L'index de Jaccard est un algorithme basé sur les tokens qui calcule la similarité en divisant l’intersection de deux chaînes par l’union de ces chaînes.
- distance Levenshtein est un algorithme basé sur les modifications qui calcule la similarité en déterminant le nombre minimal de modifications à caractère unique nécessaires pour transformer une chaîne en une autre.
- BLEU évalue la qualité du texte résultant de la traduction automatique d’une langue à une autre. BLEU calcule le chevauchement des n-grammes entre une traduction automatique et une traduction de qualité humaine pour effectuer cette évaluation.
- ROUGE est une métrique qui compare une traduction automatique d’une langue à une autre à une traduction créée par l’homme. Il existe plusieurs variantes de ROUGE qui utilisent le chevauchement des n-grams, des skip-bigrams ou de la plus longue sous-séquence commune.
- METEOR évalue la qualité d'un texte résultant d'une traduction automatique en examinant les correspondances exactes, les correspondances après troncature, les synonymes, la paraphrase et l'alignement.
Pour plus d’informations sur les métriques courantes de similarité et d’évaluation, consultez les ressources suivantes :
Utilisation de plusieurs métriques d’évaluation ensemble
Vous devez utiliser ensemble les métriques d’évaluation du modèle de langage pour mieux comprendre le fonctionnement de votre solution RAG. Voici plusieurs exemples d’utilisation de plusieurs métriques d’évaluation.
Base et exactitude
Les métriques de base et de correction permettent de déterminer si le système interprète et utilise le contexte avec précision. Si la pertinence est élevée mais que l'exactitude est faible, cela signifie que le modèle de langage utilise le contexte, mais fournit une réponse incorrecte. La réponse incorrecte peut être due à une utilisation incorrecte du contexte ou des problèmes liés aux données sources. Par exemple, si la pertinence est de 0,9, mais que l'exactitude est de 0,4, cela indique que le système fait référence au matériel source correct, mais qu'il tire des conclusions incorrectes. Considérez une réponse indiquant « Einstein a développé la mécanique quantique » basée sur un contexte qui mentionne séparément à la fois Einstein et la mécanique quantique. Cette réponse est fondée mais factuelment incorrecte.
Cette combinaison de métriques est l’une où la hiérarchisation de l’une par rapport à l’autre peut être très importante pour votre charge de travail spécifique. Par exemple, si les données sources contiennent des informations potentiellement fausses par conception et qu’il peut être essentiel que le système conserve ces fausses informations dans ses réponses. Dans ce cas, vous devez privilégier une réponse fondée plutôt qu'une réponse correcte. Dans d'autres cas, votre charge de travail préférerait que des données contextuelles soient consultées, mais que l'exactitude ultime reste la priorité.
Utilisation et complétivité
Les métriques d’utilisation et d’exhaustivité permettent d’évaluer l’efficacité du système de récupération. Une utilisation élevée (0,9) avec une faible complétivité (0,3) indique que le système récupère des informations précises mais incomplètes. Par exemple, lorsqu’on lui demande des causes de la Seconde Guerre mondiale, le système peut parfaitement récupérer des informations sur l’invasion de la Pologne, mais manquer d’autres facteurs essentiels. Ce scénario peut indiquer qu’il existe des blocs avec des informations pertinentes qui n’ont pas été utilisées dans le contexte. Pour résoudre ce scénario, envisagez de renvoyer davantage de blocs, d’évaluer votre stratégie de classement de blocs et d’évaluer votre prompt.
Ancrage et utilisation et similarité
Les métriques de base, d’utilisation et de similarité permettent d’identifier la façon dont le système conserve la vérité lors de la transformation des informations. Un niveau élevé d'ancrage (0,9) et d'utilisation (.9) avec une faible similarité (0,3) indique que le système utilise des données d'ancrage exactes, mais que la paraphrase est médiocre. Pour répondre à ce scénario, évaluez votre requête. Modifiez la requête et testez les résultats.
Documentation, création de rapports et agrégation
Vous devez documenter les hyperparamètres que vous choisissez pour une expérience et les métriques d’évaluation résultantes afin de comprendre comment les hyperparamètres affectent vos résultats. Vous devez documenter les hyperparamètres et les résultats à des niveaux granulaires, tels que l’incorporation ou l’évaluation de la recherche, et au niveau d’une macro, comme tester l’ensemble du système de bout en bout.
Pendant la conception et le développement, vous pouvez effectuer le suivi des hyperparamètres et des résultats manuellement. Toutefois, l’exécution de plusieurs évaluations sur l’ensemble du document de test et de la collection de requêtes de test peut impliquer des centaines d’exécutions d’évaluation et des milliers de résultats. Vous devez automatiser la persistance des paramètres et des résultats pour vos évaluations.
Une fois vos hyperparamètres et résultats enregistrés, vous devez envisager de créer des graphiques et des tableaux pour vous aider à visualiser de quelle manière les hyperparamètres affectent les métriques. La visualisation vous permet d'identifier les choix qui mènent à des creux ou à des pics de performance.
Il est important de comprendre que la conception et l’évaluation de votre solution RAG ne sont pas une opération ponctuelle. Votre collection de documents change au fil du temps. Les questions que vos clients posent changent au fil du temps et votre compréhension des types de questions évolue à mesure que vous apprenez de la production. Vous devriez revoir ce processus à nouveau et à nouveau. La gestion de la documentation des évaluations passées est essentielle pour les efforts futurs de conception et d’évaluation.
Accélérateur d’expérience RAG
Ces articles vous guident tout au long des phases et des choix de conception impliqués dans la conception et l’évaluation d’une solution RAG. Les articles se concentrent sur ce que vous devez faire, pas sur la façon de le faire. Une équipe d’ingénierie qui travaille avec les principaux clients de Microsoft a développé un outil appelé RAG Experiment Accelerator. L’accélérateur d’expérience RAG est un framework d’expérimentation de pointe. Il a été conçu pour optimiser et améliorer le développement de solutions RAG. L'accélérateur d'expérimentation RAG permet aux chercheurs et aux développeurs d'explorer et d'affiner facilement et efficacement les composants critiques qui améliorent les performances de RAG. Cette innovation aboutit finalement à une génération de texte plus précise et cohérente.
L’accélérateur d’expérience RAG utilise une interface de ligne de commande. Vous pouvez donc facilement expérimenter différents modèles incorporés, affiner les stratégies de segmentation et évaluer différentes approches de recherche pour déverrouiller le plein potentiel de votre système RAG. Il vous permet de vous concentrer sur les aspects principaux du développement RAG à l’aide d’une configuration simple pour le réglage des hyperparamètres.
L’infrastructure fournit également une prise en charge complète de la configuration du modèle de langage. Ce support vous aide à trouver un équilibre parfait entre la complexité du modèle et la qualité de génération. Cet outil vous aide à rationaliser le processus d’expérimentation, à gagner du temps et à améliorer considérablement les performances de vos modèles RAG.
RAG avec Vision Application Framework
Une grande partie des conseils de cet article sur l’utilisation des médias dans votre solution RAG provient d’une autre équipe d’ingénierie qui travaille avec les principaux clients de Microsoft. Cette équipe a écrit un framework appelé RAG avec Vision Application Framework. Cette infrastructure fournit un pipeline RAG basé sur Python qui traite le contenu textuel et image à partir de documents MHTML.
Le cadre charge, segmente et enrichit le texte et les images à partir de fichiers MHTML. Il ingère ensuite les segments dans la recherche Azure AI. L’infrastructure implémente la mise en cache pour l’enrichissement d’images pour le traitement et l’efficacité des coûts. Le cadre intègre également l'évaluation dans le cadre du pipeline.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
- Raouf Aliouat | Ingénieur logiciel II
- Rob Bagby | Responsable Principal du Contenu du Centre d'Architecture
- Paul Butler | Ingénieur logiciel
- Prabal Deb | Ingénieur logiciel principal
- Soubhi Hadri | Scientifique des données senior
- Ritesh Modi | Ingénieur principal
- Ryan Pfalz | Responsable du programme technique senior
- Mahdi Setayesh | Ingénieur logiciel principal
- Randy Thurman | Architecte de solution cloud IA principal