Уже через год мы будем общаться с базами данных по-русски
По прогнозу 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 сценариях.
Кто проигнорирует этот тренд, тот останется в аутсайдерах с негибкими данными, а конкуренты будут принимать решения в режиме реального времени с использованием чат-интерфейсов.
