Как SnapLogic создал приложение для преобразования текста в конвейер с помощью Amazon Bedrock для перевода бизнес-намерений в действия

Как SnapLogic использовал Amazon Bedrock для разработки приложения, преобразующего текст в конвейер, и перевода бизнес-намерений в действия

Данный пост был соавторстве Грега Бенсона, главного ученого; Аарона Кеслера, старшего менеджера по продукту; и Рича Дила, архитектора корпоративных решений из SnapLogic.

Множество клиентов создают генеративные приложения искусственного интеллекта на Amazon Bedrock и Amazon CodeWhisperer, чтобы создавать кодовые артефакты на основе естественного языка. Этот случай использования подчеркивает, как большие языковые модели (LLM) могут стать переводчиком между человеческими языками (английский, испанский, арабский и другие) и машинно-интерпретируемыми языками (Python, Java, Scala, SQL и т. д.) вместе с сложным внутренним рассуждением. Эта возникающая способность в LLM заставляет разработчиков программного обеспечения использовать LLM как инструмент автоматизации и улучшения UX, преобразующий естественный язык в язык, специфичный для определенной области (DSL): системные инструкции, запросы API, кодовые артефакты и т. д. В этом посте мы покажем вам, как SnapLogic, клиент AWS, использовал Amazon Bedrock для оснащения своего продукта SnapGPT автоматическим созданием таких сложных DSL-артефактов на основе естественного языка.

При создании DSL-объектов из LLM результирующий DSL является либо точной копией, либо производным от существующих данных и схемы интерфейса, которые составляют контракт между пользовательским интерфейсом и бизнес-логикой в обслуживающем сервисе. Этот шаблон особенно популярен с независимыми поставщиками программного обеспечения (ISV) и поставщиками программного обеспечения в виде сервиса (SaaS) из-за их особого способа представления конфигураций через код и желания упростить пользовательский опыт для своих клиентов. Примеры использования включают:

• Преобразование естественного языка в инструмент-специфичные визуальные и вычислительные выражения, как это видно в недавно анонсированных генеративных возможностях BI в Amazon QuickSight
• Создание правильного вызова API на основе намерений и контекста каждого отдельного пользователя в лучших приложениях SaaS для повышения продуктивности с помощью предстоящего функционала для повышения продуктивности в AWS AppFabric
• Создание сложных интеграционных конвейеров с помощью простых человеческих подсказок, о которых вы узнаете больше в этом посте

Самый простой способ создания и масштабирования приложений текст-к пайплайн с использованием LLM на AWS – это использование Amazon Bedrock. Amazon Bedrock – это самый простой способ создавать и масштабировать генеративные приложения искусственного интеллекта с использованием фундаментальных моделей (FMs). Это полностью управляемый сервис, который предлагает доступ к выбору высокопроизводительных базовых FM от ведущих AI с помощью единого API, а также широкий набор функций, необходимых для создания генеративных приложений ИИ с соблюдением конфиденциальности и безопасности. Anthropic, исследовательская лаборатория по безопасности и исследованиям ИИ, которая создает надежные, интерпретируемые и управляемые ИИ-системы, является одной из ведущих компаний по разработке ИИ, которая предоставляет доступ к своей передовой LLM, Слод, на Amazon Bedrock. Слод – это LLM, который отлично справляется с широким спектром задач, от осмысленного диалога, создания контента, сложного рассуждения, творчества и программирования. Anthropic предлагает как модели Слод, так и мгновенные модели Слод, все они доступны через Amazon Bedrock. Слод быстро набрал популярность в этих приложениях текст-к пайплайн благодаря его улучшенной способности рассуждения, что позволяет ему преуспевать в неоднозначном техническом решении проблем. Слод 2 на Amazon Bedrock поддерживает контекстное окно из 100 000 токенов, что эквивалентно около 200 страницам английского текста. Это особенно важная функция, на которую вы можете положиться при создании приложений текст-к пайплайн, требующих сложного рассуждения, подробных инструкций и комплексных примеров.

• Оптимизация затрат для Amazon SageMaker Canvas с автоматическим отключением неактивных приложений
• Автоматизация создания описания продуктов с помощью платформы Amazon Bedrock
• Ускорение разработки искусственного интеллекта и машинного обучения в BMW Group с помощью Amazon SageMaker Studio

Фон SnapLogic

SnapLogic – это клиент AWS, который стремится привнести предприятий в мир автоматизации. Платформа интеллектуальной интеграции SnapLogic (IIP) позволяет организациям реализовать автоматизацию на всю компанию, связывая всю экосистему приложений, баз данных, больших данных, машин и устройств, API и многого другого с помощью предварительно созданных интеллектуальных соединителей под названием Snaps. SnapLogic недавно выпустил функцию SnapGPT, которая предоставляет текстовый интерфейс, где вы можете вводить желаемый конвейер интеграции, который вы хотите создать на простом человеческом языке. SnapGPT использует модель Claude от Anthropic через Amazon Bedrock для автоматического создания этих интеграционных конвейеров в виде кода, которые затем используются в основном решении интеграции SnapLogic. Однако путь SnapLogic к SnapGPT был результатом многолетней работы в области ИИ.

AI-путешествие SnapLogic

В области платформ интеграции SnapLogic всегда был на переднем крае, используя трансформационную силу искусственного интеллекта. На протяжении многих лет явственно видно, что компания после Iris добралась до AutoLink, продвигаясь с инновациями в области ИИ.

Скромные начала с Iris

В 2017 году SnapLogic представил Iris – первый в отрасли интеграционный помощник на базе ИИ. Iris была создана для использования алгоритмов машинного обучения (МО) для прогнозирования следующих шагов в создании конвейера данных. Анализируя миллионы метаданных и потоков данных, Iris могла делать интеллектуальные предложения пользователям, демократизируя интеграцию данных и позволяя даже тем, у кого нет глубоких технических знаний, создавать сложные рабочие процессы.

AutoLink: Построение инерции

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

Прорыв с SnapGPT

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

SnapGPT имеет огромное влияние на клиентов SnapLogic, поскольку они могут существенно сократить время, необходимое для создания первого конвейера SnapLogic. Ранее клиентам SnapLogic требовалось проводить дни или недели на настройку конвейера интеграции с нуля. Теперь эти клиенты могут просто попросить SnapGPT создать, например, “конвейер, который переместит всех моих активных клиентов SFDC в WorkDay”. Рабочий начальный вариант конвейера создается автоматически для этого клиента, что значительно сокращает время разработки для создания основы интеграционного конвейера. Это позволяет конечным клиентам больше времени уделять тому, что имеет настоящий бизнес-влияние, вместо работы с конфигурацией интеграционного конвейера. В следующем примере показано, как клиент SnapLogic может ввести описание в функцию SnapGPT, чтобы быстро создать конвейер при помощи естественного языка.

AWS и SnapLogic тесно сотрудничали на протяжении всего процесса разработки продукта и получили много ценного опыта. Оставшаяся часть этого поста будет сфокусирована на техническом опыте AWS и SnapLogic в использовании LLM для приложений преобразования текста в конвейеры.

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

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

Запрос к SnapGPT проходит следующий рабочий процесс:

1. Пользователь отправляет описание приложению.
2. SnapLogic использует подход Retrieval Augmented Generation (RAG) для поиска релевантных примеров конвейеров SnapLogic, похожих на запрос пользователя.
3. Извлеченные релевантные примеры комбинируются с пользовательским вводом и проходят предварительную обработку текста, прежде чем отправляются на Claude на платформе Amazon Bedrock.
4. Claude создает JSON-артефакт, представляющий конвейер SnapLogic.
5. JSON-артефакт напрямую интегрируется в основную платформу интеграции SnapLogic.
6. Конвейер SnapLogic выводится пользователю в визуально понятном виде.

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

Подсказка для экспериментов

Во время разработки SnapGPT AWS и SnapLogic обнаружили, что быстрая итерация по подсказкам, отправляемым Клоду, является ключевой задачей развития для повышения точности и актуальности выводов текст-на-пайплайн в SnapLogic. Используя интерактивные блокноты Amazon SageMaker Studio, команда AWS и SnapLogic смогла быстро работать с разными версиями подсказок с помощью подключения к Amazon Bedrock SDK Boto3. Разработка на основе блокнотов позволила командам быстро создавать соединения с клиентской стороны к Amazon Bedrock, включать текстовые описания вместе с кодом Python для отправки подсказок в Amazon Bedrock и проводить совместные сессии по инженерии подсказок, в ходе которых были быстро внесены изменения множества персон.

Методы инженерии подсказок Anthropic Claude

В этом разделе мы описываем некоторые итерационные техники, которые мы использовали для создания высокопроизводительной подсказки на основе иллюстративного запроса пользователя: «Создать пайплайн, который использует базу данных ExampleCompany для извлечения всех активных клиентов». Обратите внимание, что это пример не является схемой, на которой работает SnapGPT, и используется только для иллюстрации текста-на-пайплайн приложения.

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

Создать пайплайн, который использует базу данных ExampleCompany для извлечения всех активных клиентов

Ожидаемый вывод:

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.customers WHERE status = 'active'"}

Улучшение №1: Использование аннотаций Человека и Помощника

Процедура обучения Клода учит FM понимать диалог между человеком и ассистентом в структуре подсказки. Пользователи Клода могут воспользоваться этой структурой, завершив свою подсказку на Assistant:, что позволит Клоду начать генерацию ответа на запрос, основываясь на том, что сказал человек. Обратите внимание, что Клод будет продолжать генерировать текст, пока ему не скажут остановиться, поэтому убедитесь, что вы используете последовательность остановки \ n \nHuman: в запросе API к Amazon Bedrock при использовании Клода. Это гарантирует, что вы получите только ответ от помощника, а не предсказанный следующий ответ от человека в цепочке диалога. Эти индикаторы \n\nHuman и \n\nAssistant помогают не только ограничить ответ Клода только релевантной информацией, но и обеспечить четкую границу между основными входами человека и ответами помощника от других взаимодействий. Это особенно полезно в среде с несколькими запросами, где можно иметь несколько запросов и ответов с запросами, помеченными \n\nHuman и предыдущими ответами, помеченными \n\nAssistant. Давайте рассмотрим улучшенную подсказку и связанный иллюстративный API-вызов в Amazon Bedrock через SDK Boto3.

Мы используем следующую подсказку:

Human: Создать пайплайн, который использует базу данных ExampleCompany для извлечения всех активных клиентов

Assistant:

Вывод следующий:

Вот пайплайн MongoDB для извлечения всех активных клиентов из базы данных ExampleCompany:

pipeline = [    {        '$match': {            'database': 'ExampleCompany',             'status': 'active'        }    }]db.customers.aggregate(pipeline)

Основные шаги:

– `$match`, чтобы отфильтровать документы только те, которые находятся в базе ExampleCompany и с положительным статусом.

– `db.customers.aggregate()` выполняет пайплайн в коллекции customers и возвращает отфильтрованные результаты.

Таким образом, будет возвращены все документы клиентов из базы данных ExampleCompany, где поле статуса установлено как «активное».

Обратите внимание, как в выводе Клод придумывает ответ на наш вопрос без какого-либо контекста. Ответ потенциально полезен, но не относится к решаемой нами проблеме, потому что не предоставляется достаточный контекст. Также важно отметить, что Anthropic требует такой формат человека и помощника при использовании моделей Клода. Если вы не включите этот шаг, Amazon Bedrock вернет ошибку.

Улучшение №2: Включение гиперспецифического контекста для Клода до того, как он узнает, что делать

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

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

Давайте объединим эти предложения, чтобы улучшить нашу первоначальную просьбу:

Человек: Ваша задача заключается в том, чтобы выступать в роли эксперта по ETL-пайплайнам. Конкретно, ваша задача заключается в создании JSON-представления ETL-пайплайна, которое решит предоставленный вам пользовательский запрос.

JSON-вывод должен следовать следующему формату:

{  "database": "имя базы данных, которую вы будете использовать здесь",  "query": "укажите SQL-запрос для решения задачи здесь"}

Вот ваша задача: создать пайплайн, который использует базу данных ExampleCompany для выборки всех активных клиентов

Помощник:

Результат выглядит следующим образом:

Вот JSON-представление ETL-пайплайна, чтобы получить всех активных клиентов из базы данных ExampleCompany:

{  "database": "ExampleCompany",  "query": "SELECT * FROM customers WHERE status = 'active'"}

Этот пайплайн использует базу данных ExampleCompany и SQL-запрос для выбора всех записей из таблицы customers, где статус равен “active”.

С добавлением контекста модель теперь способна приблизиться к ответу. Теперь она знает, как структурировать вывод, и понимает, что ей нужно написать SQL-запрос для решения задачи. Однако заметьте, что модель не использует ожидаемую номенклатуру ec_prod.customers. Есть место для улучшения! Также обратите внимание, что на практике вам потребуется включать значительно больше контекста, чем в нашем примере, чтобы получить результаты высокого качества в случаях использования текста для создания пайплайнов.

Улучшение #3: Заключение примеров в XML-теги

Обучение на небольшом количестве примеров – популярный способ увеличить точность БМ, если имеются соответствующие примеры, которые могут помочь БМ в выполнении задачи. Это особенно важно при работе с приложениями на основе текста-пайплайнов, потому что эти гиперспецифические результаты пайплайнов обычно не включаются в общедоступные наборы данных, поскольку они специфичны для представления данных каждого отдельного клиента. При использовании Клода вы можете воспользоваться его врожденным знанием произвольных XML-тегов, чтобы предоставить эти примеры в формате обучения на небольшом числе примеров. В улучшенной просьбе ниже обратите внимание на добавление примеров, заключенных в XML-теги <example>. Также вы можете использовать сокращения для идентификаторов “человек” и “помощник” с H и A, чтобы предоставить Клоду контекст, не заставляя его думать, что это были конкретные части диалога, которые уже произошли.

Мы используем следующую просьбу:

Человек: Ваша задача заключается в том, чтобы выступать в роли эксперта по ETL-пайплайнам. Конкретно, ваша задача заключается в создании JSON-представления ETL-пайплайна, которое решит предоставленный вам пользовательский запрос.

JSON-вывод должен следовать следующему формату:

{  "database": "имя базы данных, которую вы будете использовать здесь"  "query": "укажите SQL-запрос для решения задачи здесь"}

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

<example-1>

H: запросить базу данных ExampleCompany на наличие активных заказов для клиента #1234

A:

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.orders WHERE customer_id = 1234 AND status  = 'active'"}

Основная причина этого запроса заключается в том, что клиент #1234 фильтруется, и мы ищем в таблице “orders” любые существующие записи после фильтрации “active”.

</example-1>

<example-2>

H: удалить всех клиентов в базе данных ExampleCompany, которые не были активны в последний месяц

A:

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.customers WHERE status != 'active'"}

Основная причина этого запроса заключается в том, что таблица “ec_prod.customers” – единственная таблица в базе данных ExampleCompany, содержащая записи о клиентах.

</example-2>

Вот ваша задача: создать пайплайн, который использует базу данных ExampleCompany для выборки всех активных клиентов.

Помощник:

Результат выглядит следующим образом:

Вот JSON-представление для ETL-пайплайна, который извлекает все активные клиенты из базы данных ExampleCompany:

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.customers WHERE status = 'active'"}

Рассуждение такое:

Указана база данных ExampleCompany для использования

Таблица ec_prod.customers содержит данные клиентов

Поле status указывает, является ли клиент активным, поэтому запрос фильтрует только активных клиентов

Это должно извлечь все записи активных клиентов из базы данных ExampleCompany. Дайте мне знать, если вам нужно какие-либо разъяснения или есть дополнительные требования к ETL-пайплайну!

JSON-вывод теперь имеет правильную номенклатуру базы данных, которую Клод смог использовать благодаря приведенным нами примерам. Сочетание индикаторов человека и помощника с XML-тегами облегчает понимание Клода того, что является задачей и каков был ответ в похожих примерах с очень ясным разделением между несколькими несколькими примерами с небольшим числом инструкций. Чем проще Клоду понять, тем лучше и более соответствующий будет ответ, что дополнительно снижает возможность модели вызвать галлюцинацию и предоставить случайные несвязанные ответы.

Улучшение №4: Запуск генерации JSON Клода с помощью XML-тегов

Небольшой сложностью работы с приложениями текст-в-пайплайн с использованием ФМ является необходимость точного разбора вывода из результата текста, чтобы его можно было интерпретировать в виде кода в следующем приложении. Один из способов решения этой проблемы с использованием Клода – воспользоваться его пониманием XML-тегов и совместить это с пользовательской последовательностью остановки. В следующей подсказке мы указали Клоду обрамить вывод в XML-теги <json></json>. Затем мы добавили тег <json> в конце подсказки. Это гарантирует, что первый текст, который выйдет из Клода, будет началом JSON-вывода. Если этого не сделать, Клод часто отвечает с некоторым разговорным текстом, а затем – реальным кодовым ответом. Приказав Клоду немедленно начать генерацию вывода, вы можете легко остановить генерацию, когда увидите закрывающий тег </json>. Это показано в обновленном вызове Boto3 API. Преимущества этой техники двояки. Во-первых, вы сможете точно разобрать ответ-код от Клода. Во-вторых, вы сможете снизить затраты, поскольку Клод генерирует только кодовые выходы и не дополнительный текст. Это позволяет сэкономить на Amazon Bedrock, поскольку вам начисляются затраты на каждый токен, который производится в качестве вывода из всех ФМ.

Мы используем следующую подсказку:

Человек: Вашей задачей является выступать в роли эксперта по ETL-пайплайнам. В частности, вашей задачей является создание JSON-представления ETL-пайплайна, который будет решать предоставленный вам пользовательский запрос.

JSON-вывод должен соответствовать следующему формату:

{    "database": "имя используемой здесь базы данных"    "query": "разместите здесь SQL-представление для решения данной задачи"}

Вот некоторые примеры пользовательских запросов и связанных с ними выходных JSON-артефактов, которые правильно решают предоставленную задачу. Убедитесь, что вы используете ту же номенклатуру, которая указана в примерах, если вы используете те же базы данных.

<пример-1>

H: запросите базу данных ExampleCompany для активных заказов клиента #1234

A:

<json>

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.orders WHERE customer_id = 1234 AND status  = 'active'"}

</json>

Причина для этого запроса заключается в том, что клиент #1234 отфильтрован, и мы ищем в таблице “orders” любые существующие записи после фильтра “active”.

</пример-1>

<пример-2>

H: удалите всех клиентов в базе данных ExampleCompany, которые не были активны в последний месяц

A:

<json>

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.customers WHERE status != 'active'"}

</json>

Причина для этого запроса заключается в том, что таблица “ec_prod.customers” – это единственная таблица в базе данных ExampleCompany, которая содержит записи клиентов.

</пример-2>

Всегда помните, чтобы заключать свои JSON-выводы в теги <json></json>.

Ваша задача: создать пайплайн, который использует базу данных ExampleCompany для извлечения всех активных клиентов.

Assistant:

<json>

Мы используем следующий код:

body = json.dumps({"prompt": prompt, "stop_sequences": ['\n\nЧеловек:', '</json>']})
response = bedrock.invoke_model(   body=body,   modelId='anthropic.claude-v2')

Выходные данные следующие:

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.customers WHERE status = 'active'"}

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

Вывод

Чтобы начать использовать SnapGPT сегодня, запросите бесплатную пробную версию SnapLogic или запросите демонстрацию продукта. Если вы хотите использовать эти концепции для создания приложений уже сегодня, мы рекомендуем попробовать на практике раздел по инженерии запросов в этом сообщении, используя тот же подход для создания других приложений, которые подходят для вашего бизнеса, а также углубиться в RAG-возможности, доступные через Amazon Bedrock.

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