Jev est un modèle qui excelle dans la prise de décisions typées. C’est lorsque vous lui envoyez du contexte ainsi qu’un ensemble fixe de questions et d’options, et qu’il renvoie des choix, des scores et des probabilités au lieu de générer du texte. C’est ce que nous appelons un modèle « System One ».
Mais la classification n’est pas nouvelle, et les sorties structurées, les petits modèles, ou la lecture de probabilités à partir de logits non plus. Cet historique explique une partie des réactions mitigées à Jev :
Les sceptiques ont un vrai argument, mais Jev a une vraie place dans cet écosystème. Pour mieux comprendre, nous devrions décrire l’ensemble de l’espace des solutions.
Quelles sont les alternatives ?
Lorsqu’un système a besoin d’un libellé, d’un score ou d’une réponse oui/non, il existe quatre options raisonnables :
| Approche | Pourquoi l’utiliser | Compromis |
|---|---|---|
| Un LLM généraliste | Zero-shot, flexible, et peut aussi générer des arguments ou des explications. Sans doute une « intelligence supérieure » via du calcul au moment de l’inférence (raisonnement). | Payer la latence et le coût d’un modèle autorégressif pour une petite décision |
| Un classificateur open source zero-shot | Peu coûteux, local et contrôlable | Qualité variable vous gérez le choix du modèle et son service |
| Un classificateur fine-tuné | Souvent la meilleure option pour une tâche stable, à fort volume, avec de bons labels | Collecte de données, entraînement, déploiement, dérive, et une taxonomie moins flexible |
| Jev | Flexibilité zero-shot derrière une API hébergée et épurée | Qualité dépendante de la tâche, pas de texte généré, et dépendance au fournisseur |
Le cas Jev : une équipe peut modifier la question et les options sans constituer un nouveau jeu d’entraînement, tout en évitant le travail consistant à bien opérer un modèle en production. Personne ne devrait snober ça. « On pourrait le construire nous-mêmes » est vrai pour la plupart des produits d’infrastructure.
Les reproductions open source maintiennent la revendication de nouveauté sous contrôle. Des implémentations utilisant Qwen et SGLang, DiffusionGemma et vLLM, et Kev recréent une grande partie de l’API ou de la forme du modèle.
Les tests externes de Parallel ont également jugé Jev compétitif sur le reranking, tandis que des modèles spécialisés remportaient encore deux tâches de classification.
Ce que nous avons observé chez Glean
Reste une question pratique : quand la combinaison de flexibilité zero-shot et d’inférence hébergée de Jev dépasse-t-elle réellement les alternatives ? Nous avons testé chez Glean quatre décisions bornées, pour lesquelles nous disposions déjà d’une base de référence et pouvions évaluer une qualité de niveau entreprise. La plupart de ces baselines sont des systèmes basés sur des LLM pour ces expériences, nous savons donc qu’il faut s’attendre à un gain de deux ordres de grandeur en coût et en latence. Les résultats allaient de sensiblement moins bons que la production à à la fois plus rapides et plus précis qu’un routeur basé sur LLM.
Classification de requêtes
La classification de requêtes associe une demande à une tâche générale utilisée par les systèmes en aval. C’est une charge de travail naturellement adaptée à Jev, car si, pour chaque requête, l’espace des labels est connu à l’avance, la taxonomie peut malgré tout évoluer plus vite qu’un classificateur fine-tuné ne peut être réentraîné.
Pour cette expérience, nous nous concentrons sur l’évaluation de l’accord de Jev avec nos prédictions production/baseline, qui sont basées sur des LLM. Nous nous attendons à, et observons, un gain important de débit en offline avec Jev nous rapportons donc l’accord comme un proxy simple de la qualité. Nous avons également établi une baseline avec Laya, un modèle de décision open-weight, ainsi qu’avec une version fine-tunée de Laya. Ce fine-tuning a tourné localement en quelques heures, et le modèle est aussi suffisamment petit pour être servi sur une machine de développeur.
| Expérience | Accord sur la tâche générale | Perf |
|---|---|---|
| Jev zero-shot | 66.8% | ~12min (concurrence de 4) |
| Base Laya | 35.9% | ~90s (machine de dev locale) |
| Laya fine-tuné | 74.5% | ~90s (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, mais, sans grande surprise, le fine-tuning fait briller Laya, surtout au vu des chiffres de performance. Le compromis réside dans l’effort nécessaire pour obtenir de bons labels et mettre en place l’entraînement. Jev reste probablement plus attractif lorsqu’une tâche est nouvelle ou que ses labels évoluent.
Routage de modèles : transfert vers un expert
Le routage de modèles est un problème connexe à la classification de requêtes. Ici, nous abordons le routage de modèles comme un transfert vers un expert, où notre système choisit quel expert/modèle doit traiter la demande. Notre baseline de production demande actuellement à un LLM de prendre cette décision de manière native à l’intérieur de la boucle agentique du harness. Bien que ce soit un test naturel pour déterminer si Jev peut remplacer un appel génératif par une décision bornée, une limitation technique importante est que Jev ajoutera systématiquement un appel en cas de non-transfert. Cela contraste avec la baseline de production qui, dans les cas de non-transfert, peut commencer le travail d’appel d’outils via ce même premier et unique appel au LLM.
Nous avons utilisé une version simplifiée de notre routage de production avec seulement 3 experts, rejoué 751 entrées « golden » comparables via le routeur Jev mis à jour, comparé la route choisie avec celle de notre routeur existant basé sur des prompts (propulsé par un LLM traditionnel), et mesuré la précision par rapport au label « golden ».
| Route | Entrées « gold » | Précision de la baseline | Rappel de la baseline | Précision de Jev | Rappel de Jev |
|---|---|---|---|---|---|
| Expert 1 | 34 | 70.2% | 97.1% | 86.8% | 97.1% |
| Expert 2 | 42 | 47.1% | 38.1% | 86.7% | 61.9% |
| Expert 3 | 6 | 12.5% | 33.3% | 85.7% | 100% |
| Aucun expert | 669 | 95.6% | 93.4% | 97.6% | 98.7% |
Nous avons également isolé 40 entrées où le chemin existant effectuait un véritable appel de transfert vers un expert (n plus petit) et comparé la latence d’appel sur ces mêmes entrées.
L’accélération médiane par entrée était de 8,1×. C’est l’un des résultats internes Jev les plus marquants à ce jour : sur cette tâche de routage bornée, Jev était à la fois plus précis et nettement plus rapide. L’ampleur de l’écart suggère que la « taxe » de “blocking” que nous supportons sur les requêtes non routées vers des experts peut constituer un bon compromis. Notez qu’il s’agit toujours d’une comparaison hors ligne sur un golden set, et que l’échantillon de latence ne contient que 40 transferts positifs il reste donc beaucoup à sécuriser et à tester !
Reranking
Un sujet qui tient particulièrement à cœur à Glean ! Ci-dessous, notre baseline en production correspond à l’ordre produit par la stack de recherche existante de Glean. Cette expérience a ensuite demandé à Jev de réordonner jusqu’à 50 résultats.
Nous avons testé quatre façons d’exprimer la pertinence via les sorties typées de Jev :
| Formulation | Comment elle exprime la pertinence |
|---|---|
| Pointwise Noul | Poser une question de pertinence oui/non distincte pour chaque résultat, puis trier selon la probabilité de « oui ». |
| Shared-state Noul | 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. |
| Choice | Traiter tous les candidats comme des alternatives dans une seule décision, puis les classer selon les probabilités obtenues. |
Nous avons exécuté cela sur un evalset interne où l’utilisateur n’a pas accès à tous les canonicals les chiffres absolus ne sont donc pas représentatifs de notre classement en production — mais les chiffres relatifs sont intéressants.
Le “Choice” de Jev était la formulation la plus performante. Sur un contrôle apparié de 4 855 requêtes de recherche capturées, avec la résolution des ex æquo basée sur la production retirée, le résultat était :
| Ranker | Recall@1 | Recall@3 | Recall@6 | Evaluator MAP |
|---|---|---|---|---|
| Ordre de production Glean existant | 35.74% | 45.79% | 51.18% | 0.4289 |
| GPT-6-Luna-high comme reranker | 30.71% | 39.15% | 45.08% | 0.3766 |
| GPT-6-Sol-high comme reranker | 31.54% | 40.14% | 46.84% | 0.3862 |
| Jev Choice | 24.37% | 33.72% | 40.21% | 0.3201 |
Jev Choice coûtait environ 0,00044 $ par requête et prenait 0,195 seconde au p50 dans le test hors ligne. Mais il attribuait des scores identiques à environ 37 des 41 candidats dans une requête moyenne. Le fait d’utiliser l’ordre de production pour départager ces ex æquo a fait passer le Recall@6 de 40,2 % à 44,3 %, ce qui rend le résultat non corrigé plus flatteur que ce que justifient les seuls scores de Jev. Il y a comme d’habitude de nombreuses réserves, mais dans l’ensemble, Jev est une base de référence peu coûteuse et efficace, pas un remplacement du ranker de production de Glean.
Évaluation du support par citations
L’évaluation par citations pose deux questions liées : les affirmations qui nécessitent des preuves ont-elles des 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, parce que l’espace sortie/étiquette est borné (comme pour la plupart des configurations d’évaluation), cela semble parfaitement adapté à Jev. La grille d’évaluation est toutefois complexe et peut nécessiter de décomposer plusieurs affirmations – en outre, Jev ne produit pas la justification que nous utilisons souvent pour l’analyse d’erreurs, ce qui comporte un certain risque à la fois pour la qualité et l’utilisabilité.
Nous avons testé Jev sur une réponse d’évaluation de production réelle de 1 448 mots, en conservant la réponse et les éléments de preuve des citations fixes. Nous avons comparé son passage partagé précision-et-rappel avec GPT-5.6 Luna en mode sans raisonnement et en raisonnement xhigh. Pour 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 timing est indicatif plutôt que de bout en bout : Jev rapporte un temps mural côté client séquentiel, tandis que les lignes Luna additionnent les durées des appels au modèle. Les coûts incluent le caching observé.
Nous avons également comparé la cohérence sur les mêmes 28 paragraphes. Un élément modifié signifie que le juge a changé son verdict quant au fait qu’un paragraphe disposait d’une couverture de citation adéquate dans au moins l’une des trois exécutions à entrées identiques. Le désaccord pair à pair 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 pair à pair sur le rappel |
|---|---|---|
| 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 de Jev portait sur la question de savoir si un paragraphe devait être considéré comme nécessitant une citation sa catégorie de rappel brute n’a pas changé. Les verdicts de Jev sur la couverture de citation au niveau du paragraphe étaient donc plus reproductibles que ceux de l’une ou l’autre configuration Luna.
Nous ne concluons pas que cela fasse de Jev le juge le plus précis (les systèmes appliquaient des critères de support et des dénominateurs de score différents, et nous n’avons pas eu le temps de produire des labels humains indépendants). Mais même avec le raisonnement xhigh (qui a approximativement triplé le temps modèle de Luna), il est resté moins cohérent que Jev. Le résultat étaye Jev comme une façon rapide, peu coûteuse et relativement reproductible de mettre en œuvre une politique de citation étroite.
Enseignements de l’expérience et guide pratique
Dans certains cas, Jev se démarque comme une alternative à faible friction, à la fois aux LLM traditionnels et aux classifieurs fine-tunés. Lorsque la base est solide (reranking) ou qu’il est facile de fine-tuner un modèle plus petit (classification de requêtes), le gain est moindre. Certains signes indiquent une meilleure qualité pour certaines tâches (routage de modèles), ainsi que des indications d’une meilleure cohérence et stabilité (évaluateur de citations). Sur certaines de nos charges de travail les plus importantes, Jev offre les gains attendus en coût et en latence par rapport aux LLM traditionnels.
Les résultats ci-dessus donnent de bons indices directionnels, et chez Glean, nous sommes très enthousiastes à propos de Jev. Après quelques étapes supplémentaires (principalement, la préparation opérationnelle comme la résidence des données et des garanties), nous prévoyons de déployer Jev dans certains de ces cas d’usage. Par ailleurs, Jev jouera un rôle important dans notre hackathon interne cette semaine et nous avons hâte de partager davantage de résultats !
Quelques conseils généraux pour conclure : si la sortie peut être listée à l’avance, benchmarkez Jev. Si la tâche et les labels sont stables et que le volume est élevé, benchmarkez aussi un classifieur fine-tuné. Si l’appel doit générer une requête, une explication ou un autre texte dynamique, gardez 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 Glean ont toujours besoin d’arguments générés dynamiquement (comme des requêtes de recherche).
Jev ne change pas le fait que les classifieurs existaient déjà. Il rend un bon classifieur zero-shot beaucoup plus facile à utiliser. C’est un produit solide, même si ce n’est pas une nouvelle fondation pour chaque système d’IA.
Auteurs : Eddie Zhou, Chau Tran, Aviral Singh, Matt Zhao, Manav Agrawal.
