Работающий AI-агент — это ещё не хороший AI-агент: доступность сервиса и отсутствие ошибок в логах ничего не говорят о качестве ответов. Для оценки AI-агентов нужны как минимум два контура данных — реальные продакшен-трейсы и набор примеров, которые команда уже проверила вручную. Для российских команд, внедряющих LLM в поддержку, разработку и внутренние процессы, это означает простую вещь: запуск в прод не завершает проект, а открывает самый важный этап.
Об этом пишет The New Stack в материале о том, как превратить обратную связь из эксплуатации в улучшение агентов. Главная проблема сформулирована без лишней магии: агент может быть технически здоров — отвечать быстро, вызывать инструменты и не падать, — но при этом регулярно выбирать не те источники, неверно интерпретировать запрос или слишком уверенно выдавать сомнительный результат. Обычный мониторинг покажет задержку и процент ошибок, но не отличит полезный ответ от правдоподобной ерунды.
Под продакшен-трейсом здесь понимается не только финальный текст, который увидел пользователь. Важен весь маршрут выполнения: исходный запрос, выбранные агентом шаги, обращения к моделям и внешним инструментам, найденный контекст, промежуточные решения, длительность и результат. Такой след позволяет разбирать конкретный сбой не на уровне «модель стала хуже», а на уровне проверяемой гипотезы: агент не получил нужный документ, вызвал инструмент с неверными параметрами, потерял ограничение из системной инструкции или сделал лишний шаг.
Следующий слой — курированные данные. В отличие от потока реальных диалогов, это набор задач с понятным ожидаемым поведением: правильным ответом, обязательным действием, запрещённым действием или набором критериев для проверки. Он нужен, чтобы изменения можно было сравнивать воспроизводимо. Если команда поменяла промпт, модель, поиск по базе знаний или логику маршрутизации, нельзя ограничиваться несколькими удачными ручными тестами. Новую версию стоит прогнать по набору сценариев, собранных из реальных проблем, и проверить, не исправила ли она один кейс ценой нескольких новых регрессий.
Именно здесь оценка AI-агентов перестаёт быть разовой демонстрацией перед релизом. Негативные сигналы из продакшена — повторные уточнения пользователя, отменённые действия, ручные исправления оператором, жалобы, подозрительно длинные цепочки вызовов — становятся кандидатами для разбора. После проверки человеком часть таких эпизодов пополняет контрольный набор. Получается замкнутый цикл: эксплуатация выявляет слабое место, команда описывает ожидаемый результат, изменение проходит повторную проверку, а затем снова наблюдается в реальной среде.
У такого подхода есть важное ограничение: реальные данные нельзя бездумно превращать в датасет. В трейсы нередко попадают персональные данные, коммерческая информация, фрагменты исходного кода и внутренние документы. Значит, до хранения и передачи данных в систему наблюдаемости нужны правила минимизации, маскирования и разграничения доступа. Не менее опасна и автоматическая вера в пользовательскую реакцию: короткий диалог не всегда означает успех, а длинный — не обязательно провал. Сигналы из продакшена полезны как очередь для расследования, а не как готовая разметка истины.
Для разработчиков практический вывод довольно приземлённый. В архитектуру агента стоит сразу заложить идентификаторы запросов, запись ключевых шагов и возможность сопоставить итог с версией промпта, модели и инструментов. Иначе после обновления команда увидит лишь расплывчатое «качество снизилось» и начнёт охоту на причину с фонариком. Для продакт-менеджеров это способ связать технические метрики с продуктовым эффектом: не только считать стоимость и задержку, но и отслеживать, завершил ли пользователь задачу без эскалации к человеку.
Бизнесу такой цикл помогает трезво выбирать место для автономии. Если агент умеет искать информацию, но нестабилен при выполнении действий, можно оставить ему подготовку ответа и передать подтверждение человеку. Если контрольные сценарии показывают устойчивое качество в узком процессе, уровень автоматизации можно повышать постепенно. Это гораздо полезнее, чем спорить об «интеллекте» модели по отдельным эффектным примерам из демо.
Рынок AI-агентов постепенно смещается от вопроса «можем ли мы подключить модель к инструментам?» к вопросу «как доказать, что после следующего изменения агент не стал хуже?». Победят не обязательно команды с самой громкой моделью, а те, у кого оценка AI-агентов встроена в разработку так же естественно, как тесты, логи и разбор инцидентов. Агенту недостаточно быть живым в продакшене — он должен оставлять достаточно следов, чтобы команда могла сделать его полезнее на следующем релизе.