Comment bien configurer son architecture RAG

Les fondamentaux d’une architecture RAG

De petits rappels s’imposent. À commencer les fondamentaux d’une architecture RAG. Son fonctionnement se décline en deux grandes étapes que sont l’ingestion et la recherche. Dans le détail, l’ingestion de documents est elle-même divisée en trois sous étapes : le parsing, le chunking et la phase d’embedding.

Le parsing consiste à transformer des documents comme des PowerPoint, des PDF, des fichiers HTML, ASPX, Word, etc., en textes. Ces textes peuvent être découpés en petits bouts lors de la phase de chunking. Puis la phase d’embedding correspond à leur conversion en vecteurs et leur indexation dans une base de données.

Lors de la recherche, « la première étape qui peut avoir lieu, mais qui est souvent facultative, c’est la réécriture de la requête ou sa décomposition », précise Virginie Mathivet. « Elle consiste à réécrire la question ou à la subdiviser. Ensuite, l’on va récupérer les documents qui correspondent à la question, et l’on va les retrier. C’est le re-ranking. Nous allons enrichir un prompt avec ces documents et généralement un LLM va fournir une réponse ».

Ce sont autant de sous-étapes qui peuvent poser des problèmes. Or, décoincer un tel flux n’est pas évident. D’autant qu’un « système RAG défectueux ne produit pas de grosses hallucinations. Les informations peuvent ne pas être retrouvées ou il peut les mélanger parce que les sujets sont proches », observe l’experte.

L’extraction de texte, une étape presque aussi importante que le chunking

AWS Summit oblige, Virginie Mathivet base ses exemples sur les services du fournisseur cloud AWS. Bon nombre de ces remarques et conseils sont applicables avec d’autres technologies.

Ainsi, avec Amazon Bedrock, il existe plusieurs moyens d’effectuer le parsing. Le premier, par défaut et gratuit, extrait uniquement le texte des documents. Il ne s’appuie pas sur des modèles d’IA, mais sur des librairies du type PyMuPDF qui, en quelque sorte, décompose les formats de fichiers pour en extraire le texte. « Quand vous n’avez que du texte, c’est très bien. En revanche, dans un fichier PDF, il y a aussi des images et des tableaux. Ils seront tout simplement ignorés », explique-t-elle. « J’ai l’exemple d’un client qui avait effectué un rapport marketing où un chiffre important était joliment présenté sous la forme d’une image, donc il n’existait pas pour le parser ».

Au sein de Bedrock, l’option Data Automation extrait le texte des documents, des tableaux, des schémas et des images. Elle est facturée à la page. « Ce n’est pas précisé, mais le ou les modèles sous-jacents ne sont pas capables d’extraire du texte des images au milieu d’un PDF », précise Virginie Mathivet. « Les images doivent être dans des fichiers séparés ». L’avantage, c’est que ce système prend également les fichiers audio et vidéo, là où d’autres services réclameraient de faire appel à des outils de transcripts ou de descriptions distincts. AWS ne détaille pas les technologies exactes, mais Data Automation repose sur des modèles d’IA générative qui ne gèrent pas ou mal la multimodalité.

Enfin, il est possible de sélectionner le LLM de son choix avec l’option Foundation Model. « Vous payez le modèle de votre choix au token. Un prompt permet d’extraire les données, de les décrire et de placer ces éléments dans des balises, même quand le document est multimédia. Si les résultats sont beaucoup plus complets, c’est aussi beaucoup plus cher », prévient Virginie Mathivet.

D’où la nécessité de préparer plusieurs pipelines d’injection en fonction des types de documents, conseille-t-elle. « Il n’est pas nécessaire d’utiliser un LLM pour toutes les opérations d’extraction ».

Rien n’empêche les équipes responsables d’un projet RAG de constituer leurs propres pipelines d’ingestion en s’appuyant sur des librairies d’extraction open source. C’est d’ailleurs recommandé quand les structures des documents sources sont particulières ou que les données à extraire sont de même nature.

Virginie Mathivet mentionne par exemple Chunk Norris, un projet open source consacré au chunking de documents, qui contient des parsers pour les fichiers Markdown et PDF. De même, il existe plusieurs parsers pour s’adapter aux particularités du format PPTX. « Les textes d’un slide PowerPoint ne sont pas rangés dans leur ordre d’apparition, mais d’édition et de modification », déclare-t-elle. « Par défaut, le texte est dans le désordre ». Une autre option est d’utiliser des modèles OCR de type Tesseract comme Amazon Textract.

Du bon découpage des documents

Peu importe le pipeline d’extraction, le texte peut ensuite être ingéré gratuitement avec le parseur par défaut de Bedrock.

Après avoir extrait le texte vient l’opération délicate du chunking. Elle revient à diviser le texte en petits morceaux qui seront convertis en vecteurs à des fins de recherche. « Une fois vectorisé – donc résumé de manière mathématique –, si un chunk est trop gros, le sens sera noyé. S’il est trop petit, l’information recherchée n’y sera même pas présente », distingue la dirigeante du cabinet Hemelopse.

Bedrock propose six options en la matière. La première consiste en un découpage, tous les 300 tokens environ. « Ce n’est pas exactement 300 tokens : l’outil de chunking ne découpe pas les textes en milieu de phrase ». En revanche, il n’y a pas de chevauchement et le système respecte la pagination. « Cette option fonctionne rarement, car l’on traite rarement d’un sujet différent par page », relate Virginie Mathivet. De plus, 300 tokens seraient souvent insuffisants pour la langue française.

La deuxième option consiste à sélectionner un chunk de taille fixe. Ici, le mécanisme ne respecte plus la structure de la phrase. « L’on se retrouve avec des bouts de phrases incompréhensibles réparties dans les chunks qui se suivent. Pour résoudre ce problème, l’on ajoute l’overlap. Cela consiste à reprendre un certain pourcentage de la fin d’un chunk pour commencer le suivant et ainsi de suite », détaille l’experte. Si une phrase n’est pas trop longue, une même information peut se retrouver dans deux chunks qui se suivent. Si les phrases sont longues, il faudra augmenter le pourcentage du chevauchement. Ce principe est valable pour tous les systèmes de chunking, mais chez AWS il faut ajouter là encore le respect de la pagination.

Les grands chunks sont recommandés quand les documents ne sont pas très structurés ou qu’ils renvoient à des idées générales. En revanche, les documents techniques requièrent de plus petits chunks.

Pas de chunk, pas de problème ?

« La troisième option consiste à ne pas chunker », poursuit Virginie Mathivet. « C’est idéal pour des fiches de référence utilisées pour les appels d’offres, pour des CV d’une page ou des fiches produit ». Si un article de loi tient sur une page, cela fonctionne également. C’est la méthode privilégiée par MongoDB pour son système d’automatisation du RAG.

Les trois autres options disponibles au sein d’Amazon Bedrock correspondent à un découpage hiérarchique, sémantique ou personnalisé.  

Le découpage hiérarchique ne respecte pas la structure du document, mais offre une option intermédiaire quand il est difficile de déterminer la taille idéale des chunks. L’outil crée de petits chunks et de plus grands qui contiennent les éléments des plus petits. Les petits chunks sont utilisés lors de la recherche et les plus grands servent à générer la réponse. Ce découpage est forcément plus coûteux, car les deux types de chunks sont conservés. « C’est rare que cette méthode soit utilisée en production. Elle permet surtout de déterminer la taille des chunks dans une phase de POC », observe Virginie Mathivet.

Le découpage sémantique correspond à la tentative de créer des chunks par idée. « Ici, le système découpe le texte phrase par phrase, les compare deux à deux sous forme de vecteurs. Plus leurs vecteurs sont proches, plus elles parlent du même sujet. Si le vecteur s’éloigne du précédent, le système crée le chunk suivant », explique-t-elle. Ce mécanisme fonctionne bien pour des documents longs comme des discours, mais le mécanisme implique de doubler les étapes de chunking et d’embedding, ce qui revient à deux fois plus cher, souligne l’experte. Il convient de paramétrer la taille maximale d’un chunk et le seuil de similarité qui déclenchera le passage au chunk suivant.

La dernière option consiste à créer, là encore, son propre découpage. AWS ne propose aucune option de découpage par titraille. Or, un simple parser est capable d’extraire le texte en respectant les balises HTML. La librairie Chunk Norris utilise une méthode similaire en s’appuyant sur la table des matières et en ne prenant pas en compte les en-têtes et les pieds de page (contrairement aux autres techniques). Ensuite, le contenu de chaque balise correspond à un document à vectoriser, sans chunking.

La vectorisation, plus complexe qu’il n’y paraît

Vient ensuite l’étape de vectorisation. Par défaut, Amazon Bedrock propose trois modèles d’embedding : Amazon Titan et deux autres fournies par Cohere (anglais et multilingue). « Il en existe beaucoup d’autres accessibles sur Hugging Face, mais le choix n’est pas forcément évident », indique Virginie Mathivet. « Si un modèle d’embedding ne comprend pas votre vocabulaire, il ne comprend pas le document. Il lui associe un vecteur de manière un peu aléatoire qui sera difficile à retrouver ».

« Si un modèle d’embedding ne comprend pas votre vocabulaire, il ne comprend pas le document. Il lui associe un vecteur de manière un peu aléatoire qui sera difficile à retrouver. »

Il faut donc analyser la similarité de vecteurs correspondant à des chunks contenant des mots différents qui renvoient au même sujet. Si cela ne fonctionne toujours pas, un fine-tuning léger du modèle d’embedding peut s’imposer, mais reste plus complexe.

La fondatrice de Hemelopse conseille de ne pas modifier les paramètres par défaut du type et du nombre de dimensions des embedding. « Ces paramètres correspondent à des usages avancés qu’il vaut mieux laisser de côté dans un premier temps ».

Les bases de données capables de stocker et de retrouver les vecteurs pullulent. Depuis Bedrock, AWS propose quatre grandes options : OpenSearch, S3 vectors, Aurora PostgreSQL et Amazon Neptune Analytics.

OpenSearch est une base de données NoSQL dérivée d’ElasticSearch et donc d’Apache Lucene. « C’est la plus performante, elle dispose d’un mécanisme de recherche hybride et peut encaisser un grand nombre de documents. En revanche, elle coûte très cher ».

S3 Vectors est l’option de stockage de vecteur de l’espace de stockage objet d’AWS. Simple à utiliser, peu cher, le service pêche par l’absence d’une recherche hybride, la plus grande latence pour retrouver les documents et une limite de taille des métadonnées associées, utilisées pour filtrer les documents.

Aurora PostgreSQL est compatible avec l’extension pgvector. « C’est assez limité en volumétrie, en revanche vous pouvez stocker les vecteurs dans une colonne à côté de données associées. Cela évite de créer des espaces de stockage dédiés pour les vecteurs », résume Virginie Mathivet. C’est également vrai pour PostgreSQL open source. D’autres bases de données relationnelles comme Oracle ou SQL Server disposent de propriétés similaires.

Amazon Neptune Analytics est un moteur analytique en mémoire orienté graphe, qui permet de créer des graphes de connaissances. « L’avantage, c’est ce que ce service est un GraphRAG. L’inconvénient c’est que c’est un GraphRAG », plaisante l’experte. « Cela fonctionne très bien dans des cas très limités. Il vous faut une ontologie, c’est-à-dire des liens entre vos données et des concepts, ainsi que des connexions clairement établies entre les concepts. Sans cela, ce n’est pas très utile ». Neo4J est également à ranger dans cette catégorie. Et de constater que la plupart des patrimoines de données en entreprise ne sont pas prêts pour cette architecture.

Recherche augmentée : l’embarras du choix

La recherche elle-même implique un enchaînement d’étapes plus ou moins obligatoires.

« N’oubliez pas de proposer une route de secours : si le système ne retrouve pas un document, les usagers veulent un point de contact, un courriel ou un moyen automatisé de rédiger un ticket. »

« Il y a certains choix faciles et d’autres plus difficiles. Parmi les options de facilité, il est possible de s’arrêter au R de RAG. L’on peut exploiter les vecteurs pour retrouver le document. C’est idéal quand il n’est pas nécessaire de commenter la réponse et c’est beaucoup moins cher », suggère Virginie Mathivet.

Si l’aspect génératif est important, le choix du LLM capable de formuler la réponse aurait peu d’impact. « Lorsque leur système RAG ne fonctionne pas bien, mes clients ont le réflexe de changer de LLM. Généralement, les problèmes se situent en amont », rappelle-t-elle. Un petit modèle de type Haiku chez Anthropic et un system prompt bien écrit (suffisamment précis sur les intentions) suffisent. « En revanche, n’oubliez pas de proposer une route de secours : si le système ne retrouve pas un document, les usagers veulent un point de contact, un courriel ou un moyen automatisé de rédiger un ticket », insiste-t-elle.

Dans tous les cas d’usage externes, les garde-fous pour éviter les requêtes mal intentionnées et l’exfiltration de documents sont nécessaires. Les fournisseurs proposent des options en la matière et il existe des modèles et des boîtes à outils open source.

Les choix plus difficiles concernent le classement des chunks pour formuler une réponse, ainsi que le type de recherche.

Au sujet du nombre de chunks nécessaires à classer pour formuler une réponse, Virginie Mathivet recommande de se limiter à 20 entrées au maximum. « Si vous en avez besoin de plus, c’est probablement qu’il faut revoir l’ingestion ». Il faut toutefois analyser les résultats pour déterminer le nombre idéal : souvent, trois à cinq chunks suffisent.

La recherche vectorielle (par comparaison de vecteurs) est efficace, mais pose des problèmes quand il est fait mention de références exactes dans une question, par exemple un produit ou une erreur. Dans ce cas-là, la recherche hybride qui combine la comparaison des vecteurs et la recherche plein texte dans les chunks est nécessaire. Les scores de confiance des deux mécanismes de recherche sont combinés pour classer les chunks.

« Plutôt que d’apprendre [aux usagers] à utiliser l’outil, adaptez-le. »

De manière plus générale, Virginie Mathivet considère selon son expérience que l’effort de re-ranking, de reclassement des réponses, n’est pas nécessaire si l’ingestion, le chunking et la vectorisation sont bien faits.

Quant à la réécriture des requêtes par un LLM, elle peut être utile lorsque les usagers se contentent d’une recherche par mot clé ou qu’ils formulent leurs questions de manière inattendue. « Plutôt que de leur apprendre à utiliser l’outil, adaptez-le », conseille-t-elle.

Lorsque les usagers formulent plusieurs demandes en une seule requête, un mécanisme de décomposition en plusieurs questions peut être utile. « Un LLM est utilisé pour diviser la demande en requêtes et pour rassembler les résultats. Cela coûte néanmoins plus cher », rappelle-t-elle.

Peu importe la pile technologique utilisée, Virgine Mathivet insiste sur trois conseils essentiels :

1. L’évaluation systématique de l’architecture RAG après chaque modification, afin d’en juger l’utilité et les performances.
2. La bonne sélection et la mise en qualité des documents.
3. Les échanges avec les métiers à propos du ou des cas d’usage ciblés.

« Vos choix techniques dépendent souvent de la bonne mise à jour des documents, ainsi que des types de requêtes (longues, courtes, par mot clé ou non) », conclut-elle.