Машинное обучение

Как написание SQL может стать намного проще с NLQ

Запросы на естественном языке изменят вашу работу с данными к лучшему

Какой самый интуитивный, эффективный и наименее утомительный способ задать вопрос? Это использование самых простых слов, возможных на вашем родном языке. Современные поисковые системы, такие как Google, сделали поиск информации в Интернете с помощью простых предложений обычным явлением. Это помогло создать наше современное общество и улучшить доступ к информации во всем мире; трудно переоценить, насколько революционным на самом деле было появление поисковой системы. Однако поиск информации в Интернете не стал по-настоящему демократичным и популярным до тех пор, пока мы не смогли задавать вопросы в Интернете, используя естественный язык, так же, как мы разговаривали бы с другим человеком.

Такая же возможность поиска информации с использованием естественного языка вскоре может стать реальностью для специалистов по данным. И нет, я не говорю о необходимости искать в Google миллион раз в день фрагменты кода, которые нужно копировать и вставлять. А скорее ввести предложение для запроса к базе данных и получить ответ в виде таблицы в паре с SQL-запросом, который использовался для ее создания.

Весь этот процесс возможен благодаря обработке естественного языка (NLP). И, несмотря на все пресс-релизы о новейшей и лучшей языковой модели, ведущей к AGI, использование NLP для управления запросами на естественном языке (NLQ) еще не решенная проблема, но я считаю, что эта возможность может быть ближе, чем мы думаем.

Краткая история запросов на естественном языке (NLQ)

Я хочу кратко рассказать о том, как мы сюда попали, потому что это имеет отношение к тому, о чем я говорю, а именно о том, что Интернет не стал действительно «доступным» для масс, пока задавать вопрос не стало так же интуитивно, как говорить. Я тоже думаю, что история интересная.

В 1970-х годах Интернет находился на ранней стадии развития с ARPANet, где вам приходилось просматривать каталоги файлов FTP¹. В конечном итоге это привело к появлению первой поисковой системы, известной как Арчи, выпущенная в 1990 году². Archie был первым веб-индексом, и поисковый запрос выполнялся путем сопоставления текста одним из 4 способов³: точное совпадение, регулярное выражение, подпункт и подрегистр.

1990-е годы привели к гонке поисковых систем: ранние поисковые системы могли найти веб-сайт, только если вы знали точное название веб-сайта⁴. Постепенно поисковые системы становились все более похожими на повседневную речь, и именно тогда Интернет действительно стал демократизированным и доступным для общественности. Первая успешная поисковая система, сделавшая это, стала настолько популярной, что сочетание высокого интернет-трафика и недостаточного количества серверов сделало сайт настолько медленным, что его практически невозможно было использовать⁴.

Остальное уже история. AltaVista и Ask Jeeves (позже Ask.com)⁴ выполняли поиск на естественном языке лучше, чем кто-либо другой, пока Google не представил свой алгоритм PageRank, который выдавал релевантные результаты на естественном языке, и полностью разгромил конкурентов.

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

Что могут сделать запросы на естественном языке для SQL?

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

Язык SQL был создан примерно в то же время, когда зарождался Интернет, то есть в 70-х годах. До того, как был создан SQL, ученый-компьютерщик, создавший модель реляционной базы данных⁵ предложил запросы, в которых использовалась математическая запись, которая выглядела следующим образом:

Создатели SQL, Дональд Чемберлин и Рэй Бойс, так сказали о создании языка: «Мы считали возможным разработать реляционный язык, который был бы более доступным для пользователей без формального обучения математике или компьютерному программированию».

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

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

Запросы к базам данных на естественном языке уже здесь

Вы заметили, что для компаний, занимающихся инструментальными панелями визуализации, стало стандартом использовать возможности искусственного интеллекта для запросов на естественном языке? Такие компании, как Tableau, Power BI и Pyramid Analytics (и это лишь некоторые из них), добавляют запросы на естественном языке в свои решения для информационных панелей. У Tableau есть AskData, который был выпущен в феврале 2019 года⁹, а позже в том же году Power BI добавила запросы на естественном языке в свой продукт вопросов и ответов¹⁰. В Pyramid Analytics недавно была статья¹¹, в которой упоминалось: Подход без кода [Pyramid] позволяет нетехническим пользователям в компании находить ответы на сложные бизнес-вопросы. Это включает в себя поддержку запросов на естественном языке и анализ на основе ИИ, который «работает непосредственно с источником данных¹¹. Вы можете перейти по этой ссылке¹², чтобы посмотреть видео об их возможностях запросов на естественном языке в действии.

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

Доступ к базам данных для неспециалистов

Tableau, Power BI и Pyramid Analytics — это примеры запросов на естественном языке, которые используются для запросов к одной таблице. Это интересно и определенно полезно, но я думаю, что технология может предложить гораздо больше в ближайшем будущем. Что, на мой взгляд, может быть по-настоящему революционным, так это использование естественного языка не только для запроса панели мониторинга, но и в первую очередь для разработки запросов для создания этой панели.

Преобразование текста в SQL, более формально известное как интерфейс на естественном языке для баз данных (NLIB)¹³, представляет собой увлекательную проблему, которая еще не завершена, прежде чем ее можно будет считать решенной. Однако в этой области уже достигнута большая веха. В 2019 году ИИ смог создать запрос к одной таблице на уровне выше человеческого²⁰. Есть даже сайты, такие как AI2SQL, где можно попробовать на себе¹⁴.

Несмотря на то, насколько впечатляет то, что ИИ может создавать запросы для одной таблицы, это, вероятно, не сэкономит специалистам по данным много времени. Что действительно сложно для специалиста по данным, так это когда ему приходится писать сотни или даже тысячи строк кода SQL для создания информационной панели или отчета. И мало того, что нужно написать много кода, каждый из этих запросов также должен:

  • избегать дубликатов
  • удалить нули
  • очистить данные
  • преобразовать данные
  • избежать ошибок при преобразовании данных
  • и т. д…

Я хочу сказать, что есть над чем подумать! Что этот процесс действительно эмулирует, так это перевод бизнес-логики в код.

Является ли преобразование текста в SQL просто несбыточной мечтой?

Мысль о Text-to-SQL может показаться размышлениями аналитика, который провел слишком много часов перед экраном своего компьютера, но независимо от того, являетесь ли вы этим аналитиком или нет, позвольте себе представить следующий сценарий на просто момент.

Представьте себе, что эксперт в предметной области может написать бизнес-логику в документе вместе с примером итоговой таблицы, которую он передает в ИИ. Затем этот ИИ переводил этот набор указаний в набор SQL-запросов для получения желаемого результата. На протяжении всего этого процесса будут выполняться проверки первичного ключа и избегать дублирования. Роль специалиста по данным сместится с создания кода в течение нескольких месяцев на аудит вывода кода ИИ, что может занять несколько недель. Если бы это было возможно, можно было бы получить огромный прирост эффективности.

Это может звучать как несбыточная мечта, но я верю, что именно в этом направлении и что однажды это станет возможным. Аэрин Ким работала исследователем в команде Microsoft, разрабатывающей ИИ для преобразования текста в SQL. Вот что она должна была сказать об этом,

Лично я нахожу перевод естественного языка в исполняемый SQL интересной задачей для работы, и я считаю этот проект чем-то большим, чем выстрелом в луну. Text-to-SQL — это проект, который потенциально может быть решен, и как только он будет решен, он станет широко применимым, учитывая, насколько широко реляционные базы данных используются в каждом секторе¹⁵.

Разве Github Copilot уже не делает этого?

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

Github Copilot предложит код на основе ваших строк документации, имен функций и другого текста в вашем коде. ИИ Github Copilot (названный Codex) был обучен с использованием кода на Github. Следовательно, код, который он предлагает, по сути является шаблонами, основанными на том, что другие программисты создали на веб-сайте Github¹⁶. Это отличается от Text-to-SQL, поскольку Text-to-SQL пытается брать предложения и вместо того, чтобы предлагать шаблоны, переводит это предложение в код. Термин для перевода текста в код называется семантическим анализом.

Самое большое сходство между ними заключается в том, что современные модели (SOTA) были созданы для обоих приложений с использованием языковых моделей. Codex построен на основе GPT-3, а текущий семантический парсер SOTA основан на языковой модели Google T5.

Каковы текущие возможности Text-to-SQL?

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

Чтобы понять текущее состояние Text-to-SQL, я хочу представить три разных набора данных, которые в настоящее время используются для бенчмаркинга: WikiSQL, Spider и SPArC.

1. ВикиSQL

База данных WikiSQL¹⁷ была выпущена в 2017 году и содержит 80K рук¹⁸ аннотированных вопросов и SQL-запросов. Набор данных был сгенерирован из 24 тыс. таблиц Википедии¹⁸. Чтобы стимулировать исследования в этой области, Salesforce собрала данные и сделала их доступными. Они также создали базовую модель, основанную на модели RNN Seq2Seq, которая обычно используется для трансляции. Модель смогла обеспечить правильный вывод при вводе текстового вопроса в 59 % случаев (точность выполнения) и смогла получить правильный формат SQL в 48 % времени (логическая точность формы).¹⁷

В сообщении блога под названием Как общаться с вашей базой данных команда Salesforce объясняет, как их базовая модель Seq2Seq (названная Seq2SQL) способна преобразовывать вводимый текст в SQL-запросы. Команда Salesforce сосредоточилась на создании моделей SQL для трех вещей: агрегации, операторов select и предложения where.¹⁹

Это отличное начало, но с тех пор был достигнут большой прогресс. Сверхчеловеческая производительность была достигнута с набором данных WikiSQL всего через 2 года после его выпуска²⁰. В 2019 году статья, выпущенная Hwang et. др. сказал,

Мы представляем SQLova, первую модель преобразования естественного языка в SQL (NL2SQL), обеспечивающую человеческую производительность в наборе данных WikiSQL. Мы пересматриваем и обсуждаем различные популярные методы в литературе по NL2SQL, в полной мере используем BERT… Мы особенно показываем, что производительность нашей модели близка к верхней границе в WikiSQL, где мы наблюдаем, что большая часть ошибок оценки связана с неправильными аннотациями, и наша модель уже превосходит человеческие возможности на 1,3% по точности выполнения.²⁰

Их модель достигла 89% точности исполнения и 84% точности логической формы. С тех пор самая высокая модель в таблице лидеров улучшила производительность еще на 4% по обоим показателям точности.¹⁷

2. Паук

Вскоре исследователи поняли, что для продвижения области NLQ необходим еще один набор данных, поэтому в сентябре 2018 года исследователи создали набор данных Паук²¹. Перефразируя аннотацию к статье Spider²², Spider отличается от WikiSQL тем, что он обучается на базе данных, отличной от тестовых данных, и вводит соединения как часть требования для поиска ответов на вопросы. Это ключевые отличия от набора данных WikiSQL, и они на шаг ближе к тому, как специалисты по данным ежедневно используют SQL.

Вот несколько примеров типов запросов, которые Паук требует от моделей²¹:

SELECT name ,  capacity FROM stadium ORDER BY average DESC LIMIT 1  concert_singer
SELECT count(*) FROM concert WHERE YEAR  =  2014 OR YEAR  =  2015   concert_singer
SELECT T2.name ,  count(*) FROM concert AS T1 JOIN stadium AS T2 ON T1.stadium_id  =  T2.stadium_id GROUP BY T1.stadium_id  concert_singer

Аннотированный вопрос и пример пары SQL-запросов выглядят следующим образом:

Вопрос

Как называется и вместимость стадиона с наибольшим количеством концертов после 2013 года?

SQL-запрос

Наивысшая точность логической формы в наборе данных Spider в настоящее время составляет 75%»²³ (они не используют точность выполнения, поскольку не предоставляются значения для прогнозирования). Это огромное улучшение по сравнению с исходной базовой моделью, точность которой составляла всего 12%. Однако, чтобы быть полезной, точность должна быть улучшена, чтобы, по крайней мере, соответствовать тому, чего могут достичь люди.

3. СПАРК

SParC — это аббревиатура, расшифровывающаяся как Сэмантический Парсинг в Cконтексте»²⁴. Набор данных был построен поверх набора данных Spider, и его цель — сосредоточиться на контекстных запросах. Это означает, что ваша модель может учиться на множестве вопросов, заданных последовательно.

Повышенная сложность этой задачи по сравнению с набором данных Spider очевидна в результатах таблицы лидеров; текущая модель SOTA для этого набора данных составляет всего 45%²⁴. Для измерения точности используется та же структура, что и для набора данных Spider, который разбит на 1 0 различных компонентов²¹.

Запросы оцениваются по точности логической формы, и, несмотря на возможность генерировать значения, точность выполнения не обеспечивается.

Как выглядит будущее запросов на естественном языке?

Все наборы данных, которые я упоминал до сих пор, по-прежнему страдают одним ограничением: они зависят от контекста, то есть они сосредоточены на «одной задаче, домене или наборе данных»²⁸. Например, эта статья в основном посвящена переводу естественного языка в SQL с использованием реляционных баз данных. Но если уровень владения текстом в SQL для реляционных баз данных будет достигнут на уровне человека, те же самые модели могут оказаться не очень полезными при применении к данным в форме графов знаний или любой другой форме, кроме реляционной базы данных. При этом большая часть данных хранится в реляционных базах данных, и это все равно будет огромным достижением.

Чтобы решить проблему контекстно-зависимых моделей, та же команда, которая помогала разрабатывать набор данных Spider, создала унифицированную структуру структурированного заземления знаний (Unified SKG) для тестирования моделей. Их страница проекта определяет заземление структурированных знаний как «[заземление] пользовательских запросов в структурированных знаниях [производство] различных выходных данных, включая компьютерные программы (например, SQL и SPARQL), значения ячеек и ответы на естественном языке».²⁹

Структурированное обоснование знаний — это метаподход к проблеме с «взглядом на 10 000 футов» и расширенный набор семантического анализа и других запросов на извлечение знаний. На приведенной ниже диаграмме показаны примеры типов текста, к которым эта структура может обращаться с помощью NLP, выходящего за рамки семантического анализа:

Их последняя модель была выпущена в марте 2022 года и основана на трансформаторе T5 от Google. Их новый метод использует текст как для ввода, так и для вывода, чтобы обобщать задачи, домены и наборы данных. Команда считает, что многозадачное обучение — это способ продвинуться вперед. На своей странице в Github они сказали: «UnifiedSKG — это сложная испытательная площадка для обучения с нулевым и малым количеством выстрелов, с которым борются T0, GPT-3 и Codex».²⁸

Заключение

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

Спасибо за прочтение!



Присоединяйтесь к Medium и поддержите меня по моей реферальной ссылке
Как участник Medium, часть вашего членского взноса идет авторам, которых вы читаете, и вы получаете полный доступ ко всем историям… medium.com



Дополнительная рекомендуемая литература/ресурсы:

  • Если вы заинтересованы в кодировании собственной модели преобразования текста в SQL, ознакомьтесь с этой статьей Towards Data Science, которая проведет вас через шаги: Естественный язык в SQL с нуля с помощью TensorFlow.
  • У одного из исследователей, создавших набор данных Spider, есть несколько замечательных ссылок внизу его статьи на Medium, посвященной запросам на естественном языке: Spider: еще один шаг к интерфейсам на естественном языке для баз данных.
  • Исследователи работали над улучшением семантического синтаксического анализа и преобразования текста в SQL до выпуска набора данных WikiSQL в 2017 году. Одним из первых наборов данных был ATIS, выпущенный в 1990²⁶. Другой важной ранней работой в этой области исследований была Geoquery, опубликованная в 1996²⁷.

Ссылки

  1. Дж. Лейден, ФТП отмечает рубиновый юбилей (2011), The Register
  2. Д. Шедден, Сегодня в истории СМИ: первая поисковая система в Интернете выпущена в 1990 году (2014), Пойнтер.
  3. Охота за данными на ftp-линии с Арчи (1992), Частная технология для практиков
  4. С. Воган-Никол, До Google: история поиска (2017), Hewlett Packard Enterprise
  5. Эдгар Ф. Кодд, Википедия
  6. Д. Чемберлин, Ранняя история SQL (2012), Annals of the History of Computing
  7. А. Кулкарни, Почему SQL побеждает NoSQL и что это означает для будущего данных (2017), Medium
  8. Тенденции переполнения стека, Переполнение стека
  9. Tableau выпускает Ask Data, новый и интуитивно понятный способ анализа данных с помощью естественного языка (2019), Tableau
  10. С. Н. Картикешвар, Вопросы и ответы о ваших данных в Power BI (2019 г.), visualbig
  11. П. Соерс, Платформа для принятия решений Pyramid Analytics привлекает 120 миллионов долларов (2022 г.), VentureBeat
  12. Запрос на естественном языке, пирамида
  13. Э. Пангу, Естественный язык в SQL с нуля с помощью Tensorflow (2022), Medium
  14. АИ2SQL
  15. А. Ким, [Text-to-SQL] Обучение запросам таблиц на естественном языке (2020), Medium
  16. Дж. Ховард, GitHub Copilot — благословение или проклятие?, fast.ai
  17. Виктор Чжун, Каймин Сюн и Ричард Сочер, WikiSQL, Github
  18. Виктор Чжун, Каймин Сюн и Ричард Сочер, Seq2SQL: создание структурированных запросов на естественном языке с использованием обучения с подкреплением. (2017), архив
  19. В. Чжун, Как общаться с базой данных, Salesforce
  20. В. Хван и др. и др., Всестороннее исследование WikiSQL с контекстуализацией слова с учетом таблиц (2019), arxiv
  21. Тао Ю, Паук, Github
  22. Тао Ю, и др. и др., Паук: крупномасштабный набор данных, помеченный человеком, для сложного и междоменного семантического анализа и задачи преобразования текста в SQL (2018), arxiv
  23. Тао Ю, и др. и др., Паук 1.0: Yale Semantic Parsing and Text-to-SQL Challenge, Github
  24. Тао Ю, и др. и др., SParC 1.0: Yale & Salesforce Semantic Parsing and Text-to-SQL in Context Challenge, Github
  25. Тао Ю, и др. и др., SParC: междоменный семантический анализ в контексте, Github
  26. П. Дж. Прайс, Оценка систем разговорного языка: домен ATIS (1990), aclanthology.org
  27. Дж. М. Зелле и Р. Дж. Муни, Обучение разбору запросов к базе данных с использованием индуктивного логического программирования (1996), aaai.org
  28. Тао Ю, и др. al, UnifiedSKG: объединение и многозадачность структурированных знаний с помощью языковых моделей преобразования текста в текст, Github
  29. Тао Ю, и др. al, Введение в структурированное обоснование знаний, Github
  30. Тао Ю, Паук: еще один шаг к естественно-языковым интерфейсам к базам данных (2018), Medium