vectara/hallucination-leaderboard : mesurer l'hallucination en résumé de documents courts
Leaderboard Comparing LLM Performance at Producing Hallucinations when Summarizing Short Documents
En bref
- De quoi s’agit-il ?
- Le dépôt publie un classement de LLM évalués par le modèle HHEM de Vectara sur une tâche précise : résumer un document court sans inventer. Utile pour choisir un modèle de résumé, trompeur si on l'étend à d'autres usages.
- À qui s’adresse-t-il ?
- À adopter si vous devez choisir un modèle pour du résumé de documents courts et que vous voulez un point de comparaison reproductible. À éviter si votre charge réelle est du RAG multi-documents, du raisonnement long ou de l'extraction structurée : la tâche mesurée n'est pas la vôtre.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 127 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Ce que le classement mesure, et ce qu'il ne mesure pas
La tâche est étroite et assumée : on demande à un LLM de résumer un document court, puis on vérifie si le résumé contient des affirmations absentes de la source. Le README présente le projet comme un classement public calculé avec le Hallucination Evaluation Model de Vectara, abrégé HHEM. Chaque ligne du tableau correspond à un modèle, avec quatre colonnes : Hallucination Rate, Factual Consistency Rate, Answer Rate et Average Summary Length (Words).
Les deux premières colonnes sont complémentaires (1,8 % d'hallucination correspond à 98,2 % de cohérence factuelle). La troisième est celle qu'on regarde trop vite. Un modèle peut afficher un faible taux d'hallucination tout en refusant de répondre une fois sur trois. Dans le tableau du 11 mai 2026, snowflake/snowflake-arctic-instruct affiche 62,7 % de Answer Rate, contre 100,0 % pour openai/gpt-5.4-nano-2026-03-17. Comparer ces deux lignes sur la seule colonne d'hallucination n'a pas de sens.
Le périmètre est le résumé d'un document court. Rien dans le matériel fourni ne permet de dire que ce classement prédit le comportement d'un modèle en RAG sur plusieurs sources, en extraction de champs ou en dialogue multi-tours. C'est une mesure de fidélité à une source unique, pas une mesure générale de véracité.
HHEM comme juge, et la dépendance que cela crée
Le classement n'est pas produit par des annotateurs humains : il est calculé par un modèle d'évaluation développé par Vectara. Le dépôt est donc à la fois le banc de mesure et la vitrine du modèle qui mesure. Ce n'est pas un défaut en soi, mais cela signifie que le classement hérite des angles morts de HHEM. Si le juge rate une catégorie d'hallucination, tous les modèles évalués sont notés avec le même biais.
Vectara assume cette évolution. Le README renvoie vers deux versions antérieures : une première basée sur HHEM-1.0, conservée dans la branche hhem-1.0-final, et une version plus récente basée sur le jeu de données précédent, dans la branche hhem-2.3-old-dataset. Les chiffres publiés ne sont donc pas comparables d'une génération de HHEM à l'autre, ni d'un jeu de données à l'autre. Toute citation d'un taux d'hallucination doit préciser la version, sinon elle ne veut rien dire.
Le corollaire pratique : vous ne pouvez pas auditer facilement le juge à partir de ce dépôt seul. Vous pouvez auditer les modèles évalués, pas le barème.
Lire le tableau sans se tromper de colonne
Le tableau est trié par Hallucination Rate croissant, ce qui met en tête des modèles dont le comportement réel est très différent. Prenez les premières lignes de la mise à jour du 11 mai 2026 : antgroup/finix_s1_32b à 1,8 %, openai/gpt-5.4-nano-2026-03-17 à 3,1 %, google/gemini-2.5-flash-lite à 3,3 %, microsoft/Phi-4 à 3,7 %. Ce dernier affiche 80,7 % de Answer Rate, soit près d'une non-réponse sur cinq. Le classement le place quatrième, mais un pipeline de production qui attend un résumé systématique ne peut pas s'en contenter.
La colonne Average Summary Length (Words) est un autre piège. Les longueurs vont de 54,7 mots (openai/gpt-5.4-mini-2026-03-17) à 254,4 mots (openai/gpt-5.1-high-2025-11-13). Un résumé plus long offre mécaniquement plus d'occasions d'introduire une affirmation non étayée, et un résumé très court peut omettre l'essentiel sans pour autant halluciner. Le classement ne pénalise pas l'omission. Un modèle qui recopie presque la source obtient un bon score sans démontrer une vraie capacité de synthèse.
Le tri masque aussi la dispersion des familles. Les modèles qwen/qwen3 occupent des positions très étalées, de qwen/qwen3-8b à 4,8 % jusqu'à qwen/qwen3-235b-a22b à 9,3 %. La taille des paramètres n'ordonne pas la fidélité.
Mise en route : ce que le dépôt fournit réellement
Le dépôt est en Python, sous licence Apache-2.0, branche par défaut main. Le README ne documente pas de commande d'installation ni de script d'exécution : il décrit le classement, son historique de versions et publie le tableau entre les marqueurs LEADERBOARD_START et LEADERBOARD_END. Ces marqueurs indiquent une génération automatisée du tableau dans le README, mais le matériel fourni ne détaille ni le script ni le format d'entrée.
Ce que le README donne, c'est l'accès aux résultats : un lien vers l'espace interactif hébergé sur Hugging Face, à l'adresse huggingface.co/spaces/vectara/leaderboard, et des liens vers les branches d'archives hhem-1.0-final et hhem-2.3-old-dataset. Si vous voulez seulement consulter les taux, le Space suffit. Si vous voulez reproduire la mesure, il faut lire le code du dépôt, car la procédure n'est pas décrite dans le README.
Aucune release n'est récupérée dans les métadonnées. Il n'y a donc pas de version épinglée à citer : le suivi se fait par commit sur main, et le tableau lui-même porte sa date de mise à jour, ici le 11 mai 2026. Pour un usage en documentation interne, citez cette date plutôt qu'un numéro de version.
Un instantané, pas une garantie de stabilité
Le README annonce une mise à jour régulière du classement, au rythme des évolutions du modèle d'évaluation et des LLM. C'est une qualité pour la fraîcheur, une contrainte pour la reproductibilité. Un modèle peut changer de version côté fournisseur sans que son nom change, et le tableau peut bouger d'une publication à l'autre sans qu'aucun changelog ne l'explique.
La liste des modèles évalués mélange des poids ouverts (microsoft/Phi-4, meta-llama/Llama-3.3-70B-Instruct-Turbo, ibm-granite/granite-4.0-h-small) et des endpoints propriétaires (openai/gpt-5.4-nano-2026-03-17, anthropic/claude-sonnet-4-6, amazon/nova-pro-v1:0). Pour les seconds, vous ne pouvez pas vérifier que le modèle servi au moment de votre test est celui qui a été noté. C'est une limite structurelle de tout classement d'API, pas une erreur du projet.
Autre point : la tâche de résumé de documents courts est celle où les hallucinations sont les plus faciles à détecter automatiquement, parce que la source est intégralement disponible et bornée. Les taux affichés ici, souvent sous 10 %, ne se transposent pas à des tâches où la vérification est plus difficile. Un modèle à 3 % sur ce banc peut produire bien davantage d'affirmations non étayées dans un contexte long.
Face à un harnais d'évaluation maison
L'alternative directe n'est pas un autre classement, c'est votre propre jeu de test. La différence d'approche est nette. Ici, un juge unique, HHEM, note tous les modèles sur un corpus commun, ce qui donne une comparaison transversale et bon marché à consulter. Un harnais maison construit sur vos documents vous donne des chiffres non comparables à ceux du voisin, mais pertinents pour votre domaine, votre longueur de document et votre définition de ce qu'est une hallucination tolérable.
Le compromis se joue sur deux axes. Le classement de Vectara couvre des dizaines de modèles que vous n'évaluerez jamais vous-même, avec un protocole identique pour tous. Votre harnais couvre trois ou quatre modèles, mais il mesure ce qui compte pour vous, y compris l'omission, que le leaderboard ne capture pas.
Si vous cherchez un classement public comparable, il n'existe pas d'équivalent évident cité dans ce dépôt. La page d'accueil du projet pointe vers vectara.com, et le seul artefact de comparaison est l'espace Hugging Face. Vous pouvez réutiliser HHEM comme juge dans votre propre harnais, ce qui aligne vos mesures sur celles du classement tout en changeant le corpus. C'est probablement l'usage le plus défendable du dépôt.
Coût de suivi et cadre de licence
Le coût de maintenance du dépôt lui-même vous concerne peu si vous ne faites que lire le tableau : il n'y a pas de dépendance à installer, pas de service à héberger. Le coût réel est celui de la relecture. Chaque mise à jour peut déplacer des modèles de plusieurs points, et le README signale explicitement que les versions successives de HHEM ne sont pas comparables entre elles. Si vous citez ces chiffres dans une décision d'architecture, vous devez noter la date de mise à jour et la génération de HHEM, comme le fait le README en séparant ses branches.
La licence Apache-2.0 couvre le code du dépôt. Elle ne dit rien des modèles évalués, qui ont leurs propres conditions, ni du modèle HHEM lui-même, dont les termes d'utilisation ne sont pas détaillés dans le matériel fourni. Avant de réutiliser HHEM comme juge dans un produit, lisez les conditions attachées à ce modèle précis : le README ne les expose pas. Ce paragraphe n'est pas un avis juridique, seulement un repérage des zones à vérifier.
Un point de gouvernance mérite d'être noté : le projet est maintenu par Vectara, qui édite aussi le modèle d'évaluation. Le classement n'est pas neutre au sens où un organisme indépendant le serait. Cela ne l'invalide pas, mais cela doit figurer dans la façon dont vous le présentez en interne.
Conclusion éditoriale
À adopter si vous devez choisir un modèle pour du résumé de documents courts et que vous voulez un point de comparaison reproductible. À éviter si votre charge réelle est du RAG multi-documents, du raisonnement long ou de l'extraction structurée : la tâche mesurée n'est pas la vôtre. Avant de vous appuyer sur une ligne du tableau, vérifiez le taux de réponse du modèle et la version du jeu de données indiquée dans le README, puis reproduisez la mesure sur vos propres documents.
Notes de la communauté