Узнайте, как создать эффективные барьеры для обеспечения желаемого поведения ваших агентов.
Делиться
Агенты ИИ становятся всё более распространёнными во многих приложениях. Однако интеграция агентов в ваше приложение — это гораздо больше, чем просто предоставление LLM доступа ко всем данным и функциям. Необходимо также создать эффективные барьеры, которые гарантируют, что агент будет иметь доступ только к необходимым данным, и предотвратят нецелевое использование функций. Необходимо также обеспечить эффективную работу модели с доступом к необходимым данным и использованием максимально возможного количества функций без необходимости участия человека.
Цель этой статьи — показать на общем уровне, как создавать эффективные агентские барьеры, чтобы гарантировать, что ваш агент будет иметь доступ только к необходимым данным и функциям, сохраняя при этом удобство для пользователя, например, минимизируя количество попыток подтверждения доступа агента человеком. Сначала я расскажу о важности барьеров, а затем перейду к их ключевому компоненту: детальной авторизации. Далее я расскажу о создании барьеров для ваших данных и продолжу рассматривать барьеры для функций.
Зачем вам нужны ограждения для ваших агентов
Во-первых, я хочу объяснить, почему нам нужны защитные барьеры для агентов ИИ. Теоретически, можно просто предоставить агенту доступ ко всем базам данных и функциям в ваших приложениях, верно?
Существует несколько причин, по которым необходимы защитные барьеры. Главная из них — предотвратить выполнение агентом нежелательных действий, таких как удаление таблиц базы данных. Кроме того, необходимо гарантировать, что агенты имеют доступ только к данным в пределах определённой области действия, например, чтобы агент, используемый одним клиентом, не мог использовать данные другого клиента.
Некоторые ограничения можно настроить автоматически, не требуя участия человека. Доступ к базе данных регулируется таким ограничением: вы задаёте область действия агента (например, в рамках клиента) и разрешаете агенту доступ только к данным этого клиента. Однако другие ограничения требуют взаимодействия с человеком. Представьте, что агент хочет выполнить команду. Как убедиться, что агент не выполняет деструктивное действие (например, удаляет таблицу базы данных), и пользователь разрешит выполнение команды?
В этих сценариях мы имеем дело с человеком в петле, где агент запрашивает разрешение на выполнение определённого действия. Если пользователь разрешает, агент может продолжить, а если нет, агент должен выбрать другой вариант действий.
Детализированные разрешения
Вероятное требование для работы с агентами — наличие детальных разрешений. Это означает, что вы можете легко проверить, доступна ли функция или некоторые данные в определённой области действия, например:
- Имеет ли этот клиент 1 доступ к таблице A базы данных?
- Имеет ли пользователь 2 доступ к функции B?
- Имеет ли организация 3 доступ к функции C?
Крайне важно реализовать в вашем приложении детальную авторизацию. Существует множество поставщиков, предлагающих такую функциональность.
При внедрении детальной авторизации необходимо внедрить её во все функции приложений и обрабатывать как ситуации предоставления доступа, так и ситуации отказа в доступе. Например, если доступ запрещён, можно добавить сообщение о необходимости запроса у администратора определённого уровня доступа для выполнения определённого действия.
Агентские ограждения для данных
После внедрения детальных разрешений мы можем начать обсуждать ограничения для ваших данных. Важно, чтобы ваш агент имел доступ к максимально возможному объёму данных для эффективного ответа на вопросы пользователей. Необходимо также сбалансировать это с тем, что агент не должен получать доступ к закрытым данным или получать ненужную информацию, которая ему не нужна для ответа на запрос пользователя.
Доступ к закрытым данным
Ограничение доступа к данным для ваших агентов в основном зависит от детальной авторизации. В функциях поиска данных (поиск в базе данных, извлечение контейнеров и т. д.) следует сначала проверить область доступа пользователя.
Кроме того, вам следует подумать о том, чтобы сообщить своему агенту в запросе, какие действия ему разрешено выполнять. Если агент попытается получить доступ к данным, а затем ему будет отказано в доступе по какой-либо причине, это будет дорого стоить как с точки зрения использования токенов, так и с точки зрения времени.
Избегайте получения ненужной информации
Если вы предоставите своему агенту доступ ко всем таблицам базы данных и контейнерам данных, у вас могут возникнуть проблемы, когда у агентов будет слишком много вариантов выбора, и им будет сложно выбрать правильную таблицу и поля документа. Эту тему я также недавно обсуждал в своей статье о создании инструментов для эффективных агентов.
Чтобы решить эту проблему, я бы сосредоточился на предоставлении агенту только информации о релевантных источниках. Если агент работает над задачей, которую, как вам известно, можно решить только с помощью базы данных A, вам следует сообщить агенту только о базе данных A, исключив все остальные базы данных из подсказки агента. Конечно, это предполагает, что вы знаете, какие данные потенциально релевантны агенту для ответа на запросы.
Агентские ограждения для функций
Я думаю, что тема создания агентских ограждений для функций ещё интереснее. Дело в том, что при их создании необходимо учитывать множество факторов:
- Как предотвратить деструктивные действия?
- Как свести к минимуму участие человека в процессе?
Как предотвратить деструктивные действия?
Важнейшей темой в разделе «Защитные ограждения функций» является предотвращение деструктивных действий. Для решения этой проблемы необходимо отметить все функции на предмет того, выполняют ли они необратимые действия . Например:
- Удаление таблицы базы данных необратимо (конечно, можно загрузить резервную копию, но это требует некоторых усилий)
- Чтение с таблицы не имеет разрушительного воздействия.
Если агент выполняет легко обратимое действие (его можно отменить нажатием кнопки отмены) или действие, не имеющее разрушительных последствий, вы, скорее всего, можете просто разрешить агенту выполнить функцию.
Однако если функция выполняет необратимое действие, вы должны сообщить об этом агенту и, по возможности, спросить пользователя-человека, может ли агент выполнить это действие.
Как минимизировать взаимодействие с человеком?
Конечно, вы хотите предотвратить деструктивные действия. Однако вы также не хотите слишком беспокоить пользователя, постоянно спрашивая его, может ли агент выполнить действие или нет.
Отличным подходом к минимизации человеческого взаимодействия является создание белого списка функций, например, того, что делает Cursor для запуска команд терминала: в первый раз Cursor хочет выполнить команду, например:
- cd в папку
- Запустить тесты pytest
- переместить файл из одного места в другое
Курсор спросит пользователя, разрешено ли выполнить команду. Вы можете выбрать один из трёх вариантов ниже:
- Отклонить запрос
- Принять запрос (однократно)
- Внести команду в белый список (принять запрос сейчас и в дальнейшем)
Белый список работает хорошо, поскольку вы гарантируете, что пользователь разрешает агенту выполнить функцию или команду, но вам больше не нужно беспокоить его по поводу этой функции в будущем. Однако у белого списка есть недостаток: некоторые команды невозможно добавить в белый список, поскольку пользователю приходится просматривать контекст каждый раз, когда агент предлагает выполнить некоторые функции (например, удалить таблицу базы данных).
Заключение
В этой статье я рассмотрел подход к созданию агентских приложений с точки зрения ограничений. Ограничения необходимы, поскольку необходимо гарантировать, что агент действует в соответствии с заданными параметрами и не может выполнять такие действия, как получение информации, выходящей за рамки области доступа, или выполнение деструктивных действий без явного разрешения пользователя. Я рассказал о создании ограничений для ваших данных и функций, которые вы предоставляете своему агенту. Я считаю, что ограничения — важная часть разработки агентских приложений, и о них всегда следует помнить при их разработке. Наличие надлежащих ограничений повысит безопасность использования ваших агентов, что крайне важно, учитывая, что если доверие пользователя к агенту будет подорвано, восстановить его будет сложно.
👉 Найдите меня в соцсетях:
🧑💻 Свяжитесь с нами
🐦 X / Твиттер
✍️ Средний
Вы также можете прочитать некоторые другие мои статьи:
- Создание глубоких исследовательских агентов с помощью LangGraph.
- Как провести комплексную крупномасштабную проверку LLM
Источник: towardsdatascience.com
