Почему AI-агент может дать три разных ответа на вопрос о выручке за сентябрь
Переход корпоративных ИИ-агентов с учебных баз данных на рабочие хранилища сопряжен с серьезными рисками. Один и тот же бизнес-запрос может привести к трем синтаксически корректным, но семантически различным SQL-запросам, выдающим разные цифры. Проблема кроется не в неумении модели писать код, а в отсутствии четкого определения бизнес-логики и словаря данных.
# Выручка за сентябрь: как AI-агент получает три разных ответа
Когда корпоративный ИИ-агент впервые подключают к реальной системе учета, часто происходит конфуз. На демонстрационной базе данных система идеально отвечает на вопрос «Покжите выручку за сентябрь по регионам». Через месяц, при интеграции с настоящим хранилищем предприятия, тот же запрос возвращает число, которое не совпадает с отчетами бухгалтерии. Спросите иначе — получите еще одно число.
Модель при этом работает без сбоев: SQL-запросы выполняются успешно, без ошибок синтаксиса. Однако результат остается некорректным с точки зрения бизнеса. Это подтверждают исследования и собственный эксперимент, проведенный экспертом из компании OTUS Сергеем Прощаевым.
От бенчмарков до реальности: где теряется точность
Главная трудность enterprise text-to-SQL (генерация SQL по вопросам на естественном языке) заключается в огромном разрыве между открытыми учебными данными и закрытыми корпоративными системами.
Авторы бенчмарка Spider 2.0, опубликовавшего исследования на ICLR 2025, обнаружили резкое падение точности моделей на реальных данных. Если на учебных наборах (Spider 1.0) современные агенты решают до 91% задач, то на реальном корпоративном бенчмарке (Spider 2.0) этот показатель упал до 21,3%. Сложность усугубляется наличием большого количества колонок, нескольких диалектов SQL и специфической структуры данных.
Еще один бенчмарк, BEAVER, анализирует запросы из логов реальных компаний. Здесь усредненная точность базовых агентов не превышает 11%. Даже использование продвинутых подсказок (разбиение задачи на этапы: поиск таблиц, определение ключей, сопоставление колонок) повышает успех лишь до 25–30%.
Ключевая проблема, отмеченная исследователями Майкла Стоунбрейкера и Питера Чена, заключается в контексте. Учебные данные открыты и могли быть «пробудены» в процессе обучения модели. Реальные хранилища закрыты, их схемы со временем «гниют», а бизнес-правила меняются быстрее, чем обновляется документация. Модель, не имея явного контекста о том, что такое «выручка» или как правильно соединять таблицы, вынуждена восстанавливать это «наугад».
Эксперимент: один вопрос — три SQL-запроса
Чтобы продемонстрировать механику ошибки, был проведен эксперимент на учебных данных интернет-магазина. Вопрос был прост: «Какая выручка за сентябрь?».
На основе одной и той же базы данных сгенерировали три разных SQL-запроса, каждый из которых выглядит правдоподобно, но решает задачу по-разному:
1. Запрос А (по дате создания): Суммирует суммы всех заказов, созданных в сентябре, независимо от их статуса (отмененные, ожидающие оплаты и т.д.). 2. Запрос Б (по статусу заказа): Филtrрует только завершенные заказы, но ошибочно соединяет их с таблицей платежей. Из-за отсутствия строгих ограничений (fan-out), где один заказ может быть оплачен несколькими транзакциями, сумма заказов удваивается для повторных платежей. 3. Запрос В (чистые поступления): Суммирует платежи, поступившие в сентябре, и вычитает возвраты, совершенные в сентябре. Это наиболее частая финансовая методология, но требует четкого понимания дат движений.
Результаты: * Запрос А дал значение +23,6% больше эталона. * Запрос Б дал значение +28,0% больше эталона (из-за двойного учета сумм). * Запрос В стал базой сравнения («нулем» отклонения), так как наиболее точно отражает финансовый поток.
Оба первых варианта синтаксически безупречны. Разница кроется исключительно в семантике: какое событие (создание, оплата или поступление денег) считать базой для расчета и как трактовать связи между таблицами.
Семантический слой как решение
Ошибка не в умении модели писать код, а в ее способности связывать вопрос с конкретной бизнес-логикой и структурой данных. Решение этой проблемы лежит в плоскости семантического слоя.
Семантический слой — это описание данных на уровне бизнеса: сущности, связи, зерно таблиц (что одна строка означает) и жесткие определения каждой метрики. Инструменты, такие как dbt, позволяют фиксировать это в спецификациях. В таких системах определение «выручки» не выводится из угадывания, а задается заранее: «Дата агрегации — дата оплаты, а не дата создания заказа; соединение производится только через внешние ключи».
Этот подход переносит знание аналитика из его головы в машинно-читаемую модель. Если термина нет в слое, агент не должен выдумывать, а должен запросить уточнение у пользователя: «Считать по отгрузке или по поступлению денег?»
Что означает «зерно»?
В контексте работы с базами данных под «зерном» (granularity) понимают минимальную единицу данных, содержащуюся в таблице. Например, в таблице заказов зерно может быть «одна строка — один заказ», а в таблице платежей — «одна строка — один платеж». Понимание различия между этими уровнями критично для корректного подсчета сумм и избегания ошибок наложения данных (duplications).
Вывод: роль аналитика растет
Подключение ИИ-агентов к рабочим хранилищам сделало написание SQL дешевым и доступным. Однако дорогой остался самый важный этап — договориться о том, что значат данные, и записать это так, чтобы это прочла машина.
Enterprise text-to-SQL — это не просто генерация кода, а цепочка разрешения контекста. Часть этого контекста традиционно живет в голове аналитика. Следовательно, роль специалиста не исчезает, а смещается: от написания каждого запроса к формализации смыслов, правил и метрик, на которых эти запросы будут строиться.
*«Честнее спросить, чем выдать число»*, — напоминает опыт экспериментов с семантическими слоями. В мире данных нет универсальных ответов, только точные формулировки.