Génération augmentée de récupération

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.
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é.

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'entreprise 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 bien d'autres, lisez le Grand Livre des MLOps.

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. Le département finances, 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 des 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 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)