Как Q4 Inc. использовала инструменты Amazon Bedrock, RAG и SQLDatabaseChain для решения числовых и структурированных проблем с наборами данных при создании своего чат-бота для вопросов и ответов.

Как Q4 Inc. применила инструменты Amazon Bedrock, RAG и SQLDatabaseChain для решения числовых и структурированных проблем с данными при разработке своего чат-бота для вопросов и ответов.

Этот пост совместно написан со Станиславом Ещенко из компании Q4 Inc.

Предприятия все больше обращаются к модели Retrieval Augmented Generation (RAG) в качестве основного подхода к созданию чат-ботов для вопросно-ответных систем. Мы продолжаем видеть возникающие проблемы, обусловленные характером разнообразных доступных наборов данных. Эти данные часто представляют собой смесь числовых и текстовых данных, которые могут быть структурированными, неструктурированными или полуструктурированными.

Компании Q4 Inc. было необходимо решить некоторые из этих проблем в одном из множества своих применений искусственного интеллекта, построенных на платформе AWS. В этом посте мы обсудим пример использования чат-бота для вопросно-ответной системы, реализованный Q4, проблемы, связанные с числовыми и структурированными данными, и то, как Q4 пришла к выводу, что использование SQL может быть жизнеспособным решением. Наконец, мы рассмотрим, как команда Q4 использовала Amazon Bedrock и SQLDatabaseChain для реализации решения на основе RAG с генерацией SQL.

Обзор примера использования

Q4 Inc., с головным офисом в Торонто и офисами в Нью-Йорке и Лондоне, является ведущей платформой для доступа к финансовым рынкам, которая изменяет способ взаимодействия между эмитентами, инвесторами и продавцами, обеспечивая их эффективное соединение, коммуникацию и взаимодействие. Платформа Q4 обеспечивает взаимодействие на финансовых рынках через продукты для веб-сайтов, виртуальные мероприятия, аналитику взаимодействия, CRM для инвесторских отношений, анализ рынка и акционеров, контроль и ESG-инструменты.

В сегодняшнем быстром и данными наполненном финансовом мире специалисты по связям с инвесторами (ИСИ) играют важную роль в укреплении коммуникации между компанией и ее акционерами, аналитиками и инвесторами. В рамках своих ежедневных обязанностей ИСИ анализируют разнообразный объем данных, включая CRM, данные о владельцах и фондовом рынке. Эти данные используются для составления финансовых отчетов, определения целей в области инвестиционных отношений и общения с существующими и потенциальными инвесторами.

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

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

Финансовые рынки – регулируемая отрасль с большими ставками. Предоставление неверной или устаревшей информации может повлиять на доверие инвесторов и акционеров, а также представлять риски для конфиденциальности данных. Понимая особенности этой отрасли и требования, Q4 устанавливает конфиденциальность данных и точность ответа в качестве руководящих принципов при оценке любого решения перед его выходом на рынок.

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

Поскольку Q4 хотела убедиться, что она сможет удовлетворить все рассмотренные нами функциональные и негибкие требования, проект также должен был оставаться коммерчески возможным. Это было учтено на всех этапах выбора подхода, архитектуры, выбора технологии и специфических элементов решения.

Экспериментирование и проблемы

Было ясно с самого начала, что для понимания вопроса на естественном языке и генерации точных ответов Q4 должна использовать большие языковые модели (LLM).

Ниже представлены некоторые из экспериментов, проведенных командой, а также выявленные проблемы и полученные уроки:

Предварительное обучение – Q4 поняла сложность и проблемы, с которыми связано предварительное обучение LLM с использованием собственных данных. Быстро стало понятно, что этот подход требует больших ресурсов и включает множество нетривиальных шагов, таких как предварительная обработка данных, обучение и оценка модели. Помимо затрат на ресурсы, это также было бы неэффективно с точки зрения затрат. Учитывая характер датасета временных рядов, Q4 также поняла, что ей пришлось бы постоянно выполнять инкрементное предварительное обучение при поступлении новых данных. Для этого потребовалась бы отдельная команда с междисциплинарными знаниями в области науки о данных, машинного обучения и предметной области.
Настройка – Настройка предварительно обученной базовой модели (FM) включала использование нескольких примеров с маркировкой. Этот подход показал некоторый первоначальный успех, но во многих случаях проблемой стало появление ложных результатов модели. Модель имела сложности с пониманием нюансов контекстуальных сигналов и возвращала неправильные результаты.
RAG с семантическим поиском – Перед переходом к генерации SQL команда экспериментировала с использованием поиска, семантического поиска и вложений для извлечения контекста с помощью RAG. В ходе эксперимента с вложениями датасет был преобразован в вложения, хранящиеся в векторной базе данных, после чего они сравнивались с вложениями вопроса для извлечения контекста. Полученный контекст в любом из трех экспериментов затем использовался для дополнения исходного запроса в качестве входных данных в LLM. Этот подход хорошо работал для текстового контента, где данные представлены естественным языком с словами, предложениями и абзацами. Однако из-за характера датасета Q4, в основном состоящего из финансовых данных (чисел, финансовых транзакций, котировок и дат), результаты во всех трех случаях были неоптимальными. Даже при использовании вложений вложения, сгенерированные из числовых данных, имели проблемы с ранжированием по сходству и во многих случаях приводили к извлечению неверной информации.

Заключение по Q4: создание SQL – путь вперед

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

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

На основе первоначальных тестов этот метод показал отличные результаты. LLM, оснащенный всей необходимой информацией, мог генерировать правильный SQL, который затем выполнялся в базе данных для извлечения правильного контекста. После экспериментов с этой идеей Q4 решила, что генерация SQL была способом вперед для решения проблемы извлечения контекста для их собственного конкретного набора данных.

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

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

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

В случае использования Q4 мы начинаем с перевода вопроса клиента в SQL. Мы делаем это, объединяя пользовательский вопрос, схему базы данных, некоторые примеры строк базы данных и подробные инструкции в качестве приглашения для LLM для генерации SQL. После получения SQL мы можем выполнить шаг проверки, если это необходимо. Когда мы довольны качеством SQL, мы выполняем запрос в базе данных, чтобы извлечь необходимый контекст для следующего шага. Теперь, когда у нас есть соответствующий контекст, мы можем отправить исходный вопрос пользователя, извлеченный контекст и набор инструкций обратно LLM, чтобы получить окончательный краткий ответ. Цель последнего шага – позволить LLM суммировать результаты и предоставить контекстуальный и точный ответ, который затем может быть передан пользователю.

Выбор LLM, использованного на каждом этапе процесса, существенно влияет на точность, стоимость и производительность. Выбор платформы или технологии, которая позволяет вам гибко переключаться между LLM в рамках одного случая использования (несколько поездок к LLM для различных задач) или между различными случаями использования, может быть полезен для оптимизации качества вывода, задержки и стоимости. Мы рассмотрим выбор LLM позже в этом сообщении.

Строительные блоки решения

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

Amazon Bedrock

Amazon Bedrock – это полностью управляемый сервис, предлагающий выбор высокопроизводительных моделей от ведущих компаний, включая AI21 Labs, Anthropic, Cohere, Meta, Stability AI и Amazon. Amazon Bedrock также предлагает широкий набор инструментов, необходимых для создания генеративных приложений на базе искусственного интеллекта, упрощения процесса разработки и обеспечения конфиденциальности и безопасности. Кроме того, с помощью Amazon Bedrock вы можете выбрать из различных вариантов моделей и дополнительно настроить модели, используя свои собственные данные, чтобы согласовать ответы моделей с требованиями вашего случая использования. Amazon Bedrock полностью безсерверный, без необходимости управления базовой инфраструктурой, и обеспечивает доступ к доступным моделям через единый API. Наконец, Amazon Bedrock поддерживает несколько требований к безопасности и конфиденциальности, включая соответствие HIPAA и GDPR.

В решении Q4 мы используем Amazon Bedrock в качестве безсерверного строительного блока для создания многофункциональных моделей на основе API. Поскольку мы планируем совершать несколько поездок к LLM в рамках одного случая использования, в зависимости от типа задачи мы можем выбирать наиболее оптимальную модель для конкретной задачи, будь то генерация SQL, проверка или суммирование.

LangChain

LangChain – это фреймворк интеграции и оркестрации с открытым исходным кодом, который включает набор предварительно созданных модулей (ввод/вывод, выборка, цепочки и агенты), которые можно использовать для интеграции и оркестрации задач между FM, источниками данных и инструментами. Фреймворк облегчает создание генеративных приложений искусственного интеллекта, требующих оркестрации нескольких шагов для достижения желаемого результата, без необходимости писать код с нуля. LangChain поддерживает Amazon Bedrock как API модели с несколькими основами.

В контексте использования Q4 мы используем LangChain для координации и оркестрации задач в нашем рабочем процессе, включая подключение к источникам данных и LLM. Этот подход упростил наш код, так как мы можем использовать существующие модули LangChain.

SQLDatabaseChain

SQLDatabaseChain – это цепочка LangChain, которую можно импортировать из langchain_experimental. SLDatabaseChain упрощает создание, реализацию и выполнение SQL-запросов с помощью своих эффективных преобразований и реализаций текста в SQL.

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

Набор данных

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

Детали реализации

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

Давайте рассмотрим детали реализации и ход процесса.

Создание SQL-запроса

Для упрощения кодирования мы используем существующие фреймворки. Мы используем LangChain в качестве оркестрационного фреймворка. Мы начинаем с этапа ввода, где мы получаем вопрос пользователя на естественном языке.

На этом первом этапе мы берем этот ввод и генерируем эквивалентный SQL, который мы можем запустить на базе данных для извлечения контекста. Для генерации SQL мы используем SQLDatabaseChain, который основывается на Amazon Bedrock для доступа к нашему нужному LLM. С помощью Amazon Bedrock, используя одно API, мы получаем доступ к нескольким базовым LLM и можем выбрать подходящий для каждой поездки к LLM. Сначала мы устанавливаем соединение с базой данных и извлекаем требуемую схему таблицы вместе с несколькими образцовыми строками из таблиц, которые мы собираемся использовать.

В наших тестах мы отметили, что 2-5 строк данных таблицы достаточно для предоставления достаточной информации модели без добавления излишней нагрузки. Три строки были достаточными для предоставления контекста, без перегрузки модели излишним вводом. В нашем случае мы начали с модели Anthropic Claude V2. Модель известна своими продвинутыми рассуждениями и артикулированными контекстуальными ответами, когда ей предоставляется правильный контекст и инструкции. В качестве инструкций мы можем включить более уточняющие детали для LLM. Например, мы можем указать, что столбец Comp_NAME означает название компании. Теперь мы можем создать запрос, объединив вопрос пользователя таким, какой он есть, схему базы данных, три образцовые строки из таблицы, которую мы собираемся использовать, и набор инструкций для генерации необходимого SQL в чистом формате без комментариев или добавлений.

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

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

Проверьте SQL-запрос

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

Если мы используем LLM для шага проверки, мы можем использовать тот же самый LLM, что и раньше (Claude V2), или более компактный и производительный LLM для более простой задачи, например, Claude Instant. Поскольку мы используем Amazon Bedrock, это должно быть очень простое изменение. С помощью того же API мы можем изменить имя модели в нашем вызове API, что позволяет справиться с изменением. Важно отметить, что в большинстве случаев более компактный LLM может обеспечить большую эффективность как в стоимости, так и в задержке, и следует учитывать этот факт, пока вы получаете желаемую точность. В нашем случае тестирование показало, что сгенерированный запрос оказался постоянно точным и с правильным синтаксисом. Зная это, мы смогли пропустить этот шаг проверки и сэкономить время и деньги.

Выполнить SQL-запрос

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

Мы берем сгенерированный контекст, предоставляем его LLM нашего выбора с исходным пользовательским вопросом и некоторой инструкцией и просим модель сгенерировать контекстуальное и доходчивое резюме. Затем мы представляем сгенерированное резюме пользователю в качестве ответа на исходный вопрос, все в соответствии с контекстом, извлеченным из нашего набора данных.

Для LLM, участвующего в шаге резюмирования, мы можем использовать либо Titan Text Express, либо Claude Instant. Оба варианта подойдут для задачи резюмирования.

Интеграция в приложение

Возможность Q&A-чатбота является одной из AI-сервисов Q4. Для обеспечения модульности и масштабируемости Q4 создает AI-сервисы как микросервисы, доступные для приложений Q4 через API. Такой подход на основе API обеспечивает плавную интеграцию с экосистемой платформы Q4 и облегчает предоставление возможностей AI-сервисов полному набору приложений платформы.

Основная цель AI-сервисов – предоставить простые возможности для извлечения данных из любого открытого или собственного источника данных с использованием естественного языка в качестве ввода. Кроме того, AI-сервисы предоставляют дополнительные уровни абстракции, чтобы удовлетворить функциональные и нефункциональные требования, такие как защита данных и безопасность. Ниже приведена диаграмма, демонстрирующая концепцию интеграции.

Трудности реализации

Помимо трудностей, связанных с природой структурированного числового набора данных, которые мы рассмотрели ранее, Q4 столкнулась с рядом других трудностей реализации, которые требовалось решить.

Выбор LLM и производительность

Выбор правильного LLM для задачи является ключевым, поскольку это непосредственно влияет на качество выходных данных, а также на производительность (задержку в обмене сообщениями). Вот некоторые факторы, влияющие на процесс выбора LLM:

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

Поэтому при оптимизации вашей задачи учитывайте следующие лучшие практики:

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

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

Применение той же логики к задаче суммаризации привело нас к выводу, что использование Клод Инстант или Титан Текст Экспресс позволит достичь необходимой точности с лучшей производительностью по сравнению с использованием более крупной модели, такой как Клод V2. Титан Текст Экспресс также предлагает лучшее соотношение цена-производительность, как мы уже обсуждали ранее.

Вызов оркестрации

Мы поняли, что перед тем, как мы можем получить осмысленный выход для вопроса пользователя, требуется многое оркестрировать. Как показано в обзоре решения, процесс включал несколько обращений к базе данных и несколько обращений к LLM, которые тесно связаны друг с другом. Если бы мы начинали с нуля, нам пришлось бы вложить значительные усилия в тяжелую рутину, прежде чем код был бы готов. Мы быстро перешли к использованию LangChain в качестве фреймворка для оркестрации, воспользовавшись силой сообщества открытого исходного кода и повторным использованием существующих модулей, не изобретая велосипед заново.

Вызов SQL

Мы также поняли, что генерация SQL не так проста, как механизмы извлечения контекста, такие как семантический поиск или использование эмбеддингов. Сначала нам нужно получить схему базы данных и несколько образцовых строк, чтобы использовать их в нашем запросе к LLM. Также есть этап проверки SQL, где нам нужно взаимодействовать как с базой данных, так и с LLM. SQLDatabaseChain был очевидным выбором инструмента. Поскольку он является частью LangChain, его было легко адаптировать, и теперь мы можем управлять генерацией и проверкой SQL с помощью цепочки, минимизируя объем работы, который нам пришлось бы выполнить.

Проблемы производительности

Используя Клода V2 и после правильной подготовки запроса (о чем мы обсудим в следующем разделе), мы смогли производить качественный SQL. Учитывая качество сгенерированного SQL, мы начали рассматривать, насколько много ценности фактически вносит этап проверки. После дальнейшего анализа результатов стало ясно, что качество генерированного SQL согласованно точно в такой степени, что соотношение затрат/выгоды от добавления этапа проверки SQL было невыгодным. Мы удалили этот этап без негативного влияния на качество выходных данных и сократили время прохода проверки SQL.

В дополнение к оптимизации для более эффективной в экономическом и производственном плане LLM на этапе суммаризации, мы смогли использовать Титан Текст Экспресс для достижения лучшей производительности и экономической эффективности.

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

Инженерия запросов и оптимизация

Вы можете настроить Клода на Amazon Bedrock для различных деловых задач, если используются правильные техники инженерии запросов. Клод в основном выступает в качестве разговорного помощника, использующего формат взаимодействия с человеком/помощником. Клод обучен заполнять текст для роли помощника. Учитывая желаемые инструкции и завершения запроса, мы можем оптимизировать наши запросы для Клода, используя несколько техник.

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

Еще один способ оптимизировать ответ Клода – экспериментировать и итерировать, добавляя правила, инструкции и полезные оптимизации. По результатам этих оптимизаций вы можете получить различные типы завершений, например, указать Клоду добавить “Я не знаю”, чтобы предотвратить галлюцинации, думать шаг за шагом, использовать связывание запросов, давать время “думать”, пока он генерирует ответы, и проверять понимание и точность.

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

Использование правильного синтаксиса человек/ассистент
Использование XML-тегов (Клоду уважает и понимает XML-теги)
Добавление ясных инструкций для модели, чтобы предотвратить галлюцинации

Следующий обобщенный пример показывает, как мы использовали синтаксис человек/ассистент, применяли XML-теги и добавляли инструкции для ограничения вывода в SQL и указания модели сказать «sorry, I am unable to help», если она не может создать соответствующий SQL. XML-теги использовались для формулирования инструкций, дополнительных подсказок, схем баз данных, пояснений к таблицам и примерных строк.

"""Человек: Вы эксперт по SQL. Ваша задача - сгенерировать SQL-заявление на основе предоставленной инструкции.<instructions>Понимая входной вопрос, обращаясь к схеме базы данных и просматривая примеры строк, сгенерируйте SQL-заявление, которое отображает вопрос.</instructions><database_schema>"здесь вы можете включить схемы таблиц</database_schema><table_description>"Comp-Nam" означает название компании "Own-Hist" - история владения</table_description><example_rows>"здесь вы можете вставить 2-5 образцов строк из базы данных"</example_rows><question>{пример_ввода}</question><additional_hints>В вашем ответе предоставляйте только SQL без дополнительных комментариев.SQL должен соответствовать правильной схеме базы данных.Если вопрос не связан с базой данных или если вы не можетесгенерировать соответствующий SQL, скажите "sorry, I am unable to help".Не выдумывайте ответНе отвечайте ничем, кроме SQL</additional_hints>Ассистент: """

Финальное рабочее решение

После того, как мы справились со всеми выявленными вызовами на этапе концепции, мы выполнили все требования решения. Q4 остался доволен качеством генерируемого LLM SQL. Это верно как для простых задач, которые требовали только условия WHERE для фильтрации данных, так и для более сложных задач, которые требовали агрегирования с контекстом с помощью GROUP BY и математических функций. Время отклика от начала до конца всего решения пришлось в рамки, определенные для данного случая использования – однозначные секунды. Это было достигнуто за счет выбора оптимального LLM на каждом этапе, правильного выдвижения, исключения этапа проверки SQL и использования эффективного LLM для этапа суммаризации (Titan Text Express или Claude Instant).

Стоит отметить, что использование Amazon Bedrock в качестве полностью управляемой службы и возможность иметь доступ к набору LLM через одно API позволило экспериментировать и легко переключаться между LLM, изменяя название модели в API-вызове. Благодаря такому уровню гибкости Q4 смог выбрать наиболее производительный LLM для каждого вызова LLM в зависимости от характера задачи – генерация запроса, проверка или суммаризация.

Заключение

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

В этом посте мы показали, что для числовых и структурированных наборов данных использование SQL для извлечения контекста, используемого для увеличения может привести к более благоприятным результатам. Мы также продемонстрировали, что инструменты, такие как LangChain, могут минимизировать усилия по кодированию. Кроме того, мы обсудили необходимость возможности переключения между LLM в рамках одного случая использования для достижения наиболее оптимальной точности, производительности и стоимости. Наконец, мы подчеркнули, как Amazon Bedrock, будучи серверным и с набором LLM “под капотом”, предоставляет необходимую гибкость для создания безопасных, производительных и оптимизированных по стоимости приложений с минимальными усилиями.

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

Advanced (300),Amazon Bedrock,Artificial Intelligence,Customer Solutions

Pixel 8 Pro – первый смартфон с встроенным искусственным интеллектом – теперь работает на Gemini Nano, а также добавлены дополнительные обновления искусственного интеллекта для портфеля Pixel.

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