AWS показала Text-to-SQL на Amazon Bedrock для перевода бизнес-вопросов в SQL

AWS опубликовала подробный разбор Text-to-SQL-решения на Amazon Bedrock, которое переводит бизнес-вопросы на обычном языке в SQL-запросы и сразу возвращает ответ в понятной форме. Это не отдельный новый продукт, а практическая архитектура для компаний, у которых данные есть, а быстрых ответов на вопросы бизнеса по-прежнему нет.

Почему BI мало В AWS объясняют проблему просто: даже в компаниях с

сильной аналитикой пользователь все равно упирается в очередь к аналитикам или в ограничения готовых дашбордов. Если вопрос выходит за рамки заранее собранного отчета, нужны join'ы, временные срезы, расчетные метрики и знание внутренней логики таблиц. Для sales, finance или operations это означает потерю часов, а иногда и дней, на одноразовый запрос, который сам по себе не оправдывает отдельную разработку.

Именно здесь, по версии AWS, обычный self-service BI начинает буксовать. Натуральный язык в BI-интерфейсах хорошо работает на заранее подготовленных семантических слоях, но хуже справляется с сырыми таблицами, внутренними терминами и метриками, которые в каждой компании считаются по-своему. Поэтому AWS предлагает строить не просто генератор SQL, а систему, которая понимает контекст бизнеса: что такое revenue, как считается pipeline и какие таблицы вообще можно соединять.

Как устроен пайплайн В основе схемы —

Amazon Bedrock как слой инференса и оркестрации, плюс knowledge graph для бизнес-контекста и аналитическое хранилище для исполнения запросов. Центральную роль играет AgentCore Runtime: он принимает вопрос, решает, нужно ли разбивать его на подзадачи, вызывает поиск контекста, запускает генерацию SQL и возвращает итоговый ответ. Для компаний это важно, потому что логика не зашита в один промпт: ее можно разложить на отдельные шаги и контролировать на каждом этапе.

классификация вопроса на простой или составной поиск бизнес-контекста через GraphRAG генерация SQL в структурированном формате детерминированная валидация запроса перед запуском * синтез ответа на естественном языке по результатам выборки Для контекста AWS использует связку Amazon Neptune и OpenSearch: в графе хранятся связи между таблицами, колонками, метриками, терминами и иерархиями внутри компании. Дальше система делает векторный поиск по описаниям и значениям, проходит по связям графа и отдает модели только релевантные таблицы, поля, пути join'ов и бизнес-правила. При сложных вопросах архитектура может запускать несколько агентов параллельно и выбирать наиболее надежный результат по majority voting.

Продакшен и контроль Самый практичный кусок поста — не про LLM, а про защитные слои.

AWS отдельно подчеркивает, что промптами нельзя надежно поймать семантически неверный SQL: запрос может быть синтаксически валидным, но давать опасный или просто ложный результат. Поэтому после генерации SQL проверяется детерминированными валидаторами на уровне AST. Если система видит риск — например, слишком широкий скан, неправильную агрегацию или отсутствие нужных фильтров, — она автоматически правит запрос и пробует снова.

Вторая тема — задержка и доступы. По данным AWS, простые SQL-запросы в такой схеме обычно генерируются примерно за 3–5 секунд, хотя итоговое время зависит от модели, размера графа знаний и скорости хранилища. Чтобы сохранить интерактивность, AWS советует параллелить подзадачи, экономить токены и не раздувать агентный контекст.

Параллельно в архитектуру сразу встраиваются Row-Level Security-фильтры, чтобы пользователь видел только те строки, к которым у него уже есть доступ по корпоративным правилам.

Что это значит AWS фактически показывает, что

Text-to-SQL перестает быть демонстрацией из песочницы и превращается в инженерный паттерн для реальных BI-сценариев. Главный вывод не в том, что LLM умеет писать SQL, а в том, что рабочая система требует графа знаний, проверок, оркестрации и контроля доступа. Для команд, которые хотят дать бизнесу чат-интерфейс к данным, это хороший ориентир: меньше магии, больше инфраструктуры и правил.