Наблюдаемость LLM: трассировка, логи и мониторинг ИИ-приложений

Зачем ИИ-приложениям особая наблюдаемость

Классический мониторинг отвечает на вопрос «сервис жив и быстр?». Для ИИ-приложения этого мало: сервис может быстро вернуть HTTP 200 и при этом дать неверный, выдуманный или небезопасный ответ. Ответы недетерминированы, а одно действие пользователя может запустить несколько вызовов модели, поисков и инструментов.

Наблюдаемость LLM — это способность ответить на три вопроса по любому запросу:

• Что именно модель получила и что вернула?
• Какие шаги, инструменты и документы участвовали?
• Сколько это стоило, сколько заняло времени и был ли ответ хорошим?

Что логировать по каждому запросу

Полезный минимум для каждого вызова LLM:

Трассировка многошаговых агентов

Агент может спланировать, сделать поиск, вызвать API, снова обратиться к модели и только потом ответить. Если логировать каждый вызов отдельно, восстановить картину невозможно. Используйте трассы и спаны:

• трасса (trace) — один запрос пользователя от начала до конца;
• спан (span) — один шаг внутри: вызов LLM, векторный поиск, вызов инструмента;
• спаны вложены друг в друга, поэтому видно дерево событий и куда ушли время и токены.

Общий стандарт для этого — OpenTelemetry, в нём развиваются семантические соглашения для генеративного ИИ. Специализированные инструменты (open-source и SaaS) добавляют поверх LLM-ориентированные представления: песочницы промптов, дашборды стоимости, прогоны оценок.

from opentelemetry import trace

tracer = trace.get_tracer("support-bot")

with tracer.start_as_current_span("answer_question") as span:
    span.set_attribute("prompt.version", "support-v7")
    docs = search_docs(question)          # дочерний спан внутри
    span.set_attribute("rag.docs_count", len(docs))
    reply = call_llm(question, docs)      # дочерний спан внутри
    span.set_attribute("llm.tokens.total", reply.usage.total_tokens)

Следите за типичными сбоями агентов: зацикливание (один и тот же инструмент снова и снова), слишком много шагов, ошибки инструментов, которые модель игнорирует, и неконтролируемый расход токенов.

Мониторинг качества и дрейфа

Качество ответов может меняться, даже если ваш код не менялся: провайдер обновил модель, вопросы пользователей сместились, база знаний устарела. Отслеживайте это:

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

Настраивайте алерты на резкие изменения, а не только на абсолютные пороги.

Логирование без риска для приватности

В промптах часто есть имена, телефоны, адреса, документы. Писать их в логи как есть — значит готовить утечку.

• Маскируйте или удаляйте персональные данные (PII) до записи в логи.
• Храните полные тексты только там, где это нужно, и с коротким сроком хранения.
• Ограничьте доступ к сырым трассам по ролям и фиксируйте, кто их читает.
• Держите метрики (токены, задержка, стоимость) отдельно от содержимого, чтобы дашборды не раскрывали тексты.
• Проверьте, что место хранения данных и условия сервиса логирования соответствуют местному законодательству и вашим договорам.

Частые ошибки

• Логировать только ошибки — тогда правдоподобные, но неверные ответы остаются невидимыми.
• Не версионировать промпты — невозможно понять, какое изменение ухудшило качество.
• Считать стоимость за месяц, но не по функциям и пользователям.
• Отправлять сырые данные пользователей во внешний сервис логирования без проверки.