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

Глава бизнес-аналитики «МТС Банка» рассказывает, что это за решение и с какими проблемами столкнулись при его разработке.

Роман Русаков, директор департамента бизнес-аналитики «МТС Банка» поделился в рамках XII Форума «СТРАТЕГИЯ РОЗНИЧНОГО БИЗНЕСА 2027» практическим кейсом внедрения инхаус-решения по использованию ИИ в аналитике, где пользователь задает вопрос и получает аналитический срез из хранилища. Из выступления присутствующие узнали из чего состоит агент, как его создавали и как его можно внедрить небольшой командой на собственном IT-решении. Также Роман озвучил ключевые проблемы, с которыми столкнулись на этапе внедрения.

Что может агент

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

И тогда встает вопрос: а можно ли пользователю получать данные из хранилища напрямую?

В «МТС Банке» собрали ИИ-агента, который работает по контуру аналитика:

1. Пользователь задает вопрос своими словами, как коллеге;

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

3. Исходя из полученной интерпретации, агент ищет в базе знаний релевантные источники и похожие примеры из датасета;

4. Из полученной информации, агент формирует SQL-запрос, направляет его в хранилище, валидирует полученный результат;

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

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

Важно отметить, что данные всегда подкреплены источниками информации, и их можно сверить вручную с теми агрегатами, на которых были построены отчеты и презентации.

Как создавали агента

Мы начали с того, что научили агента в формате вопрос-ответ возвращать информацию из хранилища. Когда поняли, что с этим функционалом он в целом справляется, перешли к следующему этапу. Тут агент ближе к профилю аналитика – отвечает на вопросы по детализации или о причинах изменения, то есть он может учитывать несколько факторов внутри себя и делать несколько запросов в базу данных, чтобы получить набор метрик, которые необходимы для ответа. Здесь у нас есть определенные достижения, сейчас находимся на стадии финализации данного этапа и после этого сможем приступить к третьему этапу. Это уже продвинутая аналитика, когда вопрос формулируется более комплексно и требует еще большей детализации и аналитических выводов от агента. Важно отметить, что каждый следующий этап основывается на предыдущем.

Коротко о подходе к построению агента без погружения в стек.

Критерием успеха начального этапа является то, что на стартовом датасете агент понимает, что мы от него хотим, умеет формулировать запрос и возвращать результат в соответствии с нашими ожиданиями. Иными словами, агент может отвечать на простые запросы и возвращать данные из хранилища.

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

Цикл нашего проекта

За шесть месяцев нам удалось выйти на рабочий прототип. И это подтверждение того, что ИИ можно сделать полноценной частью аналитики. В начале мы защитили нашу идею как эксперимент и сформировали кросс-функциональную команду. Это четыре человека на старте: двое аналитиков из финансов и два человека из команды CVM – технический лидер и DevOps, те коллеги, у которых есть техническая экспертиза в построении агентных систем. Месяц ушел на разворачивание локальной модели, настройку линка к хранилищу и описание первых датасетов. Затем в течение еще двух месяцев тестировали базовые логики агента, дорабатывали, улучшали качество ответов. Когда поняли, что это работает, перешли к логикам рассуждения, когда агент может запускать несколько циклов внутри себя для того, чтобы анализировать полученную информацию и тем самым улучшать качество и глубину ответов. После того как мы убедились, что агент в большинстве случаев способен отвечать на вопросы пользователей, пришли к ключевым пользователям отчетности и продемонстрировали функционал. После признания проекта успешным, начали расширять датасеты по направлениям и масштабировать агента на бизнес-пользователей.

Ключевой вывод: за шесть месяцев небольшой командой с фокусом на задачу можно реализовать проект такого уровня. По трудозатратам мы выделяли от 20 до 50% своего рабочего времени на эту задачу. Иными словами, результаты подтверждают, что важен не размер команды, а понятный фокус.

Ключевые проблемы

Первое — отсутствие единой версии правды. Одна метрика может находиться в разных витринах, или разные подразделения могут считать ее по-разному. Также показатель может досчитываться на стороне аналитика вручную или же метрика можно считаться на хранилище очень сложно, несколькими скриптами с большим количеством витрин и связей – такие запросы даже человеку зачастую сложно написать, не говоря уже об ИИ-агенте.

Решением данной проблемы является введение каталога данных, когда четко определен владелец. Каталог должен содержать бизнес- и техническое описание структуры данных и связей с другими витринами. Сама структура данных должна быть уложена в удобном для аналитика виде. Хорошим правилом является – не добавлять показатель в агента, пока данные правильно не описаны и не уложены. Это спасает доверие.

Еще одна проблема: даже хороший каталог не поможет, если описание обучающих вопросов для агента формулируют не те люди. Аналитик, особенно если он не в команде бизнеса, зачастую формулирует запрос иначе, чем бизнес-пользователь. Именно примеры бизнес-вопросов для ИИ-агента очень важны, потому что вся работа LLM основывается на словах. Это вероятностная машина и, если вопрос будет неправильно сформулирован, ИИ просто даст похожий, но не совсем нужный ответ. Вторая часть этой проблемы – должно быть вовлечение бизнеса в тестирование ответов. Если мы просто выдадим продукт в релиз, то в большинстве случаев бизнес попробует ИИ ошибется и решит, что инструмент нерабочий, обратная связь в обучении агента вряд ли вернется. В таком случае решение просто останется игрушкой, которой пару раз воспользовались. Поэтому важно развивать и тестировать агента вместе с бизнес-пользователями. Для этого не обязательно нужны руководители: это могут быть линейные сотрудники, которые пользуются информацией от аналитиков на регулярной основе.

Чек-лист пилота

И в конце — ключевые моменты, на что стоит обратить внимание при запуске подобного проекта.

1. Небольшая команда с понятным фокусом на задачу.

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

3. Необходимо одно конкретное направление для MVP проекта с небольшим каталогом витрин, который покрывает это направление.

4. Должен быть владелец данных, ответственный за единую версию правды и аналитический слой данных, который описан в каталоге.

5. Вовлечение бизнеса в процесс тестирования и улучшение метрик ответа.

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