推荐系统中的矩阵分解：ALS算法原理与Spark MLlib实现详解

张

张建站

2026/6/14 3:07:52

10分钟阅读

推荐系统中的矩阵分解ALS算法原理与Spark MLlib实现详解最近在重构一个老旧的电影推荐服务时我又一次把目光投向了协同过滤。当用户和物品的数量膨胀到千万级别传统的基于内存的协同过滤方法就显得力不从心了。这时矩阵分解Matrix Factorization技术特别是交替最小二乘法Alternating Least Squares, ALS配合像Apache Spark这样的分布式计算框架就成了一个非常务实的选择。这篇文章不是教科书式的理论复述而是想从一个实际构建过大规模推荐系统的大数据工程师视角和你聊聊ALS在Spark MLlib里是怎么“活”起来的以及我们在实践中踩过的坑和总结的优化门道。对于处理用户-物品评分矩阵这种典型的高维稀疏数据矩阵分解的核心思想很直观用一个低维的“隐因子”空间来近似表示用户和物品。想象一下我们有一个巨大的表格行是用户列是电影格子里的数字是评分。这个表格绝大部分是空的稀疏而且非常庞大。矩阵分解的目标是找到两个小得多的矩阵一个用户隐因子矩阵一个物品隐因子矩阵让它们的乘积尽可能地拟合已知的评分。ALS就是求解这两个矩阵的一种高效且特别适合并行化的算法。1. ALS算法原理从直觉到公式推导理解ALS关键在于抓住“交替”和“最小二乘”这两个词。为什么需要交替因为如果我们同时优化用户矩阵U和物品矩阵V目标函数是非凸的直接求解非常困难。ALS巧妙地将其转化为两个凸优化子问题固定物品矩阵V优化用户矩阵U然后固定优化后的U再去优化V。如此反复迭代直至收敛。1.1 目标函数与优化思想假设我们的评分矩阵为 ( R ) (维度 ( m \times n ))将其分解为用户隐因子矩阵 ( U ) (维度 ( m \times k )) 和物品隐因子矩阵 ( V ) (维度 ( n \times k ))。ALS的目标是最小化已知评分上的预测误差同时加入正则化项防止过拟合。目标函数通常表示为[ \min_{U, V} \sum_{(i, j) \in \kappa} (r_{ij} - u_i^T v_j)^2 \lambda (|u_i|^2 |v_j|^2) ]这里( \kappa ) 是所有已知评分的( (用户i, 物品j) )对集合( \lambda ) 是正则化系数。第一项是平方误差损失第二项是L2正则化。注意这个公式假设评分是显式的如1-5星。对于隐式反馈数据如点击、观看时长目标函数会有所不同通常采用加权最小二乘。交替优化的精髓在于当固定 ( V ) 时对于每个用户 ( i )其隐因子向量 ( u_i ) 的优化是独立的且目标函数关于 ( u_i ) 是凸的。这开启了大规模并行计算的大门。1.2 单变量闭式解推导我们来看固定 ( V ) 时如何求解 ( u_i )。对于特定用户 ( i )其损失函数部分为[ L(u_i) \sum_{j \in J(i)} (r_{ij} - u_i^T v_j)^2 \lambda |u_i|^2 ]其中 ( J(i) ) 是用户 ( i ) 评过分的物品集合。这是一个关于 ( u_i ) 的岭回归Ridge Regression问题。将其写成矩阵形式会更清晰。令 ( V_i ) 是一个 ( |J(i)| \times k ) 的矩阵其行是用户 ( i ) 评分过的物品对应的隐因子向量 ( v_j^T )。令 ( R_i ) 是一个 ( |J(i)| \times 1 ) 的向量包含对应的真实评分 ( r_{ij} )。则损失函数可重写为[ L(u_i) |R_i - V_i u_i|^2 \lambda |u_i|^2 ]对 ( u_i ) 求梯度并令其为零[ \frac{\partial L}{\partial u_i} -2V_i^T(R_i - V_i u_i) 2\lambda u_i 0 ]整理后得到[ (V_i^T V_i \lambda I) u_i V_i^T R_i ]这是一个经典的线性方程组形式 ( A x b )。其中 ( A V_i^T V_i \lambda I ) 是一个 ( k \times k ) 的矩阵( b V_i^T R_i ) 是一个 ( k \times 1 ) 的向量。由于 ( k )隐因子维度通常很小如10-200这个方程组的求解成本极低。其闭式解为[ u_i (V_i^T V_i \lambda I)^{-1} V_i^T R_i ]同理固定 ( U ) 时每个物品 ( j ) 的隐因子向量 ( v_j ) 的解为[ v_j (U_j^T U_j \lambda I)^{-1} U_j^T R_j ]这里 ( U_j ) 是给物品 ( j ) 评过分的用户对应的隐因子矩阵。下表对比了用户侧和物品侧优化的关键要素要素用户侧优化 (固定V求U)物品侧优化 (固定U求V)优化变量用户隐因子向量 ( u_i )物品隐因子向量 ( v_j )数据矩阵( V_i ) (物品因子矩阵的子集)( U_j ) (用户因子矩阵的子集)目标向量( R_i ) (用户i的评分向量)( R_j ) (物品j的评分向量)核心计算求解 ( (V_i^T V_i \lambda I) u_i V_i^T R_i )求解 ( (U_j^T U_j \lambda I) v_j U_j^T R_j )并行粒度按用户并行每个用户独立计算按物品并行每个物品独立计算这种对称性使得算法实现非常规整。从工程角度看每一轮迭代包含两个完全数据并行的阶段一个更新所有用户向量一个更新所有物品向量。这正是Spark这类基于内存的分布式计算框架所擅长的模式。2. Spark MLlib中的ALS实现剖析Spark MLlib的ALS实现是教科书级的分布式算法工程案例。它没有简单照搬单机算法而是针对分布式数据的特点做了大量优化。理解这些细节对于调优和排查问题至关重要。2.1 数据表示与分区策略在Spark中评分数据通常表示为Rating(user: Int, product: Int, rating: Float)对象的RDD。高效的分区是性能的第一步。MLlib的ALS在内部会将用户和物品ID重新编码为连续的整数索引0到numUsers-1, 0到numItems-1这大大方便了后续的矩阵操作。关键的一步是数据的分区与广播。在更新用户向量时我们需要每个用户对应的物品因子向量 ( V_i ) 和评分 ( R_i )。如果简单地将物品因子矩阵 ( V ) 作为广播变量发送到每个节点然后在每个用户计算时从中查找所需的 ( V_i )会产生大量的网络小流量查询效率低下。MLlib采用了一种更聪明的方法它根据评分数据的分区预先构造好每个分区所需的“因子块”Factor Blocks。具体来说评分数据分区评分RDD按用户ID或物品ID进行分区通过partitionBy。构建发送信息对于每个评分分区算法会分析该分区内的评分涉及哪些用户和物品然后只收集这些用户/物品对应的最新因子向量打包成一个个小的“消息块”。高效的Join通过将评分分区与对应的因子消息块在本地进行Join每个计算节点就获得了它处理本地评分数据所需的全部因子信息完全避免了在计算过程中进行远程数据拉取。这个过程通过OutBlock和InBlock等数据结构进行管理是Spark ALS性能优于许多原生实现的核心。2.2 迭代计算与优化器ALS的迭代循环在Spark中通过一个简单的for循环或while循环实现检查RMSE均方根误差是否收敛或达到最大迭代次数。在每一轮迭代中有两个核心的computeFactors函数调用分别用于更新用户因子和物品因子。更新用户因子的代码逻辑可以简化为以下伪代码// 假设ratingsForUser是一个(userId, (itemIdList, ratingList))的迭代器 // itemFactors是一个广播的数组存储所有物品因子 def computeUserFactors(ratingsForUser: Iterator[(Int, (Array[Int], Array[Float]))], itemFactors: Broadcast[Array[Array[Float]]], rank: Int, lambda: Double): Array[(Int, Array[Float])] { ratingsForUser.map { case (userId, (itemIds, ratings)) // 1. 收集该用户评分过的物品因子构成矩阵V_i var VtV new DoubleMatrix(rank, rank).zero() var VtR new DoubleMatrix(rank, 1).zero() for (idx - 0 until itemIds.length) { val itemFactor itemFactors.value(itemIds(idx)) // 获取物品因子向量 val rating ratings(idx) // 外积累加: V_i^T * V_i // 点积累加: V_i^T * R_i // ... (具体BLAS运算) } // 2. 添加正则化项: V_i^T * V_i lambda * I for (i - 0 until rank) { VtV.put(i, i, VtV.get(i, i) lambda) } // 3. 求解线性方程组 (V_i^T V_i lambda I) * u_i V_i^T R_i // 使用Cholesky分解或直接求逆因为矩阵很小 val userFactor solveLinearEquation(VtV, VtR) (userId, userFactor.toArray) }.toArray }提示实际Spark源码中使用的是jblas库旧版或netlib-java新版进行本地矩阵运算效率远高于纯Scala实现。对于隐式反馈计算V_i^T V_i时会引入置信度权重计算略复杂但框架相同。这个computeFactors函数会在每个评分分区上被调用通过mapPartitions转换实现并行。更新物品因子的过程完全对称。3. 性能调优与实战技巧把ALS算法跑起来是一回事让它在大规模数据集上高效、稳定地跑起来是另一回事。下面分享一些从实战中总结的配置和调优经验。3.1 关键参数解析与设置Spark MLlib的ALS模型有一系列参数理解它们的含义对效果和性能影响巨大。rank(隐因子数量)这是最重要的参数之一。rank太小模型表达能力不足精度低rank太大计算和存储开销剧增且容易过拟合。通常从10-50开始尝试对于千万级用户物品的数据100-200也常见。一个经验是rank值可以设为预估的“用户兴趣维度”的2-3倍。iterations(迭代次数)ALS通常收敛很快10-20次迭代足以。更多迭代带来的收益递减且增加计算成本。一定要设置checkpointInterval防止迭代过程中RDD血缘过长导致栈溢出。lambda(正则化系数)控制模型复杂度防止过拟合。典型值在0.01到1.0之间。需要和rank一起通过验证集调整。lambda越大因子向量越小模型越简单。implicitPrefs(是否为隐式反馈)这个开关至关重要。对于点击、观看时长等数据必须设为true算法会使用alpha和rating参数计算置信度。对于明确的1-5星评分设为false。alpha(隐式反馈置信度系数)仅当implicitPrefstrue时有效。它控制了隐式行为转化为置信度的速度。值越大系统越认为用户的一次点击代表强烈的偏好。通常设置在1到100之间需要仔细调优。一个典型的模型训练代码示例如下import org.apache.spark.ml.recommendation.ALS val als new ALS() .setMaxIter(15) .setRank(50) .setRegParam(0.1) // 即lambda .setUserCol(userId) .setItemCol(movieId) .setRatingCol(rating) .setColdStartStrategy(drop) // 处理预测时新用户/物品的策略 .setCheckpointInterval(5) // 每5次迭代设置一个检查点 val model als.fit(trainingData)3.2 分布式计算优化点当数据量极大时以下几个工程层面的优化能带来显著的性能提升数据预处理与分区过滤噪音移除评分次数过少的用户或物品如少于5次这些数据噪声大对模型贡献小却增加计算复杂度。分区数调整确保RDD有足够的分区通常是集群总核心数的2-4倍以充分利用并行度。可以使用ratingsRDD.repartition(numPartitions)。序列化优化使用Kryo序列化替代默认的Java序列化能减少Shuffle数据量和内存占用。在SparkConf中设置spark.serializer为org.apache.spark.serializer.KryoSerializer并注册相关类。内存与Shuffle调优ALS在迭代中会频繁Shuffle因子矩阵。增大spark.shuffle.file.buffer和spark.shuffle.io.maxRetries有助于稳定Shuffle过程。如果出现OOM内存溢出考虑增加Executor内存 (spark.executor.memory)。降低rank值。使用更小的数据样本进行前期实验。利用缓存训练数据RDD在迭代中被多次使用务必调用.cache()或.persist()将其持久化在内存中。这是Spark迭代算法性能提升的关键。处理冷启动与生成推荐训练好的模型为新用户不在训练集中预测时MLlib会返回NaN。可以通过setColdStartStrategy(“drop”)在评估时自动过滤掉这些预测或者用其他策略如热门推荐来填补。为所有用户生成Top-K推荐时使用model.recommendForAllUsers(K)。这个方法内部进行了优化避免了为每个用户计算所有物品分数的巨大开销。其原理是通过矩阵乘法 ( U \times V^T ) 得到完整的预测评分矩阵分布式计算然后为每个用户取Top-K。4. ALS的对比分析与适用场景没有放之四海而皆准的算法。ALS因其出色的并行能力和在隐式反馈上的良好表现而广受欢迎但它也有其局限性。4.1 与其他矩阵分解方法的对比除了ALS矩阵分解家族还有其他成员它们在优化目标和求解方法上各有侧重。方法核心思想优点缺点适用场景ALS交替固定一组变量用最小二乘求解另一组变量。高度可并行适合分布式计算天然支持隐式反馈收敛速度相对较快。对显式评分数据的噪声较敏感需要反复迭代。大规模用户-物品交互数据显式/隐式需要分布式训练的场景。SGD (随机梯度下降)对每个训练样本沿梯度负方向更新所有参数。实现简单内存消耗低可以轻松加入其他损失函数。串行性较强不易并行收敛速度可能较慢需要仔细调学习率。中小规模数据集或需要尝试复杂、非标准损失函数的场景。SVD (奇异值分解)对评分矩阵直接进行线性代数分解。有严格的数学理论保证能提取最大方差方向。计算复杂度高O(n^3)无法处理缺失值需要先填充矩阵难以加入正则化。数据稠密、矩阵较小且需要精确数学分解的理论分析场景。BPR (贝叶斯个性化排序)优化目标是物品对的排序顺序而非评分绝对值。更适合排序任务直接优化推荐列表的优劣。训练样本是物品对数据量更大实现和调参更复杂。对推荐结果的排序质量有极高要求的场景如电商、新闻流。从工程实现角度看ALS的最大优势在于其“分治”特性。更新用户因子时每个用户的计算完全独立仅依赖于该用户的历史交互和当前的物品因子矩阵。这使得计算可以无冲突地分布到成千上万个计算节点上数据交换Shuffle的模式也非常规整非常适合MapReduce或Spark这样的编程范式。相比之下SGD需要随机访问和更新全局参数在分布式环境下需要复杂的参数同步机制如Parameter Server引入了额外的复杂性和通信开销。4.2 何时选择ALS项目实践中的考量在我经历过的几个推荐项目中选择ALS通常基于以下几点判断数据规模是首要驱动力当用户和物品数量达到百万甚至千万级并且交互数据评分、点击也达到亿级时ALS配合Spark几乎是标准答案。它的扩展性在实践中得到了充分验证。数据稀疏性问题推荐系统的核心挑战之一是数据稀疏。ALS通过低维隐因子模型来泛化用户和物品的特征能够在一定程度上缓解稀疏性问题挖掘潜在的关联。隐式反馈数据如果你的数据是点击、浏览、购买时长等隐式反馈ALS的加权最小二乘变体WALS是现成的、效果良好的选择。很多公司的视频推荐、音乐推荐核心算法都基于此。对实时性要求不高ALS是离线批处理算法通常每天或每小时训练一次全量模型。它不适合需要每秒更新用户偏好的实时推荐场景。这类场景可能需要在线学习算法如流式SGD或将ALS模型作为特征输入到实时排序模型中。一个常见的混合架构是使用ALS离线训练出用户和物品的隐因子向量将其作为“静态”的特征存入特征数据库。线上服务时实时召回阶段可能使用这些向量进行快速近邻搜索如Faiss而在精排阶段则将这些隐因子特征与其他实时特征用户当前会话信息、物品属性等一起输入到一个更复杂的机器学习模型如深度学习排序模型中进行最终打分。这样既利用了ALS从全局历史数据中挖掘长期兴趣的能力又兼顾了实时个性化的需求。最后别忘了模型评估。在推荐系统中离线评估指标如RMSE、MAE对于显式反馈有意义但对于隐式反馈或最终的业务目标更应关注PrecisionK、RecallK、NDCGK等排序指标以及A/B测试中的业务指标如点击率、转化率、观看时长。ALS模型的参数rank, lambda, alpha最终应该以这些线上指标为指导进行优化。调参过程虽然繁琐但往往是模型效果提升最关键的一步。我习惯先用小样本数据网格搜索确定大致范围再在全量数据上进行精细调整这样能节省大量计算资源。