IA générative : comment créer une architecture de RAG ?
Le RAG pour retrieval-augmented generation permet d'aligner la puissance des assistants intelligents et des moteurs de LLM (large Language model) sous-jacents sur les besoins de contextualisation des utilisateurs. Comme son nom l'indique, cette technologie repose sur deux briques : une couche de retrieval d'une part, une couche de génération de texte augmenté d'autre part. "La fusion des deux permet à un assistant d'aller glaner dans une base de connaissances spécifiques une information qui est ensuite enrichie par la couche générative", résume Ghiles Cherfaoui, tech lead data et data science au sein de l'ESN Inetum. "En aval, le prompt permettra de contrôler les résultats. Sont-ils plutôt formels, informels, créatifs... ?"
En amont, le Rag passe par un découpage des documents en sous-parties (ou chunks dans le vocabulaire du sérail). Des extraits qui sont ensuite vectorisés et stockés dans une base vectorielle. En aval, le mécanisme de retrieval compare le vecteur de la question posée par l'utilisateur avec ceux stockés dans la base de données.
Une vectorisation réalisée en amont
Principal avantage : la vectorisation des documents est réalisée en amont. "Ce qui optimise la performance du processus, car seule la question de l'utilisateur sera vectorisée à la volée. Ce n'est évidemment pas le cas si les documents sont fournis tels quels. Dans ce cas, ils devront être vectorisés a posteriori. Ce qui prendra du temps et coûtera de l'argent en termes de ressources machines consommées. Cela explique aussi pourquoi le tarif de l'embedding des LLM est en général plus élevé que le mode conversationnel", commente Didier Gaultier, head of AI au sein d'Orange Business. "Au final, le RAG glane tous les chunks vectoriellement proches de la question, puis les intègre dans le prompt conçu pour générer la réponse."
De la finesse des chunks dépendra la pertinence de la réponse. Plus le découpage des documents sera fin plus la réponse sera précise, et moins la masse de tokens supportés par le LLM devra être volumineuse en dernier lieu. "Il est donc important que le fichier initial soit bien conçu et bien découpé en parties et sous-parties structurées", insiste Didier Gaultier. De la qualité de ce travail dépendra la taille du buffer du modèle choisi. Le prix d'un modèle dépendant notamment de la taille de son buffer, cet aspect aura aussi un impact sur les coûts.
Une explosion des tokens
"On voit apparaître des modèles capables d'embarquer de plus en plus de tokens. Ce mouvement permet de facto d'augmenter le volume de chunks traités à la volée et par la même occasion d'accroître la taille du contexte soumis en entrée du LLM", commente Jean-François Gaudy, directeur de l'innovation chez Inetum. "En plus, la conversation avec l'assistant englobera le contexte de l'échange, ce qui engendrera une augmentation du volume de contenu et donc de tokens manipulés à chaque phase de question-réponse. Cela explique d'ailleurs en partie pourquoi on assiste à une course à l'échalote en termes de tokens. Claude 3 par exemple supporte actuellement 200 000 tokens, avec un objectif à terme d'en prendre en charge 1 million."
Pour constituer la base de connaissances d'un RAG, on pourra recourir à des technologies de reconnaissance automatique de caractères, voire de machine learning, de deep learning et de reinforcement learning. Derrière ces processus, l'objectif est de détecter les informations pertinentes dans des formats très divers, y compris celles contenues au sein de tableaux ou de graphiques.
"Bénéficier de bases documentaires et d'assistants bien définis permet de gérer efficacement les coûts"
Autre bonne pratique, il ne faudra pas hésiter à créer autant de bases documentaires que d'assistants. "Et ce, pour des raisons de performance, de temps de réponse, mais aussi de sécurité, chaque profil utilisateur ne devant avoir accès qu'à son domaine", martèle Didier Gaultier. Et Ghiles Cherfaoui d'ajouter "Dans cette logique, il est recommandé de définir des droits d'accès granulaires, à la fois sur les bases documentaires mais aussi au niveau de l'accès aux résultats du LLM en tant que tel."
Bénéficier de bases documentaires et d'assistants bien définis permet aussi de gérer efficacement le coût par assistant, aussi bien lors de l'ajout et de la vectorisation d'un document dans sa base documentaire que lors de l'utilisation de cette dernière pour réaliser les prompts.
Des chaînes de prompts
En aval, l'architecture de RAG peut passer par la gestion de chaînes de prompts s'emboitant les uns dans les autres. "Les moteurs de RAG permettent si besoin de dérouler plusieurs invites à la suite. Par exemple, on peut imaginer un dialogue avec des prompts qui vont venir interroger des contenus dans un progiciel SAP, récupérer des informations issues de ce dernier, puis les remettre en forme en vue de demander à l'utilisateur des précisions sur sa demande. En fonction de la réponse, on pourra ensuite recréer des prompts encore plus complexes et précis, en les enchaînant de manière conditionnelle", détaille Jean-François Gaudy. Objectif : réduire le taux d'hallucination du LLM en ajoutant des couches de contrôle.
Entre le Rag et la réponse de l'utilisateur, une chaîne de prompts permettra notamment d'éviter que le modèle confonde les chunks entre eux. "Ce qui peut arriver par exemple avec le code du travail qui contient des mots clés récurrents. Du coup, les chunks qui en sont issus seront de facto très proches les uns aux autres. Dans ce contexte, chaîner des prompts permettra d'aboutir à une réponse la plus précise possible", détaille Jean-François Gaudy. Idem pour générer des présentations PowerPoint. "Pour réaliser une telle tâche, vous allez passer par un enchainement de prompts sur la base d'un historique de documents. Une base à partir de laquelle le modèle va créer ses slideshows", explique Jean-François Gaudy. "Des invites vont générer des résumés de fichiers, d'autres créer un plan structuré. Ensuite, on lancera des prompts en boucle en demandant de réaliser un résumé des chapitres à aborder sous forme de points clés, etc."
En fonction du prompt généré, de la précision attendue, des contraintes d'optimisation en matière de nombre de tokens, on pourra par ailleurs réorienter le prompt vers tel ou tel LLM. Un routage qui pourra être géré par ailleurs en fonction du coût de l'utilisation des API et de la réactivité de la réponse. Au final, il est conseillé de développer des métriques pour jauger la performance du RAG. Avec un objectif : mesurer la précision de la réponse fournie par le LLM en se basant sur un score de pertinence.