Что такое agent evaluation метрика: successful task completion rate vs step efficiency?

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

rate|Completion rate|Completion task rate|completion rate|Completion rate|Completion task rate|completion rate|Successful rate|Completion rate|Completion task rate|completion rate (task completion STCR) и step efficiency — две ключевые метрики для оценки AI-агентов. STCR измеряет долю задач, выполненных полностью и правильно (primary metric). Step efficiency показывает среднее количество шагов (вызовов инструментов/LLM) на успешную задачу. Между ними существует trade-off: агент может делать лишние шаги для повышения уверенности (растёт STCR, но падает efficiency). Оптимальная оценка часто использует composite score, объединяющий обе метрики с бизнес-весами.

1. Определение: Successful Task Completion Rate (STCR)

Successful task completion rate — это доля агентских сессий, в которых задача была завершена с корректным результатом, соответствующим заранее определённым критериям.

• Формула STCR = (число успешно завершённых задач) / (общее число задач)
• Primary metric — главная метрика: если агент не делает то, что нужно, остальные метрики теряют смысл.
• Критерии успеха должны быть формализованы:
  • Точное совпадение ответа (exact match)
  • Похожесть по эмбеддингам (semantic similarity)
  • Чеклист подзадач (subtask completion)
  • Человеческая оценка (human eval)

Пример: Агент-заказчик пиццы. Успех = заказ оформлен, выбраны верные ингредиенты, получено подтверждение. 80 из 100 заказов успешны → STCR = 0.8.

2. Определение: Step Efficiency

Step efficiency — количество шагов (шаг = один вызов LLM или инструмента), которое агент тратит на выполнение задачи. Обычно усредняется только по успешным задачам, чтобы не смешивать с задачами, где агент зациклился.

• Метрика avg_steps = (сумма шагов по успешным задачам) / (число успешных задач)
• Может выражаться как медиана, p90, p99, так как распределение часто скошено.
• Optimization goal минимизировать шаги (снижает стоимость, латентность, потребление токенов).

Зачем это важно Каждый шаг стоит денег (API calls) и времени. В production агент-система должна быть экономически эффективной.

3. Trade-off: Почему STCR и Step Efficiency конфликтуют?

Агент может увеличить STCR, делая дополнительные шаги: перепроверять результаты, запрашивать уточнения у пользователя, повторять неудачные попытки. Но это увеличивает среднее число шагов.

Пример trade-off В задаче поиска информации агент может после первого ответа сделать дополнительный шаг «проверить достоверность источника» — STCR растёт, но добавляется шаг.

4. Composite Score: объединение метрик

Для баланса между качеством и эффективностью используют composite score (взвешенную сумму). Пример формулы:

Composite = w1 * STCR - w2 * (avg_steps / max_steps)

где:

• w1, w2 — веса, определяющие приоритет бизнеса.
• max_steps — нормирующий множитель (например, максимальное допустимое число шагов).
• Знак минус: меньше шагов → выше score.

Вариант с нормализацией

Composite = w1 * STCR + w2 * (1 - avg_steps / max_steps)

Подбор весов

• Финансовый агент: w1 = 0.9 (точность критична), w2 = 0.1 (стоимость вторична).
• Чат-бот поддержки: w1 = 0.5, w2 = 0.5 (быстрота и точность важны одинаково).

Практическое применение Веса уточняются через A/B-тесты или анализ user satisfaction.

5. Контекст задачи: когда какая метрика важнее?

Не для всех задач balance одинаков.

6. Как измерять метрики в production

1. Логирование всех шагов — каждый вызов LLM, вызов инструмента, возврат управления пользователю.
2. Семантическая аннотация успеха — возможна автоматическая проверка (например, ответ содержит требуемые поля) или ручная разметка (human evaluation).
3. Трассировка — инструменты вроде LangSmith, Weights & Biases Traces, Arize AI позволяют собрать полную историю сессии.
4. Агрегация — за период (день, неделя) считаем STCR и avg steps, строим дашборд.

Пример кода (pseudocode):

class AgentEvaluator:
    def __init__(self, success_checker):
        self.success_checker = success_checker
        self.logs = []
    
    def record_session(self, session_id, steps, final_state):
        success = self.success_checker(final_state)
        self.logs.append({'session_id': session_id, 'steps': steps, 'success': success})
    
    def stcr(self):
        successes = sum(1 for log in self.logs if log['success'])
        return successes / len(self.logs) if self.logs else 0
    
    def avg_steps_success(self):
        successful = [log['steps'] for log in self.logs if log['success']]
        return sum(successful) / len(successful) if successful else 0
    
    def composite(self, w1=0.7, w2=0.3, max_steps=10):
        stcr = self.stcr()
        efficiency = 1 - self.avg_steps_success() / max_steps
        return w1 * stcr + w2 * efficiency

7. Подводные камни

• Некорректное определение успеха — если критерий слишком строгий, STCR будет низким, даже если пользователь доволен. Нужен баланс между автоматической и человеческой оценкой.
• Разный масштаб шагов — одни задачи требуют 2 шага, другие 20. Усреднение по всем задачам может быть некорректно. Лучше стратифицировать по типу задачи.
• Early stopping — агент может сам прерваться при неудаче, искажая количество шагов (короткие неудачные сессии). Влияет на avg_steps, если считаем по всем задачам. Рекомендуется считать step efficiency только для успешных.
• Смещение из-за сложности — если в бенчмарке много простых задач, efficiency будет высокой, но в production сложные задачи съедят бюджет. Лучше взвешивать по реальному распределению.

8. Связь с другими метриками (экосистема)

• Cost per task — средняя стоимость токенов и API на задачу. Прямо коррелирует с step efficiency.
• Latency (время ответа) — может нелинейно расти с количеством шагов (из-за последовательных вызовов).
• User satisfaction (NPS/CSAT) — итоговая метрика, на которую влияют и STCR, и скорость.
• Tool call accuracy — доля корректных вызовов инструментов. Влияет на STCR.

9. Best practices при оценке агентов

1. Собирайте бенчмарк из реальных сценариев — минимум 100–500 задач для статистической значимости.
2. Используйте A/B-тестирование — сравнивайте версии агента по STCR и efficiency.
3. Вводите ограничение на max шагов — чтобы избежать бесконечных циклов.
4. Мониторьте отдельно сложные и простые задачи — не усредняйте всё подряд.
5. Периодически делайте human eval — автоматические метрики могут расходиться с реальным качеством.

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

Задача Создать evaluation pipeline для простого AI-агента (на базе LangChain или своими руками), который отвечает на вопросы по документации с помощью поиска. Агент может делать до 5 шагов (search + LLM). Измерить STCR, avg steps и composite score.

Инструменты Python, OpenAI API (или локальная модель), логирование в JSON, дашборд (Plotly Dash или просто matplotlib).

Шаги:

1. Разработать функцию success_checker(answer, gold_standard) — сравнивает ответ с эталоном по semantic similarity (embedding cosine > 0.9).
2. Собрать 20 тестовых вопросов и золотые ответы.
3. Реализовать агента (ReAct pattern) с трассировкой шагов.
4. Прогнать все вопросы, записывая session_id, шаги, success.
5. Вывести STCR, avg_steps_success, composite score.
6. Эксперимент: изменить prompt, чтобы агент перепроверял ответ (добавил шаг reflection). Сравнить метрики.

Ожидаемый результат Таблица с двумя версиями агента и метриками. Вывод о trade-off.

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

Навигация

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