ИИ-агент уверенно пишет: «Задача выполнена». В CRM при этом создан дубль, письмо ушло другому клиенту, а статус сделки остался прежним. Если команда оценивает только финальный текст, такой прогон выглядит успешным.
Evals — это систематические проверки поведения AI-системы на заданных задачах. Для агента они сложнее обычного сравнения ответа с эталоном: система действует в несколько шагов, вызывает инструменты и меняет состояние внешней среды. Проверка должна охватывать и фразу в чате, и последствия во внешней системе.
Есть и обратная ловушка: после опасного сбоя агенту оставляют только безопасные отказы и постоянные запросы подтверждения. Ошибок меньше, но автоматизация исчезает. Хорошая оценка ищет рабочую границу между самостоятельностью и вмешательством человека.
Опишите результат как состояние
Фраза «обработать обращение» слишком широка. Задача становится проверяемой, когда определено конечное состояние: найден правильный клиент, создана одна заявка, заполнены обязательные поля, персональные данные не попали в комментарий, ответ не отправлен без подтверждения.
Часть условий можно проверить кодом. Часть потребует экспертной оценки. Результат агента должен подтверждаться состоянием внешней системы или независимой проверкой, а не собственным сообщением агента.
Сохраняйте траекторию
Одинаковый итог может быть получен безопасным и опасным путем. Агент мог сначала выгрузить всю базу, а затем выбрать одну запись. Или пять раз вызвать платный инструмент. Итоговая карточка выглядит нормально, но риск и стоимость отличаются.
Сохраняйте последовательность инструментов, аргументы, ответы систем, подтверждения пользователя и ошибки. Траектория помогает понять, где возник сбой и не получил ли агент лишний доступ.
Проверяйте несколько прогонов
Генеративная модель недетерминирована. Один удачный запуск не доказывает устойчивость. Для каждой критичной задачи заранее задайте число повторов k и считайте долю успешных прогонов.
Метрика должна соответствовать режиму продукта. pass@k показывает шанс хотя бы одного успеха за k попыток и подходит, когда допустимо выбрать лучший из нескольких результатов. Для клиентского агента чаще важнее pass^k — вероятность того, что успешными окажутся все k прогонов. Она быстро снижается при нестабильном поведении и не позволяет одному удачному ответу спрятать повторяющийся сбой. Сравнивать версии можно только при одинаковых задачах, числе повторов и состоянии тестовой среды.
Три слоя оценки вместо одного
Программные проверки надежно находят дубли, неверные поля, запрещенные вызовы и превышение лимита. Модельный оценщик может проверить полноту и тон ответа, но сам способен ошибаться. Человек нужен для спорных случаев и калибровки критериев.
Ни один слой не закрывает все риски. Сильный набор сочетает проверку конечного состояния, правила для траектории и выборочный экспертный просмотр.
Начинать лучше с реальных сбоев. Команды часто придумывают удобные тесты, которые агент уже проходит. Полезнее взять обращения из поддержки, ошибки пилота, пограничные случаи и задачи, где сотрудники расходятся в ожиданиях.
Anthropic в практическом руководстве 2026 года предлагает начать с 20–50 простых задач из реальных случаев. Это не отраслевой норматив, а ориентир для первого набора: он позволяет увидеть повторяемость без чрезмерной нагрузки на разработку.
Способность и регрессия — разные вопросы
Один набор отвечает на вопрос «может ли агент сделать новое». Его задачи должны быть трудными и показывать пространство роста. Другой защищает уже работающие функции. Там ожидается почти стабильный результат, а падение означает регрессию.
Если смешать два набора, команда не поймет, ухудшила ли новая версия базовый процесс или просто не справилась с более сложной задачей.
В набор обязательно входят и задачи, где правильное действие — остановиться. Добавьте неполные данные, конфликтующие инструкции, отсутствие прав и высокую цену ошибки. Успехом будет уточнение, эскалация или безопасный отказ. Особенно важны входящие документы и письма: текст внутри них не должен незаметно расширять полномочия агента.
Цена безопасного отказа
После первых опасных ошибок команда иногда делает агента «безопасным» простым способом: он просит подтверждение почти на каждом шаге. Число инцидентов падает, но вместе с ним исчезает экономический смысл автоматизации. Если считать только запрещенные действия, такой агент выглядит образцовым.
Считайте два вида ошибок: опасное действие без подтверждения и лишнюю эскалацию там, где агент мог работать сам. Для разных уровней автономности сравните, сколько задач завершено без человека, сколько остановлено обоснованно, сколько передано зря и какова цена пропущенной ошибки. Для платежа и обновления справочника рабочий режим будет разным.
Стоимость, время и цена ошибки
Агент может правильно решить задачу, но сделать двадцать вызовов вместо трех. Сохраните длительность, число обращений к инструментам, объем модели и стоимость одного успешного результата.
Стоимость ошибки считайте отдельно. Дешевый средний прогон не компенсирует один дорогой неверный платеж или массовую рассылку.
Одинаковая доля успеха тоже имеет разный смысл. Ошибка в черновике внутренней справки и ошибочный платеж не могут проходить один порог приемки. Разделите действия на обратимые, требующие подтверждения и потенциально необратимые. Для каждой группы задайте допустимый уровень автономности и цену ошибки.
Высокорисковые действия проверяйте отдельными тестами: распознает ли агент необходимость подтверждения, останавливается ли при нехватке данных, сохраняет ли контекст для расследования. Для небольшой дорогой категории нужен отдельный порог; средняя оценка по всему набору ее размоет.
Калибруйте модельного судью
LLM-оценщик удобен для открытых ответов, но его критерии нужно сверять с экспертами. Возьмите выборку результатов, дайте их оценить людям, сравните расхождения и уточните рубрику.
Модельный судья не должен оценивать собственную безопасность без независимых сигналов. Запрещенный вызов лучше проверит журнал, а факт изменения записи — база данных.
Встройте проверки в выпуск
Регрессионный набор запускается при смене модели, промпта, инструмента, прав и важного справочника. Более широкий набор можно проводить по расписанию и перед крупным релизом.
Производственный мониторинг дополняет тесты. Реальные пользователи приносят новые случаи; подтвержденный сбой превращается в новую задачу для набора.
Для первого контура выберите один процесс. Опишите 20–50 реальных задач, конечное состояние и запрещенные действия. Для критичных задач задайте одинаковое число повторов. Проверьте кодом то, что можно проверить объективно, а спорные ответы отдайте экспертам.
Пилот готов к расширению, когда команда знает долю успешных прогонов при указанном k, устойчивость на критичных задачах, классы ошибок, худшие последствия, стоимость и границы безопасного отказа.
Tess Technology помогает превратить демонстрацию агента в проверяемый пилот: описать конечные состояния, собрать набор реальных задач и сбоев, определить автоматические и экспертные проверки, задать пороги выпуска и связать качество с экономикой процесса. Подробнее — об услуге системной ИИ-трансформации.
Продолжение темы: как выбрать задачу для ИИ-агента и как ограничить его доступ к CRM.
