Le principe du RAG (Retrieval Augmented Generation) est d’utiliser un modèle de langage pour analyser et mettre en forme les résultats d’une recherche. Mais pour aboutir à cette étape finale, il faut au préalable :
- charger la donnée, qui peut être issue d’un PDF, d’une base de données, d’un site web, etc.,
- la morceler en petites unités (chunks),
- indexer sémantiquement ces petites unités pour les classer,
- transformer la requête de l’utilisateur,
- comparer la proximité entre la recherche et les petits morceaux de contenu,
- rapatrier les n premiers résultats en fonction d’un score de proximité sémantique,
- appeler le modèle pour qu’il « retravaille » les résultats en fonction de la recherche de l’utilisateur.
Rassurez-vous, toutes ces étapes peuvent s’écrire en quelques lignes de code grâce à une librairie comme llamaindex, mais il est intéressant de les détailler car chacune d’entre elles a un impact sur la robustesse et la performance du système final.
Et le no-code ?
Depuis quelques années, une tendance est de fournir des outils no-code. Cette approche est particulièrement adaptée pour les professionnels n’ayant aucune compétence en programmation. Il existe même des formations spécialisées sur le sujet pour les avocats. Les grandes plateformes du marché, comme Bubble ont, bien entendu, pris la vague de l’IA et intégré des briques de RAG dans leur offre. Plus intéressant, il existe des offres spécialisées pour l’implémentation de cette technique comme langflow ou Rivet. Cette dernière offre, opensource, est issue d’un éditeur de la legaltech. A cheval entre les deux, on trouve des ateliers de développement hybride qui permettent de tester les processus visuellement et de générer le code dynamiquement en fonction des choix effectués.
Alors pourquoi choisir une librairie python comme llamaindex pour cet article ? L’explication principale est que nous allons employer par la suite des techniques beaucoup plus sophistiquées qui nécessitent une maîtrise du code. Il n’est pas nécessaire d’en comprendre le fonctionnement mais de le voir en action pour saisir les subtilités notamment dans les processus d’évaluation. Sans cet accès au code source, il n’est pas possible de jongler entre les différents concepts. L’autre justification tient au fait qu’il y a peu de différences entre une solution no-code et trois lignes de code qui se comprennent aisément.
1 – Le sourcing : quelle donnée ?
La matière juridique a un avantage, c’est sa structuration. Un code ou un texte consolidé fournit une approche hiérarchique qui renseigne sur le sens d’un texte par sa position en son sein. Une décision de justice obéit à une structure type qui se répète de manière globalement identique. Cette structuration intrinsèque présente un avantage par rapport à un texte libre car le découpage peut nous aider à capturer le sens.
Dans notre exemple, nous allons prendre un document de plusieurs centaines de pages, à savoir le nouveau règlement européen sur l’IA. Cet exemple va permettre d’explorer à la fois les contraintes liées à un document qui n’est pas structuré au départ pour la machine et illustre les contraintes que l’on peut rencontrer si l’on indexe ses propres documents, comme des contrats types. Enfin, cela me permettra d’explorer la création d’un dataset dédié à la nouvelle législation via la création d’un jeu d’instructions (cf. partie IV) et la possibilité de fine-tuner notre propre modèle.
Le document de l’IA Act se présente sous forme d’un long PDF que nous allons tronçonner en petits morceaux pour des raisons d’indexation.
2 – Le découpage
Le découpage ou chunking permet d’isoler les différents éléments sémantiques d’un contenu. Il existe une multitude de techniques et de stratégies différentes en fonction des objectifs : on peut découper les phrases, découper des chaînes de caractères, utiliser des techniques sophistiquées de découpage sémantique… Ces différentes approches dépassent largement ce court article.
3. L’indexation : mots-clés ou sémantique
Une fois le contenu découpé, il faut l’indexer. Il y a traditionnellement deux approches : la première consiste à créer un dictionnaire de mots-clés rattaché à chaque document (en l’occurrence aux morceaux de documents) ; la seconde consiste à utiliser des vecteurs, des suites de chiffres, qui représentent sémantiquement le contenu dans des espaces multidimensionnels. Ces vecteurs sont extraits des modèles de langage et fournissent la représentation sémantique apprise par le modèle.
| Critère | Indexation par mots-clés | Indexation sémantique |
|---|---|---|
| Définition | Utilisation de mots spécifiques comme étiquettes pour le contenu. | Utilisation de la signification globale et du contexte pour indexer le contenu. |
| Technologie | Simplicité, basée sur des mots exacts. | Plus complexe, utilise l’intelligence artificielle et le traitement du langage naturel. |
| Précision | Moins précise, dépend des mots exacts utilisés dans la requête. | Plus précise, peut comprendre la nuance et le contexte. |
| Flexibilité | Limitée aux mots spécifiques présents dans les textes. | Plus flexible, capable de relier des concepts même sans mots clés précis. |
| Mise en œuvre | Plus facile et moins coûteuse à mettre en place. | Nécessite des outils et des compétences plus avancés, donc plus coûteuse. |
| Performances | Rapide pour des bases de données simples et des requêtes directes. | Peut être plus lente mais fournit des résultats plus pertinents sur des requêtes complexes. |
| Évolutivité | Bien adaptée à des systèmes où les requêtes sont prévisibles et standardisées. | Mieux adaptée à des environnements évolutifs avec des besoins complexes et changeants. |
| Utilisation typique | Catalogues, bibliothèques, recherche de documents simples. | Recherche avancée, assistants virtuels, systèmes de recommandation. |
L’indexation sémantique présente l’avantage de capturer le sens des phrases. Par exemple, la référence à un couple marié permettra de trouver les jurisprudences concernant les régimes matrimoniaux, alors que ces mots n’apparaissent jamais dans le texte.
Cette indexation est réalisée à l’aide de modèles spécifiquement entraînés pour cela. La bonne nouvelle est qu’il existe une multitude de fournisseurs, à commencer par le français Mistral, ou OpenAI. D’ailleurs, leurs services sont directement intégrés dans les librairies les plus connues.
Rien n’empêche de réaliser cette opération manuellement, mais elle nécessite des jeux de données particuliers ainsi que les compétences associées.
4. Le stockage
Une fois les données indexées, et avant de les interroger, il faut pouvoir les stocker. Il existe, là encore, pléthore d’offres de stockage sur le marché. Cette offre s’est véritablement étoffée avec l’explosion des LLM et l’engouement du marché pour les solutions basées sur le RAG.
Dans notre exemple, on se contentera d’utiliser une indexation en mémoire non persistante, mais dans un déploiement réel il faudra prendre en compte différents critères pour le choix d’une solution de ce type. Là encore, cela dépasse le cadre de ce tutoriel.
5. Le procédé d’interrogation : le R de RAG
Une fois nos documents indexés, il faut pouvoir les interroger. La solution est assez simple : on indexe de la même manière la recherche de l’utilisateur et on la compare à nos données présentes dans la base de données pour ne rapatrier que les exemplaires les plus proches. On choisit généralement de ne rapatrier que 10 ou 20 résultats.
6. La transformation des résultats grâce au LLM : le AG de RAG
L’astuce consiste à passer les résultats au modèle avec différentes techniques de prompt pour qu’il fournisse une réponse à la recherche. Le modèle agit comme un assistant qui va synthétiser les résultats en fonction de votre recherche. Compte tenu de sa capacité à manier la langue, il sera capable, en principe, d’identifier les passages les plus pertinents dans les résultats retournés puis de les présenter de manière à fournir une synthèse, en citant ou non ses sources. Là encore, la matière est vaste et la théorie ne colle pas toujours à la pratique, loin s’en faut.
7. Mise en musique
Maintenant que les étapes sont posées, voici le code et ce qu’il produit :
! pip install llama-index
from llama_index.core import SimpleDirectoryReader, VectorStoreIndex
from llama_index.core.node_parser import SentenceSplitter
# On lit les documents depuis le répertoire
reader = SimpleDirectoryReader(input_dir="/content/docs/")
documents = reader.load_data()
# Llama index s'occupe d'indexer les documents et de les stocker pour interrogation
index = VectorStoreIndex.from_documents(documents)
# On créé un chatbot prêt à l'emploi
chat_engine = index.as_chat_engine(chat_mode="condense_question", verbose=True)
# et on pose nos questions ...
question = "Peux tu me définir ce qu'est un modèle de fondation dans l'IA Act ? "
Querying with: Peux tu me définir ce qu'est un modèle de fondation dans l'IA Act ?
response = chat_engine.chat(question)
print(response)
Un modèle de fondation dans l'IA Act est un modèle d'IA à usage général qui est clairement défini et distinct de la notion de systèmes d'IA. Il se caractérise par sa capacité à exécuter de manière compétente un large éventail de tâches distinctes, généralement entraîné avec de grandes quantités de données à travers diverses méthodes telles que l'apprentissage auto-supervisé, non supervisé ou par renforcement. Ces modèles peuvent être mis sur le marché de différentes manières, mais ils nécessitent l'ajout d'autres composants, comme une interface utilisateur, pour devenir des systèmes d'IA.
response = chat_engine.chat("Peux tu m'en dire plus sur les relations entre les systèmes d'IA et les modèles à usage général dans l'IA Act")
print(response)
Querying with: Quelles sont les relations entre les systèmes d'IA et les modèles à usage général dans l'IA Act ?
Les modèles d'IA à usage général sont des composants essentiels des systèmes d'IA, mais ils ne constituent pas des systèmes d'IA en soi. Pour devenir des systèmes d'IA, les modèles d'IA nécessitent l'ajout d'autres composants tels qu'une interface utilisateur. Lorsqu'un modèle d'IA à usage général est intégré dans un système d'IA ou en fait partie, ce système est considéré comme un système d'IA à usage général, ce qui lui confère la capacité de répondre à divers usages.
response = chat_engine.chat("Quel régime juridique est prévu pour les modèles à usage général ? ")
print(response)
Querying with: Quel régime juridique est prévu pour les modèles à usage général dans l'IA Act ?
Les modèles à usage général dans l'IA Act sont soumis à un régime juridique qui prévoit des obligations spécifiques pour ces modèles. Ces obligations continuent de s'appliquer une fois que les modèles à usage général sont mis sur le marché, en plus des obligations applicables aux systèmes d'IA. Les modèles d'IA à usage général présentant un risque systémique doivent toujours respecter les obligations pertinentes énoncées dans l'IA Act.
# On remarque au passage la reformulation de la question !
response = chat_engine.chat("Ta réponse est trop vague, peux tu me décrire précisément les obligations qui sont prévues ? ")
print(response)
Querying with: Quelles sont les obligations spécifiques prévues pour les modèles à usage général dans l'IA Act?
Les obligations spécifiques prévues pour les modèles à usage général dans l'IA Act incluent l'élaboration et la mise à jour de la documentation technique du modèle, y compris son processus d'entraînement et d'essai, ainsi que les résultats de son évaluation. De plus, les fournisseurs doivent élaborer, tenir à jour et mettre à disposition des informations et de la documentation pour les fournisseurs de systèmes d'IA qui envisagent d'intégrer le modèle d'IA à usage général dans leurs systèmes, afin de leur permettre de comprendre les capacités et les limites du modèle et de se conformer aux obligations du règlement.Critique
On voit que les résultats produits sont assez bluffants pour une solution qui tient en quelques lignes. Bien entendu, il y a des imprécisions et cela manque de fiabilité, mais il ne faut pas oublier que rien n’a été travaillé en amont. À ce stade, on a utilisé des mécanismes standards et le texte a été découpé de manière abrupte sans utiliser de techniques raffinées. Le but de la démonstration est d’illustrer comment on peut réaliser un chatbot en quelques lignes de code sur un sujet juridique. Pour revenir à mon propos liminaire, on peut voir avec quelle facilité déconcertante il est possible de réaliser ce type d’outils. D’où la prolifération des offres de remplacement des professionnels du droit et des outils no-code permettant de mettre en musique ce processus.
La réalité est, bien entendu, beaucoup plus complexe, et cette technique ne fournit que des réponses imparfaites aux besoins de fiabilité des domaines comme la médecine ou le droit.
A ce stade, nous n’avons que produit un chatbot comme il en existe des milliers dans différents domaines. Nous verrons, dans une prochaine partie, les différents enjeux tout au long de la chaîne de production pour construire un chatbot juridique qui tienne la route :
- Quelle stratégie de découpage (chunkisation) ?
- Est-il possible d’améliorer les résultats bruts (reranking, cross-encoder, bi-encoder) ?
- Comment et quand utiliser le LLM ?
- Quelles stratégies pour organiser les données ?
- Faut-il opter pour l’adaptation d’un modèle (fine tuning) ou peut-on se contenter d’un système de type RAG ?
- Comment évaluer les sorties du modèle et améliorer notre système en continu ?
- Est-ce que les agents autonomes apportent des avantages significatifs dans notre système ?
Dans toutes ces questions, les avocats ont un rôle à jouer dans l’élaboration de systèmes qui reposent sur le langage et, surtout sur une expertise métier forte. N’hésitez pas à me faire part de vos commentaires par email sur ces différents sujets.