Допустим, вы внедрили LLM-агента в финансовый отдел компании. Все хорошо, пока вы не решаете его подправить: добавить инструкцию или сделать тон дружелюбнее. С точки зрения классического инфобеза вам нужно все перевалидировать.
Личность вашего агента (инструкции, тон, самопрезентации и так далее) живет в одном доверительном домене с действиями агента. Если домен строгий, каждое изменение придется сертифицировать. Если же домен разрешительный, аудит только фиксирует действия в логах, но ничего не блокирует.
Проблема в том, что некоторые домены обязаны быть строгими. А некоторые из строгих надо менять так часто, что постоянно перевалидировать неудобно.
В этом материале расскажу о работе китайского исследователя Исена Си (Yisen Xi), который описал подход PES (Persona–Execution Separation), отделяющий «личность» виртуального агента от задач.
NB! PES требует ресурсов; это не «еще один уровень абстракции»; оно работает и заслуживает рассмотрения.
Промпты решают не все
В LLM-агентах и личность, и инструкции пользователя — один и тот же текст. Отредактировав промпт, вы измените логику решений или тон так же, как если бы поменялась инструкция в личности. Ни модель, ни система контроля не увидят разницы.
Получается, к одному доверительному домену — тексту — у нас два противоречивых требования.
С одной стороны, личность агента должна развиваться, для чего операторы настраивают инструкции, тон и привязку навыков. И конечно, не разово настраивают, а непрерывно улучшают.
С другой — исполнение должно быть аудируемым. Каждое действие, изменяющее состояние, будь то платеж, заявка или одобрение, должно быть записано, привязано к стабильной идентичности и доступно для проверки.
Кто пробовал строить такие системы, прекрасно знает, что придется выбирать из двух зол: либо заморозить личность, потому что каждый раз поменять — бюрократический ад; либо ослабить аудит. Первое приводит к тому, что агент не развивается. Второе — к тому, что вы вроде бы записываете логи, но личность меняется — и прошлые действия уже не связаны с новым агентом.
На рынке эти подходы используют несколько моделей. Однодоменные агенты ChatGPT и ReAct замораживают личность. LangChain и Dify, наоборот, дают свободу личности с отслеживаемостью на уровне инструментов.
Готовим требования к агенту
Исену Си было недостаточно выбора между свободной и замороженной личностями, так что он предложил модель из трех уровней:
-
G1 — свободный дрейф личности. Меняем инструкции, тон, навыки — никакой перевалидации.
-
G2 — полный аудит каждого действия. Привязан к стабильной идентичности.
-
G3 — разделение. Изменения личности не влияют на аудит.
Поговорим о реализации.
Один виртуальный сотрудник и два доверительных домена
Автор придумал простую, но не тривиальную схему: личность и исполнение не обязаны находиться в одном доверительном домене.
Предлагаемая архитектура PES состоит из трех частей: разрешающего домена, ограничивающего домена и управляемого контрактного моста. Рассмотрим их.
Разрешающий домен
Содержит личность агента: инструкции, тип общения, самопрезентации и настройки навыков. Здесь операторы могут править промпты, тестировать поведение и общаться в диалоговом интерфейсе. По сути, можно менять все без последствий и вам не потребуются никакие согласования и повторные валидации.
Ограничивающий домен
Все жестче. Вызывают инструменты для стандартных операционных процедур (SOP). Действия контролируют по матрице утверждений: запретить, спросить, разрешить. В этом домене у нас нет личности как таковой, агент просто выполняет SOP. Соответственно, пользовательская поверхность — не чат-бот, а формы, движок процессов и бухгалтерская книга.
Третий домен — управляемый контрактный мост
В этом случае два домена соединяются не произвольным API, а строгим контрактом, который пропускает только определенные типы трафика:
-
Первый тип трафика — данные из ограничивающего домена в разрешающий. В диалоге вы увидите только «Заявка на этапе согласования» без деталей: цифры, файлы и прочее останутся в ограничивающем домене.
-
Второй тип трафика назовем базовым. Здесь данные не покидают ограничивающий домен в произвольном виде, за исключение случаев использования DLP — о нем еще поговорим.
-
И третий тип трафика предполагает непрерывность идентификации. Когда пользователь переходит из диалога в интерфейс выполнения, он не теряет контекст, так как кнопка «Вернуться в диалог» с идентификатором сессии работает как надо. То есть это один виртуальный сотрудник, а не два разных агента.
Соответственно, мост — это не туннель, а контрольно-пропускной пункт. Там проверяются разрешения в списке контроля доступа и в матрице утверждений, после чего вносится запись в аудит. А при необходимости на мосту мы будем предотвращать утечки конфиденциальных данных (Data Leakage Prevention).
Обращаю внимание читателя на пару интересных нюансов:
-
В ограничивающем домене нет копии личности агента. Это сознательное решение: копия — второй источник правды, который может рассинхронизироваться с первым. Так что вместо копирования предлагают так называемую привязку возможностей. То есть разрешающий домен знает, какие SOP может инициировать агент, но сама SOP (логика, версионирование, полномочия) остается в ограничивающем домене. Уместна аналогия со списком ссылок вместо набора готовых файлов.
-
Наш дрейф не безграничный, и мы не можем менять все что угодно. Личность имеет базовый слой (имя сотрудника, роль, привязку к SOP), и вот это промптом не переделать. А вот инструкции, тон, самопрезентацию и настройку навыков можно править свободно.
При этом аудиторский реестр привязан к базовому слою. И когда вы меняете тон общения — реестр стабилен.
Вы можете сказать: «Ну автор просто вынес исполнение в отдельный сервис, это же обычный паттерн». Не совсем так, или даже совсем не так. Обычный паттерн работает по принципу master-slave, то есть агент просто вызывает функцию. А архитектура PES предлагает контрольный контракт, определяющий утверждение, аудит и идентичность. При этом в PES один виртуальный сотрудник может работать в разных доверительных доменах.
Результаты проверки PES
Автор работы проверил механизм на пяти конфигурациях модели (менял персону) и получил, что изменение личности не требует повторной валидации на стороне выполнения. То есть он поменял инструкции — и агент продолжал работать, аудит тоже не сломался. В жестко заданных полях не остается следов персоны. То есть ограничивающий домен не знает, какой тон общения вы выбрали, — только какую SOP выполнять.
Изначально автор предполагал, что можно разделить личность и исполнение. Через месяц пилота, пять принятых решений и кучу отклоненных альтернатив он получил подтвержденный архитектурный паттерн. Он, конечно, не идеален и не избавит ото всех проблем с LLM-агентами. Но решает поставленную задачу: менять агента без перевалидации, сохраняя полный аудит.
Когда применять PES, а когда нет
Если вы создаете виртуальных сотрудников в финансовом секторе, здравоохранении или госсекторе — посмотрите на PES. Возможно, вам нужно именно это. Для многопользовательских развертываний PES подходит идеально, так как несколько операторов могут использовать одного агента, меняя его роли и ничего больше.
Также архитектура хорошо ложится на системы с требованиями к аудиту, например там, где некоторые действия должны быть строго записаны и привязаны к стабильной идентичности агента.
PES эффективен и когда необходимо часто менять личность. Например, там, где инструкции, тон и навыки должны исправляться регулярно. А вот если у вас один пользователь и один агент, действия которого не нужно аудировать, то PES вам вряд ли нужен. И если личность вашего агента меняется раз в год — проще перевалидировать.
Автор: aberglaube
