Définir l'unité de comparaison
Le premier choix d'architecture consiste à définir ce qui rend deux campagnes d'évaluation comparables. Il faut au minimum conserver :- les versions du jeu de données et de chaque exemple ;
- les versions du prompt, du modèle, de la recherche documentaire et des outils ;
- les versions des évaluateurs et de leurs grilles ;
- les règles d'échantillonnage et les graines aléatoires lorsqu'elles sont pertinentes ;
- l'environnement et les versions des dépendances ;
- le segment associé à chaque exemple.
Segmenter avant d'agréger
Les moyennes globales donnent une orientation, mais protègent mal une mise en production. Un assistant interne peut progresser au global tout en régressant sur une famille de documents, une langue, une intégration ou un workflow à risque. Un modèle de segmentation utile peut inclure :| Dimension | Exemples de segments |
|---|---|
| Intention | Recherche, comparaison, explication, demande d'action |
| Risque | Information, donnée sensible, approbation requise |
| Preuves | Source forte, sources contradictoires, source insuffisante |
| Intégration | Recherche seule, un outil, workflow multi-outils |
| Contexte utilisateur | Langue, entité métier, niveau de permission |
| Historique | Parcours stable, incident récent, zone faible connue |
Adapter le détecteur au type de signal
Toutes les métriques ne doivent pas partager la même règle d'alerte. Les échecs déterministes, comme des arguments d'outil invalides ou une citation obligatoire manquante, peuvent bloquer une mise en production dès qu'ils apparaissent sur un cas critique. Les métriques continues, comme la qualité de l'ancrage factuel ou l'accomplissement d'une tâche, exigent une référence, un volume minimal d'exemples et une tolérance adaptée au bruit de l'évaluateur. Pour les signaux de production, il faut comparer des distributions et des taux sur une fenêtre adaptée plutôt que de réagir à une seule requête. Le volume, la saisonnalité et l'évolution du profil des utilisateurs comptent. Une hausse brutale des solutions de repli peut signaler une panne de source, mais aussi une nouvelle catégorie de questions. L'alerte doit déclencher une investigation, pas imposer automatiquement une cause. Il faut distinguer :- régression de version : une version candidate se dégrade face à sa référence sur des cas comparables ;
- dérive en production : le comportement réel ou les entrées quittent la zone validée ;
- dérive de l'évaluation : le jeu, la grille ou le juge évolue au point d'invalider la comparaison.
Concevoir des alertes qui portent un diagnostic
Une alerte exploitable doit contenir :- les versions candidate et de référence ;
- la métrique et les segments touchés ;
- l'écart absolu et relatif ;
- le nombre d'exemples évalués ;
- des cas représentatifs et leurs traces ;
- la dernière version connue comme fiable ;
- le responsable et la décision attendue.
Relier l'alerte au déploiement et au retour arrière
La réponse dépend de la gravité et de la réversibilité. Une version candidate peut être bloquée lorsqu'un cas critique de politique échoue, tandis qu'un mouvement qualité moins risqué peut exiger une revue et un déploiement progressif. En production, une alerte peut suspendre l'élargissement du trafic, activer une solution de repli sûre ou revenir à la dernière configuration validée. La politique doit être définie avant l'incident :- quels échecs bloquent le déploiement ;
- qui peut approuver une exception ;
- quelle configuration peut être restaurée indépendamment ;
- comment la solution de repli sûre est validée ;
- quelles preuves permettent de fermer l'incident.