首先,我有一些用户应用程序的使用历史记录。
例如:
user1,app1,3(发布时间)
user2,app2,2(发布时间)
user3,app1,1(启动时间)
我基本上有两个要求:
所以我在spark上使用MLLib的ALS(隐式)来实现它。首先,我只是使用原始数据来训练模型。结果很可怕。我认为这可能是由于发射时间的延长造成的。发射时间从1到数千。所以我处理原始数据。我认为得分可以反映真实情况和更多正规化。
得分= lt / uMlt + lt / aMlt
得分是训练模型的过程结果
lt 是原始数据的启动时间
uMlt 是用户在原始数据中的平均启动时间。 uMlt(用户的所有启动时间)/(此用户启动的应用程序数量)
aMlt 是应用程序在原始数据中的平均启动时间。 aMlt(应用程序的所有启动时间)/(启动此应用程序的用户数量)
以下是处理后数据的一些示例。
评分(95788,20992,0.14167073369026184)
评级(98696,20992,5.92363166809082)
评级(160020,11264,2.261538505554199)
评级(67904,11264,2.261538505554199)
评级(268430,11264,0.13846154510974884)
评级(201369,11264,1.7999999523162842)
评级(180857,11264,2.2720916271209717)
评级(217692,11264,1.3692307472229004)
评级(186274,28672,2.4250855445861816)
评级(120820,28672,0.4422124922275543)
评级(221146,28672,1.0074234008789062)
完成此操作后,聚合具有不同包名称的应用程序,结果似乎更好。但还是不够好。
我发现用户和产品的功能非常小,而且大多数都是负面的。
以下是产品功能的3行示例,每行10个维度:
((CompactBuffer(com.youlin.xyzs.shoumeng,com.youlin.xyzs.juhe.shoumeng)),( - 4.798973236574966E-7,-7.641608021913271E-7,6.040852440492017E-7,2.82689171626771E-7, -4.255948056197667E-7,1.815822798789668E-7,5.000047167413868E-7,2.0220664964654134E-7,6.386763402588258E-7,-4.289261710255232E-7))
((CompactBuffer(com.dncfcjaobhegbjccdhandkba.huojia)),( - 4.769295992446132E-5,-1.7072002810891718E-4,2.1351299074012786E-4,1.6345139010809362E-4,-1.4456869394052774E-4,2.3657752899453044E-4,-4.508546771830879E- 5,2.0895185298286378E-4,2.968782791867852E-4,1.9461760530248284E-4))
((CompactBuffer(com.tern.rest.pron)),( - 1.219763362314552E-5,-2.8371430744300596E-5,2.9869115678593516E-5,2.0747662347275764E-5,-2.0555471564875916E-5,2.632938776514493E-5,2.934047643066151E -6,2.296348611707799E-5,3.8075613701948896E-5,1.2197584510431625E-5))
以下是用户功能的3行示例,每行10个维度:
(96768,( - 0.0010857731103897095,-0.001926362863741815,0.0013726564357057214,6.345533765852451E-4,-9.048808133229613E-4,-4.1544197301846E-5,0.0014421759406104684,-9.77902309386991E-5,0.0010355513077229261,-0.0017878251383081079))
(97280,( - 0.0022841691970825195,-0.0017134940717369318,0.001027365098707378,9.437055559828877E-4,-0.0011165080359205604,0.0017137592658400536,9.713359759189188E-4,8.947265450842679E-4,0.0014328152174130082,-5.738904583267868E-4))
(97792,( - 0.0017802991205826402,-0.003464450128376484,0.002837196458131075,0.0015725698322057724,-0.0018932095263153315,9.185600210912526E-4,0.0018971719546243548,7.250450435094535E-4,0.0027060359716415405,-0.0017731878906488419))
所以你可以想象当我得到特征向量的点积来计算用户项矩阵的值时有多小。
我的问题是:
我在这里放了一些代码。这绝对是一个程序问题。但也许不能通过几行代码解决。
val model = ALS.trainImplicit(ratings, rank, iterations, lambda, alpha)
print("recommendForAllUser")
val userTopKRdd = recommendForAllUser(model, topN).join(userData.map(x => (x._2._1, x._1))).map {
case (uid, (appArray, mac)) => {
(mac, appArray.map {
case (appId, rating) => {
val packageName = appIdPriorityPackageNameDict.value.getOrElse(appId, Constants.PLACEHOLDER)
(packageName, rating)
}
})
}
}
HbaseWriter.writeRddToHbase(userTopKRdd, "user_top100_recommendation", (x: (String, Array[(String, Double)])) => {
val mac = x._1
val products = x._2.map {
case (packageName, rating) => packageName + "=" + rating
}.mkString(",")
val putMap = Map("apps" -> products)
(new ImmutableBytesWritable(), Utils.getHbasePutByMap(mac, putMap))
})
print("recommendSimilarApp")
println("productFeatures ******")
model.productFeatures.take(1000).map{
case (appId, features) => {
val packageNameList = appIdPackageNameListDict.value.get(appId)
val packageNameListStr = if (packageNameList.isDefined) {
packageNameList.mkString("(", ",", ")")
} else {
"Unknow List"
}
(packageNameListStr, features.mkString("(", ",", ")"))
}
}.foreach(println)
println("productFeatures ******")
model.userFeatures.take(1000).map{
case (userId, features) => {
(userId, features.mkString("(", ",", ")"))
}
}.foreach(println)
val similarAppRdd = recommendSimilarApp(model, topN).flatMap {
case (appId, similarAppArray) => {
val groupedAppList = appIdPackageNameListDict.value.get(appId)
if (groupedAppList.isDefined) {
val similarPackageList = similarAppArray.map {
case (destAppId, rating) => (appIdPriorityPackageNameDict.value.getOrElse(destAppId, Constants.PLACEHOLDER), rating)
}
groupedAppList.get.map(packageName => {
(packageName, similarPackageList)
})
} else {
None
}
}
}
HbaseWriter.writeRddToHbase(similarAppRdd, "similar_app_top100_recommendation", (x: (String, Array[(String, Double)])) => {
val packageName = x._1
val products = x._2.map {
case (packageName, rating) => packageName + "=" + rating
}.mkString(",")
val putMap = Map("apps" -> products)
(new ImmutableBytesWritable(), Utils.getHbasePutByMap(packageName, putMap))
})
更新:
在阅读完论文后,我发现了一些关于我的数据的新内容("隐式反馈数据集的协同过滤")。与本文中描述的IPTV数据集相比,我的数据太稀疏。
论文:300,000(用户)17,000(产品)32,000,000(数据)
我的:300,000(用户)31,000(产品)700,000(数据)
因此,论文数据集中的用户项矩阵已填充0.00627 =(32,000,000 / 300,000 / 17,000)。我的数据集比率为0.0000033。我认为这意味着我的用户项目矩阵比纸张更稀疏2000倍 这会导致糟糕的结果吗?还有什么方法可以改善它吗?
答案 0 :(得分:1)
你应该尝试两件事:
从模型中删除用户后,您将无法通过提供用户ID直接从模型获取该用户的推荐。但是,他们只有一个应用评级。因此,您可以在产品矩阵上运行KNN搜索,以查找与用户apps = recommended最相似的应用。