Des chercheurs de Fudan et d'Ant Group font suivre à un LLM une procédure juridique définie par un graphe

Presque tous les juristes utilisent l'IA, mais très peu lui font confiance. Le problème ne vient pas du fait que le modèle confond des faits. Il est bien plus dangereux qu'il saute silencieusement une étape de la procédure et produise un rapport fluide auquel il manque quelque chose. Nous examinons l'approche TG-RAG, qui tente de résoudre précisément ce problème, et ce que peut en retenir toute personne qui construit des agents pour des domaines réglementés.

L'écart entre le possible et le réel

Selon une étude d'Anthropic de mars 2026, les modèles seraient théoriquement capables d'exécuter près de 90 % des tâches des métiers juridiques, alors que l'IA n'en couvre en pratique qu'environ 20 %. Une enquête de l'ILTA montre que 94 % des cabinets juridiques utilisent ou testent l'IA générative, contre 80 % un an plus tôt. Mais la plupart des outils restent au stade de pilotes. En Russie, le tableau est similaire : environ 88 % des juristes travaillent déjà avec des réseaux de neurones, 84 % craignent des informations inexactes et 80 % se voient obligés de vérifier chaque résultat.

L'auteur de l'analyse, la linguiste appliquée Sergueï Slepoukhine, voit la racine du problème dans la séparation des connaissances. Les connaissances déclaratives (ce que disent les normes et la pratique) sont déjà bien stockées dans des bases vectorielles et de graphes. Les connaissances procédurales (comment agir) se trouvent généralement dans des prompts et des fichiers comme skills.md, c'est-à-dire sous la même forme textuelle que les données elles-mêmes. Un LLM ne fait aucune frontière entre données et instructions ; dans un long dialogue, il s'écarte donc peu à peu de l'instruction initiale. C'est l'instruction drift, que les auteurs de TG-RAG appellent dérive cognitive.

Comment fonctionne TG-RAG

L'idée est simple. Le raisonnement d'un modèle de type reasoning est un simple texte placé entre les balises <think> et </think>. Si vous disposez d'un modèle ouvert sur votre propre serveur, par exemple Qwen ou DeepSeek R1-Distill sur vLLM, vous contrôlez le modèle de chat et pouvez écrire ce texte à la place du modèle. Il le poursuivra comme sa propre pensée, sans le distinguer d'un texte généré.

Le schéma repose sur ce principe. La procédure d'expert (SOP) est formalisée sous forme de graphe : les sommets sont les étapes d'analyse, les arêtes représentent l'ordre et les conditions de transition. Le programme exécute lui-même le graphe. À la frontière d'une étape, il interrompt la génération, insère dans le raisonnement la directive de l'étape suivante et ajoute les connaissances nécessaires à ce moment précis. La procédure trace le chenal, tandis que la recherche dans la base fonctionne de façon ciblée au lieu de tout déverser dans un seul contexte.

Prenons l'exemple d'une due diligence lors de l'achat de parts d'une SARL (OOO). Après la demande de documents, le travail se divise en volets : corporate, actifs, contrats, fiscalité, litiges, dettes et faillite, réglementation et sanctions. Tous convergent vers une matrice des risques. Il faut ici à la fois du multi-hop (rassembler des faits de sources différentes) et du multi-step (parcourir chaque branche dans l'ordre). L'erreur peut ne pas être un fait inexact, mais une étape sautée, difficile à repérer lors de la vérification.

Limites et pistes d'action

La première limite est technique : il faut un accès au prompt « brut » et au modèle de chat. Avec des API fermées, impossible d'insérer du texte dans le raisonnement, du moins sous cette forme. L'approche est donc liée aux modèles ouverts hébergés sur sa propre infrastructure, ce qui n'est pas toujours un inconvénient pour les juristes manipulant des données confidentielles.

La seconde limite est méthodologique. Quelqu'un doit établir le graphe de la procédure, et c'est un travail d'expert. Il doit décrire la SOP et les conditions de transition, et le graphe doit être maintenu à jour lorsque les normes changent. L'approche convient aux tâches dont la procédure est standard ou descriptible, mais pas à l'analyse créative ouverte. De plus, le droit russophone ne dispose d'aucun benchmark reconnu, ce qui rend le gain difficile à mesurer honnêtement. L'auteur le souligne explicitement et promet, dans une seconde partie, une expérience sur ses propres données et une analyse des limites. Les résultats des auteurs de l'article ne figurent pas encore dans cette partie.

Conclusion pratique pour les développeurs et les product managers : si votre agent travaille dans un domaine à procédure stricte (droit, conformité, médecine, finance), cessez de conserver la procédure dans le prompt. Placez-la dans une structure explicite, par exemple un graphe, et exécutez-la par programme. Fournissez les connaissances étape par étape. La vérification du résultat devient alors plus simple : vous ne regardez pas toute la chaîne de raisonnement, mais uniquement si les nœuds obligatoires du graphe ont été parcourus.