Classification de texte multi-label : un Choice, plusieurs questions oui/non, ou une seconde passe

Regardez l’action, pas la brochure du modèle. « On m’a facturé deux fois et l’export prend maintenant deux minutes » est à la fois un sujet de facturation et de performance. Si l’étape suivante est « le remettre à la seule équipe qui doit répondre », il vous faut un label principal : voir intent-classification et text-classification-api. Si l’étape suivante est « taguer chaque thème applicable pour que le rapport hebdomadaire n’en perde pas un », il vous faut du multi-label. Forcer un Choice cache l’un des deux faits. Cette page porte ce contrat. Elle ne remplace pas le guide d’une requête unique et ne réécrit pas l’interrupteur Make « n’assigner qu’une catégorie » : ce contrôle vit dans Make, décrit dans make-categorize-text. Le retour client qui n’a besoin que du thème principal et d’une priorité reste sur customer-feedback-classification.

Choisissez la forme que votre entrepôt peut stocker. Le tableau est une carte de contrats, pas un classement. Aucune option ne dispense de compter les faux tags sur vos propres lignes labellisées.

Écrivez chaque Noul comme une proposition : « Un problème de facturation est-il présent ? » Donnez criteria.true et criteria.false en descriptions courtes, 2 à 350 caractères chacune, et des instructions de 8 à 600 caractères. Les ids suivent la règle du Choice : une lettre initiale, puis minuscules, chiffres et underscores, 40 caractères au plus. Ne posez pas deux questions qui désignent le même fait, comme billing et invoice, sinon un vrai sera compté deux fois. N’ajoutez pas une question fourre-tout si personne ne la lit ; une probabilité basse est déjà une raison de s’abstenir. Le champ noul est la probabilité de oui, de 0 à 1. Il n’y a pas de champ confidence séparé. Une valeur proche de 0,5 est incertaine : envoyez ce tag à une personne. Ne traitez pas une valeur haute sur huit questions comme huit tags confirmés tant que vous n’avez pas mesuré les faux positifs par tag. Une requête peut mélanger un Choice (la route principale) et plusieurs Noul, tant que le total reste entre 1 et 8 questions. Huit Noul restent une exécution. L’exemple ci-dessous est une forme de requête, pas un résultat enregistré. Les seuils viennent de vos labels, pas de nombres d’exemple imaginés. Voir question-types et confidence-and-abstention.

curl --fail-with-body https://jevmodel.app/api/v1/systemone \
  -H "Authorization: Bearer $JEVMODEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"state":"I was charged twice and exporting a report now takes two minutes.","questions":{"billing":{"type":"noul","instructions":"Is a billing or charge issue present in this text?","criteria":{"true":"The text mentions charges, invoices, refunds, or payment.","false":"The text does not mention a billing issue."}},"performance":{"type":"noul","instructions":"Is a performance or speed problem present in this text?","criteria":{"true":"The text describes slowness, timeouts, or a speed regression.","false":"The text does not describe a performance problem."}}}}'

N’aplatissez pas trente labels dans un seul Choice. Le maximum est douze, et une liste plate aussi longue fait se recouvrir les descriptions. Première requête : un Choice parent qui inclut une option de revue explicite. Seconde requête : seulement les criteria enfants du parent choisi, et seulement quand la confidence de ce parent dépasse un seuil que vous avez mesuré. Sinon, une personne choisit l’enfant. Chaque appel est facturé à part. Il n’y a pas de clé d’idempotence : écrivez la requête dans votre historique avant de relancer une réponse perdue. S’il vous faut plus de huit tags Noul, séparez-les en deux requêtes avec le même state et des ids de question disjoints, et stockez les deux réponses sous un id de ligne que vous générez. Les deux appels ne se voient pas. Un Decision Flow peut dessiner cette branche dans la console, mais exécuter un flow est réservé aux offres payantes : abonnez-vous ou achetez un pack de jetons. Les flows n’utilisent pas les exécutions gratuites du jour. Voir decision-flows. Chaque requête validée, questions comprises, doit tenir dans 8 000 caractères.

Ne réduisez pas le résultat à un seul chiffre d’exactitude. Un commentaire avec deux tags vrais compte deux fois. Pour chaque tag, comptez les faux positifs et les faux négatifs sur un jeu réservé, ou donnez précision et rappel par tag si vous les calculez déjà. Un modèle qui ne prédit jamais un tag rare peut paraître fort sur une moyenne unique et quand même perdre ce tag chaque semaine. Batch dans Console exporte des réponses par ligne et ne calcule pas ces comptes ; joignez-les dans votre script. Notez une liste JSON et un passage multi_label Hugging Face sur les mêmes lignes si ce sont les alternatives. Les scores Hugging Face sont des signaux d’implication NLI ; rejetez tout nom généré absent de votre taxonomie avant la jointure. La voie zero-shot est zero-shot-text-classification. Le découpage du jeu réservé et l’habitude de revérifier après un changement de criteria sont evaluation. Les comptes gratuits vérifiés partagent 5 exécutions réussies par jour UTC entre le Playground, chaque ligne Batch et l’API. Une seconde passe est une seconde exécution.

Elle ne renverra pas une liste ouverte de tags que vous n’avez pas nommés. Elle ne lit ni images, ni audio, ni pièces jointes. Ce n’est pas une tête multi-label entraînée à télécharger, et le produit n’est pas open source. Choice n’émettra pas deux labels gagnants depuis une question. Les probabilités Noul de questions différentes ne sont pas les parts d’une même distribution : elles n’ont pas à sommer à 1, et il ne faut pas non plus en faire la moyenne pour une seule confiance. Réparer un JSON génératif est votre code, pas un champ de cette réponse. Si le texte est encore un fil d’e-mail brut, nettoyez-le avec les étapes de email-classification avant de poser plusieurs questions de tag. S’il vous fallait seulement le thème produit principal, revenez à customer-feedback-classification plutôt que de taguer chaque synonyme.