В предыдущей статье мы разобрали, почему бизнес-ассистенту полезно работать не только с документами и большим стартовым промптом, но и с внешней моделью предметной области. Если договоры, сотрудники, продукты, обязательства и процессы уже представлены в пространстве как объекты и связи, ассистенту не приходится заново восстанавливать устройство компании при каждом запуске. Однако из этой идеи возникает вполне практический вопрос: что именно нужно сделать владельцу пространства, чтобы получить такого ассистента?
Ниже я пройду весь путь на одном примере — от выбора задачи до запуска роли в новой рабочей сессии. В качестве предметной области возьмём расчёты с персоналом, а в качестве прикладной роли — аналитика, который находит расхождения между начислениями, удержаниями и фактическими выплатами. Пример достаточно понятен без погружения в отраслевую специфику, но тот же порядок действий можно применить к исполнению заказов, контролю договоров, продуктовой аналитике, закупкам или сопровождению оборудования.
В конце этого пути в пространстве появятся формальная модель выбранной части бизнеса, базовое агентное население и зарегистрированная прикладная роль. Ассистента можно будет запускать в новых сессиях без повторного описания всей компании. Его назначение и ограничения будут браться из действующего описания роли, а факты о бизнесе — из модели пространства.
Начинаем не с образа ассистента, а с результата
Когда мы придумываем новую роль, легко начать с образа: «мне нужен умный финансовый аналитик» или «хочу помощника, который разбирается в зарплате». Для первого разговора с языковой моделью этого может быть достаточно, но для устойчивой роли такая постановка слишком широка. Непонятно, какой результат от неё ожидается, с какой частью бизнеса она работает и где заканчиваются её полномочия.
Поэтому начинать лучше с наблюдаемого результата. Например, ассистент должен находить расхождения между начислениями и выплатами, проверять полноту операций перед закрытием периода или объяснять причины отклонений от плана. Чем точнее определён результат, тем легче понять, какие объекты должны существовать в модели и какие полномочия действительно нужны роли.
Для этого достаточно ответить на четыре вопроса:
- Какой результат должен создавать ассистент?
- На какой части бизнеса он работает?
- Какие решения он может принимать самостоятельно?
- В каких случаях он должен остановиться и обратиться к человеку?
Постановка «изучай всё в пространстве и помогай по любым вопросам» перекладывает определение назначения на самого ассистента. В одной сессии он может сосредоточиться на расчётах, в другой — перейти к кадровым документам, а в третьей решить, что должен ещё и исправлять данные. Устойчивую роль лучше начинать с более конкретного результата:
Проверяй полноту начислений и выплат за выбранный период, находи расхождения и объясняй их через связанные данные о сотруднике, договоре, начислении, удержании и платеже.
Здесь уже видна будущая территория роли, но пока это только постановка задачи. Следующий шаг состоит в том, чтобы убедиться: предметная область действительно представлена в пространстве так, чтобы ассистент мог работать с ней как с моделью, а не как с набором текстовых упоминаний.
Описываем часть бизнеса, с которой будет работать роль
Ассистент не сможет опираться на модель, если бизнес существует в пространстве только в виде загруженных документов и свободных описаний. Документы могут подробно рассказывать о правилах расчёта заработной платы, но из них ещё не следует, что конкретное начисление связано с конкретным сотрудником, договором и расчётным периодом. Эти отношения языковой модели снова придётся восстанавливать самостоятельно.
Для нашего примера в модели должны появиться основные понятия предметной области: сотрудник, трудовой договор, расчётный период, начисление, удержание, выплата, подразделение и правило расчёта. Необязательно сразу моделировать всю систему управления персоналом. Достаточно описать ту часть бизнеса, которая нужна для выбранной задачи, и оставить возможность расширить её позднее.
Затем между объектами фиксируются значимые отношения. Сотрудник работает по трудовому договору и относится к подразделению, договор действует в определённый период, начисление относится к сотруднику и расчётному периоду, удержание уменьшает итоговую сумму, а выплата погашает начисление. Если для объяснения расчёта необходимо знать правило, начисление также связывается с соответствующим основанием или правилом расчёта.
Наконец, у объектов появляются свойства, которые нужны для анализа: сумма, дата, период, статус, основание, ответственный, источник и вид операции. В конкретной модели набор может отличаться, но общий принцип сохраняется. Ассистент должен получать значимый факт не только потому, что похожая формулировка встретилась в одном из документов, а потому, что определённый объект занимает известное положение в модели и связан с другими объектами явным образом.
При этом формализация не означает, что весь бизнес необходимо превратить в таблицу или граф без пояснений. Текстовые документы остаются полезными для описания правил, исключений, мотивации и истории решений. Меняется только распределение ответственности: документы помогают понимать смысл, а модель фиксирует объекты, их свойства и действующие отношения.
Проверяем, достаточно ли модели для будущих выводов
Создать роль можно и поверх неполной модели, но тогда ассистент быстро столкнётся с теми же проблемами, от которых мы хотели уйти. Он начнёт угадывать отсутствующие связи, принимать старые данные за действующие или восполнять пробелы по смыслу соседних документов. Хорошее описание роли не способно компенсировать отсутствие структуры в самой предметной области.
Перед учреждением ассистента полезно пройти несколько контрольных вопросов:
- Можно ли однозначно найти объекты, с которыми должна работать роль?
- Определены ли связи, необходимые для её выводов?
- Можно ли отличить действующие данные от исторических?
- Есть ли в модели статусы и расчётные периоды?
- Понятно ли, кому принадлежат данные и кто отвечает за результат?
- Может ли ассистент объяснить вывод через конкретные связанные объекты?
- Не осталось ли критически важное понятие только внутри текстового документа?
Для аналитика расчётов особенно важно различать отсутствие выплаты и отсутствие данных о выплате. Если в модели есть начисление, но нет связи с платежом, это ещё не всегда означает, что деньги не были перечислены. Возможно, платёж пока не импортирован или не сопоставлен с начислением. Модель должна позволять ассистенту не только обнаружить расхождение, но и честно указать, каких фактов не хватает для окончательного вывода.
Если один из ключевых вопросов остаётся без ответа, лучше сначала дополнить модель. Это может потребовать добавить тип объекта, статус, период или несколько отношений. Такая работа не является подготовкой «специальных данных для ИИ»: те же уточнения обычно повышают понятность модели и для людей, потому что делают явными ранее подразумеваемые правила.
Учреждаем базовое агентное население
Когда предметная область готова, владелец пространства однократно выполняет действие «Учредить базовое население». После этого в пространстве появляются минимальная конституция и две базовые роли — хранитель конституции и методолог агентных ролей. Они создают нейтральную основу, в которой затем можно последовательно учреждать прикладных ассистентов.
Базовое население не является готовой командой для управления зарплатой, договорами или закупками. Хранитель не проверяет начисления, а методолог не анализирует выплаты. Их задача состоит в другом: помочь владельцу сформулировать новую роль, проверить её совместимость с устройством пространства и зарегистрировать как действующего жителя.
Учреждение выполняется владельцем пространства один раз и является необратимым действием. Повторно создавать базовое население перед каждой новой ролью или рабочей сессией не требуется. При этом существующие пространства со старой формой агентного населения не преобразуются автоматически: переход к новой конструкции остаётся осознанным действием владельца.
Превращаем задачу в устойчивую роль
Теперь можно подготовить описание аналитика расчётов с персоналом. Здесь важно не переносить в роль всю корпоративную документацию и не пытаться заранее перечислить каждую возможную ситуацию. Роль описывает устойчивое назначение, территорию, ожидаемый результат и границы полномочий, а конкретная задача будет поставлена уже при запуске.
Название должно обозначать функцию, которую имеет смысл использовать многократно. «Аналитик расчётов с персоналом» подходит лучше, чем «проверить майский отчёт», потому что расчётный период меняется, а назначение роли сохраняется. По той же причине названия «помощник», «умный агент» или «агент для всего» почти ничего не говорят о месте роли в пространстве.
Назначение можно сформулировать так:
Выявлять и объяснять расхождения между начислениями, удержаниями и фактическими выплатами.
Территория описывает ту часть модели, в пределах которой действует роль:
Сотрудники, трудовые договоры, расчётные периоды, начисления, удержания и выплаты, а также связи между ними.
Территорию лучше связывать с понятиями модели, а не с названиями экранов, файлов или отчётов. Экран может измениться, файл — получить новое название, а отчёт — быть перенесён в другую систему. Роль при этом продолжит работать с теми же бизнес-объектами.
Полезный результат также стоит определить заранее. В нашем случае им будет перечень обнаруженных расхождений, объяснение каждого из них, ссылки на связанные объекты, список отсутствующих данных и вопросы, требующие решения человека. Это помогает отличить завершённую работу от общего рассуждения на тему расчётов.
Наконец, роль получает явные ограничения. Аналитик не должен изменять суммы начислений, подтверждать выплату, создавать отсутствующие факты по догадке, считать документ действующим без связи с текущим договором или самостоятельно выходить за пределы выбранного расчётного периода. Эти ограничения не мешают рассуждению, а отделяют анализ от действий, способных изменить состояние бизнеса.
В собранном виде описание роли может выглядеть так:
Название: Аналитик расчётов с персоналом.
Назначение: выявлять и объяснять расхождения между начислениями, удержаниями и фактическими выплатами.
Территория: сотрудники, трудовые договоры, расчётные периоды, начисления, удержания, выплаты и связи между ними.
Результат: перечень расхождений с объяснениями и ссылками на связанные объекты, список недостающих данных и вопросы, требующие решения человека.
Ограничения: не изменять финансовые данные, не подтверждать выплаты, не восполнять отсутствующие факты догадками и не выходить за пределы заданного периода.
При необходимости подключаем методолога
Иногда владелец хорошо понимает бизнес-задачу, но затрудняется отделить устойчивую роль от конкретного поручения. В этом случае можно обратиться к методологу агентных ролей. Он помогает уточнить формулировки, обнаружить слишком широкую территорию или предложить разделить одну перегруженную роль на несколько более понятных.
Задание методологу может быть сформулировано обычным языком:
Помоги подготовить роль аналитика расчётов с персоналом. Она должна находить расхождения между начислениями, удержаниями и выплатами, объяснять их через модель пространства и не изменять финансовые данные. Сформулируй назначение, территорию, ожидаемый результат и границы полномочий.
Методолог не утверждает роль и не решает, соответствует ли она конституции. Его задача — сделать описание ясным, полным и пригодным для повторного использования. Если владелец уже подготовил такое описание самостоятельно, участие методолога можно пропустить и сразу перейти к проверке хранителем.
Это разделение важно для управляемости. Помощь в проектировании роли и решение о её допустимости — разные функции, даже если в простом случае одна рабочая сессия последовательно выполняет обе части процесса. Владельцу не требуется вручную запускать нескольких ассистентов и переносить между ними сообщения.
Передаём роль хранителю и проверяем регистрацию
Подготовленное описание передаётся хранителю конституции с прямой инструкцией:
Проверь эту роль на соответствие действующей конституции пространства. Если она не противоречит конституции и не требует дополнительного согласования, зарегистрируй её как новую активную роль.
Хранитель проверяет, не присваивает ли новый аналитик чужие полномочия, не противоречат ли его действия конституции и не пытается ли он под видом добавления изменить существующую роль. Кроме того, должны быть достаточно ясно определены назначение и территория. Если действующая конституция предусматривает дополнительное согласование, хранитель должен запустить именно эту процедуру, а не обойти её.
В базовом пространстве, где отдельное согласование не требуется, проверка и регистрация могут завершиться в одном взаимодействии. После этого недостаточно просто получить сообщение ассистента о том, что роль создана. Необходимо открыть агентное население и убедиться, что аналитик действительно присутствует в нём, находится в действующем состоянии и пригоден для запуска.
Повторная передача того же описания не должна создавать второго аналитика. Существующие роли при добавлении нового жителя также не должны измениться. Если роль не появилась в специальном представлении агентного населения, процесс нельзя считать завершённым, даже если диалог закончился уверенным подтверждением.
Здесь проявляется отличие зарегистрированной роли от удачного промпта. Промпт действует, пока продолжается разговор, а роль становится частью пространства и остаётся доступной после завершения сессии. Её внутреннее описание при этом не обязано попадать в обычные бизнес-поиски и диаграммы: служебное устройство населения отделено от предметной модели.
Запускаем роль в новой сессии
После регистрации не нужно снова вставлять полное описание аналитика, перечислять все его ограничения и пересказывать устройство бизнеса. Стартовая команда должна только указать, какую из уже существующих ролей следует применить в текущей сессии:
Прочти действующую конституцию и агентное население этого пространства. Найди роль «Аналитик расчётов с персоналом», изучи её действующее описание и работай в соответствии с ним. Факты о бизнесе получай из модели пространства. Не восполняй отсутствующие факты догадками.
Эта команда не создаёт роль заново и не изменяет её. Она выбирает действующего жителя пространства и предлагает текущему ассистенту принять соответствующие обязанности. В результате рабочая сессия начинается в контексте конкретного пространства, действующей конституции, признанной роли, её территории и ограничений.
Для каждой роли не требуется создавать отдельную учётную запись. Ассистент действует с правами пользователя, который запустил сессию, поэтому регистрация роли сама по себе не расширяет доступ к данным. Если пользователь не имеет права видеть определённые объекты или выполнять изменения, выбранная роль не должна становиться способом обойти это ограничение.
Здесь особенно хорошо видно разделение трёх уровней. Модель пространства отвечает на вопрос, что известно о бизнесе. Описание роли определяет, зачем и в каких границах действует ассистент. Стартовая команда только выбирает, какую роль применить в текущей работе.
Ставим прикладную задачу через модель
После выбора роли можно переходить к текущему поручению. Например:
Проверь расчётный период за июль. Найди сотрудников, у которых сумма выплат не соответствует итоговым начислениям с учётом удержаний. Для каждого расхождения укажи связанные начисления, удержания, выплаты и договор. Если данных недостаточно, перечисли, каких именно фактов не хватает.
Пользователь в этом запросе задаёт период и текущую цель, но не повторяет устройство предметной области. Ассистент уже знает из роли, как должен действовать и чего делать не вправе. Состав фактов определяется моделью: конкретными сотрудниками, договорами, начислениями, удержаниями, выплатами и отношениями между ними.
Предположим, у сотрудника есть начисление на 120 тысяч рублей, удержание на 20 тысяч и выплата на 90 тысяч. Аналитик может обнаружить расхождение в 10 тысяч, но его объяснение должно строиться не только на арифметике. Он проверяет, относится ли выплата к тому же периоду, связан ли сотрудник с действующим договором, существуют ли другие выплаты и не осталось ли несопоставленное удержание.
Если необходимая связь отсутствует, аналитик не должен придумывать её на основании похожей суммы или соседнего документа. Его правильным результатом станет указание на недостаточность данных: например, выплата найдена, но не связана с конкретным начислением или расчётным периодом. Такой ответ может казаться менее эффектным, чем уверенное предположение, зато он показывает реальное состояние модели и помогает её улучшить.
Проверяем, что ассистент действительно работает с моделью
Хороший связный ответ ещё не доказывает, что ассистент использовал объекты и связи пространства. Языковая модель способна правдоподобно рассуждать и по обычному тексту, поэтому механизм полезно проверить несколькими простыми экспериментами. Они показывают не красоту формулировок, а устойчивость поведения роли.
Сначала можно попросить аналитика объяснить вывод и перечислить объекты и связи, на которых он основан. В хорошем ответе появятся конкретный сотрудник, договор, расчётный период, начисления, удержания и выплаты. Если вместо этого ассистент только пересказывает общий регламент, вероятно, модель пока не стала настоящей опорой его рассуждения.
Затем стоит намеренно не создавать одну из необходимых связей. Например, выплата существует, но не сопоставлена с начислением. Аналитик должен сообщить, что имеющихся фактов недостаточно, а не восстанавливать отношение по совпадению суммы, даты или фамилии.
Третья проверка касается полномочий. Если попросить аналитика исправить сумму начисления, он должен отказаться или предложить передать действие другой роли, потому что его назначение ограничено наблюдением и объяснением. Уверенный анализ не должен незаметно превращаться в право менять финансовые данные.
Наконец, ту же роль нужно запустить в новой сессии и повторить проверку на другом периоде. Назначение, территория и ограничения должны сохраниться без повторной передачи полного описания. Можно также задать вопрос из соседней предметной области: аналитик расчётов должен обозначить выход за свои границы, а не превращаться по ходу разговора в универсального кадрового или юридического помощника.
Как развивать население дальше
После успешного запуска первой роли может возникнуть желание сразу создать целую команду. На практике новые роли лучше добавлять последовательно, проверяя пользу и границы каждой из них. Это позволяет заметить, где заканчивается ответственность одного участника и начинается работа другого.
Развитие можно начать с аналитика, который наблюдает и объясняет происходящее. Затем добавить контролёра, проверяющего соблюдение установленных правил, и планировщика, предлагающего варианты действий. Только после этого имеет смысл учреждать исполнителя, способного выполнять разрешённые изменения, потому что такая роль требует более строгих ограничений и контроля.
Отдельным жителем может стать куратор модели, который следит за качеством понятий, связей и данных. Если аналитик регулярно сообщает об отсутствующих периодах, несопоставленных выплатах или неоднозначных договорах, это уже не только результат финансовой проверки, но и материал для развития самой модели. Так прикладная работа ассистентов постепенно показывает, какие части пространства требуют уточнения.
Несколько ролей могут использовать одни и те же объекты бизнеса, не становясь копиями друг друга. Аналитик объясняет расхождение, контролёр определяет нарушение правила, планировщик предлагает способ устранения, а исполнитель в пределах своих полномочий вносит изменение. Общая модель сохраняет согласованность фактов, а различие ролей — разделение ответственности.
Что этот рецепт не решает автоматически
Качество ассистента напрямую зависит от качества модели пространства. Регистрация роли не создаёт отсутствующие договоры, начисления или связи и не делает устаревшие данные актуальными. Если предметная область описана неполно, ассистент должен обнаруживать эти пробелы, но не может безопасно устранить их одной интерпретацией.
Роль также не получает собственных прав доступа и не становится отдельной цифровой личностью. Она действует с правами текущего пользователя, а её регистрация фиксирует назначение и место в населении, но не создаёт новую учётную запись. Для изменения, приостановки или удаления уже принятой роли потребуются отдельные управленческие процедуры: повторное добавление не должно использоваться как скрытый способ переписать существующего жителя.
Сложные согласования, голосования и дополнительные проверки появляются только в тех пространствах, где они действительно предусмотрены конституцией. Нет необходимости заранее усложнять базовую конструкцию механизмами, которые бизнес пока не использует. Конституция должна поддерживать реальное устройство работы, а не изображать формальность ради самой формальности.
Свободный текст при этом никуда не исчезает. Он остаётся лучшим способом объяснять назначение, принципы, исключения и человеческий смысл работы. Важно лишь, чтобы факты, на которых строятся прикладные выводы, извлекались из модели, а не возникали заново из интерпретации одного и того же рассказа.
Что получилось в результате
Мы начали не с попытки придумать «умного помощника», а с конкретного бизнес-результата — поиска расхождений между начислениями и выплатами. Затем определили часть предметной области, необходимую для такого анализа, проверили качество модели и учредили в пространстве базовое агентное население. После этого задача превратилась в устойчивую роль с понятным назначением, территорией, результатом и ограничениями.
Владелец при необходимости уточнил описание с методологом, передал его хранителю и проверил, что новая роль действительно появилась в населении. Теперь в новой сессии не нужно снова рассказывать ассистенту, как устроены расчёты с персоналом и кем он должен себя считать. Достаточно выбрать зарегистрированную роль, указать период и поставить текущую задачу.
Модель пространства отвечает на вопрос, что известно о бизнесе. Роль определяет, зачем и в каких границах действует ассистент. Стартовая команда лишь связывает текущую рабочую сессию с уже учреждённой ролью.
Так бизнес-ассистент перестаёт быть удачной формулировкой, которую нужно бережно переносить из одного чата в другой. Он становится повторно запускаемым участником пространства, работает с конкретными объектами бизнеса и сохраняет свои границы между сессиями. А когда модель меняется или дополняется, обновлённая картина становится доступна не только ему, но и другим людям и ролям, работающим вокруг того же бизнеса.