Text-to-SQL повзрослел: агенты сами пишут запросы к базам

За последний год генерация SQL из естественного языка перестала быть демо на конференциях и переехала в продакшн-инструменты. Snowflake добавил Cortex Analyst и Copilot прямо в свой веб-редактор, Google встроил Duet AI (позже переименованный в Gemini) в BigQuery Studio, Databricks развивает Databricks Assistant, а десятки стартапов вроде Vanna и Dataherald предлагают open-source-обвязку поверх GPT-4o и Claude. Общий сдвиг простой: раньше нейросеть выдавала запрос, который надо было перепроверять руками, теперь это агент, который сам смотрит на схему таблиц, строит запрос, выполняет его, ловит ошибку и переписывает.

Что изменилось: от автодополнения к агенту

Первые text-to-SQL-инструменты работали как продвинутый автокомплит. Вы писали комментарий вроде «выбери всех клиентов из Москвы за прошлый месяц», модель дописывала SELECT — и на этом её работа заканчивалась. Если таблица называлась не так, как модель предположила, или колонка хранила дату строкой, запрос падал, и разбираться приходилось вам.

Агентный подход добавляет цикл. Модель получает доступ к метаданным: список таблиц, типы колонок, иногда примеры значений и связи между таблицами. Дальше она действует итеративно: формирует запрос, прогоняет его (часто на лимитированной выборке или в режиме EXPLAIN), читает сообщение об ошибке и корректирует себя. Для сложных вопросов агент разбивает задачу на шаги — сначала найти нужные таблицы, потом собрать JOIN, потом добавить агрегацию.

Ключевой строительный блок здесь — RAG¹ по схеме базы. Вместо того чтобы запихивать описание всех 800 таблиц в промпт, система хранит их описания в векторном индексе и подтягивает в контекст только релевантные вопросу. Это решает две проблемы разом: экономит контекстное окно и снижает шанс, что модель придумает несуществующую таблицу.

Text-to-SQL хорош ровно настолько, насколько хороша документация вашей схемы. Модель не угадает, что колонка status = 3 означает «отменённый заказ», если это знание живёт только в голове разработчика.

Кто что предлагает

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

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

Насколько это точно

Академический ориентир для этой задачи — бенчмарки Spider и BIRD, где модели генерируют SQL по вопросам на английском к заранее описанным схемам. Лидеры leaderboard-таблиц BIRD показывают исполняемую точность выше 70 процентов, но это лабораторные условия с чистыми схемами и понятной постановкой. Проверяйте свежие результаты на официальном leaderboard BIRD, потому что верхние строчки меняются почти каждый месяц.

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

Кому это пригодится, а кому нет

Инструмент решает конкретную боль: очередь к аналитику. Когда маркетолог хочет узнать конверсию по когорте, а единственный человек с доступом к SQL занят на неделю вперёд, агент закрывает вопрос за минуты.

• Продуктовые и маркетинговые команды — задают вопросы к готовой витрине данных, где схема описана и метрики согласованы. Здесь text-to-SQL работает лучше всего.
• Аналитики-джуниоры — используют агента как ускоритель: получают черновик запроса и правят его, вместо того чтобы писать десятый JOIN с нуля.
• Разработчики — быстро проверяют гипотезы по незнакомой базе, не открывая документацию по каждой таблице.

Где это скорее навредит:

• Финансовая и регуляторная отчётность — цена ошибки в цифре высока, а агент иногда выдаёт правдоподобный, но неверный запрос: например, считает сумму без фильтра по отменённым транзакциям.
• Базы без документации — если схема не описана, агент угадывает смысл колонок и ошибается тем чаще, чем запутаннее данные.
• Прямой доступ на запись — давать агенту право на UPDATE или DELETE без подтверждения человека опасно, здесь одна галлюцинация стоит потерянных строк.

Что проверить перед внедрением

1. Убедитесь, что у витрин есть описания таблиц и колонок — без них качество будет низким независимо от модели.
2. Ограничьте агента правами на чтение и отдельной учётной записью с квотами, чтобы кривой запрос не положил кластер.
3. Настройте обязательный предпросмотр SQL перед выполнением: пусть человек видит, что именно уйдёт в базу.
4. Проверьте, куда уходят метаданные и содержимое запросов — при использовании внешних API схема и примеры данных покидают ваш периметр.
5. Заведите набор эталонных вопросов с известными ответами и прогоняйте его при смене модели, чтобы ловить регрессии.

¹ RAG (retrieval-augmented generation) — подход, при котором модель перед ответом подтягивает релевантные фрагменты из внешнего хранилища (здесь — описания таблиц и колонок) и использует их как контекст, вместо того чтобы держать всё знание в самих весах.