Formation progressive du modèle de SLA

j'imagine que vous utilisez le modèle SLA de sparklib qui effectue la factorisation matricielle. Le résultat du modèle sont deux matrices une matrice des caractéristiques de l'utilisateur et une matrice des éléments.

en supposant que nous allons recevoir un flux de données avec des notations ou des transactions pour le cas de implicite, une vraie (100%) mise à jour en ligne de ce modèle sera de mettre à jour les deux matrices pour chaque nouvelle information de notation venant en déclenchant un retrain complet du modèle ALS sur l'ensemble des données à nouveau + la nouvelle notation. Dans ce scénario, on est limité par le fait que l'exécution de l'ensemble du modèle ALS est coûteuse sur le plan informatique et que le flux de données entrantes pourrait être fréquent, de sorte qu'il déclencherait trop souvent un recyclage complet.

donc, sachant que nous pouvons chercher des alternatives, une seule notation ne devrait pas changer les matrices beaucoup plus nous avons des approches d'optimisation qui sont incrémentielles, par exemple SGD. Il est intéressant (encore expérimental) bibliothèque écrite pour le cas de Les notations explicites qui font des mises à jour incrémentielles pour chaque lot D'un DStream:

https://github.com/brkyvz/streaming-matrix-factorization

L'idée d'utiliser une approche progressive comme SGD suit l'idée d'aussi loin que l'on se déplace vers le dégradé (problème de minimisation) l'une des garanties qui évolue vers un minimum de la fonction d'erreur. Donc, même si nous faisons une mise à jour à la nouvelle notation unique, seulement à la matrice des fonctionnalités de l'utilisateur pour ce spécifique utilisateur, et seulement la matrice item-feature pour cet élément spécifique noté, et la mise à jour est vers le gradient, nous garantissons que nous nous dirigeons vers le minimum, bien sûr comme une approximation, mais encore vers le minimum.

l'autre problème vient de spark lui-même, et le système distribué, idéalement les mises à jour doivent être faites séquentiellement, pour chaque nouvelle notation entrante, mais spark traite le flux entrant comme un lot, qui est distribué comme un RDD, de sorte que les opérations effectuées pour la mise à jour serait effectuée pour l'ensemble du lot sans garantie de séquentialité.

en plus de détails si vous utilisez la prédiction.IO par exemple, vous pouvez faire une formation hors ligne qui utilise les fonctions régulières train et de déploiement intégrées, mais si vous voulez avoir les mises à jour en ligne, vous devrez accéder aux deux matrices pour chaque lot du flux, et exécuter des mises à jour en utilisant SGD, puis demander le nouveau modèle à être déployé, cette fonctionnalité n'est bien sûr pas dans la prévision.IO you would construire sur votre propre.

notes Intéressantes pour SGD mises à jour:

http://stanford.edu / ~rezab/classes/cme323/S15/notes / lec14.pdf

pour mettre à jour votre model near-online (j'écris near, parce que face à cela, la vraie mise à jour en ligne est impossible) en utilisant la technique du fold-in, par exemple: mise à jour en ligne des modèles de factorisation matricielle régularisée pour les systèmes de redémarrage à grande échelle.

Ou vous pouvez regarder le code de:

• MyMediaLite
• Oryx - construction de cadre avec le paradigme de L'Architecture Lambda. Et il devrait avoir des mises à jour avec pli de nouveaux utilisateurs / articles.

C'est la partie de ma réponse pour similaires question où les deux problèmes: la formation en ligne et le traitement des nouveaux utilisateurs/articles étaient mélangés.

dans le journal l'apprentissage Incrémental pour la factorisation de matrice dans prescripteur systèmes ils ont utilisé l'approche des moindres carrés unilatéraux pour l'apprentissage progressif dans la SLA.

http://ieeexplore.ieee.org/document/7840707/