Что такое NL2SQL и как он работает?

NL2SQL означает автоматический перевод вопроса на естественном языке в запрос SQL, который может выполняться на реляционной основе. В отличие от обычного чат-бота, который отвечает в произвольном тексте, система NL2SQL создает структурированный артефакт SQL, который выполняется на основе реальных данных и построчно возвращает проверяемый результат.

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

NL2SQL отличается от диалогового агента, подключенного к базе данных в широком смысле. Первый создает читаемый и проверяемый запрос; второй может объединить несколько вызовов инструментов (поиск, расчет, запись), не обязательно приводя к уникальному и проверяемому SQL. Правильно спроектированная система NL2SQL остается в этой сознательно ограниченной области: трансляция, проверка, выполнение, возврат результата.

Надежный конвейер NL2SQL всегда следует одной и той же последовательности, независимо от провайдера: вопрос проходит через языковую модель, затем созданный SQL проверяется перед выполнением, и никогда после. Реализация Aurabase, проверенная в сервисном коде aura-ai, иллюстрирует каждый из этих шагов конкретными правилами, а не абстрактным описанием.

1. Вопрос получен с фактической схемой базы.

Система связывает вопрос на естественном языке со схемой запрашиваемой базы данных: названиями таблиц, столбцов, типов. Этот шаблон должен исходить из самоанализа фактической основы, а не из описания, предоставленного вызывающей стороной. Реализация, которая принимает схему, объявленную клиентом, откроет дверь к вопросам о несуществующих таблицах или к обходу изоляции между проектами. Механизм Aurabase явно отклоняет (ошибка 400) любое поле schema, отправленное в запросе, а не игнорирует его молча.

2. LLM генерирует кандидатный SQL.

Языковая модель получает вопрос и схему в своем приглашении, а затем создает возможный SQL-запрос вместе с кратким объяснением. Aurabase одинаково относится к трем поставщикам с выделенным собственным клиентом: OpenAI, Anthropic (Claude) и Gemini. Этот кандидатный SQL на данном этапе является всего лишь предложением, которое никогда не выполняется напрямую.

3. SQL-кандидат проверяется до выполнения, а не после.

Это шаг, который отличает серьезную систему NL2SQL от простого вызова LLM с последующим наивным выполнением. Сгенерированный SQL анализируется в синтаксическом дереве (AST), а не проверяется поиском по ключевым словам, который легко обойти. Реализация Aurabase с библиотекой sqlparserдопускает только простые запросы SELECT: CTE/WITH, подзапросы, UNION, оконные функции и предложения блокировки (FOR UPDATE) явно отклоняются, как и любые функции SQL за пределами белого списка из десяти функций (count, sum, avg, min, max, lower, upper, coalesce, date_trunc, now).

4. Зафиксированный запрос выполняется с ограничением строки.

Проверенный SQL получает LIMIT, если он еще не имеет: 100 строк по умолчанию с Aurabase, максимум 1000, оба значения настраиваются на стороне сервера. Запрос, превышающий ограничение, явно отклоняется, а не сокращается молча. В ответе указывается, был ли этот LIMIT добавлен сервером, поэтому вызывающая сторона знает, отличается ли выполненный SQL от кода, созданного моделью.

-- Вопрос: «Сколько заказов в этом месяце для премиум-клиентов?»
SELECT count(*) FROM orders
WHERE customer_plan = 'premium'
  AND created_at >= date_trunc('month', now())
LIMIT 100  -- добавлено сервером, отсутствует в сгенерированном SQL

Полная информация об этом конвейере, с каждым вызовом HTTP и каждым ответом JSON, описана в нашем пошаговом руководстве по созданию конечной точки NL2SQL в Postgres.

NL2SQL не предназначен для повсеместной замены рукописного SQL. Он охватывает конкретную область применения: специальные, разовые вопросы, которые задает тот, кто не знает SQL или просто хочет сэкономить время на простом запросе.

• Специальное исследование информационной панели нетехническим человеком (поддержка, продукт, управление).
• Быстрое создание прототипа функции, которая запрашивает базу данных без написания специального маршрута API для каждого возможного вопроса.
• Ограниченное аналитическое самообслуживание: подсчитывайте, фильтруйте, просто агрегируйте, не предоставляя конечному пользователю прямого доступа к базе данных.

Рукописный SQL остается предпочтительнее, как только вопрос выходит за рамки этих рамок. Реализация, проверенная AST, подобная описанной выше, исключает CTE, подзапросы и оконные функции по своей конструкции по соображениям безопасности. Анализ, структурно нуждающийся в этих конструкциях, когортах, расширенном временном оконном режиме, не проходит через NL2SQL: он кодируется напрямую. Это приемлемый компромисс: безопасность системы важнее полноты сгенерированного SQL.

В реализации NL2SQL систематически повторяются три риска, реакция на которые зависит от зрелости системы.

SQL-инъекция через приглашение или вопрос

LLM можно манипулировать для создания вредоносного SQL-кода, если сам вопрос содержит попытку внедрения типа «игнорировать предыдущие утверждения и...». Защита заключается не в том, чтобы доверять подсказке, а в проверке SQL-запроса, созданного независимо от того, что было запрошено, а именно на шаге 3 описанного выше конвейера. Эта тема заслуживает специального рассмотрения: см. Защита NL2SQL от SQL-инъекций для получения точных векторов атак и мер противодействия.

Галлюцинация несуществующих таблиц или столбцов

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

Стоимость и задержка вызовов моделей

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

Две архитектуры дают одинаковый видимый результат, но с совершенно разными гарантиями. NL2SQL интегрирует генерацию, проверку и выполнение непосредственно на внутренний уровень, который уже знает схему проекта и права доступа: это логика, описанная выше для Aurabase, где служба aura-ai разделяет инфраструктуру и изоляцию схемы с остальной частью серверной части.

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

Ландшафт инструментов NL2SQL, встроенных и собранных, с открытым исходным кодом и коммерческих, подробно сравнивается в нашем Сравнение инструментов NL2SQL 2026.

NL2SQL и RAG (генерация с расширенным поиском) отвечают на два разных семейства вопросов, которые часто путают, поскольку оба полагаются на LLM, подключенный к базе данных.

NL2SQL ориентирован на структурированные и реляционные данные: сколько, когда, какая пропорция вопросов, которые естественным образом преобразуются в агрегаты SELECT, GROUP BY. RAG нацелен на неструктурированный контент: документы, заметки, заявки в службу поддержки, где ответ не умещается в строке таблицы, но требует найти соответствующий отрывок по семантическому сходству, векторному поиску по pgvector, индексу HNSW, прежде чем передать его в контекст модели.

Эти две возможности могут сосуществовать в одном проекте и объединяться в агенте, который выбирает одну или другую в зависимости от заданного вопроса. В основе искусственного интеллекта Aurabase подробно описано, как эти два механизма работают вместе, а в нашем руководстве по конвейеру RAG для pgvector рассматривается реализация второго.