AI-агент для аналитики данных: спросили по-русски, получили цифру и способ расчёта

Как работает AI-агент для аналитики данных: от вопроса до проверяемого ответа

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

1. Находит в глоссарии определения: что такое «активный клиент» и «филиал».
2. Если определений два, задаёт уточняющий вопрос, а не угадывает. Если утверждённого определения нет совсем, не считает и говорит об этом.
3. Пишет запрос к витрине; код проверяет его: только чтение, разрешённые представления, лимиты.
4. Выполняет запрос. Число и таблицу показывает код, а не модель, поэтому цифру не может исказить пересказ модели. Правильность самого запроса так не проверить, для этого есть меры ниже.
5. Пишет пояснение: что посчитано, за какой период, что исключено, насколько свежи данные.

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

Витрина вместо сырых таблиц: на чём агент отвечает

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

Поэтому агент работает над витриной, то есть отдельным управляемым слоем: схема в базе или хранилище (например, PostgreSQL или ClickHouse) с понятными именами и описанием полей. Данные попадают туда из 1С, CRM и других систем штатным обменом, как в сценарии агента с доступом к 1С, а не чтением чужой базы напрямую.

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

Если витрины нет, это главный объём работ, и мы говорим об этом на аудите: собираем минимальный слой под несколько десятков реальных вопросов или откладываем проект, пока учёт не наведён в порядок. Что проверять в данных — в статье о подготовке данных перед внедрением ИИ.

Глоссарий метрик: что такое «выручка», «заказ» и «активный клиент»

Очень часто спор «цифра неверна» — это спор об определениях, а не об арифметике. Модель определения не знает и выбирает самое вероятное, поэтому метрика записывается один раз и становится источником правды для агента и для людей.

Запись в глоссарии: название, синонимы («оборот», «продажи»), определение словами, выражение для расчёта, владелец, дата утверждения. Владелец — человек из бизнеса, например финансовый директор. Мы помогаем собрать список, а что считать «выручкой», решает компания.

Правило агента: нет утверждённого определения — нет ответа. Он скажет, что метрики в глоссарии нет, предложит близкие и может набросать черновик на утверждение, но числа по нему не выдаст.

Агент не решает, что такое выручка. Он применяет определение, которое компания уже утвердила, и называет его в каждом ответе.

Запросы к базе на русском языке: чем ограничен агент

Вопрос на русском превращается в SQL-запрос (технически это называют text-to-SQL), а это код, который может нагрузить базу, вытащить лишнее или изменить данные. Поэтому ограничения стоят не в просьбе к модели «пиши аккуратно», а в коде и правах базы, которые модель обойти не может.

• Роль только на чтение. Отдельная учётная запись без прав на изменение и удаление, с доступом только к схеме витрины: принцип минимальных прав, о котором мы пишем и в материале о безопасности AI-агентов.
• Проверка запроса до выполнения. Код разбирает запрос и пропускает один оператор чтения по разрешённым представлениям; остальное отклоняет.
• Лимиты. Время выполнения и число строк ограничены, по возможности средствами самой СУБД. Сработал лимит — ответ помечен как неполная выборка, а не выдан за итог.
• Закрытые поля. ФИО, телефоны, e-mail, паспортные и платёжные данные в представления для агента не входят; доступ открывается отдельным решением для роли и пишется в журнал.
• Права спрашивающего. Агент не должен знать больше, чем спрашивающий: менеджер филиала получает цифры своего филиала. Для этого нужны политики доступа на уровне строк, если СУБД их умеет, или представления по ролям.
• Журнал. Кто спросил, какой запрос выполнен, какая версия глоссария и данных. Без него разбор спорной цифры превращается в гадание.

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

Как ошибается ИИ-аналитик и чем это ловится

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

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

Проверка перед запуском: вопросы с известными ответами

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

• простые вопросы и сравнения периодов: «к прошлому году», «нарастающим итогом»;
• двусмысленные вопросы, где правильный ответ — уточнение;
• метрика без определения в глоссарии: правильный ответ — отказ;
• недопустимые вопросы (персональные данные, чужой филиал, просьба изменить данные): правильный ответ — отказ.

Допуски и пороги приёмки (какое расхождение считать совпадением, сколько вопросов должно пройти) фиксируем в договоре до начала работ. Набор прогоняется после каждой смены модели, глоссария или витрины; после запуска ключевые цифры сверяют с существующим отчётом, а найденные расхождения пополняют набор.

ИИ для анализа данных и BI: как они дополняют друг друга

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

Агент закрывает «длинный хвост» вопросов, под которые дашборд не строили. Если в компании уже есть BI-инструмент с моделью данных (например, DataLens, Superset или Metabase), агент может опираться на те же определения; что возможно, зависит от инструмента, смотрим на аудите.

Данные остаются у вас: облачная модель или контур компании

Что уходит из компании, зависит от схемы. В типовой облачной схеме наружу идут вопрос, описание схемы и глоссарий, иногда списки значений справочников (например, названия филиалов), чтобы модель верно составила условие. Строки данных можно не отправлять совсем, потому что число и таблицу показывает код. Если пояснению нужны результаты, передаётся только согласованный агрегат. Поля с персональными данными закрыты в витрине и до модели не доходят.

Если политика компании не допускает и этого, модель разворачивается в вашем контуре: установка on-premise от 2 500 000 ₽, по проекту; оборудование и расход на модель — отдельной строкой. Оговорка: на момент подготовки материала небольшие локальные модели могут хуже писать запросы на сложной схеме, поэтому проверяем это на вашем тестовом наборе. Вопросы 152-ФЗ лежат на операторе данных, то есть на вашей компании; что выяснить — в статье об ИИ и персональных данных.

С чего начать и что это стоит

Начинаем с экспресс-аудита: 50 000 ₽, 5-7 рабочих дней, сумма засчитывается в проект. Смотрим источники и наличие витрины, собираем реальные вопросы, отмечаем спорные метрики, называем объём подготовки данных. Отказ от проекта — тоже результат аудита.

Пилот на одном процессе, то есть на одной предметной области (например, вопросы руководителя по продажам или складу), — от 200 000 ₽, 3-4 недели: глоссарий на выбранные метрики, доступ только на чтение, агент, интерфейс и проверочный набор. Построение витрины с нуля в этот объём может не уложиться: скажем на аудите. Сопровождение — от 40 000 ₽/мес: определения и структура учёта меняются, и без обновления глоссария агент отвечает по старым. Расход на модель зависит от размера схемы и числа вопросов, см. про расход на модель. Общий порядок работ — на странице разработки AI-агентов.

Когда агент для аналитики не нужен

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

Больше таких случаев разобрано в статье «Когда AI-агент не нужен».