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

Альтернативный архитектурный подход — Federated RAG, при котором данные не собираются в единый централизованный индекс. Они остаются в автономных корпоративных системах или связанных с ними локальных хранилищах, а запрос в момент выполнения направляется в один или несколько подходящих источников. Каждый источник самостоятельно выполняет поиск с учётом собственных правил доступа, после чего полученные результаты объединяются и передаются языковой модели. Например, запрос может проходить через интеграционный хаб — Tools Hub. Платформа получает краткоживущий токен через Token Exchange, а внешняя корпоративная система сама проверяет, имеет ли пользователь доступ к запрошенной информации. В платформу возвращается только результат конкретного запроса. Сами данные не копируются и не сохраняются в ней как постоянная общая база. Federated RAG позволяет: — учитывать актуальные права пользователя непосредственно в момент запроса; — не создавать ещё одну полную копию чувствительной корпоративной информации; — подключать несколько систем с разными моделями авторизации, не пытаясь полностью перенести их правила внутрь RAG-платформы.

Но Federated RAG создаёт и новые архитектурные сложности: — скорость ответа начинает зависеть от внешних систем. — недоступность одной корпоративной системы может сделать часть ответа неполной. — каждую систему необходимо интегрировать отдельно. — результаты из разных источников нужно объединить и ранжировать.

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

Применяете ли вы Federated RAG в контуре своей организации? И как решаете вопрос актуальности прав доступа в корпоративном поиске?

#FederatedRAG #RAG #AIAgents #EnterpriseAI #AIArchitecture