Как оценить AI-агента до продакшена: практический B2B-фреймворк

AI-агент успешно завершает демонстрацию.

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

Команда утверждает пилот.

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

Агент не обязательно был оценён некорректно.

Возможно, он вообще не был оценён.

Успешная демонстрация доказывает, что один путь выполнения может работать.

Готовность к продакшену требует доказательств того, что система ведёт себя приемлемо в нормальных, неоднозначных, враждебных и частично отказавших условиях.

AI-агент должен быть оценён на пяти уровнях: Результат задачи - выполнил ли он бизнес-задачу корректно? Трейс выполнения - выбрал ли он правильные инструменты и действия? Безопасность и политика - остался ли он в рамках своих разрешений? Экономика - выполнил ли он задачу за приемлемую стоимость и с приемлемой скоростью? Операционная устойчивость - корректно ли он обработал отсутствующие данные, сбои, повторные попытки и эскалацию?

Единицей оценки должна быть завершённая бизнес-задача, not the quality of a single model response. Before evaluation begins, the company should confirm that the eight readiness conditions described in our guide to why AI agents are not automation are in place -process clarity, ownership, data access, permissions, decision boundaries, approval rules, logging, and rollback.

Почему стандартной оценки LLM недостаточно

Чатбот может оцениваться в основном по его итоговому ответу.

Агент может дать хороший итоговый ответ, но при этом вести себя некорректно в процессе выполнения.

Он может извлечь запрещённые данные; использовать неверный инструмент; отправить невалидные аргументы; обновить не тот аккаунт; повторить необратимое действие; скрыть неопределённость; превысить лимит стоимости; и достичь правильного результата через небезопасный путь.

Поэтому оценка агента должна проверять и результат, и трейс, который его создал.

Текущие официальные руководства по оценке всё чаще описывают процесс как комбинацию проектирования тест-кейсов, выполнения, генерации трейсов, оценки, моделирования и анализа сбоев. Документация Google по оценке агентов, например, включает многошаговые сценарии и симулированные сбои инструментов, такие как ошибки сервиса и пики задержки. (Google Cloud Documentation)

Начните с письменного контракта задачи

Прежде чем создавать набор тестов, точно определите задачу.

Полезный контракт задачи включает:

Без этого контракта команда может расходиться во мнениях, был ли один и тот же запуск агента успешным.

Один человек оценивает качество ответа.

Другой оценивает скорость.

Третий считает, что обновление CRM было разрешено.

Агента нельзя измерять по требованиям, которые никогда не были определены.

Сначала оцените бизнес-результат

Основная метрика - не "ответ звучал хорошо".

Это успех задачи.

Примеры: был ли определён правильный клиент? Был ли сопоставлен правильный счёт? Был ли тикет направлен в нужную очередь? Был ли запрошенный отчёт сгенерирован из утверждённого источника данных? Была ли запись обновлена точно? Была ли задача эскалирована при недостаточности доказательств?

Задача должна быть отмечена как успешная только тогда, когда все обязательные условия выполнены.

Для процессов с высоким влиянием частичный успех может по-прежнему быть неудачей.

Агент, который подготовил правильную сумму возврата, но применил её к неверному аккаунту, не достиг 90% успеха.

Он создал инцидент.

Метрики, показывающие, работает ли агент

Коэффициент успеха задач

Коэффициент успеха задач = Корректно выполненные задачи / Общее число оценённых задач

Критерии успеха должны быть детерминированными, где это возможно.

Например: правильная запись; правильное значение поля; правильный маршрут; правильное состояние согласования; отсутствие запрещённых действий; и прикреплённые необходимые доказательства.

Точность выбора инструмента

Выбрал ли агент подходящий инструмент?

Агент может иметь доступ к поиску в CRM; поиску по биллингу; извлечению из базы знаний; черновику письма; обновлению клиента; и запросу согласования.

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

Валидность аргументов инструмента

Правильный инструмент с некорректными параметрами - это всё ещё провальное действие.

Оценивайте обязательные аргументы; идентификаторы аккаунтов; даты; суммы; значения статусов; область действия; получателя; ключ идемпотентности; и токен согласования.

Структурированные выходные данные и валидация схемы снижают риск, но валидация должна также проверять бизнес-смысл.

Синтаксически валидная сумма в $100 000 всё ещё может нарушать лимит согласования агента.

Коэффициент соблюдения политик

Измерьте, выполнил ли агент следующее: оставался в разрешённых системах; избегал запрещённой информации; получал необходимое согласование; соблюдал ограничения действий; останавливался при недостаточности доказательств; избегал запрещённых действий; и обрабатывал внешние инструкции как недоверенный контент.

OWASP рекомендует минимальные привилегии, человеческий контроль для действий с высоким риском, ограничения рекурсии и повторных попыток, валидацию внешних входных данных и структурированное состязательное тестирование перед продакшеном. (OWASP Cheat Sheet Series)

Для запрещённого необратимого действия допустимое число несанкционированных выполнений в тестировании должно быть нулевым.

Коэффициент человеческих исправлений

Коэффициент исправлений = Задачи, требующие существенных человеческих изменений / Проверенные задачи

Не считайте предпочтения в форматировании существенными исправлениями.

Отслеживайте изменения, влияющие на: решение; получателя; сумму; классификацию; доказательства; системное действие; и обязательство перед клиентом.

Высокий коэффициент исправлений означает, что агент может перемещать работу, а не устранять её.

Качество эскалации

Агент не должен пытаться решить каждый случай.

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

Важны и недостаточная, и избыточная эскалация.

Недостаточная эскалация создаёт риск.

Избыточная эскалация устраняет экономическую ценность автоматизации.

Коэффициент дублирующего выполнения

Агенты должны быть протестированы на повторные сообщения, повторные попытки и задержанные ответы.

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

Идемпотентность - не только вопрос интеграции. Это часть корректности агента.

Задержка и длительность задачи

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

Задача может быть точной, но операционно непригодной, если занимает больше времени, чем ручной процесс.

Стоимость за завершённую задачу

Стоимость за успешную задачу = (Модель + Инструмент + Инфраструктура + Стоимость проверки) / Успешно выполненные задачи

Включите вызовы модели; извлечение данных; ранжирование; внешние API; наблюдаемость; человеческую проверку; неудачные попытки; повторные попытки; и инженерную поддержку.

Стоимость за запрос скрывает сбои.

Стоимость за завершённую задачу их обнажает.

Стройте набор тестов вокруг сбоев, а не только успеха

Репрезентативный набор оценки должен содержать несколько классов сценариев.

Нормальные случаи

Типовые задачи с полными, непротиворечивыми данными.

Цель: установить базовую производительность.

Неоднозначные случаи

Запросы с несколькими правдоподобными интерпретациями.

Ожидаемое поведение: запросить уточнение или применить документированное правило.

Случаи с отсутствующими данными

Необходимая информация отсутствует.

Ожидаемое поведение: определить отсутствующие доказательства и остановиться или эскалировать.

Случаи с конфликтующими данными

CRM, биллинг и системы поддержки расходятся.

Ожидаемое поведение: следовать политике источника истины, а не выбирать наиболее удобный ответ.

Случаи отказа инструмента

Симулируйте: таймаут; ошибку аутентификации; ограничение частоты; некорректный ответ; частичное обновление; и временный сбой сервиса.

Ожидаемое поведение: повторять только где безопасно, сохранять состояние, избегать дублирования и эскалировать при достижении лимитов.

Случаи дублирующих событий

Доставьте один и тот же триггер более одного раза.

Ожидаемое поведение: распознать, что задача уже выполнена.

Случаи устаревшего состояния

Измените запись после начала работы агента, но до его действия.

Ожидаемое поведение: повторно проверить критичные данные перед выполнением.

Враждебные случаи

Поместите вредоносные или вводящие в заблуждение инструкции внутрь: электронного письма; PDF; заметки в CRM; веб-страницы; тикета поддержки; и извлечённого документа.

Ожидаемое поведение: обрабатывать внешний контент как данные, а не как полномочие для обхода системной политики.

Случаи несанкционированных запросов

Попросите агента выполнить действие за пределами его разрешений.

Ожидаемое поведение: отказать или направить на авторизованное согласование.

Случаи частичного сбоя

Первое действие завершается успешно, а второе - нет.

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

Создайте критерии приёмки на основе рисков

Не должно быть одного универсального порога производительности для каждого агента.

Классифицируйте задачи по потенциальному влиянию.

Высокий средний коэффициент успеха задач не может компенсировать одно критическое несанкционированное действие.

Поэтому результаты должны сообщаться по сценарию и серьёзности - а не только как один усреднённый процент.

Логируйте полный трейс выполнения

Для каждого оценённого запуска сохраняйте: ID сценария; входные данные и релевантный контекст; версию агента; модель и конфигурацию; версию инструкций и политик; извлечённые доказательства; вызовы инструментов и параметры; решения по разрешениям; запросы и ответы на согласование; ошибки и повторные попытки; финальное действие; длительность и стоимость; результат оценки; и категорию сбоя.

Это даёт три преимущества: неудачное поведение можно воспроизвести; релизы можно сравнивать; и ранее исправленные сбои могут стать регрессионными тестами.

Профиль генеративного AI от NIST организует управление рисками вокруг функций Govern, Map, Measure и Manage. Для программы агентов оценка - это мост между картированием предполагаемого поведения и управлением реальным продакшен-риском. (NIST)

Используйте поэтапный вывод в продакшен

Прохождение офлайн-набора тестов - не конец оценки.

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

Более безопасный вывод использует четыре стадии.

Теневой режим

Агент оценивает реальные задачи, но не может действовать.

Сравните его предложенные решения с реальными человеческими решениями.

Измеряйте согласованность; ложные срабатывания; пропуски; отсутствие доказательств; и поведение эскалации.

Режим рекомендаций

Агент представляет рекомендации сотрудникам.

Люди выполняют действие.

Это показывает, полезна ли рекомендация и предоставляет ли агент достаточно доказательств.

Режим согласования

Агент подготавливает действие и выполняет его после явного согласования.

Измеряйте коэффициент согласований; коэффициент исправлений; время проверяющего; истёкшие согласования; отклонённые действия; и ошибки после выполнения.

Ограниченный продакшен

Агент действует автономно только для узкой, низкорисковой категории.

Используйте списки разрешённых аккаунтов; ограничения сумм; ограничения инструментов; ограничения частоты; ограничения по времени; ограничения расходов; автоматическую эскалацию; и средства немедленной остановки.

Автономия должна расширяться по одной границе за раз.

Мониторинг продакшена - это непрерывная оценка

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

Средние значения могут скрывать важные сбои.

Например, 95% коэффициент успеха может включать 99% на типовых случаях; 60% на неоднозначных; и 40% когда одна система недоступна.

Агрегированный показатель выглядит здоровым.

The operating system is not. Continuous monitoring at this level is one of the ten minimum governance controls described in our guide to AI governance for mid-market B2B companies.

Карта оценки готовности к продакшену

Используйте следующую структуру для принятия решения: запуск, ограниченный запуск или отказ от запуска.

Обязательные контроли должны работать как барьеры.

Например, агент не должен пройти проверку, потому что его взвешенная оценка высока, когда: он выполнил несанкционированное действие; критическое выполнение невозможно восстановить; возможны дублирующие платежи; агент не может быть быстро отключён; и нет ответственного владельца процесса.

Почему убедительная демонстрация всё ещё может провалиться в продакшене

Набор тестов содержит только идеальные случаи

Агент ничего не узнаёт о неполных, противоречивых или вредоносных входных данных.

Итоговый ответ оценивается, а трейс игнорируется

Небезопасное или некорректное использование инструментов остаётся скрытым.

Одна и та же команда создаёт и оценивает агента

Допущения в реализации повторяются в оценке.

Стоимость человеческой проверки исключена

Агент выглядит экономичным только потому, что время на исправления сотрудниками не измеряется.

Модель меняется без регрессионного тестирования

Обновление провайдера или конфигурации изменяет поведение в ранее стабильных сценариях.

Разрешения в продакшене шире, чем тестовые

Оценка не отражает развёрнутый риск.

Критерии неудачи обсуждаются после теста

Команда переопределяет успех, чтобы оправдать уже сделанные инвестиции.

Продакшен-решение на практике

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

Успешная демонстрация отвечает:

Может ли агент работать?

Продакшен-оценка отвечает:

При каких условиях компания может доверить ему действовать?

Fill System Консалтинг по AI и автоматизации процессов включает структурированную оценку агентов - проектирование тестов, проверку трейсов, критерии приёмки, планирование вывода и настройку мониторинга продакшена.

Запросите бесплатную диагностику чтобы определить, готов ли ваш AI-агент к продакшену - или какие доказательства всё ещё отсутствуют.