LLM : les outils d’évaluation des fournisseurs cloud
Comment sélectionner un modèle d’IA générative ? Les fournisseurs cloud américains – portes d’entrée principales des déploiements – ont prévu des outils d’évaluation. Voici leurs principales caractéristiques.
Anthropic, Cohere, Meta, IBM, Google, AWS, OpenAI, Microsoft, Snowflake, Databricks, sans oublier les centaines de startups et d’équipes de recherche, développent des grands modèles de langage.
Face à la profusion de modèles d’IA générative, il paraît difficile de choisir, d’autant que les critères d’évaluation des modèles ne sont pas des plus limpides. LeMagIT s’est déjà intéressé aux benchmarks génériques, et une fois cette fiche devant les yeux, cela paraît plus simple de comprendre à quoi correspondent les scores affichés et vantés par les fournisseurs de LLM.
À lire également :
Les benchmarks et classements communautaires
Des projets comme le LLM leaderboard d’Hugging Face permettent de comparer les résultats des modèles « open weight ».
Il existe également des classements créés par la communauté, des instituts ou des équipes de recherche. L’on peut citer Chatbot Arena et Big Code. Il y a également les benchmarks RepoBench, CRUXEval, CrossCodeEval, EvalPlus, SWE-bench, etc. Ceux-là utilisent d’autres jeux de données, concoctés manuellement ou à l’aide d’autres modèles d’IA générative.
Outre un classement, ces projets fournissent des outils de visualisation de ces résultats. L’Open LLM leaderboard disponible sur Hugging Face permet de sélectionner la taille du modèle, le format du checkpoint (bfloat 16, float16, 8 bit, etc.), une moyenne des benchmarks génériques, de sélectionner les modèles de base préentraînés ou instruits, mais également des modèles fine-tunés par la communauté.
Même s’ils donnent des indicateurs, ces benchmarks sont avant tout des outils de recherche.
Les outils d’évaluation chez Azure, Google Cloud et AWS
Azure AI Studio
À travers Azure AI Studio, Microsoft fournit un outil de comparaison des modèles accessibles sans compte Azure ou même sans se connecter à Microsoft 365. Il permet de filtrer les modèles, de cibler des collections et de comparer visuellement les résultats des LLM sur les benchmarks génériques.
L’outil « Model Benchmarks » peut également filtrer les benchmarks suivant des tâches, elles aussi génériques. Dans l’onglet « points de référence de qualité », il est possible de sélectionner des tâches de génération de texte et de réponses à des questions.
Dans l’onglet « points de références d’incorporation », l’on retrouve des filtres pour les tâches de génération augmentée par la recherche (Retrieval Augmented Generation ou RAG), celles de classification, d’extraction dans du texte, de résumé, de reranking, d’analyse de la similarité textuelle spécifiques aux modèles d’embeddings. Dans le cadre d’une architecture RAG, ces modèles de vectorisation de mots, de code et de documents sont autant, voire plus importants que le modèle utilisé pour générer la réponse à partir d’une source d’information réelle (vérité terrain).
Pour l’heure, l’outil en préversion ne fait figurer les résultats que de trois modèles d’embeddings, deux de Cohere (cohere-embed-v3-english et multilingual) et un d’OpenAI (text-embedding-ada-002).
À partir des benchmarks génériques, les ingénieurs de Microsoft proposent leur propre grille de lecture avec des métriques spécifiques. Pour les LLM, Azure AI Studio calcule les scores d’exactitude, de cohérence, d’aisance (ou fluidité), et de similitude, tout en expliquant les méthodes utilisées pour ce faire.
Les métriques d’évaluation au sein d’Azure AI Studio
- L’exactitude (accuracy) correspond à la moyenne des scores obtenus sur des benchmarks génériques, hormis HumanEval. Ces parangonnages sont souvent binaires : le modèle a bien répondu ou non. C’est exactement ce que fait cette métrique. « L’exactitude compare simplement le texte généré par le modèle avec la réponse correcte en fonction du jeu de données, en remontant “un” si le texte généré correspond exactement à la réponse et “zéro” dans le cas contraire », précise Microsoft.
- La cohérence permet de savoir si le LLM répond naturellement, dans un « langage humain ».
- L’aisance (Fluency) s’intéresse à « la conformité du texte généré aux règles grammaticales, aux structures syntaxiques et à l’utilisation appropriée du vocabulaire, ce qui aboutit à des réponses linguistiquement correctes et naturelles ».
- La similarité, elle, est une métrique pour comparer une phrase générée avec la « vérité terrain », c’est-à-dire des phrases ou documents présents dans un jeu de données de test.
Dans le catalogue de modèles d’Azure AI Studio, il est possible de sélectionner parmi plus de 1 600 checkpoints modèles LLM, de NLP, d’embedding et de computer vision répartis dans 13 collections. On peut les filtrer à partir de 25 tâches génériques (résumé, image à image, détection d’objets, conversations, etc.). Les fiches des LLM renseignent leurs scores issus du classement Open LLM Leaderboard.
Or pour réellement se rendre compte des performances des modèles, il faut pouvoir les tester. C’est en tout cas la position d’acteurs comme Microsoft, AWS, Google Cloud, Hugging Face ou IBM.
Pour ce faire, Azure AI Studio propose des solutions. Une fois un modèle sélectionné, il est possible de réaliser ce que Microsoft nomme des « évaluations manuelles ». Des métriques similaires, en sus de mécanismes de vérifications de la toxicité, sont utilisées pour vérifier si le LLM en question répond correctement à des cas d’usage spécifiques. L’utilisateur doit constituer lui-même un jeu de données, généralement de questions récurrentes et des réponses attendues (des prompts). La pertinence du modèle est évaluée suivant la promixité des prédictions avec les données de référence.
Les 50 premières entrées sont gratuites, mais cette fonctionnalité est payante : cela demande d’appeler les API mis à disposition par Microsoft Azure.
D’autres options permettent de gérer des flux d’évaluation automatique personnalisés et de générer des simulations contradictoires, afin d’éviter les hallucinations au regard de demandes toxiques (contenus violents, sexuels, haineux, cybermalveillant, etc.).
Microsoft ne précise pas exactement combien coûte l’utilisation de ce service, mais propose un guide pour maîtriser l’appel aux différents services Azure nécessaires à l’exécution de ces scénarii.
Attention, le service d’évaluation contradictoire d’Azure AI Studio n’est pas disponible dans toutes les régions cloud, mais en Europe, il est déjà déployé en France (Centre), en Suède (Centre) et Royaume-Uni (Sud).
Google Vertex AI
Chez Google Cloud, il y a un équivalent au catalogue de modèles, le « jardin de modèles » (150 références), mais GCP n’offre pas depuis sa plateforme Vertex AI d’équivalent aux systèmes de visualisation des benchmarks.
GCP dispose, lui aussi, de plusieurs mécanismes d’évaluation payants pour tester les modèles accessibles à travers ce registre.
Il y a d’abord Rapid Evaluation, en préversion publique (Pre-GA). Celui-ci permet depuis un workbench Vertex AI ou un espace Google Colab de lancer des tests à partir de petits volumes de données batch.
Ensuite, le fournisseur propose deux pipelines d’évaluation de bout en bout. « Ces options utilisent les Vertex AI Pipelines pour orchestrer une série d’étapes liées à l’évaluation, telles que la génération de réponses de modèles, l’appel au service d’évaluation en ligne et le calcul des métriques. Ces étapes peuvent également être appelées individuellement dans des pipelines personnalisés », précise Google, dans sa documentation.
Il y a d’abord AutoSxS réservé à la comparaison des résultats de deux modèles dans un test consistant à observer le taux de victoire (Win rate) des deux concurrents par rapport à une tâche donnée. Ce travail est effectué automatiquement par un modèle « autorater », c’est-à-dire un modèle de récompense entraîné sur les préférences humaines.
L’option « Computation based » correspond à l’évaluation manuelle d’Azure AI Studio, c’est-à-dire la comparaison des résultats des LLM et des modèles d’embeddings par rapport à un jeu de données « vérité terrain ».
Ces méthodes d’évaluation peuvent être appliquées à quatre tâches principales : la production de résumé, la réponse à des questions, l’utilisation d’outils et la génération de texte. Chaque tâche est associée à quelques métriques, par exemple la qualité, la verbosité, l’utilité et la pertinence. Elles donnent lieu à une notation de 1 à 5, de « très mauvais » à « très bon » par rapport aux instructions, aux prompts confiés par les utilisateurs.
La tarification de Rapid Evaluation dépend du nombre d’appels API, mais l’utilisation de l’option Computation Based ne semble pas associée à un SKU particulier.
Amazon Bedrock
À travers Amazon Bedrock, AWS propose lui aussi deux méthodes d’évaluation payantes : l’une automatique, avec des jeux de données génériques ou spécifiques, l’autre manuelle, effectuée soit par des employés, soit par des « experts » missionnés à travers la plateforme.
Ces approches permettent là encore de tester les LLM et les SLM dans des cas d’usage de génération de texte, de classification, de réponse à des questions et de production de résumés à partir de prompts « maison ». Ici, les résultats sont stockés au format JSON dans un bucket Amazon S3 qu’il faut pointer.
Suivant les tâches à accomplir, Amazon Bedrock fournit des jeux de données et des benchmarks (TREX, WikiText 2, Gigaword, BoolQ, TriviaQ, NaturalQS), principalement des paires de questions-réponses, conçus pour mesurer l’exactitude par rapport à des données terrain, à la robustesse linguistique des LLM ou encore leur toxicité.
Dans le cadre de l’évaluation automatique, ces métriques –, exactitude, robustesse, toxicité – sont mesurées différemment suivant les tâches. Par exemple pour la génération de texte, l’exactitude est fonction d’un score de « connaissance sur le monde réel » (Real World Knowledge ou RWK) tandis que pour les tâches de résumé, elle est fonction d’un score BERT. « Le score BERT est calculé à l’aide d’embeddings contextuels préentraînés provenant de modèles BERT. Il met en correspondance les mots des phrases candidates et des phrases de référence par similarité cosinusoïdale », précise la documentation d’AWS.
L’évaluation manuelle est davantage utilisée pour comparer les résultats de plusieurs modèles quand ils sont soumis à 1 000 prompts maximum. Dans ce cadre, le calcul de ces métriques est fonction de notes données par les humains, aux contenus générés par le modèle évalué par rapport au prompt en entrée. Amazon Bedrock propose de mettre en place plusieurs systèmes pour juger la qualité d’une réponse par rapport à une autre : échelle de Likert individuel (« fortement en désaccord, en désaccord, neutre, d’accord fortement d’accord ») ou comparative, choix, échelle ordinale, ou encore pousse vers le haut/vers le bas.
Ici, la pertinence des métriques dépend essentiellement des annotateurs. Là encore, Amazon bedrock permet de tester des LLM tiers, qu’ils soient open source ou en provenance de partenaires.
Le prix de l’évaluation automatique correspond aux nombres d’appels API réalisées vers les modèles inférés. L’évaluation manuelle, elle est facturée 0,21 dollar par tâche de notation humaine. Il faut également ajouter le coût (minime) de stockage des fichiers dans les buckets S3.
Conclusion
Pour se rendre compte des résultats d’un LLM, les benchmarks publics donnent un premier aperçu. Mais le marché s’entend sur le fait qu’il faut tester les usages en conditions réelles. Force est de constater que les fournisseurs cloud proposent des solutions plutôt complètes, même si la tarification pourrait être plus claire et le nombre de scénarii couverts (surtout des cas exemplaires spécifiques) plus conséquents. Par exemple, l’évaluation des modèles de génération de code ne semble pas réellement prise en compte. Il semble préférable de passer par des assistants, tels GitHub Copilot, Gitlab Duo Chat, Tabnine et autres.
