Привет! Меня зовут Ира Кульбякина, я BI-разработчик в Недвижимости в Авито. Коллеги всё чаще стали приносить нам на доработку дашборды, собранные с ИИ: графики в них выглядят интересно и детализированно, но частая проблема — непонятно, куда смотреть и как вытаскивать основные выводы.
В статье разберём, как такие дашборды собирает агент, и доработаем один из них пошагово. Ещё расскажу, как нейросеть нашла ответ на вопрос заказчика, но не поняла этого, и насколько мы сократили сборку сложных дашбордов, подключив ИИ. Заодно посмотрим, какие правила из этого разбора можно закрепить в скилле.
Содержание
Как и зачем использовать ИИ в построении дашбордов
Прежде чем строить дашборд, нужно понять, на какие вопросы он отвечает и какие показатели будем выводить на него. Потом разобраться в данных: какие таблицы актуальны и как корректно считать метрики. И только после делать запросы к данным и собирать сам дашборд.
Если учитывать ожидание ответов заказчиков, то дольше всего обычно длится сбор требований. Но и техническая часть съедает немало времени: узнать у коллег, какие данные уже есть, собрать датасет, написать SQL и код визуализаций, вручную протянуть фильтры к каждому графику. У новичка построение нетривиального дашборда может растягиваться на месяц.
Мы решили подключить к работе агента — подумали, что наибольшую пользу он принесёт на этапе сбора данных и написания кода.
Сделали MCP-серверы для Redash и хранилища на Trino — через них мы вместе с агентом ищем таблицы, извлекаем данные, пишем SQL и строим графики. Источники и расчёты при этом проверяем сами.
Первые результаты нам нравились: работа шла быстрее. Потом мы попросили агента собрать из всех графиков дашборд, и, кажется, что-то пошло не так…
Почему набор хороших графиков от нейронки ≠ хороший дашборд
Александр Богачёв в книге «Графики, которые убеждают всех» замечает, что люди делают плохие графики не потому, что не стараются, а потому, что пользуются настройками по умолчанию и повторяют то, что видят вокруг.
С ИИ похожая история: обычно модель предлагает самые типичные решения, но такие дашборды редко бывают хорошими.
Есть и другая причина, на мой взгляд, более важная. Модель собирает дашборд по кусочкам, и каждый график для неё — отдельная задача: вот запрос, вот тип визуализации, вот цвета, вот форматирование.
Отдельный график она строит неплохо, но и тут иногда ошибается: смешивает на одной панели разные масштабы, показывает сумму там, где нужно среднее, забывает про прошлый период. Такие ошибки легко найти и поправить по правилам. Сложнее с решениями, которые касаются всего экрана сразу:
какой цвет закреплён за показателем;
с чем сравнивать каждое число;
что главное и куда смотреть первым делом;
чего на экране быть не должно.
Эти решения нельзя принять, глядя на один график. Они зависят от задачи и от того, кто и зачем будет смотреть дашборд.
Эксперимент: пошагово дорабатываем нейродашборд
⚠️ Все данные в дашборде синтетические, имена сотрудников замаскированы.
Мы взяли один из существующих дашбордов. Сначала коллега со своим агентом восстановила по нему ТЗ: что хотелось понять заказчику, какие нужны показатели, какие фильтры.
Потом по этому ТЗ я собрала дашборд уже с другим агентом. Исходную версию он не видел: мы специально разделили эти задачи, чтобы он работал только по требованиям.
Это дашборд с данными по работе кол-центра. Его сотрудники взаимодействуют с покупателями квартир в новостройках в разных городах.
Оператор звонит клиенту, уточняет бюджет и пожелания и подбирает варианты. Если что-то подошло, он во время разговора соединяет клиента с застройщиком-партнёром, то есть переводит его.
Целевой перевод — когда застройщик получил нового заинтересованного покупателя, нецелевой — когда после общения застройщик и покупатель ни о чём не договорились.
ТЗ на дашборд по работе кол-центра. Сейчас на встречах с руководителями команд трудно быстро понять, как отработали за неделю или месяц и почему стало меньше целевых переводов потенциальных клиентов на застройщиков.
Что хотим видеть:
— клиентов, первичных и повторных отдельно;
— задачи и звонки;
— переводы партнёрам-застройщикам: сколько всего, сколько целевых, какая доля нецелевых и как она меняется;
— динамику и сравнение с прошлым периодом;
— весь отдел, команды и отдельных сотрудников, источники трафика и города;
— загрузку: сколько сотрудники разговаривают с клиентами, в какие дни и часы, равномерно ли распределена работа.
Как отображать данные:
Основные цифры — наверху, ниже графики, а подробности по сотрудникам — в таблице.
🧐 Мы отдали это ТЗ агенту, но главный вопрос «Почему стало меньше целевых переводов?» специально не выносили отдельно: агенту предстояло самому понять, что именно это самое важное.
С первой же итерации у агента был доступ к данным и небольшой сохранённый контекст работы над другими визуализациями.
Период в примере — сентябрь, сравниваем с августом.
Посмотрим, что собрал агент на первой итерации. Кажется, всё на месте: семь карточек с главными цифрами, динамика, водопад, источники, города, тепловая карта, загрузка сотрудников и подробная таблица.
Блоки стоят в том порядке, который просили в ТЗ.
Если присмотреться поближе, становятся очевидны мелкие проблемы, например, что одни и те же цвета означают разное. Но главная беда в том, что дашборд не выполняет свою основную задачу: не помогает наглядно видеть данные и принимать решения, опираясь на них.
Дальше мы с агентом дорабатывали дашборд: обсуждали результат и вносили правки. Ниже покажу правила, по которым работала, в деле, а в конце соберу их в список.
Добавляем динамику и делим один большой график на несколько поменьше
Начнём доработку с графика вверху дашборда, который показывает количество задач сотрудников кол-центра, переводы партнёрам и отдельно целевые переводы.
В чём проблема. Заметим, чтопрошлого периода на графиках нет, изменения к нему видны только в KPI-карточках сверху.
На динамике шкалы скрыты, а количество переводов клиентов застройщикам и их доля нарисованы на одной панели.
Как решаем. Три панели со скрытыми шкалами разложим на пять небольших графиков.
— Три из них будут показывать количество: задачи, переводы партнёрам-застройщикам и целевые переводы.
— Два из них будут показывать доли: переводы из задач в целом и нецелевые переводы.
Рядом с текущим периодом пунктиром покажем прошлый. Теперь видно не только как менялся сентябрь, но и как он выглядит на фоне августа.
А неполные недели — первую из шести дней и последнюю из трёх — закрасим серым, иначе конец месяца выглядит как провал.
В результате один большой и сложный график превратился в пять более компактных: их удобнее читать, данные не смешиваются, лучше считывается динамика по сравнению с августом.
Улучшаем тепловую карту и вытаскиваем данные наружу
Тепловая карта показывает сумму звонков выбранных сотрудников по часам и дням недели. Например, в клетке «вторник, 10–11» собраны все звонки по вторникам с 10 до 11 за сентябрь.
В чём проблема. В сентябре пять вторников и пять сред, а остальных дней по четыре. В итоге эти дни выглядят загруженнее просто из-за особенностей месяца.
Как решаем. Выведем среднее число звонков за день недели, а не сумму, чтобы вторник со средой перестали выделяться. И добавим легенду цветовой шкалы, которая показывает, какому диапазону значений соответствует каждый цвет.
Ещё мы видим, что в каждой клетке стоит число. Уберём его: точное значение останется в подсказке при наведении, а на экране достаточно цвета. Тем более у нас уже есть легенда со значениями цветов.
Дорабатываем источники и города
Источники показывают, откуда потенциальные покупатели попадают в работу кол-центра. Например, человек может сам оставить заявку на консультацию или попасть в обзвон после проявленного интереса к новостройкам на Авито.
Для работы с клиентом создаются задачи оператору. «Доля переводов из задач» показывает, какая часть задач завершилась передачей клиента партнёру.
В чём проблема. В карточках видно, что задач стало больше, но по источникам и городам непонятно, где именно они выросли, а где упали. С долей переводов то же самое: текущее значение есть, а изменения не видно.
Как решаем. Превратим источники, откуда клиенты попадают в кол-центр, и города в две таблицы: в каждой строке столбик, значение и изменение к прошлому периоду.
Первой строкой поставим «Всего» с общими показателями.
Унифицируем отображение данных по сотрудникам кол-центра
В чём проблема. Непонятно, какие сотрудники в каких командах.
На графике загрузки много почти пустых строк.
Команды разделены по цветам: одни отмечены зелёным, другие — красным. Некоторые работники выглядят отстающими из-за того, что красный мы привыкли воспринимать как сигнал, что что-то не так, а зелёный — что всё хорошо.
Как решаем. Сотрудников на графике загрузки сразу сгруппируем по командам.
Сотрудников с пятью звонками и меньше, а заодно служебные строки, свернём в «Прочие» внутри каждой команды.
Всех сотрудников покрасим в один цвет — больше никто не выглядит отстающим только потому, что попал в другую команду.
А таблицу, которая находится в самом низу дашборда, соберём иерархией: весь отдел, команда, сотрудник.
Приводим показатели к единому виду
Перемещаемся к водопаду, который показывает, как изменение объёма задач и долей переводов повлияло на количество целевых переводов.
В чём проблема. В карточках вверху дашборда показана доля нецелевых переводов партнёрам, а на других графиках, например, в источниках, городах и на водопаде, — доля целевых. Это одно и то же число, только перевёрнутое, и каждый раз его приходится переворачивать в голове.
Как решаем. На водопаде заменим «долю целевых» на «долю нецелевых», как в карточках. В источниках и городах теперь тоже доля нецелевых.
Вклады покажем целыми числами и под каждым фактором подпишем, насколько он изменился.
После первых правок стало лучше, но экран всё ещё шумный: на нём много цифр и линий, которые отвлекают от главного.
Так что уберём с водопада сетку и подписи осей: над каждым столбиком и так стоит число.
Теперь договоримся о цветах на всём дашборде. Текущий период сделаем синим, прошлый — серым.
Оранжевый совсем уберём с графиков динамики.
Зелёный и красный оставим для изменений, которые можно оценить как улучшение или ухудшение.
А как быть с ростом звонков? Это хорошо или плохо?
Ни то ни другое, это просто объём. Поэтому изменения у задач и звонков серые.
На водопаде итоговые столбики теперь окрашены в серый и синий, как прошлый и текущий период, а вклады — зелёные и красные.
Дорабатываем карточки и делаем то, чего агент не смог, — вытаскиваем главное на первый план
Карточки показывают главные выводы, так что данные на них должны считываться быстро и отражать то, что будет самым важным для заказчика.
В чём проблема. Все карточки выглядят одинаково важными, хотя главный показатель здесь — целевые переводы. Их изменение теряется среди остальных цифр.
Часы разговоров вынесены в отдельную карточку, хотя загрузку уже показывает другой блок.
А водопад, который помогает разобраться в падении целевых, теряется сбоку.
Как решаем. Уберём KPI-карточку часов разговоров, так как загрузку уже показывает отдельный блок.
В карточках под числом оставим одну строку: изменение и прошлое значение.
В карточках выделим «Целевые» и на каждой подпишем период и то, с чем сравниваем.
Вернёмся к ТЗ: заказчик хотел понять, почему стало меньше целевых. Ответ на это даёт водопад, но он стоит сбоку и занимает только половину ширины. То есть ответ на главный вопрос агент нашёл сам, только не понял, что это и есть ответ и что его нужно выделить.
Сразу же вынесем водопад под карточки и растянем на всю ширину.
Ярким на нём останется только самый большой вклад: −63 целевых из-за роста доли нецелевых. Остальное приглушим. И картина сразу складывается: задач стало даже больше, а целевых меньше, потому что выросла доля нецелевых переводов.
Над каждым блоком поставим заголовок-вопрос: «Почему изменилось число целевых переводов?», «Насколько равномерно распределена нагрузка?».
Что получилось
После доработки отдельных графиков посмотрим на дашборд целиком.
Первым на экране стало видно главное: сколько целевых и почему их стало меньше. Каждый график теперь можно читать без пояснений и без пересчёта в уме.
Правила, которым мы следовали, когда дорабатывали дашборд
Для каждого графика
✍️ Сравнение должно быть честным. Одна шкала на график, неполная неделя помечена. Если в месяце пять вторников, а остальных дней по четыре, показываем среднее, а не сумму. Иначе график показывает разницу, которой нет.
✍️ Без сравнения трудно понять, что означает число. 82,3% нецелевых — это много или мало? Рядом с числом должен стоять прошлый период, а у доли — база, из которой она посчитана.
✍️ Убираем то, что повторяет уже показанное. Если над столбиками есть числа, проверяем, нужна ли ещё шкала. Если разницу уже показывает цвет, числа можно оставить в подсказке.
✍️ Всё, что нужно для чтения, подписано. Период и то, с чем сравниваем, — на карточке. Единицы — в заголовке. Серая неполная неделя — в легенде. Если человеку приходится догадываться, он может догадаться неправильно.
Для всего экрана
✍️ Цвет закрепляется за смыслом, а не за графиком. Если синий — это текущий период, он синий везде. Пользователь выучивает код один раз и дальше просто читает. А что бывает, когда каждый график выбирает цвета сам, мы видели на примере команд, раскрашенных в цвета метрик.
✍️ Зелёный и красный — это оценка. Ими говорят «стало лучше» или «стало хуже», и это значение одинаково на всём экране. Поэтому для категорий они не подходят, а у объёмов вроде звонков изменение серое.
✍️ Одна метрика — одна формулировка. Если в карточках доля нецелевых, то и на всех графиках доля нецелевых. Каждый раз, когда приходится переворачивать число в голове, можно ошибиться.
✍️ Порядок экрана — это порядок вопросов. Сначала ключевые цифры, сразу под ними ответ на главный вопрос, дальше детали. И одно яркое пятно на блок, потому что, если выделено всё, значит, не выделено ничего.
В этом эксперименте я передавала агенту правила в диалоге, и мы вместе дорабатывали дашборд. Можно закрепить их в скилле, чтобы использовать те же инструкции в следующих задачах.
В эксперименте мы восстановили ТЗ по готовому дашборду. Запрос заказчика уже был сформулирован, и агенту оставалось найти на него ответ.
В реальной работе часто сначала приходится разбираться в задаче: обсуждать её с заказчиком, изучать процесс и уточнять, какие решения он будет принимать по отчёту.
Правила помогают показать главное, но что считать главным, уже определяет аналитик вместе с заказчиком.
Как используем ИИ в работе и какие результаты получаем
Правила из разбора мы закрепили в скилле, а для контроля качества собрали эвалы. Теперь дашборды мы собираем вместе с агентом: он берёт на себя черновую работу, а за человеком остаются сбор требований, общение с заказчиком, проверка цифр и решения.
Выглядит это так:
Задача. Агент читает задачу и находит похожие дашборды и метрики. Аналитик проверяет, правильно ли ИИ всё понял.
Данные. Агент смотрит, какие источники есть и что в них считается. Аналитик решает, что из этого подходит.
Каркас. Агент предлагает, какие виджеты нужны и в каком порядке. Аналитик утверждает.
Сборка. Агент пишет запросы и собирает графики по нашим правилам. Аналитик проверяет цифры и смотрит, удобно ли читать.
Сдача. Агент проверяет работу и готовит описание для заказчика. С заказчиком общается аналитик.
Всё, что можно проверить по правилам, делает агент. Всё, что требует понимания задачи, остаётся за человеком.
⭐ По нашей оценке, трудозатраты на сложный дашборд сократились примерно с 20 до 8–10 рабочих дней, без учёта ожидания согласований.
Сильнее всего ускорилось то, что раньше делалось руками: поиск данных, датасет, запросы и графики. Теперь агент ищет и пишет, а мы проверяем.
⭐ Например, датасет и расчёт метрик сжались с четырёх-пяти дней до полутора-двух, а сборка дашборда — с дня до часа: фильтры, которые раньше приходилось вручную протягивать к каждому графику, агент подключает сам.
⭐ А там, где решает человек, почти ничего не изменилось. На требования и ТЗ как уходило два-три дня, так и уходит. Понять, что на самом деле нужно заказчику, агент за нас пока не может.
И ещё одно наблюдение: агент хорошо работает и в обратную сторону. Для этой статьи он за несколько минут разобрал готовый дашборд из 17 виджетов, восстановил по нему ТЗ, а заодно заметил, что одни и те же метрики в разных виджетах считаются по-разному. Вручную на это ушло бы полдня.
Ещё больше говорим про дашборды в «Коммуналке аналитиков». Например, устраивали прожарку дашбордов и рассказывали, как мы в Авито повышаем культуру визуализации данных.
Комментарии 0