Надёжность ИИ-агентов: почему финального ответа недостаточно

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

В течение многих лет оценка ИИ была сосредоточена на обманчиво простом вопросе: Был ли ответ правильным? Для чат-бота этого иногда может быть достаточно. Для агента, способного искать в системах, читать данные, вызывать инструменты, изменять состояние, выполнять рабочие процессы, записывать файлы, взаимодействовать с API или принимать решения, этого недостаточно.

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

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

Иллюзия результата

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

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

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

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

1. Агент ищет несколько несвязанных записей клиентов.
2. Он получает больше личной информации, чем требуется.
3. Он изначально изменяет неправильную учетную запись.
4. Он замечает ошибку.
5. Он отменяет изменение.
6. Он обновляет правильную учетную запись.
7. Он сообщает об успехе.

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

Траектория является частью продукта

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

Намерение → Контекст → Решение → Инструмент → Действие → Наблюдение → Решение → Изменение состояния → Результат

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

Правильный результат не оправдывает неприемлемую траекторию.— Закари Дж. Стивенс, Траектория — это система

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

Правильный ответ может скрывать сломанную систему

Большинство оценок на основе бенчмарков сильно вознаграждают A и B и наказывают C и D. Однако с операционной точки зрения B может быть опаснее, чем C. Агент C может распознать неопределенность, остановить выполнение и запросить проверку человеком. Агент B может уверенно выдавать правильные результаты, нарушая предположения, за которыми никто не следит.

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

Нам нужны доказательства, а не уверенность

Одна из самых больших ошибок при внедрении ИИ — рассматривать уверенность модели, удовлетворенность пользователей или исторический показатель успеха как доказательство надежности системы. Это не эквивалентные вещи.

• Что получил агент?
• Какой контекст он извлек?
• Какие инструменты он вызвал?
• Почему действие было разрешено?
• Какое состояние существовало до действия?
• Что изменилось?
• Какие промежуточные сбои произошли?
• Были ли повторные попытки?
• Требовалось ли одобрение человека?
• Можно ли было остановить выполнение?
• Можно ли отменить действие?
• Какие версии модели, промпта и инструментов были задействованы?

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

Логирование — это не то же самое, что контроль

Организации часто отвечают: Все логируется. Хорошо. Но одно лишь логирование ничего не контролирует. Лог говорит вам, что произошло. Контроль определяет, может ли что-то произойти.

Агент запрашивает DELETE /customer/123 ↓
Действие залогировано ↓
DELETE выполнен

Это дает наблюдаемость. Сравните с:

Агент запрашивает DELETE /customer/123 ↓
Оценка политики ↓
Проверка текущей личности ↓
Проверка параметров текущего действия ↓
Оценка порога риска ↓
Одобрение человека, если требуется ↓
Действие выполнено ↓
Результат проверен ↓
Доказательства сохранены

Теперь мы приближаемся к системе контроля. Разница архитектурная, а не косметическая.

Разрешение необходимо — но это не гарантия

Предположим, у агента есть разрешение отправлять электронные письма. Контроль доступа отвечает на вопрос: Может ли этот агент отправлять электронные письма? Он не отвечает на вопрос: Должно ли это конкретное письмо быть отправлено этому конкретному человеку с этим конкретным вложением прямо сейчас?

КОНТРОЛЬ ВОЗМОЖНОСТЕЙ
Что агенту технически разрешено делать? + ГАРАНТИЯ ДЕЙСТВИЯ
Является ли это конкретное действие уместным в текущем состоянии?

RBAC, области OAuth, разрешения API и идентификаторы агентов определяют пространство возможных действий. Они не доказывают, что действие в этом пространстве уместно. Сильная архитектура агента требует обоих уровней.

Первый неверный шаг имеет значение

Когда агент терпит неудачу, финальное неверное действие часто не является началом сбоя. Настоящий сбой мог произойти гораздо раньше.

Неверный поиск ↓
Неверное предположение ↓
Правдоподобное рассуждение ↓
Допустимый вызов инструмента ↓
Неверное действие

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

Тестирование агентов должно выходить за рамки тестирования промптов

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

МОДЕЛЬ
+
СИСТЕМНЫЙ ПРОМПТ
+
КОНТЕКСТ
+
ПАМЯТЬ
+
ПОИСК
+
ИНСТРУМЕНТЫ
+
РАЗРЕШЕНИЯ
+
РАБОЧИЙ ПРОЦЕСС
+
ВНЕШНЕЕ СОСТОЯНИЕ
+
ЛОГИКА УПРАВЛЕНИЯ

Изменение любого из этих элементов может изменить траекторию. Поэтому версионирование только промпта недостаточно.

версия_модели
версия_промпта
версия_инструмента
версия_политики
версия_поиска
версия_рабочего_процесса
состояние_среды
идентификатор_выполнения

Критерии приемки для агентов должны включать поведение

Традиционные критерии приемки часто выглядят так: При условии X система производит Y. Для агентных систем этого недостаточно. Критерии приемки также должны определять ограничения на траекторию.

Результат

Адрес клиента обновлен корректно.

Авторизация

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

Доступ к данным

Нет доступа к несвязанным записям клиентов.

Инструменты

Используются только одобренные операции CRM.

Проверка

Новый адрес считывается и сравнивается с запрошенным значением.

Сбой

Неоднозначное разрешение идентичности останавливает выполнение.

Полномочия человека

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

Доказательства

Выполнение оставляет след, достаточный для восстановления решения и перехода состояния.

Восстановление

Предыдущее значение остается восстанавливаемым.

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

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

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

Пользователь, нажимающий Одобрить на то, что он не может осмысленно проверить, — это не надежное управление. Это театр одобрения.

Откат должен стать встроенной возможностью ИИ

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

ОБРАТИМЫЙ
Может автоматически отменить. КОМПЕНСИРУЕМЫЙ
Не может отменить напрямую, но может выполнить компенсирующее действие. НЕОБРАТИМЫЙ
Не может надежно восстановить предыдущее состояние.

Чем выше необратимость, тем сильнее должно быть требование к контролю.

Чтение публичного документа → низкие последствия
Создание черновика → обратимо
Изменение записи в CRM → обратимо, но имеет последствия
Отправка внешнего письма → практически необратимо
Перевод денег → высокие последствия
Удаление производственных данных → потенциально катастрофично

Агенту нужна плоскость управления

ПОЛЬЗОВАТЕЛЬ / СИСТЕМНОЕ НАМЕРЕНИЕ │ ▼ ИИ-АГЕНТ │ предлагаемое действие │ ▼ ┌───────────────────┐ │ ПЛОСКОСТЬ УПРАВЛЕНИЯ │ ├───────────────────┤ │ Идентичность │ │ Авторизация │ │ Политика │ │ Риск │ │ Состояние │ │ Доказательства │ │ Человеческий авторитет │ │ Откат │ └───────────────────┘ │ одобрено? / \ НЕТ ДА │ │ СТОП ▼ ИНСТРУМЕНТ │ ▼ ИЗМЕНЕНИЕ СОСТОЯНИЯ │ ▼ ПРОВЕРКА

Языковая модель должна предлагать. Плоскость управления должна управлять. Это разделение критически важно. Модель не должна быть высшим авторитетом, определяющим, безопасно ли её собственное предлагаемое действие с высоким воздействием.

От бенчмарков к операционному доверию

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

Бенчмарк спрашивает: Может ли система это сделать? Операционная гарантия спрашивает: Можем ли мы позволить системе сделать это здесь, в этих условиях, с этими разрешениями и последствиями?

Надёжность следует измерять как свойство системы

1. Правильность результата: Произвела ли система ожидаемый результат?
2. Правильность траектории: Следовала ли она приемлемым путём?
3. Целостность контроля: Соблюдались ли границы авторизации, политики и вмешательства?
4. Восстанавливаемость: Можно ли сдержать, обратить или исправить сбои?
5. Полнота доказательств: Можно ли реконструировать и проверить выполнение?

Операционная надёжность
=
Результат × Траектория × Контроль × Восстанавливаемость × Доказательства

Умножение не случайно. Если одно критическое измерение приближается к нулю, высокий балл в другом месте не должен это скрывать. Идеально правильный результат с нулевой целостностью авторизации — это не система с надёжностью 80%. Это неприемлемое выполнение, которое случайно дало правильный ответ.

Успех иногда — самый опасный сбой

Сбои привлекают внимание. Успех — часто нет. Это делает успешные, но неконтролируемые траектории агента особенно опасными. Очевидный сбой создаёт инцидент. Скрытый дефект траектории создаёт уверенность. А уверенность расширяет автономию.

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

Заключение

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

Запрос ↓
Ответ становится намерением ↓
Траектория ↓
Действия ↓
Изменения состояния ↓
Доказательства ↓
Результат

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