Створення цінності з корпоративних даних: найкращі практики для Text2SQL і генеративного штучного інтелекту | Веб-сервіси Amazon

Generative AI відкрив великий потенціал у сфері AI. Ми бачимо численні способи використання, зокрема генерування тексту, генерування коду, узагальнення, переклад, чат-боти тощо. Однією з таких областей, яка розвивається, є використання обробки природної мови (NLP) для відкриття нових можливостей доступу до даних за допомогою інтуїтивно зрозумілих запитів SQL. Замість того, щоб мати справу зі складним технічним кодом, бізнес-користувачі та аналітики даних можуть задавати запитання, пов’язані з даними та інформацією, простою мовою. Основна мета — автоматично генерувати SQL-запити з тексту природною мовою. Для цього введений текст перетворюється на структуроване представлення, і з цього представлення створюється SQL-запит, який можна використовувати для доступу до бази даних.

У цій публікації ми пропонуємо введення тексту в SQL (Text2SQL) і досліджуємо випадки використання, проблеми, шаблони проектування та найкращі практики. Зокрема, ми обговорюємо наступне:

• Навіщо нам Text2SQL
• Ключові компоненти для Text to SQL
• Підкажіть інженерні міркування для природної мови або Text to SQL
• Оптимізація та найкращі практики
• Архітектурні візерунки

Навіщо нам Text2SQL?

Сьогодні великий обсяг даних доступний у традиційній аналітиці даних, сховищах даних і базах даних, які можуть бути нелегкими для запитів або розуміння для більшості членів організації. Основна мета Text2SQL — зробити бази даних запитів більш доступними для нетехнічних користувачів, які можуть надавати свої запити природною мовою.

NLP SQL дозволяє бізнес-користувачам аналізувати дані та отримувати відповіді, вводячи або промовляючи запитання природною мовою, як-от:

• «Показати загальний обсяг продажів для кожного продукту за минулий місяць»
• «Які продукти принесли більше доходу?»
• «Який відсоток клієнтів з кожного регіону?»

Amazon Bedrock – це повністю керований сервіс, який пропонує вибір високопродуктивних базових моделей (FM) через єдиний API, що дає змогу легко створювати та масштабувати програми Gen AI. Його можна використовувати для створення SQL-запитів на основі запитань, подібних до перерахованих вище, а також запитів до структурованих даних організації та створення відповідей природною мовою з даних відповідей на запит.

Ключові компоненти для тексту в SQL

Системи Text-to-SQL включають кілька етапів для перетворення запитів природною мовою в придатний для виконання SQL:

• Обробка природної мови:
  • Проаналізуйте введений користувачем запит
  • Виділіть ключові елементи та наміри
  • Перетворення в структурований формат
• Генерація SQL:
  • Зіставте витягнуті деталі в синтаксис SQL
  • Згенеруйте дійсний SQL-запит
• Запит до бази даних:
  • Запустіть SQL-запит, створений ШІ, до бази даних
  • Отримати результати
  • Повернення результатів користувачеві

Однією чудовою можливістю великих мовних моделей (LLM) є генерація коду, включаючи структуровану мову запитів (SQL) для баз даних. Ці LLM можна використовувати для розуміння питання природної мови та створення відповідного SQL-запиту як результат. Магістри LLM отримають вигоду від прийняття навчання в контексті та точного налаштування налаштувань у міру надходження більшої кількості даних.

Наступна діаграма ілюструє базовий потік Text2SQL.

Підкажіть інженерні міркування для природної мови в SQL

Підказка має вирішальне значення при використанні LLM для перекладу природної мови в запити SQL, і є кілька важливих міркувань щодо розробки підказок.

Ефективний оперативне проектування є ключем до розробки природної мови для систем SQL. Чіткі, зрозумілі підказки надають кращі інструкції для мовної моделі. Надання контексту про те, що користувач запитує SQL-запит разом із відповідними деталями схеми бази даних, дозволяє моделі точно перекладати наміри. Включення кількох анотованих прикладів підказок природної мови та відповідних SQL-запитів допомагає скеровувати модель для отримання виводу, сумісного з синтаксисом. Крім того, включення Retrieval Augmented Generation (RAG), де модель отримує схожі приклади під час обробки, додатково покращує точність відображення. Добре розроблені підказки, які надають моделі достатні інструкції, контекст, приклади та розширення пошуку, є вирішальними для надійного перекладу природної мови в запити SQL.

Нижче наведено приклад базової підказки з представленням коду бази даних із офіційного документа Покращення можливостей перетворення тексту в SQL у великих мовних моделях: дослідження стратегій оперативного проектування.

/* Given the following database schema : */
CREATE TABLE IF NOT EXISTS " gymnast " ( " Gymnast_ID " int , " Floor_Exercise_Points " real , " Pommel_Horse_Points " real , " Rings_Points " real , " Vault_Points " real , " Parallel_Bars_Points " real , " Horizontal_Bar_Points " real , " Total_Points " real , PRIMARY KEY ( " Gymnast_ID " ) , FOREIGN KEY ( " Gymnast_ID " ) REFERENCES " people " ( " People_ID " ) ) ; CREATE TABLE IF NOT EXISTS " people " ( " People_ID " int , " Name " text , " Age " real , " Height " real , " Hometown " text , PRIMARY KEY ( " People_ID " ) ) ; /* Answer the following : Return the total points of the gymnast with the lowest age .
*/ select t1 . total_points from gymnast as t1 join people as t2 on t1 . gymnast_id = t2 .
people_id order by t2 . age asc limit 1

Як показано в цьому прикладі, навчання на основі підказок за кількома випадками надає моделі кілька анотованих прикладів у самій підказці. Це демонструє цільове відображення між природною мовою та SQL для моделі. Як правило, підказка міститиме приблизно 2–3 пари, які показуватимуть запит природною мовою та еквівалентний оператор SQL. Ці кілька прикладів скеровують модель для створення сумісних із синтаксисом запитів SQL з природної мови, не вимагаючи великих навчальних даних.

Тонка настройка проти оперативного проектування

Під час створення природної мови для систем SQL ми часто вступаємо в дискусію про те, чи точне налаштування моделі є правильною технікою, чи ефективна оперативна інженерія є шляхом. Обидва підходи можна розглянути та вибрати на основі правильного набору вимог:

• • Тонка настройка – Базова модель попередньо тренується на великому загальному текстовому корпусі, а потім може використовуватися точне налаштування на основі інструкцій, який використовує позначені приклади для покращення продуктивності попередньо навченої базової моделі на текстовому SQL. Це адаптує модель до цільового завдання. Тонке налаштування безпосередньо тренує модель на кінцевому завданні, але вимагає багато текстових прикладів SQL. Ви можете використовувати контрольовану точну настройку на основі свого LLM, щоб підвищити ефективність перетворення тексту в SQL. Для цього ви можете використовувати кілька наборів даних, наприклад Павук, WikiSQL, CHASE, BIRD-SQLабо CoSQL.
  • Швидка інженерія – Модель навчена виконувати підказки, призначені для підказки цільового синтаксису SQL. Під час генерації SQL з природної мови за допомогою LLM надання чітких інструкцій у підказці є важливим для контролю результату моделі. У підказці анотувати різні компоненти, наприклад вказувати на стовпці, схему, а потім вказувати, який тип SQL створити. Вони діють як інструкції, які повідомляють моделі, як форматувати вихідні дані SQL. У наступній підказці показано приклад, коли ви вказуєте стовпці таблиці та вказуєте створити запит MySQL:

Table offices, columns = [OfficeId, OfficeName]
Table employees, columns = [OfficeId, EmployeeId,EmployeeName]
Create a MySQL query for all employees in the Machine Learning Department

Ефективний підхід до моделей тексту в SQL полягає в тому, щоб спочатку почати з базового LLM без будь-яких тонких налаштувань для конкретного завдання. Добре розроблені підказки потім можна використовувати для адаптації та управління базовою моделлю для обробки відображення тексту в SQL. Ця оперативна інженерна робота дозволяє розвинути можливості без необхідності тонкого налаштування. Якщо оперативне проектування на базовій моделі не досягає достатньої точності, можна досліджувати точне налаштування невеликого набору прикладів текстового SQL разом із подальшим оперативним проектуванням.

Поєднання точного налаштування та оперативного проектування може знадобитися, якщо лише швидке проектування на сирій попередньо навченій моделі не відповідає вимогам. Однак спочатку краще спробувати оперативне проектування без тонкого налаштування, оскільки це дає змогу виконувати швидку ітерацію без збору даних. Якщо це не забезпечує належної продуктивності, доцільним наступним кроком є ​​точне налаштування разом із оперативним проектуванням. Цей загальний підхід максимізує ефективність, але все ще дозволяє налаштувати, якщо методів, заснованих на підказках, недостатньо.

Оптимізація та найкращі практики

Оптимізація та найкращі практики необхідні для підвищення ефективності та забезпечення оптимального використання ресурсів і досягнення правильних результатів найкращим способом. Методи допомагають підвищити продуктивність, контролювати витрати та досягти кращого результату.

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

• кешування – Щоб покращити час затримки, контроль витрат і стандартизацію, ви можете кешувати проаналізований SQL і розпізнані підказки запиту з тексту в SQL LLM. Це дозволяє уникнути повторної обробки повторних запитів.
• Моніторинг – Слід збирати журнали та показники аналізу запитів, оперативного розпізнавання, генерації SQL і результатів SQL, щоб контролювати систему LLM для перетворення тексту в SQL. Це забезпечує видимість для прикладу оптимізації, оновлюючи підказку або переглядаючи тонке налаштування з оновленим набором даних.
• Матеріалізовані види проти таблиць – Матеріалізовані представлення можуть спростити генерацію SQL і підвищити продуктивність для типових запитів тексту в SQL. Пряме запитування таблиць може призвести до складного SQL, а також призвести до проблем із продуктивністю, включаючи постійне створення методів продуктивності, таких як індекси. Крім того, ви можете уникнути проблем із продуктивністю, якщо ту саму таблицю одночасно використовувати для інших областей застосування.
• Оновлення даних – Матеріалізовані подання потрібно оновлювати за розкладом, щоб підтримувати актуальність даних для запитів тексту в SQL. Щоб збалансувати накладні витрати, можна використовувати пакетне або поетапне оновлення.
• Центральний каталог даних – Створення централізованого каталогу даних надає єдине вікно для перегляду джерел даних організації та допоможе магістрам права вибрати відповідні таблиці та схеми, щоб надавати більш точні відповіді. Вектор вбудовування створений із центрального каталогу даних, можна надати LLM разом із інформацією, необхідною для створення релевантних і точних відповідей SQL.

Застосовуючи найкращі методи оптимізації, такі як кешування, моніторинг, матеріалізовані перегляди, оновлення за розкладом і центральний каталог, ви можете значно покращити продуктивність і ефективність систем перетворення тексту в SQL за допомогою LLM.

Архітектурні візерунки

Давайте розглянемо деякі шаблони архітектури, які можна реалізувати для робочого процесу тексту в SQL.

Швидка інженерія

Наступна діаграма ілюструє архітектуру для генерування запитів за допомогою LLM за допомогою оперативного проектування.

У цьому шаблоні користувач створює кількакратне навчання на основі підказок, яке надає моделі анотовані приклади в самій підказці, яка включає деталі таблиці та схеми та деякі зразки запитів із її результатами. LLM використовує надану підказку, щоб повернути згенерований штучним інтелектом SQL, який перевіряється, а потім запускається в базі даних для отримання результатів. Це найпростіший шаблон для початку використання швидкого проектування. Для цього можна використовувати Amazon Bedrock or моделі фундаменту in Amazon SageMaker JumpStart.

У цьому шаблоні користувач створює кількакратне навчання на основі підказок, яке надає моделі анотовані приклади в самій підказці, яка включає деталі таблиці та схеми та деякі зразки запитів із її результатами. LLM використовує надану підказку, щоб повернути SQL, згенерований штучним інтелектом, який перевірено та запускається в базі даних для отримання результатів. Це найпростіший шаблон для початку використання швидкого проектування. Для цього можна використовувати Amazon Bedrock це повністю керований сервіс, який пропонує вибір високопродуктивних базових моделей (FM) від провідних компаній штучного інтелекту через єдиний API, а також широкий набір можливостей, необхідних для створення генеративних програм ШІ з безпекою, конфіденційністю та відповідальним ШІ. або Моделі JumpStart Foundation який пропонує найсучасніші основні моделі для таких випадків використання, як написання вмісту, генерація коду, відповіді на запитання, копірайтинг, узагальнення, класифікація, пошук інформації тощо

Швидке проектування та доведення

Наступна діаграма ілюструє архітектуру для генерування запитів за допомогою LLM із використанням оперативного проектування та точного налаштування.

Цей потік схожий на попередній шаблон, який здебільшого покладається на оперативне проектування, але з додатковим потоком тонкого налаштування набору даних для домену. Тонко налаштований LLM використовується для генерації SQL-запитів із мінімальним значенням у контексті підказки. Для цього ви можете використовувати SageMaker JumpStart для точного налаштування LLM на доменно-спеціальному наборі даних так само, як ви б навчали та розгортали будь-яку модель на Amazon SageMaker.

Оперативний інженерний і RAG

На наведеній нижче діаграмі показано архітектуру для створення запитів за допомогою LLM за допомогою оперативного проектування та RAG.

У цьому шаблоні ми використовуємо Доповнена генерація пошуку використання векторних вбудованих магазинів, наприклад Amazon Titan Embeddings or Cohere Embed, На Amazon Bedrock із центрального каталогу даних, наприклад Клей AWS Каталог даних, баз даних в організації. Вбудовані вектори зберігаються у векторних базах даних, наприклад Vector Engine для Amazon OpenSearch Serverless, Служба реляційної бази даних Amazon (Amazon RDS) для PostgreSQL з pgvector розширення, або Амазонка Кендра. LLM використовують векторні вбудовування, щоб швидше вибирати правильну базу даних, таблиці та стовпці з таблиць під час створення запитів SQL. Використання RAG корисно, коли дані та релевантна інформація, яку необхідно отримати LLM, зберігаються в кількох окремих системах баз даних, і LLM повинен мати можливість шукати або запитувати дані в усіх цих різних системах. Саме тут надання векторних вставок централізованого або уніфікованого каталогу даних LLMs призводить до більш точної та повної інформації, що повертається LLMs.

Висновок

У цьому дописі ми обговорювали, як ми можемо генерувати цінність корпоративних даних за допомогою природної мови для створення SQL. Ми розглянули ключові компоненти, оптимізацію та найкращі практики. Ми також вивчали шаблони архітектури від базової розробки підказок до тонкого налаштування та RAG. Щоб дізнатися більше, зверніться до Amazon Bedrock легко створювати та масштабувати генеративні програми ШІ за допомогою базових моделей

Про авторів

Ренді ДеФо є старшим головним архітектором рішень в AWS. Він має ступінь MSEE Мічиганського університету, де працював над комп’ютерним зором для автономних транспортних засобів. Він також має ступінь магістра ділового адміністрування в Університеті штату Колорадо. Ренді обіймав різні посади в технологічному просторі, починаючи від розробки програмного забезпечення та закінчуючи управлінням продуктами. In увійшов у сферу великих даних у 2013 році та продовжує досліджувати цю сферу. Він активно працює над проектами у сфері машинного навчання та виступає з доповідями на численних конференціях, зокрема Strata та GlueCon.

Нітін Євсевій є старшим архітектором корпоративних рішень в AWS, має досвід розробки програмного забезпечення, корпоративної архітектури та штучного інтелекту/ML. Він глибоко захоплений дослідженням можливостей генеративного ШІ. Він співпрацює з клієнтами, щоб допомогти їм створювати добре архітектурні додатки на платформі AWS, і присвячує себе вирішенню технологічних проблем і допомозі в їхній хмарній подорожі.

Арг'я Банерджі є старшим архітектором рішень в AWS в районі затоки Сан-Франциско, який зосереджений на тому, щоб допомогти клієнтам адаптувати та використовувати AWS Cloud. Arghya зосереджена на великих даних, озерах даних, потоковій передачі, пакетній аналітиці та послугах і технологіях AI/ML.

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
• PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
• ПлатонЕСГ. вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
• PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
• джерело: https://aws.amazon.com/blogs/machine-learning/generating-value-from-enterprise-data-best-practices-for-text2sql-and-generative-ai/