Создание информационной границы с диалоговым доступом к данным

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

Читают: 0

разговорный ИИ для анализа данных

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

По мере того, как наш мир становится все более глобальным и динамичным, предприятия все больше зависят от данных для принятия обоснованных, объективных и своевременных решений. Однако на данный момент раскрытие полного потенциала организационных данных часто является привилегией нескольких специалистов по данным и аналитиков. Большинство сотрудников не владеют традиционным набором инструментов для обработки данных (SQL, Python, R и т. д.). Чтобы получить доступ к нужным данным, они проходят через дополнительный уровень, где аналитики или команды бизнес-аналитики «переводят» формулировку бизнес-вопросов на язык данных. Потенциал трения и неэффективности на этом пути высок — например, данные могут быть доставлены с задержками или даже тогда, когда вопрос уже устарел. Информация может быть потеряна по пути, если требования не будут точно переведены в аналитические запросы. Кроме того, для создания высококачественной информации требуется итеративный подход, который не рекомендуется с каждым дополнительным шагом в цикле. С другой стороны, эти специальные взаимодействия создают проблемы для дорогостоящих специалистов по данным и отвлекают их от более стратегической работы с данными, как описано в этих «признаниях» специалиста по данным:

Когда я работал в Square, и команда была меньше, у нас была ужасная ротация «аналитиков по вызову». Он строго чередовался еженедельно, и если это была ваша очередь, вы знали, что на этой неделе вы проделаете очень мало «настоящей» работы и потратите большую часть своего времени на ответы на специальные вопросы от различных групп по продуктам и операциям в отделе. компания (мы называли это SQL-манипулированием). В команде аналитиков существовала беспощадная конкуренция за должности менеджеров, и я думаю, что это было полностью результатом того, что менеджеры были освобождены от этой ротации — никакая награда за статус не могла соперничать с пряником в виде отказа от работы по вызову.[1]

В самом деле, не было бы здорово поговорить напрямую с вашими данными вместо того, чтобы проходить через несколько раундов взаимодействия с вашим персоналом по данным? Это видение реализовано в диалоговых интерфейсах, которые позволяют людям взаимодействовать с данными с помощью языка, нашего наиболее интуитивно понятного и универсального канала общения. После разбора вопроса алгоритм кодирует его в структурированную логическую форму на выбранном языке запросов, таком как SQL. Таким образом, пользователи, не являющиеся техническими специалистами, могут общаться со своими данными и быстро получать конкретную, актуальную и своевременную информацию, не прибегая к помощи группы BI. В этой статье мы рассмотрим различные аспекты реализации Text2SQL и сосредоточимся на современных подходах с использованием больших языковых моделей (LLM), которые на данный момент обеспечивают наилучшую производительность (см. [2]; обзор альтернативных подходов). помимо LLM, читатели отсылаются к [3]). Статья структурирована в соответствии со следующей «ментальной моделью» основных элементов, которые следует учитывать при планировании и создании функции ИИ:

разговорный ИИ для анализа данных — Рисунок 2: Ментальная модель функции ИИ

Давайте начнем с конечной цели и подведем итоги — почему вы должны встроить функцию Text2SQL в свой продукт для данных или аналитики. Три основных преимущества:

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

Теперь, каковы сценарии продукта, в которых вы могли бы рассмотреть Text2SQL? Три основных параметра:

Вы предлагаете масштабируемые данные/продукт BI и хотят предоставить большему количеству пользователей доступ к своим данным нетехническим способом, тем самым увеличивая как использование, так и базу пользователей. Например, у ServiceNow есть интегрированные запросы данных в более крупное диалоговое предложениеи Атлан недавно объявила об исследовании данных на естественном языке.
Вы хотите создать что-то в области данных/ИИ, чтобы демократизировать доступ к данным в компаниях, и в этом случае вы могли бы потенциально рассмотреть MVP с Text2SQL в основе. Провайдеры любят AI2SQL и Text2sql.ai уже делают вход в это пространство.
Вы работаете над настраиваемая BI-система и хотят максимизировать и демократизировать его использование в отдельной компании.

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

Большой и растущий, чтобы Text2SQL мог раскрывать свою ценность с течением времени по мере использования все большего количества данных.
Высокое качество, чтобы алгоритму Text2SQL не приходилось иметь дело с чрезмерным шумом (несоответствиями, пустыми значениями и т. д.) в данных. Как правило, данные, автоматически генерируемые приложениями, имеют более высокое качество и согласованность, чем данные, созданные и поддерживаемые людьми.
Семантически зрелый в отличие от необработанных, чтобы люди могли запрашивать данные на основе основных концепций, отношений и показателей, которые существуют в их ментальной модели. Обратите внимание, что семантическая зрелость может быть достигнута за счет дополнительного шага преобразования, который приводит необработанные данные в концептуальную структуру (см. раздел «Наполнение подсказки информацией из базы данных»).

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

Если этот подробный образовательный контент будет вам полезен, вы можете подпишитесь на нашу рассылку исследований ИИ быть предупрежденным, когда мы выпустим новый материал.

1. Данные

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

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

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

Question"Укажите имя и количество подписчиков для каждого пользователя».

Запрос SQL:

выберите имя, подписчиков из user_profiles

В пространстве обучающих данных сопоставление между вопросами и SQL-запросами осуществляется по принципу «многие ко многим»:

SQL-запрос может быть сопоставлен с множеством различных вопросов на естественном языке; например, приведенная выше семантика запроса может быть выражена следующим образом: «покажи мне имена и количество подписчиков на пользователя","сколько подписчиков у каждого пользователя?" так далее.
Синтаксис SQL очень универсален, и почти каждый вопрос может быть представлен в SQL несколькими способами. Самый простой пример — разный порядок предложений WHERE. С более продвинутой точки зрения, каждый, кто занимался оптимизацией SQL-запросов, знает, что многие пути ведут к одному и тому же результату, а семантически эквивалентные запросы могут иметь совершенно разный синтаксис.

Ручной сбор обучающих данных для Text2SQL особенно утомителен. Это требует не только мастерства SQL со стороны аннотатора, но и больше времени на пример, чем более общие лингвистические задачи, такие как анализ тональности и классификация текста. Чтобы обеспечить достаточное количество обучающих примеров, можно использовать увеличение данных — например, LLM можно использовать для создания парафраз для одного и того же вопроса. [3] содержит более полный обзор методов расширения данных Text2SQL.

1.2 Дополнение подсказки информацией из базы данных

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

Столбцы и таблицы базы данных
Отношения между таблицами (внешние ключи)
Содержимое базы данных

Есть два варианта включения знаний о базе данных: с одной стороны, обучающие данные могут быть ограничены примерами, написанными для конкретной базы данных, и в этом случае схема изучается непосредственно из SQL-запроса и его сопоставления с вопросом. Этот параметр для одной базы данных позволяет оптимизировать алгоритм для отдельной базы данных и/или компании. Однако это убивает любые амбиции в отношении масштабируемости, поскольку модель необходимо точно настраивать для каждого отдельного клиента или базы данных. В качестве альтернативы, в настройке с несколькими базами данных схема базы данных может быть предоставлена как часть входных данных, что позволяет алгоритму «обобщать» новые, невидимые схемы базы данных. Хотя вам абсолютно необходимо использовать этот подход, если вы хотите использовать Text2SQL во многих разных базах данных, имейте в виду, что он требует значительных оперативных инженерных усилий. Для любой разумной бизнес-базы данных включение полной информации в подсказку будет крайне неэффективным и, скорее всего, невозможным из-за ограничений длины подсказки. Таким образом, функция, отвечающая за формулирование подсказок, должна быть достаточно умной, чтобы выбирать подмножество информации из базы данных, которая является наиболее «полезной» для данного вопроса, и делать это для потенциально невидимых баз данных.

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

2. Алгоритм

Text2SQL — это тип семантический разбор — отображение текстов в логические представления. Таким образом, алгоритм должен «учить» не только естественный язык, но и целевое представление — в нашем случае SQL. В частности, он должен приобрести и следующие биты знаний:

Синтаксис и семантика SQL
Структура базы данных
Понимание естественного языка (НЛУ)
Сопоставление естественного языка и SQL-запросов (синтаксических, лексических и семантических)

2.1 Решение лингвистической изменчивости во входных данных

На входе основная проблема Text2SQL заключается в гибкости языка: как описано в разделе Формат и структура данных, один и тот же вопрос можно перефразировать по-разному. Кроме того, в реальном разговорном контексте нам приходится сталкиваться с рядом проблем, таких как орфографические и грамматические ошибки, неполный и двусмысленный ввод, многоязычный ввод и т. д.

LLM, такие как модели GPT, T5 и CodeX, все ближе и ближе подходят к решению этой задачи. Учась на огромном количестве разнообразного текста, они учатся справляться с большим количеством языковых паттернов и несоответствий. В конце концов, они получают возможность обобщать вопросы, которые семантически схожи, несмотря на то, что имеют разные поверхностные формы. LLM можно применять «из коробки» («нулевой выстрел») или после тонкой настройки. Первый, хотя и удобен, приводит к снижению точности. Последнее требует больше навыков и работы, но может значительно повысить точность.

С точки зрения точности, как и ожидалось, наиболее эффективными моделями являются последние модели семейства GPT, включая модели CodeX. В апреле 2023 года GPT-4 привел к резкому увеличению точности более чем на 5% по сравнению с предыдущим уровнем техники и достиг точности 85.3% (по показателю «исполнение со значениями»).[4] В лагере открытого исходного кода первоначальные попытки решить головоломку Text2SQL были сосредоточены на моделях автоматического кодирования, таких как BERT, которые превосходно справляются с задачами NLU. на авторегрессионных моделях, таких как модель T5. T6 предварительно обучается с помощью многозадачного обучения и поэтому легко адаптируется к новым лингвистическим задачам, в т.ч. различные варианты семантического разбора. Однако у авторегрессионных моделей есть существенный недостаток, когда речь идет о задачах семантического разбора: они имеют неограниченное пространство вывода и не имеют семантических ограждений, которые ограничивали бы их вывод, что означает, что они могут быть потрясающе творческими в своем поведении. Хотя это отличный материал для создания контента в свободной форме, он доставляет неудобства для таких задач, как Text7SQL, где мы ожидаем ограниченный, хорошо структурированный целевой вывод.

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 не позволяет полностью интегрировать его в производственные системы — вместо этого необходимо активно управлять ожиданиями и поведением пользователя, который всегда должен осознавать, что он взаимодействует с система ИИ.

3.1 Управление отказами

Text2SQL может дать сбой в двух режимах, которые нужно отлавливать по-разному:

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

Второй режим особенно сложен, так как высок риск «тихих сбоев» — ошибок, которые пользователь не замечает. У прототипического пользователя не будет ни времени, ни технических навыков для проверки правильности запроса и/или полученных данных. Когда данные используются для принятия решений в реальном мире, такой сбой может иметь разрушительные последствия. Чтобы избежать этого, крайне важно обучать пользователей и устанавливать ограждения на уровне бизнеса которые ограничивают потенциальное воздействие, например, дополнительные проверки данных для решений с более высоким воздействием. С другой стороны, мы также можем использовать пользовательский интерфейс для управления взаимодействием человека и машины и помогать пользователю обнаруживать и улучшать проблемные запросы.

3.2 Взаимодействие человека и машины

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

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

Вторая возможность состоит в том, чтобы вовлечь пользователя в разъяснительный диалог в случае неуверенных, двусмысленных или иным образом подозрительных запросов. Например, ваша система может предложить орфографические или грамматические исправления для ввода и попросить устранить неоднозначность определенных слов или грамматических структур. Это также может позволить пользователю заблаговременно запрашивать исправления в запросе:[14]

USER: Покажи мне задачи Джона в этом спринте.

АССИСТЕНТ: Хотите увидеть задачи, созданные Джоном, или те, над которыми он работает?

USER: задачи, созданные Джоном

АССИСТЕНТ: Хорошо, вот идентификаторы задач:

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

АССИСТЕНТ: Конечно, вот задачи вместе с краткими описаниями, исполнителями и сроками, отсортированными по срокам.

Наконец, чтобы упростить понимание запросов пользователем, ваша система также может предоставить явную текстовую переформулировку запроса и попросить пользователя либо подтвердить, либо исправить его.[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-запросов. Хотя это делает приложение менее гибким, оно также снижает частоту сбоев, позволяет пользователям более гибко исследовать данные и создает ценные сигналы для дальнейшего обучения.
Основными нефункциональными требованиями, которые следует учитывать, являются точность, масштабируемость, скорость, объяснимость, конфиденциальность и адаптируемость с течением времени. Основные компромиссы заключаются между точностью, с одной стороны, и масштабируемостью, скоростью и конфиденциальностью, с другой.

[2] Нитаршан Раджкумар и др. 2022. Оценка возможностей преобразования текста в SQL больших языковых моделей

[3] Найхао Денг и др. 2023. Последние достижения в области преобразования текста в SQL: обзор того, что у нас есть и что мы ожидаем

[4] Мохаммадреза Пурреза и др. 2023. DIN-SQL: декомпозированное контекстное обучение преобразованию текста в SQL с самоисправлением

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

[6] Си Виктория Лин и др. 2020. Объединение текстовых и табличных данных для междоменного семантического анализа текста в SQL

[7] Тонг Го и др. 2019. Содержимое Расширенное преобразование текста в SQL на основе BERT

[8] Торстен Шолак и др. 2021. PICARD: пошаговый синтаксический анализ для ограниченного авторегрессивного декодирования на основе языковых моделей

[9] Цзиньян Ли и др. 2023. Graphix-T5: смешивание предварительно обученных преобразователей со слоями, поддерживающими графы, для синтаксического анализа текста в SQL

[10] Ленгчейн. 2023. LLM и SQL

[11] Тао Ю и соавт. 2018. Паук: крупномасштабный набор данных с человеческой маркировкой для сложного и междоменного семантического анализа и задачи преобразования текста в SQL

[12] Жуйци Чжун и др. 2020. Семантическая оценка для преобразования текста в SQL с помощью дистиллированных наборов тестов

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