Представете си свят, в който можем да говорим с нашите данни, използвайки нормален човешки език. Text-to-SQL е проблем, който си струва да бъде решен и Open AI ни помага да надскочим този проблем.

Във филма „Endgame“ Тони Старк (Робърт Дауни Джуниър) използва изкуствен интелект, за да помогне за разрешаването на проблема с пътуването във времето, докато поглежда към проекция на „лента на мобиус“. Той прави това с помощта на AI (F.R.I.D.A.Y.), който е създал. ПЕТЪК може да изчисли точното местоположение на камъните на безкрайността в миналото, настоящето и бъдещето. AI помогна за решаването на проблема с пътуването във времето и позволи на Отмъстителите да пътуват назад във времето, за да извлекат камъните и да победят Танос. Този филм вдъхновява използването на AI за решаване на сложни и на пръв поглед невъзможни проблеми.

Сега, нека смекчим това до много практично ниво и на ниво, което е подходящо за нашето време. Можем ли да задаваме въпроси, свързани с данни на AI, и да извличаме данните вместо нас?

През 70-те години IBM изобретява SQL (Structured Query Language). Създаден е за използване с тяхната система за управление на релационни бази данни, която те пуснаха през 80-те години на миналия век, и е специално създаден за бизнес потребители, които биха искали да имат достъп до данни за целите на отговаряне на въпроси, свързани с бизнеса. От техническа гледна точка SQL вече е много прост, но все пак трябва да научите основите му, за да използвате напълно силата на данните, които се намират в различни бази данни.

През годините популярността на SQL намаля с въвеждането на технологии за база данни NoSQL (напр. MongoDB). За обикновения бизнес потребител обаче SQL все още е най-гъвкавият начин за достъп до данни и извършване на анализ на данни от високо ниво. Въпреки че е прост, SQL изисква стръмна крива на обучение, за да стане напълно използваем за бизнес потребител. Проблемът, който бихме искали да разрешим, е дали можем да позволим на бизнес потребителите да задават въпроси, свързани с данни, без да се налага да пишат сложен SQL код.

През 2022 г. има експоненциален ръст на AI технологиите и много скоро може да сме в състояние да използваме AI подобно на това, което Тони Старк направи във филма. Въведете OpenAI, тази технология вече ни позволява да задаваме въпроси като „Напишете ми SQL заявка, за да преброя всички поръчки от Финландия?“ След това ще напише следното:

Възможно ли е да използваме тази технология, за да разрешим проблемите на бизнес потребителите, които не знаят как да пишат SQL заявки, но имат много въпроси, които искат да зададат на нашите данни?

Това не е опит да се реши този проблем, а по-скоро опит да се вдъхнови всеки, който го чете, да спести любопитството и да изследва. В продължение на много години има много компании, които са се опитвали да решат проблемите на бизнес потребителите и са измислили базирани на свободен текст решения за търсене на данни. Как работи е, че потребителят има свободно текстово поле, където той/тя/той/тя пише заявка за данни и излизат данни — всичко това се прави без писане на един SQL код.

За да ви преведа през това, ви предлагам да се „регистрирате“, за да отворите средата на пясъчника на AI. Методът, който ще използваме, е функцията SQL translate. Ето основните неща, които трябва да решим, за да направим това жизнеспособно.

Проблем за разрешаване не. 1: Уведомете изкуствения интелект за източника на данни, от който искате да прави заявки за данните.

Както можете да видите в примера по-горе, помолих го да преброи броя на поръчките и той реши, че таблица, наречена ***поръчки***, ще бъде най-логичната таблица за тази заявка.

Сега във вашия контекст, ако имате таблица, наречена продукти, транзакции, фактури, доставчици и т.н... всичко, което трябва да направите, е да създадете речник или да използвате функция за заместване, за да дешифрирате написаната от човека заявка, която сочи към конкретното име на таблицата във вашата база данни.

Ето един пример:

Проблем за разрешаване не. 2: Уведомете AI за колоните, които човекът иска да запитва.

В този пример „Покажете ми сумата от продажби за 2022 г.“, AI знаеше, че „продажбите“ са колона:

Отново, както в примера в стъпка 1, можете да създадете речник или да използвате функцията за замяна, която превежда точното име на колона, която трябва да бъде заявена.

Проблем за разрешаване не. 3: Решете как изкуственият интелект би извършил филтриране на данни.

Все още използвайки горния пример, AI филтрира order_date между 2022–01–01 и 2022–12–31, AI знаеше, че order_date е колона за дата, дори ако не сме го споменали, за да филтрира точно от тази колона. Сложната част тук е как са представени датите, например, той избра да пише във формат ГГГГ-ММ-ДД, така че можете да си представите, че това е малко по-различно в различните региони на света. В Европа например това би било във формат ДД-ММ-ГГГГ.

Проблем за разрешаване не. 4: Решете как AI ще групира правилно данни.

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

Проблем за разрешаване не. 5: Как да обединим данни?

Как AI би могъл да разбере, че за да получи най-добрия продавач/продавачка по брой поръчки, той трябва да се присъедини към таблиците: поръчка и продавачи? В повечето фирмени бази данни повечето таблици са нормализирани по теми.

Е, това е малко сложно, но знаете ли какво? Научих, че AI предполага, че трябва да имате колоната за продавач в таблицата с поръчки, невероятно, нали? Така че предполага, че не са необходими свързвания на таблици.

В известен смисъл това има смисъл за опростяване, тъй като не трябва да се правят обединения и нормален бизнес потребител няма да знае, че поръчките и данните за търговците са в две отделни таблици. За съжаление в класическите принципи за управление на бази данни обикновено разделяте таблици с факти и размери. Но хей, затова ли са измислили възгледи? Оставете AI да използва DB изгледи или подбрани таблици, за да активира AI.

Проблем за разрешаване не. 6: Съберете данни от вашите бизнес потребители, как те обикновено задават бизнес въпроси относно данните и как това беше решено за тях?

Тук можете да се обърнете към билетите (напр. JIRA, Github), които са написани към екипите за инженеринг на данни или анализи и след това съответната заявка, произведена за създаване на резултатите за този бизнес потребител. След това вероятно можете да използвате и AI подходи, за да обучите модел, който може да анализира написани от хора въпроси в SQL заявки - това е малко сложно, но както беше казано, ако нямате подбрани набори от данни, това ще означава множество SQL съединявания и сложна логика за създават фундаментален въпрос.

Проблем за разрешаване не. 7: Използвайте NLP за решаване на проблеми с AI.

Спомнете си, че в задачи 1 и 2 използвахме функция за замяна. Какво ще стане, ако използваме подхода за обработка на естествен език (NLP) и изградим модел, който може да замени всяка естествена дума и да я преведе в технически текст, например, можем да създадем модел, който може да класифицира дума и да идентифицира кой технически термин трябва връзка към:

Ключът е да съберете възможно най-много данни от вашите потребители на данни и да разберете какви типове естествени думи ще използват и какви данни очакват да бъдат поискани. Събирането на думи и след това етикетирането им е досадно и също е предразположено към проблеми с подобни имена на таблици/имена на колони. Но това е нещо, което си заслужава да се проучи.

Проблем за разрешаване не. 8: С кого можем да обединим сили, за да разрешим проблема Text-to-SQL.

  1. Data QnA (Google) — Това се разработва от Google и сега е в алфа версия, документацията може да бъде намерена чрез връзка: https://cloud.google.com/blog/products/data-analytics/introducing-data-qna
  2. QueryGenie — Shivaprasad Bhat решава проблема с помощта на GPT3. Можете да проверите тази работа чрез QueryGenie: https://sqlgenie-co.web.app/
  3. Alphaa.ai — Saurabh Moddy успя да разреши обединяването на множество таблици и деконструкцията на ниво стойност на колона. Вижте неговата демонстрация: https://youtu.be/65Z26y8pzoo
  4. NLIDB — Интерфейс на естествен език към база данни (NLIDB) е система, която позволява на потребителя достъп до информация, съхранена в база данни, чрез въвеждане на заявки, изразени на някакъв естествен език (напр. английски) или подмножество от естествен език. Ако искате да разберете повече подробности те са публикували ръководство: https://arxiv.org/pdf/cmp-lg/9503016.pdf
  5. Lolo Code — Създаване на SQL Whatsapp чат бот с помощта на OpenAI: https://www.youtube.com/watch?v=vm2oJmU_buI

Резюме

Проблемът с text-to-sql е проблем, който все още няма идеално решение или ако е бил решен, известните технологии не са известни или са все още в ранна детска възраст. С пускането на Open AI този проблем вече може да бъде решен много по-далеч, докато търговско жизнеспособно решение стане масово. Благодаря, че прочетохте и се надявам това да ви вдъхнови да разрешите този проблем.