Considérations pratiques dans la conception d’application RAG

Préoccupations pratiques dans la conception de l'application RAG

Ceci est la deuxième partie de l’analyse RAG:

• partie 1: Inconvénients de RAG
• partie 2: Considérations pratiques dans la conception d’une application RAG

L’architecture RAG (Retrieval Augmented Generation) a prouvé son efficacité pour surmonter la limite de longueur d’entrée LLM et le problème de coupure de connaissance. Dans la pile technique LLM d’aujourd’hui, RAG fait partie des fondements pour ancrer l’application sur une connaissance locale, atténuer les hallucinations et rendre les applications LLM auditables. Il existe de nombreux exemples de la façon de construire une application RAG. Et il existe également différents types de bases de données vectorielles.

Beaucoup de personnes ont remarqué que, malgré le fait que les applications RAG soient faciles à démontrer, elles sont difficiles à mettre en production. Dans cet article, examinons quelques détails pratiques du développement d’une application RAG.

Ordre du jour

• Examiner l’impact du boom de l’IA sur les services cloud
• Exploiter les super pouvoirs du TPN un tutoriel étape par étape sur l’affinage Hugging Face
• De 2D à 3D Améliorer la cohérence de génération de texte en 3D avec des présomptions géométriques alignées

· Le niveau de base parfait LLM· Attentes de performance de RAG· Préservation de l’information· Forces et faiblesses de RAG· Vers une meilleure application RAG ∘ Traitez votre LLM ∘ Maintenir le modèle d’incorporation sur la même page ∘ La stratégie de fragmentation compte ∘ Réduire la perte d’information ∘ LLM Empathy· Mots de clôture· Références

Le niveau de base parfait LLM

Supposons que nous disposions d’un LLM génératif avec une longueur d’entrée illimitée, la longueur de la chaîne d’entrée n’a aucune incidence sur l’exactitude du LLM génératif. Mis à part cela, il se comporte exactement comme tous les autres LLM populaires. Appelons ce modèle le LLM parfait. Nous le considérons comme parfait, non pas parce qu’il a d’excellentes performances, mais parce qu’il possède la longueur d’entrée illimitée souhaitée, impossible à obtenir aujourd’hui. La longueur d’entrée illimitée est vraiment une fonctionnalité attrayante à avoir. En fait, quelques projets ambitieux travaillent déjà sur des LLM à entrée incroyablement longue. L’un d’entre eux étudie la possibilité d’un LLM avec 1 million de jetons d’entrée! Cependant, je crains même que la limite de 1 million de jetons ne suffise pas encore dans l’application car elle équivaut seulement à 4-5 Mo. C’est encore plus petit qu’un grand nombre de documents dans le monde de l’entreprise réelle.

Maintenant, la question est la suivante: lorsque vous disposez d’un tel LLM parfait, envisageriez-vous toujours l’architecture RAG? Le LLM parfait avec une longueur d’entrée illimitée réduit la nécessité de construire un RAG compliqué. Cependant, probablement oui, vous devez toujours envisager l’architecture RAG. L’architecture RAG aide non seulement à surmonter la limite de longueur d’entrée LLM, mais réduit également les coûts d’invocation LLM et améliore la vitesse de traitement. Les LLM génératifs doivent traiter le contenu en séquence. Plus l’entrée est longue, plus c’est lent.

Lorsque nous concevons une application RAG, nous devons utiliser le LLM parfait présumé comme référence pour scruter l’application RAG, afin d’avoir une vue claire des avantages et des inconvénients de RAG et trouver des moyens d’améliorer nos applications RAG.

Attentes de performance RAG

Avec le modèle de référence, l’entrée de l’application d’IA générative est directement alimentée dans le LLM en une seule fois. Ainsi, le LLM a l’opportunité de digérer toutes les informations du texte d’entrée. L’exactitude du résultat final dépend uniquement de la performance du LLM génératif.

Pour une application RAG standard, il y a deux autres composants qui influencent les performances finales : la méthode de recherche sémantique et la mise en œuvre de RAG. L’architecture RAG utilise un modèle d’incorporation pour générer des vecteurs de connaissances réelles et de la requête. Ensuite, utilisez la fonction de similarité de vecteur pour récupérer le contenu le plus pertinent. La capacité du modèle d’incorporation à extraire le sens du texte est très critique. Outre le modèle d’incorporation, il existe de nombreux détails de mise en œuvre dans le développement de RAG, qui influencent également grandement le résultat final. Par conséquent, l’exactitude de la sortie RAG serait égale au produit de l’exactitude du LLM génératif, de l’exactitude de la recherche sémantique et du taux de préservation des informations RAG. Je vais expliquer plus tard le concept du taux de préservation des informations RAG.

Parce que les trois facteurs sont inférieurs à 100%, l’exactitude attendue d’une application RAG est inférieure à celle d’une application basée sur le même modèle LLM parfait. Si le RAG n’est pas conçu correctement, ses performances chutent très significativement. C’est le premier concept à garder à l’esprit lorsque nous commençons à réfléchir à la conception de notre application RAG. Sinon, les performances inattendues nous surprendront.

Étant donné que la performance finale est influencée par ces trois facteurs, la conception de l’application RAG doit également se concentrer sur ces trois composants pour obtenir un résultat satisfaisant.

Préservation des informations

Il est facile de comprendre que le modèle LLM et la recherche sémantique ne peuvent pas atteindre une précision de 100%. Permettez-moi d’expliquer ce qu’est le taux de préservation des informations RAG.

Le corpus de texte que nous alimentons dans l’application peut contenir des informations très riches. Jetons un coup d’œil à ce qui se trouve dans le corpus et comment les informations sont transmises au LLM :

Le graphique représente les relations d’entité dans le corpus de texte. Les entités sont réparties dans tout le corpus, et les relations de référence sont également présentes partout. Après le regroupement, les entités sont contraintes dans chaque silo, et les relations entre les groupes sont toutes coupées. Dans la phase de recherche, seuls les k meilleurs groupes ont la possibilité d’être envoyés à travers le LLM. Cela signifie que seule une partie des entités et des relations peuvent être transmises au LLM. Le LLM aura des difficultés s’il nécessite une connaissance approfondie des relations pour répondre à la requête.

En plus des relations d’entité, l’opération de regroupement aura également un impact sur divers autres types d’informations dans l’entrée :

1. Informations contextuelles :

Dans la plupart des cas, le texte contient plusieurs couches d’informations contextuelles. Par exemple, le livre “The Elements of Statistical Learning” comporte 18 chapitres, chacun se concentrant sur un sujet unique. Il y a des sous-thèmes et des sous-thèmes de deuxième niveau dans chaque chapitre, etc. Les gens ont l’habitude de comprendre le texte dans son contexte. La stratégie de regroupement rend le contenu déconnecté de son contexte.

2. Informations de position :

Les textes ont des poids différents en fonction de leur position dans le document. Les textes au début et à la fin d’un document sont plus importants que ceux du milieu. Ils sont plus importants lorsqu’ils se trouvent au début ou à la fin d’un chapitre que lorsqu’ils se trouvent au milieu d’un chapitre.

3. informations séquentielles :

Le texte naturel utilise fréquemment des liens linguistiques explicites et implicites pour connecter les sujets. Par exemple, une histoire peut commencer par « au début », puis continuer avec « ensuite », « donc », « après cela », jusqu’à ce qu’elle se termine par « finalement », « enfin », etc. Avec la stratégie de découpage en blocs, ce type de connexion n’est plus complet. Non seulement les pièces du puzzle manquent, mais l’ordre de séquence est également mélangé.

4. informations descriptives :

Cela concerne les informations décrivant un seul sujet. Avec le découpage en blocs, les informations descriptives ne sont pas garanties d’être regroupées. Imaginez que vous êtes en plein milieu d’un appel téléphonique et que soudainement la ligne est coupée. Cela dépend de l’importance de votre appel et du moment où cela s’est produit, l’impact peut varier du banal à très frustrant.

Points forts et faiblesses de RAG

Si nous appelons RAGs utilisant uniquement le découpage en blocs et la recherche de similarité vectorielle “RAGs vanille”, nous pouvons voir qu’ils peuvent seulement gérer quelques types de requêtes car ils perdent certaines des informations d’entrée dont nous avons parlé plus tôt :

1. Bonne capacité à répondre à des questions descriptives à portée étroite. Par exemple, quel sujet possède certaines caractéristiques ?

2. Pas bon pour le raisonnement relationnel, c’est-à-dire trouver un chemin d’une entité A à une entité B ou identifier des cliques d’entités.

3. Pas bon pour la synthèse à longue portée. Par exemple, “Listez tous les combats de Harry Potter” ou “Combien de combats Harry Potter a-t-il ?”.

Les applications RAG ont de mauvaises performances pour ce type de tâches car seulement quelques blocs peuvent être alimentés dans le LLM et ces blocs sont dispersés. Il serait impossible pour le LLM de collecter les informations nécessaires pour commencer.

Les applications RAG sont principalement équipées d’un LLM génératif, ce qui donne aux utilisateurs l’impression que l’application RAG doit avoir une capacité de raisonnement de haut niveau similaire à celle de l’application LLM parfaite. Cependant, parce que le LLM dispose d’une entrée insuffisante par rapport au modèle parfait, les applications RAG n’ont pas le même niveau de puissance de raisonnement. La prise de conscience des limites des informations d’entrée peut nous aider à comprendre ce que RAG peut et ne peut pas faire. Nous devrions rechercher le domaine le plus adapté pour RAG et éviter de le forcer là où il ne convient pas.

Vers une meilleure application RAG

Après avoir discuté des limites de l’application RAG, voyons comment nous pouvons améliorer ses performances.

Traiter votre LLM

Très souvent, lorsque nous traitons la requête d’entrée, nous acceptons simplement ce que l’utilisateur envoie. Ce n’est pas idéal, non seulement à cause des risques de sécurité tels que la divulgation et l’injection de requêtes, mais aussi parce que les performances peuvent être décevantes.

D’après les chercheurs, les LLM sont sensibles aux fautes de frappe et aux différences de formulation dans la requête [1]. Pour vous assurer que les LLM fonctionnent à leur meilleur niveau de performance, envisagez de corriger toutes les fautes de frappe et de reformuler l’entrée de manière plus facile à suivre pour les LLM.

Garder le modèle d’encodage sur la même page

Dans la plupart des cas, l’utilisateur envoie des requêtes courtes, comme « Parlez-moi plus de Tony Abbott ». Ensuite, la requête est convertie en un vecteur d’encodage, qui capture l’essence de cette requête spécifique. Effectuer une recherche sémantique avec une requête directe peut être difficile car :

1. Les requêtes de l’utilisateur sont courtes et sous forme de questions. Elles contiennent des caractéristiques sémantiques limitées. Alors que les encodages des documents sont longs, sous forme de diverses formes d’affirmations, les encodages des documents contiennent des informations beaucoup plus riches dans leurs vecteurs.
2. En raison des caractéristiques sémantiques limitées dans la requête de l’utilisateur, la fonction de recherche sémantique est susceptible de surinterpréter des détails triviaux dans la requête. L’encodage des documents peut contenir un niveau élevé de bruit. Le découpage en blocs aggrave la situation car de nombreuses relations, contextes et liens séquentiels sont absents.
3. Les modèles d’encodage et les LLM génératifs appartiennent à des familles différentes. Ils sont formés différemment et leur comportement est différent. Les modèles d’encodage n’ont pas le même niveau de capacité de raisonnement que les LLM génératifs. Ils ne tiennent même pas autant compte des détails linguistiques que les LLM génératifs. Interroger directement avec une saisie utilisateur, dans le pire des cas, fera régresser la fonction de recherche sémantique vers une recherche par mot-clé.
4. Étant donné que les modèles d’encodage et les LLM génératifs sont deux modèles différents qui jouent des rôles différents dans l’ensemble du processus, ils ne sont pas sur la même longueur d’onde. Les deux modèles effectuent leur part du travail en fonction de leur compréhension de ce qui est requis, mais ils ne communiquent pas entre eux. Les informations récupérées peuvent ne pas être ce dont le LLM a besoin pour produire le meilleur résultat. Ces deux modèles n’ont pas de moyen de s’aligner mutuellement.

Pour éviter ce problème, vous voulez probablement utiliser un LLM génératif pour d’abord augmenter les requêtes des utilisateurs. Considérez l’exemple suivant :

Requête initiale de l’utilisateur : Parle-moi de Tony Abbott.

Et les requêtes augmentées qui ont été reformulées en fonction de la requête initiale à l’aide de Bard : – Quel est le parcours politique de Tony Abbott ?

– Quelles sont les réalisations les plus remarquables de Tony Abbott ?

– Quelles sont les opinions politiques de Tony Abbott ?

– Quels sont les intérêts personnels de Tony Abbott ?

– Quelles sont certaines des controverses dans lesquelles Tony Abbott a été impliqué ?

Pouvez-vous constater l’amélioration de la richesse d’information ? Les requêtes augmentées offrent plus de fonctionnalités, ce qui produit donc un meilleur résultat de recherche. De plus, en envoyant les requêtes augmentées, le LLM a l’occasion de dire au modèle d’incorporation ce dont il a besoin, et le modèle d’incorporation peut fournir des fragments de meilleure qualité au LLM. C’est ainsi que les deux modèles peuvent travailler ensemble.

La stratégie de segmentation des fragments est importante

La taille des fragments est l’un des quelques super-paramètres que nous pouvons régler pour une application RAG. Pour obtenir de meilleurs résultats, il est recommandé d’utiliser des tailles de fragments plus petites. Une telle analyse a été effectuée par Microsoft [2]:

Lors de la segmentation du texte, nous pouvons également choisir différentes stratégies de découpage. La façon la plus simple consiste à couper au niveau de la rupture d’un mot. Nous pouvons également essayer différentes stratégies, comme couper au niveau de la rupture d’une phrase ou d’un paragraphe. Et pour obtenir un résultat encore meilleur, nous pouvons chevaucher les fragments adjacents. La comparaison des stratégies de segmentation dans l’analyse de Microsoft [2]:

Les modèles d’incorporation ont un pouvoir limité d’extraction sémantique. Ils sont moins efficaces pour présenter des corpus à plusieurs sujets et à plusieurs tours que les modèles simples. C’est pourquoi le RAG préfère les fragments plus courts. Quelle taille de fragment est donc la meilleure ? Dans l’analyse de Microsoft, la plus petite taille de fragment était de 512 jetons. Elle doit avoir été inspirée par la constatation que les fragments plus petits fonctionnent mieux ; la taille des fragments dans certaines applications RAG commerciales était seulement d’environ 100 jetons. Est-ce que la plus petite taille de fragment permet toujours d’obtenir de meilleurs résultats ?

Comme discuté précédemment, la stratégie de segmentation va découper les corpus de texte en petits morceaux, entraînant une perte d’informations. Plus la taille du fragment est petite, plus il y aura de perte d’informations. Il existe donc une taille de fragment optimale. Des fragments trop petits peuvent ne pas être idéaux. Cependant, chercher la taille de fragment optimale revient à régler un super-paramètre. Vous devez expérimenter avec vos données.

Réduire la perte d’informations

L’analyse de Microsoft a montré que la segmentation avec un chevauchement important améliore la précision. Pourquoi cela aide-t-il et pouvons-nous trouver un meilleur moyen d’améliorer les performances du RAG ?

La raison derrière le chevauchement était que celui-ci peut aider à relier les fragments adjacents et fournir de meilleures informations contextuelles pour le fragment. Cependant, même un chevauchement très agressif de 25% ne peut améliorer la précision que de 1,5%, passant de 42,4% à 43,9%. Cela signifie que ce n’est pas la manière la plus efficace d’optimiser les performances du RAG. Nous ne pouvons pas améliorer davantage les performances du RAG en chevauchant davantage. Rappelez-vous que la segmentation avec chevauchement n’est même pas une option pour les fragments plus petits.

Comme la stratégie de segmentation avec chevauchement l’a prouvé, conserver les informations peut aider le LLM à fournir de meilleures réponses. Comment pouvons-nous conserver autant que possible les informations d’entrée ?

La stratégie de découpage par chevauchement espérait simplement que les dernières phrases du fragment précédent pourraient fournir davantage d’informations contextuelles. Et comme nous pouvons le comprendre, les dernières phrases peuvent ne pas être très représentatives. Nous pouvons probablement utiliser un résumé généré par LLM du fragment précédent au lieu du chevauchement.

Et n’oubliez pas que le texte d’entrée contient plusieurs couches d’informations contextuelles. Si c’est le cas pour votre application, vous voudrez peut-être ajouter les informations contextuelles en couches au fragment également. Ou une manière plus efficace pourrait être de stocker les informations contextuelles en tant que métadonnées.

RAG avec Knowledge Graph est une tendance actuelle. Avec l’aide des graphes de connaissances, RAG peut stocker les relations dans la base de données graphique. La connexion entre les fragments peut être entièrement préservée. C’est une solution très judicieuse si le raisonnement sur les relations est essentiel pour votre projet.

Cependant, RAG avec Knowledge Graph ne présente pas que des avantages. La création d’un graphe de connaissances à partir d’un texte non structuré n’est pas simple. Il existe de nombreuses expérimentations sur l’extraction de triplets d’entités et de relations à partir d’entrées textuelles. C’est une autre histoire lorsque vous devez mettre en production la solution. Les entités et les relations extraites automatiquement peuvent contenir beaucoup de bruit et omettre trop d’informations réelles. Vous devez inspecter attentivement la qualité de la sortie. Même après la création du graphe de connaissances, les requêtes prises en charge sont étroitement liées à la conception de la base de données graphique.

Moins brillante que RAG avec Knowledge Graph, la base de données relationnelle avec recherche vectorielle est également un composant très important de la boîte à outils. Une base de données comme pgvector vous permet de stocker des informations sophistiquées sous forme de colonnes tout en conservant les fonctions de recherche sémantique. Elle est bien plus facile à intégrer avec d’autres systèmes d’entreprise et bien plus flexible qu’un graphe de connaissances.

Toutes ces options sont valables à considérer. La seule mise en garde est que de nombreuses bases de données graphiques, moteurs de recherche et bases de données relationnelles avec recherche vectorielle ne sont pas entièrement optimisés en tant que bases de données vectorielles. Leur vitesse lors du traitement d’indexation vectorielle massivement évolutive peut ne pas être idéale, surtout lorsqu’ils doivent mettre souvent à jour l’index. Veuillez consulter [3] pour plus de détails sur l’introduction aux différents types de bases de données vectorielles.

Empathie LLM

Parfois, nous constatons que RAG ne répond pas très bien à nos questions. Au lieu de tout régler pour améliorer ses performances, nous devrions probablement prendre en compte les questions suivantes :

• L’LLM dispose-t-il de toutes les informations dont il a besoin ?
• Les informations sont-elles organisées de manière conviviale pour l’LLM ?

Prenons en considération l’exemple suivant :

Nous construisons une application RAG sur un site SharePoint. L’une des pages concerne tous les projets et leurs membres d’équipe, y compris les profils de toutes les personnes. Nous devons nous assurer que RAG répond aux questions sur les projets par rapport aux membres de l’équipe avec précision ; cependant, le résultat initial était très décevant.

L’enquête initiale a montré que le site SharePoint n’organise pas les contenus de manière suffisamment structurée pour que l’affiliation des informations puisse être aisément comprise. Après avoir supprimé toutes les balises HTML, le contenu de la page Web ressemble à ce qui suit :

Projet AContact du client : SteveMembres de l'équipe :personne Apersonne Bemail de la personne Aemail de la personne Brôle de la personne Arôle de la personne Bdescription de la personne Adescription de la personne Bprojet B...

Si les humains ont du mal à comprendre qui est qui, RAG aussi a des difficultés. Pour mieux organiser les informations, nous avons utilisé du code Python pour regrouper les informations ensemble en fonction des propriétés HTML, séparé chaque projet et les noms des membres de l’équipe dans un seul fichier texte, et placé les informations de chaque personne dans son propre fichier :

fichier project_A.txt :nom du projet : project_AContact du client : SteveMembres de l'équipe :Adam SmithJobs Muskfichier person_A.txt :nom : Adam Smithemail : [email protected]ôle : ingénieuredescription : Hobbies/passion : escalade...

Les fichiers texte générés sont minuscules, ce qui semble ne pas correspondre à la pratique de découpage de RAG. La raison en est que les fichiers très concentrés évitent le problème de division et réduisent complètement le bruit. Avec les nouveaux fichiers générés, RAG n’a aucun problème pour répondre aux questions telles que “qui travaille sur le projet x ?” et “quel est le passe-temps d’adam smith ?”.

Cependant, RAG a eu du mal lorsque nous avons inversé la question : “Sur quel projet Adam Smith travaille-t-il ?” Nous avons vu Adam Smith figurant parmi les membres du projet. Nous ne savons pas très bien pourquoi le modèle d’encodage ne peut pas le détecter. Pour aider l’LLM à faire le travail, nous pouvons mettre en évidence les informations. Nous avons ajouté une ligne dans le fichier de la personne qui indique explicitement l’engagement dans le projet :

fichier person_A.txt :nom : Adam Smithemail : [email protected]ôle : ingénieuredescription : Hobbies/passion : escaladeprojet : project_A

Et cette ligne supplémentaire fait que l’application RAG est capable de répondre aux questions ci-dessus avec une précision de 100%.

Mots de conclusion

RAG, en tant que technologie émergente, évolue rapidement. J’ai constaté que cela m’a beaucoup aidé lorsque j’ai étudié ses éléments constitutifs morceau par morceau. En examinant les détails, je peux avoir une compréhension plus approfondie des avantages et des inconvénients de la technologie et développer une idée de l’importance d’une nouvelle proposition. Il existe quelques frameworks très populaires qui aident les gens à développer des applications RAG. J’ai trouvé certaines idées d’exécution inspirantes ; cependant, je ne recommande pas de commencer à apprendre ou à développer votre RAG uniquement parce que c’est facile à commencer.

Si vous avez suivi cet article jusqu’ici, vous devez être d’accord pour dire que RAG est une architecture compliquée. Les frameworks populaires ont enveloppé tous les détails, ce qui a fait penser aux gens que ces détails n’étaient pas importants. Ma suggestion est d’apprendre RAG avec une réalisation minimale et de considérer ensuite des fonctionnalités supplémentaires. Ainsi, vous saurez les bases et l’impact de chaque partie en mouvement. Il n’est pas si difficile de commencer avec un RAG aussi minimal et d’analyser son fonctionnement. Veuillez consulter mon article, Inconvénients de RAG.

Références

Robustesse de la proposition : comment mesurer et comment améliorer

Discussion sur la robustesse de la proposition LLM, la mesure, l’amélioration et l’utilisation de PromptBench.

pub.towardsai.net

Azure Cognitive Search : Dépasser la recherche vectorielle avec des capacités de recherche et de classement hybrides

Comment trouvez-vous le meilleur contenu pour alimenter vos modèles d’IA générative ? Dans cet article de blog, nous vous montrons comment utiliser Azure…

techcommunity.microsoft.com

Ce que nous devons savoir avant d’adopter une base de données vectorielle

Pour continuer notre démarche vers une IA générative applicable, j’aimerais discuter de certains des défis…

VoAGI.com

Inconvénients de RAG

Récemment, la montée en puissance des grands modèles de langage (LLMs) a suscité beaucoup d’intérêt pour les systèmes RAG. De nombreux praticiens…

VoAGI.com

We will continue to update IPGirl; if you have any questions or suggestions, please contact us!