Содержание
В статье Как построить мультиагентную систему мы говорили: «инструментируйте каждую передачу управления, прежде чем добавлять агентов». Технология, которая обеспечивает это «инструментирование» в продакшене, — это наблюдаемость ИИ (AI observability). Она делает видимым то, что ваши LLM и агенты на самом деле делают в продакшене: какие инструменты вызывают, что извлекают, где падают и сколько это стоит.
В отличие от обычного мониторинга приложений, у ИИ есть неприятная особенность: запрос может вернуть «200 OK за 50ms» и при этом уверенно врать (галлюцинировать). Иными словами, система может быть быстрой и доступной, тогда как качество сломано. Эта статья проведёт новичков через три столпа наблюдаемости, объяснит, чем она отличается от оценки (evals), какие метрики стоит отслеживать и какие есть основные инструменты.
Визуализировать «дерево выполнения» одного запроса
— trace фиксирует входы, вызовы инструментов, извлечение и выходы в виде span
* Характеристики и концепции инструментов в этой статье приведены по публичным материалам и официальной документации (по состоянию на июнь 2026). Оценки инструментов зависят от сценария и версии — воспринимайте их как ориентир.
1. Что такое наблюдаемость ИИ?
Наблюдаемость ИИ означает сделать поведение LLM и ИИ-агентов в продакшене наблюдаемым извне. Для каждого запроса вы фиксируете «какая модель была вызвана с каким промптом, какие инструменты и поиски использовались, что было возвращено, сколько времени и денег это заняло» — чтобы при сбое можно было проследить путь до причины.
Решающее отличие от обычного мониторинга приложений: традиционный мониторинг проверяет «доступно ли, быстро ли?». Но ИИ может отвечать нормально и быстро, тогда как содержание неверно. Большинство сбоев ИИ — это не сбои инфраструктуры, а «сбои качества»: галлюцинации, слабое извлечение, небезопасные ответы, незавершённые задачи, плохое использование инструментов и регрессии после изменения промпта.
Поэтому ИИ нужно специализированное наблюдение. Особенно в мультиагентных системах сбои проявляются внутри многошаговых причинных цепочек, а не на уровне отдельного вызова. «Какой шаг пошёл не так и почему» становится видно только тогда, когда вы фиксируете trace всей сессии целиком.
2. Три столпа: trace, метрики, логи
Наблюдаемость традиционно описывают через три столпа. То же справедливо и для ИИ, а отраслевой стандарт OpenTelemetry (соглашения GenAI) позволяет работать со всеми тремя через единую схему, не зависящую от вендора.
Trace
Фиксируют путь выполнения одного запроса как дерево span. Вы видите, как протекали вызовы LLM, инструменты, извлечение и цепочки рассуждений. Главный элемент наблюдения ИИ.
Метрики
Агрегируют задержку, стоимость, число токенов, частоту ошибок и пропускную способность в виде чисел. Отслеживайте тренды по каждой модели/агенту.
Логи
Подробные записи отдельных событий — полные промпты, детали ошибок — основа для глубокого расследования.
Соглашения GenAI в OpenTelemetry фиксируют промпты, ответы модели, использование токенов, вызовы инструментов/агентов и метаданные провайдера в стандартном формате. Это значит, что вы не привязаны к одному вендору и можете направлять trace ИИ в существующие бэкенды мониторинга, такие как Datadog или Grafana.
3. Чем это отличается от оценки (evals)
Чаще всего новички путают разницу между «наблюдаемостью» и «оценкой (evals)». Это разные вещи, и они имеют смысл только в связке.
🔭 Наблюдаемость
Показывает «что произошло»: trace, стоимость, задержка, ошибки. Легко измерить, но сама по себе она не скажет «правильный ли ответ?»
✅ Оценка (evals)
Измеряет «хорош ли ответ?»: точность, groundedness, безопасность. Нужны явные evals — это страж качества.
Суть в следующем: «стоимость и задержку легко измерить, но качество ответа нельзя узнать без явной оценки». Именно поэтому ведущие инструменты 2026 года не просто показывают trace — они оценивают выходы, оповещают о деградации качества и возвращают выводы в разработку. Наблюдение и оценка — это два колеса одной телеги.
4. За чем следить: ключевые метрики
Показатели, которые стоит отслеживать на дашборде, в целом делятся на «операционные» и «качественные».
⚙️ Операционные (легко измерить)
- Стоимость: плата за токены на запрос
- Задержка: время ответа (сильно зависит от входа)
- Использование токенов: раннее выявление раздутых промптов
- Частота ошибок / пропускная способность: по модели/агенту
🎯 Качественные (нужна оценка)
- Галлюцинация: уверенные, но ложные утверждения
- Groundedness: важнейшее для RAG — подкреплён ли ответ найденными источниками?
- Безопасность: утечка PII, вредный вывод
- Завершение задачи / корректное использование инструментов
Среди качественных метрик в RAG (генерация с дополнением через поиск) «groundedness (достоверность)» — самый критичный показатель: действительно ли ответ подкреплён найденными документами, или модель его выдумала? Для обнаружения галлюцинаций обычно используют LLM-as-a-judge (когда ответ оценивает ИИ), семантическое сходство и оценки groundedness.
5. Сравнение основных инструментов
Вот характерные инструменты наблюдаемости ИИ 2026 года. Многие движутся к тому, чтобы объединить трассировку и оценку в одном месте.
| Инструмент | Особенности | Для чего лучше всего |
|---|---|---|
| LangSmith | Отлично сочетается с LangChain/LangGraph. Подробная трассировка + оценка + мониторинг. Низкие накладные расходы. | Продакшен на базе LangChain |
| Langfuse | Открытый исходный код. Можно развернуть у себя (self-host), поэтому данные не нужно отправлять во внешний SaaS. | Self-hosting / строгие требования к данным |
| Arize Phoenix | Силён в отладке RAG. Хорошо визуализирует качество извлечения. | Исследование/улучшение RAG |
| MLflow | Централизует весь жизненный цикл GenAI. | Сквозной путь от разработки к эксплуатации |
| AgentOps | Специализируется на мониторинге автономных агентов. Отслеживание многошаговых сессий. | Эксплуатация агентов |
| OpenTelemetry | Стандарт. Не зависит от вендора; подключается к Datadog/Grafana и др. | Интеграция с существующим мониторингом |
Источник: различные сравнения инструментов и официальная информация (июнь 2026). Особенности — это тенденции; оценки зависят от сценария и версии.
Если сомневаетесь, безопаснее всего начать собирать trace способом, совместимым с OpenTelemetry. Вы избегаете привязки к вендору и можете позже переориентироваться на другой инструмент. Если вы используете LangChain, удобной точкой входа будет LangSmith; если хотите держать данные у себя — Langfuse.
6. С чего начать и почему это важно для агентов
Не нужно усложнять — начните с малого. Важно встроить наблюдение до того, как вы выпустите систему в продакшен.
Собирайте trace
Фиксируйте вызовы LLM, инструменты и извлечение как span. Совместимость с OpenTelemetry упрощает переход позже.
Визуализируйте операционные метрики
Выводите на дашборд стоимость, задержку и токены. Настройте оповещения при аномалиях.
Подключите оценку (evals)
Оценивайте продакшен-trace по качеству и выявляйте деградацию. Сочетайте evals с ограждениями.
Особенно в мультиагентных системах наблюдение — это не «приятное дополнение», а необходимость. Поскольку сбои прячутся в многошаговых цепочках, без trace всей сессии вы никогда не узнаете, «где и почему всё сломалось». Встройте наблюдение, прежде чем добавлять агентов — таково правило. Оно также помогает раннему обнаружению инцидентов безопасности.
Итоги
Наблюдаемость ИИ — это операционная основа, которая «делает продакшен-ИИ видимым». Подведём итоги.
Ключевые выводы
- 🔭 Делает видимыми внутренности продакшен-ИИ. Три столпа: trace, метрики, логи.
- ⚠️ 200 OK всё равно может врать. Большинство сбоев ИИ — это сбои качества, а не инфраструктуры.
- 🔁 Наблюдать + оценивать вместе. Trace отвечает на «что», evals — на «хорошо ли».
- 🛠️ Инструменты: LangSmith/Langfuse/Phoenix/MLflow/AgentOps. Стандарт — OpenTelemetry.
- 🤖 Необходимы для агентов. Многошаговые сбои видны только в trace всей сессии.
«Быстро и доступно» недостаточно, чтобы доверять ИИ. Он становится продакшен-уровнем только тогда, когда вы можете заглянуть внутрь и измерить качество. Начните со сбора trace способом, совместимым с OpenTelemetry, а затем подключите evals. О построении агентов смотрите здесь; о проектировании безопасности — ограждения.
FAQ
Q. Чем наблюдаемость отличается от оценки (evals)?
A. Наблюдаемость показывает «что произошло» (trace, стоимость, задержка); оценка измеряет «хорош ли ответ». Поскольку ответ может быть быстрым и доступным, но при этом неверным, базовый подход — использовать оба в связке.
Q. Разве нельзя обойтись обычным инструментом мониторинга приложений?
A. Он может измерить доступность и скорость, но не специфическое для ИИ качество — например, галлюцинации или groundedness. Для ИИ нужно специализированное наблюдение (или соглашения GenAI в OpenTelemetry), которое фиксирует промпты, токены и вызовы инструментов.
Q. С чего начать?
A. Безопасно начать со сбора trace способом, совместимым с OpenTelemetry. Вы избегаете привязки к вендору и можете позже выбрать другие инструменты, такие как LangSmith или Langfuse. Затем визуализируйте стоимость и задержку, и в конце подключите оценку.
Q. Почему это особенно важно для агентов?
A. Сбои агентов проявляются не в одном вызове, а внутри многошаговых причинных цепочек. Без trace всей сессии вы не сможете точно определить, «какой шаг пошёл не так и почему», что делает отладку невозможной.
