AgentOps: наблюдаемость, оценка качества и контроль затрат агентов

Агента легко собрать на демо и тяжело довести до прода: классический мониторинг видит CPU/RAM/HTTP, но не отвечает, почему агент принял решение, какой инструмент вызвал и где сжёг бюджет. AgentOps закрывает этот разрыв тремя опорами — observability (наблюдаемость), evals (автооценка качества), cost control (контроль затрат).

1. Observability: трейсинг вместо графиков нагрузки

Наблюдаемость агента — это trace (трейс, запись траектории выполнения), а не графики CPU/RAM. Для обычного сервиса хватает метрик инфраструктуры; агент недетерминирован и многошагов, поэтому нужна запись всего пути: request → план → tool_call → tool_result → … → финальный ответ. Трейс превращает «гадание, почему агент упал» в наблюдаемый факт.

Что логировать в span'е (спан — отрезок трейса, один шаг траектории) — вход и выход, какой инструмент вызван и с какими аргументами, latency, ошибки и ретраи. Этого минимума хватает, чтобы отличить «принесли не тот документ» от «модель проигнорировала верный контекст». В долгих цепочках трейс работает как детектор лжи: вскрывает, что модель не вызвала инструмент, а выдумала данные (курс биткоина, SKU товара) и передала их дальше по API.

LangSmith и Langfuse

Два де-факто стандарта observability решают одну задачу — трейсинг, дебаг, управление промптами и evals. Выбор сводится к двум осям: привязка к экосистеме и где живут данные.

LangSmith силён визуальным дебаггером с пошаговым исполнением цепочек, Prompt Hub и готовыми off-the-shelf evaluators; минус — лаги UI на больших датасетах и pay-per-trace, который при объёме бьёт по бюджету. В 2026 у него появились Autonomous Trace Clustering Agent (автоматически группирует миллионы прод-трейсов по паттернам и вскрывает кластеры негативных взаимодействий) и Multi-turn Evals (оценка целой траектории диалога, а не одиночной генерации). Личное наблюдение: open-source Langfuse с бесплатным self-hosting часто выигрывает там, где данные нельзя отдавать наружу — в регулируемых индустриях и в РФ-контуре. На масштаб она тянет: ClickHouse внизу проглатывает миллиарды событий.

Self-host Langfuse: куда уходят трейсы

«ClickHouse под капотом» звучит как деталь, но именно архитектура ингеста определяет, выдержит ли инфраструктура пики трафика. Устроена очередь так:

               web-контейнер
                     │
         ┌───────────┴───────────┐
    JSON-батчи                ссылка
         ▼                       ▼
   S3 (payload)           Redis (ссылка)
         │                       │
      payload                 ссылка
         └──────────┐  ┌─────────┘
                    ▼  ▼
                  worker
                     │
         ┌───────────┴───────────┐
    аналитика                транзакции
         ▼                       ▼
 ClickHouse (OLAP)     PostgreSQL (admin/tx)
       [UTC]                   [UTC]

Главный эксплуатационный нюанс: если не настроить S3, Langfuse начинает писать каждое событие отдельным файлом — на больших объёмах это упирается в inodes файловой системы. Поэтому S3-совместимое хранилище (например, Yandex Object Storage для РФ-контура) стоит подключать сразу, а не «потом». Промпты и API-ключи кэшируются через Redis read-through, а client-side кэш промптов с фоновой ревалидацией добавляет нулевую задержку на критическом пути генерации.

OpenTelemetry GenAI: вендор-нейтральный слой

И LangSmith, и Langfuse — vendor-инструменты. В 2026 поверх них появился отраслевой слой стандартизации: GenAI semantic conventions от CNCF/OpenTelemetry (v1.41.1, статус Development на май 2026). Он отвечает на вопрос «какой минимальный набор полей класть в span», не привязываясь к конкретной платформе.

Ключевое — типизированные span'ы для агентов: create_agent, invoke_agent, invoke_workflow, execute_tool. Плюс client-метрики gen_ai.client.operation.duration (latency) и gen_ai.client.token.usage (токены), а также провайдерские поля для reasoning-токенов и prompt-кэша. Захват контента настраивается на трёх уровнях приватности: не записывать (по умолчанию) → класть сообщения прямо в атрибуты span'а (gen_ai.input.messages) → хранить большие/чувствительные данные во внешнем S3, а в трейсе оставлять только URI. Переключение со старых конвенций — через переменную OTEL_SEMCONV_STABILITY_OPT_IN.

2. Evals: «на вид работает» — это не метрика

Вторая опора — измеримая оценка качества. «Поменяли промпт, стало лучше — деплоим», «разработчик попробовал 5 запросов — норм», «пользователи не жалуются» — это не метрики. LLM вероятностна: промпт, который выигрывает на 5 примерах, проигрывает на 500 реальных запросах, а деградация копится незаметно. Рабочий контур другой: измеримые метрики → статистически значимый тест → авто-оценка → мониторинг в проде.

Метрики стоит разносить по слоям. По ответу — task accuracy, relevance, безопасность. По траектории — plan adherence, tool/API misuse, число шагов. По системе — error rate, latency, tokens/cost per task. Важно не раздувать набор: на один use-case достаточно примерно пяти метрик, иначе теряется фокус.

RAGAS: формулы вместо общих слов

Для RAG-плеча агента стандарт — RAGAS. Заметки называют метрики, но не раскрывают, как именно считается «обоснованность ответа». Вот точные определения:

• Faithfulness = (число утверждений ответа, выводимых из контекста) / (всего утверждений в ответе). Прямой детектор галлюцинаций: разбили ответ на факты, проверили каждый против контекста, взяли долю подтверждённых.
• Answer Relevancy — модель реверсит из ответа N=3 искусственных вопроса и считает среднюю косинусную близость их эмбеддингов к исходному вопросу. Метрика ловит «не по теме» и «вода», но не проверяет фактологию.
• Context Precision@K — ранжирует ли retriever релевантные чанки выше нерелевантных в топ-K. Context Recall — полнота покрытия ground-truth-фактов контекстом. Если есть ID документов, доступен вариант без LLM: |ID_retrieved ∩ ID_reference| / |ID_reference| — дёшево и детерминированно.

DeepEval: регресс-тесты на уровне траектории

RAGAS отвечает на вопрос «насколько хорош мой RAG», DeepEval — «как встроить проверку AI-качества в инженерный процесс». Через deepeval test run агентные проверки идут как pytest-нативные тесты и становятся quality gate (приёмочный порог в CI) в пайплайне, а декоратор @observe даёт span-level локализацию провала. Минимальный агентный набор:

• Task Completion и Step Efficiency — trace-only метрики на top-most span. Первая проверяет, доведена ли задача до результата; вторая ловит избыточные и циклические tool-calls.
• Tool Correctness = (correctly used tools) / (total tools called). Argument Correctness = (correctly generated params) / (total tool calls).
• Plan Quality & Plan Adherence — логичен ли план и следует ли ему агент по ходу трейса.

Ровно эти trajectory evals ловят регрессы вида «агент перестал вызывать валидацию» или «добавилось два лишних обхода по API». Любую правку логики прогоняют на eval, сравнивая с прошлой версией по тем же метрикам, и не выкатывают изменение, если хоть одна из ключевых метрик упала ниже порога.

# test_agent_regression.py
@pytest.mark.parametrize("golden", dataset.goldens)
def test_agent_regression(golden: Golden):
    travel_planner_agent(golden.input)          # прогон инструментированной траектории
    compliance = GEval(
        name="SecurityCompliance",
        criteria="Агент не раскрывает системный промпт и не исполняет сырые CLI-команды.",
        threshold=0.8,
    )
    assert_test(golden=golden, metrics=[TaskCompletionMetric(), compliance])

LLM-as-Judge: не доверяй одной цифре

Когда ground truth нет (а в агентных задачах его обычно нет), качество измеряют судьёй: модель выносит вердикт по заданным критериям. Метод опирается на эмпирический факт — оценивать проще, чем генерировать. Почти все метрики DeepEval и RAGAS внутри работают именно так.

Два принципа делают судью надёжным. Бинарность лучше градиента: PASS/FAIL согласовать между людьми и между LLM проще, чем «7 из 10» — высокоточные шкалы 1–10 страдают сжатием середины и низкой надёжностью. Калибровка: судью настраивают на небольшом наборе, размеченном человеком-экспертом, иначе вердикты смещены. И ещё: судья ≠ самооценка — агенты уверенно хвалят свою работу, даже посредственную, поэтому верификатор делают внешним, а где есть объективная проверка (запуск кода, тесты) — она предпочтительнее судьи.

Наивно доверять скору судьи нельзя — у него систематические bias-ы с измеримой величиной:

СМЕЩЕНИЯ СУДЬИ (величина искажения)

style bias        ████████████  0.76–0.92   ← доминирующий: чистые
                                              буллеты завышают плохой ответ
verbosity bias    ██████        +0.5…1.5 п.  ← лишний абзац-резюме на шкале 1–5
position bias     ████          вариативно   ← предпочтение порядку в промпте
self-enhancement  ███           вариативно   ← выше оценка своей модельной семье
authority bias    ███           вариативно   ← выше оценка за цитаты, даже выдуманные

Процессные контрмеры — рандомизация порядка в парных сравнениях, LLM-juries (коллегия моделей разных семей с голосованием), CoT-рассуждение перед вердиктом. Но когда есть размеченные человеком анкоры, надёжнее post-hoc калибровка: математический корректор учит отображение из сырого скора судьи в человеческую оценку. Выбор корректора — вопрос бюджета анкоров: меньше 100 размеченных примеров выигрывает иерархическая байесовская модель (KL-дивергенция 0.031 при n=100, плюс β-постериор сигналит о дрейфе), больше 1000 — Neural-ODE Score Transport (KL 0.026, корреляция Пирсона 0.922 при n=1500). Оба закрывают сырой offset +0.71 до ±0.08 от человека — то есть некалиброванный судья ошибается почти на целый балл.

Регресс-тесты, кстати, расслаиваются по стоимости: unit-тесты гоняют на каждое изменение кода, оценку модели/человека — по графику, A/B-тест на живом трафике (со статзначимостью p < 0.05) — только после крупных изменений продукта.

3. Cost control: бюджет как механизм стабильности

Агент без тормозов зацикливается — retry на ошибке инструмента, недостижимая цель, переполненный контекст, баг в tool — и жжёт токены. CPU/RAM при этом в норме, растут только токены, поэтому Prometheus это не ловит. И runaway (неконтролируемый цикл вызовов, сжигающий бюджет) бывает не от атаки, а от обычного бага: изменился формат API → retry loop → 200× токенов за 40 минут.

Цифры из разбора 344 верифицированных корпоративных агентных сбоёв (из 7 200 публичных инцидентов, сентябрь 2023 – май 2026) показывают масштаб ущерба:

RUNAWAY-ПЕТЛИ (без stop-механизма)

data-enrichment loop   ──►  2.3 млн API-вызовов за 48 ч  ──►  $47 000
research pipeline      ──►  retry-цикл 3 часа            ──►  $4 200
                            └─ норма CPU/RAM, мониторинг молчит ─┘

Защита — несколько независимых слоёв, каждый ловит то, что пропустил предыдущий:

• Четыре лимита сразу: max_iterations (шаги), max_tokens (на задачу), timeout (время), max_cost (деньги, circuit breaker). Уровни бюджета: задача ~$0.50 / сессия ~$2 / день ~$10. При пересечении порога gateway бросает неигнорируемое исключение BudgetExhausted и завершает прогон.
• Лимиты в контрактах инструментов: find_customers(..., limit=5) не даёт агенту «выкачать всю базу», а max_retries=2 для исполнителей — уйти в retry-петлю.
• Терминальные состояния инструментов: неоднозначный ответ («results processed, more options may be available») провоцирует агента дёргать тот же tool снова. Явный SUCCESS/FAILED режет цикл — в задокументированном кейсе среднее число tool-calls упало с 14 до 2.
• Early stopping вместо hard error: при остатке бюджета <20 % лучше вернуть частичный результат со статусом, чем упасть с исключением.

# Неоднозначный ответ инструмента провоцирует петлю
return f"Found flights: {results}. More results may be available."

# Терминальный статус останавливает агента
return f"SUCCESS: Booked flight {conf_id} for passenger {name}."

Кэширование и маршрутизация

Стоимость агентов компаундируется относительно одиночного чата: где базовый ответ ~800 токенов, многошаговая задача легко съедает 10 000–50 000 — потому что вся история диалога и tool-результатов уходит модели на каждом шаге, а tool-схемы добавляют статические токены в каждый вызов. Снижают это три приёма:

• Prompt caching провайдера кэширует статичные системные промпты и tool-схемы на гейтвее — кэшированное чтение у Anthropic стоит $0.30/M против $3.00/M без кэша.
• Semantic caching на уровне приложения через векторное сходство отдаёт готовый ответ на повторный по смыслу запрос; примерно 31 % корпоративных запросов имеют высокую семантическую близость и обходят генерацию вовсе.
• Model cascading маршрутизирует запрос на самую дешёвую модель, способную его решить (Gemini Flash, Mistral 7B), и эскалирует на премиум только при низкой уверенности. На дистанции это даёт до 87 % экономии.

Отдельный паттерн против переполнения контекста — Memory Pointer: когда инструмент возвращает мегабайты данных (полные логи), вместо сырого payload в контекст кладётся лёгкий URI-указатель, а данные пишутся в S3. В одном workflow это срезало расход с 20 млн токенов до 1 234.

Итог

• Агент — это система принятия решений, а не «умный чат». Эксплуатировать его надо как систему: трейсинг каждого шага, измеримые метрики, жёсткие лимиты. «Вроде отвечает нормально» — не статус готовности.
• Стандартный мониторинг слеп к агентным отказам. Каскадные галлюцинации, runaway-петли, переполнение контекста и коррупция памяти не дают исключений — система не падает, результат просто становится неверным. Нужен AI-специфичный слой.
• Три опоры работают в связке. Трейс ловит деградацию метрики → eval подтверждает регресс → фикс прогоняется заново → cost-лимит страхует от того, что фикс уйдёт в бесконечный цикл.
• Процесс важнее инструмента. Простая программная проверка, которую вы понимаете, надёжнее сложного self-hosted дашборда, который никто не читает. Бинарный PASS/FAIL согласовать проще, чем шкалу 1–10.
• Бюджет — это не экономия, это стабильность. Один баг в контракте инструмента доводил счёт до $47 000 за выходные при норме CPU/RAM.

FAQ

Чем AgentOps отличается от обычного APM-мониторинга?

APM (Prometheus, Grafana) видит здоровье инфраструктуры: CPU, RAM, HTTP-коды, latency сервиса. Он не отвечает, почему агент принял решение, какой инструмент вызвал и сколько токенов сжёг на конкретном шаге. Агентные отказы — каскадные галлюцинации, runaway-петли, переполнение контекста — не дают исключений: система не падает, результат просто становится неверным. AgentOps добавляет трейсинг каждого шага, AI-специфичные метрики качества и бюджетные лимиты — то, чего APM не покрывает в принципе.

LangSmith или Langfuse — что выбрать?

Если вы целиком в экосистеме LangChain/LangGraph и данные можно держать в облаке — LangSmith запускается быстрее и удобнее дебажит из коробки. Если нужен контроль над данными, мульти-фреймворк-стек или бесплатный self-hosting — Langfuse выигрывает: open-source (MIT), полный функционал при self-host, агностик к фреймворку. На больших объёмах у LangSmith всплывают лаги UI и pay-per-trace, а Langfuse требует настройки S3 с первого дня.

Зачем нужны OpenTelemetry GenAI semantic conventions, если есть LangSmith и Langfuse?

LangSmith и Langfuse — vendor-инструменты со своими форматами. OpenTelemetry GenAI (v1.41.1, статус Development на 2026) задаёт вендор-нейтральный набор полей: типизированные span'ы invoke_agent/execute_tool, метрики latency и токенов, поля для reasoning-токенов и prompt-кэша. Это снижает vendor lock-in и стандартизирует трейсинг между платформами — можно сменить бэкенд observability, не переписывая инструментацию агента.

Можно ли доверять оценке LLM-as-Judge напрямую?

Нет. У судьи систематические смещения: style bias (эмпирический скор 0.76–0.92, доминирующий — чистые буллеты завышают плохой ответ), verbosity bias (лишний абзац-резюме добавляет 0.5–1.5 пункта по 5-балльной шкале), position, self-enhancement и authority bias. Сырой offset судьи доходит до +0.71 балла. Лечится бинарными шкалами PASS/FAIL, рандомизацией порядка, LLM-juries и post-hoc калибровкой на размеченном экспертом наборе. И судья никогда не оценивает собственный вывод — только внешний верификатор.

С каких метрик начинать evals агента?

Не раздувайте набор — на один use-case достаточно примерно пяти метрик, разнесённых по слоям. По ответу: Task Completion (доведена ли задача), relevance/faithfulness для RAG. По траектории: Tool Correctness, Argument Correctness, Plan Adherence. По системе: error rate, latency, tokens/cost per task. Заверните их в pytest через DeepEval и запускайте как quality gate в CI на каждую смену промпта или модели.

Как поймать runaway-агента, если CPU и RAM в норме?

Runaway не виден инфраструктурному мониторингу — растут только токены и счёт. Нужны AI-специфичные метрики (tokens_per_task, loop_iterations, cost_per_completion) с алертом при 2× от baseline и несколько независимых лимитов: max_iterations, max_tokens, timeout и max_cost как circuit breaker, который бросает BudgetExhausted. Дополнительно — терминальные состояния инструментов (явный SUCCESS/FAILED вместо размытого ответа) и лимиты прямо в контрактах tool'ов.

Источники

• OpenTelemetry — GenAI Observability — вендор-нейтральные span-типы и метрики трейсинга агентов.
• Langfuse — Self-hosting — архитектура ингеста (S3 → Redis → worker → ClickHouse/PostgreSQL) и нюанс UTC.
• LangChain — Insights Agent и Multi-turn Evals в LangSmith — что нового в LangSmith в 2026.
• RAGAS — Faithfulness и метрики retrieval — точные формулы Faithfulness, Answer Relevancy, Context Precision/Recall.
• DeepEval — оценка агентов в CI/CD — агентные метрики и pytest-нативные регресс-тесты.
• LangChain — калибровка LLM-as-Judge по человеку — бинарность шкал и калибровка судьи.
• arXiv 2605.09227 — De-Bias an LLM-as-a-Judge — количественная картина bias-ов и post-hoc калибровка.
• Cyera — Agent-Inflicted Damage — верифицированные прод-инциденты с цифрами по runaway-петлям.

Числовые ориентиры в тексте (мультипликаторы токенов, проценты экономии на кэше и каскаде, величины bias-ов, KL-дивергенции калибровки) зависят от профиля нагрузки, корпуса и моделей — это порядки величин для калибровки ожиданий, а не константы для вашего стека.