Avec le RLCD parallel sampling, JEV de Typesafe AI rend des décisions structurées en 75 ms pour un coût marginal quasi nul, et l'auteur l'a passé au crible sur plus de 40 cas réels : SEO, modération, cybersécurité, KYC. Un appel LLM classique, lui, demande 200 à 500 ms. Et plusieurs centimes. Le relevé de consommation donne 60M tokens pour 2, 35 $. JEV excelle sur le routing d'agents et la classification haute fréquence, à condition de lui fournir des données propres en amont.
L'auteur positionne JEV comme la colle entre scripts déterministes et LLM génératifs. Les pipelines classiques, eux, fonctionnent avec des règles fixes, des seuils codés en dur et des classifieurs ML entraînés sur des datasets labellisés. Les LLM frontier procèdent autrement : ils avalent du contexte non structuré et génèrent du texte token par token, avec une latence élevée et un coût qui suit la longueur de sortie. JEV extrait la décision, sans prose inutile.
Chiffre Typesafe AI annonce des latences de 75 millisecondes pour des décisions complexes. L'auteur rapporte avoir consommé 60 millions de tokens pour 2, 35 $, soit environ 0, 000039 $/requête en moyenne sur ses tests. Un appel GPT-4 coûte 0, 03 $/1k tokens output ; sur des tâches de classification haute fréquence, l'économie est brutale.
Outil Qwen peut théoriquement faire du parallel sampling, note l'auteur. Mais la latence mesurée atteint 1 seconde, soit 13 fois plus lent que JEV dans ses tests. Tout se joue sur l'implémentation bas niveau du RLCD parallel sampling, optimisée pour le routing.
Méthode Plus besoin d'un LLM généraliste pour déterminer quel outil appeler : JEV reçoit un state structuré et une liste de labels (ex: direct_answer, web_search, internal_db, code_execution, clarification). Il retourne instantanément le label avec un score de confiance.
L'auteur donne plusieurs exemples concrets :
Opinion Pour les architectures agent en cascade, ce routing ultra-rapide change la donne. Un appel LLM pour router coûte aujourd'hui 200-500 ms + tokens output, quand JEV passe sous 100 ms avec un coût marginal quasi nul. De quoi imaginer des agents qui explorent plusieurs chemins en parallèle avant de retenir le meilleur résultat selon le score de confiance.
Vécu L'auteur a testé JEV sur un scénario d'audit SEO par élimination. Il fournit un state décrivant l'état technique d'un site (crawlabilité OK, sitemap à jour, JS rendering OK, contenu unique, mais ranking faible), puis demande à JEV de trancher entre backlinks, crawlability et content.
Chiffre Réponse : backlinks, confiance 0.96, probabilité de 97 %. L'auteur en déduit qu'on peut automatiser la qualification de prospects pour des services de backlinks. Tous les signaux onsite au vert, un nombre de domaines référents faible, et le site devient un lead qualifié.
Outil Il prépare un produit appelé Niche Observer, qui exploitera cette logique pour repérer automatiquement les sites sous-optimisés côté netlinking. L'API SEObserver est également citée, pour injecter les données de backlinks dans le state de JEV.
Cas inverse : domaine de 14 ans, 2 300 domaines référents de qualité, mais page bloquée en noindex depuis une migration. Le classement est correct. JEV répond crawlability avec une confiance de 0.99, le contexte technique primant sur le profil de liens.
Méthode JEV reçoit le contenu d'un message support et doit déterminer le niveau d'urgence (none, low, high, critical) ainsi que la queue de traitement (sales, on-call, priority, standard). L'auteur teste 6 messages types :
Opinion Voilà l'un des cas d'usage les plus solides du transcript. Trier les tickets occupe un temps considérable dans les équipes support. Placer un router JEV en amont, branché sur des webhooks Slack ou PagerDuty, permet d'escalader les incidents automatiquement, sans attendre qu'un humain ouvre la queue.
L'auteur teste JEV sur des messages ambigus, ceux où le lexique seul ne suffit pas. Il demande 2 outputs : action (leave, escalate, hide, ban) et toxicity score (0 = none, 1 = extreme).
Exemples testés :
À vérifier Selon l'auteur, JEV a raté le doxx en première passe avant de le capter une fois la question reformulée. La qualité de la décision dépendrait donc fortement de la structure du prompt. Une mise en production supposerait de tester systématiquement plusieurs formulations, ou d'ajouter un second passage de vérification sur les messages à faible confiance.
Vécu Les heuristiques classiques (IP, horaire, device fingerprint) montrent vite leurs limites sur certains événements de sécurité, et c'est précisément le terrain de test choisi. L'auteur fournit un state structuré avec tous les signaux disponibles ; JEV doit décider : block, allow, ou escalate, avec un severity score.
Cas testés :
Chiffre L'auteur insiste : détecter l'exfiltration du point 3 suppose d'avoir capturé les bons événements en amont, c'est-à-dire d'avoir loggé le volume de fichiers lus, la vitesse d'accès et les actions mail. Sans télémétrie correcte, JEV ne peut rien faire.
Méthode Sur les CVE, JEV prend le CVSS score, la description de la vulnérabilité et le contexte de déploiement. Exemple : RCE XML parsing, score 9.8. Mais la fonction XML n'est jamais appelée dans le code et le service tourne en container sans réseau sortant → priority: not applicable, confiance 0.89. Cas inverse : CVE sur service d'auth exposé publiquement, 2 M de comptes, énumération d'emails possible à 300 req/s sans rate limiting → priority: immediate, confiance 0.98.
Vécu L'auteur teste JEV sur des profils client pour déterminer risk_level (low, standard, high, very_high), due_diligence (standard, enhanced, escalate_compliance) et first_item_to_document.
Cas testés :
Chiffre Vient ensuite un test de biais sur la nationalité, à profil identique (résident Paris 9 ans, titre de séjour 10 ans), l'auteur ne modifiant que ce seul paramètre. Français → risk 0.25. Nigérian → risk 0.80. Russe → risk 0.87. Le score bouge, mais JEV maintient due_diligence: standard tant que les autres signaux (résidence, ancienneté) restent solides. Le modèle pondère donc la nationalité sans en faire un critère discriminant absolu.
Opinion Test intéressant, mais incomplet. L'auteur ne précise pas si JEV a été fine-tuné sur des données de compliance réelles ou s'il s'appuie uniquement sur les connaissances du modèle de base. Or un système KYC/AML en production doit être auditable : chaque décision doit pouvoir être justifiée devant un régulateur. JEV fournit un score de confiance, pas d'explication textuelle. Il faudra le coupler à un LLM classique pour générer les justifications en aval.
Méthode JEV repose sur le RLCD parallel sampling, explique l'auteur. Plutôt que de générer séquentiellement des tokens de texte, le modèle évalue en parallèle plusieurs branches de décision et retourne directement la plus probable, avec son score. La phase de génération textuelle est court-circuitée, d'où la latence très faible.
Ce que JEV fait bien :
Ce que JEV ne fait pas :
Opinion L'auteur survend légèrement l'impact sur des produits comme l'indexation massive sur Internet. JEV ne remplace pas un LLM frontier. Il le complète. L'architecture optimale est hybride : JEV pour router, classifier, décider ; LLM pour générer, expliquer, raisonner. Complémentaires, pas concurrents.
L'auteur teste JEV sur des affirmations factuelles pour voir s'il distingue vérité, mythe et paradoxe. Deux outputs demandés : truthfulness score et statement type (fact, myth, unfalsifiable).
À vérifier Sur des mythes bien documentés, les résultats tiennent. Mais aucun cas limite n'est testé : affirmations scientifiques récentes, débats en cours. JEV s'appuyant sur les connaissances du modèle de base, il en hérite les biais et la date de coupure. Un usage fact-checking en production imposerait de le coupler à une recherche web temps réel.
Les limites de taille du state envoyé à JEV ne sont jamais précisées. Sur des événements complexes (logs de sécurité multi-sources, historique client complet), combien de tokens d'input peut-on envoyer avant que la latence explose ? Rien non plus sur la disponibilité en self-hosted : JEV est-il uniquement accessible via API Typesafe AI, ou existe-t-il une version locale ? Aucun chiffre, enfin, sur la reproductibilité. Deux envois du même state donnent-ils exactement le même score, ou subsiste-t-il un sampling stochastique résiduel ? Sur des use cases réglementés comme la finance ou la santé, ces questions conditionnent tout déploiement.
Le transcript porte sur JEV, un modèle d'inférence de Typesafe AI bâti sur le RLCD parallel sampling. Son auteur est développeur SEO. Il présente une série de tests menés en conditions réelles sur des cas d'usage métier : modération de contenu, détection d'urgence, routing d'agents, cybersécurité, KYC/AML, analyse SEO. Ton de praticien qui essaie un outil dans son propre domaine, sans filtre commercial.
JEV part d'une hypothèse : séparer la décision de la génération de texte. Plutôt que de solliciter un LLM généraliste, coûteux en tokens output, pour classifier ou choisir, le modèle extrait directement une décision structurée (choix, score, booléen), avec une latence annoncée à 75 ms. Il retourne un JSON contenant label, probabilité et score de confiance. De quoi injecter des seuils et des règles métier en aval.
Le levier réel : vitesse d'inférence sur des tâches de décision, avec un coût marginal quasi nul par requête (moins de 0, 01 $ pour des dizaines d'appels). L'arbitrage escamoté tient à la structuration des entrées et à la fourniture d'un contexte exploitable. Si les événements ne sont pas capturés proprement en amont, JEV ne résout rien. Rien de magique ici : un oracle rapide, qui exige des données propres.
Opinion L'auteur survend à mon sens l'impact immédiat sur les produits grand public du type Claude Code ou Cursor. Ces outils disposent déjà d'un routing interne optimisé, et intégrer JEV dans leurs pipelines supposera des refactorisations loin d'être triviales. L'effet sera réel. Progressif, pas instantané.
À vérifier Affirmer que JEV ne facture pas les tokens output est techniquement faux. Typesafe AI facture à l'input, la structure JSON retournée restant compacte : le coût marginal est faible, pas nul. Mon expérience montre que sur des volumes industriels, de l'ordre du million de requêtes par jour, même 0, 0001 $ la requête finit par compter.
Quant à l'exemple du phishing avec menace voilée, je le nuancerais : JEV a raté la détection de doxx lors d'un premier test, avant de la capter une fois la question reformulée. La qualité de la sortie dépend donc énormément du prompt structuré. Un praticien devra itérer sur les labels et les définitions pour obtenir des résultats fiables en production.
KΞVPUSH