Text-to-SQL — это сценарий, в котором пользователь задаёт вопрос обычным языком, а AI генерирует SQL под конкретную схему базы данных. Для демо достаточно дать модели DDL и вопрос. Для реальной компании этого мало: ошибка в JOIN, фильтре, timezone или правах доступа может дать убедительный, но неверный ответ — либо создать риск для данных.

Где Text-to-SQL действительно полезен

  • Ad-hoc аналитика: быстро получить черновик SELECT для бизнес-вопроса.

  • Self-service BI: дать менеджеру безопасный путь от вопроса к проверяемому запросу.

  • Поддержка разработчика: объяснить существующий SQL, найти ошибку или предложить оптимизацию.

  • Прототип аналитического интерфейса поверх PostgreSQL, MySQL, BigQuery, Snowflake и других SQL-систем.

Почему модели нужна схема базы данных

Без schema context модель угадывает названия таблиц, полей и связей. Перед генерацией полезно передавать не всю базу, а релевантный набор DDL: таблицы, типы, foreign keys, описания бизнес-полей и допустимые значения. Чем точнее semantic layer, тем меньше вероятность «правильного SQL не к тем данным».

Добавьте бизнес-контекст, а не только DDL

  • Опишите, что считается активным клиентом, выручкой, возвратом, churn и другими бизнес-метриками.

  • Укажите timezone и правила работы с датами.

  • Зафиксируйте, какие таблицы являются source of truth, а какие — staging или snapshots.

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

Read-only execution по умолчанию

AI-generated SQL не должен выполняться под ролью, которая может менять production-данные. Практический baseline — отдельный read-only пользователь, запрет INSERT/UPDATE/DELETE/DDL, доступ только к разрешённым schemas/views и отдельный connection pool для аналитических запросов.

Проверяйте SQL до выполнения

  • Парсите запрос в AST, а не проверяйте опасные слова простым regex.

  • Разрешайте только SELECT и заранее утверждённый набор функций.

  • Блокируйте доступ к системным и чувствительным таблицам.

  • Автоматически добавляйте LIMIT, statement timeout и ограничения на объём сканируемых данных.

  • Для дорогих запросов сначала запускайте EXPLAIN/EXPLAIN ANALYZE на безопасном окружении или используйте estimate/cost guard.

RLS и permissions должны применяться вне LLM

Если разные пользователи видят разные строки, модель не должна сама решать, кому что можно показывать. Row-Level Security, tenant filters и role permissions должны применяться на уровне базы или проверяемого policy layer. Передача скрытых данных модели с надеждой, что она «не покажет их пользователю», — неправильная граница безопасности.

Как проверять качество Text-to-SQL

  • Execution accuracy: выполняется ли запрос без ошибки.

  • Result accuracy: совпадает ли результат с эталонным ответом, а не только синтаксис SQL.

  • Schema grounding: использует ли модель существующие таблицы и поля.

  • Policy violations: были ли попытки обратиться к запрещённым объектам.

  • Cost/latency: сколько данных сканирует запрос и укладывается ли он в SLA.

  • Abstention: умеет ли система попросить уточнение, когда вопрос неоднозначен.

Нельзя оценивать только «красивый SQL»

Два синтаксически корректных запроса могут вернуть разные бизнес-ответы. Например, вопрос «выручка за месяц» зависит от статусов заказа, возвратов, валюты и даты признания revenue. Поэтому production Text-to-SQL должен сравниваться с golden set реальных вопросов и проверенных результатов.

Как построить безопасный pipeline

  • Классифицировать вопрос и выбрать релевантные таблицы/semantic definitions.

  • Сформировать компактный schema context.

  • Сгенерировать один или несколько SQL-кандидатов.

  • Провести AST/policy validation.

  • Оценить cost и при необходимости потребовать подтверждение.

  • Выполнить запрос через read-only роль.

  • Вернуть таблицу/визуализацию вместе с показанным SQL и источниками метрик.

  • Логировать вопрос, SQL, execution time, row count, ошибки и feedback пользователя.

Когда задавать уточняющий вопрос

Если пользователь спрашивает «лучшие клиенты», а система не знает, что считать лучшим — выручку, маржу, LTV или количество заказов — правильное поведение не угадывать, а уточнить метрику. Такая пауза полезнее, чем уверенный, но случайный SQL.

Text-to-SQL и BI — не одно и то же

BI отвечает за модель данных, governance, dashboards и согласованные метрики. Text-to-SQL — интерфейс доступа к данным и ускоритель ad-hoc анализа. Он может дополнять BI, но не заменяет semantic layer, data quality и ownership метрик.

Минимальный production checklist

  • Read-only DB role и allowlist schemas/views.

  • Schema + semantic context вместо голого prompt.

  • AST validation и запрет data-changing statements.

  • RLS/tenant permissions вне LLM.

  • LIMIT, timeout и cost controls.

  • Golden set с реальными вопросами и эталонными результатами.

  • Показ сгенерированного SQL пользователю или reviewer.

  • Audit log и наблюдаемость по ошибкам, latency и дорогим запросам.

Практический вывод

Нейросеть для SQL-запросов полезна не потому, что «пишет SELECT быстрее человека», а потому что снижает стоимость перехода от бизнес-вопроса к проверяемому запросу. Надёжный Text-to-SQL — это связка LLM, schema/semantic context, database permissions, SQL validator и quality evaluation. Без этих слоёв удобный чат легко превращается в источник тихих аналитических ошибок.