Baseten joey-1 demande si chaque décision d’IA exige un grand modèle

« Quelle équipe doit traiter ce ticket ? » nécessite rarement une réponse de cinq paragraphes. Il faut choisir parmi quelques destinations valides, disposer d’une confiance suffisante pour décider de manière responsable et pouvoir demander de l’aide lorsque la demande ne correspond à aucun cas prévu.

Baseten a présenté joey-1 le 29 octobre 2026 pour ce type de travail. Conçu par son groupe de recherche Base Labs, le modèle se situe à l’extrémité la plus petite d’une famille de modèles de décision, aux côtés d’elephant-1 et de mammoth-1. Son intérêt repose sur un contrat de sortie plus restreint : des décisions et des probabilités, plutôt qu’une explication générée que l’application doit interpréter. L’annonce de Baseten présente le lancement.

La possibilité pratique consiste à répartir autrement le travail. Confiez à un petit modèle les décisions répétitives et bien définies ; consacrez davantage de ressources aux cas incertains restants. Ce guide explique le calcul des prix, trois applications illustratives et les vérifications qui rendent cette stratégie de routage utile.

Bannière officielle de la fiche du modèle joey-1 de Baseten. Image : Base Labs / Baseten, issue de son dépôt de modèle déclaré sous licence MIT ; redimensionnée avec des marges. Source de l’image · Licence et informations sur l’image.

Un modèle de décision commence par les choix que votre application peut accepter

Un modèle de langage généraliste peut classer une demande en écrivant « facturation », en renvoyant du JSON ou en expliquant pourquoi un client mérite un remboursement. Chaque interface a son utilité. Un modèle de décision spécialisé se concentre sur le choix parmi des réponses fournies et sur la restitution de probabilités structurées.

Cela transforme le travail à effectuer avant l’inférence. Il vous faut une question précise et des options décrivant des actions pertinentes. « Que devons-nous faire ? » est un contrat faible. « Laquelle des équipes facturation, assistance technique ou fraude doit recevoir ce dossier ? » est plus ciblé, même s’il faut encore une règle pour les demandes correspondant à plusieurs équipes ou à aucune.

La page joey-1 de la bibliothèque de modèles de Baseten, consultée le 2 novembre, documente des entrées textuelles et visuelles, des questions à choix, des décisions oui/non et une notation ordonnée via /v1/systemone. Le résultat est destiné à une utilisation programmatique. Il ne remplace pas un générateur distinct d’explications ou de réponses lorsque l’utilisateur en a besoin.

Considérez le petit modèle comme un guichet de tri. Sa valeur vient de l’orientation du travail ordinaire vers le bon endroit et de la transmission des cas inhabituels à une personne disposant de davantage d’autorité ou de contexte. Un guichet qui oriente avec assurance les cas difficiles au mauvais endroit crée du travail caché en aval, même si chaque inférence coûte peu.

C’est pourquoi l’application doit préserver l’incertitude. Un système de routage peut enregistrer une étiquette provisoire, poser une question de clarification ou transmettre l’élément à une personne. Il n’est pas obligé de transformer chaque distribution de probabilités en action métier immédiate.

Un centime achète des jetons d’entrée, pas un nombre fixe de décisions

Au 2 novembre 2026, la tarification officielle indique $0.01 pour 1 million de jetons d’entrée, avec les entrées en cache et la sortie à $0.00. Le « penny » désigne cette unité de jetons. Une demande comportant un long historique consomme davantage de traitement d’entrée qu’une demande courte et soigneusement délimitée.

Voici des calculs illustratifs au tarif d’entrée publié, avant taxes, autres services ou conditions commerciales. Ils supposent des entrées sans cache et un prix stable ; il s’agit d’un exemple de planification, pas d’une estimation de facture.

La formule est simple : le total des jetons d’entrée divisé par 1 million, multiplié par $0.01. Le calcul opérationnel est plus large. Incluez le coût des transmissions, de la préparation des données, des nouvelles tentatives, de la surveillance et des corrections manuelles.

Supposons que deux configurations de routage diffèrent de quelques dollars d’utilisation du modèle. La première envoie moins de cas en vérification, mais oriente parfois des demandes urgentes vers une file lente. La seconde transmet davantage de demandes et évite cette erreur. Le bon choix dépend du coût des erreurs et de la capacité disponible de vérification, et pas simplement de la facture de jetons la plus basse.

Cet argument se renforce à mesure que l’inférence devient moins chère. Quand l’utilisation du modèle représente une faible part du coût total du processus, une amélioration modeste du calibrage ou de la conception des étiquettes peut compter davantage qu’une nouvelle baisse du prix des jetons. Une inférence bon marché élargit les possibilités d’automatisation ; elle ne supprime pas la nécessité d’évaluer les résultats.

Schéma de routage original, inspiré de l’approche de transmission présentée dans l’annonce de Baseten du 29 octobre. Les seuils relèvent de l’application qui déploie le modèle.

Le routage des tickets est une bonne première tâche lorsque les étiquettes ont des responsables

Dans un processus d’assistance illustratif, joey-1 affecte les messages entrants à la facturation, à l’assistance technique ou à la sécurité des comptes. Une question oui/non distincte vérifie si le client demande un remboursement. Un score ordonné identifie le degré d’urgence du dossier.

Ces questions sont liées, mais ne doivent pas être fusionnées en une seule étiquette. Une demande de facturation peut aussi être urgente. Une demande de sécurité de compte peut comporter une demande de remboursement. Séparer les décisions facilite la définition de ce que reçoit chaque équipe et des combinaisons nécessitant un traitement particulier.

Commencez par rédiger les étiquettes avec les personnes responsables des files. Incluez des exemples de dossiers ayant suscité des désaccords par le passé. Décidez comment traiter un message mentionnant un échec de paiement causé par un défaut logiciel. Le modèle ne peut pas résoudre une ambiguïté organisationnelle que l’organisation n’a pas définie.

Pour le déploiement, comparez les recommandations aux décisions existantes avant de déplacer automatiquement le travail. Examinez les désaccords par catégorie : règle ambiguë, contexte manquant, erreur manifeste du modèle ou étiquette historique incorrecte. Un pourcentage global d’exactitude masque ces différents problèmes.

L’annonce de Baseten du 29 octobre présente joey-1 comme un modèle de première ligne, avec des modèles frères plus grands disponibles en cas d’incertitude. Elle rapporte une latence de bout en bout P50 de 20 millisecondes pour une demande moyenne de 2 000 jetons, dans ses conditions de service en production. Il s’agit d’une mesure du fournisseur sur une charge particulière de son service, et non d’une garantie de latence pour votre application ou votre matériel. Source : Baseten.

Un routeur documentaire doit reconnaître l’absence de destination adéquate

Un deuxième cas d’usage illustratif est la réception de documents. Une application reçoit un fichier et doit décider s’il relève du traitement des factures, de la vérification des dépenses ou d’une file documentaire générale. L’entrée textuelle, éventuellement accompagnée d’images, peut rendre le modèle pertinent pour des documents mixtes, à condition que la représentation fournie contienne les informations nécessaires à la tâche.

Définissez précisément la décision réelle. Vérifier si une page ressemble à une facture diffère du fait de vérifier que cette facture est authentique, juridiquement suffisante ou payable. Un classificateur peut aider à choisir un processus sans recevoir l’autorisation d’approuver un paiement.

Les cas de test les plus précieux peuvent se trouver hors de la taxonomie : un reçu joint à un contrat, une image trop floue pour être lue ou une langue non prise en charge. Si l’application ne propose que trois destinations valides, elle a besoin d’un autre mécanisme pour les preuves incomplètes et les contenus inconnus. Un parcours explicite de vérification est plus facile à exploiter qu’un choix forcé.

Suivez aussi les évolutions de la population d’entrée. Un modèle qui voit surtout de courtes factures nationales pendant l’évaluation peut ensuite recevoir des relevés de plusieurs pages et des courriers numérisés. Ne surveiller que l’étiquette finale choisie peut masquer cette évolution. Consignez la longueur des demandes, le type d’entrée, l’incertitude et les résultats de vérification à un niveau approprié de confidentialité.

La fiche du modèle publiée, consultée le 2 novembre, décrit joey-1 comme un modèle de 2B de paramètres, post-entraîné à partir de Qwen3.5-2B, et indique une licence MIT. Ces faits étayent une option de déploiement à poids ouverts. Ils n’établissent ni un besoin universel en mémoire, ni des performances sur CPU, ni l’autorisation de réutiliser toutes les illustrations de l’annonce.

Les contrôles d’images deviennent utiles lorsque la condition est observable

Pour un troisième scénario, imaginez vérifier les photographies de produits soumises avant leur entrée dans une vérification manuelle du catalogue. Des questions utiles pourraient demander si une étiquette est visible, si l’image contient l’objet demandé ou si la photographie est trop masquée pour permettre un jugement. Chaque question doit désigner un élément observable dans l’image fournie.

Une grille peu utile mélange observation et faits cachés. « Ce vendeur est-il digne de confiance ? » ne peut pas être déterminé à partir d’une seule photographie de produit. « La zone du numéro de série demandé est-elle visible ? » est plus précis et donne au processus suivant une raison concrète de demander une autre image.

La notation ordonnée peut être utile lorsque les vérificateurs partagent déjà une grille, par exemple inutilisable, à vérifier et utilisable. Rédigez les critères en des termes qu’une personne peut appliquer de manière cohérente. Si deux niveaux adjacents sont indiscernables même pour des humains, une distribution de probabilités ne réparera pas la taxonomie.

Utilisez le modèle pour hiérarchiser les vérifications avant d’autoriser le rejet automatique. Les soumissions rejetées peuvent affecter directement les clients, et le coût d’un faux rejet peut dépasser les économies de l’automatisation. Une étape de vérification fournit aussi des exemples pour affiner la grille et déterminer si les performances diffèrent selon les conditions d’entrée.

Il s’agit de conceptions illustratives, pas de déploiements rapportés de joey-1. Leur point commun est une question délimitée suivie d’une étape réversible. C’est un point de départ raisonnable pour comprendre le comportement du modèle sur vos données.

Les probabilités ont besoin d’une règle avant de devenir des actions

Une valeur de confiance n’est pas un indicateur de permission. Si l’application choisit d’agir au-dessus de 0.90, ce seuil est un choix de conception dont il faut mesurer les conséquences. Un score élevé peut encore être erroné, surtout si la demande diffère des données utilisées pour établir le seuil.

Des erreurs différentes méritent des règles différentes. Orienter une question ordinaire vers la mauvaise équipe d’assistance est gênant. Traiter un signalement de prise de contrôle de compte comme une demande habituelle peut coûter beaucoup plus cher. Le même seuil de probabilité ne doit pas automatiquement gouverner les deux tâches.

Cadre d’évaluation original. La couverture, le coût des mauvaises actions et la qualité des transmissions sont des mesures applicatives ; le schéma ne rapporte aucun résultat mesuré de joey-1.

Constituez un jeu tenu à l’écart avec des cas ordinaires représentatifs, des cas difficiles et des entrées hors périmètre. Pour chaque seuil proposé, examinez la proportion traitée automatiquement et les erreurs dans cette proportion. Puis examinez le sort du reste : un modèle qui évite les erreurs en transmettant presque tout peut laisser le processus inchangé.

Comparez la chaîne complète à un modèle plus grand utilisé seul. La conception commençant par un petit modèle ajoute une étape de routage, avec ses propres modes d’échec et sa latence. Elle l’emporte si suffisamment de demandes peuvent être traitées correctement à la première étape et si la transmission améliore le traitement des cas difficiles restants.

Commencez par l’API hébergée, ou budgétez explicitement l’auto-hébergement

Baseten propose des Model APIs hébergées, des déploiements dédiés et des poids téléchargeables. Leur contexte et leurs conditions de service doivent être vérifiés séparément. L’article de lancement décrit un contexte de 16k pour les Model APIs et une option de 262k en déploiement dédié, tandis que la fiche du modèle spécifie une longueur de séquence d’entraînement de 16 384 jetons et refuse les demandes dépassant les limites de son entraînement. Il n’existe pas de maximum unique à recopier indistinctement pour tous les parcours. Article de lancement, fiche du modèle.

1. Choisissez un seul contrat de décision. Nommez les options valides, le sens de chacune et ce que fait l’application lorsque les éléments sont insuffisants.
2. Choisissez un mode de déploiement. Pour un pilote hébergé, ouvrez la page d’API du modèle et créez des identifiants dans l’interface de compte du fournisseur. Pour un service local, suivez les exigences d’exécution aux versions fixées dans la fiche du modèle.
3. Envoyez une demande minimale. L’exemple officiel d’API utilise https://inference.baseten.co/v1/systemone avec un state, des questions typées et l’identifiant de modèle decision-models/baseten-joey-2b-latest.
4. Validez la réponse structurée. Rejetez les résultats mal formés ou indisponibles, conservez les probabilités nécessaires à l’évaluation et gardez la règle de routage dans votre application.
5. Évaluez en parallèle sans agir. Comparez les recommandations aux résultats vérifiés avant d’activer des actions automatiques.
6. Ajoutez et mesurez la transmission. Transmettez les cas incertains ou lourds de conséquences à un modèle plus grand ou à une personne, puis examinez le résultat du parcours entier.

La fiche du modèle documente une configuration auto-hébergée exigeant un GPU CUDA et un environnement de service aux versions fixées. « 2B » décrit la taille du modèle ; cela ne promet pas qu’un ordinateur portable quelconque dispose de suffisamment de mémoire. Incluez les surcoûts d’exécution, le traitement des images, la concurrence et la longueur de contexte dans le dimensionnement du déploiement.

Un pilote d’API peut répondre à la question de l’adéquation au produit avant d’investir dans cette infrastructure. L’auto-hébergement devient une décision distincte sur le contrôle, l’utilisation, l’effort opérationnel et le coût total. Les poids ouverts rendent ce choix possible ; ils ne le rendent pas automatiquement économique.

Un jeu de rejeu protège le processus lorsque les modèles ou les consignes changent

Conservez une collection versionnée de demandes vérifiées une fois le premier pilote opérationnel. Incluez des cas ordinaires, des erreurs coûteuses et des exemples où la bonne réponse consiste à demander de l’aide. Conservez la formulation des questions et les descriptions des options à côté du résultat attendu, avec des données que vous êtes autorisé à garder.

Quand vous modifiez une consigne, un seuil ou une configuration de service, rejouez cette collection avant d’étendre le trafic. Un gain dans une catégorie peut masquer une régression dans une autre. Par exemple, un routage plus affirmé peut réduire le volume de vérification tout en augmentant les erreurs sur les messages courts et ambigus. La moyenne globale seule ne peut pas expliquer ce compromis.

Consignez l’identifiant réel du modèle et le parcours de service utilisé pour chaque évaluation. Si un déploiement suit un identifiant mobile latest, établissez comment vous remarquerez les changements de comportement et réexaminerez l’acceptation. Un schéma applicatif stable ne garantit pas des décisions identiques indéfiniment.

Testez aussi les pannes du service. Un délai dépassé, un modèle indisponible ou une réponse invalide doit conduire à un parcours de récupération défini, plutôt que choisir silencieusement une équipe par défaut. Cette valeur par défaut est elle-même une décision métier, qui peut être inadaptée aux demandes sensibles. Un système fiable à petit modèle traite les réponses indisponibles aussi délibérément que les réponses confiantes. Cette discipline d’exploitation compte même lorsqu’une demande ordinaire coûte une fraction de centime.

Les petits modèles rendent plus visible la qualité de la frontière de décision

Notre avis : joey-1 est surtout intéressant lorsque l’application a déjà clairement défini ses choix. Des décisions rapides et peu coûteuses peuvent déplacer beaucoup de travail, mais une mauvaise taxonomie ne fait qu’accélérer les erreurs.

La question précieuse est de savoir quelle quantité de travail le système peut traiter correctement dans un périmètre connu et comment il traite le reste. Un petit modèle mérite sa place lorsque le parcours de transmission fait partie du produit, plutôt que d’être une note de bas de page après le prix.

Sources

• Baseten : des décisions pour un penny, présentation de joey-1, 29 octobre 2026.
• Bibliothèque de modèles et exemple d’API Baseten joey-1, consultés le 2 novembre 2026.
• Fiche du modèle joey-1 de Base Labs, consultée le 2 novembre 2026. Les résultats de référence sont rapportés par l’éditeur ; l’entrée Artificial Analysis est identifiée comme une reproduction interne.

Reliez votre analyse à sa source

Telli.sh est une possibilité pour conserver des sources autorisées et les notes à l’appui d’une décision technique. Créer un espace de notes.