Comment ModelFinder classe et explique les résultats
Le moteur n’exécute aucun modèle. Il transforme des métadonnées publiques en critères de choix lisibles et traçables.
Classement
Le score accorde jusqu’à 35 points à la tâche déclarée, 22 à la langue, 20 à la compatibilité estimée, 8 à la clarté de licence, 8 à la fraîcheur, 5 à la documentation et 2 à l’accès public. Les téléchargements et appréciations sont affichés séparément : ils ne constituent pas une note de qualité.
Compatibilité
La taille réelle des fichiers de poids est prioritaire. À défaut, l’estimation utilise 4 octets par paramètre en float32, 2 en float16/bfloat16, 1 en int8 et 0,5 en 4 bits. Une marge d’exécution de 30 % est ajoutée. La vitesse CPU et la compatibilité logicielle restent inconnues.
Qualité et benchmarks
ModelFinder ne fusionne pas des scores issus de protocoles différents. Deux métriques ne sont directement comparables que si le jeu d’évaluation, la version, le protocole et les conditions sont identiques.
Cycle des données
Les résultats sont traités côté serveur puis placés dans un cache technique de 10 à 30 minutes. Aucun catalogue de modèles, poids, historique de recherche ou donnée personnelle n’est copié dans la base de données BNTIC.
Estimation matérielle : ce qui a changé
L’API du Hub ne renvoie la taille des fichiers que si elle est explicitement demandée. Sans cela, la taille des poids restait inconnue et la compatibilité s’affichait « inconnue » pour la plupart des modèles. Les fiches demandent désormais ces tailles, et l’estimation repose sur la taille réelle des fichiers dès qu’elle existe, sur le nombre de paramètres sinon.
Le fichier de référence de l’estimation est choisi par format : lorsqu’un dépôt publie des poids SafeTensors, ce sont eux le modèle, et une conversion GGUF déposée à côté n’est qu’un dérivé. Retenir cette dernière annonçait une taille jusqu’à quatre fois trop faible.
Échelle de quantification
Un dépôt GGUF publie couramment vingt variantes du même modèle, de 2 à 15 Go. Annoncer une seule « taille du modèle » n’aide personne : la fiche présente donc l’échelle complète, du plus compressé au plus fidèle, avec pour chaque variante la mémoire estimée et un verdict face à la configuration déclarée. La perte de qualité provoquée par la compression est signalée en termes de compromis, jamais chiffrée : elle dépend de la tâche et n’est pas mesurée ici.
Classement des résultats
La recherche ne trie plus par date de dernière modification : ce tri remontait des dépôts d’essai modifiés la veille avant les modèles réellement utilisés. Le classement par défaut est la pertinence du mot-clé ; en l’absence de mot-clé, l’usage constaté prend le relais. La popularité continue de ne pas entrer dans le score éditorial ; elle sert seulement à départager deux modèles de score égal. Le score tient compte des mots cherchés, comparés en mots entiers au nom du dépôt, et signale les copies quantifiées, adaptateurs et fusions publiés par un tiers, qui ne passent plus devant le modèle d’origine.
Les filtres de licence, d’accès public, de format et de fraîcheur ne sont pas exprimables dans l’API : ils sont appliqués après réception. La recherche collecte donc plus de notices que demandé, afin qu’une page de dix résultats en affiche dix et non deux.