Former votre propre juge LLL : de PandaLM et JudgeLM à Prometheus

Lorsqu’un modèle de langage est capable d’écrire des essais, de répondre aux demandes d’assistance et de résumer des contrats, la question « ce résultat est-il de qualité ? » ne permet plus de réponse simpliste. L’évaluation par des humains reste la norme d’or, mais elle est lente et coûteuse ; les métriques classiques d’overlap ne permettent plus vraiment d’évaluer la qualité, et l’utilisation d’un modèle propriétaire pour noter les résultats ne fonctionne bien que lorsque vos critères correspondent à ce que ce modèle connaît déjà. Ce guide présente les recherches menées sur des juges LLM affinés, des modèles ouverts entraînés spécifiquement pour évaluer et critiquer d’autres modèles, et se termine par une méthode concrète que vous pouvez suivre pour créer un outil d’évaluation adapté à votre domaine.

Pourquoi évaluer les LLM modernes est si difficile

Deux caractéristiques des modèles de fondation actuels rendent leur évaluation difficile. La première est l’étendue des fonctions attendues : on exige d’un seul modèle qu’il code, traduise, raisonne, respecte des règles de formatage, soit sûr et amical, et chacun de ces comportements nécessite une mesure distincte. La seconde est l’ouverture du système : pour presque tout stimulus, il existe un vaste éventail de réponses acceptables qui diffèrent par leur formulation, leur structure, leur longueur et leurs accents, ce qui empêche de vérifier simplement si la sortie correspond à une chaîne de caractères prévue. Mesurer correctement ne serait-ce qu’une seule capacité constitue déjà un problème de recherche, et un modèle destiné à la production en possède des dizaines.

Le signal le plus fiable provient toujours des personnes qui lisent les résultats et les évaluent. Le problème, c’est que les jugements humains sont sujets à des biais, coûteux et lents à collecter, ce qui entre en conflit avec le rythme du développement des modèles. Une équipe qui réentraîne ou reformule ses prompts plusieurs fois par semaine ne peut pas attendre une nouvelle campagne d’annotation après chaque modification. Une certaine quantité d’évaluation humaine reste indispensable, mais elle doit être complétée par des solutions qui permettent une mise à l’échelle.

Ce besoin a donné naissance à LLM-as-a-Judge, présenté dans l’article Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena : on demande à un modèle propriétaire performant d’évaluer les résultats d’un autre modèle. Cette approche est désormais omniprésente dans la recherche, mais elle présente un point faible. Les produits spécialisés dans des domaines précis tiennent souvent compte de critères très détaillés, tels que le fait qu’un résumé médical conserve les informations sur les doses ou qu’une réponse juridique cite la clause appropriée, et un modèle polyvalent peut ne pas être en mesure d’évaluer cela de manière fiable. Dans ce cas, la prochaine étape logique est d’entraîner un juge spécialisé, et comprendre comment le faire efficacement constitue l’objectif du reste de cet article.

L’outil d’évaluation : les humains, les métriques et les juges basés sur des modèles

Dans la pratique, les équipes combinent l’évaluation humaine avec des métriques automatiques. Les humains fournissent une appréciation définitive de la qualité, tandis que les métriques automatiques assurent rapidité. Comme les scores automatisés ne sont qu’une approximation de ce que pensent les humains, on continue à les comparer régulièrement avec des évaluations manuelles ; entre ces dernières, il est possible de comparer bien plus de variantes de modèles que les humains ne pourraient jamais examiner.

L’évaluation automatique des LLM modernes relève principalement de deux catégories. La première est l’évaluation de type benchmark basée sur la probabilité ou la perplexité, qui couvre la plupart des benchmarks traditionnels de NLP tels que MMLU et BIG-bench. Ces derniers fonctionnent à peu près comme des examens à choix multiples visant à évaluer ce que le modèle sait. Ils sont utiles, mais ils donnent peu d’informations sur la capacité du modèle à rédiger une réponse longue et stylistiquement adaptée à une question ouverte.

Pour des réponses longues et ouvertes, il n’y a en réalité que deux solutions : faire évaluer les réponses par des humains ou par un modèle performant. Compte tenu des coûts liés à la première solution, l’évaluation basée sur des modèles est devenue la méthode par défaut. Elle ne nécessite pas de réponse de référence, est facile à mettre en place et permet de gérer une grande variété de tâches. Les sections suivantes examinent successivement chaque outil de cette boîte à outils, en commençant par l’aspect humain, car tout le reste est mesuré par rapport à lui.

L’évaluation humaine constitue la vérité de référence, même si elle n’est pas parfaite

Les gens peuvent remarquer ce qui est vraiment important dans une réponse : qu’elle soit suffisamment brève, créative, adaptée en termes de tonalité ou sensible sur le plan culturel. C’est pourquoi l’évaluation humaine reste la référence. Les annotateurs peuvent venir de divers horizons. Vous pouvez recueillir des votes en crowdsourcing comme le fait Chatbot Arena, embaucher une équipe dédiée, ou, comme l’a fait le projet Alpaca, faire évaluer les résultats par les développeurs du modèle eux-mêmes. Considérer les humains comme source de vérité absolue ne signifie pas que leurs annotations soient parfaites. En pratique, elles sont souvent incohérentes, fastidieuses à produire et sujettes aux biais.

Conformité et calibration

Même les tâches qui semblent simples entraînent souvent un niveau de concordance étonnamment faible entre les annotateurs. Vous pouvez le quantifier à l’aide d’un taux de correspondance simple ou de statistiques corrigées du hasard telles que le kappa de Cohen (deux évaluateurs), le kappa de Fleiss (plusieurs évaluateurs) ou l’alpha de Krippendorff (flexible en cas d’étiquettes manquantes et de différents types d’échelles). La correction du hasard est importante : si 80 pour cent des réponses sont « bonnes », deux évaluateurs qui qualifient tout de « bon » seront d’accord la plupart du temps sans apprendre quoi que ce soit.

Lorsque la concordance est faible, la solution réside en une calibration, c’est-à-dire en enseignant aux annotateurs à effectuer la tâche de la même manière. Une étape typique consiste en une session de révision où les évaluateurs examinent les éléments sur lesquels ils ne sont pas d’accord, discutent des cas et parviennent à une interprétation commune. Les résultats de ces discussions sont ensuite réintégrés dans les directives de la tâche afin que le prochain lot parte d’une base plus claire.

Des directives d’écriture réellement utilisées

Les directives constituent le contrat écrit pour une tâche d’annotation. Elles doivent au minimum indiquer ce qui est évalué, c’est-à-dire les critères, ainsi que la manière dont chacun de ces critères doit être appliqué. De bonnes directives combinent des instructions en prose avec des exemples concrets de labels corrects et incorrects, et les annotateurs y ont recours tout au long du travail plutôt que de ne les lire qu’une seule fois. Elles rendent les labels plus cohérents et raccourcissent considérablement la période d’intégration des nouveaux évaluateurs. Un test utile : si un annotateur a besoin de connaissances absentes du document pour étiqueter correctement un élément, le document est incomplet.

Les directives doivent également être considérées comme des documents vivants. L’équipe InstructGPT, par exemple, a indiqué avoir révisé à plusieurs reprises ses instructions de marquage au cours du projet, au fur et à mesure que leurs retours, les champs de métadonnées et leur compréhension du sujet évoluaient, en corrigeant les passages qui se révélaient confus ou contradictoires. Cette expérience est typique : les tâches qui semblent évidentes cachent souvent beaucoup de subjectivité, et celle-ci ne ressort que lorsque un groupe de personnes tente de s’accorder sur des centaines d’exemples concrets.

Vérification de l’accord au fil du temps

L’investissement important a lieu au début : définition des critères, calibration des évaluateurs et itérations jusqu’à ce que l’accord soit acceptable. Ce n’est qu’alors que les notes fournies par des humains deviennent une mesure fiable de la qualité du modèle. Cependant, le travail ne s’arrête pas là. L’accord peut se détériorer pour des raisons banales : de nouveaux évaluateurs rejoignent l’équipe, ceux qui ont de l’expérience s’éloignent progressivement des règles écrites, ou les directives elles-mêmes changent. Suivre en permanence l’accord entre les évaluateurs, par exemple en envoyant une partie des éléments à plusieurs évaluateurs, est le seul moyen de détecter ce phénomène avant qu’il ne corrompe discrètement vos données d’évaluation.

Métriques basées sur des références et raison pour lesquelles elles ont cessé de fonctionner

Les générations précédentes de modèles de langage étaient généralement évaluées à l’aide de métriques telles que ROUGE pour la résumation et BLEU pour la traduction. Ces deux méthodes reposent sur une référence : elles comparent la sortie du modèle à une réponse de référence, principalement en comptant les n-grammes qui se recoupent, et récompensent les sorties qui partagent le plus de mots et de phrases avec cette référence.

Au fur et à mesure que les modèles se sont améliorés, ces métriques ont perdu de leur pertinence. Des études sur les sorties des LLM ont montré que de telles métriques présentent une faible corrélation avec les préférences humaines, au point que aucune des métriques classiques examinées ne parvient à refléter fidèlement le jugement humain. Elles survivent principalement parce qu’elles sont presque gratuites à calculer. Si vous disposez déjà de réponses de référence, elles restent utiles comme vérification rapide, par exemple pour détecter une dégradation où un résuméur commence soudainement à produire du texte vide ou hors sujet.

La raison principale de leur échec est structurelle. Une métrique basée sur une référence correspond essentiellement à une recherche floue sophistiquée par rapport à un seul objectif. Les modèles modernes sont ouverts : une seule demande peut donner lieu à de nombreuses réponses tout aussi bonnes, qui partagent peu de n-grams avec la référence. Un score qui récompense la similarité avec une réponse particulière ne peut pas représenter l’ensemble des réponses valables, ce qui pénalise les paraphrases parfaitement correctes et peut récompenser un texte fluide qui se trouve à reutiliser le vocabulaire de la référence tout en étant erroné.

Juges LLM pilotés par des prompts

Les faiblesses des métriques de chevauchement ont poussé le domaine vers une évaluation plus flexible, basée sur des modèles. La forme la plus populaire est LLM-as-a-Judge : un modèle puissant est incité à agir en évaluateur des résultats d’un autre modèle. Les études menées sur MT-Bench et Chatbot Arena ont montré que cette méthode correspond bien aux préférences humaines, ne nécessite guère plus qu’un prompt bien rédigé pour être mise en œuvre, gère naturellement les résultats ouverts et peut s’appliquer à de nombreux critères différents. Ces recherches l’ont présentée comme une approximation scalable et expliquable des préférences humaines, dont il est sinon coûteux de recueillir les données.

Dans le reste de cet article, l’expression « LLM-as-a-Judge » désigne spécifiquement l’utilisation d’un modèle propriétaire prêt à l’emploi, tel que GPT-4o ou Gemini 1.5, tandis que « juge affiné » fait référence à un modèle que vous entraînez vous-même pour l’évaluation. Pour en savoir plus sur les juges pilotés par des prompts, des lectures utiles comprennent un guide pratique pour créer des juges permettant de prendre des décisions commerciales, une analyse de l’efficacité des évaluateurs basés sur des LLM, ainsi qu’une revue de la recherche sur le concept de « LLM-as-a-Judge ». Si vous utilisez déjà un juge piloté par des prompts en production, les aspects opérationnels y sont abordés dans notre guide pour gérer LLM-as-a-Judge en tant que système de production dynamique.

Évaluation par paires et évaluation point par point

Il existe deux principales manières de demander un verdict à un juge :

• Paire par paire : le juge voit une question ainsi que deux réponses candidates et choisit la meilleure (souvent avec une option pour un match nul).
• Pont par point : le juge voit une question et une seule réponse, puis attribue une note, généralement sur une échelle de Likert allant de 1 à 5.

La notation par points est également appelée évaluation directe ou notation à réponse unique. Dans les deux cas, il est possible de s’appuyer sur des références en ajoutant une réponse reconnue comme correcte à la question posée au juge, afin qu’il puisse la comparer plutôt que de se fier uniquement à ses propres connaissances. Un exemple public largement utilisé de juge guidé par des questions est AlpacaEval, un classement qui utilise LLM-as-a-Judge pour prédire les préférences humaines entre les sorties des modèles et qui publie toutes ses questions d’évaluation, y compris les versions antérieures.

Choix du système de notation

Aucune méthode de mise en place ne fonctionne partout ; le choix approprié dépend de l’application. Les jugements par paires ont tendance à être plus stables, car comparer deux éléments est plus facile que de placer un seul élément sur une échelle absolue. Le prix à payer est le biais de position, c’est-à-dire la tendance à privilégier la réponse qui apparaît en premier (ou en deuxième), ainsi qu’une scalabilité moindre : les résultats par paires ne vous indiquent que le classement relatif des sorties, et comparer de nombreux systèmes nécessite de nombreuses paires. La notation point par point est plus polyvalente, car chaque sortie reçoit sa propre note qui peut être stockée, moyennée et comparée ultérieurement. Elle est également plus difficile pour le juge, car celui-ci doit fonder sa note uniquement sur son propre sens de la qualité. Fournir une réponse de référence est un moyen courant de rendre la notation point par point plus fiable.

La nature du critère est également importante. Les propriétés objectives telles que la factualité ou la fidélité au document source ont tendance à être binaires : la réponse est fidèle ou elle ne l’est pas. Demander quelle des deux réponses est « plus fidèle » est mal défini. Les critères subjectifs, tels que l’utilité, le ton ou les préférences globales, sont ceux où les jugements relatifs se révèlent pertinents, car les personnes et les modèles trouvent que les comparaisons sont plus faciles et plus reproductibles que les évaluations absolues. Une valeur par défaut raisonnable consiste en une notation pointuelle, souvent binaire, pour les vérifications objectives et en des comparaisons par paires pour la qualité subjective.

Les biais hérités de tout juge

Quel que soit le type de juge utilisé, qu’il s’agisse d’un modèle générique ou d’un modèle affiné, un certain nombre de biais systémiques réapparaissent sans cesse, et la plupart des techniques d’affinage présentées plus loin dans cet article visent justement à les combattre. Il est utile de connaître leur nom avant de continuer la lecture :

• Biais de position : en mode par paires, le juge favorise la première ou la deuxième réponse indépendamment du contenu.
• Biais de longueur ou d’élaboration : les réponses plus longues et plus détaillées obtiennent de plus hautes notes, même lorsque le texte supplémentaire n’ajoute rien.
• Biais d’autosatisfaction : un juge préfère les réponses écrites par lui-même ou par des modèles de la même famille.
• Biais de connaissance : le juge ne peut pas évaluer la justesse des réponses sur des sujets qu’il ne maîtrise pas bien, et peut récompenser des réponses confiantes mais fausses.
• Biais de format : le juge ne fonctionne que lorsque l’instruction ressemble exactement à celle pour laquelle il a été conçu ou ajusté.

Aucun de ces facteurs ne peut être entièrement éliminé, mais chacun peut être mesuré. Changer l’ordre des candidats, compléter une réponse avec du texte de remplissage inoffensif, ou évaluer le même contenu selon deux modèles d’instruction constituent des expériences simples qui révèlent dans quelle mesure un juge donné est influencé par des facteurs qui ne devraient pas compter. Les effectuer une fois lors de l’adoption d’un juge, puis à nouveau après toute modification de son modèle ou de ses instructions, fait partie des habitudes les plus utiles dans le travail d’évaluation.

Où les juges pilotés par des instructions manquent

LLM-as-a-Judge est efficace et largement adopté, mais faire appel à un modèle propriétaire présente de réels inconvénients :

• Le modèle est une boîte noire, et l’envoi de données d’évaluation à un tiers peut soulever des problèmes de sécurité et de confidentialité.

Vous n’avez pas de contrôle sur la gestion des versions. Le fournisseur peut mettre à jour le modèle sous-jacent, ce qui peut faire varier ou cesser de fonctionner vos résultats d’évaluation sans que vous ne fassiez rien.

Chaque évaluation correspond à une appel API, ce qui rend coûteux l’analyse de grandes quantités de résultats.

Ces modèles performent le mieux sur des tâches d’évaluation similaires à celles utilisées lors de leur entraînement, comme la prédiction des préférences humaines générales, et moins bien sur des critères spécialisés.

Les assistants polyvalents ne sont pas conçus spécifiquement pour la critique, et ils ont tendance à être prudents, évitant des notes élevées ou des opinions tranchées.

Tous ces problèmes découlent du fait que vous dépendez d’un modèle que vous ne pouvez ni inspecter ni modifier. Cela soulève naturellement la question de savoir s’il est possible d’entraîner son propre évaluateur. La recherche présentée ci-dessous répond par l’affirmative : un évaluateur affiné peut fournir des retours plus précis, adaptés au domaine concerné et plus critiques, à condition d’investir dans les données nécessaires.

Méta-évaluation : évaluer le juge lui-même

Au préalable de l’entraînement d’un juge, déterminez comment vous saurez s’il est efficace. La réponse réside dans un ensemble de données d’évaluation étiquetées par des humains en qui vous avez une grande confiance, car celles-ci deviennent la référence pour tous les juges que vous créerez. La méta-évaluation, c’est-à-dire l’évaluation de l’élément d’évaluation, consiste donc à faire fonctionner le juge sur ces données et à comparer ses verdicts à ceux des humains.

Si le juge produit un résultat binaire, tel qu’un choix entre deux options ou une note de réussite/échec, vous pouvez utiliser des métriques de classification classiques comme la précision, la récurrence, le taux de faux négatifs et la courbe ROC. Comme ces métriques sont très faciles à interpréter, de nombreux professionnels estiment que la notation binaire constitue la conception la plus pratique pour les juges basés sur des LLM en général.

Pour les scores non binaires, tels qu’une échelle de Likert allant de 1 à 5, on mesure dans quelle mesure les scores des juges correspondent aux scores humains. À titre de référence, une étude menée par G-Eval a indiqué qu’un évaluateur basé sur GPT-4 avait atteint une corrélation de Spearman de 0,514 avec les humains dans un test de résumé, ce qui dépassait à l’époque de loin les méthodes précédentes. La corrélation de rang de Spearman est probablement le choix le plus courant, mais on trouve également la tau de Kendall, la corrélation de Pearson et le kappa de Cohen utilisés comme indicateurs d’accord. Ceux-ci sont plus difficiles à interpréter que les métriques de classification, il convient donc d’en connaître les particularités. La corrélation de Pearson mesure l’accord linéaire et est sensible aux valeurs atypiques ; Spearman et Kendall ne se soucient que de l’ordre, de sorte qu’un juge qui est systématiquement un point trop généreux peut tout de même obtenir une note parfaite avec eux.

Habitudes pratiques de méta-évaluation

Quelques habitudes rendent la méta-évaluation bien plus informative. Présentez les résultats d’accord par critère plutôt qu’un seul chiffre global, car un juge peut être excellent pour détecter les erreurs factuelles mais médiocre pour évaluer le ton, et une moyenne masque ce fait. Examinez séparément les confusions entre scores adjacents et les désaccords majeurs : un juge qui donne 4 alors que les humains donnent 5 représente un problème très différent de celui où il donne 1. Comparez l’accord entre le juge et les humains avec l’accord entre les humains eux-mêmes sur les mêmes éléments ; si deux annotateurs formés ne s’accordent que à 70 % des fois, un juge qui est d’accord avec eux à 68 % se situe essentiellement au plafond, et chercher davantage est inutile. Enfin, gardez l’ensemble de la méta-évaluation strictement séparé de tout ce qui est utilisé pour rédiger des prompts ou former le juge, sinon les chiffres le flatteront inutilement.

La première génération de juges affinés

Dès les débuts, presque tout le monde utilisait des modèles propriétaires pour l’évaluation de type juge, et cela avait une bonne raison. À moins de fournir au juge une réponse de référence, il doit être capable de résoudre la tâche lui-même afin de distinguer une bonne réponse d’une mauvaise. Les modèles ouverts étaient longtemps en retard par rapport aux modèles fermés, si bien que ces derniers constituaient simplement de meilleurs évaluateurs. La situation a changé avec l’apparition de modèles de base ouverts plus puissants tels que LLaMA et LLaMA-2, que les chercheurs ont commencé à affiner pour en faire des évaluateurs spécialisés. Les articles ci-dessous retracent cette première vague.

Un juge Vicuna affiné dans l’article MT-Bench

Le même article qui a présenté LLM-as-a-Judge a également publié l’un des premiers essais avec un juge affiné. La majeure partie de ces travaux porte sur l’utilisation de modèles propriétaires avec des templates génériques pour prédire les préférences humaines, mais une courte annexe explore l’entraînement d’un modèle open source à cette fin, concluant qu’un Vicuna-13B affiné semblait prometteur en tant que solution open source peu coûteuse alternative aux juges propriétaires.

Les motivations énumérées restent les principales raisons de considérer un juge personnalisé aujourd’hui :

• L’évaluation via une API payante devient coûteuse à grande échelle.
• Un modèle propriétaire ne offre ni contrôle ni transparence.
• Les modèles open source deviennent de plus en plus performants, ce qui réduit l’écart.

Si un juge open source affiné pouvait atteindre la même qualité que les modèles propriétaires, ces trois problèmes disparaîtraient.

L’expérience a utilisé Vicuna-13B, un dérivé de LLaMA. Dès son utilisation initiale, il s’est révélé être un juge médiocre : il présentait un taux d’erreur élevé, échouait souvent à suivre le modèle d’évaluation ou les instructions, et montrait un fort biais de position. Le fine-tuning a considérablement changé la situation. Le modèle a été entraîné sur 20 000 votes humains en une seule interaction provenant de Chatbot Arena, chacun comparant les résultats de divers modèles, et la tâche a été simplifiée en une classification à trois options : la première réponse gagne, perd ou fait match nul. Après l’entraînement, le biais de position a fortement diminué et la concordance avec les votes humains s’est nettement améliorée, bien que le modèle fine-tuné n’ait toujours pas atteint le niveau de GPT-4.

Formuler la tâche comme une classification à trois voies constitue une simplification judicieuse. Elle élimine la nécessité de calibrer des scores numériques, correspond directement à la manière dont les votes d’Arena sont collectés, et permet de calculer facilement la précision en comparaison avec des votes humains de référence. L’inconvénient est que le juge ne fournit aucune explication, ce qui signifie qu’en cas de désaccord avec les humains, on en apprend peu sur les raisons.

Toute cette exploration occupe à peine une page, mais les résultats étaient suffisamment encourageants pour lancer des travaux sur des évaluateurs ouverts.

PandaLM : un juge pour choisir entre des points de contrôle de modèle

Une utilisation fréquente des juges concerne le choix du modèle : parmi plusieurs modèles candidats, lequel est le meilleur ? Cela devient difficile lorsque tous les candidats sont performants et ne diffèrent que légèrement. Les humains peuvent prendre cette décision, mais lentement ; un juge capable de détecter fiablement de petites différences de qualité est donc précieux.

PandaLM a été conçu précisément pour cela. Son objectif dépasse le simple contrôle de la correction d’une réponse ; il prend également en compte des qualités subjectives telles que la concision relative, la clarté, l’exhaustivité, le degré de formalité et le respect des instructions. L’application principale est l’ajustement des hyperparamètres. On entraîne plusieurs variantes d’un modèle avec différentes configurations, on laisse PandaLM comparer leurs résultats et on retient la configuration gagnante. Dans les expériences présentées dans l’article, chaque modèle ajusté de cette manière a performé mieux que avec les paramètres par défaut, ce qui montre qu’un évaluateur peut influencer directement les décisions d’entraînement au lieu de se contenter de produire des rapports.

Le jeu de données d’entraînement contient plus de 300K d’exemples. Chaque entrée est une tupule de (instruction, input, response1, response2) et chaque cible est une tupule de (résultat d’évaluation, justification de l’évaluation). Chaque exemple dispose d’une réponse de référence, et le résultat indique soit la meilleure réponse, soit qu’il s’agit d’un match nul. L’équipe a affiné les modèles LLaMA de différentes tailles à l’aide de ces données en utilisant une simple prédiction du token suivant avec une perte de croisement entropique, dans un style séquence à séquence, sans tête de classification distincte. En d’autres termes, le verdict et l’explication ne sont que du texte que le modèle apprend à générer.

Lorsque PandaLM est comparé à d’autres évaluateurs, y compris GPT-3.5 et GPT-4, leurs préférences suivent des tendances similaires : ils classent les modèles évalués dans un ordre cohérent. En confrontation directe avec des juges propriétaires, la version 7B de PandaLM est compétitive, tandis que la version 70B dépasse GPT-4 selon l’évaluation présentée dans l’étude, ce qui suggère que la capacité d’évaluation, comme la plupart des compétences, s’améliore avec l’ampleur.

PandaLM se montre également performant dans des domaines spécialisés. L’étude l’a appliqué aux réponses aux questions du LSAT ainsi qu’aux ensembles de données de réponse à des questions biomédicales, où la version plus grande a particulièrement bien performé. Comme il a été entraîné spécifiquement sur des données d’évaluation, il peut être transféré à des tâches d’évaluation propres à un domaine proche de sa distribution d’entraînement, et non seulement à des évaluations de chat générales.

JudgeLM : qu’est-ce qui fait réellement un bon juge affiné

La plupart des juges affinés initiaux ont peu parlé des raisons pour lesquelles ils fonctionnaient. JudgeLM a cherché à étudier systématiquement les facteurs en jeu, notamment :

• la quantité de données d’entraînement utilisées, ainsi que leur qualité et leur diversité ;
• la taille et la qualité du modèle de base ;
• l’impact des biais sur les verdicts du juge ;
• la capacité du juge à s’adapter à d’autres formats, tels que les conversations en plusieurs tours, l’évaluation avec une seule réponse, le classement par paires et les entrées multimodales.

Un juge affiné peut être inférieur à un modèle propriétaire pour de nombreuses raisons : un modèle de base faible, des données bruitées, des biais systématiques, etc. La valeur de JudgeLM réside dans le fait qu’il montre que ces problèmes peuvent être résolus directement.

L’ingrédient le plus important est un ensemble de données volumineux, de haute qualité, détaillé et diversifié. L’équipe JudgeLM a explicitement présenté son ensemble de données comme le plus diversifié et de la meilleure qualité disponible à l’époque. Il part de 105 000 instructions de base tirées de sources publiques telles que ShareGPT, ainsi que d’une version des données Alpaca contenant des réponses générées par GPT-4.

Pour chaque instruction de base, des réponses sont générées par plusieurs modèles, dont Alpaca, Vicuna et LLaMA, puis combinées avec la réponse originale provenant de l’ensemble de données source. Ainsi, chaque instruction se voit attribuer plusieurs réponses candidates ainsi qu’une référence. Des paires de réponses sont ensuite sélectionnées au hasard, GPT-4 évalue chaque paire et explique sa logique. GPT-4 agit donc en quelque sorte comme un enseignant : JudgeLM apprend à reproduire ses jugements.

Les modèles de notation GPT-4 existent en deux variantes, avec et sans réponse de référence. Ils ressemblent beaucoup aux prompts standard utilisés par les juges publics, avec une différence importante : ils détaillent des critères d’évaluation assez précis. Cela pousse GPT-4 à effectuer des évaluations plus fines, et le réglage fin sur ces évaluations transmet cette même précision à JudgeLM.

JudgeLM a été entraîné avec 7B, 13B et 33B de paramètres, sur des ensembles de données allant de 3,5K à 100K d’exemples, en utilisant un réglage par instructions associé à un ajustement fin supervisé (SFT). L’entrée comprend une instruction, deux réponses candidates et une réponse de référence. Le modèle génère une note distincte pour chaque réponse, suivie d’une justification. Il est alors très simple de transformer cela en verdict par paire : la réponse ayant la note la plus élevée gagne, et en cas d’égalité, c’est un match nul. Un avantage supplémentaire de cette conception est qu’un seul modèle peut servir à la fois de correcteur et de comparateur.

La réduction des biais était un objectif central. JudgeLM vise trois types de biais :

1. Biais de position : préférer une réponse en fonction de sa place dans le prompt plutôt que du contenu qu’elle contient.
2. Biais de connaissance : le modèle de base manque des connaissances acquises lors du préentraînement nécessaires pour évaluer correctement la réponse.
3. Biais de format : le juge ne fonctionne bien que lorsque le prompt correspond exactement au format utilisé lors du finetuning.

Chacun de ces problèmes dispose d’une solution assez directe. Le biais de format diminue lorsque le juge voit plusieurs formats d’entrée pendant l’entraînement. Le biais de connaissance diminue lorsque l’on fournit au juge une réponse de référence, ce qui lui évite de devoir connaître les faits par lui-même. Le biais de position est géré par le changement de position : chaque paire est évaluée dans les deux ordres, tant lors de la création des données d’entraînement que au moment de l’inférence. Si le verdict change lorsque l’ordre change, la paire est généralement considérée comme nulle. Le changement de position pendant l’entraînement apprend au modèle à se concentrer sur le contenu plutôt que sur la disposition, tandis que le changement lors de l’inférence limite tout biais restant. Utilisées ensemble, ces techniques réduisent considérablement le biais de JudgeLM.

Il convient de garder à l’esprit le coût lié au changement de position lors de l’inférence : cela double le nombre d’appels aux juges nécessaires pour une évaluation par paires. Cela est généralement acceptable pour de grandes évaluations hors ligne, mais pas nécessairement pour des utilisations en ligne sensibles à la latence.

Sur son propre ensemble d’évaluation, JudgeLM bat PandaLM et GPT-3.5, que ce soit avec ou sans réponses de référence. Cette comparaison favorise JudgeLM, car il a été entraîné sur des données provenant d’une distribution presque identique, mais il performe également bien sur l’ensemble d’évaluation de PandaLM. Il convient de noter que une grande partie des performances rapportées pour JudgeLM correspond à une concordance avec GPT-4, le même modèle qui a généré ses étiquettes d’entraînement, et non à une concordance avec des humains. Dans l’ensemble, les modèles offrent des performances solides, s’améliorent à mesure qu’ils deviennent plus volumineux, et sont plus résistants aux changements de position que les alternatives.

Cela indique une limite générale des juges issus de distillation. Lorsqu’un modèle étudiant est entraîné sur les verdicts d’un juge, la précision de ce dernier agit comme un plafond souple, et ses points aveugles ainsi que ses biais sont transmis en même temps que ses forces. Un haut degré d’accord avec GPT-4 montre que la distillation a fonctionné ; cela ne signifie pas pour autant que le juge est d’accord avec vos utilisateurs. Seul un ensemble de test étiqueté par des humains peut répondre à cette seconde question.

Auto-J : basé sur des requêtes réelles d’utilisateurs

Auto-J, issu de l’article « Generative Judge for Evaluating Alignment », est un autre évaluateur affiné, axé sur l’évaluation selon des scénarios spécifiques dans des environnements réalistes. Ses caractéristiques distinctives sont :

• Il prend en charge à la fois les comparaisons par paires et l’évaluation à réponse unique.
• Il privilégie les critiques en langage naturel bien structurées et de haute qualité.

Ses requêtes d’entraînement proviennent de personnes réelles, ce qui permet aux données de refléter la diversité des questions que reçoit réellement un modèle.

Le résultat est un juge flexible, interprétable et pratique.

Les données d’Auto-J commencent par la définition de scénarios, chacun ayant sa propre définition et ses critères d’évaluation. L’étude retient 58 scénarios regroupés en huit catégories plus larges. Pour chaque scénario, des requêtes de vrais utilisateurs sont collectées, des réponses sont générées, et GPT-4 produit les jugements. GPT-4 s’appuie sur des critères rédigés à la main spécifiques à chaque scénario, et les résultats sont post-traités à l’aide de filtres heuristiques et d’une normalisation du format afin de réduire le bruit. Chaque scénario contribue jusqu’à 100 exemples, pour un total d’environ 3 500.

Les requêtes proviennent principalement de sources publiques basées sur l’interaction humaine, telles que Chatbot Arena et WebGPT. Comme elles reflètent ce que les gens demandent dans la réalité, Auto-J se spécialise dans une évaluation réaliste. Les étiquettes, tant en comparaison paire qu’en réponse unique, sont générées par GPT-4, et des filtres éliminent les prédictions incohérentes ou mal formatées.

Auto-J a été affiné à partir de LLaMA-2-13B-Chat sur cet ensemble de données de format mixte. Une décision de conception intéressante consiste à ne pas inclure les critères d’évaluation dans l’entrée. La raison en est que le modèle devrait absorber ces critères implicitement à partir des données, ce qui en ferait un modèle plus général. Des travaux ultérieurs, notamment Prometheus, sont parvenus à une conclusion opposée et ont montré qu’il était important d’intégrer des grilles d’évaluation et d’autres matériaux de référence dans le processus d’évaluation. Afin de contrer les biais liés aux préjugés, Auto-J utilise une simple méthode d’augmentation : chaque exemple en paire est dupliqué avec les deux réponses échangées, et les étiquettes « Réponse 1 » et « Réponse 2 » dans l’évaluation sont modifiées en conséquence.

L’ensemble de test Auto-J est structuré comme son ensemble d’entraînement, à ceci près que chaque étiquette provient d’annotateurs humains. Face à une série d’autres modèles, Auto-J surpasse presque tous, à l’exception de GPT-4. Cela confirme qu’un juge spécialisé formé sur des données adaptées au domaine peut rivaliser, voire parfois surpasser, les juges propriétaires dans son contexte d’application. Cependant, son taux de concordance absolue avec les humains sur cet ensemble de données reste faible, ce qui rappelle que la qualité générale des juges laisse encore beaucoup de place à l’amélioration.

Critiques, vérificateurs et générateurs de données synthétiques

Parallèlement à ces juges, une ligne de recherche étroitement liée a entraîné des modèles pour vérifier, critiquer ou fournir des retours sur les résultats d’un autre modèle. Tout comme les juges, ces modèles évaluent les réponses et expliquent leur raisonnement. La différence est que les critiques et les vérificateurs agissent également sur le verdict : ils révisent la réponse ou déclenchent une nouvelle tentative lorsque l’original ne répond pas aux exigences.

SelFee en est un bon exemple : il s’agit d’un modèle basé sur LLaMA, entraîné à partir de générations de ChatGPT, des retours de ChatGPT sur celles-ci, ainsi que de générations révisées. Face à une réponse, SelFee écrit des retours puis réécrit la réponse en se basant sur ces retours, et il peut continuer à itérer jusqu’à ce que le résultat atteigne un seuil de qualité. Cela en fait à la fois un vérificateur, car il contrôle ses propres résultats, et un critique, car il rédige des retours et effectue des modifications.

D’autres méthodes de critique ont été proposées, notamment l’auto-correction, PEER et des modèles d’autocritique. Le même mécanisme peut générer et filtrer des données d’entraînement synthétiques pour le SFT ou l’ajustement des préférences, comme dans RLAIF et Constitutional AI.

Vus de loin, tous ces systèmes – juges pilotés par des prompts, juges affinés, pipelines de données synthétiques, outils de critique et vérificateurs – font essentiellement la même chose : produire une note et une explication. Ce qui diffère, c’est l’usage de cette note, que ce soit pour évaluer la qualité du modèle ou pour décider quels échantillons intégrer un ensemble d’entraînement. Des travaux récents sur des vérificateurs génératifs et des modèles de récompense basés sur la critique soutiennent que certains de ces rôles peuvent être unifiés au sein d’un seul modèle capable de gérer toutes les tâches d’évaluation.

La famille Prometheus : des juges affinés qui rivalisent avec GPT-4

Les juges affinés n’ont vraiment gagné en popularité qu’avec Prometheus, un modèle conçu pour une évaluation fine et spécifique à un domaine. Sa méthodologie n’est pas radicalement nouvelle ; la grande différence réside dans un point de départ bien plus solide grâce à LLaMA-2 et dans un ensemble de données soigneusement conçu. Comme il égalait ou surpassait en qualité d’évaluation de nombreux juges propriétaires, il s’est rapidement répandu et a donné naissance à plusieurs variantes ultérieures.

Prometheus : les grilles d’évaluation en tant qu’entrée de premier ordre

Il est facile d’utiliser un juge propriétaire : il suffit de décrire les critères et de laisser le modèle travailler. Les problèmes sont ceux déjà évoqués, à savoir une versionning non contrôlée et des coûts élevés, ainsi que le fait que ces modèles sont principalement entraînés sur des critères génériques tels que la préférence humaine globale, ce qui peut poser des difficultés avec des critères personnalisés. Prometheus résout cela grâce à un évaluateur affiné qui, une fois entraîné pour un domaine donné, peut égaler ou surpasser les juges propriétaires.

L’idée principale est que Prometheus prend en compte une grille d’évaluation personnalisée comme partie de ses données d’entrée, ce qui lui permet de s’adapter à de nouveaux domaines et critères sans avoir besoin d’un reconditionnement. Il est entraîné sur le Feedback Collection, un ensemble de données synthétiques créé à l’aide de GPT-4 couvrant de nombreuses tâches d’évaluation. Chaque exemple contient les mêmes éléments :

• Instruction : l’instruction donnée au modèle évalué.
• Réponse : la réponse de ce modèle, qui est celle qui est notée.
• Grille d’évaluation : des critères personnalisés décrivant la manière dont la réponse doit être jugée.
• Réponse de référence : une réponse exemplaire qui obtiendrait la meilleure note.
• Raisonnement : une explication du pourquoi de la note attribuée à la réponse.
• Note : une évaluation sur l’échelle de Likert de 1 à 5.

Une grille d’évaluation se compose de deux parties : une description générale du critère, et une explication de ce que signifie chaque note allant de 1 à 5. Cet ensemble d’informations permet au modèle d’évaluer avec un haut degré de détail et d’appliquer ce système à des situations qu’il n’a jamais vues auparavant. Le travail de Prometheus a été parmi les premiers à montrer dans quelle mesure un juge finement ajusté bénéficie de matériaux de référence riches dans ses données d’entrée, en particulier de réponses de référence.

La génération commence à partir de 50 grilles d’évaluation rédigées par des humains et s’effectue en trois étapes :

1. GPT-4, après avoir vu des exemples de ces grilles manuscrites, les développe pour en créer 1 000.
2. Pour chaque grille, GPT-4 rédige 20 instructions, ce qui donne un total de 20 000 instructions.
3. Pour chaque instruction, GPT-4 génère d’abord une réponse, puis des retours d’information à son sujet, et enfin une note, dans cet ordre.

Deux astuces d’équilibrage rendent les données plus utiles. Premièrement, GPT-4 génère cinq exemples d’entraînement par instruction, un pour chacune des notes allant de 1 à 5, ce qui assure une distribution uniforme des scores et empêche l’expert d’avoir tendance à attribuer systématiquement de hautes notes. Deuxièmement, ces exemples sont maintenus à des longueurs similaires afin que l’expert ne développe pas de biais en faveur des réponses longues, c’est-à-dire l’habitude de valoriser les réponses plus étendues quel que soit leur contenu.

Prometheus a été affiné à partir de LLaMA-2-13B-Chat en utilisant les ensembles d’évaluation Feedback Collection ainsi que MT-Bench et Vicuna Bench. Grâce à tout le matériel de référence fourni dans l’instruction, le modèle apprend par SFT à écrire d’abord son avis avant de produire la note. Cette séquence est intentionnelle et reflète l’affinage par chaîne de réflexion : la critique écrite devient le contexte sur lequel se base le modèle pour choisir un chiffre, plutôt qu’une justification ajoutée ultérieurement. L’équipe de Prometheus insiste également sur l’insertion d’un token séparateur spécial, [RESULT], entre l’avis et la note ; cela empêche les générations de dégénérer au moment de l’inférence et présente l’avantage pratique de faciliter fortement la lecture de la note.

Prometheus a été comparé à GPT-3.5, GPT-4 ainsi qu’à plusieurs modèles de base ouverts sur divers ensembles de données, afin d’évaluer à la fois sa concordance avec les scores humains et l’utilité de ses retours. Ses résultats ont atteint une corrélation de Pearson de 0,897 avec les évaluateurs humains, un niveau équivalent à celui de GPT-4 et bien supérieur à celui de GPT-3. Ainsi, un modèle affiné à l’aide de données d’évaluation de haute qualité pour un domaine donné peut atteindre, voire dépasser, le niveau de concordance avec les humains observé chez des modèles propriétaires bien plus volumineux.

Les retours sont également favorables. Dans 58,67 % des comparaisons, les évaluateurs humains ont préféré les retours de Prometheus à ceux de GPT-4, et dans près de 80 % des cas, ils ont préféré ceux de Prometheus à ceux de GPT-3.5. Lorsqu’on leur a demandé pourquoi, les évaluateurs ont souligné que Prometheus était plus critique et plus précis. L’étude résume cela en indiquant que GPT-4 a tendance à rester neutre et abstrait, tandis que Prometheus prend clairement position sur la qualité de la réponse. C’est là le bénéfice de la spécialisation : Prometheus n’est pas un assistant général formé pour être conciliant, c’est un modèle dont la seule fonction est de critiquer.

Prometheus 2 : un modèle pour l’évaluation point par point et en paires

Prometheus 2 poursuit cette lignée avec un autre évaluateur ouvert et détaillé qui prend en compte des critères personnalisés. Il vise deux faiblesses du modèle initial : la concordance avec les scores humains avait encore besoin d’amélioration, et, plus important encore, le premier Prometheus ne pouvait effectuer que des évaluations directes. Il était possible d’obtenir un classement en comparant deux scores point par point, mais ni Prometheus ni la plupart des évaluateurs ouverts antérieurs ne pouvaient comparer nativement deux réponses. Prometheus 2 combine ces deux modes au sein d’un seul modèle qui suit de près les performances des humains et de GPT-4 dans chacun d’eux.

Les exemples par paires dans Prometheus 2 diffèrent de ceux basés sur des évaluations directes à trois égards :

• Le matériel de référence ne contient pas de réponse de référence.
• Il se compose uniquement d’une description du critère d’évaluation.
• Les retours sont formulés différemment.

Dans le mode par paires, le retour d’information doit comparer les deux réponses, indiquer où elles diffèrent et utiliser ces différences pour justifier le choix d’une d’entre elles. La plupart des ensembles de données et modèles par paires antérieurs se fiaient à des critères génériques et fournissaient souvent simplement un verdict sans aucune explication comparative.

Afin d’entraîner cette compétence par paires, Prometheus 2 introduit la Collection de préférences, dérivée de la Collection de retours d’information. Comme cette dernière contient cinq réponses par instruction, une pour chaque score, il est possible de former tous les couples entre elles : dix paires par instruction. L’étiquette correspondant à chaque paire provient directement de la comparaison des deux scores Likert.

Puisque un retour d’information explicatif, de type chaîne de pensée, est au cœur de l’approche Prometheus, les étiquettes seules n’étaient pas suffisantes. GPT-4 a été invité à rédiger de nouveaux retours d’information pour chaque paire, en se concentrant sur ce que les deux réponses ont en commun et sur les points où elles divergent.

Il existe plusieurs façons d’obtenir un seul juge capable de gérer les deux modes d’évaluation :

• Utilisation de prompts : employer un modèle prêt à l’emploi avec des prompts différents pour chaque mode.
• Entraînement en format unique : entraîner un modèle par mode et utiliser celui qui convient le mieux.
• Entraînement conjoint : entraîner un seul modèle à partir d’un mélange des deux types de données.

Seul l’entraînement conjoint permet d’obtenir un modèle spécialisé couvrant les deux modes ; l’utilisation de prompts repose sur des modèles génériques, tandis que l’entraînement en format unique donne deux modèles. Une quatrième option consiste à entraîner les deux modèles en format unique puis à les combiner par fusion de modèles, ce que fait Prometheus 2. Deux évaluateurs sont entraînés séparément, l’un pour la collecte de retours et l’autre pour la collecte de préférences, et leurs poids sont combinés par une simple fusion linéaire pour créer un modèle capable d’évaluer des deux manières.

Le résultat notable est que le modèle fusionné surpasse à la fois le modèle entraîné conjointement et les modèles au format unique. Plusieurs méthodes de fusion ont été testées, notamment l’arithmétique des tâches, TIES et DARE. Les méthodes plus sophistiquées aident parfois ; avec Mixtral 8x7B comme base, par exemple, DARE a donné les meilleurs résultats. Cependant, une simple fusion linéaire avec un coefficient de 0,5, qui consiste simplement à moyener les poids des deux modèles, fonctionne bien dans la plupart des configurations et est facile à mettre en œuvre. Une explication possible à son efficacité est que les deux phases d’entraînement partent du même modèle de base et apprennent des compétences liées, de sorte que leurs poids restent dans une région compatible où la moyenne combine ces capacités au lieu de les détruire.

Prometheus 2 a été développé à partir de Mistral-7B et Mixtral 8x7B : des versions distinctes sont affinées sur chaque ensemble de données avant d’être fusionnées à l’aide de divers algorithmes. Les modèles résultants surpassent tous les autres évaluateurs open source dans un ensemble de tests d’évaluation directe et de comparaisons par paires. Leur corrélation de Pearson avec les évaluateurs propriétaires s’améliore de 0,2 sur l’ensemble des données, et dans les tests de classement par paires, ils réduisent d’environ la moitié l’écart par rapport à GPT-4.

Les gains semblent plus faibles en mode par paires, mais la comparaison y inclut des modèles de récompense ainsi que des évaluateurs ouverts. Les modèles de récompense, ces outils d’évaluation utilisés dans l’apprentissage par renforcement à partir des retours humains (RLHF), ne sont entraînés que pour les préférences par paires, ne fournissent aucun retour écrit et excellent dans l’exactitude des comparaisons par paires. Prometheus 2 montre également une meilleure cohérence entre les différents modes que d’autres évaluateurs : la réponse qu’il préfère dans une comparaison par paires reçoit généralement également la note la plus élevée lors d’une évaluation directe. Cette propriété est importante en pratique, car il est difficile de faire confiance à un juge dont les deux modes donnent des avis divergents.

Prometheus-Vision : évaluation des modèles langage-vision

Jusqu’à présent, tout portait sur les modèles uniquement textuels. Les modèles vision-langage (VLM), qui acceptent à la fois des images et du texte, sont devenus courants, tant sous forme propriétaire comme GPT-4V et Gemini, que sous forme ouverte comme LLaVA ainsi que les variantes visuelles de Llama 3.2. En dehors de cette modalité d’entrée supplémentaire, ils sont entraînés et structurés de manière très similaire aux modèles LLM textuels.

1. Si la réponse suit l’instruction, comme c’est le cas pour tout modèle LLM.
2. Si la réponse est fondée sur ce que l’image montre réellement.

Une solution de contournement consiste à convertir l’image en texte, par exemple à l’aide d’un modèle de sous-titrage ou de traitement d’image en texte, puis à transmettre cette description à un juge de texte tel que GPT-4 ou Prometheus. Cependant, des pipelines à plusieurs étapes de ce type entraînent des erreurs cumulatives : tout ce que le sous-titrage manque ne peut être évalué par le juge. Utiliser un VLM comme juge constitue une approche plus directe.

Prometheus-Vision est un évaluateur VLM open source. Des VLM propriétaires comme GPT-4V avaient déjà été utilisés comme juges pour d’autres VLM, mais Prometheus-Vision a été le premier VLM open source capable d’évaluer selon des critères détaillés et définis par l’utilisateur. En plus de la transparence et du contrôle offerts par un modèle open source, ses scores correspondent bien à ceux des juges humains et propriétaires, et il peut détecter des distinctions subtiles, comme distinguer une œuvre d’art authentique d’une parodie de celle-ci.

Lorsque le travail a été publié, il n’existait aucun ensemble de données de retours, de critiques ou de préférences pour entraîner un évaluateur VLM à haute précision, c’est pourquoi l’équipe en a créé un. La Perception Collection suit le même modèle que la Feedback Collection, et chaque instance comprend cinq parties d’entrée :

• Image : la photo que l’utilisateur fournit au VLM.
• Instruction : l’instruction textuelle de l’utilisateur.
• Réponse : la réponse textuelle du VLM à l’image et à l’instruction.
• Rubrique : des indications détaillées pour noter, incluant une description du critère ainsi que de chaque note sur l’échelle de 1 à 5.
• Réponse de référence : une réponse qui obtiendrait la note maximale de 5, générée avec GPT-4V.

Les résultats comprennent une justification écrite et une note allant de 1 à 5.

La construction reflète l’ensemble de données de texte. Le processus extrait 5 000 images des datasets MS-COCO et MMMU, rédige manuellement 50 grilles d’évaluation de base, utilise GPT-4 pour les développer en 15 000 grilles d’évaluation, génère 30 000 instructions accompagnées de réponses de référence correspondantes, puis ajoute cinq réponses par instruction, une pour chaque note, chacune étant accompagnée d’un retour d’information. Par rapport à la méthode de collecte des retours, on compte beaucoup plus de grilles d’évaluation (15 000 contre 1 000), mais bien moins d’instructions par grille (deux contre 20).

Un modèle de base ne contenant que du texte ne peut pas être utilisé ici ; l’entraînement doit partir d’un VLM pré-entraîné. Prometheus-Vision utilise les versions 7B et 13B de LLaVA-1.5. La méthode est le même affinage par chaîne de pensée que précédemment : l’entraînement supervisé enseigne au modèle à écrire des retours, puis à attribuer une note. Dans chaque exemple d’entraînement, ces deux parties sont séparées par l’expression fixe Donc la note globale est, qui remplit la même fonction que le token [RESULT] dans le modèle de texte. Avec des grilles d’évaluation et des réponses de référence en entrée, on obtient un modèle affiné pour une évaluation personnalisée et détaillée.

Prometheus-Vision présente une corrélation plus forte avec les scores humains que GPT-3.5-Turbo et que la version Prometheus ne contenant que du texte, mais GPT-4 et GPT-4V sont dans l’ensemble en meilleure adéquation avec les humains. Son résultat le plus faible se observe sur VisIT-Bench, qui contient de nombreuses images riches en texte. Là, GPT-4 performe bien, même mieux que GPT-4V, car il reçoit en entrée le texte extrait de l’image, tandis que Prometheus-Vision a du mal à le lire. Sur les autres tests, Prometheus-Vision est à peu près au même niveau que GPT-4 et GPT-4V, et dans plusieurs cas sa corrélation avec les humains est même plus forte que celle de ces deux derniers.

Les évaluateurs humains ont jugé ses réponses à peu près aussi bonnes que celles de GPT-4 et GPT-4V. L’équipe a également examiné les biais courants chez les évaluateurs, tels que le biais de longueur, qui consiste à privilégier des réponses plus longues, et le biais d’autosatisfaction, qui consiste à favoriser ses propres productions. Aucun signe évident de ces biais n’a été constaté, bien que l’on sache qu’il est en réalité très difficile d’isoler un seul biais de manière expérimentale.

Autres approches dans l’évaluation affinée

Prometheus n’est pas la seule initiative dans ce domaine. D’autres projets ont entraîné des modèles de langage pour l’évaluation, chacun apportant une idée distincte. Le bref aperçu ci-dessous couvre ceux qui sont les plus pertinents si vous concevez votre propre outil d’évaluation.

Modèles de langage auto-rémunérateurs

Les modèles auto-rémunérateurs visent à automatiser l’alignement avec l’aide d’un évaluateur interne. Au lieu d’entraîner un modèle de récompense distinct basé sur les préférences humaines, le modèle à aligner est lui-même entraîné à évaluer ses propres sorties à l’aide de prompts du type LLM-as-a-Judge, et ces évaluations deviennent la récompense. Appliqué à LLaMA-2, cette méthode a fourni des retours utiles et amélioré le modèle de base. Conceptuellement, il ressemble à Prometheus dans la mesure où le modèle apprend à agir en tant que juge, mais la sortie de ce juge est directement réutilisée comme signal d’entraînement pour le même modèle.

LLM-as-a-Meta-Judge

Une limitation des modèles à auto-rémunération est le fait que rien ne vient améliorer la compétence de jugement elle-même ; le modèle devient plus performant dans ses réponses, mais ses évaluations restent au même niveau qu’au début. Les modèles à méta-rémunération introduisent un troisième rôle. En plus d’agir en tant qu’acteur et juge, le modèle agit également en tant que méta-juge qui évalue ses propres jugements, ce qui génère des données d’entraînement permettant d’améliorer à la fois le juge et la politique. Ces deux capacités s’améliorent alors ensemble au fil des itérations d’entraînement.

Évaluateurs autodidactes

Les évaluateurs autoformés suppriment complètement les étiquettes de préférence humaine du processus. La collecte de données sur les préférences humaines est coûteuse et devient obsolète à mesure que les modèles s’améliorent ; donc cette approche génère itérativement des données d’évaluation synthétiques. À partir d’un ensemble d’instructions, un LLM produit des paires de résultats contrastés, l’un étant délibérément inférieur à l’autre, et un juge est formé pour les évaluer en rédigeant des explications et des verdicts. En répétant ce processus avec un juge amélioré, on obtient des données d’entraînement de meilleure qualité à chaque tour. Sans aucune donnée étiquetée par des humains, il a été rapporté que les évaluateurs ainsi créés surpassent tant le GPT-4 utilisé comme juge que les modèles de récompense entraînés sur des préférences humaines en termes de précision de notation.

La réserve évidente est la circularité. Un juge qui s’alimente de ses propres données d’entraînement peut tendre vers ce qu’il croit déjà être bon, et sans contrôle externe, cette dérive reste invisible. Même en adoptant un cycle d’auto-apprentissage, un petit ensemble de données étiquetées par des humains reste le seul moyen de confirmer que chaque itération améliore réellement les résultats plutôt que de se contenter d’accroître la confiance du système.

FLAMe : autorateurs fondamentaux

Les modèles fondamentaux de grande échelle pour l’évaluation (FLAMe) adoptent une approche inverse en ce qui concerne les données : ils sont entraînés sur un ensemble très vaste de jugements humains, plus de 5 millions au total, provenant de plus de 100 tâches d’évaluation de qualité. Par rapport à d’autres systèmes d’évaluation, les modèles FLAMe généralisent mieux aux tâches inédites, présentent moins de biais et constituent de bons points de départ pour un affinage ultérieur en modèles d’évaluation spécialisés. Ils se sont révélés systématiquement supérieurs aux modèles d’évaluation basés sur GPT-4 et les variantes de Claude, ainsi qu’aux modèles affinés à l’aide de données synthétiques GPT-4.

L’équilibre entre généralisation et spécificité

Optimisation de la préférence pour le jugement direct

L’optimisation directe des préférences d’évaluation applique cette optimisation aux évaluateurs plutôt qu’au SFT seul. Des paires de préférences sont recueillies pour trois cas d’usage : évaluation unique, comparaison par paires et classification binaire. Les deux premiers correspondent aux configurations habituelles point par point et par paires ; le troisième présente l’évaluation comme une question oui/non, par exemple pour déterminer si une propriété donnée est présente dans la réponse. Une tâche auxiliaire est également ajoutée : étant donné l’instruction et un résultat d’évaluation, le modèle doit déduire quelle réponse était évaluée. Pour chaque cas d’usage, un jugement bon et un jugement mauvais forment une paire de préférences, et l’évaluateur est entraîné à leur sujet grâce à l’optimisation directe des préférences (DPO). L’avantage réside dans le fait que l’évaluateur apprend non seulement à imiter les bons jugements, mais aussi à les préférer aux mauvais jugements plausibles.

Qu’est-ce qui influence les scores d’un évaluateur ?

Une question pertinente concernant tout juge basé sur un LLM est de savoir s’il applique réellement les critères qui lui sont donnés, ou s’il se contente de récompenser les textes ressemblant à ses données d’entraînement. Des analyses de juges LLM menées dans divers systèmes de notation ont montré que des instructions détaillées pour la notation dans le prompt n’améliorent leurs jugements que légèrement, et que la notation basée sur la perplexité, qui évalue une réponse en fonction de la probabilité qu’elle soit générée par le modèle, correspond parfois mieux aux jugements humains que les prompts eux-mêmes, en particulier pour la qualité textuelle.

Cela semble contredire la conclusion de Prometheus selon laquelle le matériel de référence est extrêmement important. Les deux résultats deviennent plus faciles à concilier une fois que l’on comprend ce qui était mesuré. Les analyses axées sur la perplexité se concentrent principalement sur la qualité générale des réponses du point de vue des préférences humaines. La plupart des LLM sont fortement entraînés à partir de données de préférences, il est donc naturel qu’ils attribuent une grande probabilité aux réponses que les gens apprécient. Prometheus, en revanche, vise une grande variété de critères personnalisés qui dépassent les préférences générales, et pour ceux-ci, des critères explicites fournissent des informations que le modèle ne peut pas déduire uniquement de la fluidité. Si vos critères correspondent à « quelle réponse les gens préfèrent-ils ? », les critères explicites apporteront peu d’ajout ; s’ils sont spécifiques à votre domaine, ils sont essentiels.

Une méthode pas à pas pour créer votre propre juge

Au vu du paysage de la recherche, il est utile de le structurer en un processus. Le travail de Prometheus propose déjà un cadre, et la version ci-dessous l’adapte légèrement pour intégrer les enseignements des autres articles.

Étape 1 : définir précisément les critères d’évaluation

Décidez en premier lieu de ce que vous comptez évaluer :

• Énumérez les critères spécifiques importants pour votre application.
• Rédigez une description détaillée de chacun d’eux, y compris la signification de chaque niveau de score.

La collecte de retours constitue un bon modèle de ce à quoi ressemble une telle grille d’évaluation, avec une description des critères, des descriptions par score et des réponses de référence. Prévoyez de réviser ces critères à plusieurs reprises. Au fur et à mesure que vous découvrez où les humains et les modèles sont en désaccord, vous affinerez et étendrez la grille d’évaluation, et chaque révision rendra l’évaluation humaine ainsi que celle basée sur les modèles plus cohérentes.

Étape 2 : collecter des étiquettes humaines de haute qualité

Au préalable du entraînement ou même avant d’utiliser un juge, vous avez besoin de données d’évaluation humaine fiables. Ce sont elles qui permettent de déterminer si un juge est précis, et elles doivent refléter les entrées auxquelles le juge sera confronté en environnement de production. Si les données servent uniquement à une méta-évaluation, par exemple pour valider un LLM utilisé comme juge, un ensemble modeste de 100 à 1 000 exemples suffit généralement. Le affinage d’un juge de type Prometheus nécessite quant à lui beaucoup plus d’exemples, soit entre 1 000 et 100 000 exemples.

La collecte de données humaines est difficile, et c’est précisément là que les équipes investissent le moins souvent. Si les personnes ne parviennent pas à s’accorder sur la tâche, il est impossible de déterminer si un modèle la réalise bien, et former un juge avec des étiquettes incohérentes gaspille tous les efforts fournis. Tout ce qui est indiqué dans la section d’évaluation humaine ci-dessus s’applique ici : calibrer les évaluateurs, maintenir des directives et continuer à mesurer le degré d’accord.

Étape 3 : enrichir avec des données synthétiques

Les modèles Prometheus montrent que des données synthétiques peuvent produire d’excellents juges : presque toutes leurs données d’entraînement, y compris les instructions, les réponses, les scores et les retours d’information, ont été générées par GPT-4. Les données purement synthétiques présentent un risque, car elles exposent le modèle à un éventail restreint d’entrées possibles et héritent des biais du modèle de référence. Le mélange de données étiquetées par des humains et de données synthétiques fonctionne généralement beaucoup mieux que l’un ou l’autre pris séparément. Utilisez l’ensemble de données humaines pour garantir la qualité et l’ensemble synthétique pour atteindre le volume et la couverture nécessaires au affinage, en appliquant les principes d’équilibrage issus de la collecte de retours, tels qu’une répartition équitable des scores et une longueur contrôlée des réponses, lors de leur génération.

Étape 4 : investir dans les justifications

Des notes et des classements précis sont évidemment nécessaires, mais les justifications méritent tout autant d’attention. On sait que le fine-tuning est une méthode peu efficace pour introduire de nouvelles connaissances dans un modèle ; ce qu’il fait bien, c’est enseigner le style et le format. Pour un juge, le format des retours constitue l’élément principal que l’on peut contrôler. Des justifications spécifiques, critiques et liées au critère d’évaluation permettent à celui-ci de fournir des explications réellement utiles. De plus, comme le modèle écrit les justifications avant les notes, de meilleures justifications ont tendance à soutenir de meilleures notes. Placez un séparateur fixe entre les retours et les notes afin que les résultats soient faciles à parser.

Étape 5 : ajoutez des réponses de référence là où c’est possible

Cette étape est optionnelle mais généralement utile. Les réponses de référence aident à la fois les juges qui reçoivent une instruction et ceux qui ont été affinés. Pour les juges affinés, elles compensent les biais de connaissance, comblant les lacunes dans ce que le modèle de base a appris lors du préentraînement, et rendent l’évaluation point par point nettement plus précise et stable. Pour les tâches factuelles ou nécessitant une grande expertise dans un domaine, une réponse de référence est souvent plus importante que la formulation même de l’instruction.

Étape 6 : entraînement et méta-évaluation

Avec les données, et éventuellement des réponses de référence, en place, entraînez le juge à l’aide de la méthode SFT standard. Le répertoire Prometheus propose une implémentation complète de ce processus. Conservez dès le début un ensemble de test composé de données étiquetées par des humains et utilisez-le pour la méta-évaluation : des métriques de classification si la sortie du juge est binaire, et des métriques de corrélation pour tout le reste. Pour les juges comparés deux par deux, mesurez également la fréquence à laquelle le verdict reste inchangé en cas de changement d’ordre ; un juge dont l’avis change lorsque l’ordre change n’est pas prêt.

Au avant de vous fier au juge, effectuez quelques vérifications supplémentaires :

• Évaluez-le sur des exemples hors distribution pour voir jusqu’où s’étend sa compétence.
• Comparez sa distribution de scores avec celle des humains afin de détecter une indulgence ou une sévérité systématiques.
• Examinez directement les effets de la longueur et de l’ordre, en variant la longueur de la réponse et l’ordre pour le même contenu.

Réexécutez la méta-évaluation chaque fois que les critères, les données d’entrée ou le modèle de base changent.

Quand ne pas procéder à un affinage

Une remarque sur les coûts et les opérations

Avoir un juge ne fait que déplacer les coûts au lieu de les éliminer. Vous échangez les frais API par appel contre du temps GPU, l’hébergement des modèles et les efforts techniques nécessaires pour maintenir la version du juge à jour et reproductible. En échange, vous obtenez une version de modèle fixe qui ne peut pas changer sous votre contrôle, des données d’évaluation qui ne quittent jamais votre infrastructure, ainsi que la capacité de réaliser des millions de jugements sans voir les factures augmenter. Traitez le juge comme n’importe quel autre modèle de production : fixez ses poids, enregistrez quelle version a produit quels scores, et conservez l’ensemble de métévaluation afin que un réentraînement futur puisse être comparé au modèle actuel sur des bases égales.

Points clés

• Les jugements humains restent le point de référence, mais uniquement après calibration ; des directives en cours d’actualisation et un suivi continu de l’accord permettent de les rendre suffisamment fiables pour en mesurer tout autre élément.

Les métriques d’overlap telles que ROUGE et BLEU présentent une faible corrélation avec la préférence humaine pour des résultats ouverts ; considérez-les comme de simples vérifications de base, et non comme des indicateurs de qualité.

Il est facile de commencer avec des juges propriétaires pilotés par des prompts, mais cela comporte des risques liés à la gestion des versions, des coûts élevés, des opinions mitigées et une performance inférieure pour des critères spécifiques.

Des juges affinés tels que PandaLM, JudgeLM, Auto-J et la famille Prometheus montrent que les modèles ouverts peuvent égaler ou dépasser GPT-4 dans leur domaine d’application, principalement grâce à une conception minutieuse des données : utilisation de grilles d’évaluation et de réponses de référence en entrée, retour d’information avant l’attribution de points, étiquettes équilibrées et permutation des positions.

La fusion de modèles offre un moyen simple de combiner des compétences ponctuelles et par paires au sein d’un seul juge, la simple moyenne pondérée fonctionnant bien dans la plupart des cas.

Les juges affinés sont spécifiques à une tâche donnée. Gardez-les proches de leur distribution d’entraînement et révérifiez-les à l’aide de labels humains lorsqu’un élément important change.