Не из промпта, а из пространства: на что опереть бизнес-ассистента

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

Долгое время мы воспринимали это как естественное свойство работы с языковой моделью. Казалось, что достаточно хорошо описать компанию, собрать нужные документы в одну папку и подготовить подробную инструкцию для ассистента. Чем больше в его распоряжении будет материалов, тем точнее он сможет понять происходящее. На практике вместе с объёмом контекста росла и другая проблема: модели предстояло самостоятельно отличить факт от пояснения, действующее решение от истории его обсуждения, а устойчивую структуру бизнеса — от случайной формулировки в одном из файлов.

Особенно заметно это становится, когда ассистент должен не просто отвечать на общие вопросы, а работать с конкретными объектами. Ему нужно понимать, что определённый договор относится к конкретному проекту, проект принадлежит определённому продукту, за обязательство отвечает конкретное подразделение, а изменение одного объекта затрагивает несколько других. В документах все эти сведения могут присутствовать, но каждый раз модели приходится заново выделять сущности, сопоставлять их названия и восстанавливать отношения между ними. Фактически перед началом работы ассистент снова компилирует бизнес из текста.

Мы решили попробовать другую конструкцию. Не передавать ассистенту очередное описание мира, а поместить его в пространство, где этот мир уже смоделирован.

Речь не идёт об отказе от Markdown-файлов, документов или текстовых инструкций. Текст хорошо передаёт мотивацию, нюансы, принципы и замысел роли. С его помощью можно объяснить, зачем нужен финансовый контролёр, какие риски он должен замечать и в каких ситуациях обязан обратиться к человеку. Проблема возникает только тогда, когда этот же текст становится единственным основанием для существования всех объектов бизнеса и отношений между ними.

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

Это разделение кажется небольшим, но оно меняет саму опору работы. Ассистент больше не получает инструкцию «представь, что ты аналитик компании, в которой есть такие-то подразделения, проекты и продукты». Он становится аналитиком конкретного пространства, где подразделения, проекты и продукты уже существуют как самостоятельные объекты, а их отношения не исчезают после завершения разговора. При следующем запуске не нужно заново угадывать, является ли «Проект Альфа» тем же объектом, который в другом документе назван просто «Альфой».

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

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

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

Методолог при этом не становится обязательным посредником между владельцем и пространством. Если назначение новой роли уже сформулировано достаточно ясно, описание можно сразу передать хранителю. Если идея пока существует в форме «мне нужен кто-то, кто будет следить за договорами», методолог помогает превратить её в определённую роль: уточнить территорию, режим работы, ограничения и отношения с другими участниками. После этого хранитель сопоставляет предложенную конструкцию с действующей конституцией и при необходимости проводит предусмотренное ею дополнительное согласование.

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

Здесь проходит важная управленческая граница. Добавление роли не должно незаметно изменять или заменять уже существующих участников, поэтому один запрос создаёт одного нового жителя и сохраняет прежнюю картину населения. Повторение той же операции не порождает дубль, а изменение, приостановка или удаление принятой роли не маскируется под её повторное добавление. Для таких действий нужны отдельные процедуры, потому что они меняют уже принятое устройство пространства.

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

Сам по себе ветеринарный ассистент, конечно, не является технологическим чудом. Языковая модель и без Онто способна составить общий план осмотра животного или перечислить вопросы, которые стоит задать владельцу. Для нас было важно другое: после запуска ветеринар оказался не в пустом чате и не перед папкой с условным файлом наши-коты.md. Он вошёл в пространство, где уже существовали конкретные животные, их владельцы и отношения между ними.

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

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

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

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

Мы также сознательно не стали превращать каждого ассистента в отдельную учётную запись, требовать цифровых доказательств каждой проверки или встраивать голосование в любое изменение населения. Базовая конституция не содержит конкретного бизнес-процесса и не заставляет владельца всегда запускать несколько субагентов. Нам было важно сначала получить простую управляемую конструкцию, в которой роль можно учредить, проверить и связать с пространством. Более сложные механизмы согласования могут добавляться там, где они действительно нужны.

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

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

Это особенно важно, когда в одном пространстве появляется несколько ассистентов. Если каждому из них передать собственную подборку документов, со временем возникнет несколько немного разных версий одной компании. Финансовый ассистент будет по-своему понимать проекты, операционный — по-своему трактовать обязательства, а продуктовый — использовать ещё один набор названий и связей. Общая модель не устраняет различия профессиональных взглядов, но даёт им единую поверхность, на которой эти различия можно обнаружить и согласовать.

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

Поэтому главный результат эксперимента состоит не в том, что мы научили языковую модель играть ещё одну роль. Мы получили возможность один раз учредить ассистента, определить его границы и поместить в пространство, где предметная область уже существует независимо от разговора. Текст продолжает объяснять роль и передавать смысл, но больше не обязан при каждом запуске заново создавать весь окружающий мир. Ассистент начинает работу не с легенды о компании, а с её действующей модели.

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