ROI AI agent: как измерять без фантазийных цифр
Модель измерения ROI AI agent: baselines, сторона costs с LLM usage и временем review, метрики pilot и правила решения expand-or-kill.
Northstar
Northstar - студия AI agent systems. Алекс ведёт engineering и продукт, Джордан - operations и fit процессов. Делаем production-агентов в tools, которыми команда уже пользуется.
Alex Morgan · LinkedIn · Northstar
Прямой ответ
Измеряйте ROI AI agent как ценность минус полная стоимость: сэкономленное время по полным ставкам плюс снижение ошибок против стоимости build, retainer, LLM usage, времени human review и стоимости инцидентов. Предусловие - baseline, снятый до сборки: cycle time, exception rate, rework, объём. Если вы не можете измерить workflow сегодня, вы не можете заявлять ROI завтра.
Сначала baseline, всегда
Самый частый провал - начать сборку до фиксации того, как выглядело «до». Недели-двух лёгкого logging достаточно; направленные цифры лучше, чем никаких.
| Baseline-метрика | Как снять дёшево | Почему это важно потом |
|---|---|---|
| Время на кейс | Замерьте 20-30 реальных кейсов от начала до конца | Ядро заявления об экономии |
| Объём | Посчитайте кейсы в неделю из исходной системы | Превращает экономию на кейс в итоги |
| Handoffs | Посчитайте людей и tools, которых касается каждый кейс | Показывает, где agent убирает ожидание, а не только работу |
| Error и rework rate | Помечайте переделанные кейсы две недели | Снижение ошибок часто стоит больше, чем сэкономленное время |
| Стоимость плохого действия | Согласуйте число на тип провала | Закладывает риск в ROI, а не только upside |
Заморозьте baseline в датированном общем документе; через полгода честно никто не вспомнит.
Формула ROI, которая выдерживает проверку
Ценность за период:
- Сэкономленное время = (baseline-время на кейс - новое человеческое время на кейс, включая время review) x объём x полная часовая ставка
- Снижение ошибок = (baseline error rate - новый error rate) x объём x стоимость ошибки
- Ценность cycle time = только там, где скорость доказуемо двигает результат, например ответ на leads; иначе не включайте
Стоимость за период:
- Амортизированная стоимость build (размажьте pilot на 12-24 месяца, а не на бесконечность)
- Retainer или внутреннее время на поддержку: monitoring, обновление prompts, поддержка evals
- LLM usage отдельной строкой: стоимость токенов на реальном объёме, на ваших собственных API keys, чтобы она оставалась видимой
- Время human review на gates - самая часто скрываемая статья, потому что минуты approvals - это реальные минуты
- Время обработки exceptions для очереди, которую agent эскалирует
- Ожидаемая стоимость инцидентов: малая вероятность на большую цену всё равно принадлежит модели
ROI = (ценность - стоимость) / стоимость. Если он становится положительным только после добавления мягкой строки вроде «счастье сотрудников» - он отрицательный.
Метрики pilot, которые важны
Отслеживайте небольшой набор еженедельно. Больше дашбордов не значит больше правды.
| Метрика | Определение | Здоровое направление |
|---|---|---|
| Safe auto-completion rate | Кейсы, завершённые без прикосновения человека и без поздней коррекции | Растёт по мере расширения gates |
| Human override rate | Approvals, где reviewer изменил результат | Падает к низким единицам процентов на тип кейса |
| Размер exception queue | Кейсы, эскалированные людям, и их старение | Стабилен или падает при постоянном объёме |
| Time to first response | Для клиентских потоков | Падает сразу и остаётся низким |
| Rework rate | Кейсы agent, переоткрытые или исправленные позже | На уровне человеческого baseline или ниже |
| Стоимость завершённого кейса | Все costs выше, делённые на завершённые кейсы | Падает ниже baseline-стоимости человека |
Следите за auto-completion против override rate: высокий auto-completion при высоких overrides - это не автоматизация; это человек, делающий работу с лишними шагами.
Паттерны ложного ROI
- Vanity-активность. Sessions, сообщения и «взаимодействия agent» измеряют usage, а не ценность. Десять тысяч чатов, которые ничего не решают, - это строка затрат.
- Сэкономленные часы без baseline. Если workflow никто не замерял до, «экономит 30 часов в неделю» - это догадка в костюме.
- Revenue-множители. Держите заявления о выручке за пределами модели, если причинная связь не прямая и не измерена; дисциплина атрибуции - редкость.
- Расход токенов как прогресс. Растущий API-счёт доказывает активность, а не результаты. Смотрите вместо этого на стоимость завершённого кейса.
Измерительная сантехника
Цифры ROI хороши ровно настолько, насколько хороши traces за ними; стройте pilot измеримым:
- Logging на каждом запуске: входы, действия, результат, вмешательство человека - источник override и rework rates.
- Eval-сет: 30-50 репрезентативных кейсов с ожидаемыми выходами, прогоняемый перед каждым изменением prompt или модели; он ловит дрейф раньше месячных цифр и одновременно служит acceptance test на go-live.
- Телеметрия gates: approvals и отклонения, размеченные по типу кейса, показывающие, какие срезы готовы к более широкой автономии.
- Еженедельный one-pager: метрики pilot против baseline, за которым закреплён владелец workflow. Если измерение живёт только в дашборде вендора - вы отдали правду на аутсорс.
Операции после pilot разобраны в статье измерение AI agent ops, токенная сторона - в статье LLM costs и выбор модели.
Правила решения
Согласуйте пороги письменно до старта pilot, чтобы решение expand-or-kill было механическим, а не политическим:
- Расширяйте, когда метрики бьют baseline два ревью-периода подряд без роста severity инцидентов: сначала расширьте gates на лучших типах кейсов, затем добавьте объём, затем следующий workflow.
- Держите и настраивайте, когда ценность положительная, но override или exception rates застряли: сначала чините верхние категории exceptions.
- Убивайте или пересматривайте scope, когда стоимость завершённого кейса остаётся выше человеческого baseline после честной настройки, или когда один класс инцидентов оказывается слишком дорогим для доступного gating. Убить pilot по свидетельствам - дешёвый исход, а не провал.
Как помогает Northstar
Pilots Northstar определяют acceptance test и набор метрик заранее, с logging с первого дня, чтобы решение expand-or-kill работало на ваших цифрах, а не на наших слайдах. Смотрите solutions.
FAQ
Нет. Недельная выборка замеренных кейсов и размеченный счётчик ошибок лучше квартала планирования инструментирования. Направленных baselines достаточно для честных решений expand-or-kill; чего нельзя сделать - восстановить baseline по памяти после запуска, потому что память всегда льстит проекту.