Большее число метрик не обязательно улучшает понимание. Многие панели мониторинга содержат несколько показателей одного и того же базового поведения. Метрики лучше выявляют причины, если объединить их в пары конфликтующих показателей: затраты и качество, доля автономно решённых обращений и отношение клиентов, точность и задержка.
По мере перехода ИИ-продукта от пилотного проекта к эксплуатации подходящие пары меняются. На каждом этапе измерения должны соответствовать решениям, которые предстоит принять команде.
Операционный мониторинг и стратегическая оценка служат разным целям. Команды могут отслеживать сотни системных сигналов, но при принятии продуктовых решений опираться лишь на несколько пар.
Основные метрики могут убедительно описывать ситуацию, оставляя при этом важный продуктовый вопрос без ответа.
ИИ-ассистента Klarna публично связывали с большей пропускной способностью, меньшими затратами и оценками удовлетворённости клиентов на уровне специалистов службы поддержки. В следующем году компания решила расширить доступ к поддержке со стороны людей, а её генеральный директор признал, что снижению затрат уделяли слишком много внимания.
Это не означало отказа от ИИ-ассистента или лежащей в его основе технологии. Компания скорректировала баланс между автоматизацией и обслуживанием людьми с учётом опыта эксплуатации продукта. По мере того как автоматизация брала на себя всё больше простых, высокого объема запросов, Klarna требовались операторы, подготовленные к работе со сложными, деликатными случаями.
Определив с самого начала, каких результатов должен достичь продукт, большинство организаций, создающих ИИ-продукты, рано или поздно задаются одним вопросом: действительно ли он работает?
Если ответ неясен, первой реакцией часто становится добавление новых метрик. Три превращаются в 10, а затем 10 — в 30. Панель мониторинга становится подробнее, но понимание команды может не улучшиться.
Проблема не всегда в качестве отдельных показателей, а в связи между ними. Удовлетворённость клиентов, индекс потребительской лояльности, отзывы и доля положительных оценок дают полезные сигналы, но могут отражать схожие изменения общего отношения. Когда они меняются синхронно, то подтверждают, что нечто произошло, но не обязательно объясняют причину.
Поэтому ИИ-командам следует смотреть не только на согласующиеся метрики, но и находить показатели, выявляющие конкурирующие результаты. Такие конфликтующие пары выявляют компромиссы, стоящие за эффективностью продукта, и помогают отслеживать их последствия, улучшая качество решений.
В одном из проектов перед запуском объединённая команда разрабатывала голосового ИИ-агента реального времени для входящих звонков в службу поддержки. Один из самых сложных вопросов касался не выбора модели или оркестрации. Нужно было понять, как организация определит, работает ли продукт, когда клиенты начнут массово им пользоваться.
Первоначальная система включала три показателя:
Доля автономно решённых обращений: как часто ИИ решает вопрос в ходе звонка, не переводя его на человека.
Доля эскалаций: как часто звонок переводится на агента-человека.
Доля успешно решённых вопросов: как часто проблема клиента в итоге решается.
Каждый из показателей был обоснован. Однако вместе они не отвечали на очевидный вопрос: если доля эскалаций растёт, о чём это говорит?
Команда разделила эскалации на восемь подтипов. Затем она добавила показатели прерванных обращений, пути и времени, оценки понимания языка и долю успешно решённых вопросов по типам запросов. В конечном итоге система включала 31 метрику в шести категориях.
Она позволяла подробно описать эскалации, но всё ещё не могла надёжно определить их причину. Большинство метрик представляли собой варианты одного и того же поведения, поэтому менялись синхронно, а не проверяли конкурирующие объяснения.
Панель мониторинга стала наблюдательной, а не диагностической.
Команде был нужен не ещё один уровень детализации. Ей требовались метрики, которые ограничивали бы друг друга.
Мы называем их конфликтующими парами: это два показателя, когда изолированное улучшение одного может ухудшить результат, отражаемый другим. Название описывает сценарий сбоя, возникающий при односторонней оптимизации, а не желаемое состояние.
Если оба показателя остаются на хорошем уровне, продукт, вероятно, работает устойчиво. Если они расходятся, направление расхождения помогает команде выбрать область для изучения.
Что у нас было | Взаимоисключающая пара | Что может выявить пара |
|---|---|---|
Доля эскалаций, разделённая на восемь подтипов | Доля эскалаций ↔ время до эскалации | Немедленная эскалация может указывать на проблему с доверием или подачей информации, а более поздняя — на неспособность системы выполнить задачу. |
Доля автономно решённых обращений и доля успешно решённых вопросов представлены отдельно | Доля автономно решённых обращений ↔ отношение клиента | Означает ли автономное решение, что вопрос успешно решён, или клиент отказался от дальнейших попыток. |
Доля успешно решённых вопросов по типам намерений | Доля успешно решённых вопросов ↔ глубина диалога | Было ли успешное решение эффективным или потребовало изнурительного взаимодействия. |
Чтобы подробнее понять, как выявляется компромисс и что делать с полученными выводами, рассмотрим долю эскалаций и время до эскалации. Команда не узнает, как ведут себя клиенты, пока не поступят реальные звонки, но может заранее сформулировать гипотезы для проверки.
Если число эскалаций растёт, а клиенты покидают ИИ-сервис в первые 30 секунд, команде следует изучить доверие, информирование, тон общения и начало взаимодействия. Если клиенты запрашивают эскалацию после нескольких минут попыток выполнить задачу, вероятнее всего, проблема связана с возможностями системы или охватом рабочих процессов.
Основной показатель эскалаций один и тот же. Но продуктовое решение будет разным.
Полезная пара сама по себе не доказывает причину. Она сужает область расследования и проясняет следующее решение.
Приведённый выше пример Klarna показывает, как этот принцип применяется при взаимодействии затрат и качества обслуживания. Он показывает, как операционная модель с поддержкой ИИ может развиваться по мере того, как компания отслеживает последствия компромиссов и учится на опыте внедрения.
В феврале 2024 года компания сообщила, что за первый месяц её ИИ-ассистент провёл 2,3 миллиона диалогов, выполнил объём работы, эквивалентный труду 700 штатных агентов, и достиг оценок удовлетворённости клиентов на уровне на уровне специалистов службы поддержки. По оценке Klarna, ассистент должен был увеличить прибыль за 2024 год на 40 миллионов долларов США. Это данные самой Klarna, а не результаты независимой оценки.
В мае 2025 года генеральный директор Klarna заявил, что компания уделяла слишком много внимания снижению затрат на обслуживание клиентов, и рассказал о планах расширить доступ к поддержке со стороны людей. Это означало корректировку баланса между автоматизированным обслуживанием и работой людей, а не отказ от ИИ-ассистента или лежащей в его основе технологии.
Публичные данные показывают, почему показатели эффективности следует рассматривать с учётом потребностей разных клиентов и типов взаимодействия. ИИ-система может в среднем работать хорошо, однако в некоторых сложных, деликатных или необычных случаях по-прежнему полезен доступный канал связи с человеком.
Отслеживание обеих сторон этой взаимосвязи помогает компании понять, где автоматизация создаёт ценность, где сохраняется важность поддержки людьми и как следует менять баланс по мере появления новых данных.
Другие конфликтующие пары для ИИ-продуктов могут включать:
Взаимоисключающая пара | Какой риск она помогает выявить |
|---|---|
Точность ответа ↔ задержка ответа | Система технически точна, но работает слишком медленно для данного рабочего процесса. |
Выполнение задач ↔ доля корректировок пользователями | ИИ-процесс выполняет задачи, которые пользователям постоянно приходится переделывать. |
Затраты на взаимодействие ↔ оценённое качество результата | Экономия за счёт ухудшения опыта клиентов или сотрудников. |
Внедрение ↔ время до получения пользы | Рост числа регистраций без соответствующего роста пользы для пользователей. |
Цель не в том, чтобы оба показателя росли бесконечно. Цель — сделать компромисс заметным до того, как односторонняя оптимизация создаст операционную проблему.
Схожая проблема возникла при внедрении системы поддержки игроков в компании, выпускающей мобильные игры. Система обрабатывала массовые обращения, связанные с потерей прогресса, спорами по платежам и доступом к аккаунту.
Показатели эффективности имели значение, поскольку система работала в большом масштабе. Однако поддержка игроков — не просто операционная очередь. Игроки часто обращаются уже раздражёнными, поскольку ранее при использовании продукта что-то пошло не так.
Это исходное состояние меняет интерпретацию данных об удовлетворённости клиентов. Игрок, чья проблема была решена правильно, всё равно может поставить низкую оценку из-за самой потери прогресса. Если рассматривать оценку без контекста, взаимодействие со службой поддержки может получить несправедливо низкую оценку из-за недовольства, возникшего ранее на пути клиента.
Поэтому команде нужно было отделить исходное отношение клиента от эффекта взаимодействия со службой поддержки. Полезнее было спросить не: «Доволен ли игрок?» — а: «Улучшило ли взаимодействие ситуацию по сравнению с исходным состоянием игрока?»
Такое сравнение помогает отделить недовольство продуктом от качества поддержки, если у команды есть надёжный способ измерить и то и другое.
ИИ-продукты меняются, но их метрики часто остаются прежними.
Во время пилотного проекта главный вопрос может заключаться в том, достаточно ли система надёжна, чтобы оправдать дальнейшие инвестиции:
Надёжно ли она выполняет основную задачу?
Достаточно ли пользователи ей доверяют, чтобы продолжать работу?
Как она ведёт себя за пределами наиболее распространённых сценариев?
Можно ли выявлять сбои и безопасно восстанавливаться после них?
Для этих вопросов подходят такие пары:
успешность основной задачи ↔ эффективность в нестандартных случаях;
уровень автоматизации ↔ доля вмешательств человека;
скорость выполнения ↔ уверенность пользователя.
Когда продукт приобретает операционную значимость, вопросы меняются:
Может ли он масштабироваться без снижения качества?
Улучшается ли его экономика по мере использования?
Остаётся ли эффективность стабильной по мере роста внедрения?
Происходит ли вмешательство людей там, где это необходимо?
Соответствующие пары могут измениться следующим образом:
затраты на взаимодействие ↔ оценённое качество результата;
широта внедрения ↔ глубина использования;
уровень автоматизации ↔ подверженность операционным рискам.
Метрики ранних этапов не обязательно ошибочны. Они отвечают на вопросы, важные на более раннем этапе.
Риск возникает при переходе между этапами. Метрики пилотного проекта часто сохраняются, потому что команды умеют по ним отчитываться, а за решение отказаться от них никто не отвечает. Показатели, которые прежде помогали получать знания, могут постепенно превратиться в метрики видимости успеха.
Поэтому у пар должен быть свой жизненный цикл. Командам следует вводить их для конкретного решения, проверять, выявляют ли они по-прежнему существенный компромисс, и отказываться от них при изменении продукта или решения.
ИИ-системам необходимы подробные средства наблюдения, оповещения, контроля качества и оценки. Без этих сигналов безопасная эксплуатация продукта стала бы сложнее. Но операционный мониторинг — не то же самое, что показатели для руководства.
Мониторинг помогает командам обнаруживать инциденты, отслеживать сбои и понимать поведение системы. Метрики для принятия решений помогают руководителям продукта и бизнеса решить, следует ли инвестировать, вмешаться, изменить направление или принять компромисс.
Организация может отслеживать сотни технических и операционных сигналов, выделяя для конкретного продуктового решения лишь две-три конфликтующие пары. Небольшое число показателей на уровне решений упрощает расстановку приоритетов.
Подходящая периодичность анализа зависит от продукта. Для новой или быстро меняющейся системы решения могут пересматриваться еженедельно, а для зрелого продукта — ежемесячно или ежеквартально. Принцип важнее интервала: анализируйте пару достаточно часто, чтобы успеть отреагировать, прежде чем компромисс станет дорогостоящим или небезопасным.
Пара становится полезной, только когда организация согласовала действия на случай ухудшения показателей.
Для этого недостаточно определить критическую границу расхождения. Командам следует учитывать три условия:
Абсолютный сбой: один показатель пересекает недопустимый порог независимо от другого.
Расхождение: один показатель улучшается, а уравновешивающий его — ухудшается.
Совместное ухудшение: оба показателя снижаются, что указывает на более общую проблему продукта или эксплуатации.
Для каждой пары необходимо определить:
ответственного;
конкретное решение, которое она помогает принять;
согласованные пороги или критерии оценки;
порядок расследования;
набор возможных мер.
Без этих элементов организация лишь наблюдает за продуктом, а не управляет им.
Прежде чем добавлять новый показатель, выберите одно важное продуктовое решение и ответьте на следующие вопросы. Запишите ответы, чтобы по итогам анализа согласовать следующий шаг.
1. Какое решение должны помочь нам принять эти метрики?
Сформулируйте точно: решаем ли мы, расширять ли автоматизацию, менять ли модель или улучшать передачу человеку? Сначала сформулируйте решение, а затем выбирайте показатели.
2. Если этот показатель улучшится, что может ухудшиться?
Определите результат, который нужно защитить, и показатель, способный выявить ущерб. Например, сопоставьте затраты на взаимодействие с оценённым качеством результата, чтобы проверить, остаются ли более дешёвые ответы полезными.
3. Что могут скрывать основные показатели?
Сопоставьте оба показателя для одних и тех же пользователей, задач и периода, а затем найдите группы с худшими результатами. Учитывайте и исходные условия: низкая удовлетворённость может отражать недовольство, возникшее ещё до обращения в поддержку.
4. Что побудит нас действовать и кто отвечает за реакцию?
Установите критерии действий на случай, если показатель пересечёт недопустимую границу, один показатель улучшится при ухудшении другого или ухудшатся оба. Согласуйте, кто проведёт расследование, что проверит в первую очередь и когда отчитается о результатах.
5. Соответствует ли эта пара текущему этапу развития продукта?
Решите, оставить, заменить или вывести её из использования. Пилотный проект может быть сосредоточен на надёжности выполнения задач и уверенности пользователей, а действующий сервис — требовать более тщательного контроля затрат и качества. Назначьте дату пересмотра этого решения.
Оценка ИИ-продукта должна не только описывать его эффективность. Она должна выявлять компромиссы, на которые идёт организация, и прояснять следующее решение.