Для ИИ-агента observability показывает полный путь одного запуска: вход пользователя, версию prompt, выбранную модель, найденные документы в RAG, вызовы tools, аргументы tool calls, ответы инструментов, guardrails, approval, cost, latency, fallback и финальный ответ.
Без наблюдаемости команда видит только жалобу пользователя: 'агент ответил не так'. С observability можно открыть конкретный run_id и понять причину: агент не нашел документ, retriever вернул не тот chunk, tool упал, модель превысила context budget, guardrail заблокировал действие или prompt version изменилась после релиза.
Observability не равна обычному логированию. Лог может быть строкой 'ошибка 500'. Наблюдаемость связывает события в картину: какой запрос запустил цепочку, какие шаги были внутри, сколько каждый шаг стоил, где была задержка, какие данные использовались и какой результат увидел пользователь.
Для production AI важны четыре слоя: traces для разбора конкретного запуска, structured logs для фильтрации событий, metrics для графиков и алертов, evals для оценки качества после изменений. Вместе они превращают AI-агента из черного ящика в управляемую систему.
Есть и риск: в traces и logs легко случайно сохранить персональные данные, коммерческую тайну, API keys, системные prompts или полный текст документов. Поэтому observability нужно проектировать вместе с redaction, access control, retention policy и sampling.
Примеры
- Пользователь пожаловался на неверный ответ. Команда открывает trace и видит, что RAG нашел устаревший документ, а не свежую инструкцию.
- После смены модели выросла стоимость ответов. Metrics показывают рост output tokens и долю длинных ответов по конкретной категории запросов.
- Tool call к CRM вернул 403. Structured log содержит run_id, tool_name, статус ошибки и безопасный summary без токенов доступа.
- Guardrail заблокировал отправку письма клиенту. Trace показывает причину: модель предложила действие без approval.
- Production trace ошибки попадает в dataset, после чего команда добавляет regression eval и проверяет, что баг не вернется.
Где используется
- отладка AI-агентов в production
- поиск причин плохих ответов
- контроль стоимости LLM-запросов
- мониторинг latency и ошибок tool calls
- разбор RAG-ошибок и качества retrieval
- связка incident response с trace конкретного запуска
- создание regression evals из реальных ошибок
- контроль guardrails, approvals и fallback
- дашборд качества для владельца продукта
- аудит действий агента в бизнес-процессах
Связанные термины
Частые вопросы
Чем observability отличается от мониторинга?
Мониторинг обычно отвечает, что система работает или сломалась: ошибки, latency, нагрузка. Observability помогает понять внутреннюю причину: какой prompt, tool, документ, модель или guardrail привели к результату.
Что обязательно логировать у AI-агента?
Минимум: run_id, user/session id без лишних персональных данных, prompt version, model, input/output summary, retrieved chunks, tool calls, errors, latency, token usage, cost, guardrail decisions и финальный статус.
Можно ли хранить полные prompts и ответы модели?
Не всегда. Это полезно для отладки, но может содержать персональные данные, секреты и внутренние инструкции. Нужны маскирование, роли доступа, retention policy и разные режимы для dev, staging и production.
Как observability связана с evals?
Observability показывает, что произошло в конкретном запуске. Evals проверяют, стало ли лучше после изменений. Хорошая практика: брать ошибки из traces, добавлять их в dataset и прогонять regression evals.
Какие инструменты использовать для LLM observability?
Для LLM-приложений часто используют LangSmith, Langfuse, Arize Phoenix и похожие платформы. OpenTelemetry помогает связать AI traces с общей инфраструктурой logs, metrics и distributed tracing.
