За последние годы разговорный ИИ прошел долгий путь благодаря быстрому развитию генеративного ИИ, особенно повышению производительности больших языковых моделей (LLM), введенному с помощью таких методов обучения, как точная настройка инструкций и обучение с подкреплением на основе обратной связи от человека. При правильном запросе эти модели могут вести связный диалог без каких-либо данных обучения для конкретной задачи. Однако они не могут хорошо обобщать вопросы, специфичные для предприятия, поскольку для получения ответа они полагаются на общедоступные данные, с которыми они познакомились во время предварительного обучения. Таким данным часто не хватает специальных знаний, содержащихся во внутренних документах, доступных в современном бизнесе, которые обычно необходимы для получения точных ответов в таких областях, как фармацевтические исследования, финансовые расследования и поддержка клиентов.
Чтобы создать ИИ-помощников, способных вести дискуссии, основанные на специализированных знаниях предприятия, нам необходимо подключить эти мощные, но общие LLM к внутренним базам знаний документов. Этот метод обогащения контекста генерации LLM информацией, полученной из ваших внутренних источников данных, называется извлеченной дополненной генерацией (RAG) и создает помощников, которые зависят от предметной области и более заслуживают доверия, как показано на рисунке. Генерация с расширенным поиском для наукоемких задач НЛП. Еще одним фактором популярности RAG является простота его реализации и существование зрелых решений векторного поиска, например, предлагаемых Амазон Кендра (См. Amazon Kendra запускает API поиска) и расширение Сервис Amazon OpenSearch (См. Поиск k-ближайшего соседа (k-NN) в Amazon OpenSearch Service) и другие.
Однако популярный шаблон проектирования RAG с семантическим поиском не может ответить на все типы вопросов, которые возможны в документах. Это особенно актуально для вопросов, которые требуют аналитического рассуждения по нескольким документам. Например, представьте, что вы планируете стратегию инвестиционной компании на следующий год. Одним из важных шагов будет анализ и сравнение финансовых результатов и потенциальных рисков компаний-кандидатов. Это задание включает в себя ответы на вопросы аналитического рассуждения. Например, запрос «Назовите мне 5 крупнейших компаний с самым высоким доходом за последние 2 года и определите их основные риски» требует нескольких этапов рассуждения, некоторые из которых могут использовать семантический поиск, тогда как другие требуют аналитических возможностей.
В этом посте мы покажем, как создать интеллектуального помощника по документам, способного отвечать на аналитические и многоэтапные логические вопросы, состоящие из трех частей. В первой части мы рассмотрим шаблон проектирования RAG и его ограничения в аналитических вопросах. Затем мы познакомим вас с более универсальной архитектурой, которая преодолевает эти ограничения. Часть 1 поможет вам глубже погрузиться в конвейер извлечения сущностей, используемый для подготовки структурированных данных, которые являются ключевым компонентом для аналитических ответов на вопросы. Часть 2 расскажет, как использовать Коренная порода Амазонки LLM для запроса этих данных и создания агента LLM, который расширяет RAG аналитическими возможностями, тем самым позволяя вам создавать интеллектуальных помощников по работе с документами, которые могут отвечать на сложные вопросы, специфичные для конкретной предметной области, в нескольких документах.
Часть 1. Ограничения RAG и обзор решения
В этом разделе мы рассмотрим шаблон проектирования RAG и обсудим его ограничения по аналитическим вопросам. Мы также представляем более универсальную архитектуру, которая преодолевает эти ограничения.
Обзор РАГ
Решения RAG вдохновлены обучение представлению и семантический поиск идеи, которые постепенно внедрялись в задачах ранжирования (например, рекомендации и поиск) и задачах обработки естественного языка (НЛП) с 2010 года.
Популярный подход, используемый сегодня, состоит из трех этапов:
- Задание автономной пакетной обработки принимает документы из входной базы знаний, разбивает их на фрагменты, создает для каждого фрагмента внедрение для представления его семантики с использованием предварительно обученной модели внедрения, например Амазонка Титан модели внедрения, затем использует эти внедрения в качестве входных данных для создания индекса семантического поиска.
- При ответе на новый вопрос в реальном времени входной вопрос преобразуется в встраивание, которое используется для поиска и извлечения наиболее похожих фрагментов документов с использованием метрики сходства, такой как косинусное сходство, и алгоритма приближенного ближайшего соседа. Точность поиска также можно повысить с помощью фильтрации метаданных.
- Подсказка создается путем объединения системного сообщения с контекстом, который формируется из соответствующих фрагментов документов, извлеченных на шаге 2, и самого входного вопроса. Затем это приглашение передается модели LLM для получения окончательного ответа на вопрос из контекста.
Благодаря правильной базовой модели внедрения, способной создавать точные семантические представления фрагментов входного документа и входных вопросов, а также эффективному модулю семантического поиска, это решение способно отвечать на вопросы, требующие извлечения существующей информации в базе данных документов. Например, если у вас есть услуга или продукт, вы можете начать с индексации раздела часто задаваемых вопросов или документации и получить первоначальный диалоговый ИИ, адаптированный к вашему конкретному предложению.
Ограничения RAG на основе семантического поиска
Хотя RAG является важным компонентом современных специализированных ИИ-помощников и разумной отправной точкой для создания диалогового ИИ на основе специализированной базы знаний, он не может отвечать на вопросы, требующие сканирования, сравнения и анализа всех документов в вашей базе знаний. одновременно, особенно когда пополнение основано исключительно на семантическом поиске.
Чтобы понять эти ограничения, давайте еще раз рассмотрим пример принятия решения о том, куда инвестировать, на основе финансовых отчетов. Если бы мы использовали RAG для работы с этими отчетами, мы могли бы задать такие вопросы, как «Каковы риски, с которыми столкнулась компания X в 2022 году» или «Какова чистая выручка компании Y в 2022 году?» Для каждого из этих вопросов соответствующий вектор внедрения, который кодирует семантическое значение вопроса, используется для извлечения топ-K семантически схожих фрагментов документов, доступных в поисковом индексе. Обычно это достигается путем использования приближенного решения ближайших соседей, такого как FAISS, NMSLIB, pgvector или другие., которые стремятся найти баланс между скоростью поиска и отзывом для достижения производительности в реальном времени при сохранении удовлетворительной точности.
Однако предыдущий подход не может точно ответить на аналитические вопросы по всем документам, например: «Какие пять крупнейших компаний имеют самую высокую чистую выручку в 5 году?»
Это связано с тем, что семантический поиск пытается найти K фрагментов документов, наиболее похожих на входной вопрос. Но поскольку ни один из документов не содержит исчерпывающих сводок о доходах, он вернет фрагменты документов, которые просто содержат упоминания о «чистой выручке» и, возможно, «2022 году», не выполняя при этом существенного условия сосредоточения внимания на компаниях с самым высоким доходом. Если мы представим эти результаты поиска LLM в качестве контекста для ответа на входной вопрос, он может сформулировать вводящий в заблуждение ответ или отказаться отвечать, поскольку необходимая правильная информация отсутствует.
Эти ограничения обусловлены замыслом, поскольку семантический поиск не проводит тщательное сканирование всех векторов внедрения для поиска соответствующих документов. Вместо этого он использует приближенные методы ближайшего соседа для поддержания разумной скорости поиска. Ключевой стратегией повышения эффективности этих методов является сегментирование пространства встраивания на группы во время индексации. Это позволяет быстро определить, какие группы могут содержать соответствующие вложения во время поиска, без необходимости парных сравнений. Кроме того, даже традиционные методы ближайших соседей, такие как KNN, которые сканируют все документы, вычисляют только базовые показатели расстояния и не подходят для сложных сравнений, необходимых для аналитических рассуждений. Таким образом, RAG с семантическим поиском не предназначен для ответа на вопросы, требующие аналитического рассуждения во всех документах.
Чтобы преодолеть эти ограничения, мы предлагаем решение, которое сочетает RAG с метаданными и извлечением сущностей, запросами SQL и агентами LLM, как описано в следующих разделах.
Преодоление ограничений RAG с помощью метаданных, SQL и агентов LLM
Давайте более глубоко рассмотрим вопрос, в котором RAG терпит неудачу, чтобы мы могли проследить рассуждения, необходимые для эффективного ответа на него. Этот анализ должен указать нам на правильный подход, который мог бы дополнить RAG в общем решении.
Рассмотрим вопрос: «Какие топ-5 компаний с самым высоким доходом в 2022 году?»
Чтобы ответить на этот вопрос, нам необходимо:
- Определите доход каждой компании.
- Отфильтруйте вниз, чтобы сохранить доходы за 2022 год для каждого из них.
- Отсортируйте доходы в порядке убывания.
- Выделите 5 крупнейших доходов рядом с названиями компаний.
Обычно эти аналитические операции выполняются над структурированными данными с использованием таких инструментов, как 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-запроса.
Чтобы реализовать эти шаги, сначала мы осознаем, что извлечение информации из неструктурированных документов является традиционной задачей НЛП, для которой LLM показывают многообещающие результаты в достижении высокой точности за счет обучения с нулевым или малошаговым обучением. Во-вторых, способность этих моделей генерировать SQL-запросы на естественном языке была доказана годами, как видно из 2020 релиз of Amazon QuickSightQ. Наконец, автоматический выбор подходящего инструмента для конкретного вопроса повышает удобство работы пользователя и позволяет отвечать на сложные вопросы посредством многоэтапного рассуждения. Чтобы реализовать эту функцию, мы углубимся в агентов LLM в следующем разделе.
Подводя итог, можно сказать, что предлагаемое нами решение состоит из следующих основных компонентов:
- Семантический поиск для расширения контекста генерации
- Извлечение структурированных метаданных и запросы с помощью SQL
- Агент, способный использовать правильные инструменты для ответа на вопрос
Обзор решения
На следующей схеме изображена упрощенная архитектура решения. Это поможет вам определить и понять роль основных компонентов и то, как они взаимодействуют для реализации полного поведения LLM-ассистента. Нумерация соответствует порядку операций при реализации этого решения.
На практике мы реализовали это решение, как показано в следующей подробной архитектуре.
Для этой архитектуры мы предлагаем реализацию на GitHub, со слабосвязанными компонентами, где серверная часть (5), конвейеры данных (1, 2, 3) и интерфейсная часть (4) могут развиваться отдельно. Это сделано для упрощения взаимодействия между различными компетенциями при настройке и улучшении решения для производства.
Разверните решение
Чтобы установить это решение в свою учетную запись AWS, выполните следующие действия:
- Клонировать репозиторий на GitHub.
- Установите серверную часть Комплект для разработки облачных сервисов AWS (ЦДК АМС) приложение:
- Откройте приложение
backend
папку. - Run
npm install
для установки зависимостей. - Если вы никогда не использовали AWS CDK в текущей учетной записи и регионе, запустите самонастройки
npx cdk bootstrap
. - Run
npx cdk deploy
развернуть стек.
- Откройте приложение
- При желании запустите
streamlit-ui
следующим образом:- Мы рекомендуем клонировать этот репозиторий в Студия Amazon SageMaker среда. Для получения дополнительной информации см. Подключение к домену Amazon SageMaker с помощью быстрой настройки.
- Внутри
frontend/streamlit-ui
папка, запуститьbash run-streamlit-ui.sh
. - Выберите ссылку следующего формата, чтобы открыть демо-версию:
https://{domain_id}.studio.{region}.sagemaker.aws/jupyter/default/proxy/{port_number}/
.
- Наконец, вы можете запустить Создатель мудреца Амазонки конвейер, определенный в
data-pipelines/04-sagemaker-pipeline-for-documents-processing.ipynb
блокнот для обработки входных PDF-документов и подготовки таблицы SQL и индекса семантического поиска, используемых помощником LLM.
В оставшейся части статьи мы сосредоточимся на объяснении наиболее важных компонентов и вариантов дизайна, чтобы, надеюсь, вдохновить вас при разработке собственного помощника по искусственному интеллекту на основе внутренней базы знаний. Мы предполагаем, что компоненты 1 и 4 просты для понимания, и сосредоточимся на основных компонентах 2, 3 и 5.
Часть 2. Конвейер извлечения сущностей
В этом разделе мы углубимся в конвейер извлечения сущностей, используемый для подготовки структурированных данных, которые являются ключевым компонентом для аналитических ответов на вопросы.
Извлечение текста
Документы обычно хранятся в формате PDF или в виде отсканированных изображений. Они могут состоять из простых макетов абзацев или сложных таблиц и содержать цифровой или рукописный текст. Чтобы правильно извлечь информацию, нам необходимо преобразовать эти необработанные документы в обычный текст, сохранив при этом их исходную структуру. Для этого вы можете использовать Амазонка Текст, который представляет собой службу машинного обучения (ML), предоставляющую зрелые API для извлечения текста, таблиц и форм из цифровых и рукописных данных.
В компоненте 2 мы извлекаем текст и таблицы следующим образом:
- Для каждого документа мы вызываем Amazon Textract для извлечения текста и таблиц.
- Мы используем следующие Скрипт Python воссоздать таблицы как DataFrames pandas.
- Результаты объединяем в один документ и вставляем таблицы в виде уценки.
Этот процесс описан следующей блок-схемой и конкретно продемонстрирован на notebooks/03-pdf-document-processing.ipynb
.
Извлечение сущностей и запросы с использованием LLM
Чтобы эффективно отвечать на аналитические вопросы, вам необходимо извлечь соответствующие метаданные и объекты из базы знаний вашего документа в доступный формат структурированных данных. Мы предлагаем использовать SQL для хранения этой информации и получения ответов из-за его популярности, простоты использования и масштабируемости. Этот выбор также выигрывает от проверенной способности языковых моделей генерировать SQL-запросы на естественном языке.
В этом разделе мы углубимся в следующие компоненты, которые позволяют задавать аналитические вопросы:
- Пакетный процесс, который извлекает структурированные данные из неструктурированных данных с использованием LLM.
- Модуль реального времени, который преобразует вопросы на естественном языке в запросы SQL и извлекает результаты из базы данных SQL.
Вы можете извлечь соответствующие метаданные для поддержки аналитических вопросов следующим образом:
- Определите схему JSON для информации, которую необходимо извлечь, которая содержит описание каждого поля и его типа данных, а также примеры ожидаемых значений.
- Для каждого документа запросите LLM со схемой JSON и попросите его точно извлечь соответствующие данные.
- Если длина документа превышает длину контекста и чтобы снизить стоимость извлечения с помощью LLM, вы можете использовать семантический поиск для извлечения и представления соответствующих фрагментов документов LLM во время извлечения.
- Проанализируйте выходные данные JSON и проверьте извлечение LLM.
- При необходимости создайте резервную копию результатов на Amazon S3 в виде файлов CSV.
- Загрузите в базу данных SQL для последующих запросов.
Этот процесс управляется следующей архитектурой, в которой документы в текстовом формате загружаются с помощью сценария Python, который выполняется в Обработка Amazon SageMaker задание по извлечению.
Для каждой группы сущностей мы динамически создаем приглашение, которое включает четкое описание задачи извлечения информации, а также схему JSON, определяющую ожидаемый результат и включающую соответствующие фрагменты документа в качестве контекста. Мы также добавляем несколько примеров ввода и правильного вывода, чтобы улучшить производительность извлечения с помощью обучения за несколько шагов. Это продемонстрировано в notebooks/05-entities-extraction-to-structured-metadata.ipynb
.
Часть 3. Создайте агентского помощника по работе с документами с помощью Amazon Bedrock
В этом разделе мы покажем, как использовать LLM Amazon Bedrock для запроса данных и создания агента LLM, который расширяет RAG аналитическими возможностями, тем самым позволяя вам создавать интеллектуальных помощников по работе с документами, которые могут отвечать на сложные вопросы, специфичные для конкретной предметной области, в нескольких документах. Вы можете обратиться к Лямбда-функция на GitHub для конкретной реализации агента и инструментов, описанных в этой части.
Формулируйте SQL-запросы и отвечайте на аналитические вопросы.
Теперь, когда у нас есть структурированное хранилище метаданных с соответствующими объектами, извлеченными и загруженными в базу данных SQL, к которой мы можем обращаться, остается вопрос: как сгенерировать правильный SQL-запрос на основе входных вопросов на естественном языке?
Современные LLM хорошо генерируют SQL. Например, если вы запросите у Anthropic Claude LLM через Коренная порода Амазонки для генерации SQL-запроса вы увидите правдоподобные ответы. Однако при написании приглашения нам необходимо соблюдать несколько правил, чтобы обеспечить более точные SQL-запросы. Эти правила особенно важны для сложных запросов, чтобы уменьшить галлюцинации и синтаксические ошибки:
- Точно опишите задачу в подсказке
- Включите схему таблиц SQL в приглашение, описывая каждый столбец таблицы и указывая его тип данных.
- Явно сообщите LLM использовать только существующие имена столбцов и типы данных.
- Добавьте несколько строк таблиц SQL.
Вы также можете постобработать сгенерированный SQL-запрос, используя ЛИНТЕР как sqlfluff для исправления форматирования или синтаксического анализатора, такого как sqlglot для обнаружения синтаксических ошибок и оптимизации запроса. Более того, если производительность не соответствует требованиям, вы можете предоставить несколько примеров в подсказке, чтобы направить модель с помощью пошагового обучения на создание более точных SQL-запросов.
С точки зрения реализации мы используем AWS Lambda функция для организации следующего процесса:
- Вызовите модель Anthropic Claude в Amazon Bedrock с входным вопросом, чтобы получить соответствующий SQL-запрос. Здесь мы используем База данных SQL класс из LangChain, чтобы добавить описания схемы соответствующих таблиц SQL и использовать пользовательскую подсказку.
- Разберите, проверьте и запустите SQL-запрос к Версия, совместимая с Amazon Aurora PostgreSQL база данных.
Архитектура этой части решения показана на следующей диаграмме.
Соображения безопасности для предотвращения атак с использованием SQL-инъекций
Разрешая помощнику искусственного интеллекта запрашивать базу данных SQL, мы должны убедиться, что это не создает уязвимостей безопасности. Для достижения этой цели мы предлагаем следующие меры безопасности для предотвращения атак с использованием SQL-инъекций:
- Применить разрешения IAM с наименьшими привилегиями – Ограничьте разрешение функции Lambda, которая выполняет запросы SQL с помощью Управление идентификацией и доступом AWS (IAM) политика и роль, которые соответствуют принцип наименьших привилегий. В этом случае мы предоставляем доступ только для чтения.
- Ограничить доступ к данным – Обеспечьте доступ только к минимуму таблиц и столбцов, чтобы предотвратить атаки по раскрытию информации.
- Добавьте уровень модерации – Внедрить уровень модерации, который заранее обнаруживает попытки быстрого внедрения и предотвращает их распространение на остальную часть системы. Он может принимать форму фильтров на основе правил, сопоставления сходства с базой данных известных примеров внедрения подсказок или классификатора ML.
Семантический поиск для расширения контекста генерации
Предлагаемое нами решение использует RAG с семантическим поиском в компоненте 3. Вы можете реализовать этот модуль, используя базы знаний для Amazon Bedrock. Кроме того, существует множество других вариантов реализации RAG, например API поиска Amazon Kendra, База данных векторов Amazon OpenSearchи Amazon Aurora PostgreSQL с pgvector, среди других. Пакет с открытым исходным кодом aws-genai-llm-чат-бот демонстрирует, как использовать многие из этих вариантов векторного поиска для реализации чат-бота на базе LLM.
В этом решении, поскольку нам нужны как SQL-запросы, так и векторный поиск, мы решили использовать Amazon Aurora PostgreSQL с pgvector расширение, которое поддерживает обе функции. Поэтому мы реализуем компонент RAG семантического поиска со следующей архитектурой.
Процесс ответа на вопросы с использованием предыдущей архитектуры выполняется в два основных этапа.
Сначала автономный пакетный процесс, запускаемый как задание SageMaker Processing, создает индекс семантического поиска следующим образом:
- Либо периодически, либо при получении новых документов запускается задание SageMaker.
- Он загружает текстовые документы из Amazon S3 и разбивает их на перекрывающиеся фрагменты.
- Для каждого фрагмента используется модель внедрения Amazon Titan для создания вектора внедрения.
- Он использует PGVector класс из LangChain для приема внедрений с фрагментами документов и метаданных в Amazon Aurora PostgreSQL и создания индекса семантического поиска по всем векторам внедрения.
Во-вторых, в реальном времени и на каждый новый вопрос мы строим ответ следующим образом:
- Вопрос принимает оркестратор, работающий на функции Lambda.
- Оркестратор встраивает вопрос с помощью той же модели внедрения.
- Он извлекает топ-K наиболее релевантных фрагментов документов из индекса семантического поиска PostgreSQL. Он опционально использует фильтрацию метаданных для повышения точности.
- Эти фрагменты динамически вставляются в подсказку LLM вместе с входным вопросом.
- Подсказка предоставляется Антропику Клоду на Amazon Bedrock, чтобы дать ему указание ответить на входной вопрос на основе доступного контекста.
- Наконец, сгенерированный ответ отправляется обратно оркестратору.
Агент, способный использовать инструменты для рассуждения и действия.
До сих пор в этом посте мы обсуждали отдельно рассмотрение вопросов, требующих либо RAG, либо аналитических рассуждений. Однако многие вопросы реального мира требуют обеих способностей, иногда требующих нескольких этапов рассуждения, чтобы прийти к окончательному ответу. Чтобы ответить на эти более сложные вопросы, нам нужно ввести понятие агента.
Агенты LLM, такие как агенты Amazon Bedrock, недавно появились как многообещающее решение, позволяющее использовать LLM для обоснования и адаптации с использованием текущего контекста, а также для выбора соответствующих действий из списка вариантов, который представляет собой общую структуру решения проблем. Как обсуждалось в Автономные агенты на базе LLM, существует множество стратегий подсказок и шаблонов проектирования для агентов LLM, которые поддерживают сложные рассуждения.
Одним из таких шаблонов проектирования является Reason and Act (ReAct), представленный в ReAct: синергия рассуждений и действий в языковых моделях. В ReAct агент принимает в качестве входных данных цель, которая может быть вопросом, определяет фрагменты информации, недостающие для ответа на нее, и итеративно предлагает правильный инструмент для сбора информации на основе описаний доступных инструментов. После получения ответа от данного инструмента LLM повторно оценивает, есть ли у него вся информация, необходимая для полного ответа на вопрос. Если нет, он делает еще один шаг рассуждений и использует тот же или другой инструмент для сбора дополнительной информации, пока не будет готов окончательный ответ или не будет достигнут предел.
Следующая диаграмма последовательности объясняет, как агент ReAct работает над ответом на вопрос: «Назовите мне 5 крупнейших компаний с самым высоким доходом за последние 2 года и определите риски, связанные с первой из них».
Подробности реализации этого подхода в Python описаны в Пользовательский агент LLM. В нашем решении агент и инструменты реализованы со следующей выделенной частичной архитектурой.
Чтобы ответить на входной вопрос, мы используем сервисы AWS следующим образом:
- Пользователь вводит свой вопрос через пользовательский интерфейс, который вызывает API Шлюз API Amazon.
- API Gateway отправляет вопрос в функцию Lambda, реализующую исполнителя агента.
- Агент вызывает LLM с приглашением, содержащим описание доступных инструментов, формат инструкций ReAct и входной вопрос, а затем анализирует следующее действие, которое необходимо выполнить.
- Действие содержит информацию о том, какой инструмент вызывать и каковы входные данные действия.
- Если в качестве инструмента используется SQL, исполнитель агента вызывает SQLQA, чтобы преобразовать вопрос в SQL и запустить его. Затем он добавляет результат в приглашение и снова вызывает LLM, чтобы узнать, сможет ли он ответить на исходный вопрос или необходимы дополнительные действия.
- Аналогично, если используемым инструментом является семантический поиск, входные данные действия анализируются и используются для извлечения из индекса семантического поиска PostgreSQL. Он добавляет результаты в запрос и проверяет, может ли LLM ответить или требуется другое действие.
- После того, как вся информация для ответа на вопрос доступна, агент LLM формулирует окончательный ответ и отправляет его обратно пользователю.
Вы можете расширить агент дополнительными инструментами. В реализации, доступной на GitHubмы демонстрируем, как можно добавить поисковую систему и калькулятор в качестве дополнительных инструментов к вышеупомянутой системе SQL и инструментам семантического поиска. Для хранения текущей истории разговоров мы используем Amazon DynamoDB таблице.
Из нашего опыта мы поняли, что ключом к успешному агенту являются следующие факторы:
- Базовый LLM, способный рассуждать в формате ReAct.
- Четкое описание доступных инструментов, когда их использовать, а также описание их входных аргументов с, возможно, примером входных данных и ожидаемого результата.
- Четкое описание формата ReAct, которому должен следовать LLM.
- Агенту LLM доступны правильные инструменты для решения бизнес-вопроса.
- Правильный анализ выходных данных ответов агента LLM по мере их обоснования.
Чтобы оптимизировать затраты, мы рекомендуем кэшировать наиболее распространенные вопросы с ответами на них и периодически обновлять этот кеш, чтобы уменьшить количество обращений к базовому LLM. Например, вы можете создать индекс семантического поиска с наиболее распространенными вопросами, как объяснялось ранее, и сначала сопоставить новый вопрос пользователя с индексом, прежде чем вызывать LLM. Чтобы изучить другие варианты кэширования, см. Интеграция кэширования LLM.
Поддержка других форматов, таких как видео, изображения, аудио и 3D-файлы.
Вы можете применить одно и то же решение к различным типам информации, например изображениям, видео, аудио и файлам 3D-проектирования, таким как файлы САПР или сетки. Это предполагает использование традиционных методов машинного обучения для описания содержимого файла в текстовом виде, который затем можно использовать в решении, которое мы рассматривали ранее. Такой подход позволяет вам проводить беседы по обеспечению качества для этих разнообразных типов данных. Например, вы можете расширить свою базу данных документов, создавая текстовые описания изображений, видео или аудиоконтента. Вы также можете улучшить таблицу метаданных, определяя свойства посредством классификации или обнаружения объектов в элементах в этих форматах. После того как эти извлеченные данные индексируются либо в хранилище метаданных, либо в индексе семантического поиска документов, общая архитектура предлагаемой системы остается в значительной степени согласованной.
Заключение
В этом посте мы показали, что использование LLM с шаблоном проектирования RAG необходимо для создания специализированного ИИ-помощника, но недостаточно для достижения необходимого уровня надежности для создания ценности для бизнеса. В связи с этим мы предложили расширить популярный шаблон проектирования RAG концепциями агентов и инструментов, где гибкость инструментов позволяет нам использовать как традиционные методы НЛП, так и современные возможности LLM, чтобы предоставить ИИ-помощнику больше возможностей для поиска информации и помощи. пользователей в эффективном решении бизнес-задач.
Решение демонстрирует процесс проектирования помощника LLM, способного отвечать на различные типы поиска, аналитических рассуждений и многоэтапных логических вопросов по всей вашей базе знаний. Мы также подчеркнули важность мышления в обратном направлении, от типов вопросов и задач, с которыми ваш помощник LLM должен помогать пользователям. В этом случае путь проектирования привел нас к архитектуре с тремя компонентами: семантический поиск, извлечение метаданных и SQL-запросы, а также агент и инструменты LLM, которые, по нашему мнению, являются универсальными и достаточно гибкими для различных вариантов использования. Мы также считаем, что, черпая вдохновение из этого решения и углубляясь в потребности ваших пользователей, вы сможете расширить это решение в сторону того, что лучше всего подходит для вас.
Об авторах
Мохамед Али Джамауи — старший архитектор прототипов машинного обучения с 10-летним опытом работы в сфере машинного обучения. Ему нравится решать бизнес-задачи с помощью машинного обучения и разработки программного обеспечения, а также помогать клиентам извлекать выгоду для бизнеса с помощью машинного обучения. В рамках подразделения AWS EMEA по прототипированию и облачному проектированию он помогает клиентам создавать бизнес-решения, использующие инновации в области MLOP, NLP, CV и LLM.
Джузеппе Ханнен является ассоциированным консультантом ProServe. Джузеппе применяет свои аналитические навыки в сочетании с искусственным интеллектом и машинным обучением для разработки четких и эффективных решений для своих клиентов. Он любит придумывать простые решения сложных проблем, особенно тех, которые связаны с новейшими технологическими разработками и исследованиями.
Лоуренс тен Кейт является старшим специалистом по данным. Лоренс работает с корпоративными клиентами в регионе EMEA, помогая им ускорить результаты своего бизнеса с помощью технологий AWS AI/ML. Он специализируется на решениях НЛП и фокусируется на сфере цепочек поставок и логистики. В свободное время увлекается чтением и искусством.
Ирина Раду — менеджер по взаимодействию с прототипами в подразделении AWS EMEA по прототипированию и облачному проектированию. Она помогает клиентам получить максимальную отдачу от новейших технологий, быстрее внедрять инновации и мыслить масштабнее.
- SEO-контент и PR-распределение. Получите усиление сегодня.
- PlatoData.Network Вертикальный генеративный ИИ. Расширьте возможности себя. Доступ здесь.
- ПлатонАйСтрим. Интеллект Web3. Расширение знаний. Доступ здесь.
- ПлатонЭСГ. Углерод, чистые технологии, Энергия, Окружающая среда, Солнечная, Управление отходами. Доступ здесь.
- ПлатонЗдоровье. Биотехнологии и клинические исследования. Доступ здесь.
- Источник: https://aws.amazon.com/blogs/machine-learning/boosting-rag-based-intelligent-document-assistants-using-entity-extraction-sql-querying-and-agents-with-amazon-bedrock/
- :имеет
- :является
- :нет
- :куда
- $UP
- 1
- 10
- 100
- 2022
- 3d
- 7
- a
- способность
- в состоянии
- О нас
- ускорять
- доступ
- доступной
- выполнено
- Учетная запись
- точность
- точный
- точно
- Достигать
- достижение
- через
- Действие (Act):
- действующий
- Действие
- действия
- приспосабливать
- Добавить
- Дополнительно
- Добавляет
- принял
- После
- снова
- против
- Агент
- агенты
- AI
- Помощник АИ
- AI / ML
- алгоритм
- Выравнивает
- Все
- позволяет
- рядом
- причислены
- Amazon
- Создатель мудреца Амазонки
- Амазонка Текст
- Amazon Web Services
- среди
- an
- анализ
- Аналитические фармацевтические услуги
- анализировать
- и
- Другой
- ответ
- ответы
- Антропный
- любой
- API
- API
- применяется
- Применить
- подхода
- соответствующий
- приблизительный
- архитектура
- МЫ
- Аргументы
- около
- Искусство
- AS
- спросить
- помощь
- помощник
- помощники
- Юрист
- связанный
- предполагать
- At
- нападки
- попытки
- аудио
- увеличивать
- дополненная
- Aurora
- автоматически
- автономный
- доступен
- AWS
- назад
- Backend
- Баланс
- Использование темпера с изогнутым основанием
- основанный
- основной
- BE
- , так как:
- было
- до
- поведение
- за
- верить
- Преимущества
- ЛУЧШЕЕ
- между
- Beyond
- больший
- стимулирование
- изоферменты печени
- строить
- Строительство
- бизнес
- бизнес
- но
- by
- Кэш
- CAD
- призывают
- под названием
- вызова
- Объявления
- CAN
- кандидат
- возможности
- способный
- нести
- случаев
- случаев
- цепь
- Chatbot
- Проверки
- выбор
- выбор
- Выберите
- класс
- классификация
- Очистить
- облако
- ПОСЛЕДОВАТЕЛЬНЫЙ
- сотрудничество
- Column
- Колонки
- сочетание
- комбинаты
- как
- Общий
- Компании
- Компания
- сравнить
- сравнив
- сравнения
- комплемент
- полный
- комплекс
- сложный
- компонент
- компоненты
- состоящие
- комплексный
- Вычисление
- понятия
- бетон
- состояние
- Проводить
- Свяжитесь
- Рассматривать
- соображения
- последовательный
- консолидировать
- строить
- консультант
- содержать
- содержащегося
- содержит
- содержание
- контекст
- Разговор
- диалоговый
- разговорный ИИ
- Беседы
- конвертировать
- переделанный
- Основные
- исправить
- правильно
- соответствующий
- Цена
- Расходы
- может
- соединенный
- Создайте
- создает
- Создающий
- Текущий
- изготовленный на заказ
- клиент
- служба поддержки
- Клиенты
- данным
- доступ к данным
- ученый данных
- База данных
- решенный
- Решение
- глубоко
- более глубокий
- определенный
- Определяет
- копаться
- Спрос
- демонстрация
- демонстрировать
- убивают
- демонстрирует
- Зависимости
- развертывание
- описывать
- описано
- описывающих
- описание
- Проект
- шаблоны проектирования
- процесс проектирования
- проектирование
- подробный
- подробнее
- обнаруживать
- обнаружение
- развивать
- Развитие
- события
- Интернет
- раскрытие
- обсуждать
- обсуждается
- обсуждение
- расстояние
- погружение
- Разное
- дайвинг
- do
- документ
- документации
- Документация
- приносит
- не
- домен
- доменов
- сделанный
- вниз
- водитель
- два
- в течение
- динамично
- каждый
- Ранее
- Рано
- простота
- простота в использовании
- легко
- Эффективный
- фактически
- затрат
- эффективный
- эффективно
- или
- элементы
- вложения
- в регионе EMEA
- появившийся
- используя
- включить
- позволяет
- позволяет
- конец
- обязательство
- Двигатель
- Проект и
- Двигатели
- повышать
- Усиливает
- достаточно
- обогащение
- Предприятие
- лиц
- организация
- Окружающая среда
- ошибки
- особенно
- существенный
- установленный
- Даже
- развивается
- исследовать
- пример
- Примеры
- существование
- существующий
- Расширьте
- ожидаемый
- опыт
- объяснены
- объясняя
- Объясняет
- Больше
- Разведанный
- подвергаться
- продлить
- простирающийся
- расширение
- дополнительно
- извлечение
- добыча
- Экстракты
- сталкиваются
- не удается
- FAQ
- далеко
- быстрее
- Особенность
- Особенности
- Обратная связь
- несколько
- поле
- Файл
- Файлы
- фильтрация
- фильтры
- окончательный
- в заключение
- финансовый
- Найдите
- Во-первых,
- Трансформируемость
- гибкого
- поток
- Фокус
- фокусировка
- после
- следующим образом
- Что касается
- форма
- формат
- сформированный
- формы
- Рамки
- Бесплатно
- от
- передний
- Внешний интерфейс
- выполнение
- полный
- полностью
- функция
- далее
- шлюз
- собирать
- Общие
- порождать
- генерируется
- порождающий
- поколение
- генеративный
- Генеративный ИИ
- получить
- получающий
- GitHub
- данный
- цель
- хорошо
- постепенно
- предоставлять
- группы
- Группы
- было
- Есть
- имеющий
- he
- помощь
- помощь
- помогает
- здесь
- High
- наивысший
- Выделенные
- его
- история
- С надеждой
- Как
- How To
- Однако
- HTML
- HTTPS
- человек
- идеи
- идентифицирует
- определения
- идентифицирующий
- Личность
- if
- изображение
- изображений
- картина
- осуществлять
- реализация
- в XNUMX году
- Осуществляющий
- значение
- важную
- улучшать
- улучшенный
- улучшение
- улучшение
- in
- включает в себя
- индекс
- индексированный
- промышленность
- информация
- извлечение информации
- начальный
- обновлять
- инновации
- вход
- затраты
- Вдохновение
- внушать
- вдохновленный
- устанавливать
- пример
- вместо
- интегрировать
- Умный
- взаимодействовать
- в нашей внутренней среде,
- в
- вводить
- выпустили
- Грин- карта инвестору
- ходе расследования,
- инвестиций
- включать в себя
- IT
- ЕГО
- саму трезвость
- работа
- путешествие
- JPG
- JSON
- Сохранить
- Основные
- ключи
- знания
- известный
- язык
- большой
- в значительной степени
- Фамилия
- новее
- последний
- запускает
- слой
- изучение
- наименее
- привело
- Длина
- уровень
- Кредитное плечо
- такое как
- ОГРАНИЧЕНИЯ
- недостатки
- LINK
- Список
- LLM
- грузы
- логистика
- индустрия логистики
- Длинное
- любит
- машина
- обучение с помощью машины
- сделанный
- Главная
- поддерживать
- Сохранение
- сделать
- управляемого
- менеджер
- многих
- Совпадение
- согласование
- зрелый
- Май..
- me
- смысл
- меры
- Встречайте
- упоминает
- просто
- сетке
- сообщение
- Метаданные
- метод
- методы
- метрический
- Метрика
- минимальный
- дезориентировать
- отсутствующий
- ML
- млн операций в секунду
- модель
- Модели
- умеренность
- Модерн
- Модули
- БОЛЕЕ
- Более того
- самых
- с разными
- должен
- имена
- натуральный
- Обработка естественного языка
- необходимо
- Необходимость
- необходимый
- потребности
- соседи
- сеть
- чистый доход
- никогда
- Новые
- следующий
- НЛП
- Ничто
- ноутбук
- понятие
- объект
- Обнаружение объекта
- of
- предложенный
- предлагающий
- оффлайн
- .
- on
- ONE
- постоянный
- только
- открытый
- с открытым исходным кодом
- Операционный отдел
- Оптимизировать
- Опции
- or
- заказ
- оригинал
- Другое
- Другое
- наши
- внешний
- Результаты
- контур
- изложенные
- выходной
- выходы
- за
- общий
- Преодолеть
- собственный
- пакет
- панд
- часть
- части
- шаблон
- паттеранами
- Выполнять
- производительность
- разрешение
- перспектива
- в Фармацевтической отрасли
- штук
- трубопровод
- одноцветный
- планирование
- Платон
- Платон Интеллектуальные данные
- ПлатонДанные
- правдоподобный
- Точка
- политика
- Популярное
- популярность
- населенный
- возможное
- возможно
- После
- Postgresql
- потенциал
- потенциально
- Питание
- мощный
- практика
- Точность
- Подготовить
- представить
- представлены
- разрабатывает
- консервирование
- предотвращать
- предотвращает
- предварительно
- привилегия
- решение проблем
- проблемам
- процесс
- обработка
- производит
- производства
- Продукт
- Производство
- обещание
- многообещающий
- свойства
- предлагает
- предложило
- предлагает
- макетирования
- доказанный
- обеспечивать
- приводит
- что такое варган?
- Питон
- Вопросы и ответы
- Запросы
- вопрос
- Вопросы
- САЙТ
- быстро
- Ранжирование
- быстро
- Сырье
- достигать
- достиг
- реагировать
- Reading
- готовый
- реальные
- реальный мир
- реального времени
- причина
- разумный
- получила
- получение
- последний
- недавно
- признавать
- рекомендовать
- Рекомендация
- уменьшить
- относиться
- область
- соответствующие
- надежность
- полагаться
- остатки
- Отчеты
- хранилище
- представлять
- запросить
- требовать
- обязательный
- требование
- требуется
- исследованиям
- ответ
- ответы
- ОТДЫХ
- результат
- Итоги
- возвращают
- доходы
- поступления
- обзоре
- правую
- рисках,
- Роли
- условиями,
- Run
- Бег
- работает
- sagemaker
- то же
- Масштабируемость
- сканирование
- сканирование
- Ученый
- скрипт
- Поиск
- Поисковая система
- Во-вторых
- Раздел
- разделах
- безопасность
- Меры безопасности
- посмотреть
- Искать
- видел
- выбор
- выбор
- семантика
- посылает
- старший
- послать
- Последовательность
- обслуживание
- Услуги
- она
- должен
- показывать
- показал
- показанный
- аналогичный
- просто
- упрощенный
- упростить
- одновременно
- с
- одинарной
- навыки
- So
- уже
- Software
- разработка программного обеспечения
- только
- Решение
- Решения
- Решение
- некоторые
- иногда
- Источник
- Источники
- Space
- специализированный
- специализируется
- конкретный
- скорость
- расколы
- стек
- этапы
- Начало
- Начало
- управлять
- Шаг
- Шаги
- магазин
- хранить
- простой
- стратегий
- Стратегия
- удар
- стараться
- Структура
- структурированный
- студия
- успешный
- такие
- предлагать
- подходящее
- суммировать
- поставка
- цепочками поставок
- поддержка
- Поддержка
- Убедитесь
- синтаксис
- система
- ТАБЛИЦЫ
- с учетом
- взять
- принимает
- Сложность задачи
- задачи
- технологии
- снижения вреда
- технологический
- технологии
- сказать
- 10
- текст
- текстовый
- Спасибо
- который
- Ассоциация
- информация
- их
- Их
- тогда
- Там.
- тем самым
- следовательно
- Эти
- они
- think
- мышление
- этой
- те
- три
- Через
- время
- исполин
- в
- сегодня
- инструментом
- инструменты
- топ
- топ 5
- к
- к
- Прослеживать
- традиционный
- Обучение
- Transform
- лечения
- правда
- заслуживающий доверия
- два
- напишите
- Типы
- типично
- ui
- лежащий в основе
- понимать
- до
- обновление
- на
- us
- использование
- используемый
- Информация о пользователе
- Пользовательский опыт
- пользователей
- использования
- через
- VALIDATE
- ценностное
- Наши ценности
- разнообразие
- различный
- разносторонний
- Видео
- Видео
- Уязвимости
- прогулки
- Путь..
- we
- Web
- веб-сервисы
- ЧТО Ж
- были
- Что
- когда
- в то время как
- будь то
- , которые
- в то время как
- зачем
- Википедия.
- будете
- в
- без
- работает
- бы
- письмо
- X
- год
- лет
- Ты
- ВАШЕ
- зефирнет