Почему стандартный мониторинг веб‑сервисов плохо подходит для AI‑агентов
Метрики, привычные для веб‑сервисов, такие как uptime, error rate и p95 latency, почти не помогают заметить реальные сбои в работе AI‑агентов. Система может спокойно возвращать статус 200 OK, хотя качество ответов уже падает, а вычислительные расходы растут.
В одном из описанных случаев проблема возникла после небольшого изменения порядка инструментов в prompt. Это сломало prompt cache: агент начал отвечать, обходя извлечённый контекст. Стоимость задачи почти удвоилась, качество ответов ухудшилось, но инфраструктурные метрики по‑прежнему показывали «идеальное» состояние. О проблеме узнали только после жалобы пользователя.
Автор связывает это с тем, как устроен привычный мониторинг. Системы наблюдения за веб‑трафиком создавались для детерминированных сервисов. LLM‑агенты устроены иначе: внутри детерминированной оболочки работает вероятностное ядро, подход описан в концепции Deterministic Shells, Probabilistic Cores. Поэтому стандартные показатели могут искажать реальную картину.
Хороший пример, latency у LLM нельзя свести к одному числу. Ответ появляется постепенно, токен за токеном, и задержку приходится рассматривать по этапам. Первый этап называется time to first token (TTFT). Он включает время ожидания в очереди и фазу prefill, когда модель обрабатывает prompt, а пользователь ещё не видит ответа.
Есть и другая сложность, связанная со стоимостью. Расходы масштабируются не количеством запросов, а числом токенов. Каждый шаг цикла вызывает LLM и тратит токены. Поэтому график request‑per‑second может выглядеть одинаково в двух ситуациях: когда один запрос стоит десятую долю цента и когда другой обходится в пятьдесят центов. При этом многие ошибки остаются «тихими». Система возвращает аккуратно сформулированный текст со статусом 200, хотя фактически ответ может быть неверным.
Для наблюдения за такими системами автор предлагает отталкиваться от пяти практических вопросов: как быстро работает агент, способен ли он масштабироваться, корректны ли его ответы, сохраняется ли устойчивость со временем и что происходит с агентом во время выполнения задач. Эти метрики он внедряет в продакшене для агентов в Wasaphi, Izimail и клиентских системах. Причина простая: ключевые показатели для таких систем обычно не существуют «из коробки», их приходится строить и инструментировать отдельно.
Ключевые факты
В описанном продакшн‑инциденте небольшая перестановка списка инструментов в промпте инвалидировала prompt cache, после чего агент начал отвечать вокруг извлечённого контекста, а API gateway продолжал возвращать статус 200 OK.
Во время этого сбоя cost per task примерно удвоилась и снизилось качество ответов, при этом стандартные метрики uptime, error rate и p95 latency не показали проблем.
Задержка ответа LLM состоит как минимум из фаз prefill и decode; метрика time to first token (TTFT) включает очередь и prefill и отражает время до появления первого токена.
Один показатель p95 latency может усреднять короткий запрос на 50-token и длинный отчёт на 2,000-token, поэтому такая метрика не описывает реальные типы нагрузок.