Un co-inventeur de ChatGPT affirme que la pièce manquante de l'IA est un modèle qui refuse de parler

Le 15 septembre, une startup de deux ans nommée TypeSafe AI est sortie de la clandestinité avec 40 millions de dollars en financement d'amorçage et un diagnostic sans détour de l'industrie de l'IA : les modèles conversationnels sont très doués pour parler, et c'est précisément pour cette raison qu'une grande partie de l'automatisation promise n'est jamais arrivée.

À lire aussi: Claude Haiku 5.5 est le petit modèle le moins cher d'Anthropic à ce jour · SpaceXAI livre Grok 4.7 pour le code aux prix de Grok 4.6, avec ses propres benchmarks à l'appui.

La réponse de l'entreprise s'appelle Jev, le premier d'une classe qu'elle nomme System One Models. Jev n'écrit pas de phrases. Il prend un état non structuré en entrée et renvoie des valeurs typées et structurées, assorties de scores de confiance calibrés pour chacune. Selon la formule de l'entreprise, il s'agit d'un « appel de fonction d'intelligence de pointe » : quelque chose qu'un programme peut insérer à un point de décision où une règle écrite à la main serait trop fragile et où un modèle de langage serait trop lent, trop coûteux, ou trop enclin à inventer des choses.

TypeSafe a été fondée en 2024 par Diogo Almeida, un ancien chercheur d'OpenAI qui a co-inventé les méthodes d'apprentissage par renforcement à l'origine d'InstructGPT et, par extension, de ChatGPT. Ses cofondateurs sont Erik Gafni et Sasha Sheng. Le tour d'amorçage a été mené par DCVC, et l'entreprise indique que Jev est disponible dès maintenant en accès anticipé, les développeurs étant retirés d'une liste d'attente selon les capacités disponibles.

Pourquoi un modèle renoncerait aux chaînes de caractères

L'argument repose sur une distinction facile à manquer. Un grand modèle de langage classique renvoie du texte, et presque tout ce qu'il fait en aval dépend du fait que quelqu'un reconvertit ce texte en décision. Son entraînement récompense les réponses que les évaluateurs humains préfèrent, ou celles dont l'exactitude peut être vérifiée automatiquement. Aucun de ces objectifs ne produit un modèle honnête sur son propre degré de certitude.

L'équipe d'Almeida soutient que c'est là le goulot d'étranglement. « Si un modèle peut accomplir une tâche 95 % du temps mais ne dit pas quand il se trouve dans les 5 % restants, il ne peut pas automatiser cette tâche », écrit l'entreprise dans son billet de lancement. Un système qui peut avoir raison la plupart du temps et qui est incapable de signaler les exceptions n'est pas un composant que l'on peut brancher dans un flux automatisé, car les défaillances restent invisibles jusqu'à ce qu'un élément en aval casse.

La méthode d'entraînement de TypeSafe s'appelle Reinforcement Learning for Calibrated Decisions, ou RLCD. Là où le RLHF optimise pour la préférence humaine, le RLCD optimise pour des décisions accompagnées de probabilités épistémiquement honnêtes. Les sorties du modèle sont contraintes par un schéma défini à l'avance, de sorte que les valeurs possibles et leur structure sont fixées avant l'exécution du modèle. TypeSafe affirme que cela rend les erreurs de type impossibles, et qu'un modèle qui ne génère jamais de texte libre ne peut pas halluciner de texte.

La seconde moitié du dispositif est l'échantillonneur. Les modèles de langage ordinaires génèrent un jeton à la fois, chacun conditionné par le précédent, ce qui explique pourquoi une requête difficile peut prendre des secondes et pourquoi le coût grimpe avec la quantité de texte produite. Jev génère l'ensemble de ses sorties en une seule requête, en parallèle. L'entreprise indique qu'une réponse de System One arrive en 70 à 500 millisecondes, contre les 3 à 329 secondes qu'elle mesure pour les modèles conversationnels de pointe, et qu'elle facture l'entrée à 0,042 dollar par million de jetons, les jetons de sortie étant gratuits.

Sur sa page d'accueil, TypeSafe annonce des gains allant jusqu'à 193,6 fois en vitesse et 444,6 fois en réduction de coût pour les types de charges de travail qu'elle vise, tout en précisant que ces chiffres se situent à l'extrémité optimiste de ce qu'elle s'attend à voir chez ses clients.

Le banc d'essai est le point faible

La partie intéressante du lancement n'est pas la promesse de vitesse. C'est la prudence avec laquelle l'entreprise nuance son argument sur l'intelligence, et la rapidité avec laquelle des observateurs extérieurs ont trouvé la faille.

TypeSafe a publié un ensemble d'évaluations de flux de travail portant sur 711 cas répartis en quatre métiers : le tri d'incidents de sécurité, l'observabilité sur les traces d'agents, le traitement de factures et le service client. Au lieu de noter les résultats par rapport à une vérité de terrain étiquetée à la main, l'entreprise prend la moyenne des jugements de deux modèles de pointe, GPT-6 Astra et Fable 5.1, comme réponse de référence. Face à cette référence, Jev occupe la frontière d'efficacité avec une large marge, répondant souvent en une fraction de seconde pour une fraction de centime.

Le tableau de l'exactitude est plus contrasté. Sur le propre tableau de bord de TypeSafe, la concordance globale de Jev avec la politique de référence est d'environ 67,8 %, en dessous des 74,1 % du meilleur comparateur visible. Sa meilleure performance concerne le service client, à 76,0 %, proche du meilleur modèle et au-dessus d'un autre. Sa plus faible concerne le traitement de factures, où il atteint 61,8 % contre 79,1 % pour le meilleur comparateur, le genre d'écart qui compterait en production. Une analyse détaillée publiée le même jour par le site Kingy conclut que les preuves publiques « soutiennent l'histoire des systèmes » autour du typage, du traitement par lots, de la latence et du coût, mais « ne soutiennent pas encore l'histoire la plus ambitieuse sur l'intelligence », en partie parce que les étiquettes de référence sont générées par des modèles plutôt que vérifiées.

TypeSafe ne cache pas ces réserves. L'entreprise signale que les flux de travail ont été construits par sa propre équipe de capacités, que la moyenne d'Astra et de Fable biaise la référence vers OpenAI et Anthropic, et que ses multiplicateurs mis en avant proviennent d'un test propre à une charge de travail et non d'une mesure universelle. Elle concède aussi que certaines comparaisons ne sont pas flatteuses, notamment celle où un évaluateur a constaté que Jev manquait un défaut d'écriture qu'un modèle de pointe avait repéré.

Le contrepoids est un petit test indépendant. Mike Taylor, de la newsletter Every, a fait passer 37 documents et 777 jugements dans Jev, qui a renvoyé ses résultats en moins de 0,7 seconde pour un coût d'environ un quart de centime. Dans un duel sur la détection de défauts, Jev a trouvé six des sept failles recherchées là où Fable 5.1 les a toutes trouvées, tout en tournant bien plus vite et pour moins cher. Voilà la forme du compromis que vend l'entreprise : pas meilleur que le modèle le plus intelligent, mais suffisamment bon sur des décisions étroites, à un prix et une vitesse qui rendent viable l'automatisation à grand volume.

Pourquoi la confiance est tout l'argument

L'argument de la calibration mérite plus d'attention que les graphiques de vitesse, car c'est lui qui change ce que le logiciel peut faire.

Un agent qui doit décider s'il émet un remboursement, signale une transaction ou oriente un dossier de support a besoin de deux choses de la part d'un modèle : une réponse et une estimation honnête du degré de confiance qu'on peut lui accorder. Les modèles conversationnels actuels ont tendance à fournir la première et à inventer la seconde. Demandez à l'un d'eux un niveau de confiance et il renverra généralement quelque chose de plausible et sans lien avec son taux d'erreur réel. La conséquence est que les équipes qui construisent de l'automatisation finissent par ajouter une relecture humaine à chaque décision, ce qui efface une grande partie des économies recherchées.

TypeSafe parie qu'un modèle entraîné à produire des probabilités calibrées peut franchir ce seuil, en laissant le logiciel agir sur les réponses à forte confiance et escalader les autres. C'est une promesse vérifiable, et c'est aussi une promesse fragile : une calibration mesurée sur les flux de travail d'un fournisseur dit peu de chose sur le comportement du modèle quand les entrées changent. Les documents publics n'incluent ni la latence de queue, ni les limites de débit, ni le comportement en cas de nouvelle tentative qu'une équipe de production voudrait connaître, et les courbes de confiance qui étayeraient l'affirmation centrale ne sont pas publiées dans leur intégralité.

Il y a une raison plus large pour laquelle la question de la calibration se pose maintenant. L'année écoulée a montré clairement que des modèles capables agissant en autonomie peuvent échouer de manière coûteuse, et que ces échecs sont souvent des problèmes de confiance plutôt que de capacité. Les systèmes qui savent dire « je ne sais pas » clairement, et le penser, sont ceux qui peuvent fonctionner sans qu'une personne surveille chaque étape.

Ce que Jev n'est pas

Il vaut la peine d'être précis sur les limites, car le cadrage invite à la surinterprétation. Jev ne peut pas rédiger un résumé, ébaucher un courriel ou expliquer son raisonnement en prose. Ce n'est pas un agent conversationnel plus petit ou moins cher, et l'entreprise ne prétend pas qu'il doive en remplacer un. Tout flux de travail qui doit produire des mots a encore besoin d'un générateur distinct, ce qui signifie que le coût réel d'une tâche achevée inclut un grand modèle venant s'ajouter aux décisions bon marché de Jev. Les démonstrations de l'entreprise s'appuient sur le code environnant pour contraindre la liberté du modèle, ce qui est honnête sur l'origine de la fiabilité.

Ce que Jev est, si les chiffres tiennent, c'est une primitive de décision rapide et peu coûteuse pour des questions étroites et à fort volume auxquelles le logiciel doit déjà répondre : ce message est-il abusif, cet enregistrement correspond-il à cette entité, cette requête doit-elle être transmise ou rejetée. Ce sont des tâches peu glamour, et elles sont extrêmement nombreuses.

Les démonstrations amusantes, et les sérieuses

Pour rendre l'argument concret, TypeSafe a livré des démonstrations destinées à être retenues plutôt que déployées. L'une pilote un bot dans Doom, en lui fournissant un état de jeu structuré et en lui demandant des décisions à environ dix requêtes par seconde, une charge de travail qui coûte selon l'entreprise environ 7 dollars par heure. Une autre joue au wikiracing, en naviguant d'une page Wikipédia à une autre à l'aide des seuls liens, une tâche où un seul mauvais choix fait dérailler la partie et où l'incapacité de Jev à halluciner un lien est un avantage.

Les usages commerciaux visés sont plus terre à terre et plus utiles : classer et orienter des tickets de support, noter et extraire des champs, se protéger contre les jailbreaks, et vérifier les entrées ou les sorties d'autres modèles. Ce sont les conditions floues dissimulées dans le logiciel, que les équipes ont jusque-là approximées avec des règles fragiles ou des invites adressées à un grand modèle. Le pari de Jev est qu'un modèle petit, rapide et lié à un schéma convient mieux qu'un modèle généraliste.

Ce pari est encombré. OpenAI, Anthropic et Google ont tous poussé les sorties structurées, et l'année écoulée a apporté une vague de petits modèles et de modèles spécialisés visant l'inférence bon marché. L'argument de TypeSafe est plus subtil : c'est la confiance calibrée, et non la capacité brute, qui décide si un modèle peut être digne de confiance pour agir sans humain dans la boucle. C'est une affirmation que les clients peuvent tester, et l'entreprise les y invite.

Ce qu'il faut surveiller

L'accès anticipé sera le vrai test, car les évaluations des flux de travail sont réalisées par le fournisseur. Surveillez si des équipes indépendantes publient des comparaisons sur vérité de terrain qui confirment les promesses de coût et de vitesse, et si les scores de confiance de Jev restent calibrés lorsque les entrées s'éloignent des démonstrations. Surveillez aussi si l'écart d'exactitude se comble sur des tâches plus difficiles comme le traitement de factures, où le modèle est actuellement à la traîne.

Le nom est un indice sur la stratégie. Jev est l'abréviation de Jevons, du nom de l'économiste du dix-neuvième siècle qui a observé que rendre une ressource plus efficace tend à augmenter la quantité qui en est consommée, et non à la réduire. La thèse de TypeSafe est que l'intelligence a été trop coûteuse pour être saupoudrée dans le logiciel ordinaire, et qu'une chute de coût d'un facteur cent la transforme en brique de construction plutôt qu'en destination. Si cela se produit, l'IA la plus utile dans une entreprise pourrait bien être le modèle avec lequel personne ne discute.