Зачем разделять роль и личность у виртуальных сотрудников

Допустим, вы внедрили LLM-агента в финансовый отдел компании. Все хорошо, пока вы не решаете его подправить: добавить инструкцию или сделать тон дружелюбнее. С точки зрения ^[1] классического инфобеза вам нужно все перевалидировать. 

Личность вашего агента ^[2] (инструкции, тон, самопрезентации и так далее) живет в одном доверительном домене с действиями агента. Если домен строгий, каждое изменение придется сертифицировать. Если же домен разрешительный, аудит только фиксирует действия в логах, но ничего не блокирует. 

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

В этом материале расскажу о работе китайского исследователя Исена Си (Yisen Xi), который описал подход PES (Persona–Execution Separation ^[3]), отделяющий «личность» виртуального агента от задач.

NB! PES требует ресурсов; это не «еще один уровень абстракции»; оно работает и заслуживает рассмотрения.

Промпты решают не все

В LLM-агентах и личность, и инструкции пользователя — один и тот же текст. Отредактировав промпт, вы измените логику ^[4] решений или тон так же, как если бы поменялась инструкция в личности. Ни модель, ни система контроля не увидят разницы.

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

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

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

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

На рынке эти подходы используют несколько моделей. Однодоменные агенты ChatGPT и ReAct замораживают личность. LangChain и Dify, наоборот, дают свободу личности с отслеживаемостью на уровне инструментов.

Готовим требования к агенту

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

• G1 — свободный дрейф личности. Меняем инструкции, тон, навыки — никакой перевалидации.

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

• G3 — разделение. Изменения личности не влияют на аудит.

Поговорим о реализации.

Один виртуальный сотрудник и два доверительных домена

Автор придумал простую, но не тривиальную схему: личность и исполнение не обязаны находиться в одном доверительном домене.

Предлагаемая архитектура PES состоит из трех частей: разрешающего домена, ограничивающего домена и управляемого контрактного моста. Рассмотрим их.

Разрешающий домен 

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

Ограничивающий домен 

Все жестче. Вызывают инструменты для стандартных операционных процедур (SOP). Действия контролируют по матрице утверждений: запретить, спросить, разрешить. В этом домене у нас нет личности как таковой, агент просто выполняет SOP. Соответственно, пользовательская поверхность — не чат-бот, а формы, движок процессов и бухгалтерская книга.

Третий домен — управляемый контрактный мост 

В этом случае два домена соединяются не произвольным API, а строгим контрактом, который пропускает только определенные типы трафика: 

• Первый тип трафика — данные из ограничивающего домена в разрешающий. В диалоге вы увидите только «Заявка на этапе согласования» без деталей: цифры, файлы и прочее останутся в ограничивающем домене.

• Второй тип трафика назовем базовым. Здесь данные не покидают ограничивающий домен в произвольном виде, за исключение случаев использования DLP — о нем еще поговорим.

• И третий тип трафика предполагает непрерывность идентификации. Когда пользователь переходит из диалога в интерфейс выполнения, он не теряет контекст, так как кнопка «Вернуться в диалог» с идентификатором сессии работает как надо. То есть это один виртуальный сотрудник, а не два разных агента.

Соответственно, мост — это не туннель, а контрольно-пропускной пункт. Там проверяются разрешения в списке контроля доступа и в матрице утверждений, после чего вносится запись в аудит. А при необходимости на мосту мы будем предотвращать утечки конфиденциальных данных (Data Leakage Prevention). 

Обращаю внимание ^[6] читателя на пару интересных нюансов:

• В ограничивающем домене нет копии личности агента. Это сознательное решение: копия — второй источник правды, который может рассинхронизироваться с первым. Так что вместо копирования предлагают так называемую привязку возможностей. То есть разрешающий домен знает, какие SOP может инициировать агент, но сама SOP (логика, версионирование, полномочия) остается в ограничивающем домене. Уместна аналогия со списком ссылок вместо набора готовых файлов.

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

При этом аудиторский реестр привязан к базовому слою. И когда вы меняете тон общения — реестр стабилен.

Вы можете сказать: «Ну автор просто вынес исполнение в отдельный сервис, это же обычный паттерн». Не совсем так, или даже совсем не так. Обычный паттерн работает по принципу master-slave, то есть агент просто вызывает функцию. А архитектура PES предлагает контрольный контракт, определяющий утверждение, аудит и идентичность. При этом в PES один виртуальный сотрудник может работать в разных доверительных доменах.

Результаты проверки PES

Автор работы проверил механизм на пяти конфигурациях модели (менял персону) и получил, что изменение личности не требует повторной валидации на стороне выполнения. То есть он поменял инструкции — и агент продолжал работать, аудит тоже не сломался. В жестко заданных полях не остается следов персоны. То есть ограничивающий домен не знает, какой тон общения вы выбрали, — только какую SOP выполнять.

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

Когда применять PES, а когда нет

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

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

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