Створення інформаційної межі з розмовним доступом до даних

Перевидано Платоном

читають: 0

розмовний ШІ для аналізу даних

Рисунок 1: Представлення потоку Text2SQL

Оскільки наш світ стає все більш глобальним і динамічним, бізнес все більше і більше залежить від даних для прийняття обґрунтованих, об’єктивних і своєчасних рішень. Однак на даний момент розкриття повного потенціалу організаційних даних часто є привілеєм жменьки вчених і аналітиків даних. Більшість співробітників не володіють звичайним інструментарієм обробки даних (SQL, Python, R тощо). Щоб отримати доступ до потрібних даних, вони проходять через додатковий рівень, де аналітики або команди BI «перекладають» прозу бізнес-питань на мову даних. Потенціал тертя та неефективності під час цієї подорожі високий — наприклад, дані можуть надаватися із затримками або навіть коли питання вже застаріло. Інформація може бути втрачена в дорозі, якщо вимоги не будуть точно переведені в аналітичні запити. Крім того, генерація високоякісної інформації вимагає ітераційного підходу, який не рекомендується використовувати з кожним додатковим кроком у циклі. З іншого боку, ці випадкові взаємодії створюють перешкоди для дорогих спеціалістів із обробки даних і відволікають їх від більш стратегічної роботи з даними, як описано в цих «зізнаннях» спеціаліста з обробки даних:

Коли я був у Square і команда була меншою, у нас була жахлива ротація «аналітики за викликом». Його чергували щотижня, і якщо ви з’являлися, ви знали, що того тижня виконайте дуже мало «справжньої» роботи й витрачатимете більшу частину свого часу, відповідаючи на спеціальні запитання від різних груп продуктів і операцій у компанія (ми назвали це SQL monkeying). У аналітичній команді була жорстока конкуренція за посади менеджерів, і я думаю, що це було повністю результатом того, що менеджерів було звільнено від цієї ротації — жодна нагорода за статус не могла зрівнятися з пряником невиконання роботи за викликом.[1]

Дійсно, хіба не було б круто спілкуватися безпосередньо з вашими даними замість того, щоб проходити кілька раундів взаємодії з вашим персоналом обробки даних? Це бачення охоплюється розмовними інтерфейсами, які дозволяють людям взаємодіяти з даними за допомогою мови, нашого найбільш інтуїтивно зрозумілого та універсального каналу спілкування. Після аналізу запитання алгоритм кодує його в структуровану логічну форму на вибраній мові запитів, наприклад SQL. Таким чином, нетехнічні користувачі можуть спілкуватися зі своїми даними в чаті та швидко отримувати конкретну, релевантну та своєчасну інформацію, не звертаючись до команди BI. У цій статті ми розглянемо різні аспекти впровадження Text2SQL і зосередимося на сучасних підходах із використанням великих мовних моделей (LLM), які досягають найкращої продуктивності на даний момент (див. [2]; огляд альтернативних підходів окрім LLM, читачів згадують [3]). Стаття побудована відповідно до наступної «ментальної моделі» основних елементів, які слід враховувати під час планування та створення функції ШІ:

розмовний ШІ для аналізу даних — Рисунок 2: Ментальна модель функції ШІ

Давайте почнемо з кінця і нагадаємо про цінність — чому вам потрібно вбудувати функцію Text2SQL у ваші дані чи аналітичний продукт. Три основні переваги:

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

Тепер, які сценарії продукту ви можете розглянути Text2SQL? Три основні налаштування:

Ви пропонуєте a масштабовані дані/продукт BI і хочуть надати більшій кількості користувачів доступ до своїх даних у нетехнічний спосіб, таким чином збільшуючи як використання, так і базу користувачів. Як приклад, ServiceNow має інтегровані запити даних у більшу розмовну пропозицію та Атлан останнім часом оголосив дослідження даних природною мовою.
Ви прагнете створити щось у просторі даних/ШІ, щоб демократизувати доступ до даних у компаніях, у такому випадку ви потенційно можете розглянути MVP з Text2SQL в основі. Провайдерам подобається AI2SQL та Text2sql.ai вже входять у цей простір.
Ви працюєте над a індивідуальна система BI і хочуть максимізувати та демократизувати його використання в окремій компанії.

Як ми побачимо в наступних розділах, Text2SQL вимагає нетривіального попереднього налаштування. Щоб оцінити рентабельність інвестицій, враховуйте характер рішень, які потрібно підтримувати, а також наявні дані. Text2SQL може бути абсолютним виграшем у динамічних середовищах, де дані швидко змінюються та активно й часто використовуються для прийняття рішень, таких як інвестиції, маркетинг, виробництво та енергетика. У цих середовищах традиційні інструменти для управління знаннями є надто статичними, а більш вільні способи доступу до даних та інформації допомагають компаніям отримати конкурентну перевагу. З точки зору даних, Text2SQL забезпечує найбільшу цінність з базою даних, яка:

Великий і зростаючий, щоб Text2SQL міг розкривати свою цінність з часом, оскільки використовується все більше даних.
Високоякісний, щоб алгоритму Text2SQL не доводилося мати справу з надмірним шумом (неузгодженістю, порожніми значеннями тощо) у даних. Загалом дані, які автоматично генеруються програмами, мають вищу якість і послідовність, ніж дані, які створюються та обслуговуються людьми.
Семантично зрілий на відміну від необроблених, щоб люди могли запитувати дані на основі центральних концепцій, зв’язків і показників, які існують у їхній розумовій моделі. Зауважте, що семантичної зрілості можна досягти за допомогою додаткового етапу перетворення, який приводить необроблені дані в концептуальну структуру (пор. розділ «Збагачення підказки інформацією з бази даних»).

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

Якщо цей поглиблений навчальний контент стане для вас корисним, ви можете підпишіться на наш список розсилки досліджень ШІ щоб отримати попередження, коли ми випускаємо новий матеріал.

1. Дані

Будь-яка спроба машинного навчання починається з даних, тому ми почнемо з уточнення структури вхідних і цільових даних, які використовуються під час навчання та прогнозування. У цій статті ми будемо використовувати потік Text2SQL з рисунка 1 як наше поточне представлення та виділимо компоненти та зв’язки, які зараз розглядаються, жовтим кольором.

1.1 Формат і структура даних

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

Питання: «Укажіть ім’я та кількість підписників для кожного користувача».

SQL query:

виберіть ім'я, підписників з user_profiles

У просторі навчальних даних відображення між запитаннями та запитами SQL є багато-до-багатьох:

Запит SQL можна зіставити з багатьма різними запитаннями природною мовою; наприклад, наведену вище семантику запиту можна виразити так: “покажи мені імена та кількість підписників на користувача»,«скільки підписників на кожного користувача?І т.д.
Синтаксис SQL дуже універсальний, і майже кожне запитання можна представити в SQL різними способами. Найпростішим прикладом є різні впорядкування речень WHERE. З більш просунутої точки зору кожен, хто займався оптимізацією SQL-запитів, знає, що багато шляхів ведуть до одного результату, а семантично еквівалентні запити можуть мати зовсім інший синтаксис.

Ручний збір навчальних даних для Text2SQL є особливо виснажливим. Це вимагає не лише володіння SQL від анотатора, але й більше часу на кожен приклад, ніж для більш загальних лінгвістичних завдань, таких як аналіз настроїв і класифікація тексту. Щоб забезпечити достатню кількість навчальних прикладів, можна використовувати доповнення даних — наприклад, LLMs можна використовувати для створення перефразів для того самого питання. [3] містить більш повний огляд методів розширення даних Text2SQL.

1.2 Збагачення підказки інформацією з бази даних

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

Стовпці та таблиці бази даних
Зв'язки між таблицями (зовнішні ключі)
Вміст бази даних

Існує два варіанти включення знань про базу даних: з одного боку, навчальні дані можуть бути обмежені прикладами, написаними для конкретної бази даних, і в цьому випадку схема вивчається безпосередньо з SQL-запиту та її відображення на запитання. Це налаштування однієї бази даних дозволяє оптимізувати алгоритм для окремої бази даних та/або компанії. Однак це вбиває будь-які амбіції щодо масштабованості, оскільки модель потребує тонкого налаштування для кожного окремого клієнта чи бази даних. Крім того, у налаштуваннях із кількома базами даних схему бази даних можна надати як частину вхідних даних, дозволяючи алгоритму «узагальнювати» нові схеми бази даних, які ще не використовуються. Хоча вам обов’язково потрібно буде скористатися цим підходом, якщо ви хочете використовувати Text2SQL у багатьох різних базах даних, майте на увазі, що це вимагає значних оперативних зусиль з розробки. Для будь-якої розумної бізнес-бази даних включення повної інформації до підказки буде вкрай неефективним і, швидше за все, неможливим через обмеження довжини підказки. Таким чином, функція, відповідальна за оперативне формулювання, повинна бути достатньо розумною, щоб вибрати підмножину інформації бази даних, яка є найбільш «корисною» для певного питання, і зробити це для потенційно невидимих баз даних.

Нарешті, структура бази даних відіграє вирішальну роль. У тих сценаріях, коли ви маєте достатній контроль над базою даних, ви можете полегшити життя вашої моделі, дозволивши їй навчатися з інтуїтивно зрозумілої структури. За емпіричним правилом, чим більше ваша база даних відображає те, як бізнес-користувачі говорять про бізнес, тим краще й швидше ваша модель може навчитися з неї. Таким чином, подумайте про застосування додаткових перетворень до даних, таких як збирання нормалізованих або іншим чином розподілених даних у широкі таблиці або сховище даних, іменування таблиць і стовпців явним і недвозначним способом тощо. Усі бізнес-знання, які ви можете закодувати заздалегідь, зменшать тягар імовірнісного навчання на вашій моделі та допоможе вам досягти кращих результатів.

2. алгоритм

Text2SQL є типом семантичний розбір — відображення текстів у логічні представлення. Таким чином, алгоритм має не тільки «вивчати» природну мову, а й цільове представлення — у нашому випадку SQL. Зокрема, він повинен набути наступних частин знань:

Синтаксис і семантика SQL
Структура бази даних
Розуміння природної мови (NLU)
Відображення між природною мовою та запитами SQL (синтаксичними, лексичними та семантичними)

2.1 Вирішення лінгвістичної варіативності у вхідних даних

Основна проблема Text2SQL полягає в гнучкості мови: як описано в розділі «Формат і структура даних», те саме питання можна перефразувати багатьма різними способами. Крім того, у контексті розмови в реальному житті ми маємо справу з низкою проблем, таких як орфографічні та граматичні помилки, неповні та неоднозначні введення, багатомовні введення тощо.

LLM, такі як моделі GPT, T5 і CodeX, наближаються до вирішення цієї проблеми. Навчаючись на величезній кількості різноманітного тексту, вони вчаться мати справу з великою кількістю мовних шаблонів і нерегулярностей. Зрештою, вони стають здатними узагальнювати питання, які семантично схожі, незважаючи на те, що мають різні зовнішні форми. LLMs можуть бути застосовані з коробки (нульовий постріл) або після точного налаштування. Перше, хоч і зручно, але призводить до зниження точності. Останній вимагає більшої вправності та праці, але може значно збільшити точність.

З точки зору точності, як і очікувалося, найефективнішими моделями є останні моделі сімейства GPT, включаючи моделі CodeX. У квітні 2023 року GPT-4 привів до значного підвищення точності більш ніж на 5% порівняно з попереднім сучасним обладнанням і досяг точності 85.3% (за показником «виконання зі значеннями»)[4]. У таборі відкритих вихідних кодів початкові спроби розв’язати головоломку Text2SQL були зосереджені на моделях автоматичного кодування, таких як BERT, які чудово справляються із завданнями NLU.[5, 6, 7]. Однак, серед ажіотажу навколо генеративного ШІ, останні підходи зосереджені на на моделях авторегресії, таких як модель T5. T5 попередньо навчений за допомогою багатозадачного навчання і тому легко адаптується до нових лінгвістичних завдань, у т.ч. різні варіанти семантичного розбору. Однак у авторегресійних моделей є внутрішня вада, коли справа доходить до завдань семантичного аналізу: вони мають необмежений простір виводу та не мають семантичних огорож, які б обмежували їхній вивід, що означає, що вони можуть бути надзвичайно креативними у своїй поведінці. Хоча це дивовижний матеріал для генерування вмісту вільної форми, це незручність для таких завдань, як Text2SQL, де ми очікуємо обмеженого, добре структурованого цільового виводу.

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

Щоб обмежити вихід LLM, ми можемо запровадити додаткові механізми перевірки та покращення запиту. Це може бути реалізовано як додатковий етап перевірки, як запропоновано в системі PICARD.[8] PICARD використовує аналізатор SQL, який може перевірити, чи може частковий SQL-запит привести до правильного SQL-запиту після завершення. На кожному кроці генерації LLM токени, які можуть зробити запит недійсним, відхиляються, а дійсні токени з найвищою ймовірністю зберігаються. Будучи детермінованим, цей підхід забезпечує 100% валідність SQL, якщо аналізатор дотримується правильних правил SQL. Він також відокремлює перевірку запиту від генерації, таким чином дозволяючи підтримувати обидва компоненти незалежно один від одного та оновлювати та модифікувати LLM.

Інший підхід полягає в тому, щоб включити структурні та SQL знання безпосередньо в LLM. Наприклад, Graphix [9] використовує шари з підтримкою графів для введення структурованих знань SQL у модель T5. Через імовірнісну природу цього підходу він схиляє систему до правильних запитів, але не дає гарантії успіху.

Нарешті, LLM можна використовувати як багатоетапний агент, який може автономно перевіряти та покращувати запит.[10] Використовуючи кілька кроків у ланцюжку думок, агенту можна доручити обміркувати правильність власних запитів і усунути будь-які недоліки. Якщо підтверджений запит усе ще не може бути виконано, зворотне відстеження винятків SQL можна передати агенту як додатковий відгук для покращення.

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

2.3 Оцінка

Щоб оцінити наш алгоритм Text2SQL, нам потрібно створити тестовий (перевірочний) набір даних, запустити на ньому наш алгоритм і застосувати відповідні оціночні метрики до результату. Наївний набір даних, розділений на дані навчання, розробки та перевірки, базуватиметься на парах запитань і запитів і призведе до неоптимальних результатів. Запити перевірки можуть бути виявлені моделі під час навчання та призвести до надто оптимістичного погляду на її навички узагальнення. А поділ на основі запитів, де набір даних розділений таким чином, що жоден запит не з’являється ні під час навчання, ні під час перевірки, забезпечує більш правдиві результати.

З точки зору показників оцінки, те, про що ми дбаємо в Text2SQL, — це не генерувати запити, які повністю ідентичні золотому стандарту. Це «точна відповідність рядка» метод є надто суворим і генеруватиме багато помилкових негативів, оскільки різні запити SQL можуть призвести до того самого поверненого набору даних. Натомість ми хочемо досягти високого семантична точність і оцінити, чи завжди прогнозовані запити та запити «золотого стандарту» повертатимуть однакові набори даних. Є три метрики оцінювання, які приблизно відповідають цій меті:

Точна точність збігу: згенеровані та цільові запити SQL розбиваються на складові, а отримані набори порівнюються на ідентичність.[11] Недоліком тут є те, що він враховує лише варіації порядку в SQL-запиті, але не більш виражені синтаксичні відмінності між семантично еквівалентними запитами.
Точність виконання: набори даних, отримані в результаті створених і цільових SQL-запитів, порівнюються на предмет ідентифікації. Якщо пощастить, запити з різною семантикою можуть пройти цей тест на певному екземплярі бази даних. Наприклад, припустивши базу даних, у якій усі користувачі старше 30 років, наступні два запити повернуть ідентичні результати, незважаючи на різну семантику:
виберіть * від користувача
виберіть * від користувача, якому вік > 30
Точність набору тестів: точність набору тестів є більш вдосконаленою та менш дозволеною версією точності виконання. Для кожного запиту створюється набір («набір тестів») баз даних, які сильно диференційовані щодо змінних, умов і значень у запиті. Потім на кожній із цих баз даних перевіряється точність виконання. Вимагаючи додаткових зусиль для створення тестового набору, цей показник також значно знижує ризик помилкових спрацьовувань під час оцінювання.[12]

3. Досвід користувача

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

3.1 Управління відмовами

Text2SQL може виходити з ладу в двох режимах, які потрібно виловлювати різними способами:

Помилки SQL: створений запит недійсний — або SQL недійсний, або його неможливо виконати для певної бази даних через лексичні чи семантичні недоліки. У цьому випадку користувачеві неможливо повернути результат.
Смислові помилки: згенерований запит дійсний, але він не відображає семантику запитання, що призводить до неправильного повернутого набору даних.

Другий режим є особливо складним, оскільки ризик «тихих збоїв» — помилок, які залишаються непоміченими користувачем — високий. Прототипний користувач не матиме ані часу, ані технічних навичок, щоб перевірити правильність запиту та/або отриманих даних. Коли дані використовуються для прийняття рішень у реальному світі, такий збій може мати руйнівні наслідки. Щоб цього уникнути, важливо навчити користувачів і встановити огорожі на бізнес-рівні які обмежують потенційний вплив, як-от додаткові перевірки даних для рішень із більшим впливом. З іншого боку, ми також можемо використовувати інтерфейс користувача, щоб керувати взаємодією людини і машини та допомагати користувачеві виявляти та покращувати проблемні запити.

3.2 Людино-машинна взаємодія

Користувачі можуть залучатися до вашої системи ШІ з різним ступенем інтенсивності. Більше взаємодії на запит може призвести до кращих результатів, але це також уповільнює плавність взаємодії з користувачем. Окрім потенційного негативного впливу помилкових запитів і результатів, також подумайте про те, наскільки ваші користувачі будуть мотивовані надавати зворотній зв’язок, щоб отримати точніші результати та допомогти покращити продукт у довгостроковій перспективі.

Найпростіший і найменш захоплюючий спосіб — це працювати з показниками впевненості. Хоча наївне обчислення впевненості як середнього значення ймовірностей згенерованих токенів є надто спрощеним, можна використовувати більш просунуті методи, такі як вербалізований зворотний зв’язок. [13] Достовірність може відображатися в інтерфейсі та підсвічуватися явним сповіщенням, якщо вона небезпечно низька. Таким чином, відповідальність за відповідні подальші дії в «реальному світі» — будь то відхилення, прийняття чи додаткова перевірка даних — лягає на плечі вашого користувача. Хоча це безпечний вибір для вас як постачальника, передача цієї роботи користувачеві також може знизити цінність вашого продукту.

Друга можливість полягає в тому, щоб залучити користувача до роз’яснювального діалогу у випадку ненадійних, неоднозначних чи інших підозрілих запитів. Наприклад, ваша система може запропонувати орфографічні чи граматичні виправлення введених даних і попросити усунути неоднозначність певних слів або граматичних структур. Це також може дозволити користувачеві заздалегідь запитувати виправлення в запиті:[14]

КОРИСТУВАЧ: Покажіть мені завдання Джона в цьому спринті.

ДОПОМОГА: Хочете побачити завдання, створені Джоном, або ті, над якими він працює?

КОРИСТУВАЧ: завдань, створених Джоном

ДОПОМОГА: Добре, ось ідентифікатори завдань:

КОРИСТУВАЧ: Дякую, я також хотів би побачити більше інформації про завдання. Також сортуйте за терміновістю.

ДОПОМОГА: Звичайно, ось завдання разом із короткими описами, виконавцями та термінами, відсортованими за термінами.

Нарешті, щоб полегшити розуміння запитів користувачем, ваша система також може надати явне текстове переформулювання запиту та попросити користувача або підтвердити, або виправити його.[15]

4. Нефункціональні вимоги

У цьому розділі ми обговорюємо конкретні нефункціональні вимоги для Text2SQL, а також компроміси між ними. Ми зосередимося на шести вимогах, які здаються найважливішими для завдання: точність, масштабованість, швидкість, пояснюваність, конфіденційність і адаптивність у часі.

4.1 Точність

Для Text2SQL вимоги до точності високі. По-перше, Text2SQL зазвичай застосовується в налаштуваннях розмови, де передбачення робляться по одному. Таким чином, «закон великих чисел», який зазвичай допомагає збалансувати помилку в пакетних прогнозах, не допомагає. По-друге, синтаксична та лексична валідність є «важкою» умовою: модель має генерувати добре сформований SQL-запит, потенційно зі складним синтаксисом і семантикою, інакше запит не може бути виконано до бази даних. І якщо це вдасться і запит можна буде виконати, він усе ще може містити семантичні помилки та призвести до неправильного повернутого набору даних (див. розділ 3.1 Керування помилками).

4.2 Масштабованість

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

Швидкість 4.3

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

4.4 Зрозумілість і прозорість

В ідеальному випадку користувач може стежити за тим, як був згенерований запит із тексту, бачити відповідність між конкретними словами чи виразами у запитанні та SQL-запитом тощо. Це дозволяє перевірити запит і внести будь-які корективи під час взаємодії з системою. . Крім того, система може також надати явне текстове переформулювання запиту та попросити користувача підтвердити або виправити його.

Конфіденційність 4.5

Функцію Text2SQL можна ізолювати від виконання запиту, тому повернута інформація бази даних може бути невидимою. Однак критичним питанням є те, скільки інформації про базу даних включено в підказку. Три варіанти (зниження рівня конфіденційності):

Немає інформації
Схема бази даних
Вміст бази даних

Конфіденційність компроміс із точністю — чим менше ви будете змушені включати корисну інформацію в підказку, тим кращі результати.

4.6 Адаптивність з часом

Щоб довгостроково використовувати Text2SQL, вам потрібно адаптуватися до дрейфу даних, тобто зміни розподілу даних, до яких застосована модель. Наприклад, припустімо, що дані, які використовуються для початкового тонкого налаштування, відображають просту поведінку запитів користувачів, коли вони починають використовувати систему BI. З часом інформаційні потреби користувачів стають складнішими та вимагають складніших запитів, які перевантажують вашу наївну модель. Крім того, цілі або стратегія компанії можуть змінюватися і спрямовувати потреби в інформації в інші області бази даних. І, нарешті, проблемою, характерною для Text2SQL, є дрейф бази даних. Оскільки база даних компанії розширюється, нові, невидимі стовпці та таблиці потрапляють у підказку. Хоча алгоритми Text2SQL, розроблені для застосування з кількома базами даних, можуть добре впоратися з цією проблемою, це може значно вплинути на точність моделі з однією базою даних. Усі ці проблеми найкраще вирішити за допомогою точного налаштування набору даних, який відображає поточну поведінку користувачів у реальному світі. Таким чином, дуже важливо реєструвати запитання користувачів і результати, а також будь-які пов’язані відгуки, які можна зібрати під час використання. Крім того, алгоритми семантичної кластеризації, наприклад з використанням вбудовування або тематичного моделювання, можна застосовувати для виявлення основних довгострокових змін у поведінці користувачів і використовувати їх як додаткове джерело інформації для вдосконалення вашого набору даних для точного налаштування.

Висновок

Підсумуємо ключові моменти статті:

Text2SQL дозволяє реалізувати інтуїтивно зрозумілий і демократичний доступ до даних у бізнесі, таким чином максимізуючи цінність доступних даних.
Дані Text2SQL складаються із запитань на вході та запитів SQL на виході. Відображення між запитаннями та SQL-запитами є багато-до-багатьох.
Важливо надати інформацію про базу даних як частину підказки. Крім того, структуру бази даних можна оптимізувати, щоб полегшити її вивчення та розуміння алгоритмом.
Що стосується вхідних даних, головною проблемою є лінгвістична варіативність питань природною мовою, до яких можна підійти за допомогою LLM, попередньо навчених широкому спектру різних стилів тексту
Результат Text2SQL має бути дійсним запитом SQL. Це обмеження можна включити шляхом «введення» знань SQL в алгоритм; альтернативно, використовуючи ітераційний підхід, запит можна перевірити та покращити за декілька кроків.
Через потенційно великий вплив «тихих збоїв», які повертають неправильні дані для прийняття рішень, керування збоями є головною проблемою в інтерфейсі користувача.
У «доповненому» вигляді користувачі можуть брати активну участь в ітераційній перевірці та вдосконаленні запитів SQL. Незважаючи на те, що це робить програму менш гнучкою, це також зменшує кількість відмов, дозволяє користувачам досліджувати дані більш гнучким способом і створює цінні сигнали для подальшого навчання.
Основними нефункціональними вимогами, які слід враховувати, є точність, масштабованість, швидкість, зрозумілість, конфіденційність і адаптивність у часі. Основні компроміси полягають між точністю, з одного боку, і масштабованістю, швидкістю та конфіденційністю, з іншого боку.

посилання

[1] Кен Ван Харен. 2023 рік. Заміна аналітика SQL на 26 рекурсивних підказок GPT

[2] Нітаршан Раджкумар та ін. 2022 рік. Оцінка можливостей Text-to-SQL великих мовних моделей

[3] Найхао Денг та ін. 2023 рік. Останні досягнення в Text-to-SQL: огляд того, що ми маємо та чого ми очікуємо

[4] Mohammadreza Pourreza та ін. 2023 рік. DIN-SQL: розкладене в контексті навчання тексту в SQL із самовиправленням

[5] Віктор Чжун та ін. 2021 рік. Обґрунтована адаптація для семантичного аналізу виконуваного файлу Zero-shot

[6] Xi Victoria Lin та ін. 2020 рік. Поєднання текстових і табличних даних для міждоменного семантичного аналізу тексту в SQL

[7] Тонг Го та ін. 2019 рік. Генерація Text-to-SQL на основі розширеного вмісту BERT

[8] Торстен Шолак та ін. 2021 рік. PICARD: Поступовий аналіз для обмеженого авторегресійного декодування з мовних моделей

[9] Jinyang Li та ін. 2023 рік. Graphix-T5: змішування попередньо навчених трансформаторів із шарами з підтримкою графів для розбору тексту в SQL

[10] LangChain. 2023 рік. LLM і SQL

[11] Тао Ю та ін. 2018 рік. Spider: великомасштабний набір даних із мітками людини для складного та міждоменного семантичного аналізу та завдання Text-to-SQL

[12] Ruiqi Zhong та ін. 2020 рік. Семантичне оцінювання для Text-to-SQL із дистильованими наборами тестів

[13] Кетрін Тіан та ін. 2023 рік. Просто попросіть калібрування: стратегії отримання каліброваних оцінок впевненості з мовних моделей, налаштованих за допомогою відгуків людини

[14] Брейден Хенкок та ін. 2019 рік. Вчимося з діалогу після розгортання: нагодуйся, чат-бот!

[15] Ахмед Елгохарі та ін. 2020 рік. Поговоріть зі своїм парсером: інтерактивне перетворення тексту в SQL із зворотним зв’язком природною мовою

[16] Жанна Липенкова. 2022 рік. Говори зі мною! Text2SQL спілкується з даними вашої компанії, говорити на зустрічі з обробки природної мови в Нью-Йорку.

Усі зображення належать автору.

Ця стаття була спочатку опублікована на Назустріч науці про дані та повторно опубліковано в TOPBOTS з дозволу автора.

Ми повідомимо вас, коли випустимо більше таких підсумкових статей, як ця.