La lutte pour la suprématie de l’IA
Cet article a été initialement publié sur The Sequence.
Qu’est-ce que LangChain
Les grands modèles de langage (LLM) sont la nouvelle vague technologique. Les géants, Google et Microsoft, entrent dans le Colisée pour se battre dans la bataille de l’IA et s’emparer de la couronne de la recherche. Ce combat colossal n’est que le début de la percée des LLM, et LangChain est là pour aider à la pousser encore plus loin. À eux seuls, les LLM offrent de bonnes capacités conversationnelles avec une mémoire limitée et une tendance à halluciner dans leurs réponses. Un exemple de cette hallucination est lorsque vous demandez à ChatGPT : « Quels sont les niveaux de difficulté dans Read Dead Redemption » ; ChatGPT répondra en affirmant qu’il n’y a pas de paramètres de difficulté. Cette réponse est incorrecte, car RDR a 3 niveaux de difficulté définis. Comme le LLM génère des réponses à l’aide de ses poids, il est impossible de vérifier les informations ou de fournir des sources.
Et si nous voulions que les LLM répondent à des questions et résument nos données ?
Et si nous voulions pouvoir fournir les sources des réponses ?
Et si nous voulions que les LLM se souviennent de conversations précédentes qui dépassent la limite de tokens ?
C’est là que LangChain intervient. LangChain est un framework qui vous permet d’enchaîner différents calculs et connaissances avec des LLM afin de pousser encore plus loin l’utilité des LLM. LangChain vous permet de créer des chatbots propres à un domaine, des agents d’action pour des calculs spécifiques, etc.
Quel rôle joue Milvus
Alors, où Milvus entre-t-il en jeu ? Les LLM ne peuvent traiter qu’un certain nombre de tokens (environ quatre caractères) à la fois, ce qui signifie que les LLM ne peuvent pas analyser un document volumineux ou une collection de documents. Pour contourner cela, nous pouvons stocker tous nos documents dans une base de données, rechercher uniquement les documents pertinents pour la question saisie, et fournir ces documents au LLM pour la génération de réponses. Milvus est parfait pour cela, car nous pouvons tirer parti de la recherche sémantique pour récupérer des documents plus pertinents plus rapidement. Nous commençons par prendre tous les documents que nous analysons et par convertir les textes en embeddings. Un avantage important est que nous pouvons utiliser le LLM d’origine pour générer les embeddings, ce qui permet finalement de conserver le « processus de pensée » du LLM dans notre recherche. Une fois toutes les données intégrées, nous pouvons stocker (l’embedding et le texte original), ainsi que toutes les métadonnées, dans Milvus. Ensuite, lorsqu’une requête arrive, nous pouvons prendre le texte de la requête, l’intégrer à l’aide du même modèle, rechercher les textes pertinents et les fournir à notre LLM pour générer des réponses. Bien que ce pipeline semble simple, sa création peut demander beaucoup de travail. Heureusement, LangChain facilite la mise en place d’un tel pipeline et propose le wrapper VectorStore pour les bases de données vectorielles.
Intégration
Voici l’intégration sur laquelle j’ai travaillé entre Milvus et LangChain.
class VectorStore(ABC):
"""Interface for vector stores."""
@abstractmethod
def add_texts(
self,
texts: Iterable[str],
metadatas: Optional[List[dict]] = None,
**kwargs: Any,
) -> List[str]:
"""Run more texts through the embeddings and add to the vectorstore."""
@abstractmethod
def similarity_search(
self, query: str, k: int = 4, **kwargs: Any
) -> List[Document]:
"""Return docs most similar to query."""
def max_marginal_relevance_search(
self, query: str, k: int = 4, fetch_k: int = 20
) -> List[Document]:
"""Return docs selected using the maximal marginal relevance."""
raise NotImplementedError
@classmethod
@abstractmethod
def from_texts(
cls: Type[VST],
texts: List[str],
embedding: Embeddings,
metadatas: Optional[List[dict]] = None,
**kwargs: Any,
) -> VST:
"""Return VectorStore initialized from texts and embeddings."""
Comme mentionné précédemment, intégrer Milvus à LangChain implique d’étendre la classe VectorStore. Pour ce faire, nous devions implémenter quelques fonctions clés : add_texts(), similarity_search(), max_marginal_relevance_search() et from_text(). Le VectorStore Milvus suit un pipeline simple dans la plupart des cas d’utilisation. Il commence d’abord par recevoir une collection de Documents. Dans la plupart des projets LLM, un Document est une classe de données qui contient le texte original et toutes les métadonnées qui l’accompagnent. Les métadonnées du Document sont généralement basées sur JSON, ce qui permet un stockage plus accessible dans Milvus. Une fois que le VectorStore Milvus consomme un Document, il intègre le texte qui s’y trouve à l’aide de la fonction d’embedding qui lui est fournie. Dans la plupart des systèmes de production, ces fonctions d’embedding sont généralement des services LLM tiers tels qu’OpenAI, Cohere, etc. Cependant, il est possible d’utiliser votre modèle tant que vous fournissez une fonction qui accepte une entrée textuelle et renvoie un vecteur. À cette étape du pipeline, LangChain transfère le contrôle à Milvus lui-même. Milvus reçoit l’embedding, le texte original et les métadonnées, puis les stocke dans une collection. À mesure que de plus en plus de ces documents entrent dans la collection, des index sont créés pour accélérer les recherches dans tous les embeddings stockés.
La dernière étape de ce pipeline consiste à effectuer des recherches de données pertinentes. Lorsqu’un utilisateur envoie une question, le texte et les filtres de métadonnées sont envoyés au VectorStore Milvus. En utilisant la même fonction d’embedding qu’auparavant, Milvus intègre la question et effectue une recherche de similarité dans ses données. Milvus propose deux types de recherches en tant que VectorStore : une recherche par défaut qui renvoie les objets dans leur ordre non modifié, et une autre où l’ordre par pertinence marginale maximale est utilisé. L’ordre par pertinence marginale maximale fonctionne en trouvant les exemples dont les embeddings présentent la plus grande similarité cosinus avec les entrées, puis en les ajoutant itérativement tout en les pénalisant pour leur proximité avec les exemples déjà sélectionnés.
L’intégration de Milvus à LangChain a rencontré quelques difficultés, la plus importante étant que Milvus ne peut pas gérer JSON. L’absence de prise en charge de JSON a compliqué les choses en raison de la manière dont les configurations sont générées pour Milvus. Actuellement, il n’existe que deux façons d’utiliser le VectorStore Milvus : créer un VectorStore sur une collection Milvus déjà existante ou créer un VectorStore à partir du premier document transmis à Milvus. Si la Collection existe déjà, le schéma est gravé dans le marbre. Toutes les données ajoutées doivent suivre le schéma à la lettre ; si des données sont manquantes ou mal formées, le système ignorera l’entrée entière.
De même, si des métadonnées supplémentaires sont ajoutées à un Document après la création de la Collection, ces métadonnées supplémentaires seront ignorées. Cela ne se prête pas à un système très adaptable et entraîne la nécessité de faire beaucoup de travail supplémentaire pour nettoyer les entrées, ainsi qu’un travail supplémentaire pour créer une nouvelle collection. Heureusement, dans la version 2.3, Milvus ajoutera la possibilité de stocker JSON, ce qui simplifiera cette intégration et toutes les suivantes. Milvus 2.3 est actuellement en bêta, alors n’hésitez pas à l’essayer et à nous faire part de vos commentaires !
Conclusion
Le résultat est une mémoire de travail et une base de connaissances pour les LLM. Depuis que l’intégration a été fusionnée, LangChain a quelque peu changé, en introduisant l’idée de Retrievers. Les Retrievers sont un moyen de se connecter à un stockage externe et représentent la voie que LangChain suivra. En raison de la nature très évolutive de ce projet, le code présent dans le Milvus VectorStore pourrait être plus propre, et les prochaines étapes consisteront à le nettoyer et à ajouter également cette fonctionnalité de retriever. Comme mentionné précédemment, Milvus ne peut pas gérer un schéma dynamique, ce qui rend très difficile la gestion des collections prédéfinies et des insertions auxquelles il manque des données. Une fois que Milvus prendra en charge les métadonnées JSON, il sera temps de revenir et de refaire cette intégration.
Dans l’ensemble, travailler sur ce projet a été une excellente expérience. La communauté est accueillante, et Harrison est très actif et serviable. J’ai hâte de voir les sommets que le projet LangChain atteindra.
Continuer à lire
Introducing Loon: A New Storage Engine for Vector Data That Never Stops Changing
Loon is a new storage engine for Milvus 3.0 and Zilliz Vector Lakebase, built to manage evolving vector datasets with ColumnGroups, row ID alignment, and Manifests.
My Wife Wanted Dior. I Spent $600 on Claude Code to Vibe-Code a 2M-Line Database Instead.
Write tests, not code reviews. How a test-first workflow with 6 parallel Claude Code sessions turns a 2M-line C++ codebase into a daily shipping pipeline.
Introducing Zilliz Cloud Global Cluster: Region-Level Resilience for Mission-Critical AI
Zilliz Cloud Global Cluster delivers multi-region resilience, automatic failover, and fast global AI search with built-in security and compliance.