GlowByte:
зачем бизнес-аналитика, если ИИ собирает отчет за две минуты
Языковые модели научились собирать за пару минут то, на что аналитики раньше тратили недели: черновик информационной панели (дашборда), SQL-запрос, пояснение к данным. Из этого у части бизнес-пользователей и руководителей возникает логичный вопрос о том, нужны ли отдельные системы бизнес-аналитики (BI) и команды, которые их разрабатывают и сопровождают, если отчет можно получить из чата. Ответ зависит от того, что считать отчетом и кто отвечает за цифру в нем. О том, где проходит граница между ускорением работы и подменой ее результата, — в экспертном материале Александра Брежнева, руководителя отдела продаж практики Business Intelligence, GlowByte.
За цифру кто-то отвечает
Вопрос «зачем нам бизнес-аналитика, если отчет собирается за две минуты» мы в GlowByte слышим нередко. Бизнес-пользователь получает от языковой модели аккуратную HTML-страницу с графиками и цифрами и делает вывод, что витрины, семантический слой и команда разработки ему больше не нужны. С первой половиной этого рассуждения я согласен. Страницу действительно можно собрать за две минуты. Но страница и отчет, на основании которого принимают решения, — это разные вещи, и разница видна ровно в тот момент, когда цифры не сошлись.
Вопрос «зачем нам бизнес-аналитика, если отчет собирается за две минуты» мы в GlowByte слышим нередко. Бизнес-пользователь получает от языковой модели аккуратную HTML-страницу с графиками и цифрами и делает вывод, что витрины, семантический слой и команда разработки ему больше не нужны. С первой половиной этого рассуждения я согласен. Страницу действительно можно собрать за две минуты. Но страница и отчет, на основании которого принимают решения, — это разные вещи, и разница видна ровно в тот момент, когда цифры не сошлись.
Регламентная, управленческая и надзорная отчетность держится на двух свойствах. Показатель воспроизводим, и у него есть владелец. Если выручка посчитана определенным способом, через месяц при повторном запросе должен получиться тот же результат, а при расхождении можно найти, где именно разошлись расчеты.
Языковая модель устроена иначе, она вероятностная. Один и тот же вопрос, заданный дважды, может дать два разных ответа, и разницу не всегда видно глазом. Для разовой справки это терпимо, для показателя в отчете регулятору или в формуле вознаграждения — нет.
По проектам GlowByte я вижу, что дороже всего обходится момент, когда расхождение находят уже после публикации, и пользователи перестают доверять отчету целиком. В среднем от 3 до 7 показателей на дашборд требуют уточнения во время приемо-сдаточных испытаний.
Сколько стоит ответ
Второе различие экономическое. Открытие уже построенного отчета в системе бизнес-аналитики почти ничего не стоит. Данные уже посчитаны и загружены, и затраты на каждое следующее открытие ничтожны. Каждый запрос к языковой модели оплачивается отдельно, мощностями собственного контура или токенами внешнего сервиса. Если модель каждый понедельник заново выясняет одну и ту же выручку по региону, мы платим за ответ, который у нас уже есть. В сравнении с этим бизнес-аналитика обходится практически бесплатно. В закрытом контуре добавляется очередь. Вычислительные мощности ограничены, и пока одни пользователи спрашивают модель о привычных показателях, другим достается то, где она действительно нужна.
Модель не знает, что такое «выручка» в вашей компании
Качество ответа зависит от того, насколько описаны данные: что означает показатель, из каких источников он собран, кто отвечает за его определение. Эту работу компании годами делали ради бизнес-аналитики: каталог, бизнес-глоссарий, семантический слой, управление данными (Data Governance).
По проектам GlowByte я вижу, что дороже всего обходится момент, когда расхождение находят уже после публикации, и пользователи перестают доверять отчету целиком. В среднем от 3 до 7 показателей на дашборд требуют уточнения во время приемо-сдаточных испытаний.
Сколько стоит ответ
Второе различие экономическое. Открытие уже построенного отчета в системе бизнес-аналитики почти ничего не стоит. Данные уже посчитаны и загружены, и затраты на каждое следующее открытие ничтожны. Каждый запрос к языковой модели оплачивается отдельно, мощностями собственного контура или токенами внешнего сервиса. Если модель каждый понедельник заново выясняет одну и ту же выручку по региону, мы платим за ответ, который у нас уже есть. В сравнении с этим бизнес-аналитика обходится практически бесплатно. В закрытом контуре добавляется очередь. Вычислительные мощности ограничены, и пока одни пользователи спрашивают модель о привычных показателях, другим достается то, где она действительно нужна.
Модель не знает, что такое «выручка» в вашей компании
Качество ответа зависит от того, насколько описаны данные: что означает показатель, из каких источников он собран, кто отвечает за его определение. Эту работу компании годами делали ради бизнес-аналитики: каталог, бизнес-глоссарий, семантический слой, управление данными (Data Governance).
Теперь именно она определяет, насколько правдиво отвечает модель. Без нее получается убедительный, но, увы, неверный ответ. Считаю управление данными тем фундаментом, без которого ни одна модель не даст надежного результата.
Где модель ускоряет работу по-настоящему
В аналитике языковые модели дают большой выигрыш в нескольких задачах: разовый вопрос к данным, исследование незнакомого набора, черновик панели, который аналитик доведет до ума, проверка SQL-запросов. Вероятностный ответ здесь приемлем, потому что дальше его читает человек, понимающий, что он видит.
В GlowByte мы исходим из того, что для регламентной отчетности модель остается инструментом разработчика. Результат проходит ту же верификацию, что и отчет, написанный вручную: проверку логики расчета, сверку с источником, назначение владельца, настройку прав доступа. Самое трудоемкое в этой цепочке как раз проверка, и модель ее не отменяет. На проверку уходит от 20% до 40% времени проекта. Собрать панель за две минуты можно, а принять ее в промышленную эксплуатацию за две минуты не получится.
Что проверить, прежде чем отказываться от бизнес-аналитики или запускать агента
Если в вашей компании звучит тот же вопрос, я бы начал с пяти проверок.
1. Разделите отчеты по цене ошибки. Показатели для регулятора, совета директоров и расчета вознаграждений остаются в проверенном контуре бизнес-аналитики. Для разовых вопросов и исследований допустим вероятностный ответ.
2. Оцените стоимость запроса. Сколько людей будет обращаться к модели каждый день и за какими показателями, и сколько стоит тот же показатель в готовом отчете.
3. Если у показателей нет определений и владельцев, начинать нужно с описания данных.
4. Права пользователя должны действовать и через модель. Он видит только то, что видит сам, поэтому доступ разумнее строить по ролевой модели инструмента бизнес-аналитики и ограничивать чтением.
5. На каждый отчет, собранный с помощью модели, назначьте человека, который подтвердит расчет перед публикацией.
Что будет через полтора года
На горизонте 12−18 месяцев, на мой взгляд, главным вопросом станет автономность агентов. ИИ-агенты, которые сегодня отвечают по запросу, начнут запускаться по событиям: пришел платеж, сработал порог, изменился статус заявки. Агент, действующий без человека, обращается к базам, вызывает программные интерфейсы (API), запускает процессы, и сразу возникают вопросы, на которые у рынка нет устоявшегося ответа.
В аналитике языковые модели дают большой выигрыш в нескольких задачах: разовый вопрос к данным, исследование незнакомого набора, черновик панели, который аналитик доведет до ума, проверка SQL-запросов. Вероятностный ответ здесь приемлем, потому что дальше его читает человек, понимающий, что он видит.
В GlowByte мы исходим из того, что для регламентной отчетности модель остается инструментом разработчика. Результат проходит ту же верификацию, что и отчет, написанный вручную: проверку логики расчета, сверку с источником, назначение владельца, настройку прав доступа. Самое трудоемкое в этой цепочке как раз проверка, и модель ее не отменяет. На проверку уходит от 20% до 40% времени проекта. Собрать панель за две минуты можно, а принять ее в промышленную эксплуатацию за две минуты не получится.
Что проверить, прежде чем отказываться от бизнес-аналитики или запускать агента
Если в вашей компании звучит тот же вопрос, я бы начал с пяти проверок.
1. Разделите отчеты по цене ошибки. Показатели для регулятора, совета директоров и расчета вознаграждений остаются в проверенном контуре бизнес-аналитики. Для разовых вопросов и исследований допустим вероятностный ответ.
2. Оцените стоимость запроса. Сколько людей будет обращаться к модели каждый день и за какими показателями, и сколько стоит тот же показатель в готовом отчете.
3. Если у показателей нет определений и владельцев, начинать нужно с описания данных.
4. Права пользователя должны действовать и через модель. Он видит только то, что видит сам, поэтому доступ разумнее строить по ролевой модели инструмента бизнес-аналитики и ограничивать чтением.
5. На каждый отчет, собранный с помощью модели, назначьте человека, который подтвердит расчет перед публикацией.
Что будет через полтора года
На горизонте 12−18 месяцев, на мой взгляд, главным вопросом станет автономность агентов. ИИ-агенты, которые сегодня отвечают по запросу, начнут запускаться по событиям: пришел платеж, сработал порог, изменился статус заявки. Агент, действующий без человека, обращается к базам, вызывает программные интерфейсы (API), запускает процессы, и сразу возникают вопросы, на которые у рынка нет устоявшегося ответа.
Под чьими правами он действует, кто отвечает за результат, как остановить цепочку действий, если она пошла не так. Идея завести для агента отдельного «двойника» учетных данных кажется заманчивой, но пока непонятно, как его контролировать и ограничивать, и часть таких сценариев еще слишком рискованна для промышленной эксплуатации.
Эти вопросы станут центральными на конференции Fine Day, которую GlowByte в этом году проводит в пятый раз. Она пройдет 23 октября, и мы хотим услышать на ней практиков, у которых уже есть работающие решения, и тех, у кого вопросов пока больше, чем ответов. Историй с измеримым результатом от ИИ в аналитике пока немного, поэтому разговор о границах применимости сейчас нужнее всего.