Как вы делаете A/B тест между двумя агентами с разными архитектурами (ReAct vs Plan-and-Execute)?

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

A/B тест между агентами с разными архитектурами (например, ReAct и Plan-and-Execute) проводится в shadow mode: оба агента получают один и тот же запрос, но пользователю отвечает только контрольная версия (control). Собираются метрики: cost, latency, user satisfaction (через implicit/explicit feedback). Статистическая значимость различий оценивается с помощью bootstrap-метода. Такой подход минимизирует риски для пользователей и позволяет объективно сравнить архитектуры до принятия решения о rollout.

1. Термины и контекст

ReAct (Reasoning + Acting]]) — архитектура, в которой агент чередует рассуждение (chain-of-thought) и выполнение действий (вызов инструментов, API) в одном цикле, пока не достигнет цели. Каждый шаг включает «Thought → Action → Observation».

Plan-and-Execute — архитектура, в которой агент сначала строит план (последовательность шагов), а затем выполняет его, возможно, с адаптацией по ходу. План может быть статическим или динамическим.

A/B тест — эксперимент, в котором две версии системы (control и treatment) сравниваются на реальных пользователях или в симулированной среде.

Shadow mode — режим, при котором treatment-версия работает «в тени»: получает те же входные данные, что и control, но её ответы не показываются пользователю. Это безопасный способ сбора данных без влияния на пользовательский опыт.

Bootstrap — метод передискретизации (resampling) для оценки распределения статистики (например, разницы средних) без параметрических предположений. Позволяет вычислить p-value и доверительные интервалы.

2. Зачем A/B тестировать агентов?

Сравнение архитектур агентов (ReAct vs Plan-and-Execute) необходимо, чтобы:

• Объективно измерить, какая архитектура даёт лучшие результаты по ключевым метрикам (качество ответа, стоимость, скорость).
• Минимизировать риск внедрения неоптимальной архитектуры, которая может ухудшить пользовательский опыт или увеличить затраты.
• Принять data-driven решение о rollout, а не полагаться на интуицию.

Без A/B теста легко ошибиться: Plan-and-Execute может казаться более структурированным, но на практике ReAct может быть гибче в нестандартных запросах.

3. Подготовка к эксперименту

3.1 Выбор метрик

Метрики делятся на три группы:

Для A/B теста выбирают primary metric (главную, например, task success rate) и несколько secondary.

3.2 Определение контрольной и экспериментальной групп

• Control — текущая архитектура (например, ReAct).
• Treatment — новая архитектура (Plan-and-Execute).

Важно: обе версии должны использовать одинаковые инструменты, промпты (кроме самой архитектуры) и LLM, чтобы разница была обусловлена только архитектурой.

3.3 Размер выборки

Минимальный размер выборки рассчитывается через power analysis. Для bootstrap это менее критично, но всё равно нужно собрать не менее нескольких сотен запросов на каждую версию для стабильных оценок.

4. Shadow mode: архитектура сбора данных

Shadow mode — ключевой элемент безопасного A/B теста агентов.

Как это работает

1. Каждый входящий запрос пользователя направляется одновременно на control и treatment.
2. Control обрабатывает запрос и возвращает ответ пользователю (как обычно).
3. Treatment обрабатывает запрос в фоне, но его ответ не показывается пользователю.
4. Логи обеих версий (вход, цепочка мыслей, действия, выход, метрики) сохраняются в едином хранилище.

Преимущества shadow mode

• Нулевой риск для пользователя (он видит только control).
• Можно собирать данные параллельно с production-трафиком без изменения пользовательского опыта.
• Позволяет накопить достаточно наблюдений для статистического анализа.

Недостатки

• Удвоение нагрузки на инфраструктуру (cost, compute).
• Невозможно измерить метрики, зависящие от реального поведения пользователя (например, повторные визиты), так как treatment не влияет на пользователя.

5. Сбор и хранение логов

Каждый запрос должен логироваться с уникальным ID, меткой времени, версией агента, полным трейсом (chain-of-thought, вызовы инструментов, ответ) и метриками.

Пример структуры лога (JSON):

{
  "request_id": "abc123",
  "timestamp": "2025-03-15T10:30:00Z",
  "agent_version": "react_v2",
  "user_query": "Какой прогноз погоды в Москве на завтра?",
  "trace": [
    {"step": 1, "type": "thought", "content": "Нужно найти погоду..."},
    {"step": 2, "type": "action", "tool": "weather_api", "input": "Moscow", "output": "..."},
    {"step": 3, "type": "observation", "content": "..."},
    {"step": 4, "type": "final_answer", "content": "Завтра в Москве +5°C..."}
  ],
  "latency_ms": 2340,
  "total_tokens": 450,
  "cost_usd": 0.0032,
  "user_feedback": null
}

Для treatment-версии поле user_feedback всегда null, так как ответ не показывается.

6. Анализ результатов: bootstrap для статистической значимости

После сбора данных (например, 1000 запросов на каждую версию) нужно проверить, значимо ли различаются метрики.

Bootstrap — непараметрический метод, который не требует предположений о распределении.

Алгоритм

1. Вычисляем наблюдаемую разницу средних (или медиан) между treatment и control: delta_obs = mean(treatment) - mean(control).
2. Многократно (например, 10 000 раз) генерируем псевдовыборки:
   • Объединяем все наблюдения в один пул.
   • Случайным образом с возвращением делим пул на две группы того же размера, что и исходные.
   • Вычисляем разницу средних для каждой псевдовыборки: delta_boot.
3. Получаем распределение delta_boot при нулевой гипотезе (разницы нет).
4. p-value = доля псевдовыборок, где |delta_boot| >= |delta_obs| (двусторонний тест).
5. Если p-value < 0.05 (или другого порога), разница статистически значима.

Пример кода на Python

import numpy as np

def bootstrap_test(control, treatment, n_iterations=10000):
    combined = np.concatenate([control, treatment])
    n_c = len(control)
    n_t = len(treatment)
    delta_obs = np.mean(treatment) - np.mean(control)
    deltas = []
    for _ in range(n_iterations):
        sample = np.random.choice(combined, size=n_c+n_t, replace=True)
        c_boot = sample[:n_c]
        t_boot = sample[n_c:]
        deltas.append(np.mean(t_boot) - np.mean(c_boot))
    deltas = np.array(deltas)
    p_value = np.mean(np.abs(deltas) >= np.abs(delta_obs))
    return delta_obs, p_value, np.percentile(deltas, [2.5, 97.5])  # 95% CI

# Пример: task success rate (0/1)
control_success = [1, 0, 1, 1, 0, ...]  # 1000 значений
treatment_success = [1, 1, 0, 1, 1, ...]  # 1000 значений
delta, p, ci = bootstrap_test(control_success, treatment_success)
print(f"Delta: {delta:.3f}, p-value: {p:.4f}, 95% CI: {ci}")

Интерпретация если p < 0.05, то с вероятностью 95% разница не случайна. Доверительный интервал показывает диапазон возможной разницы.

7. Дополнительные метрики и анализ

7.1 User satisfaction (только для control)

Поскольку treatment не показывается пользователю, его satisfaction измерить напрямую нельзя. Можно:

• Использовать LLM-as-a-judge для оценки качества ответов treatment (например, по шкале 1-5).
• Провести offline-оценку на краудсорсинговой платформе, где люди сравнивают ответы control и treatment на одних и тех же запросах (без знания, какая версия какая).

7.2 Анализ по сегментам

Разбить запросы на категории (простые vs сложные, короткие vs длинные) и провести bootstrap для каждой подгруппы. Это поможет понять, в каких сценариях одна архитектура выигрывает.

7.3 Cost vs Quality trade-off

Построить scatter plot: по оси X — cost per query, по оси Y — quality metric. Если treatment даёт значимо лучшее качество при небольшом увеличении cost, это может быть приемлемо.

8. Ограничения и риски shadow mode

9. Альтернативы shadow mode

• Online A/B test — разделение трафика: 50% пользователей видят control, 50% — treatment. Позволяет измерить реальное поведение, но рискованно, если treatment хуже.
• Interleaving — пользователю показываются ответы обеих версий в случайном порядке (для задач, где ответы можно перемешать, например, поиск). Требует специальной UI-логики.
• Offline evaluation — прогон на исторических запросах с размеченными ответами. Дешево, но не отражает динамику реального использования.

Для агентов с разными архитектурами shadow mode — самый безопасный первый шаг.

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

Задача Реализовать A/B тест между ReAct и Plan-and-Execute агентом для простого RAG-сценария (ответы на вопросы по документации).

Инструменты

• Python, LangChain или собственный фреймворк для агентов.
• LLM API (OpenAI, Anthropic).
• Хранилище логов: SQLite или CSV.
• Библиотека для bootstrap: scipy или самописная.

Шаги:

1. Создать два агента: ReAct (с циклом Thought-Action-Observation) и Plan-and-Execute (сначала строит план, потом выполняет).
2. Подготовить тестовый набор из 200 запросов (можно взять из FAQ).
3. Запустить shadow mode: для каждого запроса вызвать обоих агентов, сохранить логи и метрики (latency, cost, success rate по LLM-judge).
4. Провести bootstrap-тест для метрики success rate.
5. Визуализировать распределение разницы и сделать вывод.

Ожидаемый результат Вы получите p-value и доверительный интервал, на основе которых сможете сказать, какая архитектура значимо лучше (или нет).

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

12. Навигация

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

Навигация

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