Dans Men in Black II, l'agent J rend visite à K dans un bureau de poste en apparence tout à fait ordinaire. Il ouvre une machine de tri du courrier et y découvre un extraterrestre qui trie frénétiquement les lettres.
C'est une petite scène ridicule, mais elle nous offre aussi une façon très utile de penser l'IA.
Entre la réception d'une information et l'action à mener, il y a souvent une décision plus petite à prendre : où cela doit-il aller ?
Si cette décision est prise correctement dès le départ, le reste du système peut suivre le chemin approprié.
Je pense beaucoup à ce petit extraterrestre lorsque je développe des logiciels d'IA.
Une application reçoit une question de facturation, un signalement de bug, une photo de produit et une demande de démonstration. Chacun de ces éléments nécessite un traitement différent. Pourtant, on finit souvent par demander au même grand modèle de langage d'examiner le tout et de déterminer la suite. Ce n'est ni efficace, ni économique.
C'est pourquoi je pense que les modèles spécialisés joueront un rôle bien plus important dans l'avenir de l'IA. Par exemple, Jev est conçu pour prendre des décisions structurées sur lesquelles un logiciel peut agir. Coinbase a adapté Qwen3.5-9B spécifiquement pour la détection de fraude dans son service Onramp. Chacun se concentre sur une tâche définie, avec des résultats mesurables.
https://x.com/brian_armstrong/status/2109412046244913643
Je construis la couche de tri
Les requêtes familières peuvent être envoyées directement vers un workflow défini. Celles qui exigent plus de raisonnement sont transmises à un autre modèle. Les cas ambigus sont signalés pour clarification ou vérification.
L'économie potentielle vient du fait qu'on accorde à chaque requête exactement la puissance de traitement dont elle a besoin. Ensuite, il faut mesurer si le trieur prend suffisamment de bonnes décisions pour justifier sa présence.
Notre point de départ a été CludeMem. Nous cherchions à déterminer ce qu'une IA devait mémoriser, ce qu'elle devait récupérer, et ce qui consommait inutilement des tokens. Une préférence durable, une instruction temporaire et une question non résolue méritent des traitements différents. Avant de prendre ces décisions, nous devions classifier l'information.
C'est ainsi qu'est née l'idée d'une couche de classification plus large. Cette même étape pourrait aider à trier une demande d'assistance, à router un document ou à choisir quel spécialiste doit traiter une tâche.
GIF
À mesure que de nouveaux modèles spécialisés apparaissent, les applications devront décider quelles entrées méritent leur attention. C'est précisément ce que nous construisons : classifier ce qui arrive, traiter localement les cas familiers et transmettre les plus complexes au modèle ou au processus de révision approprié.
Voici Clude Cat (Cat pour catégorisation 😉)
Avant de stocker un souvenir, de récupérer un document, d'appeler un outil ou de générer une réponse, il faut généralement décider du type d'information auquel on a affaire.
Ces décisions sont omniprésentes.
Imaginons quelqu'un qui écrit à une entreprise de logiciels :
« Où puis-je télécharger ma facture ? »
Un agent IA pourrait lire le message, examiner ses outils, analyser l'intention du client et décider de chercher une facture.
Un workflow plus direct ressemblerait à ceci :
Message → demande de document de facturation → vérification du compte → récupération de la facture.
Un modèle de langage pourrait toujours rédiger la réponse. La décision initiale de routage pourrait, elle, être gérée localement.
Changeons maintenant le message :
« J'ai été facturé deux fois, mon compte est bloqué et je veux résilier. »
Envoyer cela avec assurance dans un simple workflow de facturation créerait davantage de travail. Il y a plusieurs problèmes à résoudre, et la bonne réponse pourrait nécessiter des clarifications ou l'intervention d'un humain.
Le trieur doit avoir le droit de dire : « Je ne peux pas classer cela de manière fiable. »
C'est un aspect essentiel du produit. Un système qui envoie avec assurance les requêtes vers la mauvaise destination peut annuler son avantage de vitesse par le travail nécessaire pour corriger ses erreurs.
Pour le client, le bénéfice attendu est moins d'attente et moins de répétitions.
Pour le développeur, c'est une décision explicite qu'il peut inspecter, tester et modifier. Il peut voir la catégorie sélectionnée, la version du modèle, le temps de traitement et savoir si le système a refusé de trancher.
Sous le capot, l'implémentation textuelle commence par un petit modèle préentraîné appelé encodeur.
Il convertit un message en une liste de nombres représentant les aspects de son sens. Les développeurs appellent cette représentation un embedding.
« Où est ma facture ? » et « J'ai besoin d'une copie de ma note » utilisent des mots différents. Leurs représentations numériques peuvent néanmoins être suffisamment similaires pour que le système reconnaisse le même type de requête.
Une couche de classification utilise ces représentations pour évaluer les catégories définies par le développeur.
Nous avons implémenté deux approches. L'une compare le message entrant avec des exemples de chaque catégorie. L'autre apprend les frontières entre les catégories à partir d'exemples étiquetés.
Dans l'approche ajustée (fitted), nous gardons l'encodeur fixe et entraînons une couche de décision plus petite au-dessus. Pas besoin d'entraîner un nouveau modèle de base pour chaque application.
Le développeur doit tout de même définir la signification des catégories et les relier à des actions utiles. Le classifieur ne peut pas inventer les départements de l'entreprise, sa politique de remboursement ou les permissions des comptes.
Il lui faut également une politique d'acceptation.
La catégorie obtenant le meilleur score peut malgré tout correspondre assez mal. Deux catégories peuvent être presque à égalité. Une requête inhabituelle peut ressembler à quelque chose de familier.
Nos scores locaux actuels ne sont pas des probabilités calibrées. Un score de 0,92 ne signifie pas automatiquement « 92 % de chances d'être correct ».
Nous devons tester ce qui se passe lorsque ces scores contrôlent les décisions.
La sortie distingue donc une catégorie acceptée, une requête nécessitant une vérification et une défaillance technique. Les délais d'attente, les annulations et les erreurs de modèle doivent aussi être gérés de manière prévisible.
C'est toute l'ingénierie autour du trieur. Elle détermine si une autre application peut utiliser le résultat de façon sûre et cohérente.
Nous avons mené une expérience sur 770 requêtes bancaires pour voir si cette approche pouvait réduire le travail des modèles génératifs.
La première configuration envoyait chaque requête à un modèle Qwen2.5 7B exécuté localement pour classification.
La seconde utilisait d'abord notre classifieur local, puis envoyait les requêtes non résolues à Qwen.
Voici les résultats :
- Les appels à Qwen sont passés de 770 à 227.
- Les classifications correctes sont passées de 535 à 642.
- La précision globale sur toutes les entrées est passée de 69,5 % à 83,4 %.
- La somme des temps de requête mesurés est passée de 299,7 secondes à 87,7 secondes.
L'étape locale a évité 543 appels à Qwen, soit une réduction de 70,5 %.
La mise en cache est restée activée, et l'approche directe a été exécutée avant l'approche combinée. Les chiffres de chronométrage excluent la configuration et les phases de chauffe. Nous avons mesuré uniquement la classification, sans générer de réponses finales aux clients ni payer de fournisseur de modèle.
Ces chiffres décrivent cette configuration précise. Ils ne prouvent pas une supériorité sur tous les LLM ni ne garantissent des économies pour le client.
Une autre expérience, menée ultérieurement, a testé un classifieur local ajusté sur 24 intentions liées au voyage et au milieu professionnel.
Sur 720 requêtes, il en a traité 688 localement. Parmi celles-ci, 681 étaient correctes et sept erronées. Il en a laissé 32 pour vérification.
Cela nous donne deux mesures différentes :
- Couverture : il a traité 95,6 % des requêtes localement.
- Précision des acceptations : il a eu raison dans 99,0 % des décisions qu'il a acceptées.
Les deux doivent figurer dans le résultat. Un classifieur pourrait afficher une précision impressionnante en n'acceptant qu'une poignée de requêtes faciles.
Nous avons aussi testé 100 000 entrées inhabituelles censées sortir de ses catégories prises en charge. Il a été précis dans plus de 94 % des cas.
Reconnaître ce que le système ignore fait toujours partie du travail.
La vitesse exige la même rigueur. Lors d'un test séparé à CPU chaud, le classifieur bancaire complet a pris environ 1,8 milliseconde par requête en médiane sur un M4 Max. Cela incluait la tokenisation, l'embedding et le scoring.
Cela excluait le téléchargement et le démarrage du modèle. C'est une mesure de classification, pas le temps nécessaire pour résoudre l'ensemble de la requête de l'utilisateur. Cela ne garantit pas non plus les mêmes performances sur un téléphone ou un ordinateur portable classique.
Jev s'inscrit dans cette discussion car il traite déjà une classe similaire de décisions.
TypeSafe décrit Jev comme un modèle destiné aux jugements bornés, notamment pour choisir entre des options fournies et router des requêtes vers du code classique, des modèles spécialisés ou des humains. \Documentation sur le routage d'intentions de Jev\
Le rôle que j'envisage pour Jev est celui d'une voie d'escalade optionnelle pour les requêtes que le classifieur local ne peut pas résoudre de manière fiable.
L'architecture vers laquelle nous travaillons est simple :
Requête entrante → classification locale → les requêtes familières suivent un chemin défini ; les requêtes incertaines passent à Jev, à un autre modèle ou à une vérification humaine.
Sans Jev, cette même étape de classification locale peut renvoyer les requêtes non résolues au LLM existant de l'application, à l'étape de clarification ou au processus de vérification.
Le développeur contrôle les catégories, les seuils d'acceptation et les solutions de repli. Il peut intégrer le classifieur local dans un workflow existant et mesurer quelles décisions celui-ci peut prendre en charge.
Aujourd'hui, l'intégration de Jev fonctionne en mode shadow, comparant les décisions sur cinq grands thèmes sans modifier le comportement de l'application. L'étape suivante consiste à tester si une escalade sélective améliore le workflow complet. Les résultats de Qwen ci-dessus ne constituent pas un benchmark de Jev.
C'est ce que nous devons mesurer : moins d'appels inutiles aux modèles, un traitement plus rapide des requêtes familières et un chemin explicite pour les cas nécessitant plus d'attention.
Nous avons commencé à étendre cette même approche aux images.
Imaginez une entreprise recevant un reçu, une capture d'écran d'erreur et une photo de produit. Chacun nécessite un chemin de traitement différent.
Le reçu pourrait aller vers l'extraction de reçus. La capture d'écran vers un workflow d'assistance. La photo de produit vers un workflow de catalogue. Une image incertaine serait envoyée en vérification.
Le classifieur choisit la destination. Lire le total de l'achat, diagnostiquer l'erreur et identifier les détails du produit restent des tâches distinctes.
Notre implémentation expérimentale pour les images utilise un encodeur CLIP préentraîné pour produire une représentation numérique de l'image.
Un candidat de recherche ajusté a correctement classifié 19 photographies de produits alimentaires sur 20 lors d'un petit test de diagnostic. Il a également envoyé les 30 images de feuilles de haricot en vérification.
L'erreur concernait l'étiquette nutritionnelle et le code-barres d'une bouteille, classifiés comme un reçu.
Vous voyez le problème. Les deux peuvent contenir du texte dense, des chiffres et des mises en page rectangulaires. Il nous faut des exemples qui enseignent la frontière pertinente pour notre application.
Cet échantillon est trop restreint pour tirer des conclusions valables en production. Les étiquettes provenaient du jeu de données plutôt que d'une validation indépendante, et aucun nouvel exemple de reçu ou de capture d'écran n'était inclus dans le test. La démo publique utilise une base de référence distincte, le résultat du candidat ajusté ne doit donc pas lui être attribué.
Le traitement d'images était également plus lourd que la classification de texte. Le traitement médian à chaud a pris environ 36 millisecondes sous Node et 197 millisecondes sous Chromium sur le M4 Max. Le navigateur a d'abord besoin d'environ 85 Mio de ressources de modèle, en plus de son environnement d'exécution.
L'exécution locale a aussi un coût. La taille du téléchargement, la mémoire, le temps de démarrage et les performances de l'appareil doivent tous entrer dans l'évaluation.
Le produit que j'imagine s'intègre dans une application existante où il décide de la suite des événements.
Un développeur définit les catégories, fournit des exemples représentatifs, relie les destinations et choisit ce qui doit se passer lorsque la classification est incertaine.
Le premier déploiement devrait observer le workflow actuel sans en modifier le résultat. Nous pourrons ensuite comparer les décisions proposées aux résultats validés avant de laisser le classifieur contrôler le routage.
Nous devons inspecter les erreurs acceptées avec autant de soin que les requêtes rejetées. Sinon, une décision fausse mais prise avec assurance risque de disparaître derrière un score rassurant.
L'entraînement, le calibrage et les tests nécessitent également des données distinctes. L'entraînement enseigne les catégories. Le calibrage définit les règles d'acceptation. Un test protégé vérifie le résultat figé.
Dès qu'une erreur de test influence le modèle suivant, cet exemple devient une donnée de développement. L'évaluation suivante exige alors un nouveau test.
Le petit extraterrestre du tri postal permet de visualiser facilement la tâche. En construire une version utile implique de découvrir exactement quelles entrées il peut gérer, quand il doit demander de l'aide et ce que coûtent ses erreurs.
L'étape suivante est un workflow représentatif avec des étiquettes indépendantes et un suivi de chaque résultat. Nous devons mesurer combien de requêtes empruntent la voie locale, combien atteignent un autre modèle, combien tournent mal, et si l'application complète devient plus rapide ou moins chère après avoir pris en compte ces erreurs.
Il est temps de monter en puissance et de donner quelques stéroïdes à ce modèle local.
