Реализация Agentic RAG с использованием Claude 3.5 Sonnet, LlamaIndex и Milvus
Поскольку системы ИИ продолжают стремительно развиваться, опоры исключительно на большие языковые модели (LLM) уже недостаточно, чтобы удовлетворять разнообразные потребности современных отраслей. Эти растущие вызовы требуют разработки более сложных архитектур, способных решать проблемы более эффективно и результативно.
На Unstructured Data Meetup, организованном Zilliz, Bill Zhang, Director of Engineering в Zilliz, представил концепцию Compound AI Systems, которая была освещена в блоге Berkeley AI Research (BAIR). Этот модульный подход объединяет несколько компонентов для обработки различных задач, вместо того чтобы полагаться на одну модель ИИ, обеспечивая более адаптированные и эффективные результаты. Вы можете посмотреть презентацию Bill на канале Zilliz YouTube.
В этом блоге мы кратко рассмотрим ключевые тезисы Bill, включая эволюцию архитектур приложений на основе LLM, концепции Retrieval Augmented Generation (RAG) и Agentic RAG, а также их вызовы и преимущества. Мы также покажем, как создать Agentic RAG с использованием Claude 3.4 Sonnet, LlamaIndex и векторной базы данных Milvus.
Развитие архитектуры приложений LLM
LLM являются частью ландшафта ИИ уже более десяти лет, но появление общедоступных foundation models, особенно ChatGPT от OpenAI, за последние три года значительно ускорило разработку приложений LLM, стимулируя их быстрое распространение. На Unstructured Data Meetup Bill обобщил ключевые компоненты современных архитектур ИИ и их развитие.
Figure 1- LLM System Evolution .png
Рисунок 1: Эволюция системы LLM
Полагаться исключительно на предварительно обученные знания LLM
Самый простой способ использовать LLM — полагаться на ее “собственные” знания для ответа на ваш запрос. Однако у этого метода есть ограничение: LLM не могут охватить все темы или сценарии использования, что может приводить к неточным или “галлюцинированным” ответам. Один из способов решить эту проблему — использовать несколько LLM, каждая из которых адаптирована под разные типы вопросов, но такой метод сделал бы систему чрезмерно сложной и трудной для масштабирования.
Compound AI systems: добавление дополнительных компонентов в ваш конвейер LLM
Итак, как мы можем решить эту проблему? Решение заключается в Compound AI systems. Добавление дополнительных компонентов в конвейер LLM может повысить производительность системы. Распространенный пример — Retrieval Augmented Generation (RAG). RAG вводит “базу знаний” или “контекст”, обычно хранящиеся в векторной базе данных, такой как Milvus или Zilliz Cloud (управляемый Milvus), где сохраняется конкретная информация для поиска по сходству. Вы можете получить доступ к информации, настроенной под ваш сценарий использования, передав свои знания в систему RAG. RAG использует возможности LLM в сочетании с адаптированным prompt, составленным из пользовательского запроса и контекста, извлеченного из векторной базы данных, создавая более точные и релевантные ответы.
Agents
Итак, нужно ли нам реализовать больше модулей? Это зависит от конкретного варианта использования. Однако, как и LLM, RAG также имеет ограничения, поскольку зависит от конкретной модели. Например, что если ваш запрос предполагает выполнение задачи сравнения, но ваша модель была обучена для суммаризации? Как можно эффективно обрабатывать разные типы вопросов? Именно здесь на практике появляется дополнительный модуль: агенты. ИИ-агенты — это сложные системы, добавляющие в конвейер «человекоподобные» шаги, такие как рассуждение, использование инструментов или планирование. Давайте сначала разберем основы RAG, чтобы понять преимущества агентов.
Retrieval Augmented Generation (RAG)
Как упоминалось выше, системы RAG улучшают вывод LLM, включая векторную базу данных в качестве базы знаний. Базовые шаги построения системы RAG можно резюмировать следующим образом:
Разбиение на фрагменты: Разделение документов на более мелкие части для повышения релевантности контента, извлекаемого из векторной базы данных с помощью семантического поиска, ключевой характеристики векторных баз данных, таких как Zilliz Cloud и Milvus.
Embedding: Векторизация (создание числовых представлений) фрагментов, которые будут загружены в векторную базу данных.
Prompt: Инструкции, данные LLM для поиска в векторной базе данных на основе запроса, чтобы получить ответ
Запрос: Вопрос, заданный LLM
Эти шаги в основном основаны на сходстве. Модель ищет наиболее похожие фрагменты в базе данных и на основе этого генерирует наиболее точный ответ.
Рисунок 2- Базовые шаги RAG .png
Рисунок 2: Базовые шаги RAG
Однако поиск по семантическому сходству — это не волшебное решение. Полученный ответ также окажется недостаточным, если наиболее похожие фрагменты недостаточно точны. Билл рассмотрел некоторые слабые места систем RAG, особенно в вариантах использования, где LLM могут работать неоптимально, включая суммаризацию, сравнение и вопросы из нескольких частей.
Однако проблема RAG, а именно отсутствие у него возможностей рассуждения и неспособность точно извлекать необходимые документы, может быть эффективно решена за счет внедрения агентов. Эти сущности играют ключевую роль во всем процессе, предлагая потенциальное решение проблем, создаваемых RAG.
Агентный RAG
Теперь, когда мы понимаем ограничения LLM и RAG, мы можем глубже изучить преимущества агентов. На диаграмме ниже агенты LLM содержат несколько компонентов, которые взаимодействуют друг с другом в итеративном процессе. Теперь речь идет не только о сходстве, но и о планировании, рассуждении, использовании инструментов и запоминании.
Рисунок 3- Агенты LLM .png
Рисунок 3: Агенты LLM
Хотя существует несколько агентных архитектур и фреймворков, одним из самых популярных является ReAct (Reasoning/Acting). ReAct включает несколько шагов: планирование/рассуждение, действие (использование инструментов), наблюдение/оценка и генерация ответа. Билл выделил эти шаги как часть итеративного процесса.
На этапе наблюдения/оценки, если модель не находит ответ, она продолжит искать альтернативы, возвращаясь к этапу рассуждения или даже запрашивая у пользователя дополнительный промпт.
Рисунок 4- Фреймворк ReAct.png
Рисунок 4: Фреймворк ReAct (Источник)
Итак, как мы можем использовать этих агентов в RAG-пайплайне? Хорошая новость в том, что они могут быть реализованы на всех этапах пайплайна, будь то маршрутизация/планирование в нижестоящий RAG-пайплайн или вызов инструментов. Даже базу знаний можно рассматривать как инструмент или фреймворк ReAct.
Figure 5- How An Agentic RAG works .png
Рисунок 5: Как работает Agentic RAG
Во время выступления Билл объяснил пять возможных агентных реализаций внутри RAG-пайплайна:
Маршрутизация: Пользовательский запрос перенаправляется в конкретную базу знаний, релевантную запросу.
- Пример: Если пользователь просит рекомендации по конкретным типам книг, запрос может быть направлен в базу знаний, содержащую информацию об этих типах книг.
Планирование запроса: Запрос разбивается на подзапросы, при этом каждый подзапрос направляется в соответствующий RAG-пайплайн.
- Пример: Если вы хотите узнать финансовые результаты компании за последние три года, агент создает подзапросы для каждого года и направляет каждый из них в соответствующую базу знаний.
Использование инструментов: LLM взаимодействует с внешним API или инструментом, определяя необходимые параметры для взаимодействия.
- Пример: Если пользователь запрашивает прогноз погоды, LLM вызывает погодный API, определяет такие параметры, как местоположение и дата, и обрабатывает ответ API, чтобы предоставить ответ.
ReAct: Итеративный процесс, включающий рассуждение и действие, в том числе этапы планирования, использования инструментов и наблюдения.
- Пример: Чтобы создать подробный маршрут путешествия, система анализирует потребности пользователя, использует API для сбора информации о достопримечательностях, ресторанах и проживании, проверяет результаты на точность и релевантность, а затем предоставляет комплексный план поездки.
Динамическое планирование запросов: Агент выполняет несколько задач или подзапросов параллельно, а не последовательно, и агрегирует результаты
Пример: Если вы хотите сравнить финансовые результаты двух компаний и рассчитать разницу по конкретной метрике, агент обрабатывает данные для обеих компаний параллельно, а затем объединяет результаты, чтобы предоставить сравнение. LLMCompiler — это пример фреймворка, который обеспечивает эффективную и результативную оркестрацию параллельного вызова функций.
Figure 6- LLM Compiler.png
Рисунок 6: LLM Compiler (Источник)
Итак, агенты добавляют дополнительный слой к RAG-пайплайну, повышая и улучшая общую эффективность процесса. Однако, как и LLM и RAG как самостоятельные системы, агенты также имеют некоторые сложности, такие как контроль их внутренних шагов и настройка для достижения лучших результатов в конкретных сценариях использования.
Теперь давайте продемонстрируем простой агентный пайплайн с использованием векторной базы данных Milvus.
Agentic RAG с использованием Claude 3.5 Sonnet, LlamaIndex и Milvus
Следующий notebook является примером Agentic RAG-пайплайна, созданного с LlamaIndex в качестве агентного фреймворка, Milvus в качестве векторной базы данных и Claude 3.5 Sonnet в качестве LLM. В этом разделе я покажу вам, как построить этот agentic RAG.
Вы также можете посмотреть полный код в этом notebook.
Шаг 1: Загрузка данных
Мы используем страницы FAQ из документации Milvus 2.4.x как частные знания в нашем RAG, что является хорошим источником данных для простого RAG-пайплайна.
!pip install -qq llama-index pymilvus llama-index-vector-stores-milvus llama-index-llms-anthropic
!wget https://github.com/milvus-io/milvus-docs/releases/download/v2.4.6-preview/milvus_docs_2.4.x_en.zip
!unzip -q /content/milvus_docs_2.4.x_en.zip -d /content/milvus_docs
from llama_index.core import SimpleDirectoryReader
# load documents
documents = SimpleDirectoryReader(
input_files=["/content/milvus_docs/en/faq/operational_faq.md"]
).load_data()
print("Document ID:", documents[0].doc_id)
Шаг 2: Переменные окружения
Нам нужно импортировать два API-КЛЮЧА: Anthropic и OpenAI.
import os
from google.colab import userdata
os.environ["ANTHROPIC_API_KEY"] = userdata.get('ANTHROPIC_API_KEY')
os.environ["OPENAI_API_KEY"] = userdata.get('OPENAI_API_KEY')
Шаг 3: Индексация данных
Индекс документов создается с использованием векторной базы данных Milvus. Это будет наша база знаний. Поскольку OpenAI является моделью эмбеддингов по умолчанию в LlamaIndex (ее можно изменить), нам нужно определить те же размеры (dim = 1536) в MilvusVectorStore. Кроме того, после выполнения следующего кода будет создана локальная база данных, которая будет содержать нашу базу знаний.
from llama_index.core import VectorStoreIndex, StorageContext
from llama_index.vector_stores.milvus import MilvusVectorStore
vector_store = MilvusVectorStore(dim=1536)
storage_context = StorageContext.from_defaults(vector_store=vector_store)
index = VectorStoreIndex.from_documents(documents, storage_context=storage_context)
Шаг 4: Простой механизм запросов
Сначала протестируем механизм запросов без агента. Он работает на базе Claude 3.5 Sonnet и ищет релевантный контент в нашем индексе.
llm = Anthropic(model="claude-3-5-sonnet-20240620")
query_engine = index.as_query_engine(similarity_top_k=5, llm=llm)
res = query_engine.query("What is the maximum vector dimension supported in Milvus?")
print(res)
"""
Вывод:
Milvus поддерживает векторы размерностью до 32 768 по умолчанию. Однако, если вам нужно работать с векторами еще более высокой размерности, у вас есть возможность увеличить значение параметра 'Proxy.maxDimension'. Это позволяет Milvus обрабатывать векторы с размерностями, превышающими лимит по умолчанию.
"""
Шаг 5: Агентный механизм запросов
Теперь мы добавляем QueryEngineTool, который будет выступать в качестве инструмента-обертки для механизма запросов и будет использоваться агентом.
from llama_index.core import VectorStoreIndex
from llama_index.core.tools import QueryEngineTool, ToolMetadata
from llama_index.llms.anthropic import Anthropic
llm = Anthropic(model="claude-3-5-sonnet-20240620")
query_engine = index.as_query_engine(similarity_top_k=5, llm=llm)
query_engine_tool = QueryEngineTool(
query_engine=query_engine,
metadata=ToolMetadata(
name="knowledge_base",
description=(
"Provides information about Milvus FAQ."
"Use a detailed plain text question as input to the tool."
),
),
)
Шаг 6: Создание ИИ-агента
Агент, используемый в этом случае, — это FunctionCallingAgentWorker из LlamaIndex, который применяет критическую рефлексию к ответу на запрос с использованием инструмента механизма запросов для генерации улучшенного ответа.
from llama_index.core.agent import FunctionCallingAgentWorker
agent_worker = FunctionCallingAgentWorker.from_tools(
[query_engine_tool], llm=llm, verbose=True
)
agent = agent_worker.as_agent()
response = agent.chat("What is the maximum vector dimension supported in Milvus?")
print(str(response))
"""
Вывод:
Добавлено сообщение пользователя в память: Какова максимальная размерность вектора, поддерживаемая в Milvus?
=== Ответ LLM ===
Чтобы ответить на ваш вопрос о максимальной размерности вектора, поддерживаемой в Milvus, мне нужно обратиться к базе знаний FAQ Milvus. Позвольте мне сделать это для вас.
=== Вызов функции ===
Вызов функции: knowledge_base с аргументами: {"input": "What is the maximum vector dimension supported in Milvus?"}
=== Вывод функции ===
Milvus по умолчанию поддерживает векторы размерностью до 32 768. Однако если вам нужно работать с векторами еще более высокой размерности, у вас есть возможность увеличить значение параметра 'Proxy.maxDimension'. Это позволяет Milvus поддерживать векторы с размерностью, превышающей лимит по умолчанию.
=== Ответ LLM ===
На основе информации из базы знаний FAQ Milvus я могу дать вам следующий ответ:
Максимальная размерность вектора, поддерживаемая в Milvus, по умолчанию составляет 32 768. Это означает, что «из коробки» Milvus может обрабатывать векторы размерностью до 32 768, что подходит для большинства приложений.
Однако важно отметить, что Milvus предоставляет гибкость для случаев, когда вам может понадобиться работать с векторами еще более высокой размерности. Если ваш сценарий использования требует векторов с размерностью, превышающей 32 768, у вас есть возможность увеличить этот лимит. Это можно сделать, изменив параметр 'Proxy.maxDimension' в конфигурации Milvus.
Итак, подводя итог:
1. Максимальная размерность по умолчанию: 32 768
2. Можно увеличить: Да, изменив параметр 'Proxy.maxDimension'
Такая гибкость позволяет Milvus поддерживать широкий спектр сценариев использования: от типичных приложений машинного обучения и ИИ до более специализированных сценариев, которым могут требоваться векторы чрезвычайно высокой размерности.
На основе информации из базы знаний FAQ Milvus я могу дать вам следующий ответ:
Максимальная размерность вектора, поддерживаемая в Milvus, по умолчанию составляет 32 768. Это означает, что «из коробки» Milvus может обрабатывать векторы размерностью до 32 768, что подходит для большинства приложений.
Однако важно отметить, что Milvus предоставляет гибкость для случаев, когда вам может понадобиться работать с векторами еще более высокой размерности. Если ваш сценарий использования требует векторов с размерностью, превышающей 32 768, у вас есть возможность увеличить этот лимит. Это можно сделать, изменив параметр 'Proxy.maxDimension' в конфигурации Milvus.
Итак, подводя итог:
1. Максимальная размерность по умолчанию: 32 768
2. Можно увеличить: Да, изменив параметр 'Proxy.maxDimension'
Такая гибкость позволяет Milvus поддерживать широкий спектр сценариев использования: от типичных приложений машинного обучения и ИИ до более специализированных сценариев, которым могут требоваться векторы чрезвычайно высокой размерности.
"""
Вывод агента предоставляет более подробный ответ, включая источник информации, логику ответа и некоторые дополнительные предложения, связанные с темой. Это помогает нам лучше понять ответ, данный моделью LLM.
Архитектура агентного RAG
Полная архитектура агентного RAG, которую мы только что построили, выглядит следующим образом.
Архитектура агентного RAG, построенная с помощью Milvus, LlamaIndex и Cluade 3.5 Sonnet.png
Рисунок 7: Архитектура агентного RAG, построенная с помощью Milvus, LlamaIndex и Cluade 3.5 Sonnet
Заключение
В своем выступлении Bill Zhang рассмотрел развивающийся ландшафт систем LLM, подчеркнув переход от автономных моделей к более сложным архитектурам, которые включают RAG и агентов. Каждый компонент — LLM, RAG и агенты — имеет сильные и слабые стороны. Концепция Compound AI позволяет создавать модульные системы, предназначенные для устранения различных узких мест, тем самым повышая общую эффективность конвейера.
Хотя результаты этих продвинутых систем многообещающие, а реализации, готовые к производственной эксплуатации, становятся все более распространенными, сохраняется несколько проблем, особенно в управлении и настройке поведения агентов внутри этих систем. Тонкая настройка этих компонентов для эффективной работы в конкретных сценариях использования остается областью постоянного развития.
Дополнительные ресурсы о GenAI, VectorDB и ML
Читать далее
We spent 8 years making vector databases faster. Then we stopped.
Rarely queried embeddings still need to stay searchable. See how Vector Lakebase enables on-demand vector search without always-on compute costs.
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.
Bringing AI to Legal Tech: The Role of Vector Databases in Enhancing LLM Guardrails
Discover how vector databases enhance AI reliability in legal tech, ensuring accurate, compliant, and trustworthy AI-powered legal solutions.