Lorsque vous atteignez cette phase, vous avez déjà généré votre index de recherche et déterminé les recherches que vous souhaitez effectuer. Cette phase aborde le processus d’évaluation de votre solution de génération augmentée par récupération (RAG) du point de vue de l’évaluation des prompts utilisateur attendus contenant les données de base récupérées contre le grand modèle de langage. Avant d'atteindre cette phase, vous devez achever la phase de préparation au cours de laquelle vous collectez vos documents de test et vos requêtes, segmentez vos documents de test, enrichissez les segments, intégrez les segments, créez un index de recherche et mettez en œuvre une stratégie de recherche. Vous devez évaluer chacune de ces phases et être satisfait des résultats. À ce stade, vous devriez vous sentir à l’aise que votre solution renvoie des données de base pertinentes pour une requête utilisateur.
Ces données de base forment le contexte du prompt que vous envoyez au grand modèle de langage pour répondre à la requête de l’utilisateur. Les stratégies d’ingénierie de prompt dépassent le cadre de cet article. Cet article traite l’évaluation de l’appel conçu pour le grand modèle de langage du point de vue des données de base. Cet article couvre certaines métriques d’évaluation courantes des grands modèles de langage, et certaines métriques de similarité et d’évaluation spécifiques qui peuvent être utilisées dans les calculs d’évaluation des grands modèles de langage ou comme métriques autonomes.
Cet article ne vise pas à fournir une liste exhaustive des métriques de grands modèles de langage ou des métriques de similarité et d’évaluation. Le nombre de ces métriques augmente chaque jour. Il est important pour vous de retenir de cet article qu’il existe diverses métriques, chacune ayant son propre cas d’utilisation distinct. Vous êtes le seul à comprendre globalement votre charge de travail. Vous et vos data scientists devez déterminer ce que vous voulez mesurer et quelles métriques vous aident à accomplir cette tâche.
Cet article fait partie d’une série. Lisez l’introduction.
Métriques d’évaluation des grands modèles de langage
Il existe plusieurs métriques que vous pouvez utiliser pour évaluer la réponse du grand modèle de langage, y compris la pertinence, l’exhaustivité, l’utilisation et la pertinence.
Important
Les réponses des grands modèles de langage sont non déterministes, ce qui signifie que le même prompt à un grand modèle de langage peut et renverra souvent des résultats différents. Ceci est important à comprendre lors de l’utilisation d’un grand modèle de langage dans le cadre de votre processus d’évaluation. Envisagez d’utiliser une plage cible plutôt qu’une cible unique lors de l’évaluation à l’aide d’un grand modèle de langage.
Fondement
La pertinence, parfois appelée fidélité, mesure si la réponse est entièrement basée sur le contexte. Elle valide que la réponse n’utilise pas d’informations autres que celles existant dans le contexte. Une métrique de pertinence faible indique que le grand modèle de langage pourrait dériver vers des territoires imaginatifs ou dénués de sens connus sous le nom d’hallucinations.
Calculateur
- La pertinence basée sur le service de sécurité de contenu Azure AI (AACS) est un modèle personnalisé qui utilise l’inférence de langage naturel (NLI) pour déterminer si les affirmations, dans ce cas les segments, sont impliquées ou non par un document source.
- La pertinence basée sur le grand modèle de langage utilise un grand modèle de langage pour déterminer le niveau de pertinence de la réponse.
- Bibliothèque de fidélité Ragas
- Calcul de fidélité MLflow
Évaluation
Si la pertinence est faible, cela indique que le grand modèle de langage ne considère pas les segments comme pertinents. Vous devriez évaluer si vous devez ajouter des données à votre corpus, ajuster votre stratégie de fragmentation ou la taille des segments, ou affiner votre prompt.
Exhaustivité
L’exhaustivité mesure si la réponse répond à toutes les parties de la requête. L'exhaustivité vous aide à comprendre si les segments du contexte sont pertinents et directement liés à la requête et s'ils fournissent une réponse complète.
Calculateur
- Assisté par l’IA : Invite de score de récupération
- Un grand modèle de langage peut vous aider à mesurer la qualité de la réponse du grand modèle de langage. Vous avez besoin de la question, du contexte et de la réponse générée pour effectuer cette mesure. Ce qui suit décrit le processus général :
- Utilisez le grand modèle de langage pour reformuler, résumer ou simplifier la question. Cette étape permet d'identifier 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 pouvant être « Non » ou « Oui » pour chaque document. Les réponses commençant 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 ayant une réponse commençant par « Oui ».
- Carré le score pour mettre en évidence les erreurs.
Évaluation
Si l’exhaustivité est faible, commencez par évaluer votre modèle d’embedding. Comparez le vocabulaire dans votre contenu avec le vocabulaire de votre modèle d’embedding choisi. Déterminez si vous avez besoin d’un modèle d’embedding spécifique à un domaine ou si vous devez affiner un modèle existant. Ensuite, évaluez votre stratégie de fragmentation. Si vous utilisez la longueur fixe, envisagez d'augmenter la taille de vos segments. Vous pouvez également évaluer si vos données de test ont suffisamment de données pour répondre complètement à la question.
Utilisation
L’utilisation mesure dans quelle mesure la réponse est composée d’informations provenant des segments dans le contexte. L’objectif est de déterminer dans quelle mesure chaque segment fait partie de la réponse. Une faible utilisation indique que vos résultats ne sont peut-être pas pertinents par rapport à la requête. L’utilisation doit être évaluée en parallèle avec l’exhaustivité.
Calculateur
Vous pouvez utiliser un grand modèle de langage pour calculer l’utilisation. Vous pouvez passer la réponse et le contexte contenant les segments au grand modèle de langage. Vous pouvez demander au grand modèle de langage de déterminer le nombre de segments impliquant la réponse.
Évaluation
Le tableau suivant fournit des conseils, en tenant compte à la fois de l’exhaustivité et de l’utilisation.
Haute utilisation | Faible utilisation | |
---|---|---|
Haute exhaustivité | Aucune action n’est nécessaire | Dans ce cas, les données retournées peuvent répondre à la question, mais des segments non pertinents ont été retournés. Envisagez de réduire la valeur du paramètre top-k pour obtenir des résultats plus probables/déterministes. |
Basse exhaustivité | Dans ce cas, les segments que vous fournissez sont utilisés, mais ne répondent pas entièrement à la question. Tenez compte des éléments suivants :
|
Dans ce cas, vous ne répondez pas entièrement à la question et les segments que vous fournissez ne sont pas bien utilisés. Envisagez les éléments suivants pour résoudre ces problèmes :
|
Pertinence
Mesure dans quelle mesure la réponse du grand modèle de langage est pertinente et liée à la requête.
Calculateur
- Assisté par IA : Pertinence dans Azure AI Studio - Vous pouvez utiliser Azure AI Studio pour effectuer les calculs, ou utiliser les conseils de cet article pour calculer la pertinence vous-même.
- Bibliothèque de pertinence des réponses Ragas
- Calcul de pertinence MLflow
Évaluation
Lorsque la pertinence est faible, évaluez les éléments suivants :
- Assurez-vous que les segments fournis au grand modèle de langage sont pertinents.
- Déterminez s'il existe des segments viables et pertinents qui n'ont pas été renvoyés. Si c’est le cas, évaluez votre modèle d’embedding.
- S'il n'y a pas de segments viables, vérifiez s'il existe des données pertinentes. Si c’est le cas, évaluez votre stratégie de fragmentation.
- Si des segments pertinents ont été retournés, évaluez votre prompt.
D’autres méthodes d’évaluation comme l’exhaustivité devraient être calculées et devraient donner des scores similaires à ceux observés dans la mesure de pertinence.
Métriques de similarité et d’évaluation
Comme mentionné dans l’introduction, il existe des centaines de métriques de similarité et d’évaluation utilisées en science des données. Certains algorithmes sont spécifiques à un domaine, comme la conversion de la parole en texte ou la traduction de langue à langue. Chaque algorithme a une stratégie unique pour calculer sa métrique.
Le data scientist détermine ce que vous voulez mesurer et quelle métrique ou combinaison de métriques vous pouvez utiliser pour le mesurer. Par exemple, dans le domaine de la traduction linguistique, la métrique Bleu vérifie combien de n-grams apparaissent à la fois dans la traduction automatique et la traduction humaine pour mesurer la similarité basée sur l’utilisation des mêmes mots. La similarité cosinus utilise des embeddings entre la traduction automatique et la traduction humaine pour mesurer la similarité sémantique. Si votre objectif était d’avoir une grande similarité sémantique et d’utiliser des mots similaires à la traduction humaine, votre objectif serait un score Bleu élevé avec une haute similarité cosinus. Si vous ne vous souciez que de la similarité sémantique, vous vous concentreriez sur la similarité cosinus.
La liste suivante contient un petit échantillon de métriques de similarité et d’évaluation courantes. Remarquez que les métriques de similarité répertoriées sont décrites comme basées sur les jetons, basées sur les séquences ou basées sur les modifications, illustrant comment elles utilisent des approches très différentes pour calculer la similarité. Notez également que la liste contient trois algorithmes pour évaluer la qualité de la traduction de texte d’une langue à une autre.
- Sous-chaîne commune la plus longue : Algorithme basé sur les séquences qui trouve la plus longue sous-chaîne commune entre deux chaînes. Le pourcentage de la plus longue sous-chaîne commune prend la plus longue sous-chaîne commune et la 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) : Algorithme basé sur les séquences qui trouve la plus longue sous-séquence entre deux chaînes. LCS ne nécessite pas que les sous-séquences soient dans un ordre consécutif.
- Similarité cosinus : Algorithme basé sur les jetons qui calcule le cosinus de l’angle entre les deux vecteurs.
- Jaro Winkler : Algorithme basé sur les modifications qui compte le nombre minimum d’étapes pour transformer une chaîne en une autre.
- Hamming : Algorithme basé sur les modifications qui mesure le nombre minimum de substitutions nécessaires pour transformer une chaîne en une autre.
- Jaccard - Algorithme basé sur les jetons qui calcule la similarité en divisant l’intersection de deux chaînes par l’union de ces chaînes.
- Levenshtein - Algorithme basé sur les modifications qui calcule la similarité en déterminant le nombre minimum de modifications de caractères uniques 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-grams entre une traduction automatique et une traduction de qualité humaine pour faire cette évaluation.
- ROUGE - Compare une traduction automatique d’une langue à une autre à une traduction créée par un humain. 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é du texte résultant de la traduction automatique en examinant les correspondances exactes, les correspondances après recherche de radical, les synonymes, les paraphrases et l’alignement.
Veuillez consulter les ressources suivantes pour voir des métriques de similarité et d’évaluation courantes :
Documentation, rapports et agrégation
Vous devez documenter à la fois les hyper-paramètres que vous avez choisis pour une expérience et les métriques d’évaluation résultantes afin de comprendre l’impact des hyper-paramètres sur vos résultats. Vous devez documenter les hyper-paramètres et les résultats à des niveaux granulaires comme l’évaluation des embeddings ou des recherches et à un niveau macro, comme tester l’ensemble du système de bout en bout.
Pendant la conception et le développement, vous pouvez peut-être suivre manuellement les hyper-paramètres et les résultats. Cependant, effectuer plusieurs évaluations de votre document de test entier et de votre corpus de requêtes de test peut impliquer des centaines de runs d’évaluation et des milliers de résultats. Il est recommandé d’automatiser la persistance des paramètres et des résultats pour vos évaluations.
Une fois que vos hyper-paramètres et résultats sont persistants, il est recommandé de créer des graphiques et des tableaux pour vous permettre de visualiser plus facilement les effets des choix d’hyper-paramètres sur les métriques. La visualisation vous aide à identifier les choix qui entraînent des baisses ou des pics de performance.
Il est important que vous compreniez que la conception et l'évaluation de votre solution RAG n'est pas une opération ponctuelle. Votre corpus de documents changera avec le temps. Les questions que vos clients posent changeront avec le temps et votre compréhension des types de questions évoluera au fur et à mesure que vous apprendrez de la production. Vous devriez revisiter ce processus encore et encore. Maintenir une documentation des évaluations passées est crucial pour les futurs efforts de conception et d’évaluation.
L’accélérateur d’expérimentation RAG
Ces articles vous guident à travers toutes les phases et les 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 comment le faire. Une équipe d'ingénieurs qui travaille avec les principaux clients de Microsoft a mis au point un outil appelé « RAG Experiment Accelerator ». L’accélérateur d’expérimentation RAG est un cadre d’expérimentation à la pointe de la technologie conçu pour optimiser et améliorer le développement de solutions de génération augmentée par récupération (RAG). L’accélérateur d’expérimentation RAG permet aux chercheurs et aux développeurs d’explorer et d’affiner efficacement les composants critiques qui influencent la performance de RAG, menant finalement à une génération de texte plus précise et cohérente.
Avec son interface basée sur CLI, vous pouvez expérimenter sans effort avec divers modèles d’embedding, affiner les stratégies de fragmentation et évaluer différentes approches de recherche pour libérer tout le potentiel de votre système RAG. Il vous permet de vous concentrer sur les aspects essentiels du développement RAG tout en extrayant les complexités de l’ajustement des hyper-paramètres à l’aide d’une configuration simple.
De plus, le cadre offre un support complet pour la configuration des grands modèles de langage, vous permettant de trouver le parfait équilibre entre la complexité du modèle et la qualité de la génération. Cet outil vous permet de rationaliser le processus d’expérimentation, de gagner un temps précieux et d’améliorer considérablement les performances de vos modèles RAG.
Que vous soyez un chercheur chevronné poussant les limites de la compréhension du langage naturel ou un professionnel de l'industrie cherchant à améliorer les capacités de génération de texte, ce cadre d'expérimentation est la solution ultime pour accélérer votre parcours de développement RAG. Adoptez l’avenir de l’expérimentation RAG et libérez tout le potentiel de vos modèles avec cet outil de pointe.
Cadre d'application RAG avec Vision
La plupart des conseils donnés dans cet article sur l'utilisation des médias dans votre solution RAG proviennent d'une autre équipe d'ingénieurs qui travaille avec les principaux clients de Microsoft. Cette équipe a rédigé un cadre appelé Cadre d'application du RAG avec vision. Ce cadre fournit un pipeline de récupération et de génération augmentée (RAG) basé sur Python qui traite à la fois le contenu textuel et les images des documents MHTML.
Le framework charge, segmente et enrichit à la fois le texte et les images des fichiers MHTML et ingère les segments dans Azure Search. Le cadre met en œuvre la mise en cache pour l'enrichissement des images afin de rentabiliser le traitement et les coûts. Le cadre intègre également l'évaluation dans le cadre du pipeline.
Contributeurs
- Ritesh Modi
- Rob Bagby
- Ryan Pfalz
- Raouf Aliouat
- Randy Thurman
- Prabal Deb
- Mahdi Setayesh
- Soubhi Hadri
- Paul Butler