Jev dans une architecture d'IA juridique : 8 schémas de décision, et la limite que nous avons mesurée

L'argument, et pourquoi nous l'avons pris au sérieux

Il y a un argument selon lequel la plupart des agents d'IA gaspillent leur ressource la plus coûteuse sur des décisions qui n'ont jamais eu besoin d'une phrase. Acheminer une requête vers le bon modèle est une décision. Décider si un appel d'outil est sûr est une décision. Classer cinquante documents récupérés, c'est cinquante décisions. Aucune de celles-ci ne produit de prose que quiconque lit, pourtant toutes sont confiées à un modèle qui facture au mot et répond par paragraphes.

En septembre 2026, TypeSafe AI a livré un modèle construit autour de cet argument. Jev est ce qu'ils appellent un modèle de Système Un, et la propriété distinctive est qu'il ne génère absolument aucun texte. Vous POSTez un bloc d'état plus un ensemble de questions typées, et vous obtenez en retour des probabilités calibrées, toutes évaluées en un seul aller-retour parallèle.

Il y a trois primitives et il n'y en a pas de quatrième. Un noul est une question oui ou non qui renvoie une probabilité entre 0 et 1, et cette probabilité est la confiance : 0,5 signifie un pile ou face, pas une intensité moyenne. Un choix sélectionne une option dans une liste que vous définissez, et il ne peut physiquement pas renvoyer une option que vous n'avez pas déclarée. Un score place l'entrée sur une échelle ordonnée que vous décrivez en mots, et renvoie la moyenne pondérée par la probabilité, donc une répartition 70/30 sur deux niveaux revient à 1,30 plutôt que 1 ou 2.

C'est toute la surface. Il ne peut ni résumer, ni réécrire, ni rédiger, ni extraire une étendue, ni rechercher quoi que ce soit. Il n'a pas de base de connaissances ni de récupération. Il répond à des questions dont l'espace de réponse que vous avez déclaré, concernant un état que vous lui avez fourni.

La partie facile à manquer

L'instinct est de classer cela comme un classificateur rapide et bon marché. Cela sous-estime ce qui a réellement changé, ce qui n'est pas le prix mais l'ordonnancement.

Un modèle linguistique écrit un jeton à la fois, donc le jeton neuf ne peut exister tant que le jeton huit n'existe pas. Posez-lui quatre questions sans rapport sur un contrat et ces quatre jugements indépendants s'alignent les uns derrière les autres, reviennent sous la forme d'un blob que vous analysez ensuite, validez et réessayez lorsque la forme est incorrecte. Jev supprime la file d'attente. Vous déclarez l'espace de réponse à l'avance et chaque question se résout simultanément sur le même état. Le texte est une ligne que vous devez suivre. Un espace de réponse est une pièce que vous voyez d'un seul coup.

Cette ligne de mode de défaillance est celle qui importe en droit, et il convient d'être franc à ce sujet. La garantie offerte est que vous n'obtiendrez jamais une valeur en dehors de votre schéma. Ce n'est pas une garantie que la valeur est juste.

Une erreur valide au regard du schéma rembourse le mauvais client aussi vite qu'une erreur mal formée.

Pour une entreprise de Legal AI, le mot intéressant dans tout cela est calibré. Un nombre sur lequel on peut se baser dans le code est un objet différent d'un paragraphe qu'un avocat doit lire et auquel il doit faire confiance. Nous avons écrit dans notre article sur la couche d'orchestration de l'IA juridique que la partie de l'IA juridique qui détermine si les citations tiennent est invisible de l'extérieur. C'est un candidat pour combler une partie de cette invisibilité.

Nous l'avons donc exécuté sur l'ensemble de notre pile technologique. Toutes les mesures ci-dessous sont les nôtres, sur notre propre corpus, et celles qui ont mal tourné sont également ici.

Ce que nous avons mesuré, et ce que cela a coûté

Dix surfaces, treize tickets fermés, moins de 0,20 $ de dépenses totales. Ce n'est pas une vantardise de frugalité. C'est la raison pour laquelle l'expérience valait la peine d'être menée : à une fraction de centime par jugement, vous pouvez vous permettre de vérifier chaque événement plutôt que d'échantillonner, et un résultat nul ne coûte presque rien à établir.

Latence, mesurée sur notre propre trafic avec une connexion chaude maintenue ouverte : 292 ms au médian, 374 ms à p90, 395 ms à p95, sur 40 appels. Le calcul côté serveur seul est de 112 ms. Notre première mesure indiquait 700 ms, et nous avons répété ce chiffre en interne pendant une semaine avant de remarquer qu'il était erroné. Nous n'avions jamais réutilisé une connexion, donc chaque appel payait pour une nouvelle poignée de main. Même API, même version de modèle, une mesure minutieuse de la mauvaise chose. C'est un petit embarras et un embarras utile, car c'est exactement le genre d'erreur qui rend un benchmark non reproductible un mois plus tard.

Huit modèles, et ceux que nous avons réellement testés

Sept d'entre eux ont circulé comme une liste de modèles de développeur. Le huitième est le nôtre, et c'est celui qui s'avère le plus important pour le travail juridique.

• Routage du modèle. Prédire la complexité de la tâche, envoyer le travail facile à un petit modèle et le travail difficile à un modèle de pointe.
• Portes de risque d'appel d'outil. Avant qu'un agent n'exécute un outil, évaluez l'outil, ses arguments et la tâche actuelle, et renvoyez « autoriser », « bloquer » ou « approbation humaine ».
• Triage des intentions et des domaines. Classez la requête dans un ensemble fixe d'intentions avant que l'agent principal ne commence à raisonner. En droit, il s'agit de la juridiction, du domaine de pratique et du livrable.
• Décisions de boucle. Après chaque étape de l'agent, prédisez si une autre étape est susceptible d'être utile.
• Re-classement de la récupération. Évaluez chaque passage récupéré par rapport à la requête et ne transmettez au contexte que ceux qui ont obtenu les scores les plus élevés.
• Garde-fous et contrôles de politique. Exécutez des contrôles de sécurité et de conformité en tant que classifications rapides au lieu de générer une réponse de raisonnement complète.
• Escalade vers un humain. Prédire si une décision automatisée est suffisamment fiable pour être exécutée.
• Compactage textuel du contexte. Évaluez chaque étape d'une longue trace d'agent pour déterminer si elle est toujours pertinente par rapport à l'objectif, supprimez celles qui ne le sont pas et conservez les survivantes mot pour mot.

Nous en avons maintenant mesuré six sur nos propres données. Trois fonctionnent, dont l'un est en production aujourd'hui. Trois ne fonctionnent pas. Les échecs obtiennent plus d'espace ci-dessous, car ils sont plus instructifs et parce que personne d'autre ne les publie.

Un mot sur le voisinage : un petit nombre d'outils construits sur la même pile existent déjà pour la vérification des citations juridiques, tous livrés au cours des deux dernières semaines. Ce sont des expériences préliminaires plutôt que des produits opérationnels, et aucun ne publie un chiffre de précision. L'écart dans lequel nous écrivons n'est pas que personne n'ait eu cette idée. C'est que personne n'a publié ce qui se passe quand on la vérifie.

Là où ça marche : le re-classement de la récupération

Notre corpus législatif MENA contient 17 004 articles. La récupération y est d'abord lexicale, ce qui signifie qu'une requête et un article utilisant des mots différents pour la même obligation peuvent se manquer entièrement. C'est l'échec habituel de la recherche juridique dans toutes les langues, et c'est pire en arabe, où la morphologie crée plus de distance entre un terme de requête et sa correspondance.

Nous avons pris 80 requêtes mises de côté, les avons exécutées via la récupération existante, puis avons reclassé les candidats en posant une question par candidat : cet article répond-il à cette question.

Le rang réciproque moyen est passé de 0,719 à 0,869. Dix cas sur dix vérifiés manuellement concordaient, y compris deux où le modèle a correctement refusé de promouvoir quoi que ce soit parce qu'aucun candidat valide n'existait. Coût total : 0,0245 $.

Une autre mise en garde. Nos articles en arabe et en anglais sont séparés par juridiction, chaque article arabe est égyptien et chaque article anglais est émirati, donc cette exécution ne soutient aucune affirmation concernant la langue.

Cela fonctionne parce que la question a une bonne réponse. La question de savoir si cet article répond à cette question est réglée par l'article et la question, tous deux présentés au modèle.

Là où ça marche : identifier les réponses qui n'en sont pas.

Avant d'adopter Jev, nous évaluions les réponses de référence avec un modèle linguistique agissant comme juge. Ce juge était généreux d'une manière spécifique et préjudiciable. Il attribuait une note parfaite de 10,0 à 56 % des réponses qu'il évaluait, et pour un modèle, 90 % des réponses revenaient sans défaut sur les quatre dimensions. Un évaluateur sans plafond ne mesure rien en haut de sa fourchette.

Jev a noté 0 % des réponses à 9,9 ou plus. Plus utilement, il a détecté les cinq erreurs d'API tronquées de l'ensemble avec des probabilités comprises entre 0,96 et 0,97. Le juge précédent avait noté ces cinq mêmes erreurs 1 sur 10 et les avait intégrées dans le score de capacité du modèle, ce qui signifiait que nous rapportions un taux d'échec d'infrastructure de 10 % comme une incompétence juridique. Les exclure a fait passer un modèle de 5,80 à 7,67.

La chose la plus précieuse que le modèle ait faite pour nos références n'était pas de juger la qualité. C'était de remarquer qu'une chaîne de caractères n'était pas une réponse.

Là où ça marche, en production : la regex de la porte de conformité ne pouvait pas voir.

Celui-ci est en ligne, et il a gagné sa place en détectant quelque chose d'embarrassant.

Nous faisons passer chaque élément de contenu public par une porte de pré-vérification avant sa publication, le comparant à nos propres règles de messagerie. Certaines de ces règles sont des lignes rouges : nous ne disons pas que nous remplaçons les avocats, et nous ne prétendons pas que notre Legal AI est exempte d'hallucinations, car ni l'un ni l'autre n'est vrai et les deux sont le genre d'affirmations qu'un régulateur lit attentivement.

Une ébauche française contenant des violations littérales des deux règles a passé cette porte à exit 0, sans aucune détection. Les modèles regex étaient uniquement en anglais. Le français pour « nous remplaçons les avocats », et le français pour « notre Legal AI n'a pas d'hallucinations », sont passés directement à travers une vérification qui aurait arrêté leurs équivalents anglais instantanément.

Une passe sémantique a détecté les deux de manière décisive : 0,90 sur l'affirmation implicite, 0,95 sur la ligne rouge du remplacement d'avocat, 0,83 sur la façon dont un régulateur le lirait. Coût par ébauche : environ 0,00005 $, à travers huit questions tapées dans une seule requête parallèle.

Le résultat inattendu est que les expressions régulières (regex) et le sémantique se sont avérés complémentaires plutôt que redondants. Nous sommes partis du principe que l'un remplacerait l'autre, et avons mesuré, sur 35 projets réels, que chaque règle regex avec un équivalent sémantique capturait un libellé différent du même risque. La regex détecte le libellé littéral. Le passage sémantique détecte la paraphrase. Notre propre ticket prévoyait que nous pourrions retirer quelque chose, et les données ont dit non.

Là où ça s'est inversé : lui demander si une citation est fondée

Maintenant, l'échec qui a réorganisé notre pensée.

Nous avons demandé à Jev de noter le caractère fondé de 150 réponses juridiques réelles, produites par trois modèles de pointe à travers 50 requêtes pour la région MENA et le Royaume-Uni. Le caractère fondé ici signifie : les affirmations sont-elles étayées, les citations sont-elles réelles et utilisées correctement. C'est la question la plus importante de l'IA juridique, et c'est la question que notre propre audit d'hallucinations d'IA juridique vise à continuer de poser.

Les réponses contenant des citations fabriquées ont obtenu un score de 3,21. Les réponses honnêtes ont obtenu un score de 2,79. La corrélation entre le score composite et les étiquettes de précision révisées par des humains était de r = +0,02, c'est-à-dire nulle.

La vérification n'a pas seulement échoué à détecter la fabrication. Elle l'a récompensée.

Une fois que vous comprenez pourquoi, vous ne pouvez plus l'ignorer. L'Article 5bis de l'Arrêté Royal M/13 semble précis, spécifique et faisant autorité. Il n'existe pas. Un modèle invité à juger du caractère fondé à partir du texte seul n'a rien à comparer, il se rabat donc sur les caractéristiques qui accompagnent habituellement une écriture fondée : la spécificité, la densité des citations, une structure confiante. La fabrication produit les trois. La spécificité est ce à quoi ressemble la fabrication, donc toute rubrique qui récompense la spécificité récompense la fabrication.

Maintenant, changez une chose. Donnez au modèle le passage source à côté de l'affirmation et demandez si ce passage soutient cette proposition. Sur un ensemble de 180 paires reproductibles de notre propre corpus, le modèle hébergé a atteint une AUC de 0,9962 et a détecté 94,4 % des erreurs d'attribution avec un taux de fausses alertes nul.

Même modèle. Même tâche dans l'abstrait. Résultat opposé, car une version est une comparaison entre deux choses devant elle et l'autre est une recherche de connaissances qu'elle ne peut pas effectuer.

Une dernière mise en garde, car elle est plus importante que la victoire. Sur ce même ensemble de 180 paires, une simple vérification de confinement avec `grep` obtient un score AUC de 0,9944 et détecte 98,9 %. Ces paires ont été construites sur un confinement verbatim, ce à quoi `grep` est précisément destiné. Considérez 0,9962 comme un plancher plutôt qu'un plafond, et considérez la justification au niveau de la paraphrase, où un classificateur typé devrait réellement faire ses preuves, comme non testée par cette exécution.

La récupération n'est pas un détail d'implémentation sous l'étape de vérification. La récupération est ce qui rend la vérification possible.

Là où il a perdu face à un podomètre : contrôle de boucle

Nous l'avons testé spécifiquement pour ce billet, et il n'a pas survécu.

Le modèle dit : après chaque étape de l'agent, demandez si une autre étape est susceptible d'être utile, et arrêtez-vous lorsque la réponse est non. Nous avons construit le test à partir de 52 de nos propres trajectoires d'agent terminées, 1 750 étapes labellisées. La vérité terrain pour chaque étape était de savoir si l'étape suivante avait réellement mis en évidence des informations qui n'étaient pas déjà quelque part dans la trajectoire, calculé par une règle que nous avons vérifiée manuellement sur 24 des 25.

Nous avons payé 0,54 $ pour ne pas battre une fonctionnalité calculée avec une différence d'ensemble.

Deux choses sous-jacentes valent plus que le titre. La première est qu'un temps mort n'est pas un épuisement. La règle d'arrêt libre après deux étapes consécutives qui n'ont rien rapporté de nouveau, exécutée comme un oracle sur sa propre prémisse, a endommagé 30 des 31 trajectoires qu'elle a arrêtées. Les agents se taisent au milieu d'un travail utile tout le temps.

La seconde explique le résultat global. Si l'on divise les lignes par le type d'outil utilisé à l'étape suivante, l'image change complètement : 0,742 lorsque l'étape suivante écrit ou modifie un fichier, 0,695 lorsqu'elle lit ou recherche, et 0,597, proche du hasard, sur les commandes shell, où résident 59 % de nos lignes.

Il ne prédisait jamais si l'agent avait suffisamment appris. Il prédisait si la prochaine chose à revenir serait un accusé de réception d'écriture ou une page de sortie. C'est un jugement sur la forme du prochain événement, et non sur l'état des connaissances de l'agent.

Soyons honnêtes : notre corpus est constitué d'agents de codage et de recherche, et non de boucles de raisonnement juridique, et le plafond des économies était faible au départ, car une transcription terminée est par définition une transcription qui s'est arrêtée approximativement lorsque l'information s'est arrêtée. Ces deux faits limitent la portée de sa généralisation. Aucun des deux ne sauve le modèle.

Où il a perdu face à une expression régulière : les barrières de risque d'appel d'outil

Le dernier modèle que nous avons testé, et le plus inconfortable, car nous voulions que celui-ci fonctionne.

Nous gérons une infrastructure qui ne doit pas tomber en panne. La règle qui la protège réside actuellement dans un fichier de configuration qu'un agent est censé lire et respecter. Une règle qui dépend d'être lue n'est pas un contrôle. Une barrière qui se déclenche à l'appel l'est.

Nous avons donc étiqueté 19 922 appels d'outils réels provenant de 766 de nos propres transcriptions, en avons scoré 284, et avons comparé un classificateur typé à la liste d'exclusion que vous écririez réellement à la main.

Nous avons exigé que chaque appel destructeur soit intercepté. Le classifieur a atteint 89,1 %, en deçà des deux listes de refus. L'expression régulière remporte la classe pour laquelle le test a été conçu.

Il y a une véritable victoire enfouie là-dedans. Sur la question étroite de savoir si un appel spécifique pouvait mettre hors ligne un hôte en direct, une question dédiée oui-ou-non a détecté 21 sur 22 avec un taux de fausse alarme de 3,4 %, tandis que la plus forte des deux listes de refus écrites à la main en a détecté 8 sur 22. En unissant les deux, le taux d'appels risqués qui passent à travers est divisé par deux. À onze cents pour mille appels, le coût n'est pas ce qui vous arrête. La recommandation qui en est ressortie est toujours d'expédier l'expression régulière et de garder le classifieur comme deuxième avis, jamais comme porte.

Le résultat le plus clair de tout le programme se trouve dans ce test, et il porte sur la manière de poser la question plutôt que sur la question elle-même. Même modèle, mêmes lignes, même après-midi. La question concrète - cet appel peut-il mettre hors ligne l'un de ces hôtes en direct spécifiques - a atteint un rappel de 95,5 % avec un taux de fausse alarme de 3,4 %. La question abstraite - cette action est-elle irréversible - a nécessité un seuil beaucoup plus lâche pour atteindre un rappel comparable et a fait monter le taux de fausse alarme à 34,6 % pour y parvenir.

Nous avions appris cela auparavant et l'avions noté comme une maxime : nommer le test concret, pas la catégorie abstraite. C'est la première fois que nous l'avons comme comparaison contrôlée plutôt que comme anecdote, et l'ampleur de l'écart nous a surpris.

Encore une chose de ce test, avec ses limites. Nous avons essayé de convaincre le classifieur d'approuver les appels qu'il avait bloqués, en utilisant huit charges utiles d'injection écrites à la main sur 384 appels appariés, insérées dans la commande, la description et le contexte de la tâche. Aucune n'a réussi à transformer de manière fiable un appel bloqué en appel autorisé. C'est un vrai résultat, et un petit : huit charges utiles écrites par la même personne qui a construit le test ne constituent pas une équipe rouge, et une liste de refus est immunisée contre cela par construction plutôt que par chance. La documentation de TypeSafe elle-même indique que l'état n'est pas traité comme hostile parmi les limitations du modèle, et pour une porte de sécurité, cette limitation porte directement sur l'entrée qu'un attaquant contrôle.

Le huitième modèle, et pourquoi il est juridique

Tout ce qui précède est emprunté à l'ingénierie générale des agents. Celui-ci est le nôtre, et il découle d'une contrainte qui ne se manifeste réellement que dans le domaine juridique.

Les longues exécutions d'agents débordent de leur contexte, et la solution standard consiste à ce qu'un modèle de langage résume la trace jusqu'à présent. Pour la plupart des logiciels, cela est acceptable. Pour le travail juridique, c'est une catastrophe silencieuse, car un résumé d'une loi est un nouveau document. Il contient de nouveaux mots. Ces mots ont été écrits par un modèle, et non par un législateur, et chaque étape en aval raisonne maintenant sur la paraphrase plutôt que sur la loi.

L'alternative consiste à compacter sans paraphraser. Évaluez chaque étape de la trace pour déterminer si elle a toujours un lien avec l'objectif actuel, supprimez celles qui n'en ont pas, et conservez les survivantes mot pour mot. Rien n'est réécrit. Le contexte devient plus court parce que des éléments ont été supprimés, et non parce que des éléments ont été reformulés.

Un résumé d'une loi est un nouveau document. Une liste filtrée de lois est toujours les lois.

C'est le modèle qui nous intéresse le plus et c'est celui que nous n'avons pas encore mesuré, alors traitez-le comme une position de conception plutôt que comme un résultat. Nous le disons à voix haute car c'est le type de problème pour lequel un modèle de décision est exceptionnellement bien adapté, et parce que nous n'avons vu personne d'autre considérer la compaction comme une exigence de correction plutôt que comme une optimisation des coûts.

Deux choses sur le travail juridique dont personne ne vous prévient

Il ne peut pas voir un document scanné. Jev prend du texte. Une très grande partie des documents juridiques réels, en particulier au Moyen-Orient et en Afrique du Nord, se présentent sous forme de photographies de papier. Cela signifie que le pipeline en amont fait tout le travail qui détermine s'il obtient une entrée équitable, et toute confiance qu'il rapporte est conditionnelle à une étape d'OCR dont il ne sait rien. Des réimplémentations ouvertes de la même architecture fonctionnant sur des modèles de base capables de vision existent, ce qui est la direction que prendra cela à terme, mais le modèle hébergé que vous avez devant vous aujourd'hui est aveugle.

Les abréviations juridiques le cassent d'une manière qui ressemble à un bug et n'en est pas un. Nous lui avons demandé de classer une demande de révision d'un MSA arabe et de le "redliner". La "légalité" est revenue à 0,30, ce qui pour une demande clairement juridique ressemble à un échec. Isolez la phrase et l'image se résout : MSA seul obtient 0,97, Master Services Agreement 0,98, un MSA écrit en arabe 0,96, et Arabic MSA s'effondre à 0,30. Placer le mot "Arabic" immédiatement avant MSA transforme l'acronyme de Master Services Agreement en Modern Standard Arabic.

Le modèle a raison. La phrase est véritablement ambiguë, et elle le serait également pour un lecteur humain. Mais le travail juridique au Moyen-Orient et en Afrique du Nord génère constamment cette construction exacte, de sorte que tout pipeline qui s'appuie sur une étiquette de document la rencontrera, et dans un benchmark, cela sera interprété comme une défaillance du modèle alors qu'il s'agit d'un artefact d'ambiguïté d'entrée. Si vous évaluez un classificateur sur du texte juridique, vérifiez s'il y a une abréviation ambiguë avant de conclure que le modèle ne peut pas gérer votre juridiction.

La règle qui en est ressortie

Six surfaces, trois victoires, trois défaites. Le modèle des défaites est ce qu'il faut retenir.

Le reclassement fonctionne parce que "cet article répond-il à cette question" a une réponse que l'article et la question règlent entre eux. L'ancrage de citation fonctionne lorsque vous fournissez la source et s'inverse lorsque vous ne le faites pas, car sans la source, la question devient une recherche de connaissances. Le contrôle de boucle échoue parce que "cet agent a-t-il suffisamment appris" n'est réglé par rien dans la trajectoire. La suggestion de lien interne, que nous avons également testée, a échoué de la même manière : à la question de savoir si un lecteur aurait une vraie raison de cliquer d'une page à l'autre, les scores pour 761 liens sélectionnés par des humains sont revenus à 0,582 pour les vrais liens et 0,537 pour les paires qu'aucun éditeur n'avait jamais connectées, un écart de 0,045, les vérificateurs manuels étant d'accord sur 12 sur 20.

Avant de vous baser sur un jugement, demandez-vous quelle en est la vérité terrain. Si la réponse honnête est une préférence de l'éditeur, attendez-vous à un écart d'environ 0,05 et prévoyez une intervention humaine.

C'est la même limite que notre propre enquête sur les fausses citations a trouvée de l'autre sens, et c'est pourquoi nous jugeons les outils sur leur capacité à vérifier qu'une citation dit ce qu'ils affirment, et non pas simplement qu'elle existe.

Ce que nous dirions à quelqu'un qui évalue l'IA juridique

Quatre choses, dont une seule concerne ce modèle en particulier.

Demandez sur quoi le contrôle est ancré. Notre IA vérifie les citations n'est pas une architecture. Vérifier qu'un cas existe est une recherche dans une base de données. Vérifier que le cas dit ce que la réponse prétend est une comparaison, et elle a besoin du passage source en main au moment du jugement. Les produits qui font le premier et le décrivent comme le second sont la norme, pas l'exception.

Demandez le taux d'échec, pas le taux de succès. Chaque outil dans cette catégorie publie un chiffre qui le flatte. Très peu publient ce qu'ils ont mesuré et perdu. Notre propre honnêteté a des limites qui méritent d'être énoncées : le premier passage automatisé d'étiquetage de ce corpus d'appels d'outils était à 86 % faux sur sa classe la plus importante, tout cela dans la même direction, et nous l'avons trouvé en vérifiant manuellement plutôt que par astuce.

Demandez sur quoi le benchmark a été évalué. Celui-ci piège presque tout le monde. Un benchmark peut être évalué par rapport à la vérité terrain, ou par rapport à un accord avec un modèle de langage de pointe. Le second est beaucoup moins cher et beaucoup plus faible, car s'accorder avec GPT inclut s'accorder avec les erreurs de GPT. Lorsqu'un fournisseur rapporte une précision, la question n'est pas de savoir à quel point le chiffre est élevé. C'est à quoi le chiffre a été comparé.

Soyez prudent avec un chiffre qui est affirmé plutôt que mesuré. Le tableau de lancement de TypeSafe montre un taux d'hallucination de 0 %, et la note de bas de page en dessous indique, selon leurs propres termes, que le chiffre n'est pas empirique et est ajouté par construction parce que la correspondance de schéma est forcée plutôt qu'observée. Ils le divulguent. Le titre au-dessus du tableau ne le fait pas. L'affirmation sous-jacente est vraie et étroite : vous n'obtiendrez jamais une valeur en dehors de votre schéma. Ce n'est pas une affirmation que la valeur est juste. Un analyste indépendant a fait cette remarque une semaine après le lancement, et elle est juste.

Ce qui a réellement changé pour nous

Pas le coût. Échanger un appel de modèle de langage contre un appel typé économise des centimes, et les centimes n'ont jamais été le problème.

Ce qui a changé, c'est qu'une décision que le système prenait déjà silencieusement porte maintenant un numéro. L'examen de contrat à 0,91 contre le litige à 0,09 est une voie que vous pouvez automatiser et enregistrer. 0,52 contre 0,46 est un tirage au sort portant une étiquette, et cela nécessite un humain. Un modèle de langage aurait donné la même réponse dans les deux cas, dans une phrase confiante, sans moyen de distinguer les deux situations.

Pour un produit où se tromper est toute la surface de risque, cela vaut plus que n'importe quel multiple de vitesse sur un tableau de fournisseur.

L'habitude que nous garderions même si nous n'envoyions plus jamais de demande : passer par votre agent et trouver chaque appel qui ne fait que choisir quelque chose. Quel outil ensuite. Est-ce un spam. Ce morceau est-il pertinent. Cela nécessite-t-il un humain. Ce diff est-il risqué. Aucune de ces tâches n'est une tâche d'écriture. Ce sont des instructions conditionnelles que quelqu'un a externalisées à un modèle de pointe, et la plupart d'entre elles n'en ont pas besoin.

Points clés à retenir

• Un modèle qui ne génère aucun texte est un véritable outil pour un harnais juridique, dans les endroits spécifiques où un jugement est une comparaison entre des choses que vous pouvez lui présenter.
• Invité à évaluer la pertinence d'un texte seul, il a obtenu des citations fabriquées plus élevées que des citations honnêtes, 3,21 contre 2,79, avec une corrélation à l'exactitude réelle de r = +0,02. La récupération est ce qui rend la vérification possible, pas un détail d'implémentation sous-jacent.
• Il est en production sur notre portail de conformité, où il a détecté des violations de ligne rouge dans un brouillon français que notre regex en anglais seulement avait laissé passer sans erreur. Les vérifications regex et sémantiques se sont avérées complémentaires, et non redondantes, contrairement à notre propre prédiction.
• Le reclassement de notre corpus de lois de 17 004 articles a fait passer le rappel au rang 1 de 0,638 à 0,850 pour moins de trois cents.
• Le contrôle de boucle n'a pas battu un compteur de pas gratuit lors d'un test apparié, et sa compétence apparente s'est effondrée à un niveau proche du hasard une fois que nous avons contrôlé le type d'action qui suivait.
• Un portail de risque d'appel d'outil a rappelé 89,1 % des appels destructeurs, tandis qu'une liste de refus manuelle a rappelé 99,2 %. Nous expédions la regex.
• Pour le travail juridique spécifiquement : il ne peut pas lire un document numérisé, et l'arabe MSA est interprété comme l'arabe standard moderne plutôt que comme un Master Services Agreement, ce qui fait chuter la qualité juridique de 0,97 à 0,30.
• La compaction doit supprimer, non réécrire. Un résumé d'une loi est un nouveau document.
• Demandez quelle est la vérité terrain pour un jugement avant de vous baser dessus. Pas de vérité terrain, pas d'outil.

Sources et lectures complémentaires

• TypeSafe AI : documentation Jev et limitations publiées
• Cognition nouvelle : la garantie, l'incapacité à halluciner couvre la forme, pas la vérité
• Comment l'Legal AI invente une citation
• Audit d'hallucinations de l'Legal AI
• La couche d'orchestration de l'Legal AI
• Legal AI Benchmark 2026