Comment évaluer un système LLM

SECTION 1

Introduction

L'évaluation des applications basées sur les grands modèles de langage (LLM) est intrinsèquement complexe en raison de la nature unique de ces systèmes. Contrairement aux applications logicielles traditionnelles, où les résultats sont déterministes et prévisibles, les LLM génèrent des résultats qui peuvent varier à chaque exécution, même avec la même entrée. Cette variabilité découle de la nature probabiliste de ces modèles, ce qui signifie qu'il n'existe pas une seule sortie correcte pour une entrée donnée. Par conséquent, tester les applications basées sur LLM nécessite des techniques d'évaluation spécialisées, connues aujourd'hui sous le nom d'« évals »,pour assurer qu'elles respectent les normes de performance et de fiabilité.

SECTION 2

Pourquoi les évals sont-elles si critiques ?

Il existe plusieurs raisons pour lesquelles les évals en IA sont si importantes. En termes généraux, il existe quatre façons clés dont elles sont précieuses :

1. Elles établissent des normes de performance.

L'évaluation établit des normes de performance pour les systèmes LLM et guide le développement en fournissant des résultats directionnels pour les choix de conception et les hyperparamètres. Ces jalons de référence permettent de mesurer l'efficacité des différentes approches.

2. Elles peuvent aider à assurer des résultats cohérents et fiables.

La cohérence et la fiabilité sont essentielles au déploiement pratique des systèmes LLM. Les évaluations régulières identifient et atténuent les problèmes qui pourraient entraîner des résultats imprévisibles ou erronés, générant la confiance des utilisateurs et des parties prenantes.

3. Elles fournissent des informations pour guider l'amélioration.

L'évaluation continue met en évidence les domaines où le système excelle et ceux où il doit progresser, offrant des opportunités d'améliorations ciblées pour affiner et optimiser le système.

4. Elles activent les tests de régression.

Lorsque des modifications sont apportées à un système LLM, prompts, choix de conception ou algorithmes sous-jacents, l'évaluation assure qu'elles ne dégradent pas la qualité de la sortie et que chaque mise à jour maintient ou améliore la performance, préservant l'intégrité de l'application.

L'évaluation des systèmes LLM peut être largement divisée en deux catégories : les évaluations pré-déploiement et les évaluations en production. Chaque catégorie remplit des objectifs distincts et est cruciale à différents stades du cycle de vie du développement et du déploiement.

SECTION 3

Évaluations pré-déploiement

Les évaluations pré-déploiement se concentrent sur l'évaluation des systèmes LLM au cours de la phase de développement. Cette phase est critique pour façonner la performance et la fiabilité du système avant sa mise en ligne. Voici pourquoi les évaluations pré-déploiement sont essentielles :

Mesure des performances et établissement de jalons de référence :

Au cours de la phase de développement, l'évaluation fournit une mesure claire de la performance du système. Ces jalons de référence aident à comparer les versions du modèle et à comprendre l'impact des choix architecturaux, pour améliorer l'efficacité, la précision et la performance globale.

Garantir des mises à jour sans régression :

À mesure que le système subit un développement continu, les modifications du code, des paramètres du modèle ou des données peuvent introduire involontairement des régressions, des réductions involontaires de la performance ou de la précision. Les évaluations régulières pré-déploiement aident à assurer que chaque modification améliore ou au moins maintient les normes de performance.

SECTION 4

Comment effectuer une évaluation pré-déploiement

Pour effectuer une évaluation pré-déploiement, voici les étapes que vous devez suivre :

### Créer un ensemble de données de vérité terrain

Créer un ensemble de données de vérité terrain pour l'évaluation, La première étape, et peut-être la plus critique, dans l'évaluation des systèmes LLM est la création d'un ensemble de données de vérité terrain robuste. Cet ensemble de données comprend un ensemble de paires question-réponse générées par des utilisateurs experts. Ils servent essentiellement de référence pour évaluer la performance du LLM.

Les données de vérité terrain sont essentielles car elles fournissent un point de référence par rapport auquel les sorties du modèle peuvent être comparées. Elles doivent être représentatives du type de questions que les utilisateurs finaux sont susceptibles de poser en production et inclure une gamme diverse de questions possibles pour couvrir différents scénarios et contextes.

La création de données de vérité terrain nécessite des utilisateurs experts qui comprennent en profondeur le domaine métier et les comportements utilisateur : ils peuvent prédire les questions que les utilisateurs poseront et fournir les meilleures réponses, un niveau de connaissance contextuelle que les LLM, malgré leurs capacités avancées, ne possèdent pas toujours.

### Les LLM peuvent-ils créer une vérité terrain ?

Les LLM peuvent-ils générer une vérité terrain ? Bien que les LLM puissent aider à générer des données de vérité terrain, ils ne devraient pas être les seuls responsables de cette tâche. Voici pourquoi :

Ils ne comprennent pas le comportement des utilisateurs :

Les LLM ne comprennent pas le comportement des utilisateurs et le contexte spécifique de votre domaine métier. Ils peuvent générer des questions et des réponses plausibles, mais celles-ci peuvent ne pas refléter avec précision le type de requêtes que vos utilisateurs poseront ou les réponses qui leur seront les plus utiles.

Ils nécessitent une supervision humaine :

Les experts humains sont nécessaires pour examiner et affiner les questions et réponses générées par les LLM. Ils s'assurent que l'ensemble de données est réaliste, contextuellement exact et précieux pour les utilisateurs finaux.

Il est vital d'assurer la qualité et la pertinence :

La qualité de l'ensemble de données de vérité terrain est primordiale. La supervision humaine garantit que les questions et les réponses ne sont pas seulement pertinentes mais adhèrent également aux normes de l'entreprise et aux attentes des utilisateurs.

Voici un bon exemple d'un ensemble de données de vérité terrain pour une application RAG. En plus de la requête et de la réponse, cet ensemble de données fournit les différents passages pertinents à la requête provenant de la base de connaissances.

### Identifier et calculer les métriques pertinentes

Identifier les métriques pertinentes pour votre système LLM, Sélectionner la métrique d'évaluation appropriée est crucial pour évaluer la performance des systèmes LLM. Le choix de la métrique dépend du cas d'usage spécifique du système LLM, car différentes applications peuvent nécessiter de mesurer différents aspects de la performance du modèle.

Voici quelques exemples de métriques d'évaluation et leurs définitions :

Pertinence de la réponse

Définition : Cette métrique mesure la pertinence de la réponse fournie par rapport à la question posée. Elle évalue si la réponse aborde directement la requête et fournit des informations utiles et pertinentes. Importance : S'assurer que les réponses du modèle sont pertinentes aide à maintenir la satisfaction des utilisateurs et la confiance dans le système. Les réponses non pertinentes peuvent confondre ou frustrer les utilisateurs, diminuant la valeur de l'application.

2. Cohérence

Définition : La cohérence évalue le flux logique et la clarté du texte généré. Elle vérifie si la réponse est cohérente en interne et a du sens dans son ensemble. Importance : Les réponses cohérentes sont plus faciles à comprendre et à suivre pour les utilisateurs. Cette métrique est vitale pour les applications où la clarté et la compréhensibilité sont essentielles, comme les outils d'assistance client ou éducatifs.

3. Pertinence contextuelle

Définition : Cette métrique mesure le degré d'alignement de la sortie du modèle avec le contexte plus large fourni. Elle évalue si la réponse considère correctement le texte environnant ou la conversation. Importance : La pertinence contextuelle assure que les réponses du modèle sont appropriées et significatives dans le contexte donné. Cela est critique pour maintenir la continuité et la pertinence des conversations ou du contenu.

4. Métriques de responsabilité

Définition : Les métriques de responsabilité évaluent la nature éthique et appropriée de la sortie du modèle. Cela comprend la vérification des biais, du contenu nuisible et de la conformité aux normes éthiques. Importance : S'assurer d'une utilisation responsable de l'IA est crucial pour prévenir la propagation de la désinformation, des stéréotypes nuisibles et du contenu contraire à l'éthique. Ces métriques aident à générer la confiance et s'assurer que le système LLM adhère aux normes sociétales et éthiques.

@cite:quatre-techniques-de-recuperation-pour-ameliorer-la-rag

La triade RAG se compose des métriques suivantes :

Métriques de récupération

Fidélité

La précision factuelle de la réponse générée

Précision du contexte

Le rapport signal-bruit du contexte récupéré

Pertinence de la réponse

La pertinence de la réponse générée par rapport à la question

Rappel du contexte

Peut-il récupérer toutes les informations pertinentes nécessaires pour répondre à la question ?

### Métriques spécifiques à la tâche

Bien que les exemples de métriques ci-dessus puissent être utilisés dans divers cas d'usage et tâches, vous aurez besoin de métriques qui sont plus adaptées à la tâche particulière que vous effectuez. Les métriques spécifiques à la tâche évaluent la performance du modèle sur des tâches particulières, adaptées aux exigences spécifiques de l'application. Les exemples comprennent les métriques pour le résumé, la traduction et l'analyse de sentiment.

Pourquoi les métriques spécifiques à la tâche sont nécessaires

La plupart des métriques d'évaluation sont génériques. Pour comprendre la performance sur des tâches spécifiques, des métriques personnalisées sont nécessaires : elles offrent des informations détaillées sur l'efficacité du modèle pour chaque fonctionnalité particulière de l'application.

Par exemple, pour les tâches de résumé abstractif, Kryscinski et al. (2019) proposent ce qui suit :

La grammaticalité et la lisibilité du résumé

La fluidité du résumé et l'enchaînement des idées

Si le résumé est factuellement cohérent avec la source

Calculer le score pour chacune de vos métriques définies par rapport à la vérité terrain, Pour chaque question de votre ensemble de données de vérité terrain, utilisez la réponse générée par le système LLM pour calculer la métrique respective, et apportez les ajustements nécessaires si les résultats sont insatisfaisants. Des bibliothèques comme DeepEval et Relari-ai comparent vos réponses LLM à la vérité terrain en exploitant des LLM, d'autres modèles PLN ou des fonctions de code traditionnelles.

Il est important de prendre des décisions guidées par les métriques sur la conception de vos systèmes LLM en fonction des métriques observées. Par exemple, un rappel faible pour les questions attendant des réponses factuelles courtes pourrait vous obliger à réduire vos tailles de chunk. Une précision faible même avec des valeurs élevées de K pourrait bénéficier du reclassement de vos chunks récupérés. De même, les différents éléments du flux de travail de votre système LLM tels que les prompts, les paramètres d'inférence, la stratégie de chunking, les mécanismes de récupération, le choix des embeddings, etc. devraient être optimisés en fonction des métriques.

Il existe une tendance émergente à utiliser un LLM puissant (par exemple, GPT-5.6) comme métrique sans référence (sans vérité terrain) pour évaluer les générations d'autres LLM. Ceci est parfois désigné par le terme « LLM-as-judge » (LLM-comme-juge). Le framework G-eval en est un bon exemple. L'article argue que, lorsqu'utilisé via ce framework, un LLM frontier a une forte corrélation avec les évaluateurs humains. Des arguments similaires ont été avancés dans les articles de Vicuna et QLoRA.

Cependant, la fiabilité et la granularité obtenues en utilisant une vérité terrain pour les évals est bien meilleure que celle obtenue en utilisant un LLM évaluateur tel que détaillé dans ce blog. De plus, certaines métriques comme le rappel du contexte ne peuvent pas être mesurées sans vérité terrain.

En conclusion, si les LLM fournissent des informations directionnelles précieuses et rationalisent le processus, ils ne remplacent pas les évaluations sur données de vérité terrain, laborieuses mais d'une précision inégalée. Combiner les deux approches peut être bénéfique.

### Intégrer les évals dans le processus de déploiement

Pour assurer que votre système LLM respecte constamment les critères de performance requis, il est essentiel d'intégrer les évaluations dans vos pipelines de déploiement. Cette intégration valide non seulement la performance du modèle avant le déploiement, mais maintient également la qualité et la fiabilité tout au long du cycle de vie du développement.

Les tests s'exécutent automatiquement à chaque commit et avant une version de déploiement pour assurer que les modifications du code n'introduisent pas d'erreurs ou ne dégradent pas la performance. Cet article parle d'écrire des cas de test unitaires pour les LLM de manière assez détaillée.

En plus de lancer les tests automatisés que vous avez écrits, les outils comme Giskard peuvent aider à exécuter des scans dans vos pipelines de déploiement pour tester votre LLM sur plusieurs aspects comme la nocivité, les hallucinations et les informations sensibles. Vous trouverez ci-dessous quelques exemples de tests automatisés implémentés à l'aide de Giskard pour vérifier les hallucinations et la nocivité. Giskard exécute ces tests dans le cadre de votre processus de déploiement.

Un point clé à noter concernant les tests automatisés pour les systèmes LLM est que nous devrons également écrire des tests pour les étapes de prétraitement et d'ingestion des données.

SECTION 5

Évaluations post-déploiement et flywheels de données

Pour assurer que votre système LLM continue à performer de manière optimale après le déploiement, il est crucial de mettre en œuvre des couches d'observabilité robustes. Ces couches fournissent les traces nécessaires des interactions entrée-sortie, vous aidant à comprendre où le système peut échouer ou sous-performer.

Surveiller les interactions vous permet de capturer les données en temps réel sur la façon dont le système LLM traite différentes questions et scénarios. Mettre en place une surveillance continue pour détecter les anomalies et les problèmes de performance. Bien que les tests automatisés fournissent une surveillance continue, ils ne sont pas suffisants en soi. Les évaluations humaines sont essentielles pour capturer les nuances et le contexte que les systèmes automatisés pourraient manquer. Planifier des sessions d'évaluation périodiques avec des experts du domaine pour évaluer la performance du LLM et fournir des retours pour l'amélioration. Enfin, créer un mécanisme de retour où les utilisateurs peuvent signaler des problèmes ou fournir des retours directement depuis l'interface.

### Flywheels de données et amélioration continue du LLM

Le concept de flywheels de données est fondamental pour l'amélioration continue des systèmes LLM. Un flywheel de données est une boucle auto-renforçante qui exploite les données collectées à partir des environnements opérationnels pour générer des améliorations continues de la performance. Pour les systèmes LLM, cela se traduit par l'utilisation des observations en temps réel et des retours des environnements de production pour affiner votre flux de travail, en s'assurant qu'il devient plus précis, pertinent et efficace au fil du temps. Comme discuté précédemment, les informations des métriques peuvent être utilisées pour apporter des modifications aux différents composants de votre flux de travail, allant de la stratégie de chunking aux embeddings aux prompts et aux méthodes de récupération.

Il est important de noter que les métriques avec lesquelles vous venez ne sont pas statiques, elles peuvent avoir besoin d'être modifiées et adaptées au fil du temps. Cela se produit à mesure que vous en apprenez plus sur le comportement de l'utilisateur final et que vous identifiez de nouveaux modes d'utilisation en production et des scénarios d'échec.

En comprenant comment les utilisateurs interagissent avec le système et où surviennent des malentendus ou des inefficacités, vous pouvez ajuster votre système LLM pour être plus clair, plus spécifique et mieux aligné sur l'intention de l'utilisateur. De même, les flux de travail peuvent être rationalisés pour réduire les frictions et améliorer l'expérience utilisateur globale.

La beauté de l'approche du flywheel de données est sa nature cyclique. À mesure que vous implémentez des améliorations en fonction de vos observations, ces modifications généreront nouvelles données, offrant des informations actualisées pour un raffinage supplémentaire. Cela crée un système continuellement améliorant qui devient plus efficace et performant à chaque itération.

@cite:testing-des-systemes-ia-construire-la-confiance-dans-le-non

SECTION 6

Évals en premier : La clé pour construire des applications LLM fiables

Pour construire des applications LLM fiables et performantes, décaler les évaluations en amont dans le flux de travail du développement n'est pas seulement bénéfique, c'est essentiel. En intégrant une approche guidée par les évals dès le départ, les équipes peuvent identifier de manière proactive les lacunes, améliorer leurs implémentations et assurer l'alignement avec les attentes des utilisateurs dès le début.

Le choix des méthodes d'évaluation devrait être guidé par la nature de l'application et l'expérience utilisateur souhaitée. Cela signifie qu'il est crucial de considérer dès le départ quelles sont les bonnes métriques et jalons de référence. Ne traitez pas les évals comme une réflexion tardive, faites-les un élément fondamental de votre processus de développement pour construire des applications d'IA robustes et centrées sur l'utilisateur.

Avertissement : Les déclarations et opinions exprimées dans cet article sont celles de l'auteur (des auteurs) et ne reflètent pas nécessairement les positions d'Adservio.

FAQ

Questions fréquentes