Skip to main content
Failproof AI Observability может автоматически оценивать качество каждого завершённого запуска агента: вы предоставляете небольшой сервис оценки, а Observability берёт на себя остальное. Используйте её для отслеживания интересующих вас параметров (полезность, эффективность инструментов, фактичность, безопасность — выбираете вы), раннего выявления регрессий и быстрого сравнения агентов или окружений. Оценка является дополнительной функцией: конвейер ничего не делает, пока вы не установите EVALUATOR_ENDPOINT на сервере.
Примечание: Вы определяете параметры оценки. Ваш оценивающий сервис может возвращать любые числовые ключи; Observability сохраняет, отслеживает и отображает всё, что вы отправляете.

Кратко

  1. Напишите оценивающий сервис. Создайте небольшой HTTP-сервис, который читает транскрипт сессии и возвращает оценки. Observability поставляется с рабочим примером, который вы можете скопировать. См. Написание оценивающего сервиса с SDK.
  2. Укажите Observability на него. Установите EVALUATOR_ENDPOINT (и общий EVALUATOR_TOKEN) на процесс сервера.
  3. Смотрите, как появляются оценки. Каждая завершённая сессия автоматически оценивается; результаты отображаются на странице деталей сессии, в сетке сессий и на сохранённых панелях.
Представление деталей сессии с резюме оценки, полосами оценок по параметрам и текстом обоснования на правой панели После настройки оценивающего сервиса каждый завершённый запуск оценивается, и результаты появляются на правой панели сессии: резюме вверху, затем полосы оценок по параметрам с обоснованием.

Как это работает

Когда Failproof AI Observability SDK генерирует событие agent_end для сессии, сервер планирует оценку. Затем он отправляет полный транскрипт событий в ваш оценивающий сервис, который может:
  • Вернуть результат сразу с {"status":"done", "scores":{...}, "reasoning":{...}, "summary":"..."}. Результат добавляется в временную линию оценок сессии. reasoning и summary опциональны.
  • Отложить с {"status":"pending", "job_id":"abc-123"}. Observability затем вызывает GET {EVALUATOR_ENDPOINT}/evaluate/abc-123 до тех пор, пока ваш оценивающий сервис не вернёт {"status":"done", ...} или {"status":"error", "error":"..."}. Интервал опроса зависит от задачи: ответ pending может включать next_poll_secs для переопределения; в противном случае Observability использует значение default_poll_interval_secs из GET /config; если его нет, сервер использует EVALUATOR_POLLING_INTERVAL_SECS (по умолчанию 10 сек). Все значения ограничиваются диапазоном [1 сек, 1 ч].
Сессии, которые никогда не генерируют agent_end (например, упавший процесс агента), также могут быть обработаны: конфигурация оценивающего сервиса GET /config может возвращать {"inactivity_timeout_secs": 1800}, и Observability будет оценивать любую сессию, которая неактивна в течение этого времени. Установите поле в null или опустите его, чтобы отключить этот резервный механизм. Конвейер полностью неактивен, когда EVALUATOR_ENDPOINT не установлен. Сессия может накапливать несколько финальных оценок в течение времени: каждое событие agent_end (и каждая ручная переоценка с панели) добавляет свежую строку оценки. Это поддерживаемый способ оценки продолжённой беседы: пользователь завершает работу агента, возвращается позже, отправляет больше событий, завершает работу агента снова, и вторая оценка запускается против полного обновлённого транскрипта. Панель отображает самую последнюю оценку как заголовок, а предыдущие оценки как свёртываемую временную линию. Пока одна оценка выполняется для сессии, дополнительные события agent_end для этой сессии игнорируются; следующий после завершения выполняемой оценки будет поставлен в очередь для свежей оценки как обычно. Резервный механизм неактивности повторно активируется и на возобновлённых сессиях: если новые события поступают после предыдущей финальной оценки и сессия затем становится неактивной дольше inactivity_timeout_secs, свежая оценка ставится в очередь. Преходящие сбои (5xx, 429, таймауты, сетевые ошибки) повторяются с экспоненциальной задержкой до EVALUATOR_MAX_ATTEMPTS; ответы 4xx являются финальными. Observability безопасно запускается с несколькими горизонтально масштабируемыми экземплярами сервера; работа разбита так, чтобы одна сессия никогда не была отправлена дважды одновременно.

HTTP контракт

Каждый защищённый маршрут использует аутентификацию по токену носителя. Одно и то же значение должно быть настроено с обеих сторон:
  • Сервер Observability: переменная окружения EVALUATOR_TOKEN
  • Сервис оценки: настроен аналогично (SDK agenteye-evaluator по соглашению читает EVALUATOR_TOKEN)
Если EVALUATOR_TOKEN не установлен, сервер не отправляет заголовок Authorization; оценивающий сервис может затем принимать анонимные запросы, что нормально для сети только внутри, но не рекомендуется в открытом интернете.

Маршруты, которые должен обслуживать оценивающий сервис

Тело EvalRequest, отправляемое сервером

Формы ответов

Синхронная (готово):
reasoning (карта обоснований для каждой оценки) и summary (общее описание в один абзац) оба опциональны. Ключи в reasoning должны соответствовать ключам в scores; панель отображает каждую запись встроенной под её полосой оценки. Старые оценивающие сервисы, возвращающие только scores, продолжают работать без изменений; reasoning и summary просто читаются как null и соответствующие элементы UI опускаются. Асинхронная (отложенная):
next_poll_secs опционален; если опущен, сервер использует default_poll_interval_secs оценивающего сервиса из /config, затем его собственную переменную окружения EVALUATOR_POLLING_INTERVAL_SECS. Финальная ошибка на стороне оценивающего сервиса:
Сервер обрабатывает любое другое тело 2xx как ошибку протокола и записывает финальную error для сессии.

Написание оценивающего сервиса с SDK

Вам не нужно реализовывать HTTP контракт вручную. Пакет Python agenteye-evaluator предоставляет типизированную обёртку FastAPI, которая обрабатывает аутентификацию, маршрутизацию и формы запроса/ответа для вас. Failproof AI Observability также поставляется с рабочим примером оценивающего сервиса, который оценивает helpfulness, tool_efficiency и factuality на основе формы транскрипта. Скопируйте его как отправную точку и замените вашей собственной логикой: судья LLM, механизм правил, что угодно, соответствующее вашему уровню качества. Минимально жизнеспособный оценивающий сервис:
Экземпляр app работает под любым ASGI сервером, поэтому uvicorn module:app его запускает. Для оценивающих сервисов, которым нужно отложить дорогостоящую работу, верните JobPending вместо этого и зарегистрируйте обработчик @app.job_lookup; сервер Observability опрашивает GET /evaluate/{job_id} до тех пор, пока вы не вернёте финальный статус или не истечёт лимит EVALUATOR_MAX_POLL_DURATION_SECS (по умолчанию 1 ч). Полный справочник API, асинхронный паттерн и схема событий задокументированы в README SDK agenteye-evaluator.

Запуск вашего оценивающего сервиса

Оценивающий сервис — ваш сервис — Failproof AI Observability не поставляет оценивающий сервис по умолчанию, поэтому вы строите и запускаете его там же, где запускаете ваши сервисы. Он работает под любым ASGI сервером (например uvicorn my_evaluator:app); обслуживайте маршруты /health, /config и /evaluate из HTTP контракта, затем укажите на него сервер (см. Настройка сервера). Как только оценивающий сервис доступен, GET /health возвращает {"status":"ok"}. После того как агент завершит работу полностью, GET /evaluations на сервере возвращает строку с status: "done" и оценками, которые произвёл ваш оценивающий сервис.

Настройка сервера

Установите на процесс сервера: Чтобы включить автоматическую оценку, установите EVALUATOR_ENDPOINT и EVALUATOR_TOKEN на сервере, затем перезагрузите его, чтобы применить изменение. С EVALUATOR_ENDPOINT не установленным конвейер остаётся неактивным. Вышеуказанные настраиваемые параметры опциональны; устанавливайте соответствующие переменные окружения на сервере только если вам нужно переопределить значения по умолчанию.

Справочник API

Фильтрация по диапазону оценок: score_filters

GET /evaluations принимает дополнительный параметр score_filters, который сужает результаты по числовым значениям внутри объекта scores. Параметр является списком, разделённым запятыми, записей key:min..max; любая граница может быть опущена. Несколько записей объединяются логическим И. Строки, где названный ключ отсутствует или не числовой, исключены. Запрос может содержать максимум 20 записей фильтра; превышение этого возвращает HTTP 400. Примеры:
Каждый объект ответа /evaluations имеет эти поля:

Разрешения

Администратор начальной загрузки (ADMIN_KEY, ADMIN_EMAIL) автоматически получает эти.

Просмотр результатов

  • /sessions/<id>: временная линия событий + правая панель, отображающая оценки сессии и любую ошибку попытки отправки. Если ваш ключ имеет evaluations:trigger, кнопка переоценить появляется рядом с кнопкой экспорта, полезно для сессий, которые никогда не генерировали agent_end, или для обновления оценок после развёртывания нового оценивающего сервиса. Панель опрашивает новый результат и обновляет правую панель когда он приходит.
  • /sessions: фильтруемая сетка сессий; столбец оценок показывает статус оценки каждой сессии и оценки с первого взгляда.
  • /dashboards: сохранённые представления здоровья оценок (см. Dashboards ниже).
Сетка Sessions с табличками статуса оценки для каждой сессии и значками оценок с цветовой кодировкой (helpfulness, factuality, tool_efficiency, safety, coherence) Сетка сессий показывает статус оценки каждого запуска и оценки с первого взгляда; красные/янтарные/зелёные значки выделяют низкие оценки.

Dashboards

Страница Dashboards (/dashboards) позволяет вам сохранить комбинацию фильтров оценок как именованное, переиспользуемое представление и смотреть, как этот срез оценок работает с первого взгляда. Dashboards совместно используются всей вашей организацией; все с dashboards:read видят одно и то же множество. Каждая панель закрепляет:
  • Filters: те же элементы управления, что на странице сессий: окружение, статус, агент, скользящее окно времени и фильтры диапазонов оценок (key:min..max).
  • Конфигурацию отображения: какие ключи оценок выделить, пороги здоровья зелёный/янтарный/красный, какие панели показывать и сворачивать ли на самую последнюю оценку для каждой сессии.
Каждая карточка показывает количество совпадающих сессий, разбор done/error/timeout, среднее значение каждой выделенной оценки и небольшую тренд-спарклайн. Открытие панели показывает полные панели; “открыть в сессиях” берёт вас на страницу сессий с предустановленным фильтром на точно этот срез. Метрики вычисляются на сервере по всему совпадающему набору (через GET /evaluations/aggregate), поэтому числа точные вместо выборки. Панель здоровья оценок со средними полосами оценок для каждого измерения оценивающего сервиса, разбором инструментов ok-vs-error, топ-инструментами и трендом событий в час Разрешения: просмотр нуждается в dashboards:read и evaluations:read; создание и редактирование нужны dashboards:write; удаление нужно dashboards:delete. Администратор начальной загрузки автоматически получает все эти.

Решение проблем

Сессии существуют, но оценки не создаются. Подтвердите, что EVALUATOR_ENDPOINT установлен на процесс сервера, что сервер и оценивающий сервис разделяют одно и то же значение EVALUATOR_TOKEN, и что конечная точка /health оценивающего сервиса доступна с сервера. С EVALUATOR_ENDPOINT не установленным конвейер неактивен. Выполняемые оценки накапливаются. Запросите GET /evaluation-jobs, чтобы увидеть очередь выполняемых. Проверьте attempt_count, next_attempt_at и last_error на каждой строке. Обычные причины: сервис оценки недоступен или возвращает 5xx (повторяется с задержкой), неправильный EVALUATOR_TOKEN (401 является финальной), или асинхронный оценивающий сервис, который возвращает pending бесконечно (см. ниже). Сессии завершены, но нет финальной оценки. Запросите GET /evaluation-jobs?status=polling; результат может всё ещё выполняться. Если задача зависла на pending, сервер испытывает сложности с доступом к оценивающему сервису; проверьте, что оценивающий сервис работает и что EVALUATOR_TOKEN совпадает. HTTP 401 от оценивающего сервиса: неверный токен носителя. EVALUATOR_TOKEN на сервере не совпадает со значением, с которым настроен сервис оценки. Они должны быть идентичны. Асинхронный оценивающий сервис возвращает pending бесконечно. Сервер опрашивает GET /evaluate/{job_id} до тех пор, пока оценивающий сервис не вернёт done или error, или пока не истечёт EVALUATOR_MAX_POLL_DURATION_SECS (по умолчанию 1 ч). После лимита оценка записывается как timeout и удаляется из очереди выполняемых. Увеличьте EVALUATOR_MAX_POLL_DURATION_SECS, если ваш оценивающий сервис законно нуждается в большем времени, чем по умолчанию.

Следующие шаги

  • Evaluator agent skill: попросите кодирующего агента спроектировать ваши параметры на основе реальных сессий и построить для вас этот сервис.
  • Python SDK: генерируйте события agent_end, которые запускают оценку.
  • API keys: разрешения evaluations:read и evaluations:trigger.
  • Audits: другая автоматизированная функция качества Observability для проверки на основе политик.