Когда ИИ не понимает бизнес-контексты

09.01.2026 • Хабр

Статья разбирает, почему ИИ-ассистенты уверенно пишут SQL и помогают с отчетами, но часто теряются в бизнес-контексте компании. Главный вывод: проблема решается не «другой моделью», а архитектурой вокруг неё.

Компании внедряют ИИ-ассистентов, которые автоматически пишут SQL-запросы и помогают менеджерам готовить отчеты.
В тексте приводится бенчмарк Spider 2.0: точность преобразования естественного языка в SQL на реальных схемах около 59%, а при усложнении задач падает до 40%.
Бизнес-логика и «корпоративная память» редко доступны модели: они находятся во внутренних артефактах вроде Jira-тикетов, презентаций, баз и схем.
Отмечено, что точность проседает на задачах, близких к реальным процессам: многошаговые запросы, джойны между незнакомыми схемами, разные SQL-диалекты и трансформации в DBT.
Как инженерный ответ описаны подходы на базе управляемого контекста, включая RAG с подгрузкой DDL, схем, моделей DBT и выборок строк, а также поиск по каталогам и хранилищам метрик.
Для снижения неоднозначности и ошибок упоминаются многоуровневая память, структурные ограничения для SQL и процесс обратной связи с оценкой по реальным KPI.

Почему это важно: Когда модель не понимает внутренние определения и правила, она выдаёт почти правильные результаты, которые превращаются в часы отладки и проверки. В тексте подчёркивается, что по мере приближения к продакшн-схемам и реальным процессам надёжность падает, а риски становятся прикладными — для отчетности и управленческих решений.

На что обратить внимание: В статье акцентируется, что полезность ассистента зависит от того, какие источники считаются «истиной» и как описаны таблицы, метрики и связи между данными. Отдельно подчёркивается работа только с контролируемыми источниками данных и соблюдение требований безопасности, иначе преимущества могут быть нивелированы рисками приватности и несоответствием требованиям регуляторов. Также описанная архитектура подразумевает следующий шаг в виде пилота и последующего измерения эффекта на реальных сценариях и метриках качества.

Коротко

Пример из текста: «активный клиент» формально считается в SQL, но на практике критерий зависит от цели — маркетинг, финансы или продукт.
Когда ассистент попадает внутрь компании, ошибки чаще связаны не с синтаксисом, а с интерпретацией внутренних правил, терминов и исключений.
Агентные подходы с запуском кода и доступом к БД могут ускорять работу, но повышают цену ошибки, если модель неверно поняла ситуацию.
Отдельно подчёркнута роль разработчиков как «инженеров контекста»: семантические слои, политика как код, поиск и хранение знаний.
Практический вывод статьи: без управляемых источников и ограничений по данным риск приватности и несоответствия требованиям регуляторов растёт.

FAQ

Зачем это важно компаниям, которые используют ИИ-ассистентов для отчетов и генерации SQL: где возникают ошибки и почему «почти верные» ответы опасны?

В тексте объясняется, что модели часто не понимают бизнес-контекст и дают «почти правильные» результаты, которые требуют времени на отладку и проверку.

Что показывает тест Spider 2.0 и как меняется точность преобразования текста в SQL на реальных схемах, когда задача становится сложнее?

Упоминается точность около 59% на реальных схемах и падение до 40% при усложнении задач; чем ближе задача к продакшн-реальности, тем хуже работает модель.

Какие инженерные подходы в статье предлагаются, чтобы приблизить ИИ к бизнес-контексту, и какие элементы архитектуры считаются ключевыми?

Автор описывает RAG над управляемыми источниками, многоуровневую память, структурные ограничения для SQL, а также обратную связь и оценку по реальным KPI.

Почему в тексте отдельно подчёркиваются контролируемые источники и безопасность данных, и как это связано с приватностью и требованиями регуляторов?

Потому что без ограничений доступа и исключения персональных данных преимущества ИИ могут быть нивелированы рисками приватности и несоответствием требованиям регуляторов.

PubMag