NUS publie Jeva-4B : intégrer le « aucun choix approprié » et le cache dans l'architecture de décision
Selon un reportage de Xinzhiyuan (新智元), le xML Lab de l'Université nationale de Singapour propose Jeva, qui s'appuie sur le backbone Qwen3.5-4B et un bloc de décision pour produire directement un choix, null ou un score ; l'article rapporte un taux d'inversion d'ordre nul, une exactitude de 69,88 % avec 2048 candidats, et des poids publiés sur Hugging Face.
Ce qui change
Selon un reportage de Xinzhiyuan (新智元) daté du 26 octobre 2026 (la date correspondant à l'horodatage original 1792987620000), le xML Lab de l'Université nationale de Singapour a publié un article et du code présentant l'architecture Jeva destinée aux tâches de décision, ainsi que le modèle Jeva-4B. D'après le reportage, ce modèle utilise Qwen3.5-4B comme backbone, auquel s'ajoute un bloc de décision léger : un encodeur partagé représente séparément la requête et les options candidates, le bloc de décision lit l'ensemble des candidats et ne met à jour que l'état de la requête, ce qui permet de mettre en cache et réutiliser les représentations des options, tandis que le jugement courant est recalculé à chaque fois. Le reportage mentionne quatre objectifs de conception : distinguer « lequel des candidats est meilleur » de « l'ensemble contient-il une réponse acceptable », ce dernier étant estimé séparément par une probabilité de couverture et autorisant une sortie null ; agréger de façon symétrique sur l'ensemble des candidats, afin que les probabilités suivent l'identité des candidats plutôt que leur position dans la liste ; appliquer la même règle de score à chaque candidat, ce qui permet de traiter directement l'ensemble complet des candidats plutôt qu'une élimination en plusieurs tours ; mettre en cache les représentations sémantiques des options et leurs projections de couches, réutilisées lors de la recomposition des ensembles de candidats. Le même calcul prend en charge trois types de sortie : Choice, Noul (probabilité qu'une proposition soit vraie) et Score. Les résultats expérimentaux cités proviennent tous de l'article : sur 3 080 requêtes construites à partir de BANKING77 (16 candidats par requête, dont 588 sans réponse), l'AUROC de détection de null atteint 98,66 %, contre 93,61 % pour KEV-BF16, 84,27 % pour InternDecision-4B et 79,44 % pour JevK5 ; sur 600 échantillons Choice testés dans l'ordre original, l'ordre inverse et jusqu'à trois permutations aléatoires, l'exactitude de Jeva dans l'ordre original et celle sur « toutes les séquences testées correctes » sont toutes deux de 76,67 %, sans inversion de décision observée, tandis que les taux d'inversion des comparateurs sont de 17,00 %, 22,67 % et 26,17 % ; dans les configurations ToolRet de 32 à 2 048 candidats, l'exactitude avec 2 048 candidats est de 69,88 % et la latence médiane par requête sur un seul H200 de 12,04 secondes, contre 67,47 % et environ 28,35 secondes pour JevK5 ; avec 83 questions fixes et un nombre de candidats passant de 32 à 2 048, Jeva répond correctement à 58 de ces questions à toutes les échelles, contre 48 pour JevK5 et 7 pour CLM ; dans l'expérience sur documents longs MLDR, la latence médiane par requête passe d'environ 2,10 secondes à 75,1 millisecondes lorsque tous les candidats sont en cache, et le reportage indique qu'aucun changement de décision n'a été observé selon les conditions de cache. Ces chiffres sont tous auto-déclarés dans l'article et n'ont pas été reproduits indépendamment ici.
Conséquences pour les développeurs
Pour les développeurs, Jeva n'est pas un énième modèle de chat généraliste, mais une forme qui couple « tri + refus de répondre + cache » dans le chemin d'inférence, ce qui modifie la conception d'intégration de plusieurs types de systèmes. Premièrement, le contrat de sortie change : l'ensemble des candidats devient l'entrée d'une requête, et le modèle renvoie une distribution ou un score avec null, et non un texte à reparsing. Pour raccorder une chaîne de prompts existante qui « demande au modèle de sortir un JSON en choisissant une option » à ce type de modèle, il faut définir au niveau du service les ID de candidats, le seuil de probabilité de couverture et le comportement de repli en cas de null, et journaliser l'ensemble complet des candidats de la requête, faute de quoi il sera impossible de déterminer après coup si un refus vient de candidats inadaptés ou d'une erreur du modèle. Deuxièmement, le cache descend du niveau du prompt vers celui de l'architecture : selon le reportage, ce qui est mis en cache est la représentation des options, non la réponse, ce qui est directement pertinent pour des cas où « les candidats sont relativement stables et les questions changent constamment », comme des clauses de politique, une base de documents longs ou des critères de notation fixes ; mais cela implique que la clé de cache soit liée à la version du modèle, au type de décision et aux réglages d'encodage, et que tout changement de modèle ou de configuration d'encodage invalide les anciens caches. Troisièmement, la taille des candidats n'a plus besoin d'être contrôlée par élimination en plusieurs tours : le reportage indique que 2 048 candidats sont encore comparés dans la même tête de décision, ce qui simplifie le processus de réordonnancement après retrieval, mais lie directement la latence au nombre et à la longueur des candidats ; la latence médiane de 12,04 secondes montre que les grands ensembles de candidats restent des tâches hors ligne ou asynchrones, et non des appels interactifs. Il faut préciser que les noms des modèles comparés dans le reportage (comme Jev-1.13.0, JevK5, CLM) et les informations sur les configurations de référence sont limités, et que les lecteurs ne doivent pas extrapoler ces chiffres comparatifs à leur propre distribution de données ou à des ensembles de candidats métier en chinois.
Intégration et évaluation
Ce qui suit relève de recommandations et d'analyses conditionnelles, non de faits rapportés. Décision 1 : remplacer ou non la « sélection générative » existante par une interface à tête de décision dépend de si vos candidats sont énumérables et si le refus doit être explicite. Si le métier comporte réellement des cas où « aucun candidat de l'ensemble ne convient » (par exemple l'affectation de tickets ou le routage d'intention), la conception null-aware décrite mérite une validation distincte : construire un lot de requêtes « sans candidat approprié » issues de votre distribution réelle, les mélanger à des requêtes avec réponse, balayer les seuils et enregistrer l'AUROC et le rappel à taux de faux refus fixé (par exemple 5 %), et n'accepter la refonte de l'interface que si cet indicateur est nettement meilleur que la solution actuelle à base de prompts. Si vos candidats ont toujours une bonne réponse, le gain de cette capacité est limité et la priorité de refonte doit être abaissée. Décision 2 : adopter ou non le cache d'options dépend du mode de réutilisation de la bibliothèque de candidats. Commencez par analyser un lot de requêtes en production et calculer le taux de chevauchement entre ensembles de candidats (l'exemple du reportage est le chevauchement progressif du type ABC, BCD, ACD) ; si le chevauchement est élevé et les textes des candidats longs, mesurez selon l'approche rapportée l'écart de latence entre cache entièrement touché et cache entièrement manqué ; il faut aussi vérifier que la décision d'une même requête est identique avant et après un hit de cache, car le reportage indique seulement qu'aucun changement de décision n'a été observé dans ses expériences, ce qui ne garantit pas l'équivalence sur vos données. Si les candidats sont presque toujours nouveaux, la complexité du cache peut dépasser le gain. Décision 3 : la limite de taille des candidats doit être fixée selon le budget de latence, et non selon l'exactitude seule. Le reportage donne 69,88 % d'exactitude et 12,04 secondes de latence médiane avec 2 048 candidats, deux chiffres à lire ensemble : si votre scénario exige une réponse en quelques secondes, il faut mesurer la courbe d'exactitude sur des ensembles plus petits, identifier le point d'inflexion où l'exactitude commence à baisser, puis décider d'élargir les candidats ou de conserver le filtrage de rappel existant. Pour l'évaluation, fixez les questions et augmentez progressivement les candidats (la méthode du reportage avec 83 questions passant de 32 à 2 048 est directement réutilisable), et calculez la proportion de réponses correctes « à toutes les échelles », ce qui révèle mieux la stabilité qu'une exactitude ponctuelle. Décision 4 : la robustesse à l'ordre doit être un test de régression fixe avant mise en production. Selon la méthode rapportée, testez sur un même lot l'ordre original, l'ordre inverse et plusieurs permutations aléatoires, alignez les résultats sur l'identité des candidats plutôt que sur leur position, et enregistrez le taux d'inversion. Pour les scénarios liés à la conformité, au contrôle des risques ou à la notation, le taux d'inversion est un indicateur à surveiller davantage que l'exactitude moyenne.
Limites et points à confirmer
Tous les chiffres expérimentaux de cet article proviennent de résultats d'article relayés par Xinzhiyuan (新智元), sans reproduction indépendante ; la configuration et les détails d'entraînement des modèles comparés sont incomplets dans le reportage, et les comparaisons entre modèles doivent être prudentes. Le reportage ne précise pas les termes de licence exacts des poids de Jeva-4B sur Hugging Face ; la possibilité de télécharger les poids ne signifie pas qu'ils sont utilisables commercialement ou redistribuables, et il faut vérifier soi-même la carte du modèle et le texte de la licence avant tout déploiement. Le reportage ne donne pas non plus d'informations sur un service API, une tarification ou une disponibilité hébergée ; s'il existe un mode d'appel, il faut s'en remettre aux indications de l'éditeur. En outre, les expériences rapportées portent sur des tâches anglaises comme BANKING77, ToolRet et MLDR, et les performances sur des ensembles de candidats en chinois, des terminologies métier et des documents longs restent inconnues. Il faut souligner en particulier que la version Jeva-4B n'est pas actuellement dans le catalogue de modèles KimiSeek, qu'aucune entrée du catalogue KimiSeek ne correspond exactement à cette version, et que toute affirmation sur sa disponibilité via API ne concerne que l'éditeur et non ce site ; pour réaliser des tâches de décision similaires sur KimiSeek, il faut évaluer séparément les modèles déjà listés sur le site et se référer à la page de tarification.