Évaluer les modèles locaux et les tâches d’agents
Ce protocole compare des configurations complètes sur des tâches, sans refaire un classement global. Distinguer les étapes d’inférence, comprendre la calibration avant de fixer les seuils et évaluer recherche et génération quand les tâches dépendent de preuves retrouvées.
L’unité expérimentale n’est pas le nom du modèle. C’est l’ensemble suivant :
weights + quantization + runtime + template + context policy
+ generation settings + tools + harness + hardware
Le résultat appartient à cette configuration complète. Pour comparer un facteur, comme la quantification, modifiez-le délibérément en gardant les autres réglages constants. Si plusieurs composants changent à la fois, vous ne pouvez pas isoler celui qui explique la différence.
Figer une fiche d’exécution
model: organization/model
revision: immutable commit or artifact hash
artifact: exact filename and quantization
runtime: name, version, backend, driver
template: chat/reasoning/tool parser
context: native limit, requested length, KV type
generation: temperature, top-p, max output, seed if supported
hardware: GPU, VRAM, RAM, CPU offload
harness: version, tools, permissions, iteration budgets
Conservez cette fiche avec les résultats bruts et les exemples d’échec.
Niveaux d’évaluation
1. Tests d’intégration élémentaires
Testez une conversation simple, une sortie JSON exacte, un appel d’outil valide accompagné d’un distracteur hostile, un appel incorrect ou refusé, les langues utiles au workflow, l’annulation et un cas situé à la limite du contexte. Ces tests détectent les erreurs de template ou de serveur avant toute mesure de qualité du modèle.
2. Rejeu de tâches personnelles
Utilisez 10 à 30 tâches représentatives assorties de critères d’acceptation externes. Pour le code, incluez la correction d’un défaut, la préservation d’une API sur plusieurs fichiers, le diagnostic d’un test, une documentation inconnue, un manque de preuves et une action hors périmètre. Pour le travail documentaire, incluez l’extraction avec citations, des sources contradictoires, des questions temporelles et l’abstention.
3. Comportement du système
Préchauffez le runtime avant les exécutions enregistrées. Mesurez le taux de résultats acceptés, la gravité pondérée des échecs, la médiane et la latence de queue du premier token, la vitesse de décodage, la médiane et la latence de queue de bout en bout, les pics de VRAM et de RAM, l’offload, les reprises, la validité des appels d’outils, les modifications hors sujet et les interventions humaines.
Exemple de comparaison
Supposons que les versions Q4 et Q6 d’un même modèle 7B soient testées sur 20 tâches, avec trois exécutions par tâche :
Ces colonnes illustrent la forme du rapport ; elles ne constituent pas des résultats réels. La décision dépend du seuil de conséquence. Six exécutions acceptées de plus peuvent justifier Q6 pour les écritures, tandis que Q4 reste utile pour un triage en lecture seule.
Avec de petits échantillons, publiez les comptes et l’incertitude, pas seulement les pourcentages. Conservez les résultats par tâche pour vérifier qu’un gain ne vient pas d’une seule catégorie facile répétée plusieurs fois.
Tests de quantification et de contexte
Pour comparer des artefacts, gardez le runtime, le prompt et les paramètres de génération constants. Incluez des tests de modification exacte et d’appel d’outils, car les benchmarks linguistiques moyens peuvent masquer une dégradation du format. Testez d’abord le contexte natif, puis augmentez sa longueur avec des distracteurs et des preuves placées à différents endroits. Mesurez ensemble la mémoire KV et la qualité.
Benchmarks externes
lm-evaluation-harness, les évaluations de type HELM et le benchmark de code d’Aider fournissent des points de repère utiles. Ils ne reproduisent ni un dépôt privé, ni une quantification locale, ni les permissions du harness, ni le coût des interventions. Vérifiez la version des tâches, le risque de contamination, l’adaptation des prompts, le nombre d’échantillons et l’origine des scores — déclarés par le fournisseur ou reproduits indépendamment.
Biais et règle de décision
Une suite personnelle surapprend le travail du moment ; une suite publique surapprend sa distribution de tâches publiée. L’anglais, Python, les exécutions réussies, le matériel disponible et les modèles capables de démarrer sont souvent surreprésentés. Conservez des échecs difficiles connus et ajoutez régulièrement une nouvelle tâche de contrôle.
Choisissez la plus petite configuration qui franchit le seuil de tâches défini à l’avance, avec une marge mémoire suffisante et un taux d’échecs graves acceptable. Recommencez l’évaluation après toute modification de la fiche d’exécution, pas seulement lorsqu’un nouveau classement paraît.
Le guide de l’interface en ligne de commande du harness explique la sélection des tâches, les limites d’échantillons et la journalisation des exemples. Commencer par un petit benchmark public dont on peut examiner les sorties avant d’en augmenter la taille ; les résultats individuels distinguent erreurs de format et erreurs de réponse.