Есть версия предложения NL2SQL, которая звучит идеально: пользователи задают вопросы на естественном языке, агенты генерируют SQL, данные возвращаются. Меньше экранов, меньше запросов, меньше кода. Просто.
Потом вы думаете об этом ещё пять минут.
Проблемы, о которых никто не говорит на демо
Схемы не были созданы для объяснения вещей. Криптические имена таблиц, непоследовательные имена столбцов, технически допустимые связи, которые семантически недопустимы без дополнительных предикатов — это нормально для корпоративных баз данных. Это не баги, это просто накопленная история бизнес-изменений. Но когда вы просите модель вывести намерение из схемы, которая не была создана для передачи намерения, модель попробует в любом случае. Она не сдастся. Она сгенерирует свой лучший вариант запроса и вернёт результаты с уверенностью.
Модели недетерминированы. Задайте один и тот же вопрос об одной базе данных дважды, и вы можете получить разный SQL. Модель вычисляет вероятности, и небольшие вариации в контексте дают разные результаты. Вы не можете тестированием добиться гарантии, что агент всегда генерирует правильный запрос.
Пользовательская проверка не масштабируется. “Просто проверяйте каждый запрос перед выполнением” звучит безопасно. Но это предполагает, что пользователи являются экспертами как в модели данных, так и в SQL — именно те люди, которым не нужен был интерфейс на естественном языке. Это также вводит когнитивную перегрузку и новый класс предвзятости подтверждения, где пользователи, перегруженные сложностью запроса, утверждают недействительные запросы вместо того, чтобы их исследовать.
И затем есть инъекция. В традиционной разработке SQL параметризация решала проблему инъекции, потому что пользовательский ввод заполнял параметры, а не структуру SQL. С NL2SQL модель сама генерирует SQL. Подсказка, контекст схемы, история разговора и полученные данные — всё влияет на то, что выполняется. Если кто-то создаёт подсказку, которая изменяет то, что генерирует модель, это инъекция — не на уровне параметра, а на уровне генерации запроса. И в отличие от удаления таблицы (очевидно, восстановимо), инъекция NL2SQL производит запросы, возвращающие неверные результаты без видимой ошибки. Бизнес-решения принимаются на основе неверных данных.
Что на самом деле решает SQL MCP Server
Именно здесь статья делает свой самый полезный практический вывод. Вместо того чтобы давать агенту произвольный доступ к схеме и надеяться на лучшее, SQL MCP Server предоставляет курируемую поверхность API, построенную на основе Data API builder.
Разница важна: агент не генерирует SQL. Он вызывает именованные конечные точки, которые возвращают предопределённые формы результатов. SQL пишется один раз, разработчиком, и является детерминированным. Недетерминизм агента ограничен выбором какую конечную точку вызвать, а не построением произвольных запросов.
Это аналогично тому, что параметризация сделала с SQL-инъекцией в традиционной модели приложений — вы убираете возможность создавать произвольные запросы из ненадёжного ввода.
Правильный вопрос
Статья не говорит “никогда не используйте NL2SQL.” Она говорит: будьте целенаправленны в том, где вы применяете его и что вы открываете. Для исследовательского анализа в контролируемой среде, с ограниченной схемой и доступом только для чтения, NL2SQL может подойти. Для производственных систем, где бизнес-решения зависят от результатов, курируемый уровень API значительно безопаснее.
Честность: некоторые проблемы действительно лучше решаются структурированными запросами за именованными конечными точками, чем естественным языком в SQL. SQL MCP Server даёт вам эту возможность, не отказываясь полностью от агентного интерфейса.
Оригинальная публикация: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?
