Как вы делаете agent evaluation на длинных horizon (100+ шагов)?

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

Оценка агентов на длинных горизонтах (100+ шагов) принципиально сложнее, чем на коротких траекториях, из-за экспоненциального роста возможных путей, разреженности поощрений и композициональности подзадач. Основной подход — разбиение длинной траектории на milestone (промежуточные вехи) с проверкой их достижения, логирование состояния на каждом шаге для state reconstruction, использование специализированных бенчмарков (AgentBench, WebShop, ALFWorld) и семплирование траекторий через множество случайных seed'ов для достоверной оценки. Ключевые метрики — milestone completion rate, average steps per milestone, success rate на полной задаче.

1. Термин: Horizon (горизонт) в контексте AI-агентов

Horizon — это максимальная длина траектории (количество шагов), которую агент может выполнить до завершения эпизода. В задачах с длинным горизонтом (>100 шагов) агент должен принимать последовательные решения в течение длительного времени, часто с отложенным вознаграждением.

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

2. Проблемы оценки на длинных горизонтах

2.1 Экспоненциальный рост траекторий

Если на каждом шаге агент может выбрать из A действий, то после H шагов количество возможных траекторий — A^H. При A=10 и H=100 это 10^100 вариантов — полный перебор невозможен. Поэтому оценка требует семплирования (тестирования на конечном наборе начальных условий и seed'ов).

2.2 Разреженная награда (sparse reward)

В длинных задачах вознаграждение часто приходит только в конце эпизода (успех/неудача). Это затрудняет обучение с подкреплением (RL) и оценку «что пошло не так». Даже при успешном финале агент мог делать неоптимальные шаги.

2.3 Композициональность подзадач

Длинная траектория естественно разбивается на несколько этапов (подзадач). Каждый этап может быть выполнен или нет, а общий успех зависит от последовательного выполнения всех этапов. Оценка только финального успеха не даёт понимания, на каком этапе произошёл сбой.

2.4 Нестабильность из-за рандомизации

Даже одинаковые агенты с одними и теми же параметрами могут вести себя по-разному из-за случайности в генерации LLM, энвайронмента или начальных условиях. Для достоверной оценки требуется множество повторных запусков (обычно не менее 50–100).

3. Подход: Milestone Evaluation (оценка по вехам)

Milestone — это проверяемое условие, которое должно быть истинно на определённом этапе траектории (например, «агент успешно авторизовался», «агент нашёл нужную статью», «агент отправил корректный SQL-запрос»).

3.1 Разбиение задачи на milestone

1. Анализ задачи — выделить логические шаги (вход, поиск, обработка, вывод).
2. Определение инвариантов — условия, которые должны выполняться после каждого шага (например, для веб-агента — «текущий URL — это страница результатов поиска»).
3. Автоматическая проверка — написать скрипты или использовать LLM-as-judge для проверки каждого milestone.

Пример для агента, бронирующего билет:

• Milestone 1: агент открыл страницу входа.
• Milestone 2: агент успешно аутентифицирован.
• Milestone 3: агент ввёл корректные параметры поиска.
• Milestone 4: агент выбрал предложение.
• Milestone 5: агент завершил оплату.

3.2 Метрики на основе milestone

3.3 Пример кода для подсчёта MCR

def compute_mcr(trajectory, milestone_checks):
    """
    trajectory: список шагов (состояний) агента
    milestone_checks: список функций, возвращающих bool для состояния
    """
    achievements = 0
    for step, state in enumerate(trajectory):
        for check in milestone_checks:
            if check(state):
                achievements += 1
                milestone_checks.remove(check)  # одноразовый milestone
                break
    total_milestones = len(milestone_checks) + achievements
    return achievements / total_milestones if total_milestones > 0 else 0

4. State Reconstruction (восстановление состояния)

Для оценки на длинных горизонтах необходимо логировать состояние на каждом шаге — контекст агента, результат выполнения инструментов, внутренние рассуждения (chain-of-thought). После завершения траектории можно «переиграть» сценарий: изменить решение на некотором шаге и оценить, как изменился результат. Это называется state reconstruction.

4.1 Формат лога

Каждый шаг должен содержать:

• timestamp
• action (текст вызова инструмента)
• observation (результат)
• internal_state (текущий системный промпт, историю сообщений, буфер контекста)
• milestones_achieved (список достигнутых вех)

4.2 Использование reconstruction

• Ablation studies: удалить один модуль (например, retrieval) на определённом шаге и проверить влияние.
• Error analysis: если финальный результат плох, восстановить момент первой ошибки и проанализировать её причину.
• Data augmentation: генерировать альтернативные траектории, заменяя некоторые действия на допустимые альтернативы.

5. Инструменты и бенчмарки

5.1 Специализированные бенчмарки для длинных горизонтов

Для длинных горизонтов (100+ шагов) лучше всего подходят AgentBench (с вариацией на 150 шагов) и Minecraft-подобные среды.

5.2 Фреймворки для оценки

• LangSmith — трекинг шагов, возможность добавлять пользовательские метрики (milestone).
• MLflow — логирование параметров, метрик, артефактов для каждой траектории.
• OpenAI Evals — расширяемая система с поддержкой кастомных сценариев.

6. Метрики для длинных горизонтов (детализация)

Помимо milestone-based метрик, используются:

• Success Rate (SR): доля эпизодов, в которых финальная цель достигнута. Основная метрика, но недостаточная — траектория может быть неоптимальной.
• Cumulative Reward: если в среде есть промежуточные награды, суммируем их. Помогает различать «еле выполнил» и «оптимально выполнил».
• Average Steps per Success (SPS): среднее количество шагов среди успешных эпизодов. Чем меньше — тем эффективнее агент.
• Cost per Episode: для агентов на LLM — количество токенов/вызовов. Важно для production.
• Entropy of Actions: мера разнообразия действий. Высокая энтропия может указывать на нестабильность.

6.1 Сравнение метрик на примере

7. Стратегии семплирования и достоверность оценки

Из-за стохастичности агентов (разные температуры, разные начальные seed'ы) оценивать нужно на множестве запусков.

7.1 Рекомендации

• Минимум 100 запусков для достоверной оценки success rate (ошибка ~1/sqrt(N) ≈ 10% при 100).
• Фиксировать seed для энвайронмента и агента (если возможно) — так можно воспроизвести сценарий.
• Стратифицированное семплирование: если среда различается по сложности (разные страницы, разные товары), убедитесь, что выборка репрезентативна.

7.2 Пример: оценка с использованием random seed

import numpy as np

def evaluate_agent(agent, env, num_episodes=100):
    successes = []
    milestone_rates = []
    for episode in range(num_episodes):
        seed = episode  # или random.randint(...)
        env.seed(seed)
        agent.reset()
        trajectory = []
        done = False
        while not done:
            action = agent.select_action()
            obs, reward, done, info = env.step(action)
            trajectory.append((action, obs))
        success = info.get('success', False)
        successes.append(success)
        milestone_rates.append(compute_mcr(trajectory, MILESTONES))
    return {
        'success_rate': np.mean(successes),
        'mean_mcr': np.mean(milestone_rates),
        'std_mcr': np.std(milestone_rates),
    }

8. Особенности для Agentic RAG

В Agentic RAG длинный горизонт часто связан с многораундовым диалогом, где агент уточняет запрос, ищет в нескольких источниках, агрегирует информацию. Здесь дополнительно нужно оценивать:

• Faithfulness — насколько финальный ответ соответствует найденным документам (даже на длинной траектории).
• Context relevance — каждый промежуточный контекст (выдача поиска) должен быть релевантен текущему подзапросу.
• Tool call success — доля вызовов инструментов (API, поиск) без ошибок.

Для этого можно комбинировать RAG-метрики (RAGAS) с агентскими метриками. Например, после каждого вызова поиска проверять faithfulness извлечённых сниппетов.

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

Задача

Реализовать среду для симуляции агента, выполняющего покупку в интернет-магазине (10 шагов — короткий горизонт, 100 шагов — длинный). Оценить агента на длинном горизонте с помощью milestone.

Инструменты

• Python + Gymnasium (для создания среды)
• LangChain / CrewAI (для агента)
• LangSmith (логирование)
• Streamlit (визуализация результатов)

Шаги

1. Создать среду MarketEnv с двумя режимами: 10 шагов (быстрый сценарий) и 100 шагов (длинный сценарий, где нужно взаимодействовать с несколькими отделами, возвращаться, уточнять).
2. Определить milestone: «открыта главная страница», «найден товар», «добавлен в корзину», «оформлен заказ» и т.д.
3. Реализовать простого агента (ReAct, tool use).
4. Запустить оценку 100 эпизодов, собрать success rate и MCR.
5. Провести анализ: на каких milestone агент чаще всего ошибается? Построить гистограмму first failure step.

Ожидаемый результат

• Таблица с метриками (SR, MCR, Steps per milestone) для короткого и длинного горизонтов.
• График, показывающий распределение steps до первого failure.
• Вывод: на длинном горизонте MCR падает, так как агент накапливает ошибки.

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

Навигация

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