Борьба за превосходство в сфере ИИ
Этот пост был первоначально опубликован в The Sequence.
Что такое LangChain
Большие языковые модели (LLM) — новая технологическая волна. Гиганты, Google и Microsoft, выходят на арену Колизея, чтобы сразиться в битве ИИ и завоевать корону поиска. Эта колоссальная битва — лишь начало прорыва LLM, и LangChain здесь, чтобы помочь продвинуть его еще дальше. Сами по себе LLM обладают хорошими разговорными способностями при ограниченной памяти и склонности к галлюцинациям в ответах. Пример такой галлюцинации — когда вы спрашиваете ChatGPT: "What are the difficulty levels in Read Dead Redemption"; ChatGPT отвечает, что настроек сложности нет. Этот ответ неверен, поскольку в RDR есть 3 заданных уровня сложности. Поскольку LLM генерирует ответы с использованием своих весов, проверить информацию или предоставить источники невозможно.
Что, если мы хотим, чтобы LLM отвечали на вопросы и резюмировали наши данные?
Что, если мы хотим иметь возможность предоставлять источники ответов?
Что, если мы хотим, чтобы LLM помнили предыдущие разговоры, которые находятся за пределами лимита токенов?
Именно здесь на помощь приходит LangChain. LangChain — это фреймворк, который позволяет связывать различные вычисления и знания с LLM, чтобы продвинуть полезность LLM еще дальше. LangChain позволяет создавать доменно-специфичные чатботы, агентoв действий для конкретных вычислений и т. д.
Какую роль играет Milvus
Так где же здесь вступает в игру Milvus? LLM могут обрабатывать только определенное количество токенов (примерно четыре символа) за раз, а значит, LLM не могут анализировать большой документ или коллекцию документов. Чтобы обойти это, мы можем хранить все наши документы в базе данных, искать только релевантные входному вопросу документы и передавать эти документы в LLM для генерации ответа. Milvus идеально подходит для этого, поскольку мы можем использовать преимущества семантического поиска, чтобы быстрее извлекать более релевантные документы. Мы начинаем с того, что берем все документы, которые анализируем, и преобразуем тексты в embeddings. Существенное преимущество заключается в том, что мы можем использовать исходную LLM для генерации embeddings, в конечном счете сохраняя «мыслительный процесс» LLM в нашем поиске. После того как все данные embedded, мы можем хранить (embedding и исходный текст) вместе с любыми метаданными в Milvus. Затем, когда поступает запрос, мы можем взять текст запроса, embedded его с помощью той же модели, найти релевантные тексты и передать их в нашу LLM для генерации ответов. Хотя этот пайплайн звучит просто, его создание может потребовать много работы. К счастью, LangChain упрощает создание такого пайплайна и предлагает обертку VectorStore для векторных баз данных.
Интеграция
Вот интеграция, над которой я работал, между Milvus и 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."""
Как упоминалось ранее, интеграция Milvus в LangChain предполагает расширение класса VectorStore. Для этого нам нужно было реализовать несколько ключевых функций: add_texts(), similarity_search(), max_marginal_relevance_search() и from_text(). Milvus VectorStore следует простому конвейеру в большинстве сценариев использования. Сначала он начинает с получения коллекции Documents. В большинстве LLM-проектов Document — это класс данных, который содержит исходный текст и все связанные с ним метаданные. Метаданные Document обычно основаны на JSON, что обеспечивает более доступное хранение внутри Milvus. После того как Milvus VectorStore обрабатывает Document, он создает эмбеддинг текста, содержащегося в нем, используя предоставленную ему функцию эмбеддинга. В большинстве производственных систем эти функции эмбеддинга обычно являются сторонними LLM-сервисами, такими как OpenAI, Cohere и т. д. Однако можно использовать и вашу модель, если вы предоставите функцию, которая принимает текстовый ввод и возвращает вектор. На этом этапе конвейера LangChain передает управление самому Milvus. Milvus принимает эмбеддинг, исходный текст и метаданные и сохраняет их в коллекции. По мере того как в коллекцию поступает все больше таких документов, создаются индексы для более быстрого поиска по всем сохраненным эмбеддингам.
Последний этап этого конвейера — выполнение поиска релевантных данных. Когда пользователь отправляет вопрос, текст и фильтры метаданных отправляются в Milvus VectorStore. Используя ту же функцию эмбеддинга, что и раньше, Milvus создает эмбеддинг вопроса и выполняет поиск по сходству среди своих данных. Milvus предлагает два типа поиска как VectorStore: стандартный, который возвращает объекты в их неизмененном порядке, и тот, где используется упорядочивание по максимальной предельной релевантности. Упорядочивание по максимальной предельной релевантности работает путем нахождения примеров с эмбеддингами, имеющими наибольшее косинусное сходство с входными данными, а затем итеративного добавления их с наложением штрафа за близость к уже выбранным примерам.
Интеграция Milvus в LangChain сопровождалась некоторыми трудностями, наиболее заметная из которых заключается в том, что Milvus не может обрабатывать JSON. Отсутствие поддержки JSON усложнило задачу из-за характера того, как конфигурации генерируются для Milvus. В настоящее время существует только два способа использования Milvus VectorStore: создание VectorStore на основе уже существующей коллекции Milvus или создание VectorStore на основе первого документа, переданного в Milvus. Если Collection уже существует, схема зафиксирована. Все добавляемые данные должны строго следовать схеме; если какие-либо данные отсутствуют или имеют неверный формат, система проигнорирует всю запись.
Аналогично, если к Document добавляются какие-либо дополнительные метаданные после создания Collection, эти дополнительные метаданные будут проигнорированы. Это не способствует созданию очень адаптивной системы и приводит к необходимости выполнять довольно много дополнительной работы по очистке входных данных, а также дополнительной работы при создании новой коллекции. К счастью, в версии 2.3 Milvus добавит возможность хранить JSON, что упростит эту интеграцию и любые последующие. Milvus 2.3 в настоящее время находится в бета-версии, так что не стесняйтесь ознакомиться с ней и предоставить нам любые отзывы!
Заключение
Результат — рабочая память и база знаний для LLM. С момента слияния интеграции LangChain немного изменился, привнеся идею Retrievers. Retrievers — это способ подключения к внешнему хранилищу, и именно в этом направлении будет развиваться LangChain. Из-за быстро меняющегося характера этого проекта код в Milvus VectorStore мог бы быть чище, и следующими шагами будут его очистка, а также добавление этой функциональности retriever. Как уже упоминалось ранее, Milvus не может обрабатывать динамическую схему, что сильно усложняет работу с заранее созданными коллекциями и вставками, в которых отсутствуют данные. Когда Milvus начнет поддерживать JSON metadata, придет время вернуться и переделать эту интеграцию.
В целом работа над этим проектом была отличным опытом. Сообщество дружелюбное, а Harrison очень активен и готов помочь. Я с нетерпением жду, каких высот достигнет проект LangChain.
Читать далее
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.
What Is a Vector Lakebase?
A Vector Lakebase is a unified, lake-native data architecture for AI that combines vector-database-grade serving with open lake storage, reusable lake-level indexes, and a shared semantic layer.
Zilliz Cloud BYOC Now Available Across AWS, GCP, and Azure
Zilliz Cloud BYOC is now generally available on all three major clouds. Deploy fully managed vector search in your own AWS, GCP, or Azure account — your data never leaves your VPC.