Classification de texte zero-shot en 2026 : prompts LLM vs Hugging Face vs API typée

La classification zero-shot répond à une question bornée : pour ce texte, lesquels de ces labels s'appliquent ? Vous fournissez les labels à la requête au lieu d'une tête figée entraînée sur vos tickets. Utile quand les files changent ou que les exemples propres manquent. Cela n'enlève pas l'évaluation : une mauvaise file facturation coûte encore. En 2026, le choix pratique porte souvent sur trois piles : un LLM génératif forcé en JSON, un pipeline NLI zero-shot Hugging Face, ou un modèle de décision typé qui renvoie Choice, Score ou des probabilités oui/non sans prose libre. Guide éditorial indépendant pour ingénieurs qui classifient déjà dans des agents, le support ou des lots. JevModel n'est affilié ni à TypeSafe AI, ni à Hugging Face, ni à MotherDuck ; aucun test payant face-à-face n'a été mené.

Beaucoup d'équipes demandent encore à GPT ou Claude de « renvoyer un JSON valide avec label et confiance ». Structured Outputs réduit les échecs de syntaxe sans rendre un enum choisi sémantiquement correct. Sur r/LLMDevs on distingue JSON valide et JSON utilisable : champs manquants, mauvais types, propriétés inventées, objets tronqués. La confiance auto-déclarée est une preuve faible : certains modèles répondent « 95 % » presque toujours ou encapsulent le JSON dans des fences markdown. Le coût croît avec les tokens générés. Gardez cette voie quand le même appel doit aussi rédiger une réponse après routage, ou quand les labels bougent et que vous acceptez réparation + revue. Traitez la sortie comme proposition non fiable : validez les enums côté serveur, refusez les labels inconnus, envoyez les cas limites à un humain.

Hugging Face décrit la classification zero-shot comme prédire une classe non vue comme cible d'entraînement dédiée à votre tâche. Le pipeline transformers charge un modèle NLI tel que facebook/bart-large-mnli, transforme chaque label en hypothèse (« This example is {label}. ») et score l'implication. Vous obtenez sequence, labels triés et scores sans JSON, ce qui évite une classe d'échecs de parse. Il reste à opérer le matériel ou un endpoint, choisir multi_label avec soin et ajuster les gabarits selon le domaine. Les scores sont des signaux NLI, pas une exactitude métier calibrée. L'auto-hébergement garde les données locales si tout le pipeline l'est ; télécharger des poids ne garantit pas la confidentialité. Préférez cette voie si Transformers tourne déjà, si vous devez rester offline/VPC et maintenir des révisions. Sinon, un contrat typé hébergé Choice/Score/Noul peut mieux convenir.

Un modèle de décision renvoie des réponses typées, pas de la prose. Avec Jev vous envoyez un state (texte/JSON) et des questions : Choice choisit parmi des labels, Score évalue une grille ordonnée, Noul renvoie une probabilité de oui. Les probabilities décrivent la distribution ; la confidence Choice résume la concentration, pas une exactitude mesurée. JevModel est un playground/API hébergé indépendant qui appelle typesafe/jev-1.13 via OpenRouter. Limites ici : texte/JSON seulement (pas de média), 8 000 caractères après validation, 1–8 questions, Choice 2–12 labels, 10 exécutions gratuites/jour UTC après e-mail (selon capacité). Pas de clé d'idempotence : vérifiez l'historique avant nouvel essai. Votre app garde permissions, tickets et bascule humaine. À choisir quand les labels sont connus, que vous voulez des probabilités structurées sans réparer le JSON, et acceptez le chemin de données amont. Ce n'est ni un générateur de réponses client, ni un runtime local de poids ouverts.

curl --fail-with-body https://jevmodel.app/api/v1/systemone \
  -H "Authorization: Bearer $JEVMODEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"state":"Package arrived damaged and I need a replacement.","questions":{"topic":{"type":"choice","instructions":"Choose the support topic.","criteria":{"shipping":"Delivery, tracking or damaged packages.","billing":"Charges, refunds or invoices.","review":"Unclear or mixed requests."}}}}'

Utilisez le tableau comme carte de décision, pas comme classement. Le blog MotherDuck rapporte, sur 100 000 lignes AG News, 89 % pour Jev en ~40 s à ~0,50 $, contre 88 % en ~32 min à 37,58 $ pour la voie GPT-5.6 Terra mesurée. L'article de Sebastian Raschka (29 sept. 2026) rapporte ~96,5 % (Choice) et ~96,2 % (Noul) sur IMDb, pour ~0,65 $ d'API sur cette course. Ce sont leurs tests. Ils ne prouvent pas une supériorité sur vos tickets. Scores NLI et labels parsés d'un LLM exigent la même discipline de jeu réservé. Si la confiance compte, préférez des distributions seuillables à un champ inventé dans la prose.

Figez un jeu étiqueté avant d'ajuster prompts, hypothèses ou critères Choice. Séparez développement, calibration et test final. Incluez cas ambigus, multilingues et d'erreur coûteuse. Notez les acceptations automatiques fausses, le volume de revue, les échecs de parse/schéma, la latence p50/p95 et le coût par décision correcte (avec retries). Pour LLM, comptez réparation et relances ; pour HF, épinglez révision et gabarit ; pour JevModel, validez code === 0, types et nombres, et envoyez les probabilités proches en revue. Passez d'abord en ombre : journalisez les propositions pendant que les humains gardent le contrôle. Si le budget d'erreur n'est pas tenu après revue, gardez règles ou hybride. Les graphiques publics sont des pistes ; votre scorecard décide.