Сегодня многие компании внедряют ИИ‑ассистентов, которые автоматически пишут SQL‑запросы и помогают менеджерам готовить отчеты. На первый взгляд они отлично справляются с цифрами и синтаксисом, но теряются, когда дело доходит до бизнес-контекста. Почему? Потому что бизнес живет не только данными, но и контекстом: историей компании, внутренними правилами, неформальными договоренностями, культурой. 

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

Ограничения ИИ в корпоративном контексте

Современные модели уверенно работают с синтаксисом, кое-как справляются с семантикой и почти всегда проваливаются в бизнес-контексте. Это критично, потому что ценность компании определяется деталями: как вы классифицируете активных клиентов, какие скидки действуют по расписанию, какие SKU переименовали после сделки и почему выручка для финансового и для продаж означает разные вещи.

Да, модели проходят тесты и генерируют SQL-запросы, которые выглядят корректно. Но, стоит загнать их за корпоративный брандмауэр, как они тут же ломаются. Тесты Spider 2.0 показывают, что точность преобразования естественного языка в SQL на реальных схемах держится около 59%, а при усложнении задачи падает до 40%. Это не игрушечные датасеты, а структуры, похожие на ваши продакшн-базы. Чем ближе к реальному бизнесу, тем хуже работает ИИ.

Если вы пишете корпоративное ПО, вас это не удивит. Проблема не в том, что ИИ умеет генерировать код. Проблема в том, что ему нельзя доверять на ваших данных и правилах. Почти правильный результат превращается в лишние часы на отладку и фактчекинг. Модель не понимает ваши процессы, и именно это делает ее слабым звеном.

Почему бизнес-контекст ломает ИИ

Большие модели – это по сути алгоритмы обработки паттернов, натренированные на открытых текстах. Но, бизнес-логика в публичном интернете не лежит. Она спрятана в Jira‑тикетах, презентациях, внутренних базах и схемах, которые отражают старые решения и корпоративную память. Даже модель данных сопротивляется: тысячи столбцов, переименованные поля, неполные измерения, терминология, которая меняется после каждой реорганизации.

Чем ближе задача к реальным процессам (многошаговые запросы, джойны между незнакомыми схемами, разные SQL‑диалекты, трансформации в DBT), тем ниже точность. Параллельно компании идут к агентным моделям, которые умеют запускать код и обращаться к базам. Но это только увеличивает риск, если модель неправильно интерпретирует ситуацию.

Например, расчет активных клиентов. Формально это SQL-задача. Но на практике выясняется, что для маркетинга активен клиент, который заходил за 30 дней: для финансов – это тот, кто платил; а для продакта – тот, кто пользовался ключевой фичей. Модель не может выбрать правильный вариант, потому что правильный зависит от цели, а цель – это управленческое решение.

Как сократить разрыв между ИИ и бизнес-контекстом

Хорошая новость заключается в том, что нам не нужен философский прорыв. Все упирается в память, управление, обратную связь и проверку. Проблема не в количестве параметров, а в том, что модели не умеют хранить и использовать корпоративную память. Если мы дадим им структурированные механизмы отслеживания событий и извлечения ключевых определений, доверие к результатам возрастет.

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

Что нужно сделать:

1. Чтобы ИИ работал в реальном бизнес‑контексте, ему нужен доступ к вашим данным, но не к каким угодно, а к управляемым и безопасным источникам. Используйте RAG, чтобы подгружать DDL, схемы, модели DBT и выборки строк. Для текст‑SQL трансформаций добавляйте описания таблиц, информацию о происхождении данных и ключи соединений. Поиск должен идти по каталогам, хранилищам метрик и линейным. графам, иначе модель будет просто угадывать. При этом важно понимать, что речь идет только о контролируемых источниках, где исключена работа с персональными данными и обеспечена защита корпоративной информации. Без этого риски приватности и несоответствия требованиям регуляторов сведут на нет все преимущества ИИ.

2. Добавить многоуровневую память. Большинство приложений ИИ страдают амнезией. Нужны рабочая, долговременная и эпизодическая виды памяти. База данных становится сердцем этой архитектуры: хранит векторные представления, метаданные, логи событий. Это переводит модель с уровня паттерн‑матчинга на уровень контекста.

3. Убрать неоднозначность через структуру. Свободный текст порождает ошибки. Для SQL используйте AST или ограниченный диалект, который проверяется уровнем исполнения. Привязывайте запросы к семантическому слою и используйте вызовы функций: get_metric(‘active_users’, date_range=’Q2′). Чем больше строительных блоков, тем меньше галлюцинаций.

4. Встроить процесс утверждения. Эксперты не должны тратить целый день на правки запятых. Система должна подсвечивать рискованные джойны, показывать дифф строк, собирать обратную связь и возвращать ее в память. Так контекст будет обучаться прямо в рабочем процессе.

5. Оценивать по реальным KPI. Важно то, помогла ли система закрыть квартал или сгенерировала канонические запросы на доход. Проверяйте контроль доступа, корректность метрик, устойчивость к многоэтапным задачам. Оценки должны быть ежедневными и максимально приближенными к реальным сценариям.

Проблему нельзя устранить полностью, но можно системно сократить разрыв. Для этого нужны инженерные решения и люди, которые будут обучать модели контексту бизнеса.

Люди и машины

Как бы ни усложнялись модели, без людей они не будут работать надежно. Это не недостаток, а преимущество.

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

Меняется и роль разработчиков. Они становятся инженерами контекста: проектируют семантические слои, пишут политику как код, создают механизмы поиска и хранения данных, поддерживают циклы обратной связи. Именно это делает их незаменимыми. Чем больше автоматизации, тем выше ценность специалиста, который понимает и машину, и бизнес.

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

Такой ИИ будет меньше похож на автозаполнитель и больше на коллегу, который работает в вашей среде. Не потому, что модель обрела здравый смысл, а потому, что архитектура вокруг нее обеспечивает этот уровень.

Заключение

Если модель не справляется с бизнес‑контекстом, решение не в другой модели, а в другой архитектуре. Архитектуре, которая сочетает сильные стороны человеческого интеллекта и машинного.

Размещайте облачную инфраструктуру и масштабируйте сервисы с надежным облачным провайдером Beget.
Эксклюзивно для читателей Хабра мы даем бонус 10% при первом пополнении.