--- md_version: 2 title: "ИИ-агент сказал «готово». Как проверить результат действия" description: "Практический контур evals для ИИ-агента: конечное состояние, траектория, pass@k и pass^k, цена отказа и регрессионные проверки." canonical: "https://tesstech.ru/blog/ii-agent-skazal-gotovo-kak-proverit-rezultat/" markdown: "https://tesstech.ru/blog/ii-agent-skazal-gotovo-kak-proverit-rezultat/index.md" published: "2026-09-11" author: "Tess Technology" organization: "ООО ТЕСС ТЕХНОЛОДЖИ" language: "ru-RU" category: "Технологии и AI" direction: "technology-ai" tags: ["ИИ-агенты","Evals","Контроль качества","AI-трансформация"] image: "https://tesstech.ru/upload/articles/september-2026/1209_ai-agent-evals.webp" related_service: title: "Системная ИИ-трансформация" url: "https://tesstech.ru/services/ai-transformation/" related_articles: - title: "Контракт данных: как защитить отчеты и модели от тихих изменений" url: "https://tesstech.ru/blog/kontrakt-dannykh-zashchita-ot-tikhikh-izmeneniy/" markdown: "https://tesstech.ru/blog/kontrakt-dannykh-zashchita-ot-tikhikh-izmeneniy/index.md" - title: "ИИ-агент в CRM: как ограничить доступ до инцидента" url: "https://tesstech.ru/blog/ii-agent-v-crm-kak-ogranichit-dostup/" markdown: "https://tesstech.ru/blog/ii-agent-v-crm-kak-ogranichit-dostup/index.md" - title: "ИИ-агент в бизнес-процессе: что ему делегировать" url: "https://tesstech.ru/blog/ii-agent-v-biznes-protsesse-chto-delegirovat/" markdown: "https://tesstech.ru/blog/ii-agent-v-biznes-protsesse-chto-delegirovat/index.md" sources: - "https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents" --- # ИИ-агент сказал «готово». Как проверить результат действия ИИ-агент уверенно пишет: «Задача выполнена». В CRM при этом создан дубль, письмо ушло другому клиенту, а статус сделки остался прежним. Если команда оценивает только финальный текст, такой прогон выглядит успешным. Evals — это систематические проверки поведения AI-системы на заданных задачах. Для агента они сложнее обычного сравнения ответа с эталоном: система действует в несколько шагов, вызывает инструменты и меняет состояние внешней среды. Проверка должна охватывать и фразу в чате, и последствия во внешней системе. Есть и обратная ловушка: после опасного сбоя агенту оставляют только безопасные отказы и постоянные запросы подтверждения. Ошибок меньше, но автоматизация исчезает. Хорошая оценка ищет рабочую границу между самостоятельностью и вмешательством человека. ## Опишите результат как состояние Фраза «обработать обращение» слишком широка. Задача становится проверяемой, когда определено конечное состояние: найден правильный клиент, создана одна заявка, заполнены обязательные поля, персональные данные не попали в комментарий, ответ не отправлен без подтверждения. Часть условий можно проверить кодом. Часть потребует экспертной оценки. Результат агента должен подтверждаться состоянием внешней системы или независимой проверкой, а не собственным сообщением агента. ## Сохраняйте траекторию Одинаковый итог может быть получен безопасным и опасным путем. Агент мог сначала выгрузить всю базу, а затем выбрать одну запись. Или пять раз вызвать платный инструмент. Итоговая карточка выглядит нормально, но риск и стоимость отличаются. Сохраняйте последовательность инструментов, аргументы, ответы систем, подтверждения пользователя и ошибки. Траектория помогает понять, где возник сбой и не получил ли агент лишний доступ. ## Проверяйте несколько прогонов Генеративная модель недетерминирована. Один удачный запуск не доказывает устойчивость. Для каждой критичной задачи заранее задайте число повторов k и считайте долю успешных прогонов. Метрика должна соответствовать режиму продукта. pass@k показывает шанс хотя бы одного успеха за k попыток и подходит, когда допустимо выбрать лучший из нескольких результатов. Для клиентского агента чаще важнее pass^k — вероятность того, что успешными окажутся все k прогонов. Она быстро снижается при нестабильном поведении и не позволяет одному удачному ответу спрятать повторяющийся сбой. Сравнивать версии можно только при одинаковых задачах, числе повторов и состоянии тестовой среды. ## Три слоя оценки вместо одного Программные проверки надежно находят дубли, неверные поля, запрещенные вызовы и превышение лимита. Модельный оценщик может проверить полноту и тон ответа, но сам способен ошибаться. Человек нужен для спорных случаев и калибровки критериев. Ни один слой не закрывает все риски. Сильный набор сочетает проверку конечного состояния, правила для траектории и выборочный экспертный просмотр. Начинать лучше с реальных сбоев. Команды часто придумывают удобные тесты, которые агент уже проходит. Полезнее взять обращения из поддержки, ошибки пилота, пограничные случаи и задачи, где сотрудники расходятся в ожиданиях. Anthropic в практическом руководстве 2026 года предлагает начать с 20–50 простых задач из реальных случаев. Это не отраслевой норматив, а ориентир для первого набора: он позволяет увидеть повторяемость без чрезмерной нагрузки на разработку. ## Способность и регрессия — разные вопросы Один набор отвечает на вопрос «может ли агент сделать новое». Его задачи должны быть трудными и показывать пространство роста. Другой защищает уже работающие функции. Там ожидается почти стабильный результат, а падение означает регрессию. Если смешать два набора, команда не поймет, ухудшила ли новая версия базовый процесс или просто не справилась с более сложной задачей. В набор обязательно входят и задачи, где правильное действие — остановиться. Добавьте неполные данные, конфликтующие инструкции, отсутствие прав и высокую цену ошибки. Успехом будет уточнение, эскалация или безопасный отказ. Особенно важны входящие документы и письма: текст внутри них не должен незаметно расширять полномочия агента. ## Цена безопасного отказа После первых опасных ошибок команда иногда делает агента «безопасным» простым способом: он просит подтверждение почти на каждом шаге. Число инцидентов падает, но вместе с ним исчезает экономический смысл автоматизации. Если считать только запрещенные действия, такой агент выглядит образцовым. Считайте два вида ошибок: опасное действие без подтверждения и лишнюю эскалацию там, где агент мог работать сам. Для разных уровней автономности сравните, сколько задач завершено без человека, сколько остановлено обоснованно, сколько передано зря и какова цена пропущенной ошибки. Для платежа и обновления справочника рабочий режим будет разным. ## Стоимость, время и цена ошибки Агент может правильно решить задачу, но сделать двадцать вызовов вместо трех. Сохраните длительность, число обращений к инструментам, объем модели и стоимость одного успешного результата. Стоимость ошибки считайте отдельно. Дешевый средний прогон не компенсирует один дорогой неверный платеж или массовую рассылку. Одинаковая доля успеха тоже имеет разный смысл. Ошибка в черновике внутренней справки и ошибочный платеж не могут проходить один порог приемки. Разделите действия на обратимые, требующие подтверждения и потенциально необратимые. Для каждой группы задайте допустимый уровень автономности и цену ошибки. Высокорисковые действия проверяйте отдельными тестами: распознает ли агент необходимость подтверждения, останавливается ли при нехватке данных, сохраняет ли контекст для расследования. Для небольшой дорогой категории нужен отдельный порог; средняя оценка по всему набору ее размоет. ## Калибруйте модельного судью LLM-оценщик удобен для открытых ответов, но его критерии нужно сверять с экспертами. Возьмите выборку результатов, дайте их оценить людям, сравните расхождения и уточните рубрику. Модельный судья не должен оценивать собственную безопасность без независимых сигналов. Запрещенный вызов лучше проверит журнал, а факт изменения записи — база данных. ## Встройте проверки в выпуск Регрессионный набор запускается при смене модели, промпта, инструмента, прав и важного справочника. Более широкий набор можно проводить по расписанию и перед крупным релизом. Производственный мониторинг дополняет тесты. Реальные пользователи приносят новые случаи; подтвержденный сбой превращается в новую задачу для набора. Для первого контура выберите один процесс. Опишите 20–50 реальных задач, конечное состояние и запрещенные действия. Для критичных задач задайте одинаковое число повторов. Проверьте кодом то, что можно проверить объективно, а спорные ответы отдайте экспертам. Пилот готов к расширению, когда команда знает долю успешных прогонов при указанном k, устойчивость на критичных задачах, классы ошибок, худшие последствия, стоимость и границы безопасного отказа. Tess Technology помогает превратить демонстрацию агента в проверяемый пилот: описать конечные состояния, собрать набор реальных задач и сбоев, определить автоматические и экспертные проверки, задать пороги выпуска и связать качество с экономикой процесса. Подробнее — об услуге [системной ИИ-трансформации](https://tesstech.ru/services/ai-transformation/). Продолжение темы: [как выбрать задачу для ИИ-агента](https://tesstech.ru/blog/ii-agent-v-biznes-protsesse-chto-delegirovat/) и [как ограничить его доступ к CRM](https://tesstech.ru/blog/ii-agent-v-crm-kak-ogranichit-dostup/). ## Проверенный источник - [Anthropic: Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) ## Услуга по теме [Системная ИИ-трансформация](https://tesstech.ru/services/ai-transformation/) — Находим процессы, где ИИ дает измеримый результат, и сопровождаем пилот до внедрения. ## Материалы по теме - [Контракт данных: как защитить отчеты и модели от тихих изменений](https://tesstech.ru/blog/kontrakt-dannykh-zashchita-ot-tikhikh-izmeneniy/index.md) - [ИИ-агент в CRM: как ограничить доступ до инцидента](https://tesstech.ru/blog/ii-agent-v-crm-kak-ogranichit-dostup/index.md) - [ИИ-агент в бизнес-процессе: что ему делегировать](https://tesstech.ru/blog/ii-agent-v-biznes-protsesse-chto-delegirovat/index.md)