Итоги вебинара: методы извлечения для доступа к наиболее релевантному контексту для приложений LLM
Подключение больших языковых моделей (LLM) к внешним источникам данных критически важно для повышения производительности многих AI-приложений. Эти подключения включают связывание с уже существующими коллекциями данных, вспоминание пользовательских разговоров или создание «новых воспоминаний» посредством рефлексии. Извлечение — это получение релевантной информации из подключенных внешних источников и включение ее в запрос для предоставления контекста.
В нашем недавнем вебинаре Harrison Chase, сооснователь и CEO LangChain, и Filip Haltmayer, Software Engineer в Zilliz, обсудили извлечение с LangChain и векторными базами данных, семантический поиск и его пограничные случаи. В этом посте мы рассмотрим ключевые выводы из вебинара и ответим на некоторые оставшиеся без ответа вопросы аудитории.
Что такое извлечение и почему оно важно?
В общем смысле извлечение означает доступ к информации из памяти или других устройств хранения. Во время вебинара Harrison объяснил, как мы можем использовать методы извлечения, чтобы передавать внешние знания LLM с помощью векторной базы данных, такой как Milvus, и AI-агента, такого как LangChain.
Хотя LLM очень мощные, у них есть ограничения, поскольку они знают только предварительно обученную информацию, которая может нуждаться в обновлении. Например, данные ChatGPT охватывают только период до 2021 года, поэтому они не знают, что произошло после этого. LLM также не хватает данных о доменно-специфической или проприетарной информации, а также данных о вашем бизнесе и проекте. Кроме того, даже если информация присутствует внутри LLM, распознать ее может быть сложно. В таких случаях извлечение может стать отличным дополнением, чтобы дать LLM больше контекста для более точных ответов или вывести на передний план целевую информацию, уже находящуюся в LLM.
Обзор семантического поиска
Извлечение с помощью семантического поиска — один из наиболее важных сценариев использования. Во время недавнего вебинара Harrison представил обзор того, как семантический поиск работает в типичной архитектуре CVP (ChatGPT+векторное хранилище+Prompt as code).
Следующая диаграмма объясняет, как семантический поиск работает в стеке CVP. Если пользователь задает общий вопрос, на который LLM может ответить, LLM отвечает на вопрос напрямую. Однако если вопрос относится к конкретной предметной области, он преобразуется в векторы и отправляется в векторную базу данных, например Milvus, которая уже содержит релевантные документы. Векторная база данных разбивает предварительно сохраненные записи на фрагменты и эмбеддинги, выполняет семантический поиск, чтобы найти top-k наиболее релевантных результатов для запроса пользователя, а затем отправляет эти результаты AI-агенту, например LangChain, вместе с запросом пользователя. LangChain объединяет результаты с вопросом пользователя и отправляет их в LLM. Затем LLM предоставляет удовлетворительный ответ.
Как семантический поиск работает в типичном стеке CVP
Пограничные случаи семантического поиска
Семантический поиск используется уже некоторое время и доказал свою полезность в решении многих задач. Harrison продемонстрировал пять пограничных случаев семантического поиска во время вебинара и подробно проанализировал каждый случай.
Повторяющаяся информация
При работе с многочисленными похожими или скопированными документами извлечение релевантной информации может быть сложной задачей. Этот тип контента не подходит для LLM и может создавать ненужный контекст. Harrison предложил три решения для преодоления этой проблемы:
Отфильтровывайте похожие документы с помощью семантического поиска перед отправкой их в LLM. Например, прежде чем LangChain отправит промпты в ChatGPT, он извлекает 20–30 документов и исключает похожие с помощью embeddings или не передает их в LLM.
Используйте max marginal relevance для оптимизации разнообразия. Этот поиск фокусируется на сходстве и разнообразии относительно других извлеченных векторов.
Удаляйте дубликаты документов перед сохранением их в векторной базе данных. Однако этот подход может быть сложным, поскольку определение оценки сходства, которая соответствует дубликату, требует большой работы. Один элемент вектора может сильно отличаться, что приводит к значительным различиям.
Противоречивая информация
Противоречивая информация возникает, когда несколько источников дают разные ответы на вопрос, что может сильно запутать, если представить все эти данные LLM. Например, если вы спросите о политике отпусков вашей компании, вы можете получить разные ответы из таких источников, как HR-документ и какие-нибудь случайные заметки со встречи.
Harrison предложил два решения этой проблемы:
Приоритизировать источники и встроить этот рейтинг в retrieval.
Передавать информацию об источнике на этап генерации, позволяя LLM решать, какой источник более надежен.
Темпоральность
Когда информация меняется со временем, это называется темпоральностью. Например, политика отпусков вашей компании может время от времени меняться.
Чтобы решить эту проблему, Harrison предлагает три решения:
Взвешивание по новизне при retrieval: полная фильтрация устаревшей информации.
Включение временных меток при генерации информации: просьба к LLM опираться на более свежую информацию.
Рефлексия: пересмотр понимания темы с течением времени.
Запросы по метаданным
Иногда пользователи задают вопросы, которые больше касаются метаданных, чем содержимого. Например, пользователь может запросить фильмы с участием инопланетян в 1980 году. Хотя "фильмы об инопланетянах" можно искать семантически, 1980 — это скорее точное совпадение.
Итак, как мы можем решить эту проблему? Harrison предлагает сгенерировать фильтр метаданных перед выполнением semantic search retrieval. Этот подход предполагает разделение вопроса на две части: фильтр метаданных (который является точным совпадением, например "год равен 1980") и запрос (например "инопланетяне или что-то подобное" в данном случае).
Но как применить фильтр метаданных? Многие vector stores позволяют напрямую включать фильтры метаданных в запрос. Если это невозможно, всё равно можно отфильтровать результаты после retrieval.
Многошаговые вопросы
Иногда пользователи могут задавать несколько вопросов одновременно, из-за чего semantic search становится сложно извлечь всю необходимую информацию из исходного вопроса.
Harrison предложил использовать AI agents, такие как LangChain, для решения этой задачи. LangChain может разбить вопрос на несколько шагов и использовать языковую модель как механизм рассуждения для извлечения необходимой информации. Однако этот привлекательный подход может генерировать много вызовов LLM, что приводит к более высоким затратам.
Filip рекомендовал интегрировать GPTCache с LangChain, потому что GPTCache может хранить вопросы и ответы, сгенерированные LLM. Когда пользователи в следующий раз задают похожие запросы, GPTCache выполняет semantic searches и выдает ответы до обращения к LLM, тем самым экономя пользователям деньги на вызовах LLM.
Вопросы и ответы
Мы получили много вопросов от нашей аудитории во время вебинара и благодарны за их участие. Harrison и Filip ответили на некоторые вопросы во время сессии Q&A, но из-за ограничений по времени некоторые остались без ответа. Ниже мы составили список вопросов и ответов.
В: Можете подробнее рассказать о генерации промптов с использованием внешних источников знаний? Какие примеры или приемы вы использовали? Планирует ли LangChain добавить функции, которые создают оптимизированные промпты?
Ключ к составлению промптов — четко понимать, чего вы хотите. Если вы не выразите ясно все свои намерения и релевантную информацию, LLM не будет знать, что делать, так же как и человек не знал бы, что делать. Да, мы добавим некоторые функции для оптимизации промптов.
Q: Как вы видите текущий ландшафт retrieval augmented generation? Существует множество решений, таких как Langchain, Llama Index, Vectara и другие. Какое решение лучше всего подходит для тонкой настройки этапов retrieval, включая router query engines и другие? Вы упомянули, что retrieval может различать важность документов; доступно ли это уже через LangChain?
Вся эта область всё ещё находится на ранней стадии и развивается чрезвычайно быстро. Я бы разделил этап retrieval и этап generation. Что касается retrieval, я бы сказал, что LangChain предоставляет наибольшую гибкость и модульность для настройки системы retrieval на основе векторов. Vectara — отличное полностью управляемое end-to-end решение для retrieval, которое абстрагирует множество деталей. LlamaIndex предоставляет несколько более интересных структур данных, например деревья, для экспериментов. Независимо от того, какой этап retrieval вы выберете, все используют LangChain на этапе generation — у нас есть интеграции со всеми тремя. Вы можете добиться такого разграничения с помощью настроенных промптов.
Q: Как, по вашему мнению, будут меняться сценарии использования retrieval и связанные с ними компромиссы по мере увеличения лимитов контекста LLM со временем?
Почему всё ещё необходимо иметь векторную базу данных для трансформеров с расширенным контекстом, таких как LLM Anthropic с длиной контекста 100k? Что ж, векторные базы данных предлагают гораздо более экономичное решение. Когда речь идет об этих LLM, они выполняют всю тяжелую вычислительную работу, тогда как векторная база данных отвечает за хранение. Имейте в виду, что вычислительные расходы могут быстро накапливаться. Поэтому, если вы хотите поместить больше контекста в свои LLM, вам придется иметь дело с этими возросшими затратами. Именно здесь проявляется преимущество векторной базы данных. Это экономичная альтернатива, поскольку большинство расходов связаны с вычислениями, которые всегда в 100 раз дороже.
Долгосрочные зависимости — LLM всё ещё могут забывать вещи из «начала» разговора, даже с архитектурой трансформеров.
Q: Что вы думаете об open-source проектах, выпускающих предварительно векторизованный контент? Cohere выпустила Wikipedia, а другой проект выпустил аннотации arXiv. Какова лучшая модель для публикации open-source векторного контента?
Это отличная идея — изучить семантический поиск и избежать дополнительных затрат времени и средств на генерацию векторов. Помимо этого, наличие заранее вычисленных векторов серьёзно ограничивает вас, поскольку не позволяет изменять то, как или что встраивается. Что касается лучшей модели, нет такой, которая давала бы наилучшие результаты для используемых вами данных: чем популярнее модель, которую вы используете, тем выше вероятность, что будет использован ваш набор данных.
Q: Как работает подпакет memory в LangChain? Почему история сообщений чата отделена от memory? Почему вы спроектировали это именно так?
Мы работаем над переработкой memory, чтобы сделать это более понятным.
Посмотрите полную запись вебинара!
Посмотрите запись вебинара, чтобы получить больше информации о LangChain и обсуждении между Филипом и Харрисоном.
Читать далее
How to Build an Enterprise-Ready RAG Pipeline on AWS with Bedrock, Zilliz Cloud, and LangChain
Build production-ready enterprise RAG with AWS Bedrock, Nova models, Zilliz Cloud, and LangChain. Complete tutorial with deployable code.
Optimizing Embedding Model Selection with TDA Clustering: A Strategic Guide for Vector Databases
Discover how Topological Data Analysis (TDA) reveals hidden embedding model weaknesses and helps optimize vector database performance.
OpenAI o1: What Developers Need to Know
In this article, we will talk about the o1 series from a developer's perspective, exploring how these models can be implemented for sophisticated use cases.