Спасибо, вот разделение Graph / Identity → policy decision → orchestration как PEP как раз проясняет границу. И тогда у меня возникает следующий вопрос — уже не столько про доступность контекста, сколько про его временную валидность. Допустим, в графе есть связь: человек состоит в проекте, документ относится к проекту, агент имеет право подтянуть этот контекст. Через неделю человек вышел из проекта или документ получил новый статус. Сам факт и старая связь в истории никуда не исчезли, но они больше не должны давать право на использование контекста. То есть помимо ABAC получается нужен ещё слой, который понимает не только кто → к чему связан, но и какая версия связи сейчас является действующей, кем она подтверждена и когда должна перестать влиять на policy decision. Вы бы такую temporal validity тоже закладывали прямо в graph/identity layer — например, через события/версии/valid-from–valid-to — или держали бы её отдельным policy-state рядом с графом? CIDOC-CRM здесь как раз интересно выглядит из-за event-centric модели, но мне пока неочевидно, где лучше провести границу между «историей того, что произошло» и «текущим фактом, который имеет право управлять доступом».
Очень знакомая проблема с многошаговым взаимодействием. В своих AI-workflow я тоже довольно быстро упиралась в то, что обычный чат перестаёт быть удобной моделью интерфейса, как только появляется state, human-in-the-loop и необходимость продолжать процесс после вмешательства пользователя, а не запускать его заново. Мне кажется, что здесь UI уже действительно становится частью orchestration layer, а не просто оболочкой над моделью. Интересен момент с одним endpoint и невозможностью нормально различать start new run и resume from interrupted state. Вы это в итоге решали на уровне собственной state-machine поверх Open WebUI или именно это и стало одной из причин перехода к другому UI-слою? И ещё интересно, где у вас хранится source of truth по состоянию такого процесса: внутри LangGraph state/checkpointing или отдельно во внешнем storage, чтобы UI мог безопасно восстанавливать текущий этап после паузы?
Очень откликнулся тезис о том, что ценность постепенно смещается от доступа к отдельным данным к связанному контексту. В прикладных AI-системах я вижу похожую проблему на меньшем масштабе: просто дать агенту доступ ко всем письмам, файлам, CRM и календарю недостаточно. Дальше всё равно приходится проектировать, какой контекст нужен для конкретного шага, что считать текущим state, какие связи можно подтягивать автоматически, а где нужны ограничения по ролям и human approval. Мне кажется, следующий важный слой после самого semantic graph — это policy над этим графом: кто, когда и для какой задачи может получить какой кусок контекста. Иначе мы решаем проблему доступности данных, но получаем новую — слишком широкий и плохо управляемый контекст для агента. Как вы видите этот слой: он должен жить внутри самого graph/identity layer или уже на уровне agent orchestration?
Информация
В рейтинге
4 750-й
Зарегистрирован
Активность
Специализация
Архитектор программного обеспечения, Системный аналитик
Спасибо, вот разделение
Graph / Identity → policy decision → orchestration как PEPкак раз проясняет границу.И тогда у меня возникает следующий вопрос — уже не столько про доступность контекста, сколько про его временную валидность. Допустим, в графе есть связь: человек состоит в проекте, документ относится к проекту, агент имеет право подтянуть этот контекст. Через неделю человек вышел из проекта или документ получил новый статус. Сам факт и старая связь в истории никуда не исчезли, но они больше не должны давать право на использование контекста. То есть помимо ABAC получается нужен ещё слой, который понимает не только
кто → к чему связан, но и какая версия связи сейчас является действующей, кем она подтверждена и когда должна перестать влиять на policy decision.Вы бы такую temporal validity тоже закладывали прямо в graph/identity layer — например, через события/версии/valid-from–valid-to — или держали бы её отдельным policy-state рядом с графом?
CIDOC-CRM здесь как раз интересно выглядит из-за event-centric модели, но мне пока неочевидно, где лучше провести границу между «историей того, что произошло» и «текущим фактом, который имеет право управлять доступом».
Очень знакомая проблема с многошаговым взаимодействием. В своих AI-workflow я тоже довольно быстро упиралась в то, что обычный чат перестаёт быть удобной моделью интерфейса, как только появляется state, human-in-the-loop и необходимость продолжать процесс после вмешательства пользователя, а не запускать его заново. Мне кажется, что здесь UI уже действительно становится частью orchestration layer, а не просто оболочкой над моделью.
Интересен момент с одним endpoint и невозможностью нормально различать
start new runиresume from interrupted state. Вы это в итоге решали на уровне собственной state-machine поверх Open WebUI или именно это и стало одной из причин перехода к другому UI-слою? И ещё интересно, где у вас хранится source of truth по состоянию такого процесса: внутри LangGraph state/checkpointing или отдельно во внешнем storage, чтобы UI мог безопасно восстанавливать текущий этап после паузы?Очень откликнулся тезис о том, что ценность постепенно смещается от доступа к отдельным данным к связанному контексту. В прикладных AI-системах я вижу похожую проблему на меньшем масштабе: просто дать агенту доступ ко всем письмам, файлам, CRM и календарю недостаточно. Дальше всё равно приходится проектировать, какой контекст нужен для конкретного шага, что считать текущим state, какие связи можно подтягивать автоматически, а где нужны ограничения по ролям и human approval. Мне кажется, следующий важный слой после самого semantic graph — это policy над этим графом: кто, когда и для какой задачи может получить какой кусок контекста. Иначе мы решаем проблему доступности данных, но получаем новую — слишком широкий и плохо управляемый контекст для агента.
Как вы видите этот слой: он должен жить внутри самого graph/identity layer или уже на уровне agent orchestration?