Motorway и AWS построили пайплайн оценки AI-агентов, который сократил долю неверных результатов с 1 из 8 запросов до 1 из 50. Время обнаружения проблем уменьшилось с нескольких часов до минут. Этот результат достигнут за счёт двухфазной стратегии оценки, трёхуровневой структуры проверки и пятиэтапного развёртывания с quality gates.
Пайплайн решает главную проблему production-среды: недетерминированность LLM. Один и тот же запрос может дать разные ответы, поэтому стандартные unit-тесты не работают. Motorway внедрила метрику passk, тестирование многопоточных диалогов и замкнутый цикл обратной связи, в котором production-инциденты автоматически превращаются в новые тестовые кейсы.
Разберём архитектуру этого пайплайна и способы адаптации под собственные задачи.
Проблема: почему 1 из 8 ответов AI-агента был неверным
Motorway использует AI-агентов для обработки клиентских запросов в автомобильной платформе. Агенты выполняют многошаговые задачи: поиск автомобиля по параметрам, проверка истории, оценка стоимости, формирование предложения. Каждый шаг требует вызова внешних API и логических переходов между ними.
Исходная система оценки показала тревожную цифру: 12,5% ответов содержали ошибки. Ошибка могла быть любой: неверный вызов инструмента, пропущенный шаг в цепочке рассуждений, галлюцинация в финальном ответе. Для бизнеса это означало прямые потери: клиент получал некорректную цену или предложение с несуществующим автомобилем.
Хуже того, обнаружение проблемы занимало часы. Команда узнавала об инциденте только после жалобы пользователя или внутреннего аудита. Реакция запаздывала, а масштаб проблемы нарастал. Нужен был системный подход к оценке качества, встроенный в процесс развёртывания и мониторинга.
Подобные проблемы характерны для многих команд, внедряющих AI-агентов. Скорость генерации кода и ответов часто маскирует фундаментальные дефекты, которые проявляются только в production. Motorway пошла по пути создания многослойного пайплайна оценки.
Двухфазная стратегия: оценка на этапе сборки и в production
Разделение на pre-production и production-оценку закрывает разные классы рисков. Тесты на этапе сборки отсекают очевидные ошибки до того, как код попадёт к пользователям. Production-мониторинг ловит проблемы, которые невозможно воспроизвести в тестовой среде: неожиданные комбинации запросов, пиковые нагрузки, взаимодействие с реальными API.
Фаза 1: Оценка на этапе сборки - быстрые проверки перед деплоем
Pre-production фаза встроена в CI/CD-пайплайн Motorway. При каждом коммите запускается набор автоматических проверок:
- Юнит-тесты инструментов: валидация схем вызовов API, проверка корректности параметров, обработка граничных случаев.
- Проверка форматов ответов: соответствие JSON-схеме, наличие обязательных полей, корректность типов данных.
- Базовые сценарии: 20-30 эталонных диалогов, покрывающих типовые пользовательские запросы. Агент должен пройти их с определённым порогом качества.
Все проверки выполняются за 5-7 минут. Этого достаточно, чтобы отсечь регрессии и очевидные ошибки, но недостаточно для оценки реального поведения агента. Поэтому вторая фаза работает непрерывно в production.
Фаза 2: Production-оценка - мониторинг реальных взаимодействий
В production Motorway собирает метрики по каждому взаимодействию агента с пользователем. Система алертинга настроена на аномалии: резкое падение доли успешных вызовов инструментов, рост времени ответа, увеличение числа эскалаций на оператора.
Выборочный аудит ответов проводит LLM-as-a-judge: 5% диалогов автоматически проверяются на соответствие критериям качества. При обнаружении проблемы инцидент не просто фиксируется - он немедленно превращается в тестовый кейс. Этот механизм обратной связи - один из ключевых факторов, позволивших сократить время обнаружения проблем с часов до минут.
Механизм работает так: production-ошибка попадает в очередь, автоматически обогащается контекстом (трейс вызовов, цепочка рассуждений, финальный ответ), и на её основе генерируется новый тестовый сценарий. Этот сценарий добавляется в набор pre-production проверок, предотвращая повторение ошибки в будущем.
Трёхуровневая структура проверки: инструменты, логика, качество
Motorway проверяет работу агента на трёх уровнях. Каждый уровень - это слой защиты, который ловит ошибки определённого класса. Пропуск любого уровня создаёт слепую зону.
Уровень 1: Корректность использования инструментов
Первый уровень проверяет, правильно ли агент вызывает внешние функции и API. Типичные ошибки этого уровня: неверные параметры вызова, пропущенные обязательные шаги, нарушение последовательности операций, вызов несуществующих эндпоинтов.
Методы проверки включают валидацию схем: каждый вызов инструмента сравнивается с эталонной сигнатурой. Параметры проверяются на соответствие ожидаемым типам и диапазонам. Трейс вызовов сравнивается с эталонным трейсом для сценария - это позволяет обнаружить пропущенные или лишние шаги.
Доля успешных вызовов инструментов стала одним из ключевых quality gates в пайплайне развёртывания Motorway. Порог установлен на уровне 95%: если агент ошибается в вызовах чаще, сборка не проходит дальше.
Уровень 2: Логика рассуждений
Второй уровень оценивает цепочку мыслей агента. Финальный ответ может быть верным, но полученным через некорректные рассуждения - и это бомба замедленного действия. При изменении входных данных такая логика неизбежно приведёт к ошибке.
Motorway анализирует промежуточные шаги на наличие галлюцинаций и логических противоречий. LLM-as-a-judge проверяет связность рассуждений: следует ли каждый следующий шаг из предыдущего, нет ли пропусков в логической цепочке, не противоречит ли агент сам себе.
Этот уровень критически важен для агентов, работающих в regulated-индустриях, где важна объяснимость решений. Опыт внедрения агентов в таких средах показывает, что некорректная логика рассуждений часто страшнее неверного финального ответа: она подрывает доверие к системе.
Уровень 3: Качество финального ответа
Третий уровень оценивает результат с точки зрения пользователя. Критерии: полнота (все ли аспекты запроса покрыты), точность (соответствие фактам), релевантность (ответ на заданный вопрос, а не на смежный), формат (соответствие ожидаемой структуре).
Для оценки Motorway использует сравнение с «золотым стандартом» - набором эталонных ответов, размеченных экспертами. Дополнительно проводится A/B-тестирование: часть пользователей получает ответы от новой версии агента, часть - от текущей, и метрики удовлетворённости сравниваются.
Пятиэтапный пайплайн развёртывания с quality gates
Motorway выстроила пятиэтапный процесс развёртывания новых версий агентов. Каждый этап имеет автоматические критерии для перехода дальше - quality gates. Сборка, не прошедшая gate, автоматически откатывается.
Этапы развёртывания:
- Локальное тестирование разработчика. Запуск юнит-тестов и 10 базовых сценариев. Gate: все тесты пройдены.
- CI-пайплайн. Полный набор pre-production тестов, включая 30 эталонных диалогов. Gate: доля успешных вызовов инструментов > 95%, оценка логики > 0.85.
- Staging-среда. Тестирование на синтетических данных, симулирующих production-нагрузку. Gate: passk > 0.9 на расширенном наборе из 100 сценариев.
- Canary-развёртывание. Новая версия получает 5% production-трафика. Gate: отсутствие алертов в течение 2 часов, пользовательская удовлетворённость не ниже baseline.
- Полное production-развёртывание. Постепенное увеличение трафика до 100% с непрерывным мониторингом.
Quality gates: автоматические критерии для перехода между этапами
Числовые пороги quality gates настраиваются под бизнес-критичность агента. Для агента, обрабатывающего платежи, пороги выше, чем для рекомендательной системы. Motorway определила три уровня критичности и соответствующие им пороги:
| Уровень критичности | passk | Успешность инструментов | Оценка логики |
|---|---|---|---|
| Высокий (платежи, цены) | > 0.95 | > 98% | > 0.90 |
| Средний (поиск, фильтрация) | > 0.90 | > 95% | > 0.85 |
| Низкий (рекомендации) | > 0.85 | > 90% | > 0.80 |
При падении метрик ниже порога срабатывает автоматический откат. Это предотвращает деградацию качества в production и даёт команде время на анализ причин.
Работа с недетерминированностью: метрика passk
LLM недетерминированы по своей природе. Один и тот же промпт может дать разные ответы при разных запусках. Однократный прогон теста не показывает реальную надёжность агента: успех может быть случайным, как и провал.
Метрика passk решает эту проблему. Агент запускается k раз на одном и том же сценарии, и замеряется доля успешных прохождений. Если агент проходит сценарий в 9 из 10 попыток, pass10 = 0.9. Это даёт статистически значимую оценку стабильности.
Выбор k зависит от требуемой уверенности. Motorway использует k=10 для большинства сценариев и k=20 для критических. Расчёт прост: для сценария с 5 шагами, где каждый шаг имеет вероятность успеха 0.95, вероятность успеха всего сценария - 0.955 ≈ 0.77. passk вскрывает эту накопительную нестабильность.
Метрика также используется для сравнения версий агента. Новая версия должна показать passk не ниже текущей на всём наборе сценариев. Это жёсткое требование предотвращает регрессии, которые могли бы пройти незамеченными при однократном тестировании.
Тестирование многопоточных диалогов
Параллельные взаимодействия создают специфические проблемы: состояние гонки, перепутывание контекстов между сессиями, блокировки при доступе к общим ресурсам. В production Motorway обслуживает тысячи одновременных диалогов, и ошибки этого класса проявляются только под нагрузкой.
Для тестирования многопоточности Motorway симулирует множественные одновременные сессии. Тестовый сценарий запускает 50-100 параллельных диалогов с разными контекстами и проверяет изоляцию: ответ в каждой сессии должен соответствовать именно её контексту, без примесей из других сессий.
Проверка изоляции контекста - ключевой аспект. Агент не должен «запоминать» информацию из параллельного диалога или использовать её в ответе. Симуляция также проверяет отсутствие деградации времени ответа при росте числа параллельных сессий.
Этот вид тестирования часто упускается при разработке AI-агентов, но именно он вскрывает проблемы, которые проявляются только на production-нагрузках. Инструменты вроде Pre2Prod частично решают эту задачу для кодовых агентов, но для диалоговых систем требуется собственная инфраструктура тестирования.
Результаты: от 1/8 до 1/50 ошибок и минуты вместо часов
Внедрение пайплайна принесло Motorway измеримые результаты по трём ключевым метрикам:
- Доля неверных ответов: с 12,5% (1 из 8) до 2% (1 из 50). Сокращение в 6,25 раза.
- Время обнаружения проблем: с нескольких часов до минут. Автоматический алертинг и цикл обратной связи позволяют зафиксировать аномалию в течение 2-3 минут после её появления.
- Время восстановления: автоматический откат проблемной версии сократил время восстановления с часов до 5-10 минут.
Бизнес-эффект выразился в снижении числа жалоб пользователей на 80% и уменьшении нагрузки на операторов, которые раньше разбирали последствия ошибок агента. Команда Motorway получила возможность выкатывать новые версии агентов еженедельно вместо ежемесячных релизов: quality gates дают уверенность, что регрессии будут отловлены автоматически.
Как адаптировать этот пайплайн под свои задачи
Опыт Motorway содержит несколько принципов, применимых к любому проекту с AI-агентами:
- Production-оценка обязательна. Pre-production тесты не покрывают реальное поведение. Минимум - выборочный аудит ответов и алертинг на аномалии.
- Многоуровневая проверка. Проверяйте инструменты, логику и финальный ответ. Каждый уровень ловит свой класс ошибок.
- Автоматические quality gates. Числовые пороги для перехода между этапами развёртывания. Без них пайплайн - просто набор тестов без механизма принятия решений.
- passk для недетерминированных систем. Однократный прогон недостаточен. Запускайте k попыток и считайте долю успешных.
- Замкнутый цикл обратной связи. Production-инциденты должны автоматически превращаться в тестовые кейсы. Это единственный способ предотвратить повторение ошибок.
Для старта достаточно минимального viable пайплайна: набор из 20-30 эталонных сценариев, pass5 в CI, выборочный аудит 5% production-ответов и один quality gate перед деплоем. Расширять набор сценариев и уровни проверки можно итеративно, по мере накопления данных о реальных ошибках.
Если вы только начинаете строить агентов, изучите архитектуру AI-агента с нуля - понимание внутреннего устройства поможет правильно спроектировать пайплайн оценки. Для команд, которые уже прошли этап прототипирования, полезен опыт Apollo по перестройке AI-ассистента с фокусом на production-качество.