AI-агент для SQL может без единой синтаксической ошибки назвать три разные суммы выручки за сентябрь — если не знает, какую дату, статусы заказов и возвраты компания включает в метрику. Для российских команд, тестирующих чат-аналитику поверх DWH, это означает неприятную, но полезную вещь: качество ответа определяется не только моделью, а прежде всего тем, насколько данные и правила подготовлены для машины.
Такую проблему на воспроизводимом примере разбирает Habr / Карьера. Автор материала Сергей Прощаев, Tech Lead и преподаватель OTUS, описывает типичный сценарий: на демонстрационной базе агент быстро строит таблицу по запросу «выручка за сентябрь по регионам», а после подключения к рабочему хранилищу выдаёт цифру, не совпадающую ни с финансовым отчётом, ни с дашбордом продаж. Повторный вопрос в другой формулировке способен принести ещё один правдоподобный результат.
Причина часто лежит не в генерации SQL как таковой. В корпоративной базе слово «выручка» может означать сумму заказов, оплаченные заказы, сумму после возвратов или показатель, рассчитанный по дате отгрузки. SQL во всех вариантах будет исполнимым. Но один аналитик отрежет период по дате создания заказа, другой — по дате оплаты, третий не исключит отмены. Модель, которой не передали правило, выбирает трактовку сама — по названиям полей, примерам в контексте или статистической догадке.
Эта разница особенно заметна за пределами учебных наборов. В опубликованной на ICLR 2025 версии бенчмарка Spider 2.0 собрали 632 задачи из корпоративных сценариев для BigQuery и Snowflake. Агент на o1-preview решил 21,3% задач; для учебного Spider 1.0 в материале приводится результат 91,2%, для BIRD — 73,0%. Позднее на наборе Spider 2.0-Snow, включающем 547 задач для Snowflake, лучшие агентные системы превысили 90%, поэтому ранние 21,3% не стоит читать как окончательный диагноз технологии. Но контраст показывает цену реальной схемы: сотни таблиц, тысячи колонок и несколько диалектов SQL быстро заканчивают праздничную часть пилота.
Ещё жёстче это видно в BEAVER — наборе из 9 128 пар «вопрос — SQL», собранных по логам закрытых корпоративных хранилищ. В нём 812 таблиц из 19 предметных областей; средний запрос затрагивает четыре таблицы и содержит 5,7 соединения. Базовый агентный фреймворк ReFoRCE с GPT-5.2 показал 10,8%, с Claude 4.5 Sonnet — 11,4%. Авторы отдельно проверили, что происходит, когда агенту заранее помогают с задачей: без подсказок средняя точность по моделям составила 9,5%, а подсказки о таблицах, ключах соединения и колонках подняли её до 18,9%. Полный набор подсказок, включая знания предметной области и декомпозицию вопроса, дал 25,9%.
Цифры не означают, что AI-агент для SQL бесполезен. Они указывают, где именно находится узкое место. После подсказок в BEAVER почти половина оставшихся ошибок — 46,8% — связана со структурой запроса: группировками, сортировками и сложными функциями. Ещё 35,2% приходятся на выбор элементов схемы, 18% — на фильтры. Иными словами, одной инструкции «используй только эти таблицы» недостаточно: агенту нужно объяснить, какие поля являются ключами, какая связь является один-ко-многим, какие статусы считаются финальными и какая дата считается датой бизнеса.
Авторы материала напоминают и о выводах Майкла Стоунбрейкера и Питера Чена, опубликованных в Communications of the ACM 23 сентября 2026 года. На реальных хранилищах мешает не только сложность запросов, но и так называемая деградация смысла схемы: после реорганизаций и интеграций названия таблиц и колонок перестают точно описывать содержимое. В одной базе может быть шесть полей с названием salary, но одно хранит сумму до вычетов, а другое — выплату на руки. В административном хранилище MIT исследователи столкнулись, например, с термином J-Term для январского учебного периода и с нумерацией зданий вместо привычных названий. Из DDL такие детали не извлечь.
Для разработчиков это аргумент не превращать text-to-SQL в прямой доступ модели ко всем таблицам. Нужны каталог метрик, описания полей, явные правила join, список допустимых фильтров и проверяемые эталонные запросы. Для продактов и руководителей аналитики — повод измерять пилот не числом красивых ответов на демо, а совпадением с утверждёнными отчётами на реальных вопросах. Полезно также показывать пользователю не только итоговую сумму, но и выбранное определение метрики, период, фильтры и сформированный запрос: спорить с цифрой проще, когда видно, откуда она взялась.
Следующий конкурентный слой в корпоративной аналитике будет строиться вокруг семантических моделей, а не вокруг очередной кнопки «спросить данные». Модель всё лучше пишет SQL, но ей всё равно нужно решить, что в конкретной компании означает «выручка за сентябрь». Пока это знание хранится в голове финансового аналитика, комментариях к дашборду и старом запросе с десятком CTE, AI-агент для SQL будет уверенно отвечать на вопрос, которого ему на самом деле не задавали.