40% запросов уходили не туда: почему мультиагентные системы ломают классический QA — 1 июня 2026 г. в 08:01:25.477
40% запросов уходили не туда: почему мультиагентные системы ломают классический QA Строить мультиагентные системы индустрия уже научилась. Доказывать, что они работают — пока нет. Между впечатляющей демонстрацией и production-grade системой лежит область, для которой у большинства команд нет ни инструментов, ни методологии. Эта область — систематическая оценка агентов. И она постепенно оформляется в отдельную инженерную дисциплину. Проблема: классический QA не работает с агентами Проблема не в халатности, а в том, что привычные подходы к тестированию здесь не применимы. Классический QA — это: ▪️ Детерминизм: на вход X → ожидается выход Y ▪️Одна точка отказа ▪️ Assertion-based подход работает Агентная система: 🔹 На один запрос → два разных, но корректных ответа 🔹 Ломается на первом же тесте 🔹 Маршрутизатор + несколько специализированных агентов + доступ к БЗ Точек отказа становится кратно больше, и локализовать сбой без специализированной методики оценки практически невозможно. Трехуровневая модель офлайн-оценки Один из подходов, который формируется в практике, — трехуровневая модель офлайн-оценки. Все три уровня работают до развертывания, на курированном датасете с известными ожидаемыми результатами. Это quality gate, а не мониторинг. Уровень 1: оценка маршрутизации Задача кажется тривиальной: правильно ли маршрутизатор выбрал агента. На практике ошибки маршрутизации имеют каскадный эффект. ➡️ Under-routing — сложный запрос попадает к простому агенту, пользователь получает поверхностный ответ. ➡️ Over-routing — простой запрос уходит к тяжелому агенту, система тратит кратно больше ресурсов без прироста качества. Реальный кейс из финансового сектора: около 40% простых запросов направлялись к сложному агенту. Пользователи не жаловались — ответы были корректными. Но стоимость обработки была в пять раз выше необходимой. Исправление логики маршрутизации существенно сократило расходы без деградации качества. Уровень 2: LLM-as-judge Поскольку выходы агентов недетерминированы, сравнение с эталоном невозможно. Вместо этого для оценки используется отдельная языковая модель, которая проверяет ответ по нескольким измерениям: 🔹Фактическая точность — верны ли цифры и утверждения. 🔹Качество рассуждений — следует ли вывод из посылок. 🔹Полнота — покрыты ли ключевые аспекты (для аналитических отчетов). Каждое измерение применяется не ко всем запросам, а в зависимости от их сложности. ▪ Простой запрос на цену акции → не требует проверки качества рассуждений. ▪ Аналитический отчет → требует. Уровень 3: оценка RAG-пайплайна Агент может сгенерировать убедительный ответ, который не опирается на извлеченные документы. Метрика faithfulness — доля утверждений в ответе, подтвержденных контекстом из базы знаний — напрямую связана с риском галлюцинаций. Практика показывает: метрика может значительно различаться в зависимости от типа запроса: 🔼 для фактических запросов — 90% и выше 🔽 для аналитических — может падать до 60%, поскольку модель начинает «достраивать» рассуждения за пределами извлечённого контекста. Почему? Модель начинает «достраивать» рассуждения за пределами извлеченного контекста. Интеграция в CI/CD Интеграция в CI/CD с определенными порогами превращает оценку из разовой процедуры в воспроизводимую практику. Пороги калибруются под контекст: ✔️ Финансовые приложения — допустимая точность от 90%. ✔️ Внутренние инструменты — может быть ниже. Ключевой вывод По сути, формируется новая область инженерной практики. Не тестирование в привычном понимании, а проектирование системы контроля качества, где метрики так же требуют архитектурных решений, как и сама агентная система. #tech_inside