Auteurs : @eddiedzhou, @mr_cheu, @MatZhao, @CosmicPegasis19, @manav_ai
Jev est un modèle conçu pour prendre des décisions typées. Vous lui envoyez un contexte accompagné d'un ensemble fixe de questions et d'options, puis il renvoie des choix, des scores et des probabilités au lieu de générer du texte. C'est un modèle « Système 1 » !
Mais la classification n'a rien de nouveau, pas plus que les sorties structurées, les petits modèles ou la lecture de probabilités à partir des logits. Ce passé explique en partie l'accueil mitigé réservé à Jev...
Les sceptiques ont de vrais arguments, mais Jev a bel et bien sa place dans cet écosystème. Pour mieux comprendre, il faut d'abord cartographier tout l'espace des solutions possibles.
Quelles sont les alternatives ?
Lorsqu'un système a besoin d'une étiquette, d'un score ou d'une réponse par oui ou non, quatre options s'offrent à vous :
Approche
Pourquoi l'utiliser
Compromis
Un LLM généraliste
Zéro-shot, flexible, capable de générer des arguments ou des explications. On peut y voir une « intelligence supérieure » grâce au calcul au moment de l'inférence (raisonnement).
Payer la latence et le coût d'un modèle autorégressif pour une simple décision
Un classifieur zéro-shot open source
Économique, local et contrôlable
Qualité variable ; vous gérez vous-même le choix du modèle et son déploiement
Un classifieur fine-tuné
Généralement le meilleur choix pour une tâche stable, à fort volume et disposant de bonnes étiquettes
Collecte de données, entraînement, déploiement, dérive du modèle et taxonomie moins flexible
Jev
La flexibilité du zéro-shot derrière une API hébergée et propre
Qualité dépendante de la tâche, aucun texte généré et dépendance au fournisseur
L'argument en faveur de Jev : une équipe peut modifier la question et les options sans avoir à constituer un nouveau jeu d'entraînement, tout en s'épargnant la charge de déployer correctement un modèle. Personne ne devrait faire la fine bouche face à un tel avantage. Dire « on pourrait le développer nous-mêmes » s'applique à la plupart des produits d'infrastructure.
Les reproductions open source relativisent la prétendue nouveauté du projet. Des implémentations basées sur Qwen et SGLang, DiffusionGemma et vLLM, ainsi que Kev recréent une grande partie de l'API ou de l'architecture du modèle.
85,7 % pour Jev et 79,6 % pour Kev-8B sur n=764
Les tests externes menés par Parallel ont également montré que Jev tenait la route sur le reranking, même si des modèles spécialisés l'ont emporté sur deux tâches de classification.
Ce que nous avons observé chez Glean
Reste une question pratique : dans quels cas précis la combinaison de flexibilité zéro-shot et d'inférence hébergée proposée par Jev surpasse-t-elle réellement les autres approches ? Chez Glean, nous avons testé quatre décisions bornées pour lesquelles nous disposions déjà d'une base de référence, ce qui nous a permis de comparer la qualité réelle en environnement entreprise. La plupart de ces références reposent sur des systèmes basés sur des LLM : pour ces expériences, nous savions donc pouvoir espérer un gain de deux ordres de grandeur en matière de coût et de latence. Les résultats se sont étalés d'une performance nettement inférieure à celle de la production jusqu'à une vitesse et une précision supérieures à celles d'un routeur basé sur un LLM.
Classification des requêtes
La classification des requêtes consiste à associer une demande à une tâche globale exploitée par les systèmes en aval. C'est un cas d'usage idéal pour Jev : même si l'espace des étiquettes est connu à l'avance pour chaque requête, la taxonomie peut évoluer plus vite qu'un classifieur fine-tuné ne peut être réentraîné.
Pour cette expérience, nous nous sommes concentrés sur la mesure de l'accord entre Jev et les prédictions de notre système de production / de référence, qui repose sur un LLM. Nous anticipions — et avons effectivement constaté — une forte accélération du débit hors ligne avec Jev ; nous utilisons donc le taux d'accord comme indicateur simple de la qualité. Nous avons également comparé les résultats à Laya, un modèle de décision à poids ouverts, ainsi qu'à une version fine-tunée de Laya. Ce fine-tuning a pu être exécuté localement en quelques heures, et le modèle est suffisamment léger pour tourner sur la machine d'un développeur.
Expérience
Accord sur la tâche globale
Perf
Jev zéro-shot
66,8 %
~
12 min (concurrence de 4
)
Laya de base
35,9 %
~
90 s (machine de dev locale)
Laya fine-tuné
74,5 %
~
90 s (machine de dev locale)
En tant que modèle prêt à l'emploi, pratique et ne nécessitant aucun entraînement, Jev surpasse clairement Laya. Sans surprise, le fine-tuning permet toutefois à Laya de briller, surtout au vu des performances affichées. Le compromis réside dans l'effort nécessaire pour obtenir de bonnes étiquettes et configurer l'entraînement. Jev reste probablement plus intéressant lorsqu'une tâche est nouvelle ou que ses étiquettes évoluent constamment.
Routage de modèles : transfert d'expert
Le routage de modèles est un problème proche de la classification des requêtes. Ici, nous l'abordons sous l'angle du transfert d'expert : notre système choisit quel expert ou modèle doit traiter la demande. Notre base de référence en production demande actuellement à un LLM de prendre cette décision nativement, au sein de la boucle agentique de l'orchestrateur. S'il s'agit d'un test pertinent pour savoir si Jev peut remplacer un appel génératif par une décision bornée, une limite technique importante subsiste : en cas de non-transfert, Jev va strictement ajouter un appel. À l'inverse, la base de référence en production permet, dans les cas de non-transfert, de démarrer l'appel d'outil directement via ce même premier appel LLM unique.
Nous avons utilisé une version simplifiée de notre routage de production limitée à 3 experts, rejoué 751 entrées de référence comparables via le nouveau routeur Jev, puis comparé l'itinéraire choisi avec celui de notre routeur actuel basé sur des prompts (alimenté par un LLM traditionnel), en mesurant la précision par rapport à l'étiquette de référence.
Nous avons également isolé 40 entrées pour lesquelles le chemin existant effectuait un véritable appel de transfert d'expert (n plus faible) afin de comparer la latence d'appel sur ces mêmes entrées.
L'accélération médiane par entrée a été de 8,1×. Il s'agit de l'un des meilleurs résultats internes obtenus avec Jev jusqu'à présent : sur cette tâche de routage bornée, Jev s'est révélé à la fois plus précis et nettement plus rapide. L'ampleur de cet écart suggère que la pénalité de « blocage » subie sur les requêtes non routées vers un expert constitue un compromis acceptable. Attention toutefois : il s'agit toujours d'une comparaison hors ligne sur un jeu de référence, et l'échantillon de latence ne contient que 40 transferts positifs. Il reste donc beaucoup de risques à évaluer et de tests à mener !
Reranking
Un sujet cher à Glean ! Ci-dessous, notre base de référence en production correspond à l'ordre généré par la pile de recherche actuelle de Glean. L'expérience consistait ensuite à demander à Jev de réordonner jusqu'à 50 résultats.
Nous avons testé quatre manières d'exprimer la pertinence via les sorties typées de Jev :
Formulation
Comment elle exprime la pertinence
Noul point par point
Poser une question de pertinence distincte (oui/non) pour chaque résultat, puis trier selon la probabilité de « oui ».
Noul à état partagé
Montrer à Jev l'ensemble complet des candidats comme contexte partagé, puis poser la même question oui/non pour chaque résultat.
Score
Demander à Jev d'attribuer à chaque candidat un score numérique de pertinence.
Choix
Considérer tous les candidats comme des options au sein d'une seule décision, puis les classer selon leurs probabilités résultantes.
Nous avons mené ce test sur un jeu d'évaluation interne où l'utilisateur n'a pas accès à tous les documents canoniques. Les valeurs absolues ne reflètent donc pas notre classement en production, mais les écarts relatifs sont riches d'enseignements.
La formulation « Choix » de Jev s'est avérée la plus performante. Sur un contrôle apparié de 4 855 requêtes de recherche capturées, après suppression du départage basé sur la production, voici le résultat :
Jev Choice a coûté environ 0,00044 $ par requête et a nécessité 0,195 seconde au p50 lors du test hors ligne. Cependant, il a attribué des scores identiques à environ 37 des 41 candidats d'une requête moyenne. L'utilisation de l'ordre de production pour départager ces égalités a fait passer le Recall@6 de 40,2 % à 44,3 %, rendant le résultat non corrigé plus flatteur que ce que les seuls scores de Jev justifiaient. Comme souvent, de nombreuses réserves s'imposent, mais la tendance est claire : Jev constitue une base de référence économique et efficace, et non un remplacement pour le ranker de production de Glean.
Évaluation du support des citations
L'évaluation des citations soulève deux questions liées : les affirmations nécessitant des preuves disposent-elles de citations adéquates (rappel des citations), et les sources citées soutiennent-elles réellement les affirmations qui leur sont attribuées (précision des citations) ? À première vue, puisque l'espace de sortie / d'étiquettes est borné (comme dans la plupart des configurations de juge), cela semble taillé pour Jev. La grille d'évaluation est cependant complexe et peut exiger la décomposition de plusieurs affirmations. De plus, Jev ne produit pas le raisonnement que nous utilisons souvent pour analyser les erreurs, ce qui présente un risque tant pour la qualité que pour l'exploitabilité.
Nous avons testé Jev sur une véritable réponse d'évaluation de production de 1 448 mots, en maintenant fixes la réponse et les éléments de citation. Nous avons comparé sa passe conjointe de précision et de rappel avec GPT-5.6 Luna, sans raisonnement puis avec un raisonnement xhigh. Afin de réduire la variance, nous avons exécuté chaque juge trois fois.
Juge
Temps mesuré initial par réponse
Coût mesuré initial par réponse
Jev
6,6 s
$
0,014
GPT-5.6 Luna, sans raisonnement
81,3–85,5 s
$
0,030–
$
0,047
GPT-5.6 Luna,
xhigh
227,4–259,7 s
$
0,047–
$
0,060
Notez que le chronométrage est indicatif plutôt que de bout en bout : Jev rapporte le temps mural séquentiel côté client, tandis que les lignes Luna additionnent les durées d'appel au modèle. Les coûts incluent la mise en cache observée.
Nous avons également comparé la cohérence sur les mêmes 28 paragraphes. Un élément modifié signifie que le juge a changé de verdict quant à la couverture adéquate des citations d'un paragraphe lors d'au moins une des trois exécutions à entrée identique. Le désaccord par paire comptabilise chaque paragraphe sur les trois paires d'exécutions, soit 84 comparaisons par juge.
Juge
Paragraphes avec un verdict de rappel modifié
Désaccords de rappel par paire
Jev
1 sur 28 (3,6 %)
2 sur 84 (2,4 %)
GPT-5.6 Luna, sans raisonnement
7 sur 28 (25,0 %)
15 sur 84 (17,9 %)
GPT-5.6 Luna,
xhigh
5 sur 28 (17,9 %)
10 sur 84 (11,9 %)
Le seul changement opéré par Jev concernait la nécessité ou non de citer un paragraphe ; sa catégorie de rappel brute n'a pas varié. Les verdicts de couverture de citations au niveau du paragraphe rendus par Jev étaient donc plus reproductibles que ceux des deux configurations de Luna.
Nous n'en concluons pas pour autant que Jev est un juge plus précis (les systèmes appliquaient des critères de support et des dénominateurs de notation différents, et nous n'avions pas le temps de réaliser un étiquetage humain indépendant). Mais même avec un raisonnement xhigh (qui a pratiquement triplé le temps de modèle de Luna), ce dernier est resté moins cohérent que Jev. Ce résultat confirme que Jev offre un moyen rapide, peu coûteux et relativement reproductible d'appliquer une politique de citation stricte.
Bilan des expériences et guide pratique
Dans certains cas, Jev s'impose comme une alternative fluide aux LLM traditionnels et aux classifieurs fine-tunés. Lorsque la base de référence est déjà solide (reranking) ou qu'il est facile de fine-tuner un modèle plus petit (classification des requêtes), le bénéfice est moindre. On observe des signes d'une meilleure qualité sur certaines tâches (routage de modèles), ainsi que des indices d'une cohérence et d'une stabilité accrues (juge de citations). Sur plusieurs de nos charges de travail les plus critiques, il délivre les gains de coût et de latence attendus face aux LLM classiques.
Ces résultats fournissent d'excellentes pistes et, chez Glean, Jev suscite un réel enthousiasme. Après quelques étapes supplémentaires (principalement de préparation opérationnelle, comme la résidence des données et les garanties associées), nous prévoyons de déployer Jev sur certains de ces cas d'usage. Par ailleurs, Jev jouera un rôle majeur lors de notre hackathon interne cette semaine, et nous avons hâte de partager de nouveaux résultats !
Pour conclure, voici quelques conseils généraux : si la sortie peut être listée à l'avance, benchmarkez Jev. Si la tâche et les étiquettes sont stables et que le volume est élevé, benchmarkez également un classifieur fine-tuné. Si l'appel doit générer une requête, une explication ou tout autre texte dynamique, conservez un modèle génératif dans la boucle. L'appel d'outils en est un bon exemple : Jev peut aider à choisir un outil, mais la plupart des outils de Glean nécessitent encore des arguments générés dynamiquement (comme les requêtes de recherche).
Jev ne change rien au fait que les classifieurs existaient déjà. Il rend simplement un bon classifieur zéro-shot beaucoup plus facile à utiliser. C'est un excellent produit, même s'il ne constitue pas la nouvelle pierre angulaire de tous les systèmes d'IA.
