Classer des demandes avec une IA : définir les catégories avant de mesurer

Commencer par l’action qui suit le classement

Je ne commencerais pas par demander à une IA de « trier intelligemment ». Je demanderais d’abord ce que l’équipe fera de chaque résultat. Si les destinataires ne partagent pas la même définition d’une catégorie, un score pourra sembler précis tout en décrivant une règle instable.

Choisissez un périmètre limité : des messages de préparation d’ateliers, par exemple. Le classement proposé prépare une file de travail ; il ne déclenche ici ni envoi, ni modification de date, ni engagement client. Le rôle humain qui confirme la suite doit rester identifiable.

Écrire les frontières et le traitement des mélanges

Dans notre jeu fictif, P signifie planning : une demande porte seulement sur une date ou un créneau. D signifie document : elle porte seulement sur un support ou une version. C signifie à clarifier : elle mélange ces objets ou ne permet pas de choisir. Ces définitions et cette priorité du mélange sont des choix de l’exercice.

Une demande « envoyez le support et changez la date » relève donc de C, même si un mot-clé semble indiquer D. Vous pourriez concevoir ailleurs un classement à plusieurs étiquettes ; ce serait une autre règle à définir et un autre contrôle à construire. Ne changez pas silencieusement de convention entre deux essais.

Six cas originaux, avec une référence explicable

Pour le cas 5, deux objets sont présents ; pour le cas 6, l’objet manque. La référence ne dépend pas de l’intuition d’un lecteur après avoir vu une sortie du modèle. Faites discuter les désaccords d’annotation et conservez leur résolution. Une référence incertaine doit rester signalée.

Lire les croisements plutôt qu’un seul total

Imaginons maintenant les propositions P, P, P, D, D, C pour ces six cas. Elles sont écrites à la main pour montrer deux erreurs ; aucune IA n’a produit cette série. La documentation scikit-learn définit une matrice où chaque cellule compte les observations d’une catégorie de référence proposées dans une catégorie donnée. ^[1]

La diagonale donne quatre accords sur six. Mais le détail compte : le cas 3 serait mal orienté vers planning ; le cas 5 serait traité comme un simple document alors qu’une clarification est attendue. Ce deuxième écart masque une ambiguïté de commande. Le total ne décrit pas à lui seul cette conséquence.

Organiser un vrai essai sans le confondre avec cet exemple

Avant tout test réel, figez les catégories, les pièces autorisées, la consigne et les cas de référence. Gardez d’autres cas pour vérifier une version corrigée sans ne relire que ceux qui ont servi à la modifier. Conservez les sorties réellement obtenues, la version du système et les paramètres effectivement connus.

Une étiquette « à clarifier » ne correspond pas automatiquement à une probabilité d’erreur calibrée. Examinez ce qui déclenche cette sortie et ce qui se passe ensuite. Une équipe doit aussi pouvoir refuser de classer une demande hors périmètre, sans la faire disparaître du suivi.

Décider de la suite avec les personnes qui reprendront le travail

Précisez les erreurs qui empêchent l’usage envisagé, le contrôle humain nécessaire et la voie de reprise. Un petit jeu peut révéler une confusion ; il ne démontre pas la qualité sur toutes les demandes futures. Aucun seuil universel de mise en production n’est proposé ici.

Préparez un dossier qui conserve les messages, les règles d’annotation et les désaccords résolus. Retrouvez aussi la méthode pour construire ces cas. Le bon résultat recherché reste une décision de travail argumentée, pas une décimale flatteuse.