Guide
Décisions structurées : format, qualité et reprise humaine
Une catégorie valide peut être incorrecte. Ce guide distingue le format de sortie, la qualité des décisions et les conditions d’automatisation.
Le contrat
Commencer par les sorties autorisées
Dans un flux de support, le logiciel attend souvent une catégorie de destination. Un contrat peut limiter les réponses à facturation, accès, technique ou autre. Ce vocabulaire fixe simplifie la validation et rend chaque sortie interprétable. Il faut aussi décider si plusieurs catégories sont permises, si une catégorie manque et comment signaler une entrée illisible. Ces choix appartiennent au métier. Ils déterminent les exemples à annoter et les erreurs à surveiller.
La forme
Une réponse valide peut être inexacte
Un schéma vérifie que les champs sont présents et que leurs valeurs appartiennent aux types attendus. Il ne vérifie pas que le ticket a été compris. Une facture peut être classée comme contrat avec un format parfaitement valide. L’évaluation doit donc séparer la validité du format et la qualité du classement. Cette distinction reste nécessaire, quelle que soit la technique utilisée pour contraindre la sortie. Une promesse de format ne vaut pas une promesse d’absence d’erreur.
Les modèles
Plusieurs approches à comparer
Un système de règles, un classifieur spécialisé ou un modèle de langage avec une sortie contrainte peuvent répondre à une partie du besoin. Le choix dépend des données disponibles, du nombre de catégories et de la diversité des formulations. La première comparaison utile porte sur les cas réels et sur les règles existantes. Il faut mesurer les erreurs qui changent le déroulement du processus, les demandes reprises par un opérateur et les coûts d’intégration. Un modèle plus large ne constitue pas, à lui seul, un meilleur résultat.
L’incertitude
Évaluer les probabilités annoncées
Les probabilités servent à exprimer une incertitude sur les choix. Leur utilité dépend de leur relation avec les résultats observés. Si les décisions annoncées à 90 % sont correctes bien moins souvent, le seuil de déclenchement perd son sens. L’étude de calibration demande des exemples distincts de ceux utilisés pour régler le système. Elle doit suivre les populations traitées et leurs évolutions. Les probabilités d’une démonstration commerciale ne suffisent pas à établir cette propriété.
La reprise
Définir le coût d’une erreur
Une demande adressée à la mauvaise équipe provoque un délai. Un dossier rejeté à tort peut bloquer un client. Ces conséquences justifient des règles différentes. Le circuit de reprise doit préciser qui examine le cas, quelles informations sont transmises et comment sa correction rejoint les données d’évaluation. Le taux de reprise humaine fait partie des résultats du pilote. Un seuil élevé peut réduire les erreurs automatiques tout en augmentant la charge de votre équipe.
La référence
Ce que propose la catégorie System One
TypeSafe présente Jev comme un modèle qui reçoit un état et renvoie des décisions typées avec des probabilités. Cette interface inspire le projet Deyqo. Les résultats, prix, garanties de format et méthodes d’entraînement annoncés par TypeSafe concernent son propre service. Deyqo ne revendique pas ces propriétés. Pour notre projet, les objectifs restent à transformer en un service évalué, documenté et exploitable en Europe.
Lire la publication de TypeSafeLe démarrage
Construire un pilote observable
Délimitez une décision, rassemblez des exemples annotés et gardez un lot indépendant pour le test. Analysez les erreurs par catégorie, puis choisissez une règle de reprise. Observez d’abord le service sans lui confier d’action irréversible. Publiez les conditions de mesure : données, version, période, coût et temps de réponse. Cette base permet de décider si le système apporte une amélioration et dans quels cas votre équipe doit garder la main.
Les données de test
Garder une place pour les cas difficiles
Un jeu d’évaluation doit inclure les messages courts, les documents incomplets et les demandes qui contiennent plusieurs intentions. Ajoutez une catégorie hors périmètre et des exemples dont aucun choix proposé ne convient. Conservez les désaccords entre annotateurs : ils révèlent parfois une règle métier imprécise. Pour chaque erreur, distinguez un manque de contexte, une catégorie mal définie et une mauvaise prédiction. Vous pourrez ainsi corriger le contrat ou le modèle au bon endroit. Ces cas difficiles servent aussi à vérifier le circuit de reprise humaine.
Décrire votre cas d’usage
Rassemblez les catégories attendues, les volumes et le rôle de votre équipe dans un brief de pilote.
Préparer un pilote