Повышение эффективности интеллектуальных документальных помощников на основе RAG с использованием извлечения сущностей, SQL-запросов и агентов с Amazon Bedrock.

Улучшение эффективности интеллектуальных документальных помощников на основе RAG с использованием извлечения сущностей, SQL-запросов и агентов с Amazon Bedrock.

Разговорный искусственный интеллект значительно продвинулся за последние годы благодаря быстрому развитию генеративного искусственного интеллекта, особенно благодаря улучшению производительности больших языковых моделей (LLM), введенных такими методами обучения, как тонкая настройка инструкций и обучение с подкреплением на основе обратной связи от человека. При правильном подходе эти модели могут вести связные беседы без каких-либо задачно-специфичных тренировочных данных. Однако они не могут хорошо обобщать специфические для предприятия вопросы, так как для генерации ответа они полагаются на открытые данные, с которыми они были знакомы во время предварительного обучения. Такие данные часто не содержат специализированных знаний, содержащихся во внутренних документах, доступных в современных компаниях, которые, как правило, необходимы для получения точных ответов в областях, таких как фармацевтические исследования, финансовое расследование и поддержка клиентов.

Чтобы создавать AI-ассистентов, способных вести обсуждения, основанные на специализированных знаниях предприятия, нам необходимо связать эти мощные, но общие LLM с внутренними базами знаний документов. Такой метод обогащения контекста генерации LLM информацией, полученной из внутренних источников данных, называется Retrieval Augmented Generation (RAG) и позволяет создавать ассистентов, которые являются областно-специфичными и более надежными, как это показано в статье “Изучение Retrieval-Augmented Generation для задач NLP, требующих большого объема знаний”. Еще одной причиной популярности RAG является простота его реализации и наличие зрелых решений векторного поиска, таких как те, которые предлагает Amazon Kendra (см. Amazon Kendra launches Retrieval API) и Amazon OpenSearch Service (см. к-ближайший соседский поиск в Amazon OpenSearch Service).

Однако популярный паттерн проекта RAG с семантическим поиском не может давать ответы на все виды вопросов, которые возможны на основе документов. Это особенно верно для вопросов, требующих аналитического мышления по нескольким документам. Например, представьте себе, что вы планируете стратегию инвестиционной компании на следующий год. Один из неотъемлемых этапов будет анализ и сравнение финансовых результатов и потенциальных рисков кандидатов-компаний. Эта задача включает ответы на вопросы аналитического рассуждения. Например, запрос “Укажите мне топ-5 компаний с наибольшим доходом за последние 2 года и определите их основные риски” требует нескольких этапов рассуждения, некоторые из которых могут использовать семантический поиск, тогда как другие требуют аналитических возможностей.

В этой статье мы покажем, как разработать умного помощника по документам, способного отвечать на аналитические вопросы и вопросы, требующие нескольких шагов рассуждения.

• Tехники автоматической суммаризации документов с использованием языковых моделей
• Что выбрать между Расширенным Генерированием с возвратом (RAG) и Тонкой Настройкой?
• Лама 2 Подробное объяснение большой языковой модели Meta!

Часть 1: Ограничения и обзор решений RAG

В этом разделе мы рассмотрим паттерн проектирования RAG, обсудим его ограничения в отношении аналитических вопросов и представим более универсальную архитектуру, которая преодолевает эти ограничения.

Обзор RAG

RAG решения вдохновлены идеями обучения представлений и семантического поиска, которые постепенно применяются в задачах ранжирования (например, рекомендации и поиска) и в задачах обработки естественного языка (NLP) с 2010 года.

Сегодняшний популярный подход состоит из трех шагов:

1. Offline-задание пакетной обработки вносит документы из базы знаний на входе, разбивает их на фрагменты и создает древовидное представление для каждого фрагмента, представляющее его семантику с использованием предварительно обученной модели вложения, такой как модели вложения Amazon Titan, затем использует эти вложения в качестве входных данных для создания семантического поискового индекса.
2. При ответе на новый вопрос в режиме реального времени входной вопрос преобразуется в древовидное представление, которое используется для поиска и извлечения наиболее похожих фрагментов документов с использованием метрики сходства, такой как косинусное сходство, и алгоритма примерного поиска ближайших соседей. Точность поиска также может быть улучшена с помощью фильтрации метаданных.
3. Формируется запрос на основе конкатенации системного сообщения с контекстом, который состоит из соответствующих фрагментов документов, извлеченных на шаге 2, и самого входного вопроса. Затем этот запрос представляется модели LLM для генерации окончательного ответа на вопрос из контекста.

С правильной встраивающей моделью, способной создавать точные семантические представления фрагментов входного документа и вопросов, и эффективным модулем семантического поиска, эта решение может отвечать на вопросы, требующие поиска существующей информации в базе документов. Например, если у вас есть сервис или продукт, вы можете начать с индексации раздела FAQ или документации и создать начальное разговорное ИИ, настроенное на ваше конкретное предложение.

Ограничения RAG, основанные на семантическом поиске

Хотя RAG является важным компонентом в современных специализированных помощниках ИИ и разумным отправным пунктом для создания разговорного ИИ с использованием специализированной базы знаний, он не может отвечать на вопросы, требующие сканирования, сравнения и рассуждения по всем документам в вашей базе знаний одновременно, особенно когда аугментация основана исключительно на семантическом поиске.

Чтобы понять эти ограничения, давайте рассмотрим еще раз пример определения того, куда вложиться на основе финансовых отчетов. Если бы мы использовали RAG для взаимодействия с этими отчетами, мы могли бы задавать вопросы, такие как «Какие риски столкнулась компания X в 2022 году?» или «Какова чистая выручка компании Y в 2022 году?» Для каждого из этих вопросов используется соответствующий вектор встраивания, который кодирует семантическое значение вопроса, что позволяет извлечь топ-K семантически схожих фрагментов документов, доступных в поисковом индексе. Это обычно достигается с помощью использования алгоритмов приближенного поиска ближайших соседей, таких как FAISS, NMSLIB, pgvector или других, которые стремятся найти баланс между скоростью поиска и точностью, чтобы достичь работы в реальном времени при сохранении удовлетворительной точности.

Однако такой подход не может точно отвечать на аналитические вопросы по всем документам, такие как «Какие пять компаний имеют наибольшую чистую выручку в 2022 году?»

Это связано с тем, что при семантическом поиске ищутся K самых похожих фрагментов документов на вопрос. Но так как ни один из документов не содержит полных сводок о выручке, будет найдено только несколько фрагментов, которые содержат упоминания «чистой выручки» и, возможно, «2022 года», не соответствуя главному требованию фокусировки на компаниях с наибольшей выручкой. Если представить эти результаты поиска LLM в качестве контекста для ответа на входящий вопрос, LLM может дать вводящий в заблуждение ответ или отказаться от ответа из-за отсутствия необходимой правильной информации.

Эти ограничения возникают в связи со спецификой семантического поиска, которая не выполняет полное сканирование всех векторов встраивания для поиска соответствующих документов. Вместо этого используются алгоритмы приближенного поиска ближайших соседей, позволяющие достигнуть удовлетворительной скорости поиска. Основная стратегия этих методов – сегментация пространства встраивания на группы при индексации. Это позволяет быстро определить, в каких группах может находиться необходимое встраивание во время поиска, без необходимости попарного сравнения. Кроме того, стандартные методы поиска ближайших соседей, такие как KNN, которые сканируют все документы, работают только с простыми метриками расстояния и не подходят для сложных сравнений, необходимых для аналитического рассуждения. Таким образом, RAG с семантическим поиском не предназначен для ответа на вопросы, требующие аналитического рассуждения по всем документам.

Для преодоления этих ограничений мы предлагаем решение, которое комбинирует RAG с метаданными и извлечением сущностей, SQL-запросами и агентами LLM, как описано в следующих разделах.

Преодоление ограничений RAG с помощью метаданных, SQL и агентов LLM

Давайте более подробно рассмотрим вопрос, на который RAG не может ответить, чтобы мы могли отследить необходимое рассуждение для эффективного ответа на него. Анализ должен указать нам правильный подход, который может дополнить использование RAG в общем решении.

Рассмотрим вопрос: «Какие пять компаний имеют наибольшую выручку в 2022 году?»

Чтобы ответить на этот вопрос, нам нужно:

1. Определить выручку для каждой компании.
2. Отфильтровать выручку за 2022 год для каждой из них.
3. Отсортировать выручку по убыванию.
4. Выбрать пять компаний с наибольшей выручкой вместе с названиями компаний.

Обычно такие аналитические операции выполняются на структурированных данных с использованием инструментов, таких как pandas или SQL-движки. Если у нас есть доступ к SQL-таблице со столбцами company, revenue и year, мы можем легко ответить на наш вопрос с помощью выполнения SQL-запроса, подобного следующему примеру:

SELECT company, revenue FROM table_name WHERE year = 2022 ORDER BY revenue DESC LIMIT 5;

Хранение структурированных метаданных в SQL-таблице, содержащей информацию о соответствующих сущностях, позволяет ответить на множество типов аналитических вопросов путем написания правильного SQL-запроса. Вот почему мы дополняем использование RAG в нашем решении модулем SQL-запросов в реальном времени к SQL-таблице, заполняемой метаданными, извлеченными в офлайн-процессе.

Но как мы можем реализовать и интегрировать такой подход в LLM-ориентированное ассистентное ИИ?

Для того чтобы добавить аналитическое рассуждение на SQL, необходимо выполнить три шага:

• Извлечение метаданных – Извлеките метаданные из неструктурированных документов в SQL-таблицу
• Текст в SQL – Формулируйте точные SQL-запросы из вопросов с использованием LLM
• Выбор инструмента – Определите, должен ли вопрос быть отвечен с помощью RAG или SQL-запроса

Для реализации этих шагов, сначала мы понимаем, что извлечение информации из неструктурированных документов является традиционной задачей NLP, для которой LLM-модели показывают высокую точность с помощью обучения с нуля или обучения на небольшом наборе данных. Во-вторых, способность этих моделей генерировать SQL-запросы из естественного языка была доказана годами, как это было показано в релизе 2020 года Amazon QuickSight Q. Наконец, автоматический выбор правильного инструмента для конкретного вопроса повышает пользовательский опыт и позволяет отвечать на сложные вопросы с помощью многошагового рассуждения. Для реализации этой функции мы более подробно рассмотрим LLM-агентов в последующем разделе.

Подводя итог, предлагаемое нами решение состоит из следующих основных компонентов:

• Семантический поиск для добавления контекста генерации
• Структурированное извлечение метаданных и запросы с использованием SQL
• Агент, способный использовать правильные инструменты для ответа на вопрос

Обзор решения

На следующей диаграмме изображена упрощенная архитектура решения. Она поможет вам определить и понять роль основных компонентов и то, как они взаимодействуют для реализации полного поведения ассистента LLM. Нумерация соответствует порядку операций при реализации этого решения.

На практике мы реализовали это решение, описанное в следующей детализированной архитектуре.

Для этой архитектуры мы предлагаем реализацию на GitHub, с слабой связью компонентов, где бэкэнд (5), потоки данных (1, 2, 3) и фронтэнд (4) могут развиваться отдельно друг от друга. Это упрощает сотрудничество между компетенциями при настройке и улучшении решения для продакшн.

Развертывание решения

Чтобы установить это решение в вашей учетной записи AWS, выполните следующие шаги:

1. Клонируйте репозиторий на GitHub.
2. Установите бэкэнд AWS Cloud Development Kit (AWS CDK) app:
   1. Откройте папку backend.
   2. Запустите команду npm install для установки зависимостей.
   3. Если вы никогда не использовали AWS CDK в текущей учетной записи и регионе, выполните процедуру развертывания с помощью команды npx cdk bootstrap.
   4. Выполните команду npx cdk deploy для развертывания стека.
3. При необходимости запустите streamlit-ui следующим образом:
   1. Мы рекомендуем склонировать этот репозиторий в среду Amazon SageMaker Studio. Дополнительную информацию см. в разделе Onboard to Amazon SageMaker Domain using Quick setup.
   2. Внутри папки frontend/streamlit-ui выполните команду bash run-streamlit-ui.sh.
   3. Выберите ссылку с следующим форматом, чтобы открыть демонстрацию: https://{domain_id}.studio.{region}.sagemaker.aws/jupyter/default/proxy/{port_number}/.
4. Наконец, вы можете запустить команду в Amazon SageMaker, определенную в блокноте data-pipelines/04-sagemaker-pipeline-for-documents-processing.ipynb, чтобы обработать входные файлы PDF и подготовить SQL-таблицу и семантический поисковой индекс, используемый ассистентом LLM.

В остальной части этого поста мы сосредоточимся на объяснении наиболее важных компонентов и выборов дизайна, чтобы, надеемся, вдохновить вас при создании вашего собственного AI-помощника на внутренней базе знаний. Мы предполагаем, что компоненты 1 и 4 понятны, и сосредотачиваемся на основных компонентах 2, 3 и 5.

Часть 2: Пайплайн извлечения сущностей

В этом разделе мы углубляемся в пайплайн извлечения сущностей, используемый для подготовки структурированных данных, которые являются ключевым компонентом для аналитического ответа на вопросы.

Извлечение текста

Документы обычно хранятся в формате PDF или в виде отсканированных изображений. Они могут состоять из простых расположений абзацев или сложных таблиц и содержать цифровой или рукописный текст. Чтобы правильно извлекать информацию, нам необходимо преобразовать эти исходные документы в обычный текст, при этом сохраняя их исходную структуру. Для этого вы можете использовать Amazon Textract, который является сервисом машинного обучения (ML), предоставляющим зрелые API для извлечения текста, таблиц и форм из цифровых и рукописных источников.

В компоненте 2 мы извлекаем текст и таблицы следующим образом:

1. Для каждого документа мы вызываем Amazon Textract для извлечения текста и таблиц.
2. Мы используем следующий Python-скрипт, чтобы воссоздать таблицы в виде объектов DataFrame библиотеки pandas.
3. Мы объединяем результаты в один документ и вставляем таблицы как markdown.

Этот процесс показан на следующей блок-схеме и практически демонстрируется в notebooks/03-pdf-document-processing.ipynb.

Извлечение сущностей и запросы с использованием LLM

Для эффективного ответа на аналитические вопросы вам необходимо извлекать соответствующую метадату и сущности из базы знаний вашего документа в доступном структурированном формате данных. Мы предлагаем использовать SQL для хранения этой информации и получения ответов из-за его популярности, простоты использования и масштабируемости. Этот выбор также имеет преимущества от возможностей проверенных моделей языка генерировать SQL-запросы на естественном языке.

В этом разделе мы углубляемся в следующие компоненты, позволяющие задавать аналитические вопросы:

• Пакетный процесс, извлекающий структурированные данные из неструктурированных данных с использованием LLM
• Модуль реального времени, преобразующий вопросы на естественном языке в SQL-запросы и извлекающий результаты из базы данных SQL

Вы можете извлекать соответствующую метадату для поддержки аналитических вопросов следующим образом:

1. Определите JSON-схему для информации, которую вам нужно извлечь, которая содержит описание каждого поля и его тип данных, а также примеры ожидаемых значений.
2. Для каждого документа попросите LLM с помощью JSON-схемы и попросите извлечь соответствующие данные точно.
3. Когда длина документа превышает длину контекста, и чтобы уменьшить стоимость извлечения с использованием LLM, вы можете использовать семантический поиск для извлечения и представления соответствующих фрагментов документов для LLM во время извлечения.
4. Разберите JSON-вывод и проверьте извлечение LLM.
5. По желанию, создайте резервную копию результатов на Amazon S3 в виде файлов CSV.
6. Загрузите в базу данных SQL для последующего запроса.

Этот процесс управляется следующей архитектурой, где документы в текстовом формате загружаются с помощью Python-скрипта, выполняющегося в задаче Amazon SageMaker Processing для выполнения извлечения.

Для каждой группы сущностей мы динамически создаем запрос, который включает четкое описание задачи извлечения информации и содержит JSON-схему, которая определяет ожидаемый вывод и включает соответствующие фрагменты документов в качестве контекста. Мы также добавляем несколько примеров ввода и правильного вывода, чтобы повысить производительность извлечения с помощью изучения на небольшом количестве данных. Это демонстрируется в notebooks/05-entities-extraction-to-structured-metadata.ipynb.

Часть 3: Создание агентского документного помощника с помощью Amazon Bedrock

В этом разделе мы демонстрируем, как использовать языковые модели Amazon Bedrock LLM для запроса данных и создания агента LLM, который расширяет RAG аналитическими возможностями, позволяя создавать интеллектуальных документных помощников, способных отвечать на сложные доменно-специфичные вопросы по нескольким документам. Вы можете обратиться к функции Lambda на GitHub для конкретной реализации агента и инструментов, описанных в этой части.

Формулирование SQL-запросов и ответ на аналитические вопросы

Теперь, когда у нас есть структурированное хранилище метаданных с извлеченными и загруженными в базу данных SQL соответствующими сущностями, вопрос, который остается, заключается в том, как сформировать правильный SQL-запрос на основе вводимых вопросов на естественном языке?

Современные LLM-модели хорошо справляются с генерацией SQL-запросов. Например, если вы попросите у Anthropic Claude LLM через Amazon Bedrock сформировать SQL-запрос, вы увидите правдоподобные ответы. Однако, нам необходимо придерживаться нескольких правил написания подсказки, чтобы получить более точные SQL-запросы. Эти правила особенно важны для сложных запросов, чтобы уменьшить появление ошибок и проблем с синтаксисом:

• Точно описывайте задачу внутри подсказки
• Включайте схему таблиц SQL внутри подсказки, описывая каждый столбец таблицы и указывая его тип данных
• Явно указывайте LLM использовать только существующие имена столбцов и типы данных
• Добавьте несколько строк из SQL-таблиц

Вы также можете провести постобработку сгенерированного SQL-запроса с помощью легализатора вроде sqlfluff для корректировки форматирования или с помощью парсера, например sqlglot, чтобы определить синтаксические ошибки и оптимизировать запрос. Кроме того, если производительность не соответствует требованиям, вы можете предоставить несколько примеров внутри подсказки, чтобы направить модель с помощью обучения с небольшим количеством данных к генерации более точных SQL-запросов.

С точки зрения реализации, мы используем функцию AWS Lambda для выполнения следующих операций:

1. Вызов модели Anthropic Claude в Amazon Bedrock с вопросом для получения соответствующего SQL-запроса. Здесь мы используем класс SQLDatabase из LangChain для добавления описаний схем соответствующих SQL-таблиц и используем настраиваемую подсказку.
2. Разбор, проверка и выполнение SQL-запроса в базе данных Amazon Aurora, совместимой с PostgreSQL.

Архитектура для этой части решения выделена на следующей диаграмме.

Меры безопасности для предотвращения SQL-инъекций

При включении возможности взаимодействия AI-помощника с базой данных SQL необходимо обеспечить защиту от возможных уязвимостей безопасности. Для этого мы предлагаем следующие меры безопасности для предотвращения атак SQL-инъекций:

• Применение правильных IAM-разрешений – Ограничьте разрешения на выполнение SQL-запросов Lambda-функции с помощью политики и роли Identity and Access Management (IAM), которая следует принципу наименьших привилегий. В данном случае мы предоставляем только чтение.
• Ограничение доступа к данным – Предоставьте доступ только к минимально необходимым таблицам и столбцам для предотвращения возможных утечек информации.
• Добавление слоя модерации – Внедрите слой модерации, который ранним образом обнаруживает попытки внедрения подсказок и предотвращает их передачу в остальную систему. Это может быть система фильтрации на основе правил, сравнение с базой данных известных примеров внедрения подсказок или система машинного обучения.

Поиск по смыслу для расширения контекста генерации

Решение, которое мы предлагаем, использует RAG с семантическим поиском в компоненте 3. Вы можете реализовать этот модуль, используя базы знаний для Amazon Bedrock. Кроме того, существует множество других вариантов для реализации RAG, таких как API извлечения Amazon Kendra, векторная база данных Amazon OpenSearch и Amazon Aurora PostgreSQL с pgvector и другие. Открытый пакет aws-genai-llm-chatbot демонстрирует, как использовать множество этих вариантов поиска по векторам для реализации чат-бота с использованием LLM.

В этом решении, поскольку нам нужны и SQL-запросы, и поиск по векторам, мы решили использовать Amazon Aurora PostgreSQL с расширением pgvector, которое поддерживает оба функционала. Поэтому мы реализуем компонент семантического поиска RAG с помощью следующей архитектуры.

Процесс ответа на вопросы с использованием приведенной архитектуры осуществляется в два основных этапа.

Во-первых, выполняется офлайн-пакетный процесс, запускаемый в качестве задания SageMaker Processing, который создает семантический поисковый индекс следующим образом:

1. Периодически, или при получении новых документов, запускается задание SageMaker.
2. Оно загружает текстовые документы из Amazon S3 и разбивает их на перекрывающиеся фрагменты.
3. Для каждого фрагмента используется модель векторного вложения Amazon Titan для генерации вектора вложения.
4. Он использует класс PGVector из LangChain для внедрения вложений, вместе с фрагментами документа и метаданными, в Amazon Aurora PostgreSQL и создания семантического поискового индекса на всех векторах вложений.

Во-вторых, в реальном времени и для каждого нового вопроса, мы создаем ответ следующим образом:

1. Вопрос получает оркестратор, который работает на функции Lambda.
2. Оркестратор встраивает вопрос с помощью той же модели вложения.
3. Он извлекает несколько наиболее релевантных фрагментов документов из семантического поискового индекса PostgreSQL. При необходимости применяется фильтрация метаданных для повышения точности.
4. Эти фрагменты вставляются динамически в LLM-подсказку наряду с входным вопросом.
5. Подсказка представляется Anthropic Claude на Amazon Bedrock, чтобы он мог ответить на входной вопрос на основе имеющегося контекста.
6. Наконец, сгенерированный ответ отправляется обратно оркестратору.

Агент, способный использовать инструменты для мышления и действий

До сих пор в этой статье мы обсуждали отдельно вопросы, требующие либо RAG, либо аналитического рассуждения. Однако многие вопросы в реальном мире требуют обеих возможностей, иногда в нескольких шагах рассуждения, чтобы получить окончательный ответ. Для поддержки этих более сложных вопросов нам необходимо ввести понятие агента.

Агенты LLM, такие как агенты для Amazon Bedrock, недавно явились перспективным решением способным использовать LLM для рассуждения и адаптации с использованием текущего контекста и выбора соответствующих действий из списка вариантов, что представляет общую каркас проблемы решения задачи. Как обсуждалось в статье LLM Powered Autonomous Agents, существует несколько стратегий подсказки и шаблонов проектирования для агентов LLM, поддерживающих сложное рассуждение.

Одним из таких шаблонов проектирования является Reason and Act (ReAct), представленный в статье ReAct: Synergizing Reasoning and Acting in Language Models. В ReAct агент принимает входной целью вопрос, определяет отсутствующую информацию для его ответа и пошагово предлагает правильный инструмент для сбора информации на основе доступных описаний инструментов. После получения ответа от заданного инструмента LLM переоценивает, обладает ли он всей необходимой информацией для полного ответа на вопрос. Если нет, он продолжает рассуждение и использует тот же или другой инструмент для сбора дополнительной информации, пока окончательный ответ не будет готов или не будет достигнут предел.

Следующая диаграмма последовательностей объясняет, как работает агент ReAct для ответа на вопрос “Покажите мне топ-5 компаний с наивысшими доходами за последние 2 года и определите риски, связанные с лучшей компанией”.

Подробности реализации этого подхода на языке Python описаны в статье Custom LLM Agent. В нашем решении агент и инструменты реализованы с использованием следующей частичной архитектуры.

Для ответа на входящий вопрос мы используем следующие сервисы AWS:

1. Пользователь вводит свой вопрос через пользовательский интерфейс, который вызывает API на Amazon API Gateway.
2. API Gateway отправляет вопрос в функцию Lambda, реализующую исполнителя агента.
3. Агент вызывает LLM с запросом, содержащим описание доступных инструментов, формат инструкций ReAct и входящий вопрос, а затем анализирует следующее действие для завершения.
4. Действие содержит информацию о том, какой инструмент использовать и каким должен быть вход.
5. Если для использования выбран инструмент SQL, исполнитель агента вызывает SQLQA для преобразования вопроса в SQL и его выполнения. Затем он добавляет результат в запрос и снова вызывает LLM, чтобы узнать, может ли он ответить на исходный вопрос или требуются дополнительные действия.
6. Точно так же, если выбран инструмент семантического поиска, то входной параметр действия извлекается и используется для извлечения данных из постгресовского семантического поискового индекса. Результаты добавляются в запрос и проверяется, может ли LLM ответить или нужно еще одно действие.
7. Когда вся информация для ответа на вопрос доступна, агент LLM формулирует окончательный ответ и отправляет его пользователю.

Вы можете расширить агент с помощью дополнительных инструментов. В доступной реализации на GitHub демонстрируется, как можно добавить поисковую систему и калькулятор в качестве дополнительных инструментов к уже упомянутым инструментам SQL и семантического поиска. Для хранения истории текущего разговора мы используем таблицу Amazon DynamoDB.

Из нашего опыта мы установили, что ключевыми факторами успешного агента являются:

• Основной LLM, способный работать с форматом ReAct
• Ясное описание доступных инструментов, когда их использовать и описание аргументов входных данных с, возможно, примером ввода и ожидаемого вывода
• Четкое описание формата ReAct, которому должен следовать LLM
• Предоставление правильных инструментов для решения бизнес-вопроса агенту LLM для использования
• Корректное извлечение выводов из ответов агента LLM при рассуждении

Для оптимизации затрат мы рекомендуем кэшировать наиболее распространенные вопросы с ответами и периодически обновлять этот кэш, чтобы сократить вызовы к основному LLM. Например, вы можете создать семантический поисковый индекс с наиболее распространенными вопросами, как уже объяснялось ранее, и сопоставлять новый вопрос пользователя с этим индексом перед вызовом LLM. Чтобы изучить другие варианты кэширования, обратитесь к руководству LLM Caching integrations.

Поддержка других форматов, таких как видео, изображения, аудио и 3D-файлы

Вы также можете применить ту же самую методику к различным типам информации, таким как изображения, видео, аудио и 3D-файлы дизайна, такие как CAD-файлы или меш-файлы. Это включает использование установленных методов машинного обучения для описания содержимого файла в текстовом формате, который затем может быть загружен в рассматриваемое решение. Этот подход позволяет проводить беседы на базе вопросов и ответов с различными типами данных. Например, вы можете расширить вашу базу документов, создавая текстовые описания изображений, видео или аудио. Вы также можете расширить таблицу метаданных, идентифицируя свойства с помощью классификации или обнаружения объектов элементов в этих форматах. После индексации извлеченных данных в хранилище метаданных или семантический поисковый индекс для документов, общая архитектура предлагаемой системы остается в основном неизменной.

Заключение

В этой статье мы показали, что использование LLM с паттерном проектирования RAG необходимо для создания AI-помощника, специфичного для конкретной области, но недостаточно для достижения требуемого уровня надежности, чтобы создать бизнес-ценность. Поэтому мы предложили расширить популярный паттерн проектирования RAG с понятиями агентов и инструментов, где гибкость инструментов позволяет использовать как традиционные техники NLP, так и современные возможности LLM для создания AI-помощника с большим количеством вариантов поиска информации и помощи пользователям в эффективном решении бизнес-проблем.

Решение демонстрирует процесс проектирования LLM-помощника, способного отвечать на различные типы вопросов по поиску, аналитическому рассуждению и многошаговому рассуждению в пределах всей вашей базы знаний. Мы также подчеркнули важность обратного мышления от типов вопросов и задач, с которыми ожидается помощь вашего LLM-помощника. В данном случае, путешествие проектирования привело нас к архитектуре с тремя компонентами: семантический поиск, извлечение метаданных и SQL-запросы, агент и инструменты LLM, которая, по нашему мнению, является общей и достаточно гибкой для множества случаев использования. Мы также считаем, что, получив вдохновение от этого решения и углубившись в потребности ваших пользователей, вы сможете дальше расширить это решение в соответствии с вашими потребностями.