Какой механизм рекомендаций для ситуации, когда пользователи могут видеть только часть всех элементов?

Я хочу добавить функцию рекомендации в систему управления документами . Это сервер, на котором хранится большинство документов компании. Сотрудники просматривают веб-интерфейс и нажимают, чтобы загрузить (или прочитать в Интернете) нужные документы.
Каждый сотрудник имеет доступ только к подмножеству всех документов:

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

Существует множество механизмов рекомендаций для общедоступных данных (все пользователи Netflix могут видеть все фильмы), но здесь особая ситуация: каждый сотрудник имеет разрешение только на часть всех документов, тогда как в Netflix любой пользователь имеет доступ ко всем фильмам.

Пример : Employee1 может читать DocumentA, но не DocumentB. Employee2 может читать оба, а Employee3 не может читать ни одного.

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

Есть ли название для такой проблемы?
Можно ли его уменьшить без потери точности / эффективности до более распространенной проблемы?
Если нет, то какой подход будет хорошо работать для такого рода проблем?

Примечание: механизм рекомендаций, похожий на Netflix, недостаточно хорош. Документ с 50 представлениями должен быть заметным, если только 10 сотрудников (включая меня) имеют к нему доступ, но не должен быть заметным, если к нему имеют доступ 100000 сотрудников.

В случае необходимости, вот несколько особенностей данных: средняя компания имеет 1000 сотрудников, около 10000 документов, сотрудник щелкает около 5 документов в день. Каждый проект имеет в среднем 10 сотрудников, имеющих доступ к нему, и имеет около 100 документов. Каждый сотрудник работает в среднем 5 проектов параллельно.

machine-learning recommender-system

— Николас Рауль
источник

Ответы:

Я чувствую, что вам нужно рассмотреть две вещи отдельно.

Во-первых, вам нужно иметь контроль доступа для пользователей вашей системы. Вы можете иметь токены доступа, прикрепленные к каждому пользователю и файлу. Фильтруйте базу данных файлов перед обработкой.

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

Например, я могу представить вес документа и вес пользователя следующим образом, но они могут быть намного более сложными в соответствии с вашей системой.

DocumentWeight = Number of Views/ Number of Users can Access
UserWeight = ## Relative to browsing user- Users in similar project will have higher weights

DocumentScore = Sum over all viewed users{DocumentWeight x UserWeight}

Вы можете ранжировать документы, это статистически подтянет нужные вам документы. Я надеюсь, что это поможет.

— EngineeredBrain
источник

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

Фильтрация скрытых результатов должна выполняться индивидуально для каждого пользователя (вы найдете все возможные предложения, но выводите только те, которые пользователь может просматривать).

— chewpakabra
источник

Я не думаю, что такого общего метода было бы достаточно: документ с 50 представлениями должен быть заметным, если только 10 сотрудников (включая меня) имеют к нему доступ, но не должен быть выдающимся, если к нему имеют доступ 100 000 сотрудников.

— Николас Рауль

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

— chewpakabra

Я достаточно четко описал свои данные в своем вопросе? Если нет, пожалуйста, не стесняйтесь спрашивать любую информацию, которая необходима, прежде чем конкретный подход может быть рекомендован. Большое спасибо :-)

— Николас Рауль

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

— chewpakabra

Откуда взялась цифра 10000? Если вы имели в виду 100000, то мне было недостаточно ясно: «иметь доступ к нему» не означает «просматривать его», это означает «иметь разрешение на доступ к нему, если они хотят». Другими словами, первый документ просматривался в среднем 10 раз каждым человеком, у которого есть разрешение на его просмотр, но второй документ просматривался только в среднем 0,0005 раз каждым человеком, у которого есть разрешение на его просмотр.

— Николас Рауль

Взгляните на Mining of Massive Data Sets стр. 328, который в конечном итоге приведет вас к SVD, который обычно используется в рекомендательных системах.

— беличье гнездо
источник

На странице, которую вы упоминаете, представлены различные общие сведения об уменьшении размерности. Не могли бы вы подвести итог, что относится к вопросу выше? Большое спасибо!

— Николас Рауль

да; это показывает, как использовать SVD для рекомендации

— Дрей