Comparer les résultats

Utilisez cette skill pour planifier et effectuer une comparaison baseline-vs-candidate. Le baseline est le checkpoint de référence, et le candidate est le checkpoint dont la variation de précision est mesurée, généralement une version davantage quantifiée du baseline.

Workflow

1. Établissez le checkpoint/run candidate et le baseline correspondant. Déduisez le baseline à partir du modèle/checkpoint source PTQ dans l'espace de travail ou la config utilisés pour créer le candidate. S'il ne peut pas être déduit, demandez à l'utilisateur le checkpoint baseline ou un chemin d'invocation/run baseline existant.
2. Si une évaluation baseline ou candidate requise est manquante, déléguez à la skill d'évaluation pour la créer, l'exécuter et la vérifier. La config d'évaluation associée doit correspondre autant que possible aux versions de benchmark, configs de tâche, arguments de serving, limites de tokens, configuration de dataset, credentials, cluster et conteneur ; modifiez uniquement le modèle/checkpoint et les flags de serving ou quantification spécifiques au checkpoint.
3. Récupérez la liste des tâches baseline et candidate, les configs, artefacts de score et logs. Si l'utilisateur fournit des runs MLflow ou des IDs d'invocation, utilisez la skill accessing-mlflow pour récupérer les configs et artefacts.
4. Confirmez que chaque run a passé l'Étape 9 d'évaluation, « Verify completed evaluation run », avant de comparer les scores. Sinon, validez les logs, la santé du serveur, l'état du judge/code-execution, la comptabilité des échantillons et l'analyse du raisonnement avant de calculer les deltas.
5. Pour chaque tâche, utilisez le champ de score canonique de la section Score Extraction correspondante dans .agents/skills/evaluation/recipes/tasks/<task>.md.
6. Calculez les deltas exacts en dehors du contexte de chat lorsqu'il y a plusieurs tâches ou runs répétées.
7. Signalez les verdicts de comparabilité et de faisabilité quantifiée avant d'interpréter le delta comme résultat de qualité du modèle. Si l'utilisateur n'a pas fourni un seuil d'acceptation, signalez la faisabilité comme non concluante plutôt que d'en inventer un.

Checklist de comparabilité

Avant de traiter un delta baseline-vs-quantifié comme résultat de qualité du modèle, vérifiez que les runs validés sont comparables :

1. Le texte du prompt, system prompt, chat template et messages rendus correspondent.
2. Le nom de tâche, version de benchmark, split de dataset, conteneur, harness et fragment de tâche correspondent.
3. Les paramètres de génération correspondent, y compris temperature, top_p, top_k, max tokens, stop strings, kwargs de chat-template, mode/budget de raisonnement et overrides spécifiques à la tâche.
4. Les traces de raisonnement sont activées, désactivées, analysées, supprimées ou ignorées de manière cohérente entre les runs.
5. Le nombre d'échantillons/repeats évalués et notés correspond pour chaque tâche et split.
6. Les tâches soutenues par judge ou simulator utilisent le même judge/user model, classe d'endpoint, prompt et config de scoring.
7. La même métrique de précision et champ de score sont utilisés pour les deux runs.
8. La précision du baseline correspond au gate. Un gate <1pp vs BF16 nécessite un vrai baseline en précision complète (BF16). De nombreux modèles sont expédiés nativement quantifiés (par ex. INT4 W4A16 ou FP8 par bloc) sans version BF16 — une comparaison quant-to-quant contre la précision publiée (par ex. INT4 vs NVFP4, comme pour Kimi-K2.6) est toujours un résultat valide ; comparez simplement like-for-like, déclarez quelle précision le baseline utilise, et appliquez le gate par rapport à ce baseline plutôt qu'à un BF16 supposé.

Si un élément diffère, soit réexécutez avec des paramètres appareillés, soit étiquetez le résultat comme n'étant pas une comparaison de quantification apples-to-apples.

Format de rapport

Incluez :

• Identifiants du baseline et du candidate.
• Par tâche : chemin de métrique, score baseline, score candidate, delta et stderr si disponible.
• Statut de comparabilité pour prompt/template, paramètres de génération, comptages d'échantillons, gestion du raisonnement, configuration judge/simulator et champ de score.
• Verdict de comparabilité : comparable, non comparable ou non concluant.
• Verdict de faisabilité de quantification : acceptable, non acceptable ou non concluant.