paint-brush
Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de donnéespar@minio
5,678 lectures
5,678 lectures

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

par MinIO13m2024/06/14
Read on Terminal Reader
Read this story w/o Javascript

Trop long; Pour lire

À la mi-2024, créer une démo d’IA qui impressionne et passionne peut être facile. Vous pouvez souvent créer un robot IA sur mesure en un après-midi. Par contre, arriver à la production est une autre affaire. Vous aurez besoin d'un système fiable, observable, réglable et performant.

People Mentioned

Mention Thumbnail
Mention Thumbnail

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données
MinIO HackerNoon profile picture


À la mi-2024, créer une démo d’IA qui impressionne et passionne peut être facile. Prenez un développeur compétent, des expérimentations rapides et intelligentes et quelques appels d'API vers un modèle de base puissant et vous pourrez souvent créer un robot IA sur mesure en un après-midi. Ajoutez une bibliothèque comme chaîne de langue ou lamaindex pour augmenter votre LLM avec un peu de données personnalisées à l'aide de RAG - et le travail d'un après-midi pourrait se transformer en un projet de week-end.


Mais arriver à la production est une autre affaire. Vous aurez besoin d'un système fiable, observable, réglable et performant à grande échelle. Il sera essentiel d'aller au-delà des scénarios de démonstration artificiels et de considérer la réponse de votre application à une gamme plus large d'invites représentant l'ensemble du spectre du comportement réel du client. Le LLM peut avoir besoin d'accéder à un riche corpus de connaissances spécifiques à un domaine, souvent absent de son ensemble de données de pré-formation. Enfin, si vous appliquez l’IA à un cas d’utilisation où la précision est importante, les hallucinations doivent être détectées, surveillées et atténuées.


Même si la résolution de tous ces problèmes peut sembler intimidante, cela devient plus facile à gérer en déconstruisant votre application basée sur RAG en ses parties conceptuelles respectives, puis en adoptant une approche ciblée et itérative pour améliorer chacune d'entre elles selon les besoins. Cet article vous aidera à faire exactement cela. Dans ce document, nous nous concentrerons exclusivement sur les techniques utilisées pour créer un pipeline de traitement de documents RAG plutôt que sur celles qui se produisent en aval au moment de la récupération. Ce faisant, nous visons à aider les développeurs d’applications d’IA générative à mieux se préparer au passage du prototype à la production.

Le lac de données moderne : le centre de gravité de l'infrastructure d'IA


On dit souvent qu’à l’ère de l’IA, les données sont votre fossé . À cette fin, la création d'une application RAG de niveau production nécessite une infrastructure de données appropriée pour stocker, versionner, traiter, évaluer et interroger des morceaux de données qui composent votre corpus propriétaire. Étant donné que MinIO adopte une approche de l'IA axée sur les données, notre recommandation d'infrastructure initiale par défaut pour un projet de ce type est de mettre en place un lac de données moderne et une base de données vectorielle. Même si d’autres outils auxiliaires devront peut-être être connectés en cours de route, ces deux unités d’infrastructure sont fondamentales. Ils serviront de centre de gravité pour presque toutes les tâches rencontrées par la suite lors de la mise en production de votre application RAG.


Une architecture de référence de lac de données moderne construite sur MinIO peut être trouvée ici . Un document complémentaire montrant comment cette architecture prend en charge toutes les charges de travail AI/ML est ici .


Un pipeline de traitement de documents RAG qui met à jour votre corpus personnalisé par étapes et le charge dans une base de données vectorielle pour une récupération en aval (étapes de récupération non affichées).

RAG : étapes du pipeline de documents

Évaluation

Une première étape cruciale dans la création d'une application RAG de niveau production consiste à mettre en place un cadre d'évaluation - souvent appelé simplement evals. Sans évaluations, vous n'aurez aucun moyen de comprendre de manière fiable les performances de votre système, de savoir quels composants doivent être réglés ou de déterminer si vous faites de réels progrès. De plus, les évaluations agissent comme une fonction de forçage pour clarifier le problème que vous essayez de résoudre. Voici quelques-unes des techniques d’évaluation les plus courantes :


  • Évaluation heuristique basée sur le code : notation des résultats par programme à l'aide de diverses mesures telles que le nombre de jetons de sortie, la présence/absence de mots clés, la validité JSON, etc. Ceux-ci peuvent souvent être évalués de manière déterministe à l'aide d'expressions régulières et de bibliothèques d'assertions pour les tests unitaires conventionnels.


  • Évaluation basée sur le code algorithmique : notation des résultats à l'aide d'une variété de mesures de science des données bien connues. Par exemple, en recadrant l'invite comme un problème de classement, vous pouvez utiliser les fonctions de notation populaires des systèmes de recommandation, telles que le gain cumulatif actualisé normalisé (NDCG) ou le classement réciproque moyen (MRR). À l’inverse, si une invite peut être présentée comme un problème de classification, alors la précision, le rappel et le score F1 peuvent être appropriés. Enfin, vous pouvez utiliser des mesures telles que BLEU, ROUGE et la similarité des réponses sémantiques (SAS) pour comparer la sortie sémantique à une vérité terrain connue.


  • Évaluation basée sur un modèle – Utiliser un modèle pour noter le résultat d'un autre, comme détaillé dans le Juger le LLM en tant que juge papier. Cette technique gagne en popularité et est beaucoup moins coûteuse à mettre à l’échelle que celle des humains. Cependant, dans les premières étapes du passage d'un projet du prototype à la production, sa mise en œuvre peut être difficile à mettre en œuvre de manière fiable, car l'évaluateur, dans ce cas, est un LLM souvent soumis aux mêmes limitations et biais que le système sous-jacent lui-même. Gardez un œil attentif sur la recherche, les outils et les meilleures pratiques dans ce domaine, car ils évoluent rapidement.


  • Évaluation humaine – Demander à des experts du domaine humain de fournir leur meilleure réponse est généralement la norme de référence. Bien que cette méthode soit lente et coûteuse, elle ne doit pas être négligée, car elle peut s'avérer inestimable pour obtenir des informations et développer votre ensemble de données d'évaluation initiale. Si vous souhaitez tirer davantage parti du travail effectué, vous pouvez utiliser des techniques telles que celles détaillées dans le Évaluation automatique correctement effectuée papier pour compléter vos évaluations générées par des experts humains avec des variations synthétiques.


Pyramide d'évaluation montrant la répartition recommandée des différents types d'évaluation. Les méthodes vers le sommet seront plus exigeantes et plus complexes et seront donc plus révélatrices d’un alignement avec la vérité terrain. Les méthodes orientées vers le bas peuvent être appliquées plus rapidement et plus fréquemment, mais ne doivent être interprétées que comme une approximation de l’exactitude factuelle.


Parallèlement à votre décision concernant les techniques d'évaluation à utiliser, envisagez de créer un ensemble de données d'évaluation de référence personnalisé - des données génériques généralement utilisées dans les classements Hugging Face comme le MMLU l'ensemble de données ne fera pas l'affaire. Votre ensemble de données d'évaluation personnalisé contiendra une variété d'invites et leurs réponses idéales, spécifiques au domaine et représentatives des types d'invites que vos clients réels saisiront dans votre application. Idéalement, des experts humains sont disponibles pour vous aider à créer l’ensemble de données d’évaluation, mais sinon, envisagez de le faire vous-même. Si vous n'êtes pas sûr de deviner quelles invites sont probables, formez simplement une hypothèse de fonctionnement et avancez comme si elle avait été validée. Vous pouvez continuellement réviser vos hypothèses plus tard, à mesure que davantage de données deviennent disponibles.


Pensez à appliquer des contraintes à l'invite de saisie pour chaque ligne de votre ensemble de données d'évaluation afin que le LLM réponde avec un type de jugement concret : binaire, catégoriel, classement, numérique ou texte. Un mélange de types de jugement maintiendra vos évaluations raisonnablement variées et réduira les biais de production. Ceteris paribus, il est préférable d'avoir plus de cas de tests d'évaluation ; cependant, il est recommandé de se concentrer sur la qualité plutôt que sur la quantité à ce stade. Recherches récentes sur le réglage fin du LLM dans le LIMA : Moins, c'est plus pour l'alignement L'article suggère que même un petit ensemble de données d'évaluation de 1 000 lignes peut améliorer considérablement la qualité des résultats, à condition qu'il s'agisse d'échantillons représentatifs de la population véritablement plus large. Avec les applications RAG, nous avons observé de manière anecdotique une amélioration des performances en utilisant des ensembles de données d'évaluation composés de dizaines, voire de centaines de lignes.


Bien que vous puissiez commencer à exécuter vos évaluations manuellement de manière ponctuelle, n'attendez pas trop longtemps avant de mettre en œuvre un pipeline CI/CD pour automatiser l'exécution de votre processus de notation d'évaluation. L'exécution d'évaluations quotidiennement ou sur des déclencheurs connectés aux référentiels de code source et aux outils d'observabilité est généralement considérée comme une bonne pratique en matière d'opérations ML. Envisagez d'utiliser un cadre d'évaluation RAG open source comme ragas ou Évaluation profonde pour vous aider à être opérationnel rapidement. Utilisez votre lac de données comme source de vérité pour les tables qui contiennent à la fois le ou les ensembles de données d'évaluation versionnés et les différentes métriques de sortie générées à chaque exécution d'une évaluation. Ces données fourniront des informations précieuses à utiliser plus tard dans le projet pour apporter des améliorations stratégiques et très ciblées.

Extracteurs de données

Le corpus RAG avec lequel vous commencez initialement le prototypage est rarement suffisant pour vous amener à la production. Vous devrez probablement augmenter votre corpus avec des données supplémentaires de manière continue pour aider le LLM à réduire les hallucinations, les omissions et les types de biais problématiques. Cela se fait généralement au cas par cas en créant des extracteurs et des chargeurs qui convertissent les données en amont dans un format pouvant être traité ultérieurement dans un pipeline de documents en aval.


Même s'il existe un petit risque d'essayer de faire bouillir l'océan en collectant plus de données que nécessaire, il est essentiel de faire preuve de créativité et de sortir des sentiers battus quant aux sources d'informations de qualité auxquelles votre entreprise a accès. Des possibilités évidentes peuvent inclure l’extraction d’informations à partir de données structurées stockées dans votre OLTP et votre entrepôt de données d’entreprise. Des sources telles que les articles de blog d'entreprise, les livres blancs, les recherches publiées et les demandes d'assistance client doivent également être prises en compte, à condition qu'elles puissent être anonymisées de manière appropriée et débarrassées des informations sensibles. Il est difficile d'exagérer l'impact positif sur les performances de l'ajout, même de petites quantités de données de qualité dans le domaine, à votre corpus. N'ayez donc pas peur de passer du temps à explorer, expérimenter et itérer. Voici quelques-unes des techniques couramment utilisées pour amorcer un corpus de haute qualité dans un domaine :


  • Extraction de documents : les fichiers PDF propriétaires, les documents bureautiques, les présentations et les fichiers markdown peuvent constituer de riches sources d'informations. Il existe un vaste écosystème d’outils open source et SaaS pour extraire ces données. Généralement, les extracteurs de données sont spécifiques à un type de fichier (JSON, CSV, docx, etc.), basés sur l'OCR ou alimentés par des algorithmes d'apprentissage automatique et de vision par ordinateur. Commencez simplement et ajoutez de la complexité uniquement si nécessaire.


  • Extraction d'API - Les API publiques et privées peuvent être de riches sources de connaissances dans le domaine. De plus, les API Web bien conçues basées sur JSON et XML ont déjà une structure intégrée, ce qui facilite l'extraction ciblée des propriétés pertinentes au sein de la charge utile tout en supprimant tout ce qui est jugé non pertinent. Il existe un vaste écosystème de connecteurs API low-code et no-code abordables pour vous aider à éviter d'écrire des ETL personnalisés pour chaque API que vous souhaitez utiliser - une approche qui peut être difficile à maintenir et à faire évoluer sans une équipe dédiée d'ingénieurs de données.


  • Web Scrapers - Les pages Web sont considérées comme des données semi-structurées avec une structure DOM arborescente. Si vous savez quelles informations vous recherchez, où elles se trouvent et la mise en page où elles résident, vous pouvez rapidement créer un scraper pour consommer ces données même sans API bien documentée. De nombreuses bibliothèques de scripts et outils low-code existent pour fournir des abstractions précieuses pour le web scraping.


  • Robots d'exploration Web : les robots d'exploration Web peuvent parcourir des pages Web et créer des listes d'URL récursives. Cette méthode peut être combinée avec le scraping pour analyser, résumer et filtrer les informations en fonction de vos critères. À une échelle plus significative, cette technique peut être utilisée pour créer votre propre graphe de connaissances.


Quelles que soient les techniques que vous utilisez pour la collecte de données, résistez à l’envie de créer des scripts uniques piratés. Au lieu de cela, appliquez les meilleures pratiques d'ingénierie des données pour déployer des extracteurs en tant que pipelines ETL répétables et tolérants aux pannes qui placent les données dans des tables au sein de votre lac de données. Assurez-vous que chaque fois que vous exécutez ces pipelines (les éléments de métadonnées clés tels que les URL sources et l'heure d'extraction) sont capturés et étiquetés à côté de chaque élément de contenu. La capture des métadonnées s'avérera inestimable pour le nettoyage, le filtrage, la déduplication, le débogage et l'attribution des données en aval.

Regrouper

Le découpage réduit les grands échantillons de texte en morceaux discrets plus petits qui peuvent tenir dans la fenêtre contextuelle d'un LLM. Alors que les fenêtres contextuelles s’agrandissent – permettant de remplir davantage de morceaux de contenu lors de l’inférence – le chunking reste une stratégie vitale pour trouver le bon équilibre entre précision, rappel et efficacité de calcul.


Un regroupement efficace nécessite de sélectionner une taille de bloc appropriée. Des tailles de fragments plus grandes ont tendance à préserver le contexte et la signification sémantique d'un morceau de texte, au détriment de la présence d'un nombre total de fragments inférieur dans la fenêtre contextuelle. À l'inverse, des tailles de fragments plus petites permettront d'insérer des fragments de contenu plus discrets dans la fenêtre contextuelle du LLM. Cependant, sans garde-fous supplémentaires, chaque élément de contenu risque d’être de moindre qualité lorsqu’il est retiré de son contexte environnant.


Exemples de résultats de récupération pour l'invite « Parlez-moi des réalisations professionnelles de Beyoncé » avec différentes configurations de taille de bloc.


En plus de la taille des fragments, vous devrez évaluer diverses stratégies et méthodes de regroupement. Voici quelques méthodes de segmentation standard à prendre en compte :


  • Stratégie de taille fixe – Dans cette méthode, nous sélectionnons simplement un nombre fixe de jetons pour nos morceaux de contenu et déconstruisons notre contenu en morceaux plus petits en conséquence. Généralement, un certain chevauchement entre les morceaux adjacents est recommandé lors de l'utilisation de cette stratégie pour éviter de perdre trop de contexte. Il s’agit de la stratégie de segmentation la plus simple et constitue généralement un bon point de départ avant de s’aventurer davantage dans des stratégies plus sophistiquées.


  • Stratégie de taille dynamique - Cette méthode utilise diverses caractéristiques de contenu pour déterminer où démarrer et arrêter un morceau. Un exemple simple serait un module de ponctuation, qui divise les phrases en fonction de la présence de caractères spécifiques comme les points et les nouvelles lignes. Bien qu'un module de ponctuation puisse fonctionner raisonnablement bien pour un contenu court et simple (c'est-à-dire des tweets, des descriptions de produits limitées en caractères, etc.), il présentera des inconvénients apparents s'il est utilisé pour un contenu plus long et plus complexe.


  • Stratégie basée sur le contenu : les fragments sensibles au contenu sont adaptés au type de contenu et de métadonnées extraits et utilisent ces caractéristiques pour déterminer où démarrer et arrêter chaque fragment. Un exemple pourrait être un chunker pour les blogs HTML qui utilise des balises d'en-tête pour délimiter les limites des chunks. Un autre exemple pourrait être un chunker sémantique qui compare le score de similarité cosinus par paire de chaque phrase avec ses voisins précédents pour déterminer quand le contexte a suffisamment changé pour justifier la délimitation d'un nouveau chunk.


La stratégie de segmentation optimale pour votre application RAG devra être adaptée à la longueur de la fenêtre contextuelle du LLM, à la structure du texte sous-jacente, à la longueur du texte et à la complexité du contenu de votre corpus. Expérimentez généreusement avec diverses stratégies de segmentation et exécutez vos évaluations après chaque modification pour mieux comprendre les performances de l'application pour une stratégie donnée. Versionnez votre contenu fragmenté dans les tables de votre lac de données et assurez-vous que chaque fragment contient des informations de lignée pour le retracer jusqu'au contenu brut et à ses métadonnées respectives de l'étape d'extraction de données en amont.

Enrichissement

Dans de nombreux cas, les morceaux de contenu indexés pour la récupération lors de RAG sont contextuellement différents des invites réelles que votre application rencontrera en production. Par exemple, si vous créez un robot de réponse aux questions IA, vous pouvez disposer d’un vaste corpus d’informations exclusives contenant de nombreuses réponses correctes aux requêtes des clients. Cependant, dans sa forme brute, il est peu probable que votre corpus soit pré-organisé sous le format de paires questions-réponses, ce qui est idéal pour la récupération d'intégration basée sur la similarité. Dans cet exemple, si au moment de la récupération, nous recherchions naïvement dans notre corpus des morceaux de contenu brut qui sont sémantiquement similaires à une question client entrante, nous pourrions rencontrer une pertinence sous-optimale de l'ensemble de résultats de récupération. Cela est dû au fait que nous comparons la similarité d’éléments contextuellement disparates – à savoir les questions et les réponses. Heureusement, la solution est relativement simple : nous pouvons utiliser la puissance des LLM pour enrichir nos réponses possibles – c'est-à-dire les morceaux de contenu brut – en les recontextualisant en questions hypothétiques. Nous indexons ensuite ces questions hypothétiques dans notre base de données vectorielles pour une récupération ultérieure. Cette technique, appelée Intégrations de documents hypothétiques (HyDE) , illustre la puissance de l'utilisation des LLM pour enrichir vos données dans le pipeline de traitement des documents. Voici un exemple d'utilisation de cette technique sur certains contenus du célèbre Ensemble de données squad_v2 :


 System Prompt: Given the provided snippet of text, generate three hypothetical questions that could be asked about it. Each question must be able to be answered using the information within the referenced snippet of text and only that information. Be concise. User Prompt: “At the 52nd Annual Grammy Awards, Beyoncé received ten nominations, including Album of the Year for I Am... Sasha Fierce, Record of the Year for "Halo", and Song of the Year for "Single Ladies (Put a Ring on It)", among others. She tied with Lauryn Hill for most Grammy nominations in a single year by a female artist. In 2010, Beyoncé was featured on Lady Gaga's single "Telephone" and its music video. The song topped the US Pop Songs chart, becoming the sixth number-one for both Beyoncé and Gaga, tying them with Mariah Carey for most number-ones since the Nielsen Top 40 airplay chart launched in 1992. "Telephone" received a Grammy Award nomination for Best Pop Collaboration with Vocals.” Response: Here are some questions that could be asked based on the provided text: * How many nominations did Beyoncé receive at the 52nd Annual Grammy Awards? * For which album was Beyoncé nominated for Album of the Year at the 52nd Annual Grammy Awards? * Which song earned Beyoncé a nomination for Record of the Year at the 52nd Annual Grammy Awards?


Si vous travaillez avec un corpus composé de contenu long et/ou thématiquement complexe, envisagez d'effectuer un prétraitement supplémentaire pour pré-résumer les morceaux de contenu et ainsi réduire leur dimensionnalité sémantique. Au moment de la récupération, vous pouvez interroger les intégrations des résumés de fragments, puis remplacer le texte non résumé pour l'insertion dans la fenêtre contextuelle. Cette méthode augmente la pertinence lors de l'exécution de RAG sur un corpus vaste, complexe et/ou en constante évolution.

Tokenisation

Les grands modèles de langage en 2024 sont généralement des réseaux de neurones basés sur des transformateurs qui ne comprennent pas nativement le mot écrit. Le texte brut entrant est converti en jetons, suivis de vecteurs d'intégration de haute dimension optimisés pour les opérations de multiplication matricielle. Ce processus entrant est généralement appelé encodage. Le processus sortant inversé est appelé décodage. De nombreux LLM ne fonctionneront que pour l'inférence en utilisant le même schéma de tokenisation sur lequel ils ont été formés. Il est donc essentiel de comprendre les bases de la stratégie de tokenisation choisie, car elle peut avoir de nombreuses implications subtiles en termes de performances.


Bien qu'il existe des schémas simples de tokenisation au niveau des caractères et des mots, presque tous les LLM de pointe utilisent des tokenizers de sous-mots au moment de la rédaction. Par conséquent, nous nous concentrerons ici uniquement sur cette catégorie de tokenizers.


Les tokeniseurs de sous-mots divisent récursivement les mots en unités plus petites. Cela leur permet de comprendre des mots hors vocabulaire sans trop exploser la taille du vocabulaire - une considération clé pour les performances de la formation et la capacité du LLM à généraliser à des textes invisibles.


Une méthode de tokenisation de sous-mots largement utilisée aujourd'hui est le codage par paire d'octets (BPE). À un niveau élevé, l'algorithme BPE fonctionne comme ceci :


  • Divisez les mots en jetons d'unités de sous-mots et ajoutez-les au vocabulaire. Chaque jeton représente un sous-mot régi par la fréquence relative des modèles de caractères adjacents communs au sein du corpus de formation.


  • Remplacez les paires de jetons communs de l'étape ci-dessus par un seul jeton représentant la paire et ajoutez-le au vocabulaire.


  • Répétez récursivement les étapes ci-dessus.


La tokenisation BPE est généralement un excellent point de départ avec votre application RAG, car elle fonctionne bien pour de nombreux cas d'utilisation. Cependant, supposons que vous disposiez d'une quantité importante de langages de domaine hautement spécialisés qui ne sont pas bien représentés dans le vocabulaire du corpus de pré-formation utilisé pour le modèle que vous avez choisi. Dans ce cas, envisagez de rechercher des méthodes alternatives de tokenisation – ou d’explorer des réglages fins et des adaptations de bas rang, qui dépassent le cadre de cet article. Le problème de vocabulaire restreint mentionné ci-dessus peut se manifester par de mauvaises performances dans les applications conçues pour des domaines spécialisés comme la médecine, le droit ou des langages de programmation obscurs. Plus précisément, cela sera répandu sur les invites qui incluent un langage/jargon hautement spécialisé. Utilisez l'ensemble de données d'évaluation stocké dans votre lac de données pour expérimenter différents schémas de tokenisation et leurs performances respectives avec différents modèles selon les besoins. Gardez à l’esprit que les tokeniseurs, les intégrations et les modèles de langage sont souvent étroitement couplés – donc changer l’un peut nécessiter de changer les autres.

Conclusion

Un lac de données moderne construit sur un magasin d'objets MinIO - fournit une infrastructure de base pour mettre en production en toute confiance des applications basées sur RAG. Une fois cela en place, vous pouvez créer des évaluations et un ensemble de données d'évaluation spécifiques au domaine qui peuvent être stockées et versionnées dans vos tables de lac de données. À l'aide de ces évaluations, évaluez à plusieurs reprises et améliorez progressivement chaque composant du pipeline de documents de vos applications RAG (extracteurs, chunkers, enrichissement et tokenizers) autant que nécessaire pour créer vous-même un pipeline de traitement de documents de qualité production.


Si vous avez des questions, n'hésitez pas à nous contacter au Mou !