Уже через год мы будем общаться с базами данных по-русски

По прогнозу Gartner, запросы на естественном языке вытеснят SQL уже в 2026 году. Самое главное из исследования на русском языке собрано в этом посте ^[1]. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Типы полей, связи между таблицами, ограничения целостности.

• Бизнес-логика. Например: revenue = sales – returns + discounts.

• Откуда поступили и как преобразовывались данные. Например: temperature_raw → очистка от шума → … → temperature_clean. 

Fluid Data

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

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

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

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

Здесь же появляется автоматизация 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 сценариях.

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