Как работает agent replay для улучшения качества (анализ failed траекторий)?

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

Agent replay — это циклический процесс сбора неудачных траекторий агента (failed sessions), их детального воспроизведения для выявления точки отказа, ручной разметки экспертом и дообучения модели (обычно через DPO на парах «trajectory|плохая траектория / trajectory|хорошая траектория»). После улучшения системы автоматически перезапускаются проблемные запросы с новой версией агента (retry policy). В результате quality агента растёт итеративно, а затраты на ручную разметку остаются управляемыми.

1. Зачем нужен agent replay?

В production-среде AI-агент (набор LLM-вызовов с инструментами) неизбежно совершает ошибки: неверно выбирает инструмент, генерирует некорректные параметры, зацикливается или даёт нерелевантный ответ. Простое логирование логов не помогает — нужно понять, почему произошла ошибка, и исправить саму модель.

Agent replay позволяет:

1. Локализовать конкретный шаг, на котором агент отклонился от правильного пути.
2. Собрать обучающие примеры для fine-tuning (например, через DPO — Direct Preference Optimization).
3. Автоматически ретестить исправления на реальных failed-запросах.

Без replay улучшение качества агента — это «чёрный ящик»: метрики падают, а причину найти трудно.

2. Сбор и логирование failed траекторий

Первый этап — логирование всех сессий агента. Для каждой сессии записываем:

• user query (входной запрос);
• мысль/рассуждение (chain-of-thought или plan);
• действия (вызов инструментов с параметрами);
• результаты (success/failure, feedback пользователя, latency, cost);
• метаданные (ID сессии, версия модели, timestamp).

Неудачные сессии (failure) определяются по:

• явному dislike/report от пользователя;
• невыполнению задачи (timeout, maximum steps exceeded);
• невалидному ответу (бланк, противоположный смыслу).

Термин «Failed траектория» — последовательность шагов агента (action-observation-thought), завершившаяся неудовлетворительным результатом.

Инструменты: LangSmith, MLflow Tracing, Phoenix Arize, custom logging в Elasticsearch.

3. Replay: воспроизведение траектории и поиск точки отказа

После сбора failed сессии её воспроизводят (replay) в изоляции:

1. Загружают трассировку (trace) — последовательность всех шагов с входными и выходными данными.
2. Подают те же самые входные данные на каждый шаг, но фиксируя точку, где агент принял неверное решение.
3. Сравнивают с эталонным (gold) поведением — либо руками размеченным, либо сгенерированным сильной моделью (GPT-4, Claude).

Точка отказа — это шаг, после которого траектория стала необратимо неверной (например, агент вызвал tool с неверным аргументом или завершил диалог раньше времени).

Точка отказа здесь — шаг 2.

4. Manual annotation: роль эксперта

После обнаружения точки отказа эксперт-аннотатор (data labeler) вручную помечает правильное действие на этом шаге. Это генерирует положительный пример (preferred trajectory) для DPO.

Process

1. Показать эксперту failed траекторию и подсветить шаг с ошибкой.
2. Предложить исправить этот шаг (выбрать правильный инструмент, верные параметры).
3. Автоматически достроить остаток траектории (перезапустить агента с исправленного шага) — это даёт хорошую траекторию.
4. Сохранить пару: (failed траектория, good траектория) для обучения.

Manual annotation дорог, поэтому его применяют выборочно:

• на самых частых ошибках;
• на запросах, где цена ошибки высока (финансы, медицина).

5. Fine-tuning (DPO) на парах траекторий

Direct Preference Optimization (DPO) — метод обучения модели на парах «предпочтительная / непредпочтительная» траектория без явного обучения reward-модели. Формула DPO:

L(π_θ) = -E_{(x, y_w, y_l) ~ D}[ log σ(β * (log(π_θ(y_w|x) / π_ref(y_w|x)) - log(π_θ(y_l|x) / π_ref(y_l|x)))) ]

Где:

• y_w — хорошая траектория (preferred);
• y_l — плохая траектория (dispreferred);
• π_ref — референсная модель (замороженная);
• π_θ — обучаемая модель;
• β — температурный параметр.

На практике:

1. Агент генерирует две траектории на один запрос: оригинальную (failed) и исправленную (good).
2. Обучаем LLM (или политику выбора инструментов) повышать вероятность good траектории и понижать — failed.
3. Необязательно обновлять всю модель: можно дообучать только политику выбора действия (action head) или использовать QLoRA для небольших изменений.

Результат агент реже повторяет ту же ошибку.

6. Retry policy: автоматический перезапуск failed запросов

После fine-tuning модели или обновления правил (manual annotations) запускается retry policy:

1. Берём все failed запросы из базы.
2. Подаём их на новую версию агента (с той же начальной конфигурацией).
3. Мониторим результат: если задача выполнена успешно — запрос «закрыт». Если снова fail — возвращается в очередь на ручной анализ (цикл replay).

Retry policy может быть:

• batch-based (раз в день недели перезапускать все fail);
• continuous (каждое улучшение сразу ретестится).

Важно: не перегружать production — ретест выполняется на shadow-трафике (теневом) или в отдельной среде.

7. Инструменты для agent replay

Рекомендация: начать с LangSmith — там есть готовый пайплайн «trace → annotate → create dataset → fine-tune».

8. Практические нюансы

• Стоимость ручной разметки – самая узкая часть. Чтобы её снизить, применяют активное обучение: размечают только те failed траектории, в которых модель наименее уверена.
• Масштабирование – количество failed сессий может быть огромно. Нужна фильтрация (например, сэмплировать по типу ошибки).
• Человеческий фактор – разные эксперты могут давать разные «правильные» траектории. Важно разработать стандарт качества (guideline).
• Retry cost – перезапуск тысяч failed запросов может нагрузить API. Используйте rate limit и кэширование идентичных запросов.

9. Метрики оценки улучшения после replay

Сравниваем метрики до и после fine-tuning на отложенной выборке failed запросов.

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

Задача Разработать простой эмулятор агента (калькулятор + поиск погоды) и реализовать полный цикл agent replay.

Инструменты Python, LangChain (или чистый OpenAI API), SQLite для хранения траекторий, DPO через библиотеку trl (Transformers Reinforcement Learning).

Шаги:

1. Создать агента, который может вызывать add(a,b), multiply(a,b), get_weather(city). Изначально он ошибается (например, путает сложение и умножение).
2. Написать эмулятор пользователя, который отправляет 100 запросов и ставит лайк/дизлайк.
3. Собрать все дизлайки в БД.
4. Написать скрипт replay: для каждого дизлайка заново прогнать запрос и найти шаг, где агент вызвал неверный tool.
5. Вручную подкорректировать 10 траекторий (заменить вызов multiply на add и достроить).
6. Обучить модель DPO на парах (failed_trace, good_trace), используя trl.DPOTrainer.
7. Запустить retry на оставшихся 90 запросах.
8. Посчитать success rate до и после — ожидаемый рост с 60% до 85%.

Ожидаемый результат Полный скрипт replay-пайплайна с визуализацией шагов и метрик.

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

Навигация

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