Чеклист наблюдаемости LLM
Минимальная телеметрия для production LLM, агентов и ИИ-сценариев.
Проблема
Наблюдаемость LLM - это не «поставьте Grafana». Она должна связывать промпт, модель, токены, задержку, стоимость, вызовы инструментов, проверку качества, обратную связь и владельцев.
Симптомы
- Ты видишь ошибки, но не версии промпта.
- Ты видишь общее число токенов, но не кешированные токены.
- Ты видишь задержку, но не TTFT или резервный маршрут.
- Ты видишь трейсы, но не успешность сценария.
Ментальная модель
Каждый AI-вызов должен разбираться как событие продукта, модели, стоимости и качества.
Архитектура
Минимально трейсы должны включать request_id, user_id или tenant_id, scenario_id, модель, провайдера, версию промпта, версию системного промпта, входные токены, выходные токены, кешированные токены, общую стоимость, TTFT, общую задержку, вызовы инструментов, события резервного маршрута, события безопасности, оценку качества, обратную связь пользователя и категорию ошибки.
Для self-hosted и routing-разборов нужны дополнительные поля: route_lane, router_version, router_confidence, prompt_family, prefix_hash, tools_hash, tools_count, schema_hash, agent_step, static_tokens, dynamic_tokens, cache_read_input_tokens, cache_creation_input_tokens, cache_eligible_tokens, pool_id, replica_id, environment, queue_time, batch_size, decode_profile, gpu_type и routing_reason.
Для self-hosted недостаточно видеть только модель и задержку. Нужно понимать, в каком пуле, на какой реплике, с каким decode profile и каким queue_time выполнялся запрос. Иначе p99 выглядит как проблема модели, хотя причина может быть в смешивании профилей нагрузки.
Метрики
Полнота трейсов, доля пропущенных полей, задержка сценария, TTFT, TPOT, стоимость принятого результата, доля срабатываний резервного маршрута, ошибки инструментов, доля попаданий в кеш, доля событий безопасности и оценка обратной связи.
Средняя доля cached tokens полезна, но опасна: cache regression нужно смотреть по route, scenario, prompt_family, tools_hash и agent_step.
Компромиссы
Глубокие трейсы могут раскрывать чувствительные данные. Production-наблюдаемость требует маскирования, правил хранения и очищенных примеров.
Анти-паттерны
- Логировать полные промпты без границ данных.
- Агрегировать сценарии так, что исчезают полезные сигналы.
- Отслеживать стоимость провайдера, но не принятые результаты.
- Прятать события резервного маршрута внутри кода повторов.
Чеклист
- ✓request_id, tenant_id и scenario_id присутствуют.
- ✓Модель, провайдер, версия промпта и версия системного промпта присутствуют.
- ✓Входные, выходные и кешированные токены разделены.
- ✓TTFT, TPOT и общая задержка разделены.
- ✓route_lane, router_version, prefix_hash, tools_hash и agent_step присутствуют для агентных сценариев.
- ✓pool_id, replica_id, queue_time, batch_size и decode_profile присутствуют для self-hosted.
- ✓Вызовы инструментов, события резервного маршрута, события безопасности и проверки качества видны.
После перехода в self-hosted
- ✓TTFT разделён по сценариям.
- ✓p95 и p99 задержки видны по пулам.
- ✓Время ожидания в очереди не смешано с временем генерации.
- ✓Загрузка GPU видна рядом с задержкой, а не отдельно.
- ✓Очередь пакетной обработки и её возраст отслеживаются.
- ✓Таймауты и ошибки разделены по моделям.
- ✓Дельты канареечной и стабильной версии видны в одном разборе.
- ✓У релиза модели есть ID прогона проверок качества.
- ✓Стоимость считается по сценарию, а не только по модели.
Пример
Если доля попаданий в кеш падает после деплоя, трейс должен показать причину: версия промпта, число инструментов, изменение схемы, маршрут, реплика или смесь трафика.
Шаблон решения
Для каждого нового маршрута определи обязательные поля трейса, политику маскирования, владельца дашборда, пороги алертов и срок хранения.