Авито сделал бота для разбора метрик: ИИ пишет текст, а считает обычный код

Каждое утро аналитик открывает финансовый дашборд, проверяет, обновились ли данные, смотрит на выручку и, если цифра дёрнулась, начинает выяснять, где и почему. Полчаса в день, никакой магии, но пропустить эти проверки нельзя. BI-разработчики Авито Айгуль Ахметова и Валерия Смирнова решили отдать эту рутину боту. Получился Big10 Pulse в корпоративном Mattermost. Самый интересный вывод у них не про то, что можно поручить языковой модели, а про то, чего поручать нельзя.

Почему одного алерта мало

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

Поэтому универсальный чат с отчётом делать не стали. Задачу сузили до первого разбора: проверить готовность данных, отделить сигнал от шума, разложить изменение на факторы и подсказать, куда смотреть дальше.

Что делает код, а что модель

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

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

Потом бот раскладывает общую разницу по направлениям бизнеса и типам выручки. Он ранжирует их не по самому большому проценту, а по вкладу. Пример: общий минус 100 условных единиц складывается из минус 80, минус 30 и плюс 10, и ясно, с какого участка начинать. Маленькая категория может вырасти на десятки процентов и ничего не изменить в итоге.

Модель включается только в самом конце. Она получает короткий набор готовых фактов: относительные изменения посчитаны заранее, абсолютные значения подставляет Python. Весь отчёт ей не передают, потому что чем больше случайных связей она видит, тем проще ей придумать правдоподобное объяснение. Формула команды: чем меньше свободы у модели, тем полезнее ответ.

Проверка текста перед отправкой

Даже на корректных входных данных модель любит усиливать вывод. Расчёт говорит: основной отрицательный вклад дало направление A. В тексте появляется: «выручка упала из-за технической ошибки в направлении A». Про ошибку модель ничего не знала, но звучит уверенно.

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

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

Что ещё пришлось решать

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

Результат и ограничения

На тестировании было 9 подписчиков, и команда оценила экономию примерно в 99 человеко-часов в месяц (9 человек × 30 минут × 22 рабочих дня). Позже ещё 55 пользователей подписались сами. Это расчётная оценка, а не хронометраж. Показательнее смена сценария: вместо 30–60 минут на проверку отчёта человек тратит одну-две минуты на чтение готового разбора.

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

Что взять на вооружение

Если строите похожего ИИ-помощника для метрик, начните с границы ответственности. Готовность данных, пороги, сезонность и декомпозиция вклада должны жить в детерминированном коде. Модели отдайте формулировку по маленькому набору проверенных фактов. Валидатору дайте те же факты, что и генератору, и учитывайте права доступа с первого дня. Самым важным решением команды оказалось не подключить языковую модель, а вовремя её остановить.