Lire les fiches, licences et évaluations des modèles
Choisir un modèle revient à 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 d’un adaptateur 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%. Si les six réussites propres à B corrigent un format mineur, mais ses quatre échecs propres perdent des faits essentiels, deux points ne suffisent pas à le choisir. À coûts d’erreur comparables, il reste à reproduire la différence sur de nouveaux exemples. C’est un calcul fictif, pas un test de produits.
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.
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. 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.