Проверка действий ИИ-агентов: разрешения, контрольные точки утверждения и уровни риска

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

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

Разницу легче всего увидеть на примере обыденной задачи. Если спросить чат-бота, как упорядочить беспорядочный набор папок, вы получите совет, который можно принять или проигнорировать. Если предоставить агенту права на упорядочивание, он сможет просмотреть каталоги, переименовать и переместить файлы, создать новые папки, обновить записи и удалить то, что он считает дубликатами. Чат-бот предлагает действие; агент его выполняет. Именно эта разница заставляет переосмысливать вопрос надежности, когда на сцену выходят агенты.

Почему неправильное действие стоит дороже, чем неправильный ответ

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

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

Reads information
↓
Makes a decision
↓
Calls another system
↓
Changes something
↓
Continues automatically

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

Минимальные привилегии: ограничение доступа агента

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

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

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

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

Подтверждение человеком важных действий

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

AI identifies issue
↓
AI proposes solution
↓
AI prepares changes
↓
Human reviews
↓
Human approves
↓
System executes

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

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

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

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

Проверка как ключевой навык

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

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

Соответствие автономии уровню риска

Формулировать вопрос «Можно ли доверять ИИ?» с требованием ответа «да» или «нет» бесполезно. Доверие следует оказывать к каждой конкретной задаче пропорционально вероятности возникновения ошибок. Простая трехуровневая модель является хорошей отправной точкой.

Низкий риск: позволить работать автономно

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

Средний риск: автоматизация, затем проверка

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

Высокий риск: требуется явное разрешение

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

Этот принцип можно обобщить так: проверка должна усиливаться по мере роста последствий ошибки.

Больше автономии не всегда лучше

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

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

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

Хорошо спроектированные системы располагают каждую функцию на соответствующем уровне, вместо того чтобы сосредотачивать всё на самом верху.

Вопросы, которые следует задать перед подключением инструмента

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

APIs
Databases
Browsers
File systems
Cloud infrastructure
Development tools
Business applications
External services

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

• К каким данным и системам он может получить доступ?
• Какие из них он может изменить?
• Если он сбоит в процессе выполнения задачи, какое состояние останется?
• Есть ли способ отменить его действия?
• Кто утверждает чувствительные операции?
• Зафиксируется ли каждое действие таким образом, чтобы его можно было позже проверить?
• Как быстро это остановить?

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

Грамотность в области ИИ теперь включает понимание рисков

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

Человеческое суждение, машинная реализация

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

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

Основные выводы

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