За последние несколько лет поставщики баз данных и аналитических решений присоединились к общему тренду, который может привести нас всех к тому, что общие запросы к данным будут свободны от ограничений специализированного языка запросов SQL.
Например, в начале этого месяца AWS пообещала «решение для преобразования естественного языка в SQL… которое преобразует бизнес-вопросы в запросы к базам данных и возвращает действенные ответы».
Однако, хотя инструменты text-to-SQL могут помочь разработчикам баз данных, которые уже знают SQL, сэкономить время, организациям следует проявлять осторожность, прежде чем позволять бизнес-пользователям свободно работать с этими инструментами, предупредил Ник Кудас, профессор кафедры компьютерных наук Университета Торонто.
В беседе с The Register Кудас, который занимается исследованиями систем SQL на естественном языке, отметил, что проблема заключается в том, что для бизнес-пользователя системы могут создавать запросы с правильным синтаксисом, но которые не отражают их предполагаемый запрос.
SQL изначально разрабатывался так, чтобы быть максимально приближенным к естественному языку, как рассказал The Register в 2024 году соавтор Дональд Чемберлин в 2024 году. Однако из-за ограничений и неоднозначности естественного английского языка пришлось пойти на компромисс при создании более или менее повсеместного языка данных, который мы видим сегодня.
Из-за ограниченного числа людей, владеющих навыками SQL, поставщики решили заполнить этот пробел, предположив, что LLM станут хорошим способом построения системы данных на естественном языке.
Например, AWS описала, как пользователи могут разработать концептуальный проект text-to-SQL, используя свою платформу Bedrock для создания приложений и агентов генеративного ИИ.
«Многие организации обнаруживают, что доступ к аналитическим данным остается значительным узким местом в процессах принятия бизнес-решений. Традиционный подход требует либо изучения синтаксиса SQL, либо ожидания технических ресурсов, либо использования заранее созданных панелей мониторинга, которые могут не отвечать на конкретные вопросы», — говорится в сообщении.
Такой инструмент может помочь устранить барьер экспертизы SQL, который блокирует быстрый анализ, утверждают они. «Большинство бизнес-пользователей не обладают техническими знаниями SQL, необходимыми для доступа к сложным данным. Простые вопросы часто требуют объединения нескольких таблиц, временных вычислений и иерархической агрегации. Эта зависимость создает узкие места, когда бизнес-пользователи долго ждут настраиваемых отчетов, а аналитики тратят ценное время на повторяющиеся запросы, а не на стратегический анализ», — говорится в сообщении.
AWS не одинока в этом стремлении. Еще в 2024 году поставщик облачных платформ данных Snowflake создал новый сервис, который, по их утверждению, поможет организациям создавать чат-боты, способные предоставлять данные из собственных аналитических систем, а также внешних по отношению к поставщику облачной платформы данных. Этот подход использует управляемый поставщиком сервис ИИ Cortex.
С тех пор компания представила Cortex Analyst, который вводит семантическую модель, «связывающую бизнес-термины со схемой базы данных», по словам поставщика. «Она направляет LLM на создание более точных SQL-запросов, включая правильные элементы, такие как объединения и фильтры», — говорится в сообщении.
Даже MongoDB — документоориентированная NoSQL база данных — имеет свой собственный API для запросов MongoDB на естественном языке, построенный на программном фреймворке LangChain.
Технологическая индустрия предоставила ресурсы, чтобы помочь разработчикам определить, какие инструменты могут помочь в создании систем text-to-SQL. Например, бенчмарк BIRD-SQL заявляет о предоставлении кросс-доменного набора данных, который изучает влияние обширного содержимого базы данных на синтаксический анализ text-to-SQL. Нынешний лидер — это исследование с использованием AskData и GPT-4o от OpenAI, с точностью выполнения почти 82 процента по сравнению с экспертной человеческой производительностью около 93 процентов.
Тем не менее, Кудас предостерегает от чрезмерной зависимости от таких систем.
«SQL был языком для баз данных более 50 лет. Люди представляли, даже до появления LLM, что можно сделать его еще более доступным, по сути, переводя естественный язык в SQL. В плане чистых исследований люди пытались это сделать и показывали, насколько это сложно. Теперь с LLM, благодаря глубокому семантическому пониманию предварительного обучения, наблюдается быстрое развитие», — сказал он.
Он объяснил, что подход обычно осуществляется в два этапа. Первый — это попытка сопоставить естественный язык со схемой базы данных, чтобы понять, какие таблицы и какие атрибуты участвуют в запросе. Второй этап — генерация SQL.
«Практически каждый поставщик баз данных уже реализовал эту функциональность в той или иной форме. Если вы посмотрите на такие компании, как Snowflake или Databricks, у них есть некий интерфейс text-to-SQL, где люди могут просто использовать естественный язык для получения SQL-запроса», — сказал он.
Текущий предел точности «из коробки» около 80 процентов обусловлен тем фактом, что большинство организаций используют системы с проприетарными наборами данных и проприетарными схемами с использованием специфической терминологии внутри компании. Без дополнительного обучения LLM не имеют доступа к этим определениям, сказал он.
Тем не менее, эти инструменты все же могут сэкономить время разработчикам и администраторам баз данных, поскольку у них есть навыки для проверки SQL, сгенерированного LLM, и его подтверждения.
«Думайте об этом как об утилите для разработчика баз данных, который знает SQL и может судить, является ли запрос, полученный от LLM, правильным запросом, и если есть ошибка, исправить ее», — сказал Кудас.
Но использование систем text-to-SQL без участия человека, понимающего SQL, может быть рискованным, сказал он. В то время как запрос, который производит синтаксически неверный SQL, может быть безвредным — он просто не сработает.
«Всегда есть шанс, что LLM после нескольких попыток создаст SQL-запрос, который на самом деле синтаксически совершенно правильный, но семантически неверный. Если вы ему доверяете, и получаете что-то, что не имеет никакого отношения к [запросу], тогда у вас большая проблема, и я думаю, люди это понимают», — сказал он.
Для повышения уровня точности или, по крайней мере, снижения риска при использовании этих систем, исследования в настоящее время сосредоточены на возвращении человека в цикл, но вместо эксперта по SQL, это пользователь, у которого LLM может запросить дополнительное разъяснение.
«Естественный язык неоднозначен и имеет множество нюансов. Поэтому, когда LLM берет естественный язык и начинает генерировать SQL, вы встраиваете механизм внутрь вывода LLM, который — при создании вашего SQL-запроса — понимает, что следующий токен, который он сгенерирует, вызовет крайнюю неопределенность. Поскольку он фиксирует собственную неопределенность и благодаря сопоставлению со схемой, когда у вас есть неопределенный токен, вы можете взять этот токен, он может проанализировать схему и задать обратный вопрос пользователю на естественном языке. Если он не уверен, он говорит: «Вы имели в виду это или то в своем вопросе? Или этот атрибут является частью вашего ответа?»
«Благодаря синергии между человеком и LLM, человек может помочь LLM правильно выполнить работу», — сказал он.
Но на данный момент большинство вариантов использования text-to-SQL схожи с использованием LLM для разработки программного обеспечения: это инструменты для повышения производительности, а не для замены разработчиков, сказал Кудас.
Несмотря на преимущества систем text-to-SQL на базе LLM, 50-летний поиск полностью естественного способа запроса и управления данными еще не завершен. ®
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Lindsay Clark
