En bref : la plupart des produits d'IA juridique sont architecturalement identiques. Votre question est adressée à un modèle à usage général avec un modèle d'invite intégré, et vous ne pouvez pas le voir depuis l'interface. La différence qui compte se produit avant l'appel du modèle. Quatre questions à la fin de cet article vous diront quel type de système n'importe quel fournisseur vous vend, en une dizaine de minutes de démonstration.
Chaque avocat évaluant l'IA juridique finit par poser la même question, généralement après environ huit minutes de démonstration : en quoi est-ce différent de l'utilisation de ChatGPT ?
C'est la bonne question, et la plupart des fournisseurs y répondent mal. Ils parlent de données d'entraînement, ou d'un corpus propriétaire, ou d'un affinage. Ces réponses sont difficiles à vérifier et, le plus souvent, ce n'est pas là que réside réellement la différence.
La réponse honnête est architecturale, et elle se résume à une chose : où se passe la réflexion ?
Le problème de l'enveloppe est réel et invisible de l'extérieur
Une grande partie des produits d'IA juridique fonctionnent ainsi. Vous tapez une question. Le produit l'enveloppe dans un modèle d'invite, des instructions pour être un assistant juridique utile, peut-être quelques exemples, et transmet le tout à un modèle à usage général. Le modèle répond. Le produit formate joliment la réponse et vous la montre.
Il n'y a rien de malhonnête à cela. Cela peut être vraiment utile. Mais cela signifie que la qualité du produit est presque entièrement la qualité du modèle, et le modèle est le même que celui auquel votre avocat adverse peut accéder pour vingt dollars par mois.
La partie inconfortable pour un acheteur est que vous ne pouvez pas le voir depuis l'interface. Une enveloppe et un moteur spécialement conçu ont l'air identiques : une zone de texte, une réponse en continu, quelques citations en dessous. La différence est en amont, là où personne ne peut la voir, et c'est précisément pourquoi si peu de fournisseurs sont interrogés à ce sujet.
Où le raisonnement doit réellement avoir lieu
Lorsqu'une question arrive chez HAQQ, elle ne va pas d'abord à un modèle général. Elle passe par une étape que nous possédons et contrôlons, dont le seul but est de déterminer ce qu'est réellement la demande et de configurer tout ce qui se passe ensuite.
Cette étape résout les problèmes qu'un associé compétent établirait avant de commencer le travail, et elle les résout en tant que données structurées plutôt qu'en tant que prose :
- Ce qui est réellement demandé. Non pas les mots tapés à 23h entre deux appels, mais la question sous-jacente, reformulée précisément et complètement. Ceci fonctionne nativement en arabe et en français ainsi qu'en anglais, plutôt que comme une traduction ajoutée après coup.
- Quel type de travail juridique il s'agit. Rédaction, recherche, révision, comparaison, une question de procédure. Chacun demande une forme de réponse différente, et le décider en amont est très différent d'espérer qu'un modèle général l'infère.
- Quelle juridiction est en jeu, et séparément, dans quelle langue le droit applicable est rédigé. Ces deux aspects ne sont souvent pas les mêmes, et les traiter comme un seul est une source d'erreur discrète et courante.
- Les faits, en tant qu'objets. Parties, dates, obligations, montants, droit applicable, type de document, extraits de la prose et transformés en données structurées avant que quoi que ce soit de coûteux ne les lise.
- Ce dont la question a besoin, et ce dont elle n'a pas besoin. Quelles capacités spécialisées mobiliser, quelle profondeur de raisonnement la question justifie réellement, et si elle relève du champ d'application.
Ce n'est qu'ensuite que le modèle à usage général s'exécute. Et il arrive déjà préparé : les capacités pertinentes chargées, les faits extraits, la juridiction identifiée, la portée décidée.
Le modèle est la dernière étape de la chaîne, pas la première.
Pourquoi cela produit une meilleure réponse, pas seulement une moins chère
Deux mécanismes, et le second nous a plus surpris que le premier.
L'attention est un budget
La fenêtre contextuelle d'un modèle est limitée, et tout ce que vous y mettez entre en compétition pour l'attention du modèle. Charger toutes les capacités d'un système dans chaque requête consomme une part importante de cette fenêtre avant que le document réel de l'avocat ne soit examiné. N'apporter que les capacités pertinentes laisse de la place pour ce qui compte : le contrat, le statut, les faits.
L'analyse syntaxique n'est pas un raisonnement
C'est l'effet le plus important. Lorsqu'un modèle reçoit un paragraphe de prose, une partie significative de son travail consiste à déterminer ce que contient le paragraphe. Lorsqu'il reçoit des faits structurés - ces parties, ce droit applicable, cette obligation, cette date - ce travail est déjà fait, et tout le budget est consacré à la question juridique.
La conséquence pratique est que le même modèle à usage général produit un travail juridique mesurablement meilleur au sein d'un tel système qu'en dehors. Le modèle n'a pas changé. Ce que nous lui avons fourni, oui.
Ce que personne ne met dans une démo
Deux choses qui n'apparaissent jamais dans une présentation commerciale, et qui décident toutes deux si le produit fonctionne un vrai mardi.
Intégration de documents. Une grande partie du travail juridique n'arrive pas sous forme de texte propre. Il arrive sous forme de photographie d'un document estampillé, d'un scan de fax, d'un PDF que quelqu'un a imprimé et rescanné de travers. Nous traitons la lecture de ces documents comme un problème d'ingénierie de première classe plutôt que comme une réflexion après coup sur le prétraitement, car si un numéro de clause est mal lu à l'entrée, aucune quantité de raisonnement en aval ne le récupérera. Le système raisonnera impeccablement sur le mauvais numéro.
La mémoire comme structure, pas comme transcription. Le moteur conserve les relations entre vos dossiers au fil du temps et les utilise lorsqu'une question l'exige. C'est différent de coller vos vingt derniers messages dans l'invite. C'est ce qui permet au système de savoir que la contrepartie dans l'accord de confidentialité que vous examinez aujourd'hui est la même que celle d'un litige il y a deux mois.
Ce que cette architecture ne corrige pas
Nous préférons le dire plutôt que de vous laisser le découvrir.
Cela n'élimine pas les erreurs. Tout système basé sur un modèle linguistique peut produire une réponse erronée, et un fournisseur qui vous dit le contraire ne fait pas attention à ses mots ou espère que vous ne vérifierez pas. Une bonne architecture rend les erreurs plus rares et détectables: des affirmations générées à partir de sources récupérées, des citations que vous pouvez ouvrir, et des indicateurs explicites lorsque la loi est réellement ambiguë plutôt qu'une résolution confiante de quelque chose d'incertain.
Cela ne remplace pas l'avocat. Tout ici est conçu autour de l'hypothèse qu'un professionnel examine le résultat et le signe. Ce n'est pas une limitation dont nous nous excusons. C'est la contrainte de conception, et c'est la raison pour laquelle l'architecture se présente comme elle le fait.
Cela ne rend pas la couverture universelle. La qualité de Legal AI varie selon la juridiction, le degré de numérisation de la loi source et la proportion de celle-ci qui est publique. Il faut demander à quiconque vous cite un chiffre de couverture global unique ce qu'il inclut. On nous pose fréquemment cette question, et nous préférons y répondre concernant votre juridiction plutôt que de vous agiter un chiffre.
Comment tester n'importe quel fournisseur pour cela lors d'une démo
Vous n'avez pas besoin de voir le diagramme d'architecture de qui que ce soit. Quatre questions, environ dix minutes, et elles fonctionnent pour tous les fournisseurs de la catégorie, y compris nous.
1. Demandez-lui quelque chose en dehors du droit
Un modèle général encapsulé dans une instruction juridique répondra généralement à une question médicale ou financière, car fondamentalement, c'est un modèle général. Un système qui établit l'intention avant de générer devrait refuser et expliquer pourquoi.
2. Posez la même question dans deux langues
Pas une version traduite. La même question juridique, une fois en anglais et une fois en arabe ou en français. Si le fond de la réponse change, la langue est traitée après le raisonnement plutôt qu'avant.
3. Soumettez un scan de mauvaise qualité
Photographiez un document de travers, sous un mauvais éclairage, et téléchargez-le. C'est le test le plus prédictif de toute la démo, car c'est l'entrée réelle la plus courante et la moins souvent démontrée.
4. Demandez-lui ce qu'il ne sait pas
Poussez vers un domaine du droit ambigu, incertain ou peu documenté. Un système optimisé pour toujours produire une réponse en produira une. Un système conçu pour le travail professionnel vous dira que le terrain est incertain et vous montrera pourquoi.
Si un fournisseur est à l'aise avec les quatre points, l'architecture est probablement réelle. Si la démo les contourne, c'est aussi une information.
Points clés à retenir
- La différence significative entre les produits d'IA juridique est architecturale et invisible depuis l'interface. Demandez où le raisonnement se produit.
- Effectuer un travail structuré avant l'appel du modèle améliore la qualité de la sortie, pas seulement le coût. Un modèle auquel on a fourni des faits extraits dépense son budget sur le droit plutôt que sur l'analyse syntaxique.
- Les composants peu glamours décident des performances réelles. La qualité de la saisie des documents est plus prédictive de l'efficacité d'un outil un mardi que n'importe quel score de référence.
- Quatre questions de démonstration, hors sujet, deux langues, un mauvais scan et un domaine du droit incertain, vous diront quel type de système vous est vendu.
- Le moteur Justinian et son mode de raisonnement
- 45 signaux d'alarme lors de l'évaluation d'un fournisseur d'IA juridique
- L'humain dans la boucle de l'IA juridique
- Ingénierie de contexte pour l'IA juridique
Essayer HAQQ AI gratuitement
Découvrez la rédaction et la recherche juridique par IA
