Qu’est-ce que la génération augmentée par récupération (RAG) ?

Résumé

• Apprenez comment la génération augmentée par récupération (RAG) fonctionne en combinant de grands modèles linguistiques (LLMs) avec des données externes en temps réel pour des sorties plus précises et pertinentes.
• Voyez comment RAG résout des problèmes spécifiques, tels que la réduction des hallucinations et la fourniture de réponses spécifiques à un domaine, le tout sans réentraînement coûteux.
• Explorez des cas d'utilisation réels pour RAG et les tendances futures dans des industries comme le support client, la conformité et la recherche d'entreprise.

Qu'est-ce que la génération augmentée de récupération, ou RAG ?

La génération augmentée par récupération (RAG) est un cadre d'IA hybride qui renforce les grands modèles de langage (LLMs) en les combinant avec des sources de données externes et à jour. Au lieu de se fier uniquement aux données d'entraînement statiques, RAG récupère des documents pertinents au moment de la requête et les intègre au modèle comme contexte. En incorporant des données nouvelles et conscientes du contexte, l'IA peut générer des réponses plus précises, actuelles et spécifiques à un domaine.

RAG devient rapidement l'architecture de prédilection pour la construction d'applications IA de niveau entreprise. Selon des enquêtes récentes, plus de 60% des organisations développent des outils de recherche alimentés par l'IA pour améliorer la fiabilité, réduire les hallucinations et personnaliser les résultats à l'aide de données internes.

Au fur et à mesure que l'IA générative se déploie dans les fonctions commerciales comme le service client, la gestion des connaissances internes et la conformité, la capacité de RAG à combler l'écart entre l'IA générale et les connaissances organisationnelles spécifiques en fait une base essentielle pour des déploiements fiables et concrets.

Comment fonctionne RAG

RAG améliore la sortie d'un modèle de langage en y injectant des informations contextuelles et en temps réel récupérées à partir d'une source de données externe. Lorsqu'un utilisateur soumet une requête, le système engage d'abord le modèle de récupération, qui utilise une base de données vectorielle pour identifier et « récupérer » des documents, des bases de données ou d'autres sources d'information pertinentes, dans une logique de similarité sémantique. Une fois identifiés, ces résultats sont ensuite combinés avec la commande d'entrée originale et envoyés à un modèle d'IA génératif, qui synthétise ces nouvelles informations dans son propre modèle.

Cela permet au LLM de produire des réponses plus précises et conscientes du contexte, basées sur des données spécifiques à l'entreprise ou à jour, plutôt que de se fier simplement au modèle sur lequel il a été formé.

Les pipelines RAG impliquent généralement quatre étapes : la préparation et le fractionnement des documents, l'indexation des vecteurs, la récupération et l'augmentation de l'invite. Ce flux de processus aide les développeurs à mettre à jour les sources de données sans avoir à re-entraîner le modèle et rend RAG une solution évolutive et économique pour la construction d'applications LLM dans des domaines tels que le support client, les bases de connaissances et la recherche interne.

Quels défis la génération augmentée de récupération (RAG) peut-elle relever ?

Problème n° 1 : les LLM ne connaissent pas vos données

Les LLM s'appuient sur des modèles d'apprentissage profond et s'entraînent sur des datasets très volumineux pour comprendre, résumer et générer du contenu inédit. La plupart des LLM sont entraînés sur un large éventail de données publiques, de façon à pouvoir accomplir un grand nombre de tâches et répondre à toutes sortes de questions. Une fois entraînés, la plupart des LLM ne peuvent plus accéder à de nouvelles données au-delà de leurs données d'entraînement. Cette nature statique est à l'origine de réponses incorrectes ou obsolètes, voire d'hallucinations quand la réponse qu'on leur demande ne se trouve pas dans leurs données d'entraînement.

Problème n° 2 : les applications d'IA doivent exploiter des données personnalisées pour être efficaces

Pour qu'un LLM puisse donner à une entreprise des réponses pertinentes et spécifiques, il faut qu'il comprenne son domaine et s'appuie sur ses données pour répondre, au lieu de donner des réponses généralistes et imprécises. Prenons l'exemple des chatbots d'assistance client : ceux-ci s'appuient sur des LLM et doivent être en mesure de donner aux clients des réponses concernant spécifiquement l'entreprise. Certaines organisations élaborent également des robots conversationnels internes chargés de répondre aux questions que posent les collaborateurs sur des données RH internes. Comment développer de telles solutions sans réentraîner les modèles ?

La solution : l'augmentation par récupération, qui est devenue une norme dans l'industrie

Un moyen simple et répandu d'exploiter vos propres données consiste à les fournir dans le prompt utilisé pour interroger le LLM. C'est ce qu'on appelle la génération augmentée par récupération (RAG) : vous récupérez des données utiles et vous les fournissez au LLM à titre de contexte enrichi. Au lieu de vous appuyer uniquement sur les connaissances dérivées des données d'entraînement, un workflow RAG retrouve des informations et les fournit à un LLM statique en temps réel.

Avec une architecture RAG, les organisations peuvent déployer n'importe quel modèle LLM et l'enrichir de façon à renvoyer des résultats qui les concernent spécifiquement. La quantité de données nécessaire reste faible, et cette pratique évite les coûts et les délais d'un réglage fin ou d'un pré-entraînement.

Quels sont les principaux cas d'usage de la RAG ?

La RAG a de nombreux domaines d'application. Voici le plus courants :

1. Robots conversationnels « questions-réponses » : l'intégration des LLMs aux chatbots leur permet de fournir automatiquement des réponses plus précises en s'appuyant sur les documents et les bases de connaissances de l'entreprise. Les robots conversationnels sont utilisés pour automatiser l'assistance et les échanges initiés sur le site web de l'entreprise : ils permettent de répondre aux questions et de résoudre les problèmes plus rapidement.

   Par exemple, Experian, un courtier en données multinationales et une entreprise de rapport de crédit à la consommation, souhaitait construire un chatbot pour répondre aux besoins internes et orientés client. Ils ont rapidement réalisé que leurs technologies de chatbot actuelles avaient du mal à évoluer pour répondre à la demande. En construisant leur chatbot GenAI — Latte — sur la plateforme d'intelligence de données Databricks, Experian a pu améliorer la gestion des invites et la précision du modèle, ce qui a donné à leurs équipes une plus grande flexibilité pour expérimenter avec différentes invites, affiner les sorties et s'adapter rapidement aux évolutions de la technologie GenAI.

2. Augmentation de la recherche : l'intégration des LLM aux moteurs de recherche enrichit les résultats à l'aide de réponses générées par les LLM, de façon à apporter un plus haut niveau de qualité aux demandes d'information des utilisateurs.

3. Moteur de connaissance – posez des questions à vos données (RH, documents de conformité, etc.) : les données d'entreprise peuvent être employées comme contexte pour les LLM afin de permettre aux collaborateurs d'obtenir facilement des réponses à leurs questions sur des sujets comme les avantages et les politiques d'entreprise, la sécurité ou la conformité.

   Une façon dont cela est déployé est chez Cycle & Carriage, un groupe automobile de premier plan en Asie du Sud-Est. Ils se sont tournés vers Databricks Mosaic AI pour développer un chatbot RAG qui améliore la productivité et l'engagement des clients en puisant dans leurs bases de connaissances propriétaires, telles que les manuels techniques, les transcriptions du support client et les documents de processus d'affaires. Cela a facilité la recherche d'informations par les employés grâce à des requêtes en langage naturel qui fournissent des réponses contextuelles et en temps réel.

Quels sont les avantages de la RAG ?

L'approche RAG présente de nombreux avantages décisifs :

1. Des réponses précises et à jour : grâce à la RAG, les réponses fournies par un LLM ne reposent pas uniquement sur des données d'entraînement statiques potentiellement obsolètes. Au contraire, le modèle utilise des sources de données externes pour produire ses réponses.
2. Réduction des réponses inexactes et des hallucinations : en basant le résultat du LLM sur des connaissances externes pertinentes, la RAG s'efforce de réduire le risque de produire des informations incorrectes ou fabriquées (également appelées hallucinations). Les résultats peuvent inclure des citations venant des sources d'origine pour faciliter la vérification humaine.
3. Des réponses pertinentes et spécifiques au domaine : grâce à la RAG, le LLM peut fournir des réponses pertinentes et contextualisées, adaptées en fonction de données propriétaires internes ou de connaissances spécialisées.
4. Efficacité et rentabilité : comparée aux autres approches visant à personnaliser les LLM à l'aide de données spécifiques, la RAG est simple et économique. Les organisations peuvent déployer la RAG sans personnaliser leur modèle. C'est particulièrement intéressant lorsqu'il faut actualiser fréquemment les données d'enrichissement.

Dans quelles situations utiliser la RAG ou le réglage fin (fine-tuning) ?

La RAG est un excellent point de départ. Elle est simple et peut parfaitement suffire dans certains cas d'usage. Le réglage fin, lui, convient mieux lorsqu'il est nécessaire de modifier le comportement du LLM ou de lui faire apprendre une autre « langue ». Mais ces approches ne s'excluent pas les unes les autres. Par la suite, il est possible d'envisager le réglage fin pour qu'un modèle comprenne mieux le langage du domaine et la forme des résultats attendus, tout en conservant la RAG pour améliorer la qualité et la pertinence des réponses.

Si je veux personnaliser mon LLM à l'aide de mes données, quelles options s'offrent à moi et quelle est la meilleure méthode (ingénierie de prompt, RAG, réglage fin ou pré-entraînement) ?

Lorsque vous cherchez à personnaliser une application de LLM avec les données de votre organisation, vous devez examiner quatre modèles d'architecture. Ces différentes techniques, décrites plus bas, ne s'excluent pas les unes les autres. Au contraire, elles peuvent (et doivent) être combinées pour tirer parti de leurs forces respectives.

Quelle que soit la technique choisie, l'organisation devra créer sa solution en adoptant une approche modulaire et rigoureusement structurée pour se préparer à l'itérer et à l'adapter. Pour en savoir plus sur ce sujet et d'autres, lisez le Grand Livre des MLOps.

Défis courants dans la mise en œuvre de RAG

La mise en œuvre de RAG à grande échelle introduit plusieurs défis techniques et opérationnels.

1. Qualité de récupération. Même les LLM les plus puissants peuvent générer de mauvaises réponses s'ils récupèrent des documents non pertinents ou de faible qualité. Il est donc essentiel de développer une pipeline de récupération efficace qui comprend une sélection minutieuse de modèles d'incorporation, de mesures de similarité et de stratégies de classement.
2. Limitations de la fenêtre de contexte. Avec l'intégralité de la documentation mondiale à portée de main, les risques peuvent être d'injecter trop de contenu dans le modèle, conduisant à des sources tronquées ou à des réponses diluées. Les stratégies de morcelage devraient pondérer la cohérence sémantique avec l'efficacité du jeton.
3. Caractère récent des données L'avantage de RAG réside dans sa capacité à recueillir des informations à jour. Cependant, les index de documents peuvent rapidement devenir obsolètes sans tâches d'ingestion programmées ou des mises à jour automatiques. En vous assurant que vos données sont à jour, vous pouvez éviter des hallucinations ou des réponses obsolètes.
4. Latence. Lorsque vous travaillez avec de grands ensembles de données ou des API externes, la latence peut interférer avec la récupération, le classement et la génération.
5. Évaluation RAG. En raison de la nature hybride de RAG, les modèles traditionnels d'évaluation de l'IA sont insuffisants. L'évaluation de la précision des sorties nécessite une combinaison de jugement humain, de notation de pertinence et de vérifications de fondement pour évaluer la qualité des réponses.
    

Quelle est l'architecture de référence des applications RAG ?

Il existe de nombreuses manières de mettre en place un système de génération augmentée de récupération, selon les besoins et les particularités des données. Nous présentons ci-dessous un workflow couramment appliqué pour vous donner un aperçu plus concret du processus.

1. Préparation des données : les données des documents sont collectées parallèlement aux métadonnées et soumises à un prétraitement initial, pour traiter des données personnelles par exemple (détection, filtrage, masquage, substitution). Pour être utilisables dans des applications RAG, les documents doivent être découpés en passages de longueur adéquate, en fonction du modèle d'intégration choisi et de l'application LLM en aval qui va utiliser ces documents comme contexte.
2. Indexation des données pertinentes : les intégrations de documents sont produites et un index Vector Search est renseigné à partir de ces données.
3. Récupération des données utiles : les données utiles à la requête d'un utilisateur sont récupérées. Ces données textuelles sont alors intégrées au prompt utilisé par le LLM.
4. Développement des applications de LLM : les composants d'enrichissement du prompt et de requête sont enveloppés sous la forme d'un point de terminaison. Ce point de terminaison peut ensuite être exposé à des applications comme un robot conversationnel de type « questions-réponses » via une simple API REST.

Databricks recommande également plusieurs composants clés pour bâtir une architecture RAG :

• Base de données vectorielle : certaines applications LLM – mais pas toutes – utilisent des bases de données vectorielles pour accélérer les recherches de similarité, généralement pour apporter du contexte ou des connaissances spécifiques à des requêtes LLM. Pour veiller à ce que le modèle de langage déployé ait accès à des informations récentes, il est possible de programmer en tant que job la mise à jour des bases de données vectorielles à intervalle régulier. Notez que la logique permettant d'extraire des informations de la base de données vectorielles pour les injecter dans le contexte du LLM peut être empaquetée dans l'artefact de modèle connecté à MLflow à l'aide des variantes de modèle LangChain ou PyFunc.
• Déploiements de LLM MLflow ou Model Serving : dans les applications de LLM qui exploitent une API LLM tierce, la prise en charge des déploiements LLM MLflow ou de Model Serving pour les modèles externes peut servir d'interface normalisée pour acheminer les requêtes provenant de fournisseurs tels qu'OpenAI et Anthropic. En plus de fournir une passerelle API de niveau entreprise, les déploiements de LLM MLflow ou Model Serving centralisent la gestion des clés API et permettent de contrôler rigoureusement les coûts.
• Model Serving : dans le cas de la RAG basée sur une API tierce, l'architecture est différente : c'est le pipeline LLM qui émet les appels API externes, entre le point de terminaison Model Serving et les API LLM internes ou tierces. Il faut noter que cette approche ajoute de la complexité, une latence potentielle et une autre couche de gestion des identifiants. Dans un modèle amélioré par réglage fin, en revanche, le modèle et son environnement sont déployés.

Ressources

• Articles de blog Databricks
  • Créer des applications d'IA générative avec la MLflow AI Gateway et Llama 2
  • Bonnes pratiques pour l'évaluation des applications RAG à destination des LLM
• Démo de Databricks
• Ebook Databricks – Le Grand Livre des MLOps

Les clients Databricks utilisent la RAG

JetBlue

JetBlue a déployé « BlueBot », un robot conversationnel qui s'appuie sur des modèles open source d'IA générative enrichis de données d'entreprise, exécuté avec Databricks. Ce chatbot est à la disposition de toutes les équipes de JetBlue qui peuvent accéder à des données en fonction de leur rôle. L'équipe « finance », par exemple, peut consulter les données SAP et les déclarations réglementaires, mais les équipes d'exploitation ne verront que les informations de maintenance.

Pour en savoir plus, lisez également cet article.

Chevron Phillips

Chevron Phillips Chemical utilise Databricks pour soutenir ses initiatives d'IA générative et automatiser le traitement de ses documents.

Thrivent Financial

Thrivent Financial se tourne vers l'IA générative pour améliorer la recherche, produire des résumés et des insights plus accessibles, et améliorer la productivité de l'ingénierie.

Où puis-je trouver des informations sur la génération augmentée de récupération ?

Vous trouverez de nombreuses ressources sur la RAG. Voici quelques suggestions :

Blogs

• Créer des applications RAG de haute qualité avec Databricks
• Databricks Vector Search en aperçu public
• Améliorez la qualité des réponses des applications RAG avec les données structurées en temps réel
• Créez plus rapidement des applications d'IA générative avec les nouvelles capacités de modèle de fondation
• Bonnes pratiques pour l'évaluation des applications RAG à destination des LLM
• Créer des applications d'IA générative avec la MLflow AI Gateway et Llama 2 (améliorer la précision en utilisant la génération augmentée de récupération (RAG) avec vos propres données)

Ebooks

• Le Grand Livre de l'IA générative
• Le Guide rapide de la RAG
• Le Grand Livre des MLOps

Démos

• Déployez votre chatbot LLM avec la génération augmentée de récupération (RAG), llama2-70B (inférences MosaicML) et Vector Search

Contactez Databricks pour planifier une démonstration et discuter de vos projets de LLM et de génération augmentée de récupération (RAG)

Avenir de la technologie RAG

RAG évolue rapidement d'une solution de contournement bricolée à une composante fondamentale de l'architecture de l'IA d'entreprise. À mesure que les LLMs deviennent plus capables, le rôle de RAG est en train de changer. Il passe de la simple comblement des lacunes en matière de connaissances à des systèmes qui sont structurés, modulaires et plus intelligents.

Une façon dont RAG se développe est à travers des architectures hybrides, où RAG est combiné avec des outils, des bases de données structurées et des agents d'appel de fonction. Dans ces systèmes, RAG fournit un ancrage non structuré alors que les données structurées ou les API gèrent des tâches plus précises. Ces architectures multimodales offrent aux organisations une automatisation de bout en bout plus fiable.

Un autre développement majeur est la co-formation du récupérateur-générateur. Il s'agit d'un modèle où le récupérateur RAG et le générateur sont entraînés conjointement pour optimiser la qualité des réponses de chacun. Cela peut réduire le besoin d'ingénierie des invites manuelles ou de réglage fin et conduit à des choses comme l'apprentissage adaptatif, la réduction des hallucinations et une meilleure performance globale des récupérateurs et des générateurs.

Au fur et à mesure que les architectures LLM mûrissent, RAG deviendra probablement plus fluide et contextuel. En dépassant les capacités finies de stockage de mémoire et d'information, ces nouveaux systèmes seront capables de gérer des flux de données en temps réel, le raisonnement multi-documents et la mémoire persistante, ce qui les rendra des assistants compétents et dignes de confiance.

Questions fréquemment posées (FAQ)

Qu'est-ce que la génération augmentée de récupération, ou RAG ? RAG est une architecture d'IA qui renforce les LLM en récupérant des documents pertinents et en les intégrant dans l'invite. Cela permet d'obtenir des réponses plus précises, actuelles et spécifiques à un domaine sans prendre de temps pour re-former le modèle.

Quand devrais-je utiliser RAG plutôt que le fine-tuning?
Utilisez RAG lorsque vous souhaitez incorporer des données dynamiques sans le coût ou la complexité du réglage fin. C'est idéal pour les cas d'utilisation où des informations précises et opportunes sont requises.

Est-ce que RAG réduit les hallucinations dans les LLMs ?
Oui. En ancrant la réponse du modèle dans un contenu récupéré et à jour, RAG réduit la probabilité d'hallucinations. C'est particulièrement le cas dans les domaines qui nécessitent une grande précision, comme la santé, le travail juridique ou le soutien aux entreprises.

Quel type de données RAG nécessite-t-il?
RAG utilise des données textuelles non structurées - pensez à des sources comme les PDF, les e-mails et les documents internes - stockées dans un format récupérable. Celles-ci sont généralement stockées dans une base de données vectorielle, et les données doivent être indexées et régulièrement mises à jour pour maintenir leur pertinence.

Comment évaluez-vous un système RAG?
Les systèmes RAG sont évalués en utilisant une combinaison de notation de pertinence, des vérifications d'ancrage, des évaluations humaines et des métriques de performance spécifiques à la tâche. Mais comme nous l'avons vu, les possibilités de co-formation entre le récupérateur et le générateur peuvent rendre l'évaluation régulière plus facile à mesure que les modèles apprennent de — et s'entraînent — l'un l'autre.