☁️ Почему мониторинга HTTP недостаточно для LLM
У LLM-сервиса может быть 99,9% успешных HTTP-запросов и при этом серьёзные проблемы с качеством.
Классический мониторинг показывает, что API отвечает, сколько занимает запрос и сколько ошибок произошло. Но он не скажет, что модель придумала факт, использовала устаревший документ из RAG или потратила в несколько раз больше токенов.
Для LLM-сервисов поэтому приходится смотреть сразу на несколько уровней.
▫️ Технические метрики: p50/p95/p99 задержки, TTFT, ошибки, таймауты и доля усечённых ответов.
▫️ Качество: доля неподтверждённых утверждений, результаты автоматических проверок, пользовательские оценки и результаты экспертной разметки.
▫️ Экономика: количество входных и выходных токенов, стоимость запросов, использование prompt caching и расходы на отдельные шаги агентной цепочки.
Особенно важны трейсы. В обычном сервисе достаточно увидеть запрос и ответ. В LLM-приложении нужно понимать весь путь: запрос → поиск по базе → реранкинг → генерация → вызов инструмента → итоговый ответ.
Для RAG это помогает обнаружить проблемы с retrieval и устаревшими документами. Для AI-агентов - зацикливание, ошибки вызовов инструментов и бесконтрольное увеличение количества шагов.
Есть и ещё один вопрос - где хранить эти данные. Трейсы могут содержать персональные данные, коммерческую информацию и содержимое внутренних документов. Поэтому отправка их во внешний SaaS или LLM-as-a-Judge требует отдельного внимания к защите данных и требованиям 152-ФЗ.
Практический старт не обязательно должен быть сложным: OpenTelemetry, несколько ключевых метрик, сохранение трейсов и регулярные проверки качества уже дают гораздо больше информации, чем один график с HTTP 200.
В блоге Cloud4U разобрали, какие метрики собирать, как измерять галлюцинации, считать стоимость успешной задачи и организовать observability-контур для LLM в российской инфраструктуре.
У LLM-сервиса может быть 99,9% успешных HTTP-запросов и при этом серьёзные проблемы с качеством.
Классический мониторинг показывает, что API отвечает, сколько занимает запрос и сколько ошибок произошло. Но он не скажет, что модель придумала факт, использовала устаревший документ из RAG или потратила в несколько раз больше токенов.
Для LLM-сервисов поэтому приходится смотреть сразу на несколько уровней.
▫️ Технические метрики: p50/p95/p99 задержки, TTFT, ошибки, таймауты и доля усечённых ответов.
▫️ Качество: доля неподтверждённых утверждений, результаты автоматических проверок, пользовательские оценки и результаты экспертной разметки.
▫️ Экономика: количество входных и выходных токенов, стоимость запросов, использование prompt caching и расходы на отдельные шаги агентной цепочки.
Особенно важны трейсы. В обычном сервисе достаточно увидеть запрос и ответ. В LLM-приложении нужно понимать весь путь: запрос → поиск по базе → реранкинг → генерация → вызов инструмента → итоговый ответ.
Для RAG это помогает обнаружить проблемы с retrieval и устаревшими документами. Для AI-агентов - зацикливание, ошибки вызовов инструментов и бесконтрольное увеличение количества шагов.
Есть и ещё один вопрос - где хранить эти данные. Трейсы могут содержать персональные данные, коммерческую информацию и содержимое внутренних документов. Поэтому отправка их во внешний SaaS или LLM-as-a-Judge требует отдельного внимания к защите данных и требованиям 152-ФЗ.
Практический старт не обязательно должен быть сложным: OpenTelemetry, несколько ключевых метрик, сохранение трейсов и регулярные проверки качества уже дают гораздо больше информации, чем один график с HTTP 200.
В блоге Cloud4U разобрали, какие метрики собирать, как измерять галлюцинации, считать стоимость успешной задачи и организовать observability-контур для LLM в российской инфраструктуре.