Rendre le RAG prêt pour la production : surmonter les défis courants avec des solutions

Temps de lecture : 7 minutes

Suivez-nous : 

Les grands modèles de langage (LLM) ont déclenché une révolution dans la manière dont les utilisateurs interagissent avec du contenu et le génèrent, suscitant un intérêt significatif pour le Retrieval-Augmented Generation (RAG). Cette technologie permet aux utilisateurs de développer des applications telles que des chatbots, des outils de recherche de documents, des agents de flux de travail et des assistants conversationnels en utilisant des LLM avec leurs données propriétaires.

Bien que la configuration des systèmes de RAG de base soit simple, la transition vers un RAG à un niveau de production présente de nombreux défis. Les ingénieurs en IA sont confrontés à des paramètres et à des points de défaillance potentiels à chaque étape de développement, ce qui nécessite des solutions innovantes pour compléter leurs applications. Ce blog vise à explorer les défis et les solutions liés à la construction de systèmes de RAG prêts pour la production tout en fournissant un aperçu de l'évolution future de cette architecture.

Qu'est-ce que le Retrieval-Augmented Generation (RAG) et quelle est son importance ? 

Le Retrieval-Augmented Generation (RAG) est une méthode qui améliore les capacités des modèles de langage en les intégrant à des sources de données externes. Le stack de RAG se compose de deux composants principaux : l'analyse et l'injection de données, ainsi que l'interrogation de données.

1. Analyse et injection de données : cela implique le traitement de documents non structurés, le regroupement et l'intégration des données dans un système de stockage, généralement une base de données vectorielle. Des exemples de bases de données vectorielles incluent Pinecone, VVA et Chroma.

2. Requête de données : une fois les données stockées, elles peuvent être interrogées pour récupérer le contexte pertinent, qui est ensuite utilisé dans les prompts pour synthétiser les réponses. Ce processus permet aux LLM de générer des réponses précises sur des données spécifiques 

Le développeur peut récupérer des informations à partir d'une base de données existante, intégrer ce contexte dans des prompts spécifiques et générer une réponse synthétisée. Ce processus permet au développeur de créer rapidement une version de base d'une expérience de recherche ou de ChatGPT en utilisant vos données.

Les défis de l'industrialisation  

Bien qu'il soit relativement simple de prototyper un pipeline de RAG de base, sa mise à l'échelle pour une utilisation en production est un défi. Si vous disposez d'un document contenant 10 000 mots ou d'un rapport annuel, vous recherchez essentiellement des informations spécifiques dans cette vaste base de connaissances. Dans de tels cas, un simple RAG fonctionne assez efficacement, mais il échoue souvent lorsqu'il s'agit de requêtes plus complexes ou de volumes de données plus importants. Les défis comprennent :

• Gestion des questions en plusieurs parties : des requêtes plus complexes peuvent nécessiter la combinaison d'informations provenant de plusieurs sources.

• Évolutivité : à mesure que le nombre de documents augmente, les performances ont tendance à se dégrader.

• Réglage des paramètres : il existe de nombreux paramètres dans le pipeline de RAG, chacun affectant les performances globales du système.

Logiciels traditionnels VS Logiciels basés sur l'IA générative 

Deux défis fondamentaux apparaissent lorsque l'utilisateur souhaite améliorer les performances d'un système basé sur l'IA : des performances médiocres et un manque de clarté sur la manière d'améliorer le système. Ce scénario souligne la nature complexe de l’optimisation des paramètres.

Dans le domaine de IA, l’abondance de paramètres tout au long du processus de développement peut être stupéfiante. Du réglage fin des modèles LLM à la configuration des hyperparamètres, les développeurs sont confrontés à une tâche ardue consistant à naviguer dans un labyrinthe de variables pour maximiser la précision de leurs systèmes.

Pour comprendre les difficultés liées à l'optimisation des pipelines de RAG, il est essentiel de comparer le développement logiciel traditionnel avec le développement logiciel basé sur l'IA :

• Logiciel traditionnel : défini par des règles de programmation, le résultat attendu peut être raisonné relativement facilement. Comme nous connaissons le fonctionnement interne du programme, nous pouvons facilement vérifier quelle entrée générera quelle sortie. Bien que des cas extrêmes existent, ils peuvent être identifiés et gérés via des essais à sec.

• Logiciel basé sur l'IA : un modèle d'IA fonctionne souvent comme une boîte noire car son fonctionnement interne est opaque. Même si les logiciels ne doivent pas nécessairement s'appuyer entièrement sur les LLM, leur présence dans le pipeline transforme l'ensemble du système en une boîte noire. Par conséquent, nous ne pouvons pas prédire comment les modifications des paramètres ou des hyperparamètres affecteront le résultat.

Les complexités du réglage des paramètres deviennent plus évidentes dans le développement de logiciels basés sur l’IA. Par exemple, l'utilisation d'un LLM pour la génération de texte implique des données pré-entraînées, mais les résultats sont imprévisibles et agissent comme une boîte noire. Chaque nouveau paramètre ajoute à la complexité du système et a un impact imprévisible sur les performances.

Un modèle d’IA est essentiellement une boîte noire définie par ses paramètres, difficiles à visualiser dans des espaces de grande dimension. Alors que la descente de gradient optimise les paramètres du modèle, les paramètres environnants dans un paramètre d'inférence restent désaccordés. À l'aide d'un LLM, le modèle de prompt est un hyperparamètre qui n'a pas été réglé.

Dans les systèmes basés sur l’IA, comme le modèle d’IA est une boîte noire, le système dans son ensemble ne fait plus qu’un. Par exemple, les paramètres opaques d'un LLM, combinés à des paramètres supplémentaires dans un système complexe tel qu'un pipeline de RAG, créent une boîte noire plus grande, ce qui rend difficile la compréhension de l'impact de chaque paramètre sur les performances globales. Même des paramètres simples comme la taille des chunks ajoutent à cette complexité.

Défis du RAG et solutions :

• Points de douleur courants dans les pipelines de RAG

En temps normal, un développeur écrit du code et peut prédire ce que fera le programme. Dans le cas du LLM, c'est plutôt une boîte noire. Les développeurs entraînent le modèle sur les données, mais la manière dont celui-ci parvient à une réponse peut rester un mystère. Cela devient encore plus délicat lorsque nous combinons des modèles d’IA avec d’autres composants logiciels.

Alors, comment pouvons-nous créer des logiciels fiables avec ces mystérieux composants d’IA ? La bonne nouvelle est que des solutions sont en cours d’élaboration. Une approche consiste à identifier les défis courants, ou « points de douleur », auxquels les développeurs sont confrontés lorsqu'ils construisent avec l'IA. De nombreux problèmes auxquels les utilisateurs sont confrontés lors de la création de RAG peuvent être considérés comme liés à la qualité des réponses. Fondamentalement, de nombreux problèmes se résument au fait que l'utilisateur pose une question et ne reçoit pas le résultat. En comprenant ces défis, les experts peuvent proposer les meilleures pratiques pour rendre le processus plus fluide. Voici quelques défis auxquels vous pourriez être confronté :

1. Contexte manquant dans la base de connaissances : Parfois, les données nécessaires pour répondre à une requête ne sont pas disponibles ou sont mal formatées. Les solutions incluent l'utilisation d'analyseurs de documents de haute qualité et l'ajout de métadonnées pertinentes à des morceaux de texte pour améliorer la compréhension du modèle d'embeddings.

2. Contexte manquant lors de la phase de récupération initiale : si le contexte pertinent n'est pas récupéré, cela peut être dû à des hyperparamètres mal réglés comme la valeur top K (la taille de la fenêtre de contexte). L'augmentation temporaire de la valeur top K peut aider au débogage si le contexte est récupéré. De plus, le reclassement des résultats récupérés peut améliorer la précision.

3. Contexte manquant après le reclassement : il existe également des cas où, même après une récupération dense, le reclassement peut toujours ne pas restituer le contexte pertinent. Dans de tels cas, il est important d’utiliser des méthodes de récupération sophistiquées, dont certaines sont propres aux LLM.

4. Contexte non extrait : cette limitation est mise en évidence dans les expériences « une aiguille dans une botte de foin », où des faits aléatoires sont injectés dans des prompts, ce qui rend difficile pour le LLM de discerner les informations pertinentes.

5. La sortie est dans un mauvais format : une préoccupation courante lors de la création d'applications de Retrieval-Augmented Generation (RAG) et de grands modèles de langage (LLM) est le format de sortie, en particulier l'attente d'une sortie JSON structurée.

6. Le résultat est incomplet : lorsqu’il s’agit de questions complexes en plusieurs parties, les limites du simple Retrieval-Augmented Generation (RAG) deviennent évidentes. Bien qu’un simple RAG soit efficace pour répondre à des questions simples sur des faits spécifiques, elle échoue souvent lorsqu’elle est confrontée à des demandes en plusieurs parties. Dans de tels cas, même avec l’approche de RAG top K, le contexte récupéré peut être insuffisant pour répondre pleinement à la question posée.

7. Traitement de documents complexes : le traitement de documents complexes tels que des PDF contenant des tableaux ou des graphiques intégrés nécessite des analyseurs spécialisés. Garantir les bonnes stratégies d’analyse et de segmentation peut avoir un impact significatif sur les performances du pipeline de RAG.

8. Optimisation pour différents types de requêtes : différents types de requêtes peuvent nécessiter différentes stratégies de récupération. Par exemple, la gestion des données tabulaires peut nécessiter une approche différente de celle du texte non structuré.

9. Gestion des données à grande échelle : à mesure que le volume de données augmente, il devient essentiel de garantir une récupération et un traitement efficaces. Cela peut impliquer des systèmes distribués et des algorithmes de récupération plus sophistiqués.

• Solutions et meilleures pratiques

À mesure que le pipeline de RAG évolue, certaines des techniques avancées et des meilleures pratiques ont été identifiées pour résoudre efficacement ces problèmes :

1. Enrichissement des métadonnées : l'ajout de métadonnées à des chunks de texte aide le modèle d'embedding et le LLM à mieux comprendre le contexte. Cela inclut des annotations sur l'origine du document, sa pertinence et d'autres informations pertinentes.

2. Gardez vos données à jour : en production, les sources de données sont fréquemment mises à jour. Il est important de mettre en place un pipeline d’ingestion de données récurrent afin que nous puissions traiter correctement les nouvelles mises à jour au fil du temps. Upsert (Mettre à jour et insérer) des documents pour éviter les doublons.

3. Stratégies de récupération adaptatives : la mise en œuvre de stratégies de récupération avancées qui vont au-delà de la simple récupération de K peut améliorer les performances. Par exemple, nous pouvons découpler les chunks utilisés pour l'embedding des chunks utilisés pour le LLM et utiliser le LLM pour effectuer la planification des requêtes. D'autres méthodes de récupération peuvent inclure des méthodes de petite à grande taille, de fusion automatique, de récupération automatique et d'assemblage.

4. Planification et raisonnement des requêtes : l'utilisation du LLM pour la planification et le raisonnement des requêtes permet d'utiliser des méthodes de récupération plus sophistiquées, exploitant la capacité du modèle à comprendre et à traiter des requêtes complexes.

5. Ajuster les modèles d'embedding aux données spécifiques à une tâche : envisagez d'affiner un modèle lorsque nous disposons d'un set d'entraînements important, particulièrement pertinent pour les entreprises qui ont du mal à récupérer les résultats de vastes référentiels de données spécifiques à un domaine.

6. Compression des prompts et réorganisation du contexte : la compression des prompts vise à condenser le contexte afin de réduire le coût et la latence des tokens tout en maintenant la qualité de la récupération. La réorganisation du contexte implique de classer les éléments de contexte par pertinence, garantissant ainsi que les informations les plus pertinentes sont priorisées pour de meilleures performances du modèle.

7. Ajouter un raisonnement agentique : il existe un intérêt croissant pour l'amélioration des approches de Retrieval-Augmented Generation (RAG) avec des capacités de raisonnement agentique. Cela vise à aborder des questions complexes en les décomposant en parties plus petites, facilitant ainsi la résolution de tâches plus longues et de problèmes de recherche ambigus. Cela nécessite l'intégration de divers composants, de la planification et de l'exécution des requêtes à l'utilisation d'outils et d'autres sources de données.

8. Évaluation et commentaires continus : l'évaluation régulière du pipeline de RAG avec un ensemble de requêtes de référence et la mise à jour des paramètres en fonction des commentaires permettent de maintenir les performances. Cela inclut l'ajustement de la taille des chunks de données d'entrée, les méthodes de récupération et les algorithmes de reclassement.

9. Solutions d'évolutivité : la mise en œuvre de systèmes distribués et la garantie de pipelines de traitement de données efficaces sont essentielles pour gérer des données à grande échelle. Des techniques telles que le partitionnement et le traitement parallèle peuvent être utilisées.

Conclusion

Construire des pipelines de RAG prêts pour la production est un voyage complexe mais enrichissant. En comprenant et en résolvant les problèmes courants, les développeurs peuvent créer des systèmes robustes et efficaces, capables de gérer un large éventail de requêtes et de types de données.

À l’avenir, ces modèles sont sur le point de devenir plus agentiques, évoluant au-delà de leurs capacités actuelles. Les grands modèles de langage (LLM) passeront d'un raisonnement ponctuel à l'exécution de séquences d'actions répétées. Ils sauront gérer efficacement les problèmes complexes, mener des opérations de recherche et de récupération et prendre des mesures proactives au nom de l'utilisateur.

L'innovation continue et les meilleures pratiques dans le domaine amélioreront encore les capacités et les performances des pipelines de RAG, ouvrant la voie à des applications d'IA générative plus sophistiquées et intelligentes.

Pour en savoir plus, réservez un appel maintenant!

Sources:

https://arxiv.org/pdf/2401.05856, https://www.youtube.com/watch?v=pRhXoEXhWAM