Обзор литературы: Интерфейсы естественного языка для баз данных (NLIDB)

Чтобы сделать многословным то, что когда-то требовало сложных языков

Добро пожаловать в серию Обзор литературы! Мы изучаем множество исследовательских работ, связанных с общей проблемой, чтобы понять различные подходы к решению данной проблемы. Эта идея вдохновлена ​​статьями в блоге Куриана. Прочтите это!



Резюме исследования
Перенос обучения от проверки говорящего на синтез речи для нескольких говорящих Введение В этой статье мы… kurianbenoy.github.io



В этой статье я исследую проблему создания успешных Естественно-языковых интерфейсов для баз данных, читая 3 исследовательских статьи. Присоединяйтесь ко мне в этом стремлении открыть для себя новые технологии от ученых людей.

Общая проблема

Все мы знакомы с базами данных. Эти таблицы с вашими данными отсортированы для доступа - как электронные таблицы! У вас могут быть определенные вопросы, которые вы хотите задать.

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

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

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

Испытания

Для решения этой проблемы существует несколько взаимосвязанных доменов. Некоторые из них:

  • Обработка естественного языка (для ввода запроса)
  • Стиль реализации базы данных (для удобного получения результатов)
  • Дизайн компилятора (система парсеров)

НЛП само по себе имеет несколько проблем, которые оно пытается решить, например, неоднозначность в запросах, два запроса с одинаковым корневым значением, но разными предложениями и т. Д.

Базами данных могут быть SQL, NoSQL, Graph Database и т. Д. Каждая из них предлагает свои преимущества и компромиссы.

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

В каждом следующем подразделе я заново объясняю содержание статей, которые я прочитал.

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

Итак, как перейти на NL → SQL? Два варианта:

  • Семантический анализ: мы конвертируем / переводим введенное предложение в стандартный формат. Опирается на более качественные лексиконы, специфические особенности представления области (не обобщенные)
  • Нейронные сети. Для выполнения задачи преобразования используются менее жестко запрограммированные правила. Основывается на когнитивных техниках и методах самовоспроизведения. Но набор данных? Хорошие новости! Salesforce выпустила огромный набор данных по преобразованию NL → SQL (см. WikiSQL). С 80 654 рукописными экземплярами вопросов на естественном языке, SQL-запросами и SQL-таблицей, извлеченными из 24 241 HTML-таблицы из Википедии, это, безусловно, достаточно велико, чтобы научить нашу модель предсказывать подходящий запрос для нового входного предложения.

NLP позволяет системам обрабатывать широкий спектр задач, связанных с естественным языком, на всех уровнях иерархии [теги POS - машинный перевод - обработка диалогов].

А что насчет RNN? Рекурсивная нейронная сеть фиксирует семантику предложения с использованием архитектуры семантического дерева - временная сложность не менее O (n²) (n: длина текста). Это неэффективно для больших документов. Кроме того, взаимосвязи между операторами трудно представить в виде дерева.

А что насчет RNN? Рекуррентная нейронная сеть обрабатывает инструкцию пословно и сохраняет семантику ранее проанализированных предложений на среднем уровне. Это имеет временную сложность O (n) и лучше фиксирует контекстную текстовую информацию. К сожалению, здесь есть критический недостаток - это предвзятая модель, в которой более поздние слова имеют большее значение для конечного результата синтаксического анализа. Это плохо, потому что в тех случаях, когда ключевые компоненты появляются раньше, их вклад в модель будет низким.

Как получить данные из СУБД? Два пути:

  • Методы, основанные на ключевых словах: (+) Понятно; (-) обработка больших предложений затруднена.
  • Метод структурированного запроса: (+) Выразительный и мощный; (-) Не простой в использовании.

Какова конечная цель NLIDB? Поддерживать различные варианты ввода на естественном языке. Тем не менее, несмотря на развитие, трудно удовлетворить требования, несмотря на развитие NLP, потому что сложно преобразовать ввод естественного языка в запрос структуры схемы - суть проблемы.

Одно из предлагаемых решений: NaLIR (интерфейс естественного языка для работы с СУБД). Эффективный NaLIR должен выполнять работу программиста баз данных. Реальный мир:

Таким образом, необходимо выполнить следующие шаги:
1. Синтаксический анализатор естественного языка → Дерево синтаксического анализа входного оператора естественного языка.

2. Лингвистическое понимание дерева синтаксического анализа → понимание базы данных (сравнение + фиксация близости расположения в дереве синтаксического анализа к близости соответствующей базы данных)

3. Уточните у пользователя, соответствует ли наше понимание его намерениям.

Щелкните соответствующие ссылки, чтобы узнать больше о рекуррентных нейронных сетях, обработке естественного языка, WikiSQL. Теперь давайте рассмотрим предлагаемую архитектуру системы. Он состоит из 3-х модулей:

Внешний интерфейс: ввод данных пользователем на естественном языке.

Серверная часть: принимает входящие данные и обрабатывает их для создания запроса SQL. Подзадачи включают → (1) Маркировка POS (2) Обработка маркировки POS.

База данных: для получения результатов.

Давайте рассмотрим несколько модулей в рамках этой схемы:

  • Модуль генератора запросов. Добавление тегов POS выполняется после синтаксического анализа и удаления стоп-слов из предложения. Для данных с тегами POS метаданные, состоящие из базы данных, столбцов и таблиц, будут использоваться для распознавания образов. Как работает распознавание образов? Использование рекуррентной нейронной сети, которая обучается на большом количестве наборов данных, для генерации SQL-запроса из данных с тегами POS.
  • Модуль базы данных: Иерархическая структура (уровень базы данных, уровень таблицы и уровень записи. Когда данные огромны, такое расположение обеспечивает легкий и быстрый поиск данных). Первичное индексирование дополнительно сокращает время выполнения запроса.

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

Источник:

Международный журнал инженерии и передовых технологий (IJEAT)
ISSN: 2249–8958, Volume-8 Issue-4, April 2019
Оптимизация интерфейса естественного языка для реляционной базы данных
Даршил Шах, Д Вануша

Другая перспектива - переосмыслить проблему в отношении системы графовых баз данных. В случаях, когда в данных есть взаимосвязи, графовые базы данных хорошо справляются с вычислениями. Вы можете щелкнуть здесь, чтобы прочитать его сравнение с обычными реляционными СУБД.

Существующие системы ›

  1. Системы сопоставления с шаблоном. Система ищет совпадения ключевых слов в последовательности токенов (например: «Заглавная буква» в «Столица Италии»). Чат-бот ELIZA следует этой системе при моделировании разговоров с людьми. (+) Простота и легкость реализации. (-) Недостаточно для обработки сложных запросов (неоднозначности).
  2. Системы на основе синтаксиса: специальная грамматика используется для анализа запроса пользователя на естественном языке и представления его в виде дерева синтаксического анализа. Затем это дерево сопоставляется со стандартным запросом шаблона базы данных, которое остается готовым путем замены переменных. (+) Инструкции могут быть более подробными, поскольку базовая маркировка POS - если все сделано правильно - гарантирует, что мы определим необходимые ключевые слова. LUNAR является примером такого рода, который принимает вопросы из области лунной геологии. (-) Они, как правило, зависят от предметной области и требуют обширного ручного проектирования для создания точных правил сопоставления для выполнения преобразования. Поскольку мы вручную создаем эту функцию сопоставления после изучения нескольких возможных запросов, нам необходимо обобщить, чтобы избежать громоздких программных проблем. Кроме того, непреднамеренная двусмысленность может сгенерировать несколько деревьев синтаксического анализа для одного и того же предложения - следовательно, несколько запросов.
  3. Системы семантической грамматики: мы разбиваем вопрос о естественном языке на заранее определенные семантические категории и разбираем в формальные представления. Затем они выполняются в базе данных. Недостатком этого подхода является то, что он ограничивает работу в определенных схемах, и мы вручную разрабатываем грамматику. Здесь стоит отметить преимущество гибкости языковой независимости, поскольку ключевым моментом является распознавание структуры. Однако потенциальная слабость состоит в том, что для создания отображений на структурированный язык нам требуется знание сущностей в предметной области.
  4. Языки промежуточного представления: мы можем использовать семантический интерпретатор для преобразования дерева синтаксического анализа в промежуточное представление (представление логического запроса) перед отображением в окончательный формат структурированного запроса. Edite и System X являются примерами такого рода. Это промежуточное представление уравновешивает компромиссы между системами на основе синтаксиса и системами на основе семантики. Кроме того, поскольку он не зависит от базы данных, он может работать с разными доменами и языками запросов.
  5. Последовательность в модели последовательности: преобразует последовательность в одном домене в последовательность в другом домене, пропуская входную последовательность через кодировщик для получения скрытых состояний и используя декодер для создания выходной последовательности из скрытых состояний. Это заставляет всю задачу перевода выглядеть как приложение нейронного машинного перевода. OpenNMT является примером такого рода. Эта модель машинного перевода «последовательность в последовательность» с открытым исходным кодом использует внимание для перевода запросов на естественном языке в запросы SQL. Этот отказ от промежуточных представлений приводит к быстрому развертыванию для множества целевых доменов. Однако требуется большой обучающий набор естественный язык - пары запросов SQL.

Теперь, говоря о базах данных графов, представьте их как узлы (информационные точки) и ребра, соединяющие их (указывающие на отношения). Графические базы данных упрощают то, что реляционные базы данных считают сложным, например операцию JOIN. Мы используем методы сопоставления подграфов для удовлетворения требований запроса. Примеры языков запросов к графам включают Gremlin, SPARQL, Cypher и т. Д.

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

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

Однако риски двусмысленности все же преобладают. Например: Статьи, написанные Смитом и написанные Алленом и Статьи, написанные Смитом и Алленом, одинаковы, но система не может легко это понять. Иногда, если NLI неправильно спроектирован, он ведет себя как черный ящик, что затрудняет различение между «Нет результатов из базы данных» и «неправильная лингвистика - вопрос плохо отформатирован» .

Что касается мира лингвистики, необходимо рассмотреть еще несколько проблем, таких как Coreference, Anaphora, Устранение двусмысленности слов и т. Д. Чтобы разобраться в них, нам нужна обратная связь от пользователя. первая интерпретация для исправления любых ошибок.

Для этой модели была создана база данных графов. Это выглядит следующим образом:

Обзор конвейера выглядит следующим образом:

Требования к этапу извлечения информации включают:

  • Обучающие данные: для обучения модулей распознавания именованных сущностей (NER) и извлечения бинарных отношений, которые вместе работают для создания оценки достоверности взаимосвязи (и направления) между двумя узлами. Для NER нам нужно аннотировать обучающие предложения - с отмеченными узлами, атрибутами, краями. Это похоже на модули извлечения двоичных отношений.
  • Распознавание именованных объектов: для классификации представляющих интерес объектов по заранее определенным категориям (имена людей / организаций / местоположений). Мы обучаем два NER - один для графов (NER-G), чтобы пометить токены как N (узлы), E (края) или A (атрибуты), а другой - для атрибутов (NER-A) тегов токенов в соответствии с типом атрибута. .
  • Извлечение двоичных отношений: для определения отношения между двумя объектами. Каждый тип ребра требует специального обучения на модуле извлечения двоичных отношений. Входными данными для BRE являются обученная модель NER-G и пары (узлы) токенов.
  • Реорганизация вывода. Выводы NER организованы в словарь.

Для обучения NER мы используем средство распознавания сущностей из набора инструментов MIT Information Extraction (MITIE), который был построен с использованием Dlib, высокопроизводительного инструментария C ++ для машинного обучения. BOBYQA используется для автоматической настройки гиперпараметров.

Для обучения BRE мы снова используем MITIE.

Требования к этапу обработки информации включают:

  • Обработка узлов: узлы создаются для каждого NER-G. Включает идентификатор, тип, атрибуты. Это получается путем простого поиска в словаре узлов. Вложения слов играют жизненно важную роль на этом этапе.
  • Обработка атрибутов: структура атрибутов создается для каждого модуля NER-A.
  • Обработка края: обнаружение края происходит в соответствии с оценкой экстракторов двоичных отношений.

При постобработке у нас есть отзывы пользователей и очистка, чтобы уменьшить шум и ошибки. Используя точность, отзыв и оценку F1, мы можем оценить эффективность наших этапов.

Источник:

Интерфейс на естественном языке для запросов к базам данных графиков
Кристины Сан
SB, Компьютерные науки и инженерия
Массачусетский технологический институт, 2017 г.
Передано в
Департамент электротехники и информатика
при частичном выполнении требований к степени
магистра технических наук в области компьютерных наук и инженерии

МАССАЧУСЕТСКОГО ИНСТИТУТА ТЕХНОЛОГИИ

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

Изучая прошлые попытки NLIDB, мы видим, что LUNAR (содержащий химический анализ лунных горных пород) и BASEBALL (для ответов на вопросы по игре «Бейсбол») были первыми оперативными, изобретенными еще в 1960-е гг.

Лучшая система была изобретена в конце 1970-х годов → ЛЕСТНИЦА (чтобы ответить на вопросы о кораблях ВМС США). Использовалась методика семантической грамматики (включающая синтаксическую и семантическую обработку). Однако это было предметно-ориентированным языком и требовало переизобретения грамматики для новых систем.

В 1980 году CHAT-80 (реализованный с использованием Prolog) прославился своей способностью преобразовывать английский запрос в выражения пролога, которые оценивались по базе данных Prolog.

Система MASQUE / SQL (модульная система ответов на запросы) была получена из кода и функций CHAT-80, сначала преобразовав запрос NL в промежуточное логическое представление, а затем преобразовав логический запрос в SQL. К сожалению, эта система не может определить точку отказа во время неудачных выполнений.

Некоторые из первых нескольких примеров из 21 века включают систему PRECISE (2004 г.) и NALIX [интерфейс естественного языка для базы данных XML] (2006 г.).

  • PRECISE нас легко реконфигурирует благодаря достижениям в области статистических анализаторов и концепций семантической управляемости, гарантируя, что NLIDB не зависит от базы данных. (+) Может решать семантически разрешимые вопросы. (-) Есть проблемы с обработкой вложенных структур.
  • Процесс преобразования NALIX состоит из 3 этапов: (1) Генерация дерева синтаксического анализа (2) Проверка дерева синтаксического анализа (3) Трансляция дерева синтаксического анализа. Это система на основе синтаксиса, которая использует XQuery без схем в качестве языка запросов к базе данных.

В данной статье предпринята попытка решить следующие задачи:

  1. Некоторые промежуточные представления зависят от языка базы данных.
  2. Синтаксический анализ обычно зависит от предметной области.
  3. Отсутствие сокращения времени ожидания для перевода уже обработанных вопросов.

Предлагаемая система:

Универсальный интерфейс запросов на естественном языке для реляционной базы данных, основанный на подходе машинного обучения. Сначала NL-запрос анализируется синтаксически → дерево синтаксического анализа транслируется (семантическим анализатором) в промежуточный логический запрос XML (IXLQ) → наконец, IXQL переводится в DBQL Experssion и оценивается в сравнении с СУБД. Промежуточная форма IXLQ оказывается выгодной, поскольку не зависит от языка базы данных и естественного языка.

Для синтаксического анализа запроса NL используются два типа синтаксических правил:

  1. Правила Связывание нетерминальных символов (нелистовые узлы) (не зависящие от домена)
  2. Правила Связывание терминальных символов (конечных узлов) (не зависящих от домена). Его можно построить с помощью автогенератора синтаксических правил (AGSR).

Модуль определений запросов на естественном языке (MNLQD) используется для представления каждого класса логической интерпретации многих запросов на естественном языке. Это помогает свести к минимуму время ожидания перевода уже заданных пользователями вопросов.

Компоненты архитектуры:

  • Лингвистические компоненты (морфологический [M], синтаксический [Sy] и семантический [Sm] анализ): [M] сегментируйте текст на отдельные единицы (токены) и определяйте характеристики. Применяемые функции включают анализ токенов (создание примитивных единиц), проверку орфографии (сравнение с содержимым словаря), уменьшение неоднозначности (замена нескольких слов каноническими внутренними словами), тегирование (грамматическая категория определение) и Morpheme (чтобы найти морфемы). [Sy] Чтобы увидеть, как слова соотносятся друг с другом, применяя набор правил, составляющих формальную грамматику. Мы используем ECFG для нетерминалов и ARG для генерации терминальных правил. Для последнего используется подход машинного обучения. Цель ASRG - проверить, все ли синтаксические правила, необходимые для синтаксического анализа пользовательского запроса, существуют в базе знаний системы. Если недоступен, он обнаруживает необходимые синтаксические правила, которые создаются и добавляются в базу знаний. В результате мы создаем дерево разбора. [Sm] Для присвоения логического значения дереву синтаксического анализа, созданному с помощью синтаксического анализа. Мы применяем семантические правила для преобразования дерева разбора в логический запрос. Между семантическими и синтаксическими правилами существует взаимно однозначная связь.

  • Компонент базы данных: (Создание DBQ) Преобразование IXLQ в SQL в 4 этапа: (1) определение имен атрибутов для предложения SELECT, (2) создание предложения FROM путем выбора частей логический запрос (3) Построить предложение WHERE (4) Построить ORDER BY. Если имена не распознаются, мы извлекаем соответствующее корневое слово из словаря, содержащего синонимы (стиль тезауруса). (Выполнение DBQ) Запуск в СУБД для получения результатов в табличной форме.

Источник:

Модель универсального интерфейса естественного языка
для запросов к базе данных
Ханане Байс, Мустафа Махкур и Лахсен Кутти 3
Лаборатория информационных систем и зрения, факультет компьютерных наук, факультет естественных наук, Университет Ибн Зохра ,
Агадир, Марокко

Я хотел прочитать больше статей и обобщить это, но, учитывая ограниченность времени, это было лучшее, что я мог сделать. Надеюсь, вам понравилось это сообщение и вы получили от него огромную пользу. Прочтите газеты, чтобы узнать больше. До свидания!