« Quel prompt est meilleur ? » semble être une question simple. En pratique, évaluer les sorties IA est l’un des problèmes les plus difficiles en IA appliquée. L’évaluation humaine est coûteuse et lente. Les métriques automatisées comme BLEU ou ROUGE manquent de nuance. Et l’évaluation LLM à juge unique est biaisée par la position, la verbosité et les préférences propres du modèle juge.
Nous avons construit un système de bakeoff qui résout ces problèmes avec un scoring multi-juges, la randomisation de position et des intervalles de confiance statistiques. Cet article couvre l’architecture, les statistiques et les leçons que nous avons tirées.
Qu’est-ce qu’un Bakeoff ?
Un bakeoff est une comparaison structurée de deux ou plusieurs « bras » IA — différents prompts, modèles, Recipes ou workflows — évalués avec les mêmes entrées. Considérez-le comme un A/B test pour les sorties IA, mais avec un scoring automatisé au lieu de taux de clics utilisateurs.
JieGou prend en charge 6 modes de bakeoff :
- Prompt vs. prompt — Même Recipe, templates de prompt différents
- Modèle vs. modèle — Même Recipe, fournisseurs LLM différents
- Recipe vs. Recipe — Des Recipes entièrement différentes
- Workflow vs. workflow — Des workflows multi-étapes différents
- Workflow modèle vs. modèle — Même workflow, modèles différents
- A/B test — Routage en production avec feedback utilisateur
Chaque bakeoff peut avoir jusqu’à 8 bras et 10 entrées, plafonné à 40 cellules totales (bras multipliés par entrées) pour maintenir des coûts raisonnables.
Évaluation LLM-as-Judge
Chaque cellule est évaluée par un LLM juge en utilisant une approche de comparaison par liste. Plutôt que de noter chaque sortie indépendamment (ce qui perd le contexte relatif), le juge voit toutes les sorties de bras côte à côte et les note selon des critères définis.
Les critères d’évaluation sont pondérés et notés de 0 à 100. Le preset par défaut utilise :
| Critère | Poids |
|---|---|
| Pertinence | 30 % |
| Complétude | 25 % |
| Clarté | 20 % |
| Précision | 15 % |
| Format | 10 % |
Les utilisateurs peuvent personnaliser ces critères ou créer les leurs. Les poids doivent totaliser 100 %.
Le prompt du juge présente la sortie de chaque bras avec un label randomisé (A, B, C…) et demande des scores structurés. Nous utilisons invokeLLMStructured() avec un schéma Zod pour garantir que le juge renvoie des scores valides et analysables.
Randomisation de position
Un biais connu dans l’évaluation LLM est la préférence de position — les modèles tendent à favoriser les sorties présentées en premier ou en dernier. Nous randomisons le mapping bras-vers-label pour chaque appel d’évaluation. Le bras 1 peut être labellisé « C » dans une exécution et « A » dans la suivante.
Cela n’élimine pas le biais de position, mais le distribue aléatoirement entre les bras plutôt que de favoriser systématiquement un seul. Sur plusieurs entrées, l’effet s’équilibre.
Consensus multi-juges
L’évaluation à juge unique est intrinsèquement bruitée. Différents modèles ont différentes préférences, et même le même modèle peut donner des scores différents sur la même entrée. Nous exécutons 2 à 3 juges indépendants en parallèle sur la même évaluation et mesurons leur accord.
Le tau de Kendall mesure la corrélation de rang en comptant les paires concordantes et discordantes. Si deux juges classent tous les deux le bras A au-dessus du bras B, c’est une paire concordante. S’ils sont en désaccord, c’est une paire discordante. Le coefficient va de -1 (désaccord parfait) à 1 (accord parfait).
Le rho de Spearman fournit une mesure complémentaire : 1 - (6 * somme des différences de rang au carré) / (n * (n^2 - 1)).
Nous classifions l’accord comme :
- Élevé — Tau de Kendall >= 0,7
- Modéré — 0,4 ≤ tau < 0,7
- Faible — tau < 0,4
Un accord faible est lui-même un signal utile. Cela signifie généralement que les critères sont ambigus, que les sorties sont trop similaires pour être différenciées, ou que la tâche n’a pas de réponse clairement « meilleure ».
Les classements de consensus sont calculés en moyennant les scores entre les juges, avec des comptages de victoires agrégés pour chaque bras.
Confiance statistique
Pour chaque bras, nous calculons un intervalle de confiance à 95 % autour du score moyen : moyenne +/- 1,96 * écartType / sqrt(n), où n est le nombre d’entrées.
Lorsque les intervalles de confiance se chevauchent entre deux bras, nous le signalons — la différence peut ne pas être statistiquement significative. Cela empêche les équipes de prendre des décisions basées sur du bruit. Une différence de 2 points sur 3 entrées est probablement aléatoire. Une différence de 15 points sur 10 entrées avec des IC non chevauchants mérite d’être prise en compte.
Intégration A/B Test
Les bakeoffs répondent à « lequel est meilleur en théorie ». Les A/B tests répondent à « lequel performe mieux en production ».
Lorsqu’un A/B test est actif, les exécutions de workflow entrantes sont routées aléatoirement vers différents bras (répartition 50/50). Les utilisateurs fournissent des notations par étoiles (1-5) comme feedback sur chaque sortie, et nous exécutons un test chi-carré pour la significativité statistique.
Le test s’arrête automatiquement lorsque deux conditions sont remplies : p-value < 0,05 et au moins 30 réponses de feedback par bras. Cela empêche les conclusions prématurées et les tests inutilement longs.
Les décisions de routage sont mises en cache dans Redis avec un TTL de 30 secondes pour la cohérence — le même utilisateur accédant à l’endpoint de manière répétée dans la fenêtre de cache obtient le même bras.
Gestion des coûts
L’évaluation multi-juges multiplie les coûts d’exécution par le nombre de juges (2-3x). Nous fournissons des estimations de coûts en amont avant le début d’un bakeoff, en utilisant les médianes historiques d’utilisation de tokens comme bases et en tenant compte du multiplicateur de juges.
Le plafond de 40 cellules (8 bras fois 10 entrées) et la limite de 10 critères maintiennent chaque bakeoff borné. Pour les bras de workflow, nous utilisons des projections de tokens multi-étapes qui tiennent compte du modèle de chaque étape et de la taille attendue des entrées/sorties.
Ce que nous avons appris
La randomisation de position est essentielle, pas optionnelle. Dans nos premiers tests sans randomisation, la sortie présentée en premier gagnait 60-65 % des évaluations indépendamment de la qualité. La randomisation a ramené cela à 48-52 %, ce qui est dans la marge de bruit.
Deux juges détectent la plupart des désaccords. Passer de 1 à 2 juges a considérablement amélioré la fiabilité. Passer de 2 à 3 juges l’a encore améliorée mais avec des rendements décroissants. Pour la plupart des cas d’usage, 2 juges avec reporting du tau de Kendall est le point optimal.
Les intervalles de confiance changent les comportements. Avant d’ajouter le reporting des IC, les équipes optimisaient pour des différences de 1-2 points. Maintenant elles voient les intervalles qui se chevauchent et les interprètent correctement comme « pas de différence significative ». Cela économise du temps d’ingénierie qui aurait été consacré à poursuivre du bruit.
Les schémas de sortie structurée rendent l’évaluation fiable. Les premières versions utilisaient des réponses de juge en format libre et analysaient les scores avec des regex. Cela cassait constamment — les modèles ajoutaient des explications, utilisaient des formats différents, ou sautaient des critères. Le passage à des sorties structurées validées par Zod a éliminé entièrement les échecs d’analyse.