Этот пост написан в соавторстве со Станиславом Ещенко из Q4 Inc.
Предприятия обращаются к поисковой дополненной генерации (RAG) как к основному подходу к созданию чат-ботов вопросов и ответов. Мы по-прежнему видим новые проблемы, связанные с характером ассортимента доступных наборов данных. Эти наборы данных часто представляют собой смесь числовых и текстовых данных, иногда структурированных, неструктурированных или полуструктурированных.
Q4 Инк. компании необходимо было решить некоторые из этих проблем в одном из многочисленных сценариев использования ИИ, созданных на базе AWS. В этом посте мы обсуждаем вариант использования бота вопросов и ответов, реализованный в четвертом квартале, проблемы, связанные с числовыми и структурированными наборами данных, и то, как в четвертом квартале был сделан вывод о том, что использование SQL может быть жизнеспособным решением. Наконец, мы подробнее рассмотрим, как команда Q4 использовала Коренная порода Амазонки и SQLDatabaseChain для реализации решения на основе RAG с генерацией SQL.
Обзор вариантов использования
Q4 Inc. со штаб-квартирой в Торонто и офисами в Нью-Йорке и Лондоне является ведущей платформой доступа к рынкам капитала, которая меняет способы эффективного взаимодействия, общения и взаимодействия эмитентов, инвесторов и продавцов друг с другом. Платформа Q4 облегчает взаимодействие на рынках капитала с помощью продуктов веб-сайтов IR, решений для виртуальных мероприятий, анализа взаимодействия, взаимоотношений с инвесторами, управления взаимоотношениями с клиентами (CRM), анализа акционеров и рынка, наблюдения и инструментов ESG.
В сегодняшнем быстро меняющемся финансовом мире, управляемом данными, сотрудники по связям с инвесторами (IRO) играют решающую роль в налаживании связей между компанией и ее акционерами, аналитиками и инвесторами. В рамках своих повседневных обязанностей IRO анализируют различные наборы данных, включая CRM, записи о собственности и данные фондового рынка. Совокупность этих данных используется для создания финансовых отчетов, установления целей по связям с инвесторами и управления общением с существующими и потенциальными инвесторами.
Чтобы удовлетворить растущий спрос на эффективный и динамичный поиск данных, Q4 стремился создать инструмент вопросов и ответов для чат-бота, который предоставил бы IRO интуитивно понятный и простой метод доступа к необходимой им информации в удобном для пользователя формате.
Конечная цель состояла в том, чтобы создать чат-бота, который бы легко интегрировал общедоступные данные вместе с собственными данными клиентов за четвертый квартал, сохраняя при этом высочайший уровень безопасности и конфиденциальности данных. Что касается производительности, цель заключалась в том, чтобы поддерживать время ответа на запрос в секундах, чтобы обеспечить положительный опыт для конечных пользователей.
Финансовые рынки — это регулируемая отрасль с высокими ставками. Предоставление неверной или устаревшей информации может повлиять на доверие инвесторов и акционеров, а также создать другие возможные риски для конфиденциальности данных. Понимая отрасль и требования, Q4 устанавливает конфиденциальность данных и точность ответа в качестве руководящих принципов при оценке любого решения перед его выводом на рынок.
Для проверки концепции в четвертом квартале было решено использовать набор данных о финансовой собственности. Набор данных состоит из точек данных временных рядов, представляющих количество принадлежащих активов; история транзакций между инвестиционными учреждениями, частными лицами и публичными компаниями; и многие другие элементы.
Поскольку в четвертом квартале хотелось убедиться, что он сможет удовлетворить всем функциональным и нефункциональным требованиям, которые мы обсуждали, проект также должен был оставаться коммерчески осуществимым. Это соблюдалось на протяжении всего процесса принятия решения о подходе, архитектуре, выборе технологии и элементах, специфичных для решения.
Эксперименты и проблемы
С самого начала было ясно, что для понимания вопроса на человеческом языке и получения точных ответов Q4 потребуется использовать большие языковые модели (LLM).
Ниже приведены некоторые эксперименты, проведенные командой, а также выявленные проблемы и извлеченные уроки:
- Предварительная подготовка – В четвертом квартале осознались сложности и проблемы, связанные с предварительным обучением LLM с использованием собственного набора данных. Быстро стало очевидно, что этот подход ресурсоемок и включает множество нетривиальных шагов, таких как предварительная обработка данных, обучение и оценка. Помимо затраченных усилий, это будет непомерно дорого. Учитывая характер набора данных временных рядов, в четвертом квартале также поняли, что ему придется постоянно выполнять дополнительное предварительное обучение по мере поступления новых данных. Для этого потребовалась бы специальная междисциплинарная команда с опытом в области науки о данных, машинного обучения и предметной области. знание.
- Тонкая настройка – Точная настройка предварительно обученной базовой модели (FM) с использованием нескольких помеченных примеров. Этот подход показал некоторый первоначальный успех, но во многих случаях модель галлюцинации была проблемой. Модель изо всех сил пыталась понять нюансы контекстуальных сигналов и возвращала неверные результаты.
- RAG с семантическим поиском – Обычный RAG с семантическим поиском был последним шагом перед переходом к генерации SQL. Команда экспериментировала с использованием поиска, семантического поиска и встраивания для извлечения контекста. В ходе эксперимента с встраиваниями набор данных был преобразован в вложения, сохранен в векторной базе данных, а затем сопоставлен с встраиваниями вопроса для извлечения контекста. Полученный контекст в любом из трех экспериментов затем использовался для дополнения исходной подсказки в качестве входных данных для LLM. Этот подход хорошо работал для текстового контента, где данные состоят из естественного языка со словами, предложениями и абзацами. Учитывая характер набора данных за четвертый квартал, который в основном представляет собой финансовые данные, состоящие из чисел, финансовых транзакций, котировок акций и дат, результаты во всех трех случаях были неоптимальными. Даже при использовании вложений вложения, сгенерированные из чисел, не соответствовали ранжированию по сходству и во многих случаях приводили к получению неверной информации.
Вывод четвертого квартала: генерация SQL — это путь вперед
Учитывая проблемы, с которыми приходится сталкиваться при использовании традиционной методологии RAG, команда начала рассматривать возможность генерации SQL. Идея заключалась в том, чтобы использовать LLM для создания оператора SQL на основе пользовательского вопроса, представленного LLM на естественном языке. Затем сгенерированный запрос выполняется к базе данных для получения соответствующего контекста. Контекст наконец используется для дополнения приглашения к вводу на этапе суммирования.
Гипотеза Q4 заключалась в том, что для увеличения запоминаемости на этапе поиска, особенно для набора числовых данных, им необходимо сначала сгенерировать SQL на основе пользовательского вопроса. Считалось, что это не только повысит точность, но и сохранит контекст в рамках бизнес-сферы для данного вопроса. Для генерации запросов и точного SQL в четвертом квартале необходимо было сделать LLM полностью контекстно-ориентированным в отношении структуры набора данных. Это означало, что подсказка должна была включать схему базы данных, несколько образцов строк данных и удобочитаемые пояснения для полей, которые нелегко понять.
Судя по первоначальным испытаниям, этот метод показал отличные результаты. LLM, оснащенный всей необходимой информацией, смог сгенерировать правильный SQL-код, который затем был запущен в базе данных для получения правильного контекста. Поэкспериментировав с этой идеей, Q4 решил, что генерация SQL — это путь вперед для решения проблем извлечения контекста для их собственного конкретного набора данных.
Давайте начнем с описания общего подхода к решению, разобьем его на компоненты, а затем соберем воедино.
Обзор решения
LLM — это большие модели с миллиардами параметров, которые предварительно обучаются с использованием очень больших объемов данных из различных источников. Из-за обширности наборов обучающих данных ожидается, что LLM будут обладать общими знаниями в различных областях. LLM также известны своими способностями к рассуждению, которые варьируются от одной модели к другой. Это общее поведение можно оптимизировать для конкретной области или отрасли путем дальнейшей оптимизации базовой модели с использованием дополнительных данных предварительного обучения для конкретной области или путем точной настройки с использованием помеченных данных. При наличии правильного контекста, метаданных и инструкций хорошо выбранный LLM общего назначения может создавать высококачественный SQL, если у него есть доступ к правильному контексту, специфичному для конкретной предметной области.
В варианте использования Q4 мы начинаем с перевода вопроса клиента в SQL. Мы делаем это, объединяя вопрос пользователя, схему базы данных, несколько примеров строк базы данных и подробные инструкции в качестве подсказки LLM для генерации SQL. После того, как у нас есть SQL, мы можем запустить этап проверки, если это будет сочтено необходимым. Когда нас устраивает качество SQL, мы запускаем запрос к базе данных, чтобы получить соответствующий контекст, который нам понадобится для следующего шага. Теперь, когда у нас есть соответствующий контекст, мы можем отправить исходный вопрос пользователя, полученный контекст и набор инструкций обратно в LLM для получения окончательного обобщенного ответа. Цель последнего шага — заставить LLM обобщить результаты и предоставить контекстуальный и точный ответ, который затем можно будет передать пользователю.
Выбор LLM, используемого на каждом этапе процесса, сильно влияет на точность, стоимость и производительность. Выбор платформы или технологии, которая позволит вам гибко переключаться между LLM в рамках одного и того же варианта использования (несколько поездок LLM для разных задач) или между разными вариантами использования, может оказаться полезным для оптимизации качества выходных данных, задержки и стоимости. . Мы рассмотрим выбор LLM позже в этом посте.
Строительные блоки решения
Теперь, когда мы осветили подход на высоком уровне, давайте углубимся в детали, начиная со строительных блоков решения.
Коренная порода Амазонки
Amazon Bedrock — это полностью управляемый сервис, предлагающий на выбор высокопроизводительные FM от ведущих компаний, включая AI21 Labs, Anthropic, Cohere, Meta, Stability AI и Amazon. Amazon Bedrock также предлагает широкий набор инструментов, необходимых для создания генеративных приложений искусственного интеллекта, упрощения процесса разработки и обеспечения конфиденциальности и безопасности. Кроме того, с помощью Amazon Bedrock вы можете выбирать из различных вариантов FM и дополнительно настраивать модели в частном порядке, используя свои собственные данные, чтобы согласовать ответы моделей с требованиями вашего варианта использования. Amazon Bedrock полностью бессерверен и не имеет базовой инфраструктуры для управления расширением доступа к доступным моделям через единый API. Наконец, Amazon Bedrock поддерживает несколько требований безопасности и конфиденциальности, включая соответствие требованиям HIPAA и соответствие GDPR.
В решении четвертого квартала мы используем Amazon Bedrock в качестве бессерверного многоосновного строительного блока модели на основе API. Поскольку мы намерены совершать несколько обращений к LLM в рамках одного и того же варианта использования, в зависимости от типа задачи, мы можем выбрать модель, наиболее оптимальную для конкретной задачи, будь то генерация SQL, проверка или обобщение.
Лангчейн
Лангчейн — это платформа интеграции и оркестрации с открытым исходным кодом с набором готовых модулей (ввода-вывода, извлечения, цепочек и агентов), которые можно использовать для интеграции и оркестрации задач между 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. Клод V2. Модель известна своими продвинутыми рассуждениями и четкими контекстными ответами при наличии правильного контекста и инструкций. В рамках инструкций мы можем включить в LLM более уточняющую информацию. Например, мы можем описать этот столбец Comp_NAME
обозначает название компании. Теперь мы можем создать подсказку, объединив вопрос пользователя как есть, схему базы данных, три примерные строки из таблицы, которую мы собираемся использовать, и набор инструкций для генерации требуемого SQL в чистом формате SQL без комментариев и дополнений.
Все объединенные элементы ввода рассматриваются как приглашение для ввода модели. Хорошо спроектированное приглашение ввода, адаптированное к предпочтительному синтаксису модели, сильно влияет как на качество, так и на производительность выходных данных. Выбор модели для конкретной задачи также важен не только потому, что это влияет на качество продукции, но и потому, что это влияет на стоимость и производительность.
Мы обсудим выбор модели, быстрое проектирование и оптимизацию позже в этой статье, но стоит отметить, что на этапе генерации запроса мы заметили, что Claude Instant смог дать сопоставимые результаты, особенно когда вопрос пользователя хорошо сформулирован и не столь сложен. Однако Claude V2 показал лучшие результаты даже при более сложном и косвенном вводе пользователя. Мы узнали, что хотя в некоторых случаях Клод Инстант может обеспечить достаточную точность при лучшей задержке и цене, наш вариант генерации запросов лучше подходил для 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. Оба они представляют собой хорошие варианты решения задачи обобщения.
Интеграция приложений
Возможность чат-бота «Вопросы и ответы» — это одна из услуг искусственного интеллекта Q4. Чтобы обеспечить модульность и масштабируемость, Q4 создает сервисы ИИ в виде микросервисов, которые доступны приложениям Q4 через API. Этот подход на основе API обеспечивает плавную интеграцию с экосистемой платформы Q4 и облегчает доступ к возможностям служб искусственного интеллекта всему набору приложений платформы.
Основная цель служб ИИ — предоставить простые возможности для получения данных из любого общедоступного или частного источника данных, используя естественный язык в качестве входных данных. Кроме того, сервисы ИИ предоставляют дополнительные уровни абстракции, гарантирующие соблюдение функциональных и нефункциональных требований, таких как конфиденциальность и безопасность данных. Следующая диаграмма демонстрирует концепцию интеграции.
Проблемы реализации
Помимо проблем, связанных с характером структурированного набора числовых данных, которые мы обсуждали ранее, в четвертом квартале возник ряд других проблем реализации, которые необходимо было решить.
Выбор и эффективность LLM
Выбор правильного LLM для задачи имеет решающее значение, поскольку он напрямую влияет на качество вывода, а также на производительность (задержку туда и обратно). Вот некоторые факторы, влияющие на процесс выбора LLM:
- Тип магистратуры – То, как спроектированы FM, и исходные данные, на которых модель была предварительно обучена, определяют типы задач, с которыми LLM будет хорошо справляться, и насколько она будет хороша. Например, текстовый LLM будет хорош для генерации и обобщения текста, тогда как модель преобразования текста в изображение или изображения в текст будет больше ориентирована на задачи анализа и генерации изображений.
- Размер LLM – Размеры FM измеряются количеством параметров модели, которые имеет конкретная модель, обычно в современных LLM исчисляются миллиардами. Как правило, чем крупнее модель, тем дороже первоначальное обучение или последующая точная настройка. С другой стороны, как правило, для одной и той же архитектуры модели, чем больше модель, тем умнее мы ожидаем, что она будет выполнять тот тип задачи, для решения которой она предназначена.
- LLM производительность – Как правило, чем больше модель, тем больше времени требуется для генерации выходных данных, при условии, что вы используете одни и те же параметры вычислений и ввода-вывода (приглашение и размер выходных данных). Кроме того, при одинаковом размере модели на производительность сильно влияет оптимизация приглашения, размер токенов ввода-вывода, а также ясность и синтаксис приглашения. Хорошо продуманное приглашение вместе с оптимизированным размером токена ввода-вывода может сократить время ответа модели.
Поэтому при оптимизации вашей задачи учитывайте следующие рекомендации:
- Выбирайте модель, подходящую для поставленной задачи.
- Выберите наименьший размер модели, который обеспечит необходимую вам точность.
- Оптимизируйте структуру подсказок и будьте как можно более конкретными с инструкциями, чтобы их было легко понять модели.
- Используйте наименьшее приглашение для ввода, которое может предоставить достаточно инструкций и контекста для достижения желаемого уровня точности.
- Ограничьте размер вывода наименьшим размером, который может иметь для вас значение и удовлетворить ваши требования к выводу.
Приняв во внимание факторы выбора модели и оптимизации производительности, мы приступили к оптимизации варианта использования генерации SQL. После некоторого тестирования мы заметили, что при наличии подходящего контекста и инструкций Claude Instant с теми же данными подсказок сможет обеспечить сопоставимое качество SQL с Claude V2, но при гораздо более высокой производительности и цене. Это справедливо, когда пользовательский ввод более прямой и простой по своей природе. Для более сложного ввода был необходим Claude V2 для достижения желаемой точности.
Применение той же логики к задаче суммирования привело нас к выводу, что использование Claude Instant или Titan Text Express обеспечит требуемую точность при гораздо более высокой производительности, чем если бы мы использовали более крупную модель, такую как Claude V2. Titan Text Expressed также предлагает лучшее соотношение цены и качества, как мы обсуждали ранее.
Задача оркестровки
Мы поняли, что нужно многое организовать, прежде чем мы сможем получить значимый ответ на вопрос пользователя. Как показано в обзоре решения, этот процесс включал несколько переплетенных обращений к базе данных и несколько переплетений LLM. Если бы нам пришлось создавать программу с нуля, нам пришлось бы вложить значительные средства в недифференцированную тяжелую работу только для того, чтобы подготовить базовый код. Мы быстро перешли к использованию LangChain в качестве платформы оркестрации, воспользовавшись мощью сообщества открытого исходного кода и повторно используя существующие модули, не изобретая велосипед заново.
Проблема SQL
Мы также поняли, что создание SQL не так просто, как механизмы извлечения контекста, такие как семантический поиск или использование встраивания. Сначала нам нужно получить схему базы данных и несколько образцов строк, чтобы включить их в запрос LLM. Существует также этап проверки SQL, на котором нам нужно взаимодействовать как с базой данных, так и с LLM. SQLDatabaseChain был очевидным выбором инструмента. Поскольку он является частью LangChain, его было легко адаптировать, и теперь мы можем управлять генерацией и проверкой SQL с помощью цепочки, сводя к минимуму объем работы, которую нам нужно было выполнить.
Проблемы с производительностью
Благодаря использованию Claude V2 и после правильного оперативного проектирования (о котором мы поговорим в следующем разделе) мы смогли создать высококачественный SQL. Принимая во внимание качество сгенерированного SQL, мы начали смотреть, какую ценность на самом деле добавляет этап проверки. После дальнейшего анализа результатов стало ясно, что качество сгенерированного SQL было неизменно точным, поэтому соотношение затрат и выгод от добавления этапа проверки SQL было неблагоприятным. В итоге мы исключили этап проверки SQL без негативного влияния на качество результатов и сократили время прохождения проверки SQL.
Помимо оптимизации затрат и производительности LLM на этапе суммирования, мы смогли использовать Titan Text Express для повышения производительности и экономической эффективности.
Дальнейшая оптимизация производительности включала тонкую настройку процесса генерации запросов с использованием эффективных методов оперативного проектирования. Вместо предоставления большого количества токенов основное внимание уделялось предоставлению наименьшего количества входных токенов с правильным синтаксисом, который обучена понимать модель, и с минимальным, но оптимальным набором инструкций. Мы обсудим это подробнее в следующем разделе — это важная тема, которая применима не только здесь, но и в других случаях использования.
Оперативное проектирование и оптимизация
Вы можете настроить Claude на Amazon Bedrock для различных случаев использования в бизнесе, если использовать правильные методы оперативного проектирования. Клод в основном действует как ассистент, использующий формат «человек/помощник». Клод обучен заполнять текст для роли помощника. Учитывая необходимые инструкции и подсказки, мы можем оптимизировать наши подсказки для Клода, используя несколько методов.
Мы начинаем с правильно отформатированного шаблона подсказки, который дает допустимое завершение, затем мы можем дополнительно оптимизировать ответы, экспериментируя с подсказками с различными наборами входных данных, которые репрезентативны для реальных данных. При разработке шаблона приглашения рекомендуется получить множество входных данных. Вы также можете использовать отдельные наборы данных быстрой разработки и тестовых данных.
Другой способ оптимизировать ответ Клода — экспериментировать и повторять, добавляя правила, инструкции и полезные оптимизации. Благодаря этим оптимизациям вы можете просмотреть различные типы завершений, например, попросив Клода упомянуть «Я не знаю», чтобы предотвратить галлюцинации, думая шаг за шагом, используя цепочку подсказок, давая место «подумать» по мере генерации ответов. и двойная проверка на понимание и точность.
Давайте воспользуемся нашей задачей создания запроса и обсудим некоторые методы, которые мы использовали для оптимизации нашего приглашения. Было несколько основных элементов, которые принесли пользу нашим усилиям по созданию запросов:
- Использование правильного синтаксиса человека/помощника
- Использование тегов XML (Клод уважает и понимает теги XML)
- Добавление четких инструкций для модели, чтобы предотвратить галлюцинации
В следующем общем примере показано, как мы использовали синтаксис «человек/помощник», применяли теги XML и добавляли инструкции для ограничения вывода SQL и указания модели сказать «извините, я не могу помочь», если она не может выдать соответствующий SQL. . Теги XML использовались для создания инструкций, дополнительных подсказок, схемы базы данных, дополнительных пояснений таблиц и строк примеров.
Окончательное рабочее решение
Решив все проблемы, выявленные в ходе проверки концепции, мы выполнили все требования к решению. В четвертом квартале был удовлетворен качеством SQL, сгенерированного LLM. Это справедливо для простых задач, для которых требовалось только предложение 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, может изменить правила игры в создании интеллектуальных приложений, которые интегрируются с вашими хранилищами данных, открывая потенциал дохода.
Об авторах
Тамер Солиман — старший архитектор решений в AWS. Он помогает клиентам независимых поставщиков программного обеспечения (ISV) внедрять инновации, создавать и масштабировать приложения на AWS. Он имеет более чем двадцатилетний опыт работы в сфере консалтинга, обучения и профессиональных услуг. Он является изобретателем множества патентов, имеет три выданных патента, а его опыт охватывает различные области технологий, включая телекоммуникации, сети, интеграцию приложений, искусственный интеллект и машинное обучение и развертывание облачных технологий. Он специализируется на сетевых технологиях AWS и страстно увлекается машинным обучением, искусственным интеллектом и генеративным искусственным интеллектом.
Мани Хануджа — технический руководитель отдела генеративного искусственного интеллекта, автор книги «Прикладное машинное обучение и высокопроизводительные вычисления на AWS», а также член совета директоров Фонда образования женщин в производстве. Она возглавляет проекты машинного обучения (ML) в различных областях, таких как компьютерное зрение, обработка естественного языка и генеративный искусственный интеллект. Она помогает клиентам создавать, обучать и развертывать большие модели машинного обучения в любом масштабе. Она выступает на внутренних и внешних конференциях, таких как re:Invent, Women in Manufacturing West, вебинарах YouTube и GHC 23. В свободное время она любит совершать длительные пробежки по пляжу.
Станислав Ещенко является архитектором программного обеспечения в Q4 Inc.. Он имеет более чем десятилетний опыт работы в области разработки программного обеспечения и системной архитектуры. Его разнообразный опыт работы, охватывающий такие должности, как технический руководитель и старший разработчик полного стека, способствует его вкладу в продвижение инноваций платформы Q4. Станислав посвящает себя внедрению технических инноваций и формированию стратегических решений в этой области.
- SEO-контент и PR-распределение. Получите усиление сегодня.
- PlatoData.Network Вертикальный генеративный ИИ. Расширьте возможности себя. Доступ здесь.
- ПлатонАйСтрим. Интеллект Web3. Расширение знаний. Доступ здесь.
- ПлатонЭСГ. Углерод, чистые технологии, Энергия, Окружающая среда, Солнечная, Управление отходами. Доступ здесь.
- ПлатонЗдоровье. Биотехнологии и клинические исследования. Доступ здесь.
- Источник: https://aws.amazon.com/blogs/machine-learning/how-q4-inc-used-amazon-bedrock-rag-and-sqldatabasechain-to-address-numerical-and-structured-dataset-challenges-building-their-qa-chatbot/
- :имеет
- :является
- :нет
- :куда
- $UP
- 100
- 118
- 125
- 15%
- 23
- 7
- a
- способности
- способность
- в состоянии
- абстракция
- изобилие
- приемлемый
- доступ
- доступной
- Учетная запись
- точность
- точный
- Достигать
- через
- акты
- на самом деле
- приспосабливать
- добавленный
- добавить
- дополнение
- дополнительный
- Дополнительно
- дополнениями
- адрес
- адресованный
- Регулировка
- продвинутый
- опережения
- плюс
- После
- против
- агенты
- совокупный
- AI
- Услуги искусственного интеллекта
- варианты использования ИИ
- AI / ML
- Нацеленный
- выравнивать
- выровненный
- Все
- позволять
- разрешено
- вдоль
- причислены
- Несмотря на то, что
- am
- Amazon
- Amazon Web Services
- количество
- суммы
- an
- анализ
- Аналитики
- аналитика
- анализировать
- анализ
- и
- Другой
- ответ
- ответы
- Антропный
- любой
- все
- API
- API
- отношение
- Применение
- Приложения
- прикладной
- подхода
- архитектура
- МЫ
- AS
- спросить
- Активы
- помощник
- помощь
- ассортимент
- At
- увеличивать
- дополненная
- автор
- доступен
- знать
- AWS
- назад
- фон
- основанный
- основной
- BE
- Beach
- стали
- , так как:
- было
- до
- начало
- поведение
- не являетесь
- распространенной
- полезный
- ЛУЧШЕЕ
- лучшие практики
- Лучшая
- между
- миллиарды
- Заблокировать
- Блоки
- доска
- совет директоров
- книга
- Бот
- изоферменты печени
- ширина
- Ломать
- широкий
- строить
- Строительство
- строит
- построенный
- бизнес
- но
- by
- призывают
- пришел
- CAN
- Может получить
- возможности
- возможности
- столица
- Рынки капитала
- заботится
- случаев
- случаев
- цепь
- цепи
- вызов
- проблемы
- проблемы со строительством
- изменение
- Переключатель
- изменения
- характеристика
- Chatbot
- chatbots
- выбор
- Выберите
- Выбирая
- ясность
- чистым
- Очистить
- ближе
- облако
- код
- Кодирование
- Column
- сочетании
- комбинируя
- как
- Комментарии
- в промышленных масштабах
- общаться
- Связь
- сообщество
- Компании
- Компания
- сравнимый
- завершение
- комплекс
- сложность
- Соответствие закону
- компоненты
- постигать
- Вычисление
- компьютер
- Компьютерное зрение
- вычисление
- сама концепция
- вывод
- в заключении исследования, финансируемого Центрами по контролю и профилактике заболеваний (CDC) и написанного бывшим начальником полиции Вермонта
- заключение
- проводятся
- конференции
- Свяжитесь
- Соединительный
- связи
- Рассматривать
- считается
- принимая во внимание
- последовательно
- Состоящий из
- состоит
- строить
- консалтинг
- содержание
- контекст
- контекстной
- продолжать
- непрерывно
- взносы
- обычный
- диалоговый
- конверсий
- переделанный
- координирующий
- Основные
- исправить
- Цена
- может
- Создайте
- критической
- CRM
- решающее значение
- клиент
- Клиенты
- ежедневно
- данным
- Озеро данных
- точки данных
- конфиденциальность данных
- Конфиденциальность и безопасность данных
- наука о данных
- управляемых данными
- База данных
- Наборы данных
- Финики
- десятилетие
- десятилетия
- решенный
- Решение
- преданный
- считается
- определенный
- Спрос
- убивают
- демонстрирует
- зависит
- развертывание
- развертывания
- описывать
- описывающих
- желанный
- подробный
- подробнее
- определяет
- Застройщик
- развивающийся
- Развитие
- различный
- направлять
- непосредственно
- Директора
- обсуждать
- обсуждается
- погружение
- Разное
- do
- домен
- доменов
- Dont
- двойная проверка
- вниз
- вождение
- два
- в течение
- динамический
- каждый
- Ранее
- легко
- экосистема
- Обучение
- Эффективный
- затрат
- эффективный
- эффективно
- усилие
- усилия
- или
- элементы
- приемлемость
- уничтожение
- появление
- занятых
- позволяет
- конец
- впритык
- закончился
- заниматься
- обязательство
- Проект и
- достаточно
- обеспечивать
- оборудованный
- Эквивалент
- ESG
- особенно
- установить
- оценки
- оценка
- Даже
- События
- Каждая
- пример
- Примеры
- существующий
- ожидать
- ожидаемый
- дорогим
- опыт
- эксперимент
- Эксперименты
- эксперту
- опыта
- Разведанный
- экспресс
- выраженный
- простирающийся
- и, что лучший способ
- извлечение
- добыча
- сталкиваются
- облегчает
- факторы
- быстрый темп
- благоприятный
- выполнимый
- несколько
- поле
- Поля
- заполнять
- фильтр
- окончательный
- в заключение
- финансовый
- финансовые данные
- Во-первых,
- Трансформируемость
- поток
- Фокус
- следовать
- после
- Что касается
- формат
- вперед
- содействие
- найденный
- Год основания
- КАДР
- Рамки
- каркасы
- Бесплатно
- от
- полный
- Полный стек
- полностью
- функциональная
- Функции
- далее
- игра
- игра-чейнджер
- GDPR
- Соответствие ВВП
- направленных
- Общие
- порождать
- генерируется
- генерирует
- порождающий
- поколение
- генеративный
- Генеративный ИИ
- получить
- получающий
- Дайте
- данный
- дает
- Отдаете
- Go
- цель
- Цели
- хорошо
- предоставленный
- большой
- группы
- Рост
- было
- рука
- счастливый
- Есть
- имеющий
- he
- со штаб-квартирой
- тяжелый
- тяжелая атлетика
- помощь
- помогает
- ее
- здесь
- High
- высокопроизводительный
- высококачественный
- высший
- наивысший
- Выделенные
- основной момент
- очень
- подсказки
- его
- история
- капот
- Как
- Однако
- HTTPS
- человек
- человек читаемый
- i
- идея
- идентифицированный
- идентифицирующий
- if
- изображение
- Влияние
- влияние
- воздействуя
- Воздействие
- осуществлять
- реализация
- реализации
- в XNUMX году
- последствия
- важную
- улучшать
- in
- В других
- Инк
- включают
- В том числе
- Увеличение
- дополнительный
- независимые
- лиц
- промышленность
- информация
- Инфраструктура
- начальный
- первоначально
- обновлять
- Инновации
- вход
- затраты
- мгновение
- учреждения
- инструкции
- интегрировать
- интеграции.
- намереваться
- взаимодействовать
- взаимодействие
- в нашей внутренней среде,
- переплетенный
- в
- интуитивный
- инвестиций
- инвестор
- Инвесторы
- вовлеченный
- эмитенты
- ISV
- IT
- ЕГО
- путешествие
- JPG
- всего
- Сохранить
- Основные
- знание
- знания
- известный
- Labs
- озеро
- пейзаж
- язык
- большой
- больше
- Фамилия
- наконец
- Задержка
- новее
- слоев
- вести
- ведущий
- Лиды
- узнали
- изучение
- наименее
- привело
- Уроки
- Уроки, извлеченные
- уровень
- Подтяжка лица
- такое как
- нравится
- LLM
- логика
- Лондон
- Длинное
- посмотреть
- искать
- серия
- машина
- обучение с помощью машины
- сделанный
- Главная
- в основном
- Mainstream
- поддерживать
- Сохранение
- сделать
- ДЕЛАЕТ
- управлять
- управляемого
- управление
- производство
- многих
- рынок
- Анализ рынка
- Данные рынка
- Области применения:
- соответствует
- математический
- Май..
- значимым
- означает,
- механизмы
- Встречайте
- член
- встретивший
- Мета
- Метаданные
- метод
- Методология
- microservices
- минимальный
- минимизация
- смешивать
- ML
- модель
- Модели
- Модерн
- Модули
- БОЛЕЕ
- самых
- в основном
- перемещение
- много
- много
- с разными
- имя
- родной
- натуральный
- Обработка естественного языка
- природа
- необходимо
- Необходимость
- необходимый
- отрицательно
- сетей
- Новые
- New York
- следующий
- нет
- в своих размышлениях
- отметив,
- сейчас
- номер
- номера
- цель
- Очевидный
- of
- от
- предложенный
- Предложения
- офицеров
- офисов
- .
- on
- ONE
- только
- открытый
- с открытым исходным кодом
- оптимальный
- оптимизация
- Оптимизировать
- оптимизированный
- оптимизирующий
- Опции
- or
- Orchestrating
- оркестровка
- заказ
- оригинал
- Другое
- наши
- выходной
- за
- общий
- обзор
- подавляющий
- собственный
- принадлежащих
- собственность
- параметры
- часть
- особый
- Прошло
- страсть
- патент
- Патенты
- путь
- Выполнять
- производительность
- выполнения
- выбирать
- штук
- Платформа
- Платон
- Платон Интеллектуальные данные
- ПлатонДанные
- Играть
- Точка
- пунктов
- положительный
- возможное
- После
- потенциал
- мощностью
- полномочия
- практиками
- привилегированный
- представить
- представлены
- предотвращать
- цена
- Принципы
- политикой конфиденциальности.
- Конфиденциальность и безопасность
- процесс
- обработка
- производит
- Произведенный
- Продукция
- профессиональный
- глубокий
- Проект
- проектов
- наводящие
- доказательство
- доказательство концепции
- правильный
- ( изучите наши патенты),
- доказанный
- обеспечивать
- при условии
- приводит
- обеспечение
- что такое варган?
- публичные компании
- публично
- цель
- положил
- Вопросы и ответы
- Запросы
- вопрос
- быстро
- кавычки
- Ранжирование
- скорее
- RE
- готовый
- реальный мир
- реализованный
- Получать
- Управление по борьбе с наркотиками (DEA)
- учет
- привязка
- регулируемых брокеров
- отношения
- отношения
- соответствующие
- Отчеты
- представитель
- представляющий
- представляет
- требовать
- обязательный
- Требования
- ресурс
- уважаемый
- почтение
- ответ
- ответы
- ограничивать
- Итоги
- доходы
- возвращаться
- обзор
- правую
- рисках,
- Роли
- роли
- Комната
- год
- условиями,
- Run
- работает
- то же
- довольный
- доволен
- Сохранить
- сообщили
- Масштабируемость
- Шкала
- Наука
- поцарапать
- бесшовные
- легко
- Поиск
- Во-вторых
- секунды
- Раздел
- безопасный
- безопасность
- посмотреть
- выбор
- Продавцы
- Отправить
- старший
- смысл
- отдельный
- Серии
- Serverless
- обслуживание
- Услуги
- набор
- Наборы
- несколько
- формирование
- акционер
- Акционеры
- она
- должен
- показал
- показанный
- Шоу
- значительный
- просто
- простой
- упрощенный
- упростить
- упрощение
- одинарной
- Размер
- Размеры
- меньше
- умный
- умнее
- Software
- разработка программного обеспечения
- Решение
- Решения
- некоторые
- сложный
- Источник
- Источники
- напряженность
- пролеты
- Говорит
- специалисты
- специализируется
- конкретный
- конкретно
- Стабильность
- стек
- Этап
- Ставки
- стоять
- стоит
- Начало
- и политические лидеры
- Начало
- заявление
- оставаться
- Шаг
- Шаги
- акции
- фондовый рынок
- хранить
- магазины
- простой
- Стратегический
- Структура
- структурированный
- впоследствии
- успех
- Успешно
- такие
- достаточный
- подходящее
- suite
- суммировать
- РЕЗЮМЕ
- поддержка
- Поддержка
- наблюдение
- Коммутатор
- синтаксис
- система
- ТАБЛИЦЫ
- с учетом
- взять
- приняты
- принимает
- с
- Сложность задачи
- задачи
- команда
- технологии
- Технический
- снижения вреда
- Технологии
- телеком
- говорят
- шаблон
- тестXNUMX
- Тестирование
- тестов
- текст
- чем
- Спасибо
- который
- Ассоциация
- Столица
- их
- тогда
- Там.
- Эти
- они
- мышление
- этой
- три
- Через
- по всему
- время
- Временные ряды
- раз
- исполин
- в
- Сегодняшних
- вместе
- знак
- Лексемы
- слишком
- инструментом
- инструменты
- тема
- Торонто
- к
- Train
- специалистов
- Обучение
- сделка
- Сделки
- превращение
- путешествие
- правда
- Доверие
- ОЧЕРЕДЬ
- два
- напишите
- Типы
- типично
- не в состоянии
- под
- лежащий в основе
- понимать
- понимание
- понимает
- понимать
- созданного
- отпирающий
- ненужный
- us
- использование
- прецедент
- используемый
- Информация о пользователе
- удобно
- через
- использует
- действительный
- Проверка
- ценностное
- разнообразие
- различный
- продавец
- проверка
- проверено
- проверить
- очень
- жизнеспособный
- Вид
- Виртуальный
- видение
- от
- стремятся
- законопроект
- Путь..
- we
- Web
- веб-сервисы
- Вебинары
- Вебсайт
- ЧТО Ж
- пошел
- были
- запад
- Что
- Колесо
- когда
- в то время как
- , которые
- в то время как
- будете
- в
- без
- Женщина
- слова
- Работа
- работавший
- рабочий
- работает
- стоимость
- бы
- записывать
- написать код
- XML
- еще
- йорк
- Ты
- ВАШЕ
- YouTube
- зефирнет