Пилот дата-агента: шаблон брифа, приёмка по 50 вопросам и пять метрик, по которым его закрывают

Первый месяц после запуска ИИ-инструмента: обучение забито, все обмениваются приёмами промптинга, подразделения приносят список идей на два листа. Через три месяца инструментом регулярно пользуется группа энтузиастов. Руководство видело десяток демо, но не может назвать ни один процесс, который стал быстрее.

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

Шаг 1. Выбрать сценарий, который можно проверить
Вендор советует брать частую повторяющуюся работу с ясным периметром данных. Согласны, но добавим четыре критерия, которые у нас отсеивают большинство предложений с брейншторма.

Частота. Задача случается минимум раз в неделю. Квартальный процесс не даст достаточно наблюдений, чтобы понять, агент работает или один раз повезло.

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

Граница данных. Один-два источника. Формулировка «пусть посмотрит все наши данные» — это не сценарий.

Наличие эталона. Самый жёсткий фильтр. Должен существовать способ узнать правильный ответ независимо от агента. Если правильный ответ не может посчитать никто, приёмку провести нечем, и пилот закончится обсуждением ощущений.

Из десятка идей после этих четырёх фильтров обычно остаётся одна-две. Это нормальный результат брейншторма, а не провал.

Шаг 2. Превратить запрос в бриф
FanRuan приводит хороший пример. Руководитель операций говорит: «Хочу быстрее видеть картину по бизнесу каждое утро». С этой фразой агент не сделает ничего.

Мы формализовали перевод такого запроса в таблицу. Пока в ней есть пустые клетки, пилот не начинается.

Последняя строка выглядит мелочью, а на практике решает, будут агенту доверять или нет. Мы про это писали в прошлой статье: ответ «продажи составили ноль» опаснее ответа «данные за вчера не загрузились».

Шаг 3. Подготовить данные ровно под этот сценарий
Здесь коротко, потому что подробно разбирали во второй статье. Главное правило: порядок наводим не во всей компании, а в границах брифа. Проверяем по пяти вопросам:

• Как считается каждая метрика из брифа?
• Откуда берётся цифра?
• Кто имеет право её видеть?
• Когда данные обновляются?
• Понимает ли модель бизнес-термины, которыми пользуются получатели?

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

Шаг 4. Провести приёмку по контрольным вопросам
Бизнес-пользователи оценивают ИИ-агента по трём параметрам: точность ответа, понятность логики и практическая ценность для задачи. Но как проверить это до релиза, а не на боевых данных?

У нас для этого есть чёткая процедура. На входе — 30−50 реальных вопросов с совещаний за последний квартал. По каждому из них аналитик вручную готовит эталонный ответ. Это занимает 2−4 дня и оказывается самой полезной инвестицией в пилоте: набор кейсов остаётся у компании и переиспользуется при каждом обновлении модели данных.

Прогоняем агента и раскладываем ответы на три категории:

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

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

Порог приёмки фиксируется в брифе заранее. Договариваться о нём после прогона поздно: цифры уже видны, и обсуждение превращается в торг.

Шаг 5. Расставить точки проверки человеком
FanRuan говорит: «Определите, что уходит автоматически, а что требует проверки». Мы в GlowByte раскладываем это по двум осям — цена ошибки и обратимость. Получается четыре сценария:

• Дёшево и обратимо, например внутренняя сводка. Отдаём агенту полностью.
• Дорого, но обратимо, например алерт, который поднимает смену на проверку линии. Автоматизируем, но с обязательной пометкой источника и времени данных — чтобы получатель мог быстро перепроверить.
• Дёшево, но необратимо, например письмо контрагенту. Только через человека.
• Дорого и необратимо — любое действие с деньгами или обязательствами. Агент готовит проект, решение принимает человек, факт согласования пишется в лог.

Отдельно фиксируем процедуру остановки. Кто и как выключает сценарий, если он начал выдавать ерунду, и как получатели узнают, что рассылка приостановлена. В пилоте это обычно один человек и одна кнопка, но договориться надо заранее, а не в момент инцидента.

Шаг 6. Мерить эксплуатацию, а не восторг на демо
Через два месяца после запуска решение об оставлении сценария принимается по цифрам. Мы в GlowByte смотрим на пять.

1. Доля принятых ответов: сколько сводок получатели использовали без ручной перепроверки.
2. Освободившееся время: сколько часов в неделю реально ушло из процесса. Считается по журналу, а не по опросу.
3. Время до реакции: сколько проходит между отклонением в данных и постановкой задачи ответственному. Обычно именно ради этой метрики сценарий и делают.
4. Число новых исключений в неделю: случаи, которые агент не умеет обрабатывать. Кривая должна идти вниз. Плоская кривая означает, что сценарий выбран слишком широко.
5. Доля отказов: должна быть заметной, но не растущей. Рост означает, что в данных что-то поехало.

Условие закрытия сценария тоже стоит записать заранее. Если через два месяца освободившееся время меньше времени на поддержку сценария, его закрывают. Это дисциплинирует выбор первого кандидата лучше любых уговоров.

Без названного владельца сценарий глохнет после первой поставки: требования, данные и правила меняются, а править их некому.

Владелец — это человек из бизнеса, ближайший к процессу. Сводкой владеет операционный блок, алертом по остаткам — руководитель цепочки поставок, управленческим отчётом — подразделение отчётности. Не И Т и не внешний интегратор.

В зоне владельца: постановка задачи, пороги отклонений, критерии приёмки, сбор обратной связи, решение расширять, переделывать или закрывать. В зоне ИТ: платформа, данные, права, безопасность, мониторинг, разбор технических инцидентов.

Как FanRuan рисует то же разделение: бизнес приносит вопрос и ждёт результата, ИТ отвечает за данные, доступы и безопасность, владелец сценария держит постановку, приёмку и обратную связь. Схема взята из оригинала статьи.

Проверить, есть ли владелец, можно одним вопросом: «Кто примет решение, если через месяц выяснится, что порог отклонения выбран неправильно?» Если в ответ звучит «ну, обсудим», владельца нет.

Масштабирование — это не двадцать пилотов одновременно. Это надёжный способ выбрать сценарий, подготовить агента, доказать ценность и повторить.

Полный цикл в версии вендора: слева — один управляемый пилот, в центре — этапы, справа — переиспользуемые сценарии для других подразделений, снизу — governance сквозной полосой. Этапов у FanRuan пять, у нас шесть: мы разделили «Validate with Business» на приёмку по контрольным вопросам и расстановку точек проверки человеком, потому что на практике это две разные работы с разными участниками. Схема взята из оригинала статьи.

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

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

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

Мы в GlowByte внедряем FineBI и мигрируем на него с других платформ, попутно приводя в порядок модель данных, метрики и права доступа. Если у вас есть задача-кандидат на первый сценарий, напишите нам на bi@glowbyteconsulting.com: пройдём по четырём критериям из первого шага и скажем, какой из вариантов готов к пилоту, а какой требует работы с хранилищем.