Recherche vectorielle et RAG - Équilibrer la précision et le contexte
Introduction
Les grands modèles de langage (LLM) ont réalisé des progrès considérables, en particulier dans l’apprentissage automatique et le traitement du langage naturel, permettant aux machines de gérer facilement des tâches complexes. Cependant, à mesure que la technologie des LLM se développe, elle a été confrontée à un problème particulier : les hallucinations de l’IA. C’est lorsque l’IA génère des informations incorrectes ou fausses, ce qui nous amène à nous interroger sur la fiabilité de ces systèmes. Christy Bergman, Developer Advocate chez Zilliz avec une riche expérience en IA/ML, a récemment parlé de l’impact de ces hallucinations et de la manière dont elles affectent le déploiement des systèmes d’IA lors du Unstructured Data Meetup.
Regarder la présentation de Christy
Pendant sa présentation, Christy a expliqué ce qui cause les hallucinations de l’IA et leurs effets. Elle a également mentionné le concept principal appelé Retrieval Augmented Generation (RAG), une méthode utilisée pour rendre les modèles de langage plus fiables en fournissant des informations pertinentes et actuelles liées à la question d’un utilisateur. Cette technique permet de garantir que les modèles peuvent accéder aux données les plus récentes, comme des actualités ou des recherches récentes, afin de donner de meilleures réponses et de réduire les erreurs.
Comprendre les hallucinations de l’IA
Les hallucinations de l’IA désignent le phénomène par lequel les systèmes d’intelligence artificielle, en particulier ceux basés sur de grands modèles de langage, génèrent des résultats factuellement incorrects, trompeurs ou entièrement fabriqués.
Ce problème peut se produire pour plusieurs raisons :
Manque de contexte : Les modèles d’IA peuvent ne pas disposer d’un contexte suffisant pour générer des réponses précises, en particulier lorsqu’ils traitent des requêtes complexes ou nuancées.
Problèmes liés aux données d’entraînement : Les données utilisées pour entraîner les modèles d’IA peuvent contenir des erreurs, des biais ou des informations obsolètes, que les modèles peuvent reproduire par inadvertance.
Surgénéralisation : Les modèles d’IA peuvent surgénéraliser à partir de leurs données d’entraînement, ce qui conduit à des extrapolations incorrectes lorsqu’ils sont confrontés à de nouvelles entrées.
Limites de conception : Certaines architectures d’IA ne sont pas conçues pour vérifier la véracité de leurs résultats, se concentrant plutôt sur la génération de réponses statistiquement probables à partir de leurs données d’entraînement.
Christy a donné un excellent exemple de cela lors du Unstructured Data Meetup. Elle a demandé au système d’IA "Gemini" de lister trois politiciens nés à New York, et il a inclus Hillary Clinton, ce qui est faux car elle est née à Chicago.
Cet exemple montre comment l’IA peut commettre des erreurs, même sur des questions simples et directes.
Comme Christy l’a mentionné, « Notez que les LLM peuvent être entraînés sur des sources non conventionnelles, telles que Reddit, ce qui peut conduire à des résultats inhabituels. »
Comment RAG atténue les hallucinations
La Retrieval Augmented Generation (RAG) est une approche avancée du traitement du langage naturel qui vise à améliorer la précision et la fiabilité des modèles d’IA, en particulier pour réduire les hallucinations.
Christy a expliqué que RAG est une nouvelle méthode permettant d’intégrer vos propres données dans le processus d’IA générative. Voici comment cela fonctionne en termes simples :
Vous commencez par fournir vos données à un modèle d’embedding. Ce modèle transforme les informations en un ensemble de nombres appelés vecteurs, qui sont ensuite stockés dans une base de données vectorielle.
Lorsque vous posez une question, le même modèle d’embedding transforme également votre requête en vecteur, puis recherche les voisins vectoriels les plus proches dans cette base de données ou cet espace vectoriel. Une fois qu’il trouve la correspondance la plus proche, il l’utilise comme contexte, avec votre question, pour interroger le grand modèle de langage. De cette façon, vous obtenez une réponse qui a plus de chances d’être exacte.
Voici maintenant comment le RAG s’attaque aux hallucinations de l’IA :
1. Rester à jour : Les modèles RAG peuvent intégrer les données les plus récentes, garantissant que leurs réponses sont fondées sur les dernières informations.
2. Précision et détail : Ces modèles sont conçus pour fournir des réponses exactes en récupérant des informations spécifiques et pertinentes. Ce processus réduit la probabilité de générer du contenu faux ou fabriqué et garantit que les réponses sont détaillées et précisément adaptées à la question, en évitant les affirmations trop générales.
Défis De La Construction D’un Système RAG
Construire un système de génération augmentée par récupération (RAG) implique plusieurs étapes et décisions complexes. Voici quelques défis clés :
Choisir un Modèle d’Embedding
Lors du choix d’un modèle d’embedding, vous pouvez vous concentrer sur quelques facteurs clés :
Dimension du vecteur : Choisissez des modèles qui produisent des vecteurs d’une taille facile à exploiter.
Performance de récupération : Examinez les performances de modèles bien connus provenant d’acteurs comme Cohere et Voyager.
Taille du modèle : Tenez compte de la taille du modèle pour vous assurer qu’il correspond à vos capacités de calcul.
Précision : Assurez-vous que le modèle peut saisir les détails fins importants pour votre domaine ou votre produit.
Scalabilité : Assurez-vous que le modèle peut gérer davantage de données à mesure que vos besoins augmentent.
Et pour vos options, vous pouvez choisir parmi :
Modèles Open Source : Ils sont disponibles gratuitement et peuvent être comparés et sélectionnés sur des plateformes comme le hub de modèles d’embedding de Hugging Face.
Modèles propriétaires : Des entreprises comme Cohere ou OpenAI proposent des modèles qui peuvent avoir des fonctionnalités uniques ou de meilleures performances pour des tâches spécifiques, mais ils ont un coût.
Choisir un Index
Sélectionner une structure d’index appropriée est essentiel pour les performances du système. Cela implique de prendre en compte :
Scalabilité : L’index doit pouvoir évoluer jusqu’à des millions ou des milliards de documents sans devenir excessivement lent.
Empreinte mémoire : Une utilisation efficace de la mémoire est importante, en particulier lorsqu’on travaille avec de grands jeux de données.
Vitesse de récupération vs précision : Il existe souvent un compromis entre la rapidité avec laquelle les documents peuvent être récupérés et la précision avec laquelle ils correspondent à la requête.
Segmentation
La segmentation consiste à découper les documents en parties plus petites et sémantiquement cohérentes afin de faciliter une récupération plus précise.
Déterminer la taille des segments : Trop grands, et les segments peuvent être moins ciblés ; trop petits, et un contexte important peut être perdu.
Maintenir la cohérence : S’assurer que chaque segment reste significatif et cohérent par lui-même.
Gérer les chevauchements : Décider comment gérer les informations qui pourraient entrer dans plusieurs segments.
Mots-clés ou Recherche Sémantique
Le choix entre la recherche basée sur les mots-clés et la recherche sémantique peut affecter la capacité du système à comprendre les requêtes et à y répondre.
Bien que la recherche par mots-clés puisse sembler simple et rapide, le fait de manquer des documents qui ne contiennent pas les mots-clés exacts, même s’ils sont sémantiquement pertinents, peut fortement affecter notre précision. À l’inverse, la recherche sémantique offre une compréhension plus approfondie de l’intention de la requête, mais nécessite davantage de ressources de calcul et des modèles sophistiqués.
Rerankers
Les rerankers sont des modèles ou algorithmes supplémentaires qui affinent les résultats initiaux de récupération, dans le but d’améliorer la pertinence et la précision des documents sélectionnés pour générer la réponse finale. La question devient : valent-ils la peine d’être utilisés et de quoi avons-nous besoin pour les intégrer avec succès ?
Intégration : Les rerankers doivent être intégrés de manière fluide dans le système sans introduire de latence significative.
Données d’entraînement : Comme les autres modèles, les rerankers ont besoin de données d’entraînement de haute qualité et représentatives pour être efficaces.
Réglage : Trouver le bon équilibre entre la récupération initiale et la phase de reranking peut être difficile.
Le RAG est-il mort ?
Une question issue de la présentation de Christy qui me trotte dans la tête ces derniers temps est de savoir si le RAG est toujours la vedette maintenant que les LLM à long contexte montent en puissance.
Les avancées récentes des LLM à long contexte ont soulevé des questions sur l’avenir des techniques de génération augmentée par récupération (Retrieval-Augmented Generation, RAG). Avec des modèles comme Claude ou Gemini 1.5 Pro, capables de traiter jusqu’à 10 millions de tokens, certains soutiennent que l’approche de récupération dynamique du RAG n’est plus nécessaire.
Le duel : le long contexte peut-il se passer du RAG ?
C’est la question dont tout le monde parle. Décomposons-la.
Coût et efficacité :
La nature économe du RAG, qui ne récupère que ce dont il a besoin, permet de réduire les coûts de calcul. Mais à mesure que les prix des technologies d’IA baissent, les LLM à long contexte deviennent plus abordables. Le match est serré ici.
Dynamiques de récupération et de raisonnement :
Les LLM à long contexte combinent leur réflexion avec la récupération d’informations, créant une touche plus personnalisée dans les réponses. La récupération d’informations en amont du RAG peut sembler un peu robotique en comparaison.
Scalabilité et complexité des données:
La capacité du RAG à gérer des billions de tokens est son atout maître, ce qui en fait le roi pour traiter des ensembles de données massifs et en constante évolution. Les LLM à long contexte sont laissés loin derrière ici.
Collaboration plutôt que compétition :
Pourquoi ne pas utiliser les deux ? Combiner la précision du RAG avec l’adaptabilité des modèles à long contexte pourrait conduire à une synergie puissante.
RAG d’OpenAI vs votre RAG personnalisé
Eh bien, vous avez vu ce qu’est le RAG et les défis qu’il présente. Maintenant, il est temps de plonger dans les aspects techniques de la création d’un RAG. Plus précisément, nous discuterons du RAG d’OpenAI et de la façon dont il se compare à la création d’un RAG personnalisé à l’aide de bases de données vectorielles comme Milvus.
Une excellente question posée par un membre du public était : « Quelles sont les raisons de faire un RAG personnalisé plutôt qu’un RAG OpenAI »
Comme Christy l’a mentionné, la partie la plus importante est « Ainsi, vous pouvez avoir une meilleure visibilité sur le système RAG, ce que vous n’avez pas en utilisant OpenAI ; en tant que développeur, vous savez quoi ajuster »
Le rôle de l’API OpenAI Assistant dans la création d’un RAG
L’API OpenAI Assistant est un outil puissant qui vous permet de créer des assistants IA dans vos propres applications. Un Assistant dispose d’instructions et peut utiliser des modèles, des outils et des fichiers pour répondre aux requêtes des utilisateurs. Cette API est idéale pour les applications qui nécessitent des conversations engageantes et de long terme, comme le support client ou les assistants personnels virtuels.
Comparaison entre le RAG d’OpenAI et le RAG personnalisé
Christy a présenté deux approches pour créer un RAG : l’une utilisant l’API OpenAI et l’autre en le personnalisant avec une base de données vectorielle appelée Milvus. Cette comparaison nous aidera à comprendre les différences et les avantages de chaque approche..
Voici les principales différences entre le RAG d’OpenAI et le RAG personnalisé.
| Critères | OpenAI RAG | RAG personnalisé |
| Adéquation à l’application | Adapté au support client, aux assistants personnels virtuels et aux conversations à long terme | Idéal pour l’assistance à la recherche universitaire, les requêtes complexes et les données factuelles |
| Performance et évolutivité | Temps de réponse rapides et haute efficacité | Peut connaître des temps de réponse plus lents en raison de la récupération en base de données |
| Complexité de mise en œuvre | Facile à configurer et à utiliser | Nécessite une expertise en intégration de modèles d’IA et en gestion de bases de données |
| Considérations de coût | Tarification basée sur l’utilisation | Les coûts incluent les ressources de calcul et la maintenance de la base de données |
Une approche RAG personnalisée utilisant des bases de données vectorielles comme Milvus offre davantage de flexibilité et de contrôle, mais nécessite plus d’expertise et de ressources
Vous voulez voir le code en action ? Consultez ce notebook pour un exemple pratique !
Méthodes d’évaluation du RAG
Pour évaluer un pipeline RAG, vous devez examiner les deux parties séparément et ensemble. Vous devez également vérifier si les performances s’améliorent. Pour cela, vous avez besoin de deux éléments : une métrique d’évaluation et un jeu de données.
Comme Christy a abordé cette partie dans son discours, le principal point qu’elle a mentionné était « Votre réponse est-elle ancrée et répond-elle fidèlement à la question »
L’un des outils mentionnés par Christy est Truera, une plateforme qui aide à évaluer et à optimiser les applications de grands modèles de langage (LLM).
Avec Truera, vous pouvez :
Évaluer vos applications LLM
Optimiser votre choix d’applications LLM à l’aide de fonctions de retour d’information et du suivi des applications
Minimiser les hallucinations en exploitant des fonctionnalités comme la triade RAG et d’autres fonctions de retour d’information prêtes à l’emploi
Surveiller et suivre les applications LLM en production à grande échelle, en créant des tableaux de bord réactifs et en configurant des alertes exploitables
Christy a également parlé de RAGAs, c’est un framework conçu spécifiquement pour évaluer les pipelines RAG. Il offre toutes les nécessités techniques pour évaluer chaque composant du pipeline de manière isolée.
RAGAs nécessite les informations suivantes :
· Question : La requête de l’utilisateur
· Réponse : La réponse générée
· Contextes : Les informations récupérées depuis la source de connaissances externe
· Vérités terrain : La réponse correcte à la question (nécessaire uniquement pour une métrique)
RAGAs fournit plusieurs métriques pour évaluer le pipeline, notamment :
· Précision du contexte : Dans quelle mesure les informations récupérées sont pertinentes
· Rappel du contexte : Si toutes les informations pertinentes ont été récupérées
· Fidélité : Dans quelle mesure la réponse générée est exacte
· Pertinence de la réponse : Dans quelle mesure la réponse générée est pertinente par rapport à la question
Évaluer les LLM à l’aide d’autres LLM comme juge
Évaluer les grands modèles de langage (LLM) peut être difficile. Une solution consiste à faire en sorte que les LLM s’évaluent mutuellement. Ce processus implique la génération de cas de test et la mesure des performances du modèle.
Voici comment cela fonctionne :
Génération automatique de tests : Un LLM crée une série de cas de test, comprenant différents inputs, contextes et niveaux de difficulté.
Métriques d’évaluation : le LLM évalué résout les cas de test, et ses performances sont mesurées à l’aide de métriques telles que l’exactitude, la fluidité et la cohérence.
Comparaison et classement : les résultats sont comparés à une référence ou à d’autres LLM, mettant en évidence les forces et les faiblesses de chaque modèle.
Un point intéressant mentionné par Christy, qui est vraiment intrigant, est « GPT se classe lui-même plus haut lorsqu’il est le juge », ce qui montre un autre aspect que nous devons prendre en compte lors de l’évaluation des LLM afin de garantir l’exactitude.
vous pourriez consulter cet article pour approfondir le sujet.
Conclusion
Et voilà ! Nous avons abordé les hallucinations de l’IA et la manière dont RAG peut aider à résoudre ce problème. Christy a donné une excellente explication de la façon dont la création d’un RAG nécessite des choix minutieux de modèles d’embedding, d’index et d’approches de recherche sémantique. En s’attaquant au problème des hallucinations de l’IA et en tirant parti de la récupération dynamique d’informations à jour, RAG offre un outil puissant pour créer des systèmes d’IA plus fiables et sensibles au contexte.
Le parcours de création d’un système RAG implique des décisions réfléchies concernant les modèles d’embedding, l’indexation et la gestion de vastes ensembles de données. Bien que cela soit difficile, les gains en matière de performance et d’exactitude sont considérables.
Que vous soyez intrigué par les nuances techniques ou inspiré par les applications pratiques, c’est le moment idéal pour vous lancer dans RAG. Expérimentez avec des bases de données vectorielles comme Milvus, intégrez des techniques de recherche avancées et constatez par vous-même comment RAG peut transformer la récupération de données et les interactions avec l’IA.
Continuer à lire
Announcing the General Availability of Zilliz Cloud BYOC on Google Cloud Platform
Zilliz Cloud BYOC on GCP offers enterprise vector search with full data sovereignty and seamless integration.
Balancing Precision and Performance: How Zilliz Cloud's New Parameters Help You Optimize Vector Search
Optimize vector search with Zilliz Cloud’s level and recall features to tune accuracy, balance performance, and power AI applications.
Vector Databases vs. Key-Value Databases
Use a vector database for AI-powered similarity search; use a key-value database for high-throughput, low-latency simple data lookups.