Как вы A/B тестируете агентов в production?

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

A/B тестирование AI-агентов в production — это процесс сравнения двух версий агента (контрольной и экспериментальной) на реальных пользователях с минимальным риском. Основной подход — shadow mode (теневой режим), когда новый агент работает параллельно, не влияя на пользовательский опыт. Сравнение ведётся по метрикам latency (задержка), cost (стоимость), faithfulness (фактологическая точность) и user feedback (обратная связь). Для принятия решения о rollout или rollback используются tests|статистические тесты (t-test или bootstrap) на основе user_id-based split, а автоматический откат срабатывает при превышении порога деградации.

1. Термин: A/B тестирование агентов

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

Для AI-агентов A/B тестирование сложнее, чем для обычных веб-страниц, потому что:

• Агент — это мультишаговая система (цепочка вызовов LLM, инструментов, памяти), а не один ответ.
• Метрики качества (faithfulness, безопасность) требуют автоматической или ручной оценки.
• Риск: плохой агент может дать вредный ответ или совершить опасное действие (например, удалить данные).

Поэтому в production применяют shadow mode как первый этап, а затем постепенный rollout с мониторингом.

2. Shadow mode (теневой режим)

Shadow mode — техника, при которой новый агент (версия B) запускается параллельно с текущим (версия A), но его ответы не показываются пользователю. Вместо этого:

• Оба агента получают один и тот же запрос.
• Ответ версии A идёт пользователю.
• Ответ версии B логируется и оценивается (автоматически или вручную).
• Метрики собираются, но пользовательский опыт не меняется.

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

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

Недостатки

• Удвоение затрат на инфраструктуру (два агента работают одновременно).
• Не измеряет user feedback напрямую, так как пользователь не видит ответ B.
• Требует автоматической оценки faithfulness, так как ручная валидация на большом объёме дорога.

Пример архитектуры shadow mode

Пользовательский запрос
       |
       v
   Load Balancer (user_id-based split)
       |
       +---> Агент A (production) ---> ответ пользователю
       |
       +---> Агент B (shadow) ---> лог + eval pipeline

3. Метрики для сравнения

Сравнение агентов ведётся по нескольким группам метрик. Ниже таблица с примерами:

Важно Для shadow mode метрики user feedback и conversion rate недоступны, так как пользователь не видит ответ B. Их можно измерять только на этапе canary release (постепенного rollout).

4. Статистическая значимость

Чтобы решить, что версия B лучше (или не хуже) версии A, нужно провести статистический тест.

4.1 Разделение пользователей (user_id-based split)

Пользователи случайным образом распределяются в группы A и B на основе user_id (или session_id). Это гарантирует, что один пользователь всегда видит одну версию, что важно для последовательности опыта.

Пример кода на Python для сплита:

import hashlib

def assign_variant(user_id: str, split_ratio: float = 0.5) -> str:
    hash_val = int(hashlib.md5(user_id.encode()).hexdigest(), 16)
    return 'A' if hash_val % 100 < split_ratio * 100 else 'B'

4.2 Выбор теста

• t-test (Стьюдента) — подходит для метрик, распределённых нормально (latency, cost). Сравнивает средние значения.
• Bootstrap — непараметрический метод, не требует нормальности. Подходит для бинарных метрик (faithfulness, success rate). Генерирует множество псевдовыборок и оценивает разницу средних.

Пример bootstrap для бинарной метрики

import numpy as np

def bootstrap_ci(metric_a, metric_b, n_bootstrap=10000, alpha=0.05):
    diffs = []
    for _ in range(n_bootstrap):
        sample_a = np.random.choice(metric_a, size=len(metric_a), replace=True)
        sample_b = np.random.choice(metric_b, size=len(metric_b), replace=True)
        diffs.append(np.mean(sample_b) - np.mean(sample_a))
    lower = np.percentile(diffs, 100 * alpha / 2)
    upper = np.percentile(diffs, 100 * (1 - alpha / 2))
    return lower, upper

Интерпретация Если доверительный интервал разницы не включает 0, то разница статистически значима.

4.3 Множественное тестирование

Если вы сравниваете много метрик одновременно, нужно применять поправку (например, Bonferroni correction), чтобы избежать ложных срабатываний.

5. Автоматический rollback при degradation

Degradation threshold (порог деградации) — заранее заданное значение ухудшения метрики, при котором эксперимент автоматически останавливается и возвращается версия A.

Как настроить

• Выбрать guardrail метрику (например, faithfulness < 0.9 или latency p99 > 5 сек).
• Установить порог: если метрика B хуже A на X% (например, faithfulness упала на 5%).
• Запустить мониторинг в реальном времени (каждые N запросов или каждые M минут).
• При превышении порога — автоматический откат на версию A и оповещение команды.

Пример логики rollback

def check_rollback(metrics_a, metrics_b, threshold=0.05):
    faithfulness_a = np.mean(metrics_a['faithfulness'])
    faithfulness_b = np.mean(metrics_b['faithfulness'])
    if faithfulness_a - faithfulness_b > threshold:
        return True  # нужно откатить
    return False

Важно Автоматический rollback должен быть реализован на уровне инфраструктуры (например, через feature flag или переключение DNS), чтобы сработать за секунды.

6. Инфраструктура и мониторинг

Для A/B тестирования агентов нужна следующая инфраструктура:

• Feature flag system (например, LaunchDarkly, Unleash) — для динамического переключения между версиями.
• Логирование — каждый шаг агента (входные/выходные данные, вызовы инструментов, latency) должен логироваться с тегом версии.
• Eval pipeline — автоматическая оценка faithfulness, safety и других метрик на основе логов.
• Dashboard (Grafana, Datadog) — визуализация метрик в реальном времени с разделением по версиям.
• Alerting — оповещения при превышении порогов.

Пример архитектуры

Запрос -> Feature Flag -> Агент A или B
   |
   v
Логи (Kafka) -> Eval pipeline -> Метрики (Prometheus) -> Dashboard + Alerting

7. Пример кода: A/B тестирование с shadow mode

Ниже упрощённый пример на Python с использованием asyncio для параллельного запуска двух агентов.

import asyncio
import random

class Agent:
    async def run(self, query: str) -> str:
        # симуляция работы агента
        await asyncio.sleep(random.uniform(0.1, 0.5))
        return f"Ответ от {self.__class__.__name__}: {query}"

class AgentA(Agent):
    pass

class AgentB(Agent):
    pass

async def shadow_mode(query: str, agent_a: AgentA, agent_b: AgentB):
    # запускаем оба агента параллельно
    result_a, result_b = await asyncio.gather(
        agent_a.run(query),
        agent_b.run(query)
    )
    # пользователю идёт ответ A
    user_response = result_a
    # ответ B логируется и оценивается
    log_shadow_result(query, result_b)
    return user_response

def log_shadow_result(query, response):
    # здесь можно вызвать eval pipeline
    print(f"Shadow log: query={query}, response={response}")

# Пример использования
async def main():
    agent_a = AgentA()
    agent_b = AgentB()
    queries = ["Как забронировать отель?", "Какая погода?"]
    for q in queries:
        resp = await shadow_mode(q, agent_a, agent_b)
        print(f"User gets: {resp}")

asyncio.run(main())

8. Проблемы и подводные камни

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

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

Инструменты

• Python, FastAPI (для API агента)
• LangChain или собственный фреймворк
• Redis (для хранения логов)
• Prometheus + Grafana (мониторинг)
• Feature flag (можно самодельный на основе конфига)

Шаги:

1. Создайте двух агентов: AgentA (базовый RAG) и AgentB (с улучшенным retrieval, например, с переранжированием).
2. Реализуйте shadow mode: оба агента запускаются параллельно, ответ A идёт пользователю, ответ B логируется.
3. Соберите метрики: latency, cost (количество токенов), faithfulness (через LLM-as-judge).
4. Настройте user_id-based split для постепенного rollout (сначала 1% трафика на B, затем 10%, 50%).
5. Реализуйте автоматический rollback: если faithfulness B падает ниже 0.8, откатить до A.
6. Визуализируйте метрики в Grafana.

Ожидаемый результат Работающий сервис, который позволяет безопасно тестировать новые версии агента на реальных пользователях с автоматическим откатом при ухудшении качества.

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

11. Навигация

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

Навигация

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