[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-permission-aware-retrieval::ru":3,"gloss-cluster-permission-aware-retrieval::ru":26,"gloss-next-permission-aware-retrieval::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"permission-aware-retrieval","data-infra","Поиск с учётом прав доступа","Поиск с учётом прав доступа — это построение поисковой системы так, чтобы она возвращала только тот материал, который вправе видеть задающий вопрос, и чтобы это проверялось в момент запроса, а не подразумевалось из того, как собирался индекс. Разница здесь между поисковым слоем, отражающим модель доступа организации, и слоем, который её тихо обходит.\n\nПроблема возникает почти случайно. Индекс обычно строит сервисный аккаунт с широкими правами на чтение — это самый простой способ обойти все источники. После векторизации исходные права исчезают: вектор — это не документ с владельцем, а числовой адрес в пространстве, где из всех связей уцелела только близость. Задаёте вопрос — система возвращает ближайшее, а у близости нет мнения о том, имел ли спрашивающий право это читать.\n\nОсобенно скверно то, что снаружи такой сбой не виден. Ничего не падает. Система бегло отвечает, ссылается на источник, который пользователь не может открыть, и утечку обнаруживают, когда кто-то читает ответ с информацией, явно не предназначенной ему. Зарплатные условия, необъявленные реорганизации и юридические споры — классические примеры именно потому, что это документы из систем, где права настроены строго, а обходчики — нет.\n\nМеханизм прост, даже если обвязка сложна. Метаданные доступа переезжают вместе с каждым фрагментом в индекс — группы, роли, тенанты или идентификаторы документов, управляющие оригиналом, — а запрос несёт личность спрашивающего, чтобы фильтрация происходила до ранжирования. Фильтровать после ранжирования — распространённое упрощение, и оно неверно дважды: утечка идёт через количество найденного, и результат молча усыхает, так что пользователь с узкими правами получает не лучшие доступные ему фрагменты, а меньше и хуже.\n\nСложное здесь — поддерживать метки в актуальном состоянии. Права меняются постоянно, а индекс — это копия, поэтому отозванный доступ, смена роли или увольнение должны доезжать до индекса, а не только до источника. Большинство решений перепроверяет права в исходной системе в момент ответа, но только для тех немногих документов, которые реально используются, — это по карману ровно потому, что речь о единицах, а не о всём корпусе.\n\nМультиарендные продукты сталкиваются с той же проблемой в более жёсткой форме: ошибка фильтра там пересекает границу клиента, а не внутреннюю. Раздельные индексы или жёсткое разделение по тенантам стоят дополнительной эксплуатационной тяжести, потому что один пропущенный фильтр в общем индексе — это раскрытие данных между клиентами, а запрос, который его вскроет, может быть совершенно невинным.","Поиск с учётом прав фильтрует индекс по тому, что вправе видеть спрашивающий, чтобы поисковый слой не стал обходным путём вокруг прав исходной системы.",null,[11,14,17,20,23],{"slug":12,"name":13},"metadata-filtering","Фильтрация по метаданным (Metadata Filtering)",{"slug":15,"name":16},"retrieval-augmented-generation","Генерация с дополненным поиском (RAG)",{"slug":18,"name":19},"role-based-access-control","Управление доступом на основе ролей (RBAC)",{"slug":21,"name":22},"tenant-isolation","Изоляция арендаторов (Tenant Isolation)",{"slug":24,"name":25},"vector-store","Векторное хранилище (Vector Store)",[27,31,34,37,40,44,47,50,53,56,60,63],{"slug":28,"category":5,"name":29,"updated_at":30},"acid","ACID","2026-08-24T02:46:37+00:00",{"slug":32,"category":5,"name":33,"updated_at":30},"ann-search","ANN-поиск (приближённый поиск ближайших соседей)",{"slug":35,"category":5,"name":36,"updated_at":30},"backpressure","Обратное давление (backpressure)",{"slug":38,"category":5,"name":39,"updated_at":30},"batch-processing","Пакетная обработка (Batch Processing)",{"slug":41,"category":5,"name":42,"updated_at":43},"bm25","BM25","2026-08-24T02:46:38+00:00",{"slug":45,"category":5,"name":46,"updated_at":30},"cache","Кэш (Cache)",{"slug":48,"category":5,"name":49,"updated_at":30},"cap-theorem","Теорема CAP (CAP theorem)",{"slug":51,"category":5,"name":52,"updated_at":30},"change-data-capture","Захват изменений данных (CDC)",{"slug":54,"category":5,"name":55,"updated_at":30},"chroma","Chroma",{"slug":57,"category":5,"name":58,"updated_at":59},"chunk-overlap","Перекрытие фрагментов","2026-08-24T03:30:02+00:00",{"slug":61,"category":5,"name":62,"updated_at":30},"columnar-storage","Колоночное хранение",{"slug":64,"category":5,"name":65,"updated_at":30},"connection-pooling","Пулинг соединений (Connection Pooling)"]