SLO для AI-агента: какие показатели действительно нужны

Почему доступности сервера недостаточно

SLO — измеримая цель надёжности сервиса за заданный период. Для обычного API успешного HTTP-ответа иногда достаточно, чтобы считать запрос исправным. У AI-агента статус 200 означает лишь то, что транспортный слой сработал.

Полезный ответ агента зависит от всей цепочки: модели, контекста, вызовов инструментов, ограничений безопасности, формата результата и бюджета. Поэтому рабочая система целей должна охватывать четыре измерения:

• доступность: доля задач, завершённых без технического отказа;
• задержка: время до первого полезного события и до полного результата;
• качество: доля результатов, соответствующих проверяемым требованиям;
• стоимость: расход на одну принятую задачу, а не просто на один запрос к модели.

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

Шаг 1. Определите единицу измерения

Начните с пользовательской задачи, а не с отдельного HTTP-запроса. Одна задача может включать повторные обращения к модели, несколько инструментов и восстановление после ошибки.

Зафиксируйте четыре события:

1. task_started — задача принята;
2. first_useful_output — получен первый пригодный для пользователя фрагмент;
3. task_finished — выполнение завершено;
4. task_accepted — результат прошёл автоматическую или ручную проверку.

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

Пример минимальной записи телеметрии:

{
  "task_id": "random-opaque-id",
  "agent_version": "2026-07-28.1",
  "scenario": "document_summary",
  "status": "completed",
  "started_at_ms": 0,
  "first_useful_output_ms": 840,
  "finished_at_ms": 3120,
  "quality_passed": true,
  "estimated_cost_units": 17
}

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

Шаг 2. Задайте четыре отдельных SLO

Доступность задачи

Считайте успешной только технически завершённую задачу. Исключайте из знаменателя явно отменённые пользователем операции и некорректные запросы, если правила исключения определены заранее.

task_availability =
  completed_tasks / eligible_started_tasks

Не относите к успеху пустой ответ, исчерпание лимита шагов или результат, который невозможно разобрать по обязательной схеме.

Задержка

Используйте процентили, а не среднее значение. Минимально нужны две метрики:

time_to_first_useful_output =
  first_useful_output_at - task_started_at

task_completion_time =
  task_finished_at - task_started_at

Разделяйте показатели по классам сценариев. Сравнивать короткую классификацию с многошаговым исследованием бессмысленно. Для каждого класса задайте, например, цели по p95; конкретные пороги должны быть получены из ваших пользовательских ожиданий и базовых измерений.

Качество результата

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

• валидность обязательного формата;
• наличие требуемых полей;
• соответствие результата известным ограничениям;
• корректность вызова инструментов;
• отсутствие запрещённых действий;
• оценка эксперта по заранее описанной рубрике там, где автоматической проверки недостаточно.

quality_success_rate =
  accepted_tasks / evaluated_completed_tasks

Не подменяйте эту метрику самооценкой модели. Модель-судья может быть одним из сигналов, но её следует калибровать на размеченной выборке и отслеживать отдельно.

Стоимость принятого результата

Стоимость одного вызова скрывает повторы и неудачные попытки. Полезнее считать полную стоимость задач, которые прошли проверку:

cost_per_accepted_task =
  total_task_cost / accepted_tasks

В полную стоимость включайте обращения к моделям, платным инструментам и, если это существенно, вычислительные ресурсы. Для оперативного контроля дополнительно измеряйте p95 стоимости одной задачи и долю задач, превысивших бюджет.

Шаг 3. Опишите цели как конфигурацию

Храните цели рядом с версией агента и меняйте их через ревью. Ниже — безопасный пример без адресов, клиентов и секретов:

window: 28d

scenarios:
  document_summary:
    availability:
      target: 0.995
    latency:
      first_useful_output_p95_ms: 2000
      completion_p95_ms: 12000
    quality:
      acceptance_rate_target: 0.97
      minimum_evaluated_tasks: 200
    cost:
      accepted_task_p95_units: 80
      over_budget_rate_target: 0.01

exclusions:
  - user_cancelled
  - invalid_input

Числа здесь условны и служат только примером формата. Перед использованием соберите базовую линию, определите ожидания пользователей и проверьте, что объём выборки позволяет интерпретировать процентили и доли.

Шаг 4. Постройте проверку без утечки данных

Создайте агрегаты по версии агента и сценарию. Если используется Prometheus-совместимый язык запросов, логика проверки может выглядеть так:

# Доля технически завершённых задач
sum(rate(agent_tasks_total{status="completed"}[1h]))
/
sum(rate(agent_tasks_total{eligible="true"}[1h]))

# p95 полного времени выполнения
histogram_quantile(
  0.95,
  sum by (le, scenario) (
    rate(agent_task_duration_seconds_bucket[1h])
  )
)

# Доля принятых результатов
sum(rate(agent_quality_total{result="accepted"}[24h]))
/
sum(rate(agent_quality_total{evaluated="true"}[24h]))

Названия метрик условны. Перед выполнением запроса проверьте их в вашей системе мониторинга. Ограничивайте кардинальность: не помещайте task_id, текст запроса, URL документов или идентификаторы пользователей в labels.

Для алертов используйте два окна. Быстрое окно обнаруживает резкий массовый сбой, медленное — устойчивое расходование допустимого бюджета ошибок. Качество полезно проверять на более длинном окне, поскольку разметка может поступать с задержкой.

Проверка результата

После внедрения проведите воспроизводимую проверку на обезличенной тестовой или разрешённой производственной выборке:

1. Выберите один сценарий и зафиксируйте версию агента.
2. Сверьте число task_started с журналом приёма задач.
3. Вручную проследите несколько технически успешных и неуспешных задач до конечного статуса.
4. Убедитесь, что отмены и некорректный ввод исключаются одинаково в числителе и знаменателе.
5. Пересчитайте p95 и стоимость независимым запросом к агрегированным данным.
6. Сравните решения автоматической проверки качества с небольшой экспертной разметкой.
7. Создайте контролируемое нарушение в тестовой среде: превысьте лимит шагов или верните невалидную схему. Проверьте, что доступность либо качество ухудшились в ожидаемой метрике.

Система считается проверенной, когда для каждой задачи можно объяснить её вклад в числитель, знаменатель, задержку и стоимость, не просматривая чувствительное содержимое.

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

HTTP 200 считается успехом

Разделите транспортный успех и успешное завершение пользовательской задачи.

Один SLO для всех сценариев

Группируйте задачи по сопоставимой сложности и пользовательским ожиданиям.

Качество измеряется только офлайн

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

Среднее скрывает длинный хвост

Контролируйте p95 или p99, а также долю задач за установленным пределом.

Экономия снижает качество незаметно

Смотрите стоимость рядом с acceptance rate и не оптимизируйте её изолированно.

Метрика меняется вместе с агентом

Версионируйте рубрики, наборы проверок и правила исключения независимо от реализации агента.

Алерт срабатывает на малой выборке

Установите минимальное число наблюдений и показывайте размер выборки рядом с процентом.

Ограничения

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

Изменение состава трафика также меняет агрегаты без изменения самого агента. Поэтому сохраняйте распределение сценариев, сравнивайте версии на сопоставимых выборках и отдельно расследуйте критические нарушения безопасности — их нельзя растворять в среднем проценте.

Наконец, SLO описывает приемлемый уровень сервиса, но не заменяет тестирование, трассировку, контроль доступа и процедуру реагирования. Связанные практики собраны в разделе руководств, а определения терминов — в глоссарии.

Итоговая рабочая модель

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

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