Choisissez un modèle à partir de preuves

Définissez la décision

Comparer des modèles exige un usage précis. Un modèle qui explique bien une petite fonction ne gérera pas forcément aussi bien une modification étendue du dépôt. Un modèle moins coûteux peut satisfaire les exigences de qualité pour des transformations courantes. Une investigation difficile peut demander des capacités de raisonnement supérieures.

Écrivez d’abord la tâche et les contraintes. Incluez les données permises, les outils nécessaires, le temps de réponse et le coût maximal acceptable. Certaines contraintes sont obligatoires. Ne faites pas disparaître une restriction de traitement des données dans une moyenne parce qu’un autre score est élevé.

Utilisez des tâches représentatives

Constituez un petit jeu d’évaluation à partir du travail réel de l’équipe. Retirez les données sensibles, sauf si l’environnement d’évaluation est approuvé pour ces données. Incluez des tâches simples, difficiles et des tâches dont la bonne réponse consiste à demander les informations manquantes.

Pour un service de reporting fictif, utilisez un défaut de date connu, une petite fonction de filtrage et l’explication d’une règle d’autorisation. Préparez le résultat attendu avant de lancer la comparaison. Incluez un test négatif qui rejette le défaut connu.

Réservez certaines tâches en dehors du travail sur les prompts. Si vous ajustez le prompt à chaque exemple à répétition, le score final peut surestimer la performance générale. Un jeu distinct aide à vérifier si le prompt amélioré fonctionne au-delà des exemples qui ont servi à le concevoir.

Gardez la comparaison équitable

Notez la version exacte du modèle, le prompt, le contexte fourni, les outils et les permissions. Partez d’états équivalents. Si un modèle reçoit le dépôt entier et un autre un seul fichier, le résultat compare aussi les workflows, pas seulement les modèles.

Les comparaisons de workflows peuvent être utiles. Nommez-les correctement. Un produit agent comprend plus qu’un modèle : la sélection du contexte, les outils, les limites d’exécution et le comportement de reprise peuvent influencer le résultat.

Répétez les exécutions lorsque la variabilité des réponses compte. Consignez les tentatives ratées au lieu de ne publier que le meilleur résultat. Pour les critères subjectifs, utilisez une grille écrite et, si possible, plusieurs personnes chargées de la revue.

Évaluez la qualité avant la vitesse

Vérifiez d’abord les critères d’acceptation obligatoires. La modification satisfait-elle l’exigence ? Préserve-t-elle les contrôles d’accès ? Les tests pertinents passent-ils ? Une personne peut-elle comprendre le diff lors de la revue ?

Comparez ensuite l’effort, le temps écoulé et le coût des résultats acceptables. Incluez les nouvelles tentatives et la revue humaine. Une réponse peu coûteuse qui exige de nombreuses corrections peut coûter cher à l’échelle de la tâche.

Les benchmarks publics peuvent aider à identifier des candidats. Ils utilisent des jeux de tâches et des méthodes de notation précis. Ne traitez pas leur score comme une mesure directe de la productivité de votre équipe.

Consignez la décision et ses conditions de réexamen

Le résultat peut être une recommandation limitée. Par exemple : « Utilisez ce modèle pour ajouter de petits tests dans ce dépôt, avec les exigences de revue existantes. » Vous n’avez pas besoin d’un modèle unique pour toutes les tâches.

Précisez ce qui imposerait une nouvelle évaluation : changement de version du modèle, configuration différente des outils, nouvelle catégorie de données ou échecs persistants. Gardez une solution de repli pour les tâches qui dépassent les capacités du modèle choisi.

L’évaluation sert à réduire l’incertitude autour d’une décision réelle. Évitez une compétition permanente entre modèles qui consommerait plus d’effort que le travail qu’elle soutient.