Как превратить текст «Сколько было продано камер в прошлом месяце?» в осмысленный SQL‑запрос? Это и есть задача text‑to‑SQL (ее ещё называют NL2SQL). Для многих компаний сейчас очень важна возможность задавать вопросы к данным обычным языком, без изучения SQL. Для этой задачи написаны десятки инструментов, но суть одна — генерация корректного запроса из фразы на человеческом языке.

Требование проясняется примером: бизнес‑пользователь хочет узнать: «Какие топ-5 товаров по выручке за вчерашний день?» — а система превращает это в SELECT product, SUM(revenue) ... LIMIT 5 и выдаёт результат. До недавнего времени требовались сложные пайплайны или ручное кодирование, а сейчас на сцене — большие языковые модели (LLM) и всякие хитрые методы достучаться до них.

В этой статье мы пробежимся по ретро‑ и ультрасовременным подходам к text‑to‑SQL. Плюс обзору добавим практических инсайтов.

---

N. B. Это, по сути, первая часть статьи!

Часть 1. Она фокусируется на истории методик text‑to‑SQL, разных подходах к промтингу и онлайн‑сервисах.

Часть 2. Если вы хотите перейти к бенчмаркам крупных языковых моделей (а именно ChatGPT o3-mini‑high, 4.1, o3, Claude Sonnet 4, DeepSeek R1–0528, Gemini 2.5 Pro), то вам сюда.

---

История подходов: от LUNAR до LLM

Корни задачи text‑to‑SQL уходят в 1973 год — легендарная система LUNAR отвечала на вопросы о Луне, написанные на естественном языке. Затем несколько десятилетий почти не происходило прорывов: часто использовались правила и шаблоны (например, парсинг по грамматикам) или небольшие специализированные нейросети. С развитием нейросетей появились seq2seq‑модели: одним из первых заметных достижений стал Seq2SQL — рекуррентная сеть, обученная на WikiSQL. Она довела точность выполнения запросов с 35,9% до 59,4%, что для тех лет было круто.

Но все классические системы заметно уступают современным крупным языковым моделям. С конца 2022-го, когда популяризовались GPT-4 и подобные, модель загружается под задачу генерации SQL и показывает чудеса — LLM в целом понимают язык лучше, чем предыдущие seq2seq‑модели. Например, открытая крупная модель Code Llama✶ после тонкой настройки превращается в SQLCoder и задаёт жару GPT-4. А ChatGPT-4 (API) тут же завоевал рекорды на Spider, достигая 85% точности лишь благодаря цепочке рассуждений в промте.

LLM закрыли многие пробелы: им не нужно вручную собирать миллион примеров под каждую базу, они разбираются с диалектами SQL и подсказывают нестандартные варианты.

Современные подходы: от промт-инжиниринга до RAG и CoT

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

Промт-инжиниринг и few-shot

Суть: не трогать веса модели, а скормить ей хитро составленный запрос. В этом известном способе промтинга, именуемом few‑shots, к запросу добавляют примеры‑образцы того, как выглядят уже существующие пары «запрос к нейросети — ожидаемый ответ от нейросети», а потом само задание. Примерно так:

Успех часто зависит от «приманки»: сколько примеров «вопрос — правильный SQL» включить, как они пересекаются с искомым вопросом, а также насколько корректен формат примеров (точки с запятой, кавычки и др.). Без этого LLM легко начинает галлюцинировать — придумывать несуществующие таблицы или столбцы. В Dataherald, например, разрешают загружать ориентирующие примеры (golden SQL), чтобы LLM видел похожие кейсы.

Плюсы: не нужно учить модель, можно быстро стартовать на новой БД.
Минусы: без примеров LLM легко ошибается и галлюцинирует (истинность галлюцинации проверять придётся руками).

Дообучение (файнтюнинг) моделей

Более надёжный путь — дообучать LLM на парных данных NL → SQL. Существуют прямо готовые модели: SQL Coder, DB‑GPT, отдельные версии Llama✶, Code Llama✶ и др. Для них готовят датасет пар «запрос — схема — ответ», и после файнтюнинга модель становится способна правильнее интерпретировать имена столбцов, фильтры и т. д.

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

Генерация с подключением внешних данных (retrieval-augmented generation, RAG)

В практической плоскости это системы, где перед генерацией промт «обогащается» схемами актуальных для текущего запроса баз данных (зачастую включая только нужные столбцы) и/или словаря знаний.

Иными словами, вспомогательный ИИ‑агент извлекает нужные куски и метаданные из баз данных (в обычном текстовом формате), затем прибавляет их к промту. Так модель лучше понимает «что такое orders.date».

Известный пример: QueryGPT (компании Uber) сначала ищет по векторному хранилищу схожие запросы и описания таблиц, потом передаёт их GPT-4 вместе с заданием. Опенсорс‑решения вроде Vanna или Dataherald тоже строятся на RAG: они и в документации прямо просят «натренировать RAG‑сущность на своих данных и потом задавать вопросы».

Плюсы: работает на реальных (или сильно меняющихся) данных, помогает при длинных схемах.
Минусы: нужна поддержка базы знаний и быстрый векторный поиск (индекс строится и обновляется периодически).

Декомпозиция, или разбиение задачи

Крупный запрос на естественном языке распадается на несколько подзадач. Например, сначала получаем промежуточный SQL‑фрагмент для SELECT, потом для WHERE и т. д., как в DIN‑SQL. Идея, роднящаяся с цепочками рассуждений.

Плюсы: проще контролировать каждую часть.
Минусы: нужен сборщик результатов.

Цепочка рассуждений (chain-of-thought, CoT)

Трюк: разбить генерацию SQL на шаги («Какие столбцы нужны?», «Как сгруппировать», «JOIN’ить какие таблицы?») и дозапросить у модели повторно.

Например, метод DIN‑SQL делал именно так: сначала GPT-4 предложил схемы и фильтры, потом дополнил недостающие части, затем проверил результат и сам же исправил помарки. Такой алгоритм с обратной связью дал +10% к точности в few‑shot и рекордные 85,3% на бенчмарке Spider. По сути, CoT — это вариант промт‑инжиниринга, где LLM размышляет вслух.

Плюсы: лучше справляется с логически сложными запросами и уменьшает галлюцинации, так как модель проверяет себя.
Минусы: многократное обращение к LLM и сложность конструирования логики проверки.

Разговорный диалог

При сложных последовательных запросах можно передавать историю; это не просто NL → SQL, а NL → SQL → NL и так далее. Чат‑агенты типа SQL Chat и Dataherald умеют помнить предыдущие фразы и подстраивать схему под каждый новый вопрос, примерно как ассистент помогает сформулировать следующий запрос.

Самодебаг

После первой SQL‑генерации модель сама себя проверяет: запускает SQL, анализирует ошибку или несоответствие, вносит поправки. Всё происходит в цикле «генерируй — тестируй — исправляй». Промты многих подходов содержат такую логику (в DIN‑SQL это именуется self‑correction loop).

Плюсы: ловит и исправляет банальные ошибки и несоответствия со схемой.
Минусы: сильно увеличивает время ответа; число итераций неопределённо.

Агенты и автотестирование

Некоторые системы строятся как мультиагентные: модель сама выполняет SQL и проверяет результат, перепрашивает себя при несоответствии или использует API БД для проверок. Пока это больше proof‑of‑concept, но архитектурно уже модно.

---

В общем, современная схема может выглядеть как применение одного из приёмов или нескольких (LLM, возможно дообученная, + RAG + CoT). Например:

• Uber QueryGPT — это LLM + RAG + агенты с потоковым генератором;

• Pinterest — GPT-4 + RAG;

• SQL Coder — почти чистая дообученная LLM (CodeLlama-7B/15B/70B✶), без RAG.

Смешивание приёмов является выигрышным: если промт слаб, дообучение или RAG подстрахует, и наоборот.

Сравнение методов промтинга

Ниже в таблице ранее описанные подходы в области текст‑в-SQL. Точность, при наличии данных, показана по известным измерениям, ну а сложность, конечно, понятие относительное — иногда она себя оправдывает.

---

Кстати, тестировать text‑to‑SQL‑модели удобно в агрегаторах — например, BotHub. Там собраны 180+ моделей в одном интерфейсе, а главное — не нужен VPN. Зарегистрируйтесь по спецссылке и получите 100 000 токенов для экспериментов с генерацией. Отличный способ сравнить, как GPT и Claude справляются с вашей базой!

---

Примеры внедрения в индустрии

Pinterest

Инженеры Pinterest в апреле 2024 рассказали об интеграции LLM в свой воркфлоу. Первоначально они скармливали ChatGPT-4 вопрос + схему таблиц и получили ~20% «сразу ок»‑запросов. В ход пошло всё — схемы, примеры, стриминг‑ответ.

После оптимизаций и обучения пользователей первоначальная точность выросла до 40%. А через полгода их новый RAG‑процесс автоматически предлагает таблицы по запросу и даёт пользователю выбрать нужные. Как итог, средняя скорость составления нужного SQL выросла примерно на 35% — за счёт того, что AI сразу понимает формат схемы и пользователю не надо лепить всё вручную.

Их ключевое решение:

1. Создание эмбеддингов описаний таблиц и примеров запросов для словаря внешних данных (RAG);

2. Затем уточнение пользователем списка таблиц;

3. И только после этого генерация финального SQL.

Этот кейс доказывает: в реальном бизнесе важен тандем LLM + RAG, а не просто «задать вопрос, и всё».

Кстати, вот какой промт они применяют:

И ещё парочка вспомогательных промтов

Scale AI

Эта компания (специализируется на ген‑ИИ и аннотировании данных) в конце 2023-го рассказала, как дообучила ChatGPT-4 на своих данных и побила мировой рекорд по SpiderDev. Итог: точность — 84% (до этого рекорд был примерно 80% у GPT-4 без дополнительного обучения). То есть даже гиганты тестируют тонкую настройку LLM для SQL.

Кстати, авторы статьи уже на тот момент (2023 год) подчёркивали, что бенчмарки, тестирующие модели в задачах текст‑в-SQL...

Такие, как эта сравнительная таблица

...не учитывают сложностей реальных баз данных, применяемых в компаниях.

Сравнивать модели здесь примерно так же сложно, как и инструменты для вайбкодинга. Допустим, если применяется внешний RAG‑источник (а он будет применяться в любой крупной организации), сперва агент или модель должны отфильтровать нужные исходные данные, затем отыскать подходящие термины из словаря знаний и лишь после скомбинировать всё это в текстовый промт, который модель и превратит в финальный SQL‑запрос. Одни и те же входные данные могут быть решены десятками способов, и задачи бывают разного уровня — отсюда и разный масштаб оценивания в разных бенчмарках.

И именно поэтому при проведении тестов я сосредоточился на проверочных датасетах LiveSQLBench — и его ощутимо сложных, нешаблонных тестовых заданиях.

Системы и инструменты

Здесь мы рассмотрим несколько популярных инструментов для задач text‑to‑SQL. Встречайте: IDE и онлайн‑сервисы (часто в формате чат‑ботов), которые существенно облегчают жизнь SQL‑разработчикам.

Vanna AI

Vanna AI — открытый RAG‑фреймворк, написанный на языке Python. Идёт больше как SDK: вы тренируете индекс (на CSV, JSON или БД‑схемах) и потом можете делать запросы. В комплекте есть демо‑интерфейсы — Python‑ноутбук, Slack‑бот и др. и поддержка нейросетей‑гигантов — ChatGPT, Anthropic, Gemini и тому подобных.

Сервис полностью бесплатен и позволяет расширенную настройку. Автоматически выбирает нужные примеры RAG, поддерживает разные СУБД (Postgres, Snowflake, BigQuery и др.). Низкий порог входа — документируется всё, можно поэкспериментировать через Colab.

Dataherald

Их ядро — LLM‑агент с цепочками рассуждений, векторным хранилищем, SQL‑исполнителем и алертами на ошибки: в компании говорят, что именно такое сочетание выдаёт лучшие результаты на больших замусоренных данных. Dataherald‑агент даже умеет подглядывать в документацию организации, например в форматах Word и PDF.

Есть GUI‑консоль, права доступа, журналы. Компания позиционирует Dataherald как «собери свой ChatGPT‑плагин к базе данных». Строго для продакшена: здесь учёт пользователей, авторизации и куча инфраструктуры.

Можно быстро сделать API на свои БД и выдавать людям ответы «как Google, но по вашим данным».

JetBrains DataGrip AI Assistant

JetBrains DataGrip AI Assistant — встроенный помощник в IDE DataGrip. Прямо в редакторе можно написать «Покажи объёмы продаж по региону» — и он сгенерирует SQL.

Прозрачно встраивается в привычный рабочий процесс разработчика, поддерживает альтернативные SQL. Работает, скорее всего, через OpenAI под капотом.

SQLAI.ai

SQLAI.ai — веб‑сервис с несколькими функциями: генерация SQL‑запросов, их форматирование, объяснение, анализ CSV. То есть это больше о помощи в отладке и анализе, чем просто текстовые промты. Подойдёт, если нужна допереписка запроса или визуализация по нему. Интуитивный интерфейс.

Outerbase

Outerbase — недавно куплен Cloudflare, но всё еще наличествует как бренд. Поддерживает множество SQL/NoSQL‑баз и хорошо адаптирован к топовым СУБД.

Kinetica SQL‑GPT

Kinetica SQL‑GPT — специализированный продукт, работающий через LLM. Они буквально назвали фичу «SQL‑GPT»: «SQL‑GPT uses an LLM to translate natural language to SQL queries». Сервис тоже позволяет преобразовывать сложные фразы на естественном языке в SQL‑запросы.

Chat2DB

Chat2DB — популярный опенсорсный клиент/чат для множества СУБД. Под капотом нейромодель + RAG. Поддерживает более 10 разных движков (Postgres, MySQL, ClickHouse, Redis и т. д.), локальный режим работы и защищённое подключение.

С помощью промтов в естественной форме можно генерировать SQL‑запросы, извлекать данные, визуализировать графики и собирать их в дашборды. По статистике, у него более миллиона пользователей, многие добавляют к нему собственные механизмы автокоррекции. Платная подписка (15–20 $/мес) даёт возможность обращаться к чат‑ботам (Claude, DeepSeek, ChatGPT, Qwen и др.).

SQLChat

MIT‑лицензированный проект (5300 звёзд на «ГитХабе»!). По сути, браузерный клиент с бэкендом на LLM, фишка — запоминание контекста диалога.

Его тоже применяют там, где нужен диалог с базой данной: например, напишите «Покажи топ-10 клиентов» и, не теряя контекста, попросите «А теперь тех, кто за последний месяц увеличил покупки». SQLChat фактически сидит на ChatGPT API и имеет привычный веб‑интерфейс.

SQL Coder

Defog выпустил несколько размеров моделей SQL Coder (7B/15B/70B). 70B‑модель показала результат «уровня человека»: на их внутреннем наборе данных — 93% точности на схемах, которые модель видела впервые. Правда, такая модель требует огромных ресурсов. Зато малые версии (7B/15B) могут работать на обычном ПК и почти не уступают в точности — компромисс для внедрения «у себя».

Возможные проблемы

Благодаря галлюцинациям, LLM порой выдумывает условия или таблицы: например, вы спросили «Сколько пользователей по городам?», а он написал WHERE country='Москва' вместо WHERE city='Moscow'. Чем меньше конкретных примеров или проверок, тем чаще глюки. Но описанные в начале статьи техники, а особенно их комбинации, спасают ситуацию.

Безопасность. LLM‑инструменты не обучены из коробки фильтровать вредоносные SQL. Например, кто‑то может спросить «Удали все таблицы» (DROP TABLE). SQLCoder прямо предупреждает: «Наша модель не отвергает опасные запросы, лучше давать ей только read‑only‑доступ».

Масштаб схемы. Огромные БД — еще одна проблема. Если таблиц сотня, а колонок несколько тысяч, ни одна модель не помещает всё в контекст. Результат — применение сложного RAG, иначе... обрезка данных. К тому же в реальности у базы могут быть непонятные названия столбцов (col1, data123), и без RAG‑контекста/словаря знаний нейросеть такое может не разгадать. Масштабные JOIN'ы (промежуточные слияния данных, требуемые для расчетов) и подзапросы — тоже вызов.

Бенчмарки и оценки

В сообществе есть множество датасетов и бенчмарков, через которые можно сравнивать существующие решения: WikiSQL, Spider, SParC, CoSQL, BIRD… Но я протестировал модели на проверочном наборе совсем нового из них — LiveSQLBench.

Что такое LiveSQLBench? Это уже существующий датасет и бенчмарк в одном лице (сайт, GitHub, Hugging Face). По словам авторов, LiveSQLBench задуман как бенчмарк с уровнем сложности существующих баз данных, то есть в нём применяются комплексные SQL‑запросы (не только SELECT).

Подобно тому, как LiveBench в целях объективности регулярно обновляет датасеты, беря материалы с сайтов вроде IMDb и Wikipedia, LiveSQLBench действует схожим образом: не предоставляет в простом открытом доступе полные результаты тестов — для их получения нужно обратиться по имейлу, указанному на https://github.com/bird‑bench/livesqlbench (в самом деле, не станет же бот‑скрейпер писать на почту с просьбой «Пришлите мне датасет»). Если указать специальный тег в теме письма, спустя полчаса робот скинет на почту JSONL‑файл, содержащий недостающие данные.

Зачем же это делать, если результаты бенчмарка всё равно уже известны? Как минимум причины две.

1. Во‑первых, я добавил одну новую модель, Gemini 2.5 Pro.

2. Во‑вторых, хотелось понять, в каких именно задачах (или типах задач) модели показывают себя хорошо и испытывают сложности.

Как я подготовил тесты

Сперва я скачал датасет:

git clone https://huggingface.co/datasets/birdsql/livesqlbench‑base‑lite

Слегка его дособирал — попросив модель o3 написать Python‑скрипт, который совместит файлы {…}_schema.txt (похоже, они были созданы через pg_dump ‑schema‑only, после чего скриптом добавлены примеры первых строк каждой таблицы) с файлами {…}_column_meaning_base.json. Тогда мы получим новые файлы, которые уже будет включать в себя комментарии к каждому столбцу «на ходу», а не отдельным файлом, — наверняка это нагляднее не только для человека, но и для нейросети.

Скриншот диалога с ChatGPT o3

Вдобавок я прицепил к каждому промту схему базы данных (которая лежала в соседнем файле {…}_kb.jsonl).

Что в итоге? Один промт получался длиной 50 000–70 000 символов, что вписывается в лимит современных моделей — 128K+ токенов.

---

И здесь мы плавно переходим к следующему материалу, где тестируются шесть LLM‑моделей на 10 text‑to‑SQL‑заданиях.

✶ Llama, Code Llama — проекты компании Meta Platforms Inc., деятельность которой запрещена на территории Российской Федерации.