BI-команда Авито собирает дашборды с агентом за 8–10 дней вместо 20

Коллеги всё чаще приносят BI-разработчикам дашборды, собранные с помощью ИИ. Графиков много, они детализированы, но непонятно, куда смотреть и какой вывод забрать. Ира Кульбякина из команды Недвижимости Авито разобрала, почему так выходит, и показала на примере, как такой дашборд доводят до рабочего состояния. По словам авторов, с агентом сложный дашборд собирается за 8–10 дней вместо 20.

Где агент помогает, а где нет

Обычно работа над дашбордом идёт так. Сначала собирают требования, потом разбираются в данных: какие таблицы актуальны и как считать метрики. Затем пишут SQL и код визуализаций и вручную протягивают фильтры к каждому графику. Эти технические шаги агент берёт на себя. В Авито сделали MCP-серверы для Redash и хранилища на Trino. Через них агент ищет таблицы, вытаскивает данные, пишет запросы и строит графики. Источники и расчёты люди всё равно проверяют сами.

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

Эксперимент: дашборд кол-центра

Коллега восстановила техзадание по существующему дашборду кол-центра, который переводит покупателей новостроек к застройщикам. Затем автор собрала новый дашборд с другим агентом, который исходной версии не видел. Главный вопрос заказчика («Почему стало меньше целевых переводов?») в ТЗ отдельно не выделили, чтобы агент сам понял, что он главный.

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

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

Главное агент не сделал сам. Ответ на вопрос заказчика давал водопад, который показывает вклад каждого фактора в изменение целевых переводов. Агент построил его, но поставил сбоку на половину ширины и не понял, что это и есть ответ. Людям пришлось вынести водопад под карточки на всю ширину и подсветить единственный крупный вклад: −63 целевых из-за роста доли нецелевых переводов. Задач стало даже больше, а целевых меньше именно потому, что выросла доля нецелевых.

Правила, которые стоит закрепить

Автор собрала выводы в список, который можно превратить в скилл для агента:

• Сравнение должно быть честным: одна шкала на график, неполные периоды помечены, среднее вместо суммы, если в периодах разное число дней.
• Число без базы сравнения ничего не значит. Рядом с 82,3% нужен прошлый период.
• Не дублировать показанное: если над столбиками стоят числа, шкала не нужна.
• Всё для чтения подписано: период, база сравнения, единицы.
• Цвет закреплён за смыслом на всём экране. Зелёный и красный только для оценки «лучше/хуже», а рост объёма звонков нейтрален и серый.

Что из этого следует

За ограничения стоит сказать отдельно. Вся статья построена на одном дашборде с синтетическими данными. Окончательные цифры экономии времени в доступном фрагменте текста не раскрыты, поэтому «8–10 дней вместо 20» нужно воспринимать как заявление команды, а не как независимый замер. Источники и расчёты авторы всё равно проверяют вручную.

Практический вывод простой. Агенту можно отдавать поиск данных, SQL и рутину с фильтрами, но приоритизацию и визуальную иерархию лучше формулировать явно. Если оформить правила дашборда как скилл, агент с первой итерации будет делать меньше типовых ошибок. А вопрос «что здесь главное и почему» по-прежнему должен задавать человек.