Un plan de contrôle type¶
Dans l'industrie, le plan de contrôle est le document qui dit, pour chaque caractéristique d'un produit : comment on la mesure, à quelle fréquence, avec quelle carte, et ce qu'on fait quand elle sort des limites. Ce chapitre assemble les chapitres précédents en un plan de contrôle pour un orchestrateur de développement entièrement automatisé.
Statut de ce chapitre
Ce plan est une synthèse proposée par ce rapport. Chacune de ses briques est sourcée dans les chapitres précédents, mais l'ensemble n'a pas été évalué en conditions réelles. Les seuils numériques sont des points de départ à recalibrer sur vos propres données.
Hypothèses¶
- un orchestrateur reçoit des tickets d'un ou plusieurs dépôts ;
- un agent traite chaque ticket et ouvre une PR ;
- la CI tourne, puis la PR est fusionnée automatiquement ou envoyée en revue ;
- quelques centaines de runs par semaine au moins (en dessous, voir la dernière section).
Avant la mise en service : la qualification¶
| Étape | Contenu | Chapitre |
|---|---|---|
| Analyse du système de mesure | Auditer à la main 30 à 50 échecs de la batterie de tests ; calibrer tout juge LLM contre des étiquettes humaines (vrais positifs et vrais négatifs séparément) | Mesurer un agent |
| Indépendance du contrôle | Tests cachés ou en lecture seule ; juge d'un autre modèle que le producteur | Causes spéciales |
| Poka-yoke | Hooks bloquants ; permissions minimales | Jidoka, andon, poka-yoke |
| Ligne de base | 300 runs au moins par type de tâche pour estimer le taux de réussite et les limites | Mesurer un agent |
| Étiquetage | Chaque run porte modèle, fournisseur, empreintes de prompt et de skills, version des outils, type de tâche | Instrumenter la chaîne |
En production : le tableau de contrôle¶
| Caractéristique | Fréquence | Carte | Règles | Réaction |
|---|---|---|---|---|
| Réussite aux tests cachés, par type de tâche | Lot de 50 runs | p | 1 et 4 ; avertissement à 2σ | Revue humaine obligatoire du type de tâche, puis suspension si confirmé |
| Tests modifiés hors périmètre | Chaque run | — | Unitaire | Blocage du run |
| Marqueurs de contournement | Chaque run | — | Unitaire | Blocage du run |
| Dépendance ajoutée (existence, liste blanche) | Chaque run | — | Unitaire | Blocage du run |
| Secrets codés en dur | Chaque run | — | Unitaire | Blocage du run |
| Tokens par run | Lot quotidien | XmR sur log | 1 | Enquête (boucle, contexte qui gonfle) |
| Tours ou appels d'outils par run | Lot quotidien | XmR sur log | 1 | Enquête |
| Erreurs d'outils | Lot quotidien | u | 1 | Vérifier les serveurs d'outils |
| Arrêts sur limite | Lot de 50 runs | p | 1 | Enquête |
| Écarts de jugement relecteur / correcteur automatique | Échantillon hebdomadaire | p | 1 | Recalibrer le correcteur |
| Reprise à 14 jours | Mensuelle | p | 1 et 4 | Revue de la politique de fusion |
| Taux de déclenchement de chaque skill | Hebdomadaire | p | 1 et 4 | Voir Skills |
Ce tableau compte une dizaine de cartes. Le script (§6) prévient : à ce nombre, avec les quatre règles partout, on aurait une fausse alarme tous les 10 jours. D'où le choix de la règle 1 seule sur la plupart des cartes, et des règles supplémentaires seulement sur la caractéristique principale.
Les événements de requalification¶
Sans attendre qu'une carte sonne, relancer la batterie de qualification à chaque :
- changement d'identifiant de modèle ou de fournisseur ;
- modification du prompt système, d'un fichier d'instructions ou d'un skill ;
- changement de version de l'environnement d'exécution ou d'un outil ;
- ouverture de l'orchestrateur à un nouveau dépôt ou à un nouveau type de tâche.
Annoter ces événements sur toutes les cartes.
Ce qu'on s'interdit¶
- Modifier un prompt ou un skill en réaction à un échec isolé (entonnoir de Deming).
- Faire juger un modèle par lui-même (biais d'auto-préférence).
- Prendre le taux de fusion comme caractéristique de qualité (près des deux tiers des rejets ne concernent pas l'agent).
- Surveiller pass@k au lieu du taux de réussite au premier essai.
- Transformer une caractéristique surveillée en objectif d'optimisation de l'agent (Goodhart).
Petits volumes¶
En dessous de quelques centaines de runs par semaine, les cartes p ne détectent que des effondrements (voir la table de puissance du chapitre Mesurer un agent). Dans ce cas :
- remplacer les cartes p par une carte CUSUM sur les résultats individuels (réussite/échec), qui accumule l'information run après run au lieu d'attendre des lots complets ;
- relire tous les runs d'un type de tâche nouveau jusqu'à disposer d'une ligne de base ;
- s'appuyer davantage sur les contrôles unitaires (poka-yoke, signaux de contournement), qui ne dépendent pas du volume.
À retenir
Un plan de contrôle d'orchestrateur tient en quatre couches : qualification avant mise en service, contrôles unitaires à chaque run (poka-yoke et signaux de triche), cartes de contrôle sur quelques caractéristiques stratifiées, et requalification à chaque changement connu. La revue humaine n'y disparaît pas : elle devient un échantillonnage piloté par les cartes (chapitre précédent).