Observability для AI: что логировать и как ловить деградацию качества

Эта статья — про то, что именно логировать в AI-системе и как настроить ловлю деградации качества, чтобы замечать проблему раньше пользователя. Без теории про «три столпа observability», только то, что работает на практике.

Классический сервис, когда ломается, кричит об этом: 500-я ошибка, рост латентности, алерт в дежурную смену. AI-фича так не делает. Модель почти никогда не «падает» — она продолжает отвечать, просто отвечает хуже. Пользователь получает правдоподобный, но неверный ответ, ассистент перестаёт замечать половину запрос, RAG подтягивает не те документы. Внешне всё зелёное, а качество уже просело.

Проблема возникает ровно тогда, когда вы выкатили LLM-функцию в прод и переключились на следующую задачу. Через две недели провайдер обновляет версию модели, кто-то правит промпт, в базу знаний заливают новые документы — и поведение системы сдвигается. Без observability вы узнаёте об этом из жалоб пользователей или из упавшей конверсии, то есть с опозданием на недели.

Чем observability для AI отличается от обычного мониторинга

Три отличия, из-за которых привычного стека (логи + метрики + трейсы) недостаточно:

• Нет однозначно правильного ответа. У API-эндпоинта есть контракт: на такой запрос — такой ответ. У генеративной модели «правильных» ответов много, а «неправильный» внешне не отличается от правильного.
• Отказы тихие. Модель не бросает исключение, когда галлюцинирует. Метрики доступности и латентности при этом идеальные.
• Система недетерминирована и зависит от внешних факторов. Один и тот же промпт даёт разные ответы. Провайдер молча обновляет модель. Деградацию вызывает не баг в вашем коде, а изменение, которое вы не контролируете.

Вывод простой: мониторить только инфраструктуру (CPU, латентность, коды ошибок) недостаточно. Нужно логировать содержание и отдельно измерять качество. Ниже — как это выглядит по слоям.

Что логировать

Минимальный набор полей на каждый вызов модели. Это фундамент — без него любые метрики качества не с чем связать.

• Вход и выход целиком. Финальный промпт (не шаблон, а то, что реально ушло в модель, со всеми подставленными переменными) и полный ответ. Самая частая боль в проде — «что мы вообще отправили?», и без сырого промпта ответа нет.
• Версии всего. Версия модели, версия промпта, версия пайплайна. Когда качество просядет, первый вопрос «что изменилось?». На него отвечают версии.
• Метаданные запроса. Идентификатор пользователя или сессии, таймстемп, тип запроса, фича. Нужны, чтобы резать метрики по сегментам.
• Технические параметры. Латентность, число токенов, стоимость, температура и прочие параметры вызова. Здесь же причина завершения: модель закончила сама или упёрлась в лимит токенов.
• Для RAG — извлечённый контекст. Какие документы и чанки подтянулись и с какими скорами. Половина проблем RAG не в модели, а в ретривере: он принёс не то. Без логирования контекста это не видно.
• Промежуточные шаги для агентов. Какие инструменты вызывались, с какими аргументами и что вернули. Для многошаговых агентов трейс — единственный способ понять, где цепочка свернула не туда.

Два правила гигиены. Маскируйте персональные данные на этапе записи, логи с PII — это утечка и нарушение, а не observability. И сэмплируйте осознанно: хранить 100% трафика дорого, но оставлять только «успешные» вызовы нельзя, иначе вы «ослепнете» именно на проблемных кейсах.

Как ловить деградацию качества

Логи отвечают на вопрос «что произошло». Чтобы поймать деградацию, нужен отдельный слой измерения качества. На практике он состоит из четырёх частей.

1. Офлайн-набор для регрессий (eval set). Соберите 50–200 примеров «вход → ожидаемое поведение» из реальных кейсов, включая граничные и ранее сломанные. Прогоняйте на нём систему перед каждым изменением промпта или модели. Это аналог юнит-тестов: дёшево, повторяемо, ловит регрессии до прода. Если такого набора нет — это первое, что стоит сделать.

2. Онлайн-метрики качества. То, что считается автоматически на живом трафике: доля ответов, обрезанных по лимиту токенов, доля пустых и отказных ответов, доля ответов вне формата (ждали JSON, а пришёл текст); для RAG — доля запросов, где ничего не нашлось. Эти прокси не измеряют «правильность», но их резкое движение — надёжный признак того, что что-то сломалось.

3. LLM-as-judge. Вторая модель оценивает ответы основной по чек-листу: релевантность, фактологичность, следование инструкции. Применяется к выборке трафика и выдаёт оценку, которую можно отслеживать во времени. Важная оговорка: «судья» сам дрейфует и сам ошибается, поэтому его нужно периодически сверять с ручной разметкой, а не доверять слепо.

4. Сигналы от пользователей. Лайки и дизлайки, повторная генерация ответа, ручные правки, ранний выход из диалога. Это самый дешёвый и самый честный источник: рост доли регенераций на конкретной фиче часто замечает деградацию раньше любой автоматической метрики.

Главное смотреть на эти метрики не в моменте, а как на тренд с алертом на отклонение от базовой линии. Деградация почти всегда выглядит как медленный или ступенчатый сдвиг, а не как обвал.

Типовые ошибки

• Мониторят только инфраструктуру. Латентность и аптайм зелёные, качество просело — и никто не в курсе.
• Не логируют финальный промпт. Хранят шаблон вместо реально отправленного текста и потом не могут воспроизвести проблему.
• Нет версионирования. Качество упало, но неясно, что менялось: модель, промпт или данные.
• Нет офлайн-набора. Каждое изменение промпта — деплой «на авось» с проверкой вручную на трёх примерах.
• Сэмплируют только хорошее. Логируют успешные вызовы и выбрасывают ошибочные — то есть именно те, ради которых всё затевалось.
• Слепо верят LLM-судье. Не сверяют его с людьми и принимают решения по метрике, которая сама уехала.
• Льют PII в логи. Удобно для дебага, опасно для безопасности и комплаенса.

С чего начать на практике

Не нужно сразу строить платформу. Минимально жизнеспособный набор разворачивается за пару дней:

1.   Логируйте на каждый вызов: финальный промпт, ответ, версии (модель и промпт), латентность, токены, для RAG — извлечённый контекст. С маскированием PII;

2.   Соберите офлайн-набор из 50 реальных примеров и прогоняйте его перед каждым изменением;

3.   Добавьте 3–5 автоматических онлайн-метрик (обрезка по токенам, отказы, формат ответа) и алерт на отклонение от базовой линии;

4.   Подключите хотя бы один пользовательский сигнал — дизлайк или повторную генерацию.

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

Выводы

•     AI-системы деградируют тихо, поэтому мониторинг инфраструктуры не спасает — нужно логировать содержание и отдельно измерять качество.

•     Минимум для логов: финальный промпт, ответ, версии, технические параметры, контекст для RAG. Без версий вы не ответите на вопрос «что изменилось».

•     Качество ловится комбинацией офлайн-набора (регрессии до прода), онлайн-прокси-метрик, LLM-судьи и сигналов от пользователей и смотреть на них нужно как на тренд.

•     Большинство провалов — это базовые вещи: не залогировали промпт, не завели eval-набор, доверились LLM-судье.

Выстраивать такую систему имеет смысл собственными силами, пока у вас одна-две AI-фичи. Когда их становится больше, появляются агенты и RAG-пайплайны, а цена ошибки растёт — разумно провести аудит наблюдаемости и собрать единый слой логирования и оценки качества.