Мониторинг LLM

Решение: Мониторинг здоровья твоего ИИ

Observability для LLM (наблюдаемость) — это отслеживание, логирование и мониторинг всех аспектов твоей ИИ-системы, когда она уже работает с реальными пользователями. Обычный веб-сервис почти детерминирован: одинаковый ввод даёт одинаковый вывод, а статус 200 обычно значит «всё хорошо». С LLM всё иначе. Модель может выдать гладкий ответ, который уверенно неверен; один и тот же промпт завтра может стоить вдвое дороже; а мелкое изменение системного промпта незаметно ухудшит качество для тысяч людей. Observability — это дисциплина, которая делает чёрный ящик читаемым. Это как система мониторинга пациента в больнице: показатели жизнедеятельности на экране, тревога, когда что-то выходит за порог (threshold), и подробная карта всего, что произошло, чтобы потом восстановить, что именно пошло не так.

Как это работает

На практике ты инструментируешь каждый вызов модели и пишешь по нему структурированное событие. Основную работу делают три типа сигналов. Метрики — это дешёвые агрегаты, за которыми ты следишь на дашбордах: задержка (отслеживай p50, p95 и p99, а не только среднее), стоимость запроса, процент ошибок и токены на входе/выходе. Логи (logs) сохраняют полную нагрузку отдельных вызовов — промпт, ответ, имя модели, число токенов, — чтобы можно было разобрать конкретный плохой ответ. Трейсы (traces) сшивают эти логи в единую временную шкалу одного пользовательского запроса: многошаговый конвейер (достать контекст, собрать промпт, вызвать модель, прогнать guardrail) превращается в водопад, где видно, какой шаг съел время. Поскольку модель недетерминирована, ты также отслеживаешь сигналы качества, которых не покажет ни один HTTP-статус: процент галлюцинаций, соотношение лайков/дизлайков и офлайн-оценки релевантности.

Компромиссы и разбор примера

Добавляй observability с первого дня — прикручивать его после инцидента больно, а команды, которые инструментируют рано, регулярно находят, что 30-40% бюджета уходит впустую на горстку раздутых промптов. Главные подводные камни: логирование полных промптов и ответов может захватывать персональные данные пользователей, поэтому маскируй или хешируй чувствительные поля; а дашборды с высокой кардинальностью дороги, поэтому сэмплируй подробные трейсы, а не храни каждый байт. Конкретный пример: p95 задержка твоего чата вдруг подскочила с 1,2с до 4,5с. Без observability ты гадаешь. С трейсом ты открываешь один медленный запрос и видишь раскладку — запрос 5мс, сборка промпта 120мс, LLM API 4200мс, guardrail 50мс. Узкое место — сам вызов модели. Смотришь в логи на число токенов и обнаруживаешь, что вход раздулся с 800 до 9000 токенов после того, как недавнее изменение начало пихать всю историю чата в контекст. Фикс — обрезать старые ходы и добавить кэширование промпта (prompt caching) для статичного системного промпта — возвращает задержку и заодно режет стоимость, и всё это потому, что данные сделали проблему видимой.

Что мониторить

• Производительность: Отслеживайте p50, p95, p99 задержку по эндпоинтам — p95 > 3с означает, что 5% пользователей ждут слишком долго
• Отладка трейса: Пример трейса: запрос (5мс) -> сборка промпта (120мс) -> LLM API (4200мс) -> гарантия (50мс) -> ответ. Шаг LLM в 10 раз медленнее ожидаемого — возможные причины: раздутый контекст, перегрузка модели или промах кэша
• Стоимость: Отслеживайте стоимость-за-диалог (не только за запрос) — многоходовый чат может стоить в 10-50 раз больше одного обмена
• Качество: Отслеживайте процент галлюцинаций, соотношение лайков/дизлайков и оценки релевантности — деградация качества бесшумна без метрик

Попробуйте сами!

Используй интерактивный дашборд ниже, чтобы увидеть, как выглядит мониторинг LLM и понять ключевые метрики для отслеживания.