Естественный язык вместо SQL: как LLM меняют работу с базами данных

По прогнозу Gartner, запросы на естественном языке вытеснят SQL уже в 2026 году. 

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

Oracle разработала APEX AI Assistant, который в интерактивном формате генерирует и выполняет SQL-запросы. На Hugging Face разработчики добавили возможность исследовать наполнение датасетов для обучения моделей при помощи инструмента, преобразовывающего естественный язык в SQL. 

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

Как мы учим LLM писать SQL

На конференции PGProDay 2025 я рассказывал про наш подход к генерации SQL в ответ на вопросы пользователя на естественном языке. 

Преимущества LLM

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

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

Возьмем для примера логистическую компанию.

Запросы вроде «Найти рейсы с задержкой более 2 часов» или «Рассчитать среднюю загрузку автопарка» легко формализуются в SELECT и JOIN.

Однако ключевое преимущество — нишевая кастомизация. Обученная на схемах таблиц или бизнес-глоссариях модель превосходит универсальные LLM. Если в некоторой БД столбец revenue включает возвраты товаров, а в другой — нет, то локально обученная модель учтет это. Она сможет корректно интерпретировать  даже сложные метрики типа «Километро-часы работы транспорта» или «Конверсии в повторные продажи».

Как изменится работа инженеров

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

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

Роль метаданных

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

Это основа для концепции Fluid Data, в которой структура данных автоматически адаптируется к изменениям контекста и среды:

• типы полей, связи между таблицами, ограничения целостности;
• бизнес-логика. Например: revenue = sales — returns + discounts;
• откуда поступили и как преобразовывались данные. Например: temperature_raw → очистка от шума → … → temperature_clean.

Fluid Data

Концепция Fluid Data подразумевает универсальность представления данных за счет применения LLM как транслятора. В частности упрощается переход от реляционной модели к графовой, от графовой к иерархической, от иерархической к документной и так далее.

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

От реляционных БД к графовым

Переход от реляционной модели к графовой — задача нетривиальная, но выполнимая. Автоматизировать этот процесс могут LLM, переводить запросы с естественного языка на язык Cypher для графовых СУБД они тоже могут. Я рассказывал об этом во все том же докладе.

Здесь же появляется автоматизация ETL/ELT. Модель анализирует разные источники данных и предлагает оптимальные пайплайны для их обработки, а также помогает адаптировать схему БД за счет написания миграций.

Адаптация схемы БД под новые данные

Представим металлургический комбинат внедряет систему предиктивной аналитики для мониторинга доменных печей.

Новые IoT-датчики на печах генерируют данные с дополнительными параметрами:

• vibration_spectrum — спектр вибрации в формате JSON. Например: {«10Hz»: 0.5, «20Hz»: 0.8}.
• electrode_wear_rate — скорость износа электродов, %/час.

Старая схема БД хранила только базовые метрики: temperature, pressure, output_volume. ETL-пайплайны загружали данные в витрину furnace_health, но не учитывали новые параметры.

Инженерам нужны отчеты:

• как спектр вибрации коррелирует с износом электродов?
• когда планировать остановку печи для замены электродов?

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

Полностью автономные СУБД рядом

Данные становятся интерактивными на уровне смысла, а не синтаксиса. Это открывает путь к полностью автономным СУБД, где LLM управляют всем циклом — от приема и обработки сырых данных до генерации аналитических отчетов.

Руководителям стоит уже сейчас:

• инвентаризировать метаданные и внедрять Data Catalogs;
• внедрять и тестировать NLP-интерфейсы в low-risk сценариях.

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