# Atelier golden dataset et classification multilabel Ces douze textes et les deux séries de prédictions sont entièrement fictifs. Aucun résultat ne représente Jev, un LLM ou un client. Le script mesure les sorties importées ; il ne classe aucun texte et ne lance aucun appel réseau. ## Démarrage Python 3.10 ou ultérieur, sans dépendance externe. Dans ce dossier : ```bash python3 evaluer.py reference.csv predictions-a.csv > resultat-a.json python3 evaluer.py reference.csv predictions-b.csv > resultat-b.json ``` A : 10/12 documents automatiques, 7/10 ensembles de thèmes exacts. B : 9/12 documents automatiques, 9/9 ensembles de thèmes exacts. B contient volontairement une ligne manquante, a12 ; le script la compte. Ces valeurs contrôlent le calcul, elles ne démontrent aucun avantage de modèle. ## Convention des métriques Les étiquettes sont séparées par |, sans doublon. Une cellule labels vide avec status=ok signifie aucun thème. Avec status=abstain, elle signifie absence de décision. status=error désigne un appel raté ou une sortie inutilisable. Une prédiction absente reste dans le dénominateur total comme missing. Precision, recall et F1 portent uniquement sur les lignes ok. support_auto est le nombre de vrais positifs de référence dans ce sous-ensemble, support_total le nombre dans toute la référence. Un dénominateur nul produit null. exact_auto exige la bonne liste complète. exact_auto_over_total compte seulement les documents complètement justes et automatisés, divisés par tous les documents. Il ne mesure pas une qualité finale après revue humaine. La couverture et les supports doivent toujours accompagner les métriques. Les sous-ensembles ok de deux configurations peuvent différer. Comparer aussi à couverture similaire, et contrôler chaque catégorie, avec un seuil fixé avant le test. ## Utilisation avec vos données 1. Fixer la taxonomie et les règles métier, versionner taxonomie.json. 2. Remplir annotation-template.csv sur des contenus autorisés, arbitrer les désaccords. Créer une référence contenant id et labels pour les seuls cas arbitrés du test. Ne pas envoyer ces labels au modèle. 3. Réserver des ensembles distincts pour développer les instructions, régler les seuils et tester. Conserver un même groupe de doublons dans un seul lot. Ici les douze lignes sont un unique test de démonstration, pas un split réel. 4. Exporter les sorties de chaque configuration avec id,status,labels. Conserver les erreurs. Ne jamais réutiliser l'identifiant d'une ligne pour une autre. 5. Archiver configuration, versions, empreinte du corpus et résultats de chaque exécution. Le script ne choisit pas de seuil et ne calibre pas les scores. 6. Renseigner couts-template.csv avec les factures et temps mesurés, même pour les échecs et retries. Cellule vide = inconnu, jamais zéro. Même devise et même période pour les deux configurations. Coût total = inférence + retries + minutes_revue / 60 * taux_horaire_charge + intégration amortie. Un petit exemple synthétique vérifie la plomberie, pas la performance réelle. Le script n'est pas un validateur de séparation train/test, de représentativité, d'accord entre annotateurs ou d'incertitude statistique. Ceux-ci sont à auditer sur le corpus réel. Le gabarit de coûts n'effectue pas de calcul automatique. Les fichiers JSON résultat sont créés localement par les commandes ci-dessus. Pour nettoyer, supprimer ce dossier et les sorties créées après les avoir archivés.