注：此文章内容均节选自充电了么创始人，CEO兼CTO陈敬雷老师的新书《GPT多模态大模型与AI Agent智能体》（跟我一起学人工智能）【陈敬雷编著】【清华大学出版社】

配套视频推荐算法系统实战全系列精品课【陈敬雷】

文章目录

推荐算法系统系列五
- 推荐算法CF协同过滤用户行为挖掘（itembase+userbase）
- - 更多技术内容
总结

推荐算法系统系列五

推荐算法CF协同过滤用户行为挖掘（itembase+userbase）

8.1.4 CF协同过滤用户行为挖掘
协同过滤 (Collaborative Filtering, 简称 CF)作为经典的推荐算法之一，在电商推荐推荐系统中扮演着非常重要的角色，比如经典的推荐为如看了又看、买了又买、看了又买、购买此商品的用户还相同购买等都是使用了协同过滤算法。尤其当你网站积累了大量的用户行为数据时，基于协同过滤的算法从实战经验上对比其他算法，效果是最好的。基于协同过滤在电商网站上用到的用户行为有用户浏览商品行为，加入购物车行为，购买行为等，这些行为是最为宝贵的数据资源。比如拿浏览行为来做的协同过滤推荐结果叫看了又看，全称是看过此商品的用户还看了哪些商品。拿购买行为来计算的叫买了又买，全称叫买过此商品的用户还买了。如果同时拿浏览记录和购买记录来算的，并且浏览记录在前，购买记录在后，叫看了又买，全称是看过此商品的用户最终购买。如果是购买记录在前，浏览记录在后，叫买了又看，全称叫买过此商品的用户还看了。在电商网站中，这几个是经典的协同过滤算法的应用。下面详细来讲述。
（1）协同过滤原理与介绍
什么是协同过滤
协同过滤是利用集体智慧的一个典型方法。要理解什么是协同过滤 (Collaborative Filtering, 简称 CF)，首先想一个简单的问题，如果你现在想看个电影，但你不知道具体看哪部，你会怎么做？大部分的人会问问周围的朋友，看看最近有什么好看的电影推荐，而我们一般更倾向于从口味比较类似的朋友那里得到推荐。这就是协同过滤的核心思想。
换句话说，就是借鉴和你相关人群的观点来进行推荐，很好理解。
协同过滤的实现
要实现协同过滤的推荐算法，要进行以下三个步骤：
收集数据——找到相似用户和物品——进行推荐。
收集数据
这里的数据指的都是用户的历史行为数据，比如用户的购买历史，关注，收藏行为，或者发表了某些评论，给某个物品打了多少分等等，这些都可以用来作为数据供推荐算法使用，服务于推荐算法。需要特别指出的在于，不同的数据准确性不同，粒度也不同，在使用时需要考虑到噪音所带来的影响。
找到相似用户和物品
这一步也很简单，其实就是计算用户间以及物品间的相似度。以下是几种计算相似度的方法：
欧几里德距离、Cosine相似度、Tanimoto系数、TFIDF、对数似然估计等。
进行推荐
在知道了如何计算相似度后，就可以进行推荐了。

在协同过滤中，有两种主流方法：基于用户的协同过滤，和基于物品的协同过滤。
基于用户的 CF 的基本思想相当简单，基于用户对物品的偏好找到相邻邻居用户，然后将邻居用户喜欢的推荐给当前用户。计算上，就是将一个用户对所有物品的偏好作为一个向量来计算用户之间的相似度，找到 K 邻居后，根据邻居的相似度权重以及他们对物品的偏好，预测当前用户没有偏好的未涉及物品，计算得到一个排序的物品列表作为推荐。下图给出了一个例子，对于用户 A，根据用户的历史偏好，这里只计算得到一个邻居 - 用户 C，然后将用户 C 喜欢的物品 D 推荐给用户 A。
基于物品的 CF 的原理和基于用户的 CF 类似，只是在计算邻居时采用物品本身，而不是从用户的角度，即基于用户对物品的偏好找到相似的物品，然后根据用户的历史偏好，推荐相似的物品给他。从计算的角度看，就是将所有用户对某个物品的偏好作为一个向量来计算物品之间的相似度，得到物品的相似物品后，根据用户历史的偏好预测当前用户还没有表示偏好的物品，计算得到一个排序的物品列表作为推荐。对于物品 A，根据所有用户的历史偏好，喜欢物品 A 的用户都喜欢物品 C，得出物品 A 和物品 C 比较相似，而用户 C 喜欢物品 A，那么可以推断出用户 C 可能也喜欢物品 C。
计算复杂度
Item CF 和 User CF 是基于协同过滤推荐的两个最基本的算法，User CF 是很早以前就提出来了，Item CF 是从 Amazon 的论文和专利发表之后（2001 年左右）开始流行，大家都觉得 Item CF 从性能和复杂度上比 User CF 更优，其中的一个主要原因就是对于一个在线网站，用户的数量往往大大超过物品的数量，同时物品的数据相对稳定，因此计算物品的相似度不但计算量较小，同时也不必频繁更新。但我们往往忽略了这种情况只适应于提供商品的电子商务网站，对于新闻，博客或者微内容的推荐系统，情况往往是相反的，物品的数量是海量的，同时也是更新频繁的，所以单从复杂度的角度，这两个算法在不同的系统中各有优势，推荐引擎的设计者需要根据自己应用的特点选择更加合适的算法。
适用场景
在item相对少且比较稳定的情况下，使用item CF，在item数据量大且变化频繁的情况下，使用User CF。
（2）类似看了又看、买了又买的单一数据源协同过滤
在这里介绍两种实现方式，一个是基于Mahout分布式是挖掘平台的实现，另一个用Spark的ALS交替最小二乘法来实现。我们先看下Mahout的分布式实现。
我们选择基于布尔型的实现，比如买了又买，用户或者买了这个商品，或者没有买，只有这两种情况。没有用户对某个商品喜好程度的一个打分。这样的训练数据的格式只有两列，用户ID和商品ID，中间以\t分割。运行脚本如下：
/home/hadoop/bin/hadoop jar /home/hadoop/mahout-distribution/mahout-core-job.jar org.apache.mahout.cf.taste.hadoop.similarity.item.ItemSimilarityJob -Dmapred.input.dir=/ods/fact/recom/log -Dmapred.output.dir=/mid/fact/recom/out --similarityClassname SIMILARITY_LOGLIKELIHOOD --tempDir /temp/fact/recom/outtemp --booleanData true --maxSimilaritiesPerItem 36

ItemSimilarityJob常用参数详解：
-Dmapred.input.dir/ods/fact/recom/log --输入路径
-Dmapred.output.dir=/mid/fact/recom/out --输出路径
–similarityClassname SIMILARITY_LOGLIKELIHOOD --计算相似度用的函数，这里是对数似然估计
CosineSimilarity余弦距离
CityBlockSimilarity曼哈顿相似度
CooccurrenceCountSimilarity共生矩阵相似度
LoglikelihoodSimilarity对数似然相似度
TanimotoCoefficientSimilarity谷本系数相似度
EuclideanDistanceSimilarity欧氏距离相似度
–tempDir /user/hadoop/recom/recmoutput/papmahouttemp --临时输出目录
–booleanData true --是否是布尔型的数据
–maxSimilaritiesPerItem 36 --针对每个item推荐多少个item

输入数据的格式，第一列userid，第二列itemid，第三列可有可无，是评分，没有默认1.0分，布尔型的只有userid和itemid：
12049056 189887
18945802 195142
17244856 199482
17244856 195137
17244856 195144
17214244 195126
17214244 195136
12355890 189887
13006258 195137
16947936 200375
13006258 200376
输出文件内容格式，第一列itemid，第二列根据itemid推荐出来的itemid，第三列是item-item的相似度值：
195368 195386 0.9459389382339948
195368 195410 0.9441653614997947
195372 195418 0.9859069433977395
195381 195391 0.9435764760714196
195382 195408 0.9435604861919415
195385 195399 0.9709127607436737
195388 195390 0.9686122649284619
ItemSimilarityJob使用心得：
1）每次计算完再次计算时必须要手动删除输出目录和临时目录，太麻烦。于是对其源码做简单改动，增加delOutPutPath参数，设置true，每次运行会自动删除输出和临时目录。方便了不少。
2）Reduce数量只能是hadoop集群默认值。Reduce数量对计算时间影响很大。为了提高性能，缩短计算时间，增加numReduceTasks参数，一个多亿的数据一个reduce需要半小时，12个reduce只需要19分钟，测试集群是三到五台集群的情况下。
3）业务部门有这样的需求，比如看了又看，买了又买要加百分比，这样的需求mahout协同过滤实现不了。这是mahout本身计算item-item相似度方法所致。另外他只能对单一数据源进行分析，比如看了又看只分析浏览记录，买了又买只分析购买记录。如果同时对浏览记录和购买记录作关联分析，比如看了又买，这个只能自己来开发mapreduce程序了。下面就讲讲如何实现跨数据源的支持时间窗控制的协同过滤算法。
（3）类似看了又买的跨数据源的支持时间窗控制的协同过滤算法
首先说下什么叫跨数据源，简单来说就是同时支持在浏览商品行为和购买行为两个数据源上关联分析。关联拿什么关联？是拿用户ID吗？不单纯是。首先第一个这个用户ID得浏览过，也购买过一些商品。如果这个用户只看过，没有购买过，那这个用户的数据就是脏数据，没有任何意义。另外一个关联就是和其他用户看过的商品有交集，不同的用户都看过同一个商品这才意义，看过同一个商品的大多数用户都买了哪些商品，买的最多的那个商品就和看过同一个的那个商品最相关。这也是看了又买的核心思想。另外再细节上还是可以再优化的。比如控制下购买的商品的时间必须要发生在浏览之后，再精细点就是控制时间差比如和浏览时间相差三个月之内等。
这个算法实现没有开源的版本，Mahout也仅仅支持单一数据源，做不了看了又买。需要我们自己写代码实现，下面是基于Hadoop的MapReduce实现的一个思路，一共是用4个MapReduce来实现。
第一个mapreduce任务-ItemJob
Map的Setup函数：从当前Context对象中获取用户id，项目id，请求时间三列的索引位置，在右数据源中要过滤的文章itemid集合，都缓存到静态变量中
Map：通过userid列的首字符是“l”还是“r”来判断是左数据源还是右数据源，解析数据后以userid作为key，左数据源“l”+itemid+请求时间作为value，右数据源“r”+itemid+userid+请求时间作为value，这些value作为item的输出向量会以userid为key进入reduce。
reduce的setup函数：从当前Context对象中获取右表请求时间发生在左数据源请求时间的前后时间范围，都缓存到静态变量中。
Reduce：key从这里以后就没用了。只需解析itemid的向量集合，接下来通过两个for循环遍历item向量集合中的左数据源itemid和右数据源itemid，计算符合时间范围约束的项目，以左数据源itemid作为key，右数据源itemid +userid为value输出到HDFS分布式文件系统。顺便对有效userid进行getCounter计数，得到总的用户数，为以后的TF*IDF相似度修正做数据准备context.getCounter(Counters.USERS). increment(1);
第二个Mapreduce任务- LeftItemSupportJob，计算左数据源item的支持度
以第一个任务的输出作为输入。Map：key值为左数据源itemid没有用。值解析value得到右数据源itemid，然后以它作为key，整型1作为计数的value为输出
Combiner/Reduce：很简单就是累加计算itemid的个数，以itemid为key，个数也就是支持度为value输出到分布式文件系统上的临时目录上。

第三个mapreduce任务- RightItemSupportJob，计算右表item的支持度
以第一个任务的输出作为输入。Map：key值为左数据源itemid没有用。值解析value得到右表itemid，然后以它作为key，整型1作为计数的value为输出
Combiner/Reduce：很简单就是累加计算itemid的个数，以itemid为key，个数也就是支持度为value输出到分布式文件系统上的临时目录上。

第四个mapreduce任务- ItemRatioJob，计算左数据源item和右表item的相似度
以第一个任务的输出作为输入。这个是最关键的一步。
Map：解析第一个任务的输入，以左数据源itemid为key，右数据源itemid+userid作为value。
Reduce的setup函数：从当前Context对象获取针对每个item推荐的最大推荐个数、最小支持度、用户总数，从第二个任务中输出的临时目录中读取每个右数据源itemid的支持度放到HashMap静态变量中。
Reduce：
1）计算看过此左数据源id并购买的用户数；
2）计算看过此左数据源id下，每个文章被购买的用户数；
3）检查是否满足最小支持度要求；
4）计算相似度（百分比TF）；
5）计算IDF：Math.log(用户总数 / (double) (右表推荐文章itemid的支持度 + 1))
+ 1.0；
6）计算相似度TF*IDF、CosineSimilarity余弦距离、CityBlockSimilarity曼哈顿相似度、CooccurrenceCountSimilarity共生矩阵相似度、LoglikelihoodSimilarity对数似然相似度、TanimotoCoefficientSimilarity谷本系数相似度、EuclideanDistanceSimilarity欧氏距离相似度，当然相似我们选择一个就行，推荐使用TFIDF，在实践做过AB测试效果是最好的，并且它用在对称矩阵和非对称矩阵上都有很好的效果。尤其适合框数据源场景，因为浏览和购买肯定是不对称的。如果是做看了又看等单一数据源，肯定是对称的，对称矩阵的情况下用LoglikelihoodSimilarity对数似然相似度效果是最好的。相似度算好后，然后就是降序排序，提取前N个相关度最高的商品ID,也就是itemid，作为推荐结果并输出到HDFS分布式文件系统上，可以对输出目录建一个Hive外部表，查看和分析推荐结果就非常方便了。
说明：Mahout里面并没有TFIDF相似度的实现，但可以改它的源码加上。另外TFIDF一般用在自然语言处理文本挖掘上，但为什么在基于用户行为的协同过滤算法上同样奏效呢？可以这样理解TFIDF是一种思想，思想是相同的，只是应用场景不同而已。不过最原始的TFIDF的提出还是自然语言处理出提出的，开始主要用在文本上。我们大概讲一下什么是TFIDF，然后引出在协同过滤中怎么去理解它。
（4）类似看了又买的跨数据源的支持时间窗控制的协同过滤算法
TF-IDF（term frequency–inverse document frequency）是一种用于资讯检索与文本挖掘的常用加权技术。TF-IDF是一种统计方法，用以评估一字词对于一个文件集或一个语料库中的其中一份文件的重要程度。字词的重要性随着它在文件中出现的次数成正比增加，但同时会随着它在语料库中出现的频率成反比下降。TF-IDF加权的各种形式常被搜索引擎应用，作为文件与用户查询之间相关程度的度量或评级。除了TF-IDF以外，互联网上的搜寻引擎还会使用基于连结分析的评级方法，以确定文件在搜寻结果中出现的顺序。
原理
在一份给定的文件里，词频（term frequency，TF）指的是某一个给定的词语在该文件中出现的次数。这个数字通常会被正规化，以防止它偏向长的文件。同一个词语在长文件里可能会比短文件有更高的词频，而不管该词语重要与否。
逆向文件频率（inverse document frequency，IDF）是一个词语普遍重要性的度量。某一特定词语的IDF，可以由总文件数目除以包含该词语之文件的数目，再将得到的商取对数得到。
某一特定文件内的高词语频率，以及该词语在整个文件集合中的低文件频率，可以产生出高权重的TF-IDF。因此，TF-IDF倾向于过滤掉常见的词语，保留重要的词语。
那么在电商里面的协同过滤它只的是什么呢？
TF就是原始相似度的值及购买某个商品的占比， docFreq文档频率就是每个商品的支持度， numDocs总的文档数就是总的用户数
public static double calculate(float tf, int df, int numDocs) {
return tf(tf) * idf(df, numDocs);
}
public static float idf(int docFreq, int numDocs) {
return (float) (Math.log(numDocs / (double) (docFreq + 1)) + 1.0);
}

public static float tf(float freq) {
return (float) Math.sqrt(freq);
}

上面讲的协同过滤算法，分别讲了一下在电商中看了又看、买了又买、看了又买的相关实现。协同过滤可以认为是推荐系统的一个核心算法，但不是全部。当在网站刚上线，或者上线后由于缺乏大数据思维，而忘了记录这些宝贵的用为，那么推荐发挥作用最大的就是基于ContentBase的文本挖掘算法。下面我们就重点来讲ContentBase文本挖掘。

总结

此文章有对应的配套新书教材和视频：

【配套新书教材】
《GPT多模态大模型与AI Agent智能体》（跟我一起学人工智能）【陈敬雷编著】【清华大学出版社】
新书特色：《GPT多模态大模型与AI Agent智能体》（跟我一起学人工智能）是一本2025年清华大学出版社出版的图书，作者是陈敬雷，本书深入探讨了GPT多模态大模型与AI Agent智能体的技术原理及其在企业中的应用落地。
全书共8章，从大模型技术原理切入，逐步深入大模型训练及微调，还介绍了众多国内外主流大模型。LangChain技术、RAG检索增强生成、多模态大模型等均有深入讲解。对AI Agent智能体，从定义、原理到主流框架也都进行了深入讲解。在企业应用落地方面，本书提供了丰富的案例分析，如基于大模型的对话式推荐系统、多模态搜索、NL2SQL数据即席查询、智能客服对话机器人、多模态数字人，以及多模态具身智能等。这些案例不仅展示了大模型技术的实际应用，也为读者提供了宝贵的实践经验。
本书适合对大模型、多模态技术及AI Agent感兴趣的读者阅读，也特别适合作为高等院校本科生和研究生的教材或参考书。书中内容丰富、系统，既有理论知识的深入讲解，也有大量的实践案例和代码示例，能够帮助学生在掌握理论知识的同时，培养实际操作能力和解决问题的能力。通过阅读本书，读者将能够更好地理解大模型技术的前沿发展，并将其应用于实际工作中，推动人工智能技术的进步和创新。

【配套视频】

GPT多模态大模型与AI Agent智能体书籍本章配套视频 - 第1章大模型技术原理【陈敬雷】
视频特色： 前沿技术深度解析，把握行业脉搏
揭秘 DeepSeek、Sora、GPT-4 等多模态大模型的技术底层逻辑，详解 Transformer 架构如何突破传统神经网络局限，实现长距离依赖捕捉与跨模态信息融合。
对比编码预训练（BERT）、解码预训练（GPT 系列）及编解码架构（BART、T5）的技术差异，掌握大模型从 “理解” 到 “生成” 的核心逻辑。
实战驱动，掌握大模型开发全流程
提示学习与指令微调：通过 Zero-shot、Few-shot 等案例，演示如何用提示词激活大模型潜能，结合 LoRA 轻量化微调技术，实现广告生成、文本摘要等场景落地（附 ChatGLM3-6B 微调实战代码）。
人类反馈强化学习（RLHF）：拆解 PPO 算法原理，通过智谱 AI 等案例，掌握如何用人类偏好优化模型输出，提升对话系统的安全性与实用性。
智能涌现与 AGI 前瞻，抢占技术高地
解析大模型 “智能涌现” 现象（如上下文学习、思维链推理），理解为何参数规模突破阈值后，模型能实现从 “量变” 到 “质变” 的能力跃升。
前瞻通用人工智能（AGI）发展趋势，探讨多模态模型（如 Sora）如何推动 AI 从 “单一任务” 向 “类人智能” 进化，提前布局未来技术赛道。

推荐算法系统实战全系列精品课【陈敬雷】
视频特色：首先推荐系统不等于推荐算法，更不等于协同过滤。推荐系统是一个完整的系统工程，从工程上来讲是由多个子系统有机的组合，比如基于Hadoop数据仓库的推荐集市、ETL数据处理子系统、离线算法、准实时算法、多策略融合算法、缓存处理、搜索引擎部分、二次重排序算法、在线web引擎服务、AB测试效果评估、推荐位管理平台等，每个子系统都扮演着非常重要的角色，当然大家肯定会说算法部分是核心，这个说的没错，的确。推荐系统是偏算法的策略系统，但要达到一个非常好的推荐效果，只有算法是不够的。比如做算法依赖于训练数据，数据质量不好，或者数据处理没做好，再好的算法也发挥不出价值。算法上线了，如果不知道效果怎么样，后面的优化工作就无法进行。所以AB测试是评价推荐效果的关键，它指导着系统该何去何从。为了能够快速切换和优化策略，推荐位管理平台起着举足轻重的作用。推荐效果最终要应用到线上平台去，在App或网站上毫秒级别的快速展示推荐结果，这就需要推荐的在线Web引擎服务来保证高性能的并发访问。这么来说，虽然算法是核心，但离不开每个子系统的配合，另外就是不同算法可以嵌入到各个子系统中，算法可以贯穿到每个子系统。
从开发人员角色上来讲，推荐系统不仅仅只有算法工程师角色的人就能完成整个系统，需要各个角色的工程师相配合才行。比如大数据平台工程师负责Hadoop集群和数据仓库，ETL工程师负责对数据仓库的数据进行处理和清洗，算法工程师负责核心算法，Web开发工程师负责推荐Web接口对接各个部门，比如网站前端、APP客户端的接口调用等，后台开发工程师负责推荐位管理、报表开发、推荐效果分析等，架构师负责整体系统的架构设计等。所以推荐系统是一个多角色协同配合才能完成的系统。
下面我们就从推荐系统的整体架构以及各个子系统的实现给大家深度解密来自一线大型互联网公司重量级的实战产品项目！！！

自然语言处理NLP原理与实战视频教程【陈敬雷】
视频特色：《自然语言处理NLP原理与实战》包含了互联网公司前沿的热门算法的核心原理，以及源码级别的应用操作实战，直接讲解自然语言处理的核心精髓部分，自然语言处理从业者或者转行自然语言处理者必听视频！

人工智能《分布式机器学习实战》视频教程【陈敬雷】
视频特色：视频核心内容有互联网公司大数据和人工智能、大数据算法系统架构、大数据基础、Python编程、Java编程、Scala编程、Docker容器、Mahout分布式机器学习平台、Spark分布式机器学习平台、分布式深度学习框架和神经网络算法、自然语言处理算法、工业级完整系统实战（推荐算法系统实战、人脸识别实战、对话机器人实战）。

上一篇：《GPT多模态大模型与AI Agent智能体》系列一》大模型技术原理 - 大模型技术的起源、思想
下一篇：DeepSeek大模型技术系列五》DeepSeek大模型基础设施全解析：支撑万亿参数模型的幕后英雄