Ces deux jours-ci, si vous brossez souvent le cercle technologique et la communauté des développeurs, il y a de fortes chances que vous ayez été Je suis Ce nom est passé à travers l'écran.
Curieusement, il ne ressemble pas du tout au « grand modèle » que nous connaissons.
Il ne vous accompagne pas pour discuter, n'est pas responsable de l'écriture d'articles et n'est pas adapté pour le laisser écrire un morceau de code en direct. Il est même difficile de le comprendre comme un produit comme ChatGPT, Claude.
Mais c'est un tel modèle « n'écrivez rien » qui a rapidement attiré l'attention de la communauté des développeurs récemment.
La raison est en fait assez simple :
Jev n'écrit pas des réponses pour les gens, mais pour juger le programme.
Si les grands modèles traditionnels sont bons dans la « génération », alors Jev tente de résoudre un autre type de problèmes dans les systèmes logiciels, qui sont énormes mais souvent négligés :
Qu ' est-ce que je choisis ensuite ?
Ce qui semble être un petit changement, peut en fait correspondre à une direction très importante dans l'architecture de l'agent d'IA.
Qu ' est-ce que jeev ?
Tout d'abord, clarifier les questions les plus confuses.
Jev de la startup AI de San Francisco TypeSafeC'est un modèle à source fermée.
Ce n'est pas le même que le positionnement du produit de ChatGPT et Claude, et ce n'est pas un simple changement d'un modèle de chat traditionnel par un emballage API.
Dès le début de la conception, Jev s'est fixé à un objectif très étroit :
Permet au modèle de trier, de sélectionner, de juger et de noter rapidement.
Ainsi, vous ne le faites pas comme en utilisant un LLM ordinaire, ce qui le laisse :
"Aidez-moi à écrire un article sur l'IA."
Ce qu ' il est vraiment bon à faire est :
« Ce message utilisateur concerne-t - il un remboursement, une logistique ou une autre question ? »
ou :
"Quel bouton de cette page correspond le mieux à la tâche actuelle ?"
Ou encore :
« Cette sortie doit-elle être vérifiée ? »
En d'autres termes :
Le grand modèle traditionnel ressemble plus à un expert parlant, tandis que Jev ressemble plus à un module de décision à grande vitesse.
À l'heure actuelle, Jev fournit principalement des services via API et n'a pas de poids de modèle public. Par conséquent, la plupart des projets connexes que vous voyez sur GitHub sont des applications et des outils construits par les développeurs autour de l'API Jev, plutôt que le poids open source du modèle Jev lui-même.
Deuxièmement, la différence la plus importante : il n'est pas responsable de « écrire » du tout.
La façon la plus simple de comprendre Jev est de comparer le LLM traditionnel et Jev ensemble.
Supposons que votre programme reçoit un message de service client :
« Quand allez-vous me rembourser ? J'attends depuis une semaine ! »
Si vous utilisez ChatGPT ou Claude, vous devez généralement dire au modèle :
- Analyse des intentions des utilisateurs
- Juger l'humeur
- Classification de sortie
- Retour au format JSON spécifié
Enfin, le programme extrait les résultats du texte généré par le modèle.
Le problème est :
Il n'y a probablement qu ' une chose que le programme veut vraiment savoir :
refund
ou :
true
même :
0.93
La longue analyse ci-dessus est un coût supplémentaire pour le programme.
Jev avait l'opposé.
Puisque le programme n'a finalement besoin que d'un jugement, ne laissez pas le modèle générer du texte redondant.
C'est aussi ce que Jev mérite de regarder le plus.
Il résout principalement trois problèmes.
Si Jev est considéré comme une API plutôt que comme un chatbot, alors ses capacités peuvent être simplement comprises en trois types de questions.
1. Question de jugement : oui ou non
La première catégorie est un jugement booléen.
Par exemple :
« Ce commentaire contient-il une attaque contre le service client ? »
Le modèle n'a pas besoin d'expliquer pourquoi, ni d'écrire une analyse.
Il donne directement une probabilité, par exemple :
true: 0.94
false: 0.06
Après avoir obtenu les résultats du programme, vous pouvez décider par vous-même :
confidence > 0.8
Ensuite, le processus correspondant est déclenché.
Ceci est particulièrement pratique pour les tâches telles que l'audit de contenu, le filtrage des spam, le détournement automatique, etc.
2. Choisissez une option fixe.
La deuxième catégorie est plus proche des tâches classiques traditionnelles.
Par exemple, un système de service à la clientèle prédéfini :
0 = 账单问题
1 = 物流问题
2 = 退款问题
3 = 其他
La tâche du modèle n'est pas de créer une catégorie elle-même, mais :
Choisissez entre ces options.
C'est très important pour les systèmes d'ingénierie.
Le LLM traditionnel est souvent exigé par le biais de l'exigence Prompt :
"Veuillez suivre strictement le format JSON."
Mais le modèle, après tout, génère du texte, qui est encore théoriquement possible :
- Une explication supplémentaire
- Erreur de format JSON
- Créer une catégorie qui n'existe pas
- Étiquette de sortie orthographiée différemment
Et le modèle à option fixe peut limiter directement l'espace de sortie à un ensemble de candidats spécifiés par le développeur.
Pour les programmes, cela fait une grande différence :
L'IA n'est plus chargée d'« écrire les résultats », mais de « choisir les résultats ».
3. Question de notation : attribuer une note estimée à un objet
La troisième catégorie est Score.
Par exemple, vous voulez juger de la force émotionnelle d'un message client :
1 = 非常平静
2 = 有些不满
3 = 明显不满
4 = 愤怒
5 = 极度愤怒
Le modèle ne renvoie pas une analyse de l'humeur, mais une distribution complète des scores.
Ainsi, le programme peut développer sa propre stratégie :
- 1 ~ 2 : Traitement automatique
- 3 : Le service client général prend en charge
- 4 ~ 5 : Promouvoir le superviseur manuel
AI est responsable du jugement.
Les règles d'affaires restent entre les mains du programme.
C'est en fait une idée d'ingénierie très importante.
Quatrièmement, ce qui est vraiment intéressant : une entrée, vous pouvez répondre à beaucoup de questions en même temps
Une autre caractéristique de Jev est la possibilité de prendre plusieurs décisions en même temps autour de la même entrée.
Par exemple, un bon de travail de service à la clientèle, vous pouvez vous préoccuper en même temps :
- Dans quelle catégorie d'affaires ?
- Quel est le niveau d'urgence ?
- Comment les clients se sentent-ils ?
- Avez-vous besoin d'une révision manuelle ?
Les scénarios traditionnels peuvent nécessiter plusieurs appels à un modèle.
Et ce modèle spécial axé sur la prise de décision peut combiner ces problèmes pour traiter.
Ainsi, une entrée n'est plus :
Lire une fois → Générer une réponse → Lire une fois de plus → Générer une réponse à nouveau
Et plus comme :
Lire une fois → Completer plusieurs jugements en même temps.
Pour les systèmes qui doivent gérer un grand nombre d'événements, cette conception peut être plus importante que la simple recherche de la question de savoir si le modèle « serait mieux écrit ».
5 - Pourquoi est-ce que ça va si vite ?
Il y a ici une différence fondamentale entre Jev et le grand modèle génératif traditionnel dans la façon de raisonnement.
Les modèles que nous connaissons comme GPT, Claude, etc. dépendent essentiellement beaucoup de la génération autorégressive.
Une compréhension simple :
Le modèle génère le premier jeton, puis le prochain jeton est généré en fonction du contenu précédent, puis continue la génération.
Si vous lui faites écrire un paragraphe, il doit décoder continuellement jeton par jeton.
Mais pour de nombreuses décisions de programme, il n'est tout simplement pas nécessaire de générer des dizaines, des centaines, voire des milliers de jetons.
Supposons que la question soit simplement :
"Il y a 30 boutons sur cette page, sur lequel cliquez-vous ?"
Le résultat que le programme a vraiment besoin peut être tout simplement :
button_17
Alors pourquoi laisser le modèle réfléchir, puis organiser le langage, puis produire une explication ?
C'est là que Jev essaie d'intervenir.
Limitez l'espace de sortie de l'IA à un espace de décision limité.
Du point de vue de l'ingénierie, cela équivaut à mettre :
« générer une réponse »
Devenir :
« Calculer les probabilités et faire des choix parmi des candidats limités ».
La tâche est plus simple, la sortie est plus courte, et le lien d'inférence peut naturellement être fortement comprimé.
Par conséquent, l'indicateur principal mis en évidence par Jev officiellement n'est pas « combien de temps il peut écrire », mais plutôt :
Combien de temps, combien de calcul et combien d'argent une décision nécessite.
Le vrai tueur n'est peut - être pas « rapide », mais « probabilité ».
Si Jev n'avait qu ' une caractéristique :
« Le modèle de classification est rapide. »
Ce n'était pas si surprenant.
Ce qui est vraiment remarquable, c'est qu ' il tente de résoudre un autre problème de longue date :
La fiabilité du modèle est-elle fiable ?
Un problème se pose souvent avec les modèles classifiés traditionnels :
Le modèle était très sûr d'avoir raison.
Mais en fait, cela pourrait être scandalement faux.
Par exemple :
预测：退款问题
置信度：99%
Résultats Après examen manuel, il a été constaté que :
Les utilisateurs demandent en fait de la logistique.
Si un tel modèle est mis dans un système automatisé, le problème est gênant.
Parce que l'ingénieur peut écrire :
confidence > 95%
→ 自动执行
Si la confiance n'est pas calibrée, ce seuil n'a pas beaucoup de sens.
Donc, l'une des directions que Jev a soulignées, c'estCalibration de probabilité。
Idéalement :
Le modèle dit qu 'il a 80% de certitude, alors les statistiques à long terme, il devrait avoir environ 80% de précision.
De cette façon, la probabilité de la sortie du modèle a vraiment une valeur d'ingénierie.
Parce que l'IA ne se contente pas de dire au programme :
Je pense que la réponse est A. »
Il dit aussi au programme :
« Je suis sûr de A. »
Entre les deux, la différence est en fait très grande.
Qu ' est-ce que cela a à voir avec l'agent ?
C'est peut - être la vraie raison pour laquelle Jev a récemment attiré l'attention des développeurs.
Dans le passé, nous parlions d'agents d'IA et nous nous concentrions souvent sur le « cerveau » :
- Une meilleure capacité de raisonner
- Un contexte plus large
- Processus de réflexion plus long
- Appels d'outils plus complexes
Mais un agent qui fonctionne vraiment doit prendre beaucoup de décisions très triviales.
Par exemple :
Voulez-vous appeler la recherche ?
Quel outil régler ?
La tâche actuelle a-t - elle été terminée ?
Ce résultat est-il crédible ?
Voulez-vous continuer le cycle ?
À quel workflow appartient cette demande utilisateur ?
Aucune de ces questions ne semble complexe.
Mais un agent peut le faire des dizaines ou même des centaines de fois par minute.
Si un LLM de poids lourd est appelé à chaque fois, les retards et les coûts s'accumulent rapidement.
À ce moment-là, un modèle comme Jev a sa place :
Le grand modèle est responsable du raisonnement complexe et le petit modèle est responsable de la décision à haute fréquence.
Cela pourrait être plus conforme à une architecture logicielle réelle que l'idée de « résoudre tous les problèmes avec un modèle ».
Comment les développeurs ont-ils commencé à l'utiliser ?
À l'heure actuelle, il y a eu quelques tentatives très représentatives dans la communauté.
1. Agent du navigateur : laissez l'IA se spécialiser dans "cliquer où"
L'automatisation du navigateur est un scénario typique.
Une fois qu 'un agent ouvre une page Web, il doit souvent faire face à des dizaines ou même des centaines d'éléments DOM.
Le vrai problème est en fait :
« Quel élément devrais-je choisir pour la tâche actuelle ? »
C'est naturellement un choix.
La communauté d'utilisation du navigateur a créé un Jev ultra-fast Jev est utilisé dans le processus de prise de décision de l'agent du navigateur.
Browser-use/jev-ultrafast Projet GitHub
L'idée n'est pas de laisser Jev gérer l'ensemble de l'agent du navigateur, mais de le laisser assumer une couche très spécifique :
Sélectionnez rapidement la prochaine étape.
La génération de texte complexe peut toujours être confiée au modèle traditionnel.
Ce type de structure est en fait très représentatif :
Un agent n'a pas nécessairement besoin d'un modèle pour être responsable du début à la fin.
2. Jeu Agent : décision à haute fréquence
Le jeu est un autre scénario qui convient parfaitement à ce modèle.
Supposons qu ' une IA joue à Doom, elle peut avoir besoin de juger à chaque instant :
- A gauche ou à droite ?
- Tu tires ou pas ?
- Tu veux changer d'arme ?
- Évité ou non ?
- Continuer à aller de l'avant ?
Ces actions ne nécessitent pas nécessairement une longue période de raisonnement.
C'est plus comme :
Entrez l'état actuel → sélectionnez l'action suivante.
Si les modèles sont capables de prendre de telles décisions à plusieurs reprises avec un délai très faible, de nouvelles possibilités apparaissent pour les scénarios en temps réel qui sont difficiles à couvrir par les LLM traditionnels.
3. Routage des agents : Décider « à qui appeler ensuite »
Cette capacité est particulièrement directe dans les systèmes multi-agents.
Supposons que le système dispose :
搜索 Agent
代码 Agent
数据库 Agent
客服 Agent
人工审核
Après l'entrée de l'utilisateur, le système doit juger :
À qui faut-il remettre cette demande ?
C'est un problème de classification.
Plus loin :
L'agent actuel devrait-il appeler l'outil de recherche ou l'outil de base de données ?
Encore une question à choix.
Si le grand modèle de langage est utilisé pour chaque routage, une grande partie du temps de l'agent pourrait être dépensée à "décider de ce qu 'il fera ensuite".
Et un modèle à grande vitesse spécialisé dans le routage peut séparer cette couche.
Cela signifie en fait que les futurs systèmes d'IA peuvent être de plus en plus « stratifiés ».
Dans le passé, on aimait discuter :
Quel modèle est le plus fort ? »
Mais pour les systèmes de production réels, le problème peut devenir lentement :
« Quel modèle est responsable de quel travail ? »
Un système d'IA typique pourrait ressembler à ceci :
用户请求
↓
高速决策模型
↓
┌────────┬────────┬────────┐
↓ ↓ ↓ ↓
搜索工具 数据库 Agent 人工审核
↓
复杂任务
↓
大型推理模型
↓
最终结果
Dans cette architecture :
Les grands modèles ne font plus tout.
Il est responsable de la partie qui nécessite réellement le raisonnement, la création et la génération.
tandis que le modèle à grande vitesse est responsable d'un grand nombre de flux de contrôle finement fragmentés.
Du point de vue de l'ingénierie logicielle, c'est en fait très naturel.
Parce que les programmes informatiques ne sont pas basés sur le langage naturel.
Une grande partie de la logique métier peut finalement être résumée en :
if
else
switch
route
score
filter
Ce que Jev a fait, c'est essentiellement essayer de mettre une partie de cela if / switch Devenir plus "intelligent".
10, mais il n'est pas tout à fait omnipotent
Un rappel particulier est nécessaire ici :
La valeur de Jev vient précisément de sa spécialité, qui implique aussi des limites.
Ce n'est pas un remplacement pour ChatGPT ou Claude.
Si la tâche nécessite :
- Longue écriture
- Génération de code complexe
- Dialogues multiples
- Questions et réponses ouvertes sur la connaissance
- Raison de longue chaîne
- Calculs mathématiques précis
Ce modèle spécifiquement orienté vers la décision n'est pas adapté à tout le travail.
En outre, les tâches telles que la couverture linguistique, le raisonnement complexe, les mathématiques et les arithmétiques, les relations de date et d'autres devraient également être vérifiées par leurs propres ensembles de tests, plutôt que de juger uniquement par le matériel de propagande du modèle.
Il y a aussi un problème qui est facilement ignoré :
Le modèle peut faire des erreurs.
Même si le modèle donne un degré de confiance élevé, cela ne peut pas signifier :
« La procédure peut être exécutée inconditionnellement. »
et concerne notamment :
- Retour
- paiement
- Supprimer les données
- Autorisation de modification
- Base de données Operations
Ces actions à haut risque devraient toujours conserver le contrôle traditionnel des droits logiciels, la vérification des règles et le couvercle manuel.
L'AI peut être responsable du jugement.
Mais la frontière de sécurité finale devrait toujours être entre les mains du programme.
Qu ' est-ce qui est vraiment intéressant à Jev ?
Si seulement Jev est compris comme :
« Un modèle de classification plus rapide ».
En fait, il est facile de le sous-estimer.
Ce qui est vraiment intéressant, c'est qu ' il pose une question très simple :
Avons-nous vraiment besoin d'avoir un modèle qui écrira de longs articles et participe à chaque jugement de programme ?
Souvent, la réponse peut être non.
Dans un système d'agent d'IA mature, les tâches d'inférence les plus complexes ne sont pas nécessairement celles qui consomment vraiment beaucoup de coûts.
Il peut s'agir d'une multitude de petites décisions :
要不要搜索？
选哪个工具？
是不是垃圾信息？
属于哪个类别？
要不要继续？
需要不需要人工？
Chaque question est très simple, regardée séparément.
Mais multipliez-les par des millions d'appels et le coût et la latence deviennent un véritable problème d'ingénierie.
C'est aussi ce qui mérite le plus d'attention sur les modèles de ce genre Jev :
Plutôt que d'essayer d'être un plus grand « cerveau », il essaie d'être une borne nerveuse dans un système d'IA.
écrit à la fin
Au cours des deux dernières années, l'industrie de l'IA a poursuivi des modèles de plus en plus grands.
Plus grand nombre de paramètres, plus de contextes, plus de raisonnement complexe, plus de capacités de code.
Mais lorsque l'IA entre vraiment dans le système logiciel, nous pouvons trouver :
Beaucoup d'interactions entre ordinateurs n'ont pas besoin de langage naturel.
Le programme n'a pas besoin de modèles pour écrire un article.
Il peut seulement être nécessaire :
true
ou :
refund
ou :
tool_7
Ou encore :
confidence = 0.91
C'est aussi ce qui est le plus intéressant dans la direction que Jev représente.
Ce n'est pas un remplacement pour ChatGPT, ni pour écrire des articles avec Claude qui est mieux.
Ce qu ' elle essaie de faire, c'est autre chose :
Transformer l'IA de « personne qui parle » en « composant du programme qui prend des décisions ».
Si cette façon de penser continue de se développer, les futures applications d'IA pourraient ne plus être « un paquet de supermodèles pour battre le monde ».
Et plus probablement,
L'un est responsable de la pensée, l'autre est responsable de la génération, l'autre est responsable du jugement, l'autre est responsable du routage et l'autre est responsable de la révision.
Le grand modèle est responsable des problèmes complexes.
Le petit modèle est responsable de la décision à haute fréquence.
Le code hérité est responsable des contraintes finales.
Les trois sont combinés pour former un système logiciel d'IA qui peut vraiment fonctionner à long terme.
Donc, s'il faut se souvenir de Jev en une phrase :
ChatGPT est pour donner des réponses aux gens, et Jev est pour choisir le programme.
Et c'est peut - être la vraie raison pour laquelle il a soudainement attiré l'attention des développeurs récemment.