Как обучать и оценивать AI-агентов: почему Pass@1 бесполезен и как работает связка SFT + GKD + GRPO

4 минут чтения •


Большинство метрик, по которым сегодня сравнивают языковые модели (вроде Pass@1 на HumanEval или статичных QA-тестах), практически бесполезны, когда дело доходит до автономных агентов в продакшне.

В отличие от классического чат-бота (prompt → response), агент — это динамическая система: модель + обвязка (harness) + инструменты + память + мутабельное окружение + логика восстановления после ошибок.

Разберем, из чего складывается реальная надежность агентов и как устроен современный трехуровневый пайплайн их обучения: SFT → On-Policy Distillation (GKD) → RLVR (GRPO).

4 измерения надежности агента (вместо Pass@1)

Когда агент выполняет транзакционные действия (запись в БД, пуш в репозиторий, исполнение ордеров), статичный процент правильных ответов ничего не говорит о безопасности. В продакшне критичны 4 других фактора:

flowchart TD
    Core["🛡️ 4 измерения надежности агента"]

    C1["🎯 1. Consistency<br/>(Повторяемость результата)"]
    C2["⚡ 2. Robustness<br/>(Устойчивость к шуму API)"]
    C3["🔄 3. Recoverability<br/>(Откат после 5xx и tool errors)"]
    C4["⛔ 4. Failure Severity<br/>(Штраф за деструктивные действия)"]

    Core --> C1
    Core --> C2
    Core --> C3
    Core --> C4
  1. Consistency (Повторяемость): одна и та же задача при повторных прогонах должна давать стабильный результат с контролируемой дисперсией по токенам и времени.
  2. Robustness (Устойчивость к шуму): мелкие изменения в формулировке, смена формата вывода CLI или незначительный шум в API не должны ломать логику рассуждений.
  3. Recoverability (Восстановление): способность агента понять, что инструмент вернул ошибку (404, SyntaxError, пустой вывод), скорректировать гипотезу и продолжить, а не падать в бесконечный цикл.
  4. Failure Severity (Тяжесть сбоя): синтаксическая ошибка tool call должна штрафоваться минимально, а необратимое действие (удаление таблицы или рассинхрон стейта) — приводить к жесткому блокирующему штрафу.

Трехуровневый пайплайн обучения

Обучать агентов только с помощью SFT или только через RL неэффективно. Оптимальный стек пост-тренинга строится в три этапа:

flowchart TD
    S1["1. SFT (Supervised Fine-Tuning)<br/>Приучает к синтаксису tool_call и Loss Masking"]
    S2["2. Distillation (On-Policy GKD)<br/>Перенос навыков учителя + выход из тупиков"]
    S3["3. RLVR (GRPO / Verifiable Rewards)<br/>Максимизация надежности через проверяемые награды"]

    S1 ==>|Формат освоен| S2
    S2 ==>|Траектории исследованы| S3

Этап 1. SFT (Supervised Fine-Tuning)

Этап 2. On-Policy Distillation (GKD / Generalized Knowledge Distillation)

Классическая дистилляция (Off-Policy) подает студенту идеальные траектории учителя-гиганта. В реальности маленькая модель неизбежно ошибается, попадает в незнакомое состояние и «галлюцинирует» (exposure bias).

Этап 3. RLVR и GRPO (Reinforcement Learning with Verifiable Rewards)

Когда формат закреплен, в дело вступает обучение с подкреплением по проверяемому результату. GRPO (Group Relative Policy Optimization) убирает необходимость в отдельной тяжелой модели-критике (Critic Network):

  1. На один входной промпт генерируется группа из $G$ вариантов ($G = 8..16$).
  2. Каждый вариант прогоняется через детерминированный верификатор (тесты, компилятор, линтер).
  3. Награда нормализуется внутри группы: $A_i = \frac{r_i - \text{mean}(R)}{\text{std}(R)}$.
# Концептуальная схема многокомпонентной награды
def calculate_agent_reward(trajectory, test_result):
    return (
        0.2 * format_reward(trajectory)       # Валидный JSON / tool schema
        + 0.6 * execution_reward(test_result) # Unit-тесты пройдены
        + 0.2 * efficiency_reward(trajectory) # Минимальное число шагов
    )

Правило дисперсии: GRPO работает только при наличии вариативности наград. Если все 8 вариантов провалились или все 8 выполнились успешно — обучающий сигнал равен нулю. Задача тренера — подбирать задачи на «границе возможностей» модели.

Главный анти-паттерн: Reward Hacking

Если верификатор наград слаб (например, оценивает только наличие ключевого слова в выводе), RL-агент моментально найдет шорткат: научится вызывать заглушку exit(0) или обходить тесты.

Грейдер должен быть физически изолирован от среды агента (отдельный контейнер / процесс), а валидация обязана проверять фактический граф мутаций файловой системы и БД.

Ключевые выводы

Первоисточники и материалы