Monitoring et annotation
1 Les risques de dégradation
Un modèle de codification en production peut se dégrader de plusieurs façons, que le cadre MLOps européen classe ainsi (Tayebjee et al. 2025, ch. 4) :
| Type de drift | Exemple pour la codification APE |
|---|---|
| Covariate shift : les entrées changent | De nouveaux métiers et de nouvelles formulations apparaissent, et la réforme du guichet unique a allongé les libellés |
| Prior shift : la répartition des classes change | Vagues d’immatriculations dans certains secteurs, comme les VTC ou la location meublée |
| Concept drift : le lien entre entrée et code change | Révision de la nomenclature (NAF rév. 2 → NAF 2025) ; une marque qui devient une nouvelle activité (par exemple « Uber » → « Uber Eats ») |
| Problème en amont | Un champ qui n’est plus renseigné, ou un changement de format de la liasse |
2 Monitorer sans annotation
La plupart des prédictions ne sont jamais vérifiées par un humain. Le premier niveau de monitoring repose donc sur des signaux qui ne demandent aucune annotation. Avec le premier modèle, les logs de l’API étaient convertis chaque jour en fichiers Parquet partitionnés, requêtés avec DuckDB et affichés dans un dashboard reconstruit chaque nuit (Faria et al. 2024). La collecte des logs de production est pour l’instant suspendue ; la remettre en place fait partie du protocole cible. Le dashboard montre :
- les volumes de requêtes et le taux de codification automatique dans le temps, pour différents seuils ;
- la distribution de l’indice de confiance et son évolution d’une période à l’autre (des tests automatiques, de Kolmogorov–Smirnov ou du χ², restent à mettre en place) ;
- la distribution des codes prédits ;
- des statistiques sur le texte en entrée (longueur, vocabulaire nouveau).
Ces indicateurs servent d’alertes : une chute brutale du taux de codification automatique, ou un décalage de la distribution de l’indice de confiance, déclenche une analyse. En revanche, ils ne disent pas si le modèle a raison.
3 Annotation humaine
3.1 Campagnes Label Studio
La qualité ne se mesure qu’avec des annotations d’experts métier. Les campagnes d’annotation passent par Label Studio, déployé sur la plateforme, avec un projet par équipe d’experts. Des cron jobs font circuler les données :
- l’échantillonnage des libellés à annoter et leur envoi dans les files d’annotation ;
- la synchronisation des annotations terminées vers S3 ;
- leur conversion en jeux d’évaluation et d’entraînement.
Annoter un libellé prend environ une minute. Deux campagnes ont été menées à ce jour :
- un référentiel NAF rév. 2 d’environ 10 000 libellés, codés à l’aveugle par l’équipe qualité de Sirene ;
- une campagne NAF 2025 d’environ 30 000 libellés, utilisée à la fois pour évaluer le recodage par LLM et comme données d’entraînement (voir Données).
3.2 Pourquoi l’annotation doit être aléatoire et à l’aveugle
Les cas à faible confiance passent chaque jour en reprise manuelle, et il est tentant de s’en servir comme jeu d’évaluation. Ce serait une erreur : ils sont sélectionnés sur les échecs du modèle et ne disent rien des cas codés automatiquement. Pour estimer l’accuracy de la codification automatique, il faut annoter une partie du flux tirée au hasard, par des experts qui ne voient pas la proposition du modèle. Sinon, leurs annotations sont influencées par la prédiction qu’elles sont censées juger.
Cet échantillon aléatoire du flux, annoté à l’aveugle, c’est le « golden set ». Tout le protocole de réentraînement repose dessus. Ce sont les seules données qui permettent :
- d’estimer l’accuracy de la codification automatique ;
- de fixer le seuil ;
- de comparer équitablement deux modèles ;
- de mesurer le drift à partir d’annotations.
4 Audit par LLM
Le projet utilise aussi des agents LLM pour contrôler les prédictions hors ligne. Le MatchVerifier de GRAAL vérifie si un couple (libellé, code) est cohérent avec les notes explicatives de la nomenclature, et propose une alternative sinon. Trop lent et trop cher pour tourner sur chaque prédiction, il peut en revanche tourner en batch pour :
- prioriser les cas que les relecteurs doivent regarder en premier ;
- repérer les codes douteux dans les données d’entraînement ;
- arbitrer les désaccords entre le modèle de production et d’autres moteurs.
Sur une autre nomenclature (COICOP), le MatchVerifier a détecté environ la moitié des erreurs, avec peu de faux positifs. C’est donc un bon outil pour prioriser la revue humaine, mais pas assez fiable pour décider seul.