Теневой трафик для LLM-агента: как тестировать новую версию без риска для продакшена

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

Тестовый стенд редко повторяет реальное распределение запросов, длину контекста и редкие ветки workflow. В продакшене агент может встретить комбинацию, которой не было в тестовых данных: неполный профиль клиента, повторный webhook или ответ внешнего API после тайм-аута.

Поэтому полезно разделять две задачи: проверить транспорт и инструменты на sandbox-данных, а качество маршрутизации и ответа сравнить на копии реального потока.

Текущая версия агента обслуживает пользователя как обычно. Параллельно тот же вход отправляется в новую версию, но её tool calls перехватываются и заменяются безопасными заглушками. Запросы к CRM, почте и платежам получают read-only или синтетический ответ. Пользователь видит только результат основной версии, а новая версия пишет свою трассу в отдельное хранилище.

Минимальная запись события:

- request_id и cohort_id; - версия модели, промпта и набора инструментов; - хеш входного контекста; - последовательность tool calls; - latency, токены и стоимость; - финальный ответ и причина завершения.

Сами персональные данные лучше заменять стабильными псевдонимами и масками. Иначе тестовый контур быстро превращается в ещё одну копию продакшена.

Сравнивать только текст ответа опасно. Для каждой пары запусков нужны как минимум четыре группы метрик:

1. Корректность: прошла ли схема, бизнес-правила и проверки домена. 2. Поведение: те ли инструменты вызваны, в том ли порядке и с теми ли аргументами. 3. Надёжность: таймауты, повторы, неизвестный результат и незавершённые workflow. 4. Экономика: токены, число вызовов, время воркера и стоимость ручной проверки.

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

Когда shadow-трафик обнаружил расхождение, сохраните вход и снимок ответов инструментов. Replay должен запускать обе версии на одинаковом наборе внешних ответов. Это убирает шум сети и позволяет понять, что изменилось: модель, промпт, роутинг или код адаптера.

Для повторяемости фиксируйте temperature, seed если провайдер его поддерживает, версию схемы и время запуска. Для недетерминированных ответов задайте не точное равенство текста, а набор проверяемых инвариантов.

Перед переключением новой версии я бы требовал:

- ноль критических регрессий на replay-наборе; - отдельный лимит на рост стоимости и p95; - отсутствие новых повторных side effects; - понятный rollback на предыдущую конфигурацию; - canary на небольшой когорте после shadow-проверки.

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

Shadow traffic и replay превращают проверку LLM-агента из демонстрации на удачных примерах в инженерное сравнение двух версий на одинаковой нагрузке. Для продакшена важен не самый красивый ответ, а предсказуемое поведение, контролируемая стоимость и отсутствие повторных действий.

Как вы проверяете новые версии агентов: через ручные сценарии, replay реальных трасс или сразу через canary?