Lire les fiches, licences et évaluations des modèles
Une même famille de modèles publie souvent en même temps une version de base, une version instruite et des fichiers quantifiés sur 4 bits : ce sont trois objets différents. Avec un mauvais modèle de conversation (chat template), ou une entrée tronquée sans prévenir, un bon modèle répond mal et paraît incapable. Choisir un modèle revient donc à demander si une version précise peut accomplir une tâche sous des contraintes données. Nom, nombre de paramètres et classement global sont des repères ; les preuves utiles concernent les entrées et sorties, les conditions d’entraînement et d’évaluation, ainsi que les artefacts reproductibles.
Les Model Cards proposent de documenter les usages visés et les performances dans différentes conditions. Une fiche ouvre l’enquête ; elle ne certifie pas la qualité.
Identifier l’artefact
Une famille peut publier des poids de base, des variantes d’instructions, des distillations et plusieurs quantifications. Des noms proches ne garantissent ni mêmes templates, ni mêmes comportements, ni mêmes besoins matériels. La documentation des fiches Hugging Face décrit la coexistence du texte et des métadonnées. Résoudre ces questions pour une version exacte :
Distinguer paramètres totaux et actifs, notamment pour les MoE. Lire le contexte maximal avec la configuration réelle et le coût du cache.
Distinguer licences du logiciel et des poids
Un dépôt peut contenir code, poids et références de données. Le champ de licence aide à trouver les conditions ; ouvrir néanmoins le texte et la documentation de publication pour identifier l’artefact concerné. La documentation des licences de dépôt explique ces métadonnées. La licence du code d’enveloppe ne détermine pas celle des poids, des données amont ou du service hébergé.
Conserver version ou révision avec les fichiers utilisés. Si le modèle change sous le même nom, un lien de téléchargement ne reproduit pas la comparaison initiale. Pour une API, noter la date et les informations de version disponibles.
Un classement ne répond pas à toutes les questions
HELM évalue les modèles selon plusieurs scénarios et métriques. Lire l’objet de l’évaluation avant de chercher un vainqueur. Exactitude, calibration, latence, débit et coût répondent à des questions différentes ; leur combinaison suppose un objectif d’application défini.
Supposons deux candidats évalués sur les mêmes 100 exemples :
A obtient 90%, B 92%. Tout l’écart de deux points vient des 10 exemples où ils divergent : A en gagne 4, B en gagne 6. Sur les 90 autres, ils ont tous deux raison ou tous deux tort. Si les deux modèles se valaient vraiment, ces 10 exemples se comporteraient comme 10 lancers de pièce. Un partage exact 5–5 a une probabilité de 252/1024, environ une sur quatre ; dans les trois quarts restants, le partage est de 4–6 ou plus déséquilibré (test des signes, p≈0,75). L’écart de deux points ne prouve donc rien à lui seul.
Le coût des erreurs peut aussi changer la conclusion. Si les six échecs de A ne sont que de petites fautes de format, alors que les quatre échecs de B perdent des faits essentiels, l’écart de deux points ne justifie pas de choisir B. À coûts d’erreur comparables, il reste à reproduire la différence sur de nouveaux exemples.
Distinguer une réponse du modèle et le résultat final du système : recherche documentaire, outils, candidats multiples, nouvelles tentatives, budget de raisonnement ? Davantage de calcul peut modifier qualité et latence ; toutes les différences entre systèmes ne viennent pas des poids.
Les résultats publiés par d’autres se lisent de la même façon. D’abord, qui les a obtenus : le fournisseur lui-même, ou un tiers qui les reproduit ? Ensuite, quel système a été mesuré : le harnais, le nombre de nouvelles tentatives et le budget de raisonnement sont-ils indiqués ? Puis, les concurrents ont-ils été évalués sur les mêmes items, avec la même configuration, et l’écart dépasse-t-il le bruit de pile ou face montré plus haut ? Enfin, les items figuraient-ils peut-être déjà dans les données d’entraînement ? Si l’une de ces questions reste sans réponse, le score est une piste, pas encore une base de décision. La liste complète des biais courants (contamination, biais de sélection, biais du fournisseur…) et une manière d’écrire une affirmation sous forme de fiche vérifiable se trouvent dans Juger les preuves dans les expériences d’IA.
Réduire les candidats par des tâches réelles
Choisir des tâches de difficultés et de coûts d’erreur variés, en excluant les données sensibles ou en obtenant l’autorisation appropriée. Fixer entrées et critères de réussite, garder une référence peu coûteuse : règles ou petit classificateur, recherche par mots-clés, tests et lecture humaine du code.
Les exemples servant à choisir un seuil, modifier un prompt ou régler la recherche appartiennent au développement et ne peuvent pas être réutilisés comme validation indépendante. Réserver de nouveaux exemples au test final après fixation des réglages ; voir partitions et fuites de données.
Conserver une décision explicable : pourquoi cette version, quelles erreurs persistent, quelles entrées dépassent les conditions testées et quel changement appelle une nouvelle évaluation. Les candidats actuels figurent dans le choix des modèles et API ; le protocole d’évaluation locale sert aux essais sur son matériel.