User matching with current data

Question

J'ai une base de données complète de deux types d'utilisateurs différents (mentors et mentorés), par laquelle je veux que le deuxième groupe (mentorés) soit capable de "chercher" des personnes dans le premier groupe (mentors) qui correspondent à leur profil. Les mentors et les mentorés peuvent entrer et modifier des éléments de leur profil à tout moment.

Actuellement, j'utilise Apache Mahout pour l'utilisateur correspondant (recommender.mostSimilarIDs()). Le problème que je rencontre est que je dois recharger les données de l'utilisateur chaque fois que quelqu'un cherche. En soi, cela ne prend pas beaucoup de temps, mais lorsque Mahout traite les données, cela semble prendre beaucoup de temps (14 minutes pour 3000 mentors et 3000 mentorés). Après le traitement, l'appariement prend quelques secondes. Je reçois également le même message INFO encore et encore pendant le traitement ("2248 utilisateurs traités"), tandis que le fait de regarder le code montre que le message ne devrait être émis que tous les 10000 utilisateurs. J'utilise GenericUserBasedRecommender et GenericDataModel, ainsi que NearestNUserNeighborhood, AveragingPreferenceInferrer et PearsonCorrelationSimilarity. Je charge les mentors de la base de données, ajoute le mentoré à la liste des POJOs et les convertis en FastByIDMap pour donner au DataModel.

Y a-t-il une meilleure façon de faire cela? Le propriétaire du produit a besoin que les données soient à jour pour chaque recherche.

Answer 1

(je suis l'auteur.)

Vous ne devriez pas besoin de lui demander de recharger les données à chaque fois, pourquoi est-ce?

14 minutes sonne beaucoup, beaucoup trop long pour charger une si petite quantité de données aussi, quelque chose ne va pas. Vous pouvez suivre avec plus d'informations à user@mahout.apache.org.

Vous voyez des messages de journal provenant d'un DataModel, que vous pouvez désactiver dans votre système de journalisation de votre choix. Il imprime un compte final. Il n'y a pas de quoi s'inquiéter.

Je vous déconseille d'utiliser un PreferenceInferrer à moins que vous ne sachiez absolument que vous le voulez. Avez-vous des évaluations ici? Je pourrais suggérer LogLikelihoodSimilarity sinon.