Мониторинг ИИ-системы отличается от мониторинга обычного сервиса тем, что привычные показатели почти ничего не сообщают. Сервис доступен, отвечает за две секунды, ошибок нет — и при этом отвечает неверно.
Поэтому наблюдение строится в двух слоях: техническом и содержательном. Для практики их удобно развернуть в четыре: инфраструктура, стоимость и задержки, качество ответов, поведение пользователей — каждый слой отвечает на свой вопрос и деградирует по-своему.
Четыре слоя наблюдения
Инфраструктура. Доступность, коды ошибок, загрузка ускорителей, память, очередь. Отвечает на вопрос «работает ли система вообще». Деградирует резко и ловится стандартными средствами.
Стоимость и задержки. Расход токенов, цена обращения и за период, время до первого токена и полное время ответа, доля обращений у лимитов. Отвечает на вопрос «предсказуем ли счёт и терпят ли пользователи ожидание».
Качество ответов. Доля отказов, результаты прогонов проверочного набора, исправления в контуре проверки, оценки верности по выборке. Отвечает на вопрос «ответы верны». Меняется медленно — это территория дрейфа данных.
Поведение пользователей. Повторные обращения, переформулировки, бросание диалога, доля передач человеку. Отвечает на вопрос «решает ли система задачу человека», и это единственный слой, который меряет ценность, а не исправность.
Слои проверяются сверху вниз: сначала исключить инфраструктуру, затем счёт и задержки, затем качество, и только потом разбираться в поведении — иначе диагностика путает причину со следствием.
Технический слой
Доступность и коды ошибок. Время ответа — отдельно время до первого токена и полное. Доля обращений, упёршихся в лимиты. Расход токенов и стоимость за период. Для локальных моделей — загрузка ускорителя, занятость памяти, длина очереди.
Всё это собирается стандартными средствами и нужно прежде всего для предсказуемости счёта и обнаружения аварий.
Задержки смотрят перцентилями, не средним. Среднее время скрывает хвост: несколько обращений по минуте при среднем «две секунды». Практический минимум — p50 и p95 по обоим временам; рост p95 при стабильном p50 означает, что часть трафика регулярно уходит в худший режим — длинный контекст, редкий инструмент, ретраи.
Время до первого токена и полное время живут по разным причинам. Первое зависит от загрузки инференса и длины промпта, второе — ещё и от длины ответа и числа вызовов инструментов. Растёт первое — проблема ёмкости; растёт только второе — система начала делать больше шагов на обращение, и это содержательный сигнал, а не технический.
Содержательный слой
Доля отказов — «не нашлось», «уточните вопрос». Резкий рост означает, что что-то сломалось в поиске или изменился характер обращений.
Доля передач человеку. Прямой показатель полезности автоматизации.
Доля повторных обращений по тому же вопросу в течение суток. Самый честный показатель: если человек вернулся, задача не решена, как бы хорошо ни выглядел журнал.
Исправления в контуре проверки — сколько и какого характера.
Результаты регулярного прогона проверочного набора.
Сочетания метрик диагносцируют точнее отдельных значений. Отказы вверх, а передачи человеку вниз — система начала честнее отказываться, и это часто улучшение. Отказы стабильны, повторные вверх — ответы формально есть, но не решают задачу: проблема в генерации или в самих источниках. Передачи вверх при неизменном качестве на проверочном наборе — изменился трафик, а не система; это граница между задачей мониторинга и задачей дрейфа.
Выборочный разбор
Показатели говорят, что стало хуже, но не говорят почему. Ответ даёт чтение реальных диалогов — десяток-другой в неделю, выбранных случайно и отдельно из проблемных категорий.
Это скучная работа, которую обычно никто не делает, и она приносит больше понимания, чем любая панель с графиками. Почти все содержательные улучшения в ИИ-системах рождаются из чтения логов, а не из анализа метрик.
Дашборд минимального состава
Шесть–восемь метрик на одном экране, не больше. Сверх этого панель перестаёт читаться, и наблюдение снова сворачивается к оповещениям.
- Код ошибок и доступность — наложение с обычным мониторингом сервиса.
- p95 времени до первого токена и полного времени.
- Стоимость за сутки и средняя цена обращения.
- Доля отказов и доля передач человеку — с дневным срезом.
- Доля повторных обращений — с недельным срезом, суточный шум по ней велик.
- Результат последнего прогона проверочного набора с датой.
Остальное — в журнале и в разборах, не на экране: дашборд отвечает на вопрос «куда смотреть», а не «что чинить».
Что настроить в первую очередь
Если ресурса мало, начинать стоит с трёх вещей: журнал с возможностью прочитать диалог целиком, счётчик расхода с оповещением при превышении, и еженедельный прогон проверочного набора.
Оповещение по расходу упоминают редко, а именно оно чаще всего спасает бюджет: зацикливание агента или ошибка в цикле обнаруживаются по счёту, если их не ловить заранее.
Оповещения: на что настраивать
Панель, на которую никто не смотрит, бесполезна. Работают оповещения, и их стоит держать немного, иначе на них перестают реагировать.
Расход выше порога за час или сутки. Ловит зацикливание агента и ошибку в цикле раньше, чем счёт.
Резкий рост доли отказов. Обычно означает поломку в поиске или индексации.
Рост доли передач человеку. Сигнал, что система перестала справляться.
Ошибки обращения к модели. Смена версии, исчерпание лимита, недоступность поставщика.
Пороги ставятся от базовой линии за последние две–четыре недели, не от ощущений: типовая стартовая точка — превышение суточного расхода в 1,5–2 раза и рост доли отказов на 5–10 процентных пунктов к обычному уровню. Пороги пересматривают после каждого значимого изменения системы, иначе сработки уходят в шум.
Что хранить в журнале
Вопрос, переданные фрагменты, ответ, версию промпта и модели, время и стоимость. Без переданных фрагментов разобрать неверный ответ невозможно: непонятно, виноват поиск или генерация.
При этом журнал содержит те же данные, что и запросы, — со всеми требованиями к сроку хранения и разграничению доступа.
Практические следствия: доступ к журналам — по ролям, персональные данные в обращениях видят только те, кто и так имел к ним доступ в бизнес-процессе; при передаче логов подрядчику или в разметку — обезличивание. Версия промпта и модели в каждой записи превращает журнал в рабочий инструмент сравнения «до и после» — без них изменения качества нельзя связать с изменениями системы.
Частые вопросы
Достаточно ли обычного мониторинга доступности?
Нет. ИИ-система может быть полностью доступна и при этом отвечать неверно — технические показатели этого не покажут. Нужен второй слой: доля отказов, передач человеку, повторных обращений и регулярный прогон проверочного набора.
Какой показатель самый информативный?
Доля повторных обращений по тому же вопросу в течение суток. Если человек вернулся с тем же, задача не решена, независимо от того, как ответ выглядел в журнале. Этот показатель трудно обмануть.
Нужно ли читать диалоги вручную?
Да, и это недооценённая практика. Метрики показывают, что стало хуже, но не почему. Разбор двух десятков реальных диалогов в неделю даёт больше понимания, чем панель с графиками.
Как отличить деградацию системы от смены трафика?
Прогоном проверочного набора: он неизменен по построению, поэтому на нём видна только система. Если на наборе качество прежнее, а на живом трафике метрики просели — изменились обращения, и лечится это обновлением примеров и набора, а не откатом промпта.
Сколько стоит сам мониторинг?
Технический слой фактически бесплатен — логируются заголовки запросов, а не содержимое. Основная цена — регулярный прогон набора (тысячи–десятки тысяч токенов в месяц) и человеко-часы на выборочный разбор: порядка двух–четырёх часов в неделю на систему средней нагрузки. Это обычно единицы процентов от стоимости инференса.
Как часто прогонять проверочный набор?
Раз в неделю–месяц в зависимости от скорости изменений в предметной области: частые регламенты — еженедельно, стабильная область — ежемесячно. Дешевле и полезнее делать прогоны частью цикла изменений: до и после каждого изменения промпта или модели.