AI-агент после запуска почти никогда не падает — он тихо портится: продолжает отвечать связно и уверенно, пока условия, документы и вопросы клиентов уходят от того, на чём его настраивали. Деньги при этом теряются незаметно — на неверно названной цене, на клиенте, который ушёл без ответа, на обращении, переданном человеку и забытом. Мониторинг AI-агента после запуска — это регулярная проверка содержания его ответов и результата процесса, а не только доступности сервиса. Ниже — что смотреть у агента после запуска, какие сигналы означают, что качество поехало, и как устроить это без отдельного отдела контроля.
Почему сбой бывает тихим
Классический отказ системы заметен: она не отвечает, сыплет ошибками, падает. Под это построен весь привычный мониторинг инфраструктуры: графики нагрузки, ошибок и времени ответа, и для сервиса с агентом они тоже нужны. Но с агентом этого мало: он продолжает отвечать связно и уверенно, просто ответы становятся хуже. Ни в логах, ни в мониторинге инфраструктуры это не отражается.
Отсюда правило, которое стоит принять до запуска: работоспособность агента измеряется не доступностью сервиса, а содержанием ответов. Зелёные графики нагрузки не говорят ничего о качестве. Они нужны, но отвечают на другой вопрос — «работает ли», а не «работает ли правильно».
Агент не ломается — он деградирует. Условия изменились, документ устарел, появилась новая тема обращений, а он продолжает отвечать по-старому, уверенно и неправильно.
Что меняется вокруг агента, пока его никто не трогает
«Работает — не трогаем» звучит разумно, но вокруг агента всё продолжает двигаться. Полезно знать источники дрейфа заранее: тогда понятно, где искать причину, когда показатели поехали.
Условия бизнеса. Цены, акции, сроки доставки, график работы. Отдел маркетинга поменял условия на сайте, а документ в базе знаний остался прежним.
Сама база знаний. Кто-то дописал раздел, удалил устаревший файл или загрузил новую версию прайса рядом со старой. Агент находит оба документа и выбирает не тот.
Модель. Если агент работает через облачный API, поставщик может обновить модель под тем же названием. Формулировки и склонность додумывать меняются, хотя вы ничего не делали.
Инструкция агента. Мелкая правка текста инструкции «чтобы был вежливее» способна изменить поведение в местах, о которых никто не подумал.
Интеграции. В CRM переименовали поле, телефония сменила формат передачи номера — агент продолжает работать, но данные в карточку не попадают.
Практический вывод для инфраструктуры: в журнале каждого диалога должна храниться версия инструкции, версия базы знаний и версия модели. Без этого на вопрос «что изменилось с прошлой недели» ответа нет, а с этим — есть за минуту. И любое изменение из списка выше стоит прогонять через тот же набор тестовых вопросов, что и перед запуском; как его собрать, разобрано в статье о тестировании агента перед запуском.
Что смотреть у агента после запуска: четыре группы показателей
- Доля передач человеку. Не сама по себе, а её динамика и состав. Рост означает, что база знаний отстала от изменений.
- Темы обращений. Появление новых тем в потоке — сигнал, что нужно дописать материалы, а не признак поломки.
- Признаки недовольства. Повторные обращения по одному вопросу, резкая лексика, прямые просьбы соединить с человеком.
- Результат процесса. Та самая метрика, которую зафиксировали до запуска: доля дозвонов, конверсия в следующий этап, время ответа.
Первые три говорят о качестве работы агента, четвёртая — о том, зачем всё затевалось. Смотреть нужно все четыре: агент может отвечать безупречно и не влиять на результат, и наоборот.
Четвёртая группа — самая важная и чаще всего отсутствующая. Если до запуска не договорились, какая цифра должна измениться, после запуска мониторинг превращается в наблюдение за агентом ради наблюдения. В 404ai метрику согласуют на старте, по методу «Цель → метрика», и дальше вся отчётность крутится вокруг неё; как отличить эффект агента от совпадения, разобрано в статье о замере эффекта от внедрения.
Что означают конкретные сигналы
| Сигнал | Скорее всего означает | Что делать |
|---|---|---|
| Резкий рост передач человеку | Изменились условия, база отстала | Сверить документы с реальностью |
| Падение передач до нуля | Агент перестал признавать незнание | Проверить ограничение источника |
| Одна тема лидирует в передачах | По ней нет материалов | Дописать и вернуть агенту |
| Клиенты переспрашивают одно и то же | Ответ формально верный, но непонятный | Переписать формулировку в базе |
| Метрика процесса не двигается | Автоматизировали не то место | Вернуться к разбору процесса |
Вторая строка контринтуитивна: падение передач человеку выглядит как улучшение, а часто означает обратное — агент начал отвечать там, где раньше честно признавал незнание. Почему модель вообще склонна уверенно додумывать и как это ограничить, разобрано отдельно — в статье о том, почему AI выдумывает.
Порог тревоги считается от своей нормы, а не от чужой
Частый вопрос — какая доля передач человеку нормальная. Универсального ответа нет: у агента первой линии поддержки и у агента, который квалифицирует заявки, нормы разные, и перенос чужой цифры ничего не даст.
Рабочий способ — снять собственную норму. Первые недели после запуска, пока идёт сплошное чтение, фиксируете недельные значения четырёх групп показателей. Это ваш коридор. Тревогой считается выход за коридор, а не абсолютная величина: резкий рост передач, резкое падение, всплеск повторных обращений.
Смотреть такие показатели ежедневно мне кажется лишним: на небольшом потоке дневные значения скачут, и команда быстро учится игнорировать уведомления. Недельного среза достаточно. Исключение — технические сигналы вроде ошибок интеграции и пустых ответов: их лучше получать сразу.
Сплошное чтение первых недель
Никакие показатели не заменяют чтение диалогов подряд в первое время. Причина в том, что выдуманный ответ выглядит нормальным и в статистику не попадает — его находят только глазами, сверяя с документом.
Разумный режим: первые две недели — все диалоги подряд, дальше — выборка плюс все случаи с передачей человеку и все обращения с признаками недовольства.
Как собрать выборку для регулярной проверки
Сплошное чтение работает первые недели, дальше становится нереалистичным. Ему на смену приходит выборка, и от того, как она собрана, зависит, найдёте вы проблемы или пропустите.
Случайная выборка — основа, но её одной мало: редкие и дорогие ошибки в неё почти не попадают. Поэтому к случайной части добавляют целевые: диалоги с самой низкой оценкой уверенности, самые короткие, самые длинные, завершённые клиентом досрочно и те, где агент отвечал по темам, добавленным за последний месяц.
Ориентир по объёму, с которого я бы начинал, — тридцать-пятьдесят диалогов в неделю на старте и вдвое меньше после стабилизации; дальше его стоит подстроить под свой поток. Важнее регулярность, чем размер: маленькая выборка каждую неделю обнаруживает сдвиг быстрее, чем большая раз в квартал.
Диалоги, которые закончились ничем
Самая информативная и чаще всего игнорируемая группа — разговоры, где клиент задал вопрос и ушёл, не получив ни ответа, ни передачи человеку. В отчётах они не выглядят проблемой: ошибки нет, жалобы нет, просто диалог оборвался.
Причины делятся на три типа. Агент ответил формально верно, но не по сути, и человек не стал переспрашивать. Агент попросил уточнение, которое клиенту показалось лишним. Или ответ пришёл слишком поздно, и вопрос потерял актуальность.
Отделить их друг от друга можно только чтением, зато выборка небольшая и находится автоматически: диалоги без завершающего действия и без передачи. Именно здесь обычно обнаруживаются самые дешёвые в исправлении улучшения — иногда одна переформулированная фраза закрывает целую группу таких обрывов.
Регулярный разбор превращает передачи человеку в список работ
Раз в месяц имеет смысл смотреть не на цифры, а на состав: по каким темам агент чаще всего звал человека и что из этого пора описать и отдать ему. Это превращает передачи из потери в список работ.
Там же проверяется актуальность: изменились ли условия, цены, регламенты с прошлого разбора. Устаревший документ в базе хуже отсутствующего — без него вопрос уйдёт человеку, с ним агент уверенно назовёт неверное. Правила, по которым агент обязан звать человека, стоит пересматривать на том же разборе; как их сформулировать, описано в статье об эскалации на оператора.
Как отличить проблему агента от проблемы процесса
Часть жалоб на агента к агенту отношения не имеет. Клиент недоволен, обращение зафиксировано, но причина в том, что произошло после: переданное человеку обращение никто не взял, обещанный перезвон не состоялся, задача повисла.
Различить помогает разделение показателей на две группы. Первая — то, что зависит от агента: доля ответов по существу, доля верных фактов, время до ответа. Вторая — то, что зависит от процесса: время до разбора переданного обращения, доля выполненных обещаний, доля повторных обращений по той же теме.
Если первая группа в порядке, а вторая проседает, менять настройки бессмысленно. Практическая польза такого разделения ещё и в том, что оно снимает беспредметный спор: вместо «система плохо работает» появляется конкретное «переданные обращения разбираются в среднем за шесть часов».
Что показывать руководству
Отчёт из двадцати графиков не читают, а из одного числа — не понимают. Работающая форма — четыре строки и одно приложение.
Четыре строки: сколько обращений обработано, какая доля закрыта без человека, что изменилось по сравнению с прошлым месяцем и одна главная находка. Последняя строка важнее остальных: она показывает, что систему действительно смотрят, а не просто снимают показания.
Приложение — два-три реальных диалога: один удачный, один проблемный и, если есть, один спорный. Конкретный разговор объясняет состояние дел лучше любой сводки и обычно вызывает именно те вопросы, которые полезно обсудить.
Когда отдельный мониторинг не нужен
Строить систему наблюдения крупнее самого агента — частая ошибка, и она тоже стоит денег.
Маленький поток. Если агент ведёт несколько диалогов в день, дашборд, выборки и пороги не нужны. Человек читает все диалоги раз в день или раз в два дня, и это надёжнее любой статистики на таком объёме.
Агент, который не отвечает на вопросы по фактам. Если агент только собирает заявку — имя, телефон, удобное время — и не отвечает на вопросы по условиям, дрейфовать почти нечему. Достаточно технических проверок: заявки доходят до CRM, поля заполнены.
Результат не сдвинулся. Если за согласованный срок метрика процесса не изменилась, дорабатывать мониторинг бессмысленно — вопрос уже не в качестве ответов, а в том, нужен ли этот агент. Такое условие остановки лучше записать до запуска; что делать, если пилот не дал результата, разобрано в статье «Пилот провалился: что дальше».
Кто за это отвечает
После вывода в прод роль владельца процесса не исчезает, а меняется: он перестаёт быть проектной фигурой и становится частью обычного управления. Признак, что переход состоялся, — вопросы про агента обсуждаются на планёрках отдела наравне с остальной работой. Как распределить поддержку между своей командой и подрядчиком, разобрано в статье о том, кто поддерживает AI после внедрения.
Если ресурсов мало, оставьте два действия: раз в неделю читать все диалоги с передачей человеку и раз в месяц сверять базу знаний с актуальными условиями. Это закрывает два самых частых источника деградации — пробелы в базе и устаревшие документы.
Мониторинг агента начинается с метрики, записанной до запуска
Из всего сказанного для решения следует одно: вопрос «как следить за агентом» решается не после запуска, а до него. Если до запуска записаны метрика процесса, версия инструкции и базы, набор тестовых вопросов и условие остановки, мониторинг сводится к недельному срезу и месячному разбору. Если не записаны — никакой дашборд не ответит, стало лучше или хуже.
Проверить своего агента можно на этой неделе: выгрузите диалоги за семь дней, прочитайте все передачи человеку и все оборванные разговоры и сверьте пять ответов о ценах и условиях с актуальными документами. Если расхождений нет — у вас работающий режим. Если есть — вы знаете, с чего начинать.
