Raft показала, как компаниям оценивать AI-агентов до запуска в рабочих процессах

Raft выпустила практический разбор того, как компаниям проверять надёжность AI-агентов до того, как доверять им реальные бизнес-процессы. Главная мысль статьи простая: агенту нельзя верить по демонстрации или среднему проценту успеха — его нужно регулярно прогонять через evals с чёткими критериями.

Почему доверия мало

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

У модели нет собственных стимулов вести себя «правильно», поэтому доверие к ней нельзя строить на ощущениях, обещаниях вендора или одном удачном пилоте. Авторы предлагают смотреть на доверие как на повторяемость результата. Если система много раз получает похожие входные данные и стабильно выдаёт ожидаемый результат, ей можно поручать этот класс задач.

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

Как собрать eval set

Отправная точка — ground truth set: набор реальных или максимально приближенных к реальности кейсов, где входные данные связаны с ожидаемым результатом. Обычно такой набор собирают из исторических задач, которые команда уже обрабатывала вручную. В статье отдельно подчёркивается, что для evals не нужны тысячи примеров, как для дообучения.

Важнее, чтобы каждый кейс был однозначным: два независимых эксперта должны одинаково ответить, прошёл агент проверку или нет. Типовой eval set состоит из нескольких слоёв: задачи с конкретными входными данными и критерием успеха тестового прогона агента с итоговым результатом одного или нескольких graders для разных аспектов качества транскрипта шагов: вызовов инструментов, промежуточных действий и логики маршрута В качестве примера Raft описывает агента поддержки интернет-магазина, который обрабатывает возвраты. Один кейс проверяет простой возврат в пределах 30 дней, другой — отказ по заявке вне политики, третий — неоднозначную ситуацию, где нельзя ни автоматически вернуть деньги, ни просто отказать без уточнений.

Такой дизайн показывает важную вещь: оценивать нужно не только конечный ответ, но и поведение по дороге к нему. Иногда лучший результат — не действие, а корректная эскалация на человека. Для самих проверок можно смешивать три подхода.

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

Какие метрики смотреть Отдельный акцент в статье — на том, что агентные системы недетерминированы.

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

95% прохождения звучит здорово — пока ошибки не сидят во false positives.

Именно поэтому одного pass rate недостаточно. Для бинарных решений полезно смотреть на confusion matrix, precision, recall и F1, потому что разные типы ошибок стоят бизнесу по-разному. Агент, который слишком легко одобряет возвраты, создаёт одну категорию риска; агент, который массово отклоняет законные запросы, — совсем другую. Поверх этого авторы напоминают о типичных ловушках: законе Гудхарта, устаревании eval-набора и иллюзии «зелёного» дашборда, когда метрика выглядит нормально, а реальные жалобы пользователей растут.

Что это значит

Для компаний, которые хотят внедрять AI-агентов в поддержку, операции или разработку, главный вывод один: сначала нужно строить систему проверки, а уже потом масштабировать автоматизацию. Побеждают не те команды, у кого агент выглядит умнее на демо, а те, кто понимает цену его ошибок, умеет измерять качество по сценариям и регулярно обновляет evals вместе с продуктом.