Récapitulatif du webinaire : techniques de récupération pour accéder au contexte le plus pertinent pour les applications LLM
Connecter les grands modèles de langage (LLM) à des sources de données externes est crucial pour améliorer les performances de nombreuses applications d’IA. Ces connexions impliquent de les lier à des collections de données préexistantes, de rappeler des conversations utilisateur ou de générer de « nouveaux souvenirs » par réflexion. La récupération consiste à extraire des informations pertinentes à partir de sources externes connectées et à les intégrer à la requête afin de fournir du contexte.
Lors de notre récent webinaire, Harrison Chase, cofondateur et CEO de LangChain, et Filip Haltmayer, Software Engineer chez Zilliz, ont discuté de la récupération avec LangChain et les bases de données vectorielles, de la recherche sémantique et de ses cas limites. Dans cet article, nous explorerons les principaux enseignements du webinaire et répondrons à certaines questions restées sans réponse de l’audience.
Qu’est-ce que la récupération, et pourquoi est-elle importante ?
En général, la récupération désigne l’accès à des informations depuis la mémoire ou d’autres dispositifs de stockage. Pendant le webinaire, Harrison a expliqué comment nous pouvions exploiter les techniques de récupération pour apporter des connaissances externes aux LLM à l’aide d’une base de données vectorielle comme Milvus et d’un agent d’IA comme LangChain.
Bien que les LLM soient très puissants, ils ont des limites puisqu’ils ne connaissent que les informations sur lesquelles ils ont été pré-entraînés, qui peuvent nécessiter une mise à jour. Par exemple, les données de ChatGPT ne couvrent que jusqu’à l’année 2021, il ne sait donc pas ce qui s’est passé ensuite. Les LLM manquent également de données sur des informations propres à un domaine ou propriétaires, ainsi que de données concernant votre entreprise et votre projet. De plus, même si l’information est présente dans le LLM, la reconnaître peut être difficile. Dans de tels cas, la récupération peut être un excellent complément pour donner aux LLM plus de contexte afin d’obtenir des réponses plus précises, ou pour mettre au premier plan l’information cible déjà présente dans le LLM.
Aperçu de la recherche sémantique
La récupération via la recherche sémantique est l’un des cas d’utilisation les plus critiques. Lors du récent webinaire, Harrison a présenté un aperçu du fonctionnement de la recherche sémantique au sein d’une architecture CVP typique (ChatGPT+Vector store+Prompt as code).
Le diagramme suivant explique le fonctionnement de la recherche sémantique dans une pile CVP. Si un utilisateur pose une question générale à laquelle le LLM peut répondre, le LLM répond directement à la question. Cependant, si la question est propre à un domaine, elle est transformée en vecteurs et envoyée à une base de données vectorielle, telle que Milvus, qui contient déjà des documents pertinents. La base de données vectorielle décompose les enregistrements pré-stockés en segments et en embeddings, effectue des recherches sémantiques pour trouver les résultats top-k les plus pertinents pour la requête de l’utilisateur, puis envoie ces résultats à un agent d’IA, tel que LangChain, avec la requête de l’utilisateur. LangChain combine les résultats avec la question de l’utilisateur et les envoie au LLM. Le LLM fournit alors une réponse satisfaisante.
Fonctionnement de la recherche sémantique dans une pile CVP typique
Cas limites de la recherche sémantique
La recherche sémantique est utilisée depuis un certain temps et s’est révélée utile pour relever de nombreux défis. Harrison a présenté cinq cas limites de recherches sémantiques pendant le webinaire et a analysé chaque cas en détail.
Informations répétées
Lorsqu’il s’agit de nombreux documents similaires ou copiés, récupérer des informations pertinentes peut être difficile. Ce type de contenu n’est pas adapté aux LLM et peut créer un contexte inutile. Harrison a proposé trois solutions pour surmonter ce problème :
Filtrez les documents similaires au moyen de recherches sémantiques avant de les envoyer au LLM. Par exemple, avant que LangChain n’envoie les prompts à ChatGPT, il récupère 20 à 30 documents et élimine les documents similaires au moyen d’embeddings ou les contourne pour le LLM.
Exploitez la pertinence marginale maximale pour optimiser la diversité. Cette recherche se concentre sur la similarité et la diversité par rapport aux autres vecteurs récupérés.
Dédupliquez les documents avant de les stocker dans la base de données vectorielle. Toutefois, cette approche peut être difficile, car déterminer le score de similarité qui équivaut à un doublon demande beaucoup de travail. Un élément vectoriel pourrait être très différent, entraînant des différences importantes.
Informations contradictoires
Les informations contradictoires surviennent lorsque plusieurs sources fournissent des réponses différentes à une question, ce qui peut être très déroutant si vous présentez toutes les données à un LLM. Par exemple, si vous vous renseignez sur la politique de congés de votre entreprise, vous pouvez recevoir des réponses différentes provenant de sources comme le document RH et quelques notes de réunion aléatoires.
Harrison a proposé deux solutions à ce problème :
Prioriser les sources et intégrer ce classement dans la récupération.
Transmettre les informations de source à l’étape de génération, permettant au LLM de décider quelle source est la plus fiable.
Temporalité
Lorsque les informations changent au fil du temps, on parle de temporalité. Par exemple, la politique de congés de votre entreprise peut changer occasionnellement.
Pour résoudre ce problème, Harrison propose trois solutions :
Pondération par récence dans la récupération : filtrer complètement les informations obsolètes.
Inclure des horodatages lors de la génération d’informations : demander au LLM de s’appuyer sur des informations plus récentes.
Réflexion : réviser la compréhension d’un sujet au fil du temps.
Interrogation des métadonnées
Parfois, les utilisateurs posent des questions qui portent davantage sur les métadonnées que sur le contenu. Par exemple, un utilisateur peut rechercher des films mettant en scène des extraterrestres en 1980. Alors que « films sur les extraterrestres » peut être recherché sémantiquement, 1980 relève davantage d’une correspondance exacte.
Alors, comment pouvons-nous résoudre ce problème ? Harrison suggère de générer un filtre de métadonnées avant d’effectuer une récupération par recherche sémantique. Cette approche consiste à diviser la question en deux parties : le filtre de métadonnées (qui est une correspondance exacte, comme « l’année est égale à 1980 ») et la requête (comme « extraterrestres ou quelque chose comme ça » dans ce cas).
Mais comment appliquons-nous le filtre de métadonnées ? De nombreux magasins vectoriels permettent l’inclusion directe de filtres de métadonnées dans la requête. Si ce n’est pas possible, il reste possible de filtrer les résultats après la récupération.
Questions multi-sauts
Parfois, les utilisateurs peuvent poser plusieurs questions à la fois, ce qui rend difficile pour la recherche sémantique de récupérer toutes les informations nécessaires à partir de la question initiale.
Harrison a suggéré que nous utilisions des agents d’IA comme LangChain pour relever ce défi. LangChain peut décomposer la question en plusieurs étapes et utiliser le modèle de langage comme moteur de raisonnement pour récupérer les informations requises. Toutefois, cette approche convaincante peut générer de nombreux appels au LLM, entraînant des coûts plus élevés.
Filip a recommandé d’intégrer GPTCache avec LangChain, car GPTCache peut stocker les questions et réponses générées par le LLM. Lorsque les utilisateurs font des requêtes similaires la fois suivante, GPTCache effectue des recherches sémantiques et fournit des réponses avant d’interroger le LLM, ce qui permet aux utilisateurs d’économiser de l’argent sur les appels au LLM.
Questions-réponses
Nous avons reçu de nombreuses questions de notre public pendant le webinaire et avons apprécié leur participation. Harrison et Filip ont répondu à certaines des questions pendant la session de questions-réponses, mais en raison de contraintes de temps, certaines sont restées sans réponse. Ci-dessous, nous avons compilé une liste des questions et réponses.
Q : Pouvez-vous parler davantage de la génération de prompts à l’aide de sources de connaissances externes ? Quels sont quelques exemples ou astuces que vous avez utilisés ? LangChain prévoit-il d’ajouter des fonctionnalités qui créent des prompts optimisés ?
La clé du prompting est d’être clair sur ce que vous voulez. Si vous n’exprimez pas clairement toutes vos intentions et les informations pertinentes, le LLM ne saura pas quoi faire, tout comme un humain ne saurait pas quoi faire. Oui, nous ajouterons quelques fonctionnalités autour de l’optimisation des prompts.
Q : Comment voyez-vous le paysage actuel de la génération augmentée par récupération ? Il existe de nombreuses solutions comme Langchain, Llama Index, Vectara et d’autres. Quelle est la meilleure solution pour affiner les étapes de récupération, y compris les moteurs de requêtes routeurs et autres ? Vous avez mentionné que la récupération pouvait différencier l’importance des documents ; cela est-il déjà disponible via LangChain ?
Tout cet espace en est encore à un stade précoce et évolue très rapidement. Je distinguerai l’étape de récupération et l’étape de génération. Pour la récupération, je dirais que LangChain offre le plus de flexibilité et de modularité pour personnaliser un système de récupération basé sur des vecteurs. Vectara est une excellente solution de bout en bout entièrement gérée pour la récupération, qui abstrait une grande partie des détails. LlamaIndex fournit des structures de données plus intéressantes, comme des arbres, pour expérimenter. Quelle que soit l’étape de récupération que vous choisissez, toutes utilisent LangChain pendant l’étape de génération — nous avons des intégrations avec les trois. Vous pouvez réaliser cette différenciation avec des prompts personnalisés.
Q : Comment pensez-vous que les cas d’utilisation de la récupération et les compromis associés seront affectés à mesure que les limites de contexte des LLM augmenteront au fil du temps ?
Pourquoi est-il encore nécessaire d’avoir une base de données vectorielle pour des transformers à contexte étendu comme le LLM d’Anthropic avec une longueur de contexte de 100k ? Eh bien, les bases de données vectorielles offrent une solution beaucoup plus rentable. En ce qui concerne ces LLM, ils effectuent tout le travail de calcul lourd, tandis que la base de données vectorielle s’occupe du stockage. Veuillez noter que les dépenses de calcul peuvent s’accumuler rapidement. Donc, si vous voulez intégrer davantage de contexte dans vos LLM, vous devez gérer ces coûts accrus. C’est là que réside l’intérêt d’une base de données vectorielle. C’est une alternative rentable, car la plupart des dépenses sont liées au calcul, qui est toujours 100 fois plus cher.
Dépendances à longue portée — les LLM peuvent encore oublier des éléments du « début » de la conversation, même avec l’architecture transformer.
Q : Que pensez-vous des projets open-source visant à publier du contenu pré-vectorisé ? Cohere a publié Wikipedia, et un autre projet a publié des résumés arXiv. Quel est le meilleur modèle pour publier du contenu vectoriel open-source ?
C’est une excellente idée pour apprendre la recherche sémantique et éviter le temps et le coût supplémentaires liés à la génération des vecteurs. En dehors de cela, disposer de vecteurs précalculés vous limite fortement, car cela ne vous permet pas de modifier la manière dont les éléments sont intégrés ni ce qui est intégré. Concernant le meilleur modèle, il n’y en a pas un qui donne les meilleurs résultats pour les données que vous utilisez — plus le modèle que vous utilisez est populaire, plus il y a de chances que votre jeu de données soit utilisé.
Q : Comment fonctionne le sous-package de mémoire dans LangChain ? Pourquoi l’historique des messages de chat est-il séparé de la mémoire ? Pourquoi l’avez-vous conçu ainsi ?
Nous travaillons à une refonte de la mémoire afin de rendre cela plus clair.
Regardez l’enregistrement complet du webinaire !
Regardez l’enregistrement du webinaire pour plus d’informations sur LangChain et la discussion entre Filip et Harrison.
Continuer à lire
DeepSeek-OCR Explained: Optical Compression for Scalable Long-Context and RAG Systems
Discover how DeepSeek-OCR uses visual tokens and Contexts Optical Compression to boost long-context LLM efficiency and reshape RAG performance.
Zilliz Cloud Update: Tiered Storage, Business Critical Plan, Cross-Region Backup, and Pricing Changes
This release offers a rebuilt tiered storage with lower costs, a new Business Critical plan for enhanced security, and pricing updates, among other features.
AI Integration in Video Surveillance Tools: Transforming the Industry with Vector Databases
Discover how AI and vector databases are revolutionizing video surveillance with real-time analysis, faster threat detection, and intelligent search capabilities for enhanced security.