Как в Harness Engineering реализована эвалюация и дрейф (evaluation & drift)?

Краткий тезис

Harness Engineering — платформа для непрерывной поставки AI-агентов, в которой evaluation (оценка качества) и drift detection (обнаружение дрейфа) встроены в CI/CD-пайплайн. Оценка строится на Eval Runner — запуске сценариев с scorers (объективными и LLM‑as‑judge метриками), а Quality Gates блокируют деплой при падении метрик ниже порога. DriftDetector сравнивает поведение агента во времени (семантическая близость ответов, tests|статистические тесты), а Flywheel автоматически собирает неудачные кейсы, улучшает промпты и перезапускает оценку. Такой подход гарантирует, что каждое изменение кода или промпта не ухудшает качество агента.

1. Термины: Evaluation и Drift в контексте AI-агентов

Evaluation (оценка) — процесс измерения качества работы агента на репрезентативном наборе сценариев. В отличие от классического RAG, агент может совершать actions (вызов инструментов, многопоточные диалоги, обращения к памяти), поэтому метрики включают не только качество ответов, но и корректность действий]], соблюдение политик, время выполнения.

Drift (дрейф) — изменение поведения агента со временем, не связанное с намеренными изменениями кода. Причины: обновления базовой LLM (скрытые изменения API), эволюция данных в векторной БД, изменение пользовательских паттернов. Дрейф может быть тихим — метрики ещё в норме, но стиль или тональность ответов изменились.

Harness Engineering — open‑source платформа (репозиторий harness-one/devkit), предоставляющая инструменты для построения, развёртывания и мониторинга AI-агентов. Её модуль evaluation/drift — это ответ на необходимость continuous AI quality assurance.

2. Eval Runner: инфраструктура оценки

Eval Runner — компонент, который берёт набор сценариев (test suite) и прогоняет агента через каждый из них, собирая результаты и вычисляя метрики.

Сценарий (scenario) состоит из:

• входных данных (user query, контекст, начальное состояние)
• ожидаемого результата (golden answer, последовательность действий, ограничения)
• конфигурации scorers (какие метрики применять)

Scorers — функции, оценивающие качество. В Harness используются три типа:

Пример конфигурации (yaml):

eval_suite:
  scenarios:
    - name: "book_flight"
      input: "Забронируй билет из Москвы в Лондон на завтра"
      expected: { action: "book_flight", params: { from: "Moscow", to: "London" } }
      scorers: ["exact_match_action", "faithfulness", "latency < 5s"]
  runners:
    - model: "gpt-4"
    - model: "claude-3"

Результат запуска — таблица со скорами по каждому сценарию и агрегированные метрики (среднее, процентили).

3. Quality Gates: контрольные точки развёртывания

Quality Gate — это пороговое правило, которое проверяется после прогона Eval Runner. Если метрика не достигает порога, пайплайн останавливается, и новая версия агента не деплоится.

Примеры типичных gate'ов

• Faithfulness >= 0.9 (не менее 90% фактов в ответе подтверждаются контекстом)
• Answer Relevance >= 0.85 (ответ релевантен запросу по оценке LLM)
• Action Success Rate >= 0.95 (доля корректно выполненных инструментов)
• Latency P95 < 3 секунды

Quality gates могут быть жёсткими (блокирующими) и предупреждающими (log warning, но деплой разрешён). В Harness gate'ы конфигурируются в harness.yaml:

quality_gates:
  - metric: "faithfulness"
    threshold: 0.9
    action: "block"
  - metric: "latency_p95"
    threshold: 3000  # ms
    action: "warn"

Такой подход превращает оценку агента в часть CI/CD — каждое изменение кода, промпта или инструмента проходит через автоматическую проверку.

4. DriftDetector: обнаружение дрейфа поведения

DriftDetector — модуль, который сравнивает текущее поведение агента с «базовым» (reference), зафиксированным в момент последнего успешного релиза.

4.1 Типы дрейфа, обнаруживаемые DriftDetector

4.2 Техника сравнения распределений

DriftDetector использует embedding-based approach:

1. Для каждого сценария из тестового набора генерируется эмбеддинг ответа (например, через all‑MiniLM).
2. Совокупность эмбеддингов за текущий период образует многомерное распределение.
3. С помощью Maximum Mean Discrepancy (MMD) или Wasserstein distance сравнивается с распределением reference.
4. Если расстояние превышает порог (например, 0.1), фиксируется дрейф.

4.3 Статистический мониторинг

Для метрик (faithfulness, latency) используется CUSUM (Cumulative Sum) — алгоритм обнаружения сдвига среднего. Когда сумма отклонений превышает порог, генерируется alert.

# Упрощённый CUSUM для drifting метрики
threshold = 0.05
cumulative = 0
for new_value in online_stream:
    cumulative += (new_value - baseline_mean)
    if abs(cumulative) > threshold:
        alert("Drift detected")
        cumulative = 0

5. Flywheel: цикл непрерывного улучшения

Flywheel (маховик) — механизм, который использует результаты evaluation и drift detection для автоматического улучшения агента.

Этапы цикла

1. Сбор failed кейсов — сценарии, на которых агент показал низкий score или обнаружен дрейф, помечаются как «программные ошибки».
2. Анализ — Harness группирует failed кейсы по корневой причине (плохой промпт, неверный инструмент, устаревшая документация).
3. Генерация улучшений — используя LLM, предлагаются изменения промптов (prompt refinement) или правил маршрутизации.
4. Тестирование — изменённый агент прогоняется через тот же Eval Runner, и если Quality Gates проходятся, новая версия предлагается к деплою.
5. Эскалация — если автоматическое улучшение не справляется, кейс передаётся человеку.

Этот цикл делает систему самовосстанавливающейся: дрейф автоматически выявляется и исправляется без ручного вмешательства.

6. Интеграция с CI/CD пайплайном

Harness Engineering встраивает evaluation и drift detection в git-ориентированный workflow:

• Pull Request → запуск Eval Runner на ограниченном наборе сценариев (smoke tests)
• Merge в main → полный прогон (regression suite) с Quality Gates
• Ежедневный scheduled run → DriftDetector сравнивает с baseline и генерирует отчёт
• Каждые N релизов → рекалибрация baseline (фиксация нового reference)

Пример пайплайна в GitHub Actions

- name: Run Eval Suite
  run: |
    harness eval run --suite integration-tests.yaml
- name: Check Quality Gates
  run: |
    harness eval gates --thresholds quality-gates.yaml

7. Сравнение с традиционным ML drift

8. Пет-проект для закрепления

Задача Реализовать упрощённую версию Eval Runner + DriftDetector для агента с одним инструментом (поиск погоды).

Инструменты Python, LangChain/LlamaIndex, sentence‑transformers, scipy, Docker.

Шаги:

1. Создайте агента, который вызывает API погоды (mock).
2. Напишите 10 сценариев с ожидаемыми вызовами инструмента.
3. Реализуйте EvalRunner: прогон агента, сбор метрик (exact match города, время ответа).
4. Реализуйте DriftDetector на основе эмбеддингов: сохраните эмбеддинги ответов первой версии, при изменении промпта сравните с помощью MMD.
5. Добавьте QualityGate: если точность < 80% — запретить деплой.
6. Создайте Flywheel: при падении метрики автоматически сгенерируйте новый промпт (через LLM) и перезапустите оценку.

Ожидаемый результат Консольный инструмент, который при изменении промпта показывает delta метрик и блокирует «плохие» версии. Вы научитесь основам continuous evaluation для AI-агентов.

9. Связь с другими вопросами

Навигация

• Предыдущий: 747
• Следующий: 749
• Индекс: 00. Индекс разборов