注:此文章內容均節選自充電了么創始人,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智能體》(跟我一起學人工智能)【陳敬雷編著】【清華大學出版社】書籍。
更多的技術交流和探討也歡迎加我個人微信chenjinglei66。
總結
此文章有對應的配套新書教材和視頻:
【配套新書教材】
《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大模型基礎設施全解析:支撐萬億參數模型的幕后英雄