任 其，李 兵，2，王 健，趙玉琦，熊燚銘

1(武漢大學(xué) 計(jì)算機(jī)學(xué)院，武漢 430072)2(武漢大學(xué) 復(fù)雜網(wǎng)絡(luò)研究中心，武漢 430072) E-mail：renqilvsx@163.com

1 引 言

移動(dòng)應(yīng)用正在日益改變著人們的日常，據(jù)統(tǒng)計(jì)，截至2018年11月初，App Store上擁有的移動(dòng)應(yīng)用數(shù)量已經(jīng)超過250萬個(gè)，下載量超過100萬次的app數(shù)量多達(dá)32788(1)http：//www.appbrain.com/stats/ free-and-paid-android-applications,2018.日益增長(zhǎng)的用戶群為移動(dòng)應(yīng)用的開發(fā)提出了更高的要求，快速敏捷的開發(fā)出高質(zhì)量移動(dòng)應(yīng)用以適應(yīng)日益增長(zhǎng)的用戶需求變得尤為重要.

在移動(dòng)應(yīng)用推薦方面，當(dāng)前大多數(shù)研究工作都是從用戶的角度出發(fā)，即為用戶推薦合適的移動(dòng)應(yīng)用.在面對(duì)日益增長(zhǎng)的移動(dòng)應(yīng)用時(shí)，研究者們關(guān)注的是如何將這大量的移動(dòng)應(yīng)用推薦給用戶以滿足他們的個(gè)性化需求.隨之產(chǎn)生了大量基于海量移動(dòng)應(yīng)用數(shù)據(jù)的推薦算法.例如文獻(xiàn)[1]提出了一種將興趣-功能交互和用戶結(jié)合起來進(jìn)行移動(dòng)應(yīng)用推薦的方法，該方法在推薦過程中考慮到了用戶的隱私偏好.文獻(xiàn)[4]則通過現(xiàn)代資產(chǎn)組合理論(MPT)將移動(dòng)應(yīng)用的流行度，個(gè)人偏好和移動(dòng)設(shè)備約束結(jié)合起來用于移動(dòng)應(yīng)用推薦.然而，這些方法都是從移動(dòng)應(yīng)用使用者的角度出發(fā)，沒有考慮到開發(fā)者的需求.因此，難以實(shí)現(xiàn)輔助開發(fā)者進(jìn)行應(yīng)用開發(fā)的目標(biāo).

第三方庫(kù)在移動(dòng)應(yīng)用開發(fā)中扮演著越來越重要的角色.首先，第三方庫(kù)是用于移動(dòng)應(yīng)用開發(fā)的一種可重用資源，開發(fā)人員可以通過重用第三方庫(kù)來實(shí)現(xiàn)自己需要的功能，從而可以有效的幫助開發(fā)者減低開發(fā)時(shí)間與開發(fā)成本.其次，第三方庫(kù)可用來幫助完成特定的商業(yè)目標(biāo).例如，可以在應(yīng)用中使用廣告庫(kù)完成廣告的推廣或者使用社交庫(kù)完成用戶社交的功能.根據(jù)在Google Play上的移動(dòng)應(yīng)用研究表明，使用最多的第三方庫(kù)是Google ads，也就是廣告庫(kù)，其中使用廣告庫(kù)的移動(dòng)應(yīng)用超過了60%[2，3].這就更加證明第三方庫(kù)在移動(dòng)應(yīng)用中的重要性.然而，可用的第三方庫(kù)數(shù)量繁多且功能各異，這為開發(fā)者選擇合適的第三方庫(kù)提出了新的挑戰(zhàn).為此，我們構(gòu)造了一個(gè)新的數(shù)據(jù)集，該數(shù)據(jù)集包含移動(dòng)應(yīng)用及其描述，第三方庫(kù)及其描述以及移動(dòng)應(yīng)用與第三方庫(kù)之間的調(diào)用關(guān)系.基于這些數(shù)據(jù)，我們可以完成移動(dòng)應(yīng)用第三方庫(kù)的推薦任務(wù).用于推薦任務(wù)的方法有很多，包括傳統(tǒng)的基于歷史信息的協(xié)同過濾算法以及基于模型的矩陣分解，這些方法在很早就被研究者證明可以在Movielens、Netflix等電影推薦中有不錯(cuò)的表現(xiàn)，研究者們進(jìn)一步將不同的推薦方法進(jìn)行混合以提高推薦的精度.基于構(gòu)造的數(shù)據(jù)集，我們提出了一種將基于歷史調(diào)用數(shù)據(jù)的推薦結(jié)果與基于描述文本的推薦結(jié)果進(jìn)行貝葉斯融合的推薦方法.該方法一方面基于歷史調(diào)用數(shù)據(jù)使用了基于用戶的協(xié)同過濾(UBCF)方法，另一方面基于文本信息使用了TF-IDF方法.從兩個(gè)不同的角度來為開發(fā)者推薦適合的第三方庫(kù).

本文的貢獻(xiàn)包括以下兩點(diǎn)：

1.構(gòu)造了一個(gè)全新的數(shù)據(jù)集，即移動(dòng)應(yīng)用(app)與第三方庫(kù)的數(shù)據(jù)集；

2.提出了一種混合推薦技術(shù)用于第三方庫(kù)的推薦，在構(gòu)造的數(shù)據(jù)集上開展實(shí)驗(yàn)進(jìn)行驗(yàn)證，表明了本文所提方法的有效性.

2 相關(guān)工作

在傳統(tǒng)的服務(wù)計(jì)算領(lǐng)域，軟件開發(fā)者通過重用服務(wù)，能夠創(chuàng)造出更多的服務(wù)組合來滿足更多更復(fù)雜的需求并實(shí)現(xiàn)商業(yè)價(jià)值[5].很多研究者提出了很先進(jìn)的推薦方法對(duì)服務(wù)進(jìn)行推薦來實(shí)現(xiàn)服務(wù)組合的目標(biāo).本文所研究的問題與此相似，在移動(dòng)應(yīng)用的開發(fā)過程中，第三方庫(kù)扮演著越來越重要的角色，第三方庫(kù)的重用可以滿足更多的需求.目前，已經(jīng)開展了大量工作進(jìn)行第三方庫(kù)的相關(guān)研究，例如Pearce P等人[6]研究了Android應(yīng)用程序當(dāng)中的廣告庫(kù)，發(fā)現(xiàn)了有49%的應(yīng)用程序中至少包含一個(gè)廣告庫(kù).Shekhar S等人[7]同樣研究的是Android第三方庫(kù)當(dāng)中的廣告庫(kù)，其中說明了一些惡意應(yīng)用會(huì)模擬廣告庫(kù)的行為.有研究人員[8，9]從代碼層面來識(shí)別第三方庫(kù)，做法是使用機(jī)器學(xué)習(xí)來提取特征，但同樣的只能識(shí)別出廣告庫(kù).之后有研究人員[10]使用了基于語義的特征聚類方法，但是這樣的方法同樣不太準(zhǔn)確.這些工作主要與發(fā)現(xiàn)和檢測(cè)第三方庫(kù)有關(guān)，就我們的調(diào)研所知，在第三方庫(kù)的推薦方面尚沒有相關(guān)研究.

在文獻(xiàn)[11]中，研究者提出了一種第三方庫(kù)自動(dòng)檢測(cè)和分類的方法，可以快速精準(zhǔn)的檢測(cè)出Android 移動(dòng)應(yīng)用當(dāng)中的第三方庫(kù).該方法基于多級(jí)聚類技術(shù)進(jìn)行識(shí)別第三方庫(kù)，然后通過機(jī)器學(xué)習(xí)方法對(duì)第三方庫(kù)的功能進(jìn)行分類.該方法用于第三方庫(kù)推薦時(shí)存在的一個(gè)局限是第三方庫(kù)在使用時(shí)可能會(huì)被開發(fā)者修改，這將導(dǎo)致聚類之后得到的第三方庫(kù)可能不全，并且檢測(cè)到的第三方庫(kù)不是完全準(zhǔn)確，難以支撐我們進(jìn)行第三方庫(kù)推薦的任務(wù).

3 問題分析

針對(duì)第三方庫(kù)推薦中面臨的第三方庫(kù)的檢測(cè)與篩選問題，我們構(gòu)造了相應(yīng)的數(shù)據(jù)集.具體構(gòu)造過程如下：首先，從Google Play上面提供的百萬移動(dòng)應(yīng)用中爬取10000多個(gè)移動(dòng)應(yīng)用安裝包，然后使用了工具ClassyShark(2)https: / /github． com/google /android-classyshark對(duì)它們進(jìn)行分析.ClassyShark是Google提供的用于對(duì)apk進(jìn)行反編譯的一個(gè)工具，可以方便我們快速且輕巧的輕量級(jí)瀏覽Android apk.通過使用該工具，我們能夠得到每個(gè)apk反編譯之后的一系列包名.然后我們?cè)O(shè)定了一個(gè)閾值，表示為包名出現(xiàn)在不同apk的次數(shù).這是為了區(qū)分出第三方庫(kù)與開發(fā)者自己寫的代碼庫(kù)，我們認(rèn)為大于這個(gè)閾值即為第三方庫(kù).而對(duì)于出現(xiàn)的代碼混淆問題，通常開發(fā)者混淆的包名和函數(shù)名都是自己為了防止被惡意篡改而對(duì)自己代碼所做的一種保護(hù)措施，所以我們?cè)诤Y選第三方庫(kù)的過程中會(huì)自動(dòng)忽略掉混淆的包名.使用這種方法得到的第三方庫(kù)做實(shí)驗(yàn)時(shí)，我們發(fā)現(xiàn)一個(gè)問題，那就是閾值的選擇問題，我們難以選擇出最適合的閾值來最準(zhǔn)確的篩選出第三方庫(kù).最終，我們選擇了工具AppBrain(3)https: / /www． appbrain． com/stats，該工具將第三方庫(kù)分為三大類：廣告類、社交網(wǎng)絡(luò)類和開發(fā)工具類，該工具上提供的app是基于Google Play，并且AppBrain上每個(gè)第三方庫(kù)都有其所對(duì)應(yīng)的標(biāo)簽及相關(guān)描述.

我們假設(shè)某一個(gè)移動(dòng)應(yīng)用開發(fā)者需要開發(fā)一個(gè)描述為“適用于Android手機(jī)的視頻app，該app提供最熱門的音樂視頻和游戲，娛樂，新聞等視頻，您可以訂閱您喜愛的頻道并與朋友分享”的移動(dòng)app.對(duì)此，開發(fā)人員一開始分析功能需求確定要使用到AdMob庫(kù)，AdMob是全球最大的移動(dòng)廣告網(wǎng)絡(luò)之一，為移動(dòng)網(wǎng)絡(luò)上的發(fā)現(xiàn)，品牌推廣和貨幣化提供解決方案.之后我們的推薦系統(tǒng)會(huì)產(chǎn)生一個(gè)用于視頻移動(dòng)應(yīng)用開發(fā)的第三方庫(kù)的候選列表Android support_lib，firebase，gcm，google_gson，android_arch，facebook，retrofit，zxing，butterknife，jsoup，protobuf.并基于這些候選列表項(xiàng)開發(fā)人員推薦可能要使用的第三方庫(kù)以提高開發(fā)效率和質(zhì)量.

針對(duì)以上的場(chǎng)景，我們可以將問題描述為：對(duì)于appi，i的描述文本與一些確定要使用的第三方庫(kù)是已知信息.我們首先將已經(jīng)要使用的第三方庫(kù)作為對(duì)i的隱式反饋，基于這些隱式數(shù)據(jù)我們可以計(jì)算出與i相似的app并將這些app調(diào)用的第三方庫(kù)作為候選集Ru.此外，通過i的描述文本挖掘出與其他app的語義相似度并生成候選集Rc.最后，通過貝葉斯定理將候選集Ru和Rc融合得到最終的推薦列表.

更一般地，我們將不同的app擴(kuò)展為一個(gè)很大的app集合M，將M中使用到的第三方庫(kù)擴(kuò)展為三方庫(kù)集合L.這樣，我們就構(gòu)建了一個(gè)M與L的隱式反饋矩陣并基于這個(gè)矩陣以及M集合中app的描述文本完成推薦目標(biāo).

4 TF-IDF與UBCF的混合推薦方法

4.1 方法概述

如圖1所示，本文提出了一種結(jié)合app和第三方庫(kù)交互信息和文本描述信息的方法.本方法主要是由兩部分組成，基于協(xié)同過濾推薦模塊和基于內(nèi)容的推薦模塊.

圖1 App第三方庫(kù)的混合推薦方法框架Fig.1 Framework of hybrid recommendation method for App third-party libraries

協(xié)同過濾的模塊主要的作用是構(gòu)建一個(gè)app和第三方庫(kù)的調(diào)用關(guān)系矩陣，從這個(gè)矩陣中我們可以挖掘出他們兩者的關(guān)系.基于內(nèi)容的推薦模塊主要是利用app的需求描述和第三方庫(kù)的描述信息來完成，本文中我們使用了TF-IDF來計(jì)算文本相似度.首先將描述信息轉(zhuǎn)化為文本特征向量，然后得到他們之間的語義關(guān)系，基于語義關(guān)系計(jì)算出app之間的相似度，然后利用相似度生成第三方庫(kù)的推薦列表.最后將協(xié)同過濾的推薦結(jié)果和基于文本的推薦結(jié)果通過使用貝葉斯定理進(jìn)行整合，整合之后得到最終的推薦結(jié)果.

4.2 UBCF部分

協(xié)同過濾算法是最早用于推薦系統(tǒng)中，也是最為經(jīng)典和著名的推薦算法.該算法主要通過歷史使用數(shù)據(jù)來發(fā)現(xiàn)目標(biāo)用戶的偏好，這些歷史使用數(shù)據(jù)可以是顯式的反饋數(shù)據(jù)，也可以是隱式反饋數(shù)據(jù).在服務(wù)計(jì)算領(lǐng)域，QoS的預(yù)測(cè)是很多研究者所關(guān)心的問題，大多數(shù)基于QoS的方法是預(yù)測(cè)和排序服務(wù)質(zhì)量(QoS)以推薦最佳服務(wù)[12-15]. 他們遵循經(jīng)典推薦系統(tǒng)的思想，其中協(xié)同過濾(CF)被廣泛使用來進(jìn)行QoS預(yù)測(cè).鄭子彬等人在文獻(xiàn)[16]中就QoS預(yù)測(cè)問題提出了一種協(xié)同過濾方法并取得較好的結(jié)果.本文中使用的是隱式反饋數(shù)據(jù)，即數(shù)據(jù)是二值的，0表示沒有交互，1則表示有.同時(shí)，傳統(tǒng)的協(xié)同過濾算法分為基于用戶與基于物品這兩種.顧名思義，前一種表示挖掘用戶之間的相似性，基本思想是根據(jù)具有相似偏好的用戶來為用戶推薦可能喜好的物品；后一種表示尋找相似的物品，來直接為目標(biāo)用戶做推薦.無論是基于用戶的推薦還是基于物品的推薦，都需要計(jì)算相似度，通?？梢允褂糜嘞蚁嗨贫然蛘咂栠d相關(guān)系數(shù)等相似度計(jì)算方法.本文中我們使用了余弦相似度來完成這個(gè)任務(wù).本文中使用到的協(xié)同過濾圖模型如圖2所示.

圖2 協(xié)同過濾圖模型Fig.2 Collaborative filtering model

如圖2所示，在協(xié)同過濾中，每行表示一個(gè)app，每列表示一個(gè)三方庫(kù)，矩陣中的1表示該app調(diào)用了該三方庫(kù)，0表示沒有.而圖的右邊則是對(duì)于三方庫(kù)的推薦過程.從左邊到右邊是通過相似度的計(jì)算進(jìn)行的，如下所示.

(1)

Sim(i，j)表示appi和appj之間的相似度值.得到app之間的相似度矩陣之后，我們可以計(jì)算appi對(duì)第三方庫(kù)lib的相似度：

(2)

其中，Si,j表示appi和appj之間的相似度，Ij,lib表示appj是否與第三方庫(kù)lib有交互，1表示是，0表示否，N則表示與appi相似的所有app集合.

4.3 TF-IDF部分

TF-IDF是一種統(tǒng)計(jì)方法，通常用于評(píng)估某一個(gè)詞對(duì)于某個(gè)文檔集合或者文檔集合中某一篇文檔的重要程度.TF-IDF分為TF和IDF兩部分.TF是詞頻的意思，是指某個(gè)給定單詞在指定文檔中的頻率，通常會(huì)將這個(gè)值歸一化；IDF表示逆向文件頻率，用來度量一個(gè)單詞的普遍重要性的程度.IDF的值越高，說明這個(gè)單詞在整個(gè)文檔集合中的重要性越低.由此，TF-IDF的思想可以表示為：當(dāng)某一個(gè)單詞在給定的一篇文檔中的TF很高，IDF值也很高的時(shí)候，就認(rèn)為這個(gè)單詞具有很好的區(qū)分能力，因此就保留下來這個(gè)單詞.

對(duì)于移動(dòng)應(yīng)用市場(chǎng)中的app，幾乎每個(gè)都有其對(duì)應(yīng)的文本描述，同樣的，給定一個(gè)將要開發(fā)的app的文本描述，在本文中，我們基于這些文本描述使用TF-IDF和向量空間模型來計(jì)算app之間的相似度.首先我們計(jì)算出每個(gè)app描述文本當(dāng)中每個(gè)單詞的TF-IDF值，在計(jì)算完單詞的TF-IDF值之后，我們進(jìn)行關(guān)鍵詞的篩選，即保留重要的單詞，去掉非必要的單詞.然后我們使用向量空間模型將文本中的單詞向量化.具體的步驟如下：

1)通過使用TF-IDF算法，將兩個(gè)app各自的描述文本進(jìn)行關(guān)鍵詞篩選，即去掉那些非重要性單詞

2)取出每個(gè)文本的若干個(gè)單詞組成單詞集合，然后計(jì)算每個(gè)app描述對(duì)該單詞集合中單詞的TF-IDF值

3)生成兩個(gè)app描述的單詞向量

4)通過計(jì)算出這兩個(gè)app單詞向量的余弦相似度

TF-IDF的方法描述如下：

(3)

(4)

其中，TF(tk，dj)是第k個(gè)詞在第j個(gè)文章中出現(xiàn)的次數(shù)，nk是包含第k個(gè)詞的文章數(shù)量.最后，第k個(gè)詞在第j個(gè)文章中權(quán)重如下：

(5)

這里做歸一化的目的是將不同文檔中的向量表示歸一到同一量級(jí)上.

得到每個(gè)描述文本中每個(gè)單詞的TF-IDF值之后，按照大小排序取前若干個(gè)單詞組成單詞向量.從而兩個(gè)app之間的文本相似度可以表示為：

(6)

其中，Des1和Des2分別app1和app2的描述，Wi1和Wi2分別表示第i個(gè)單詞在app1和app2中的權(quán)重，M表示app總數(shù).

4.4 貝葉斯融合

通過歷史調(diào)用數(shù)據(jù)，我們計(jì)算出了app與第三方庫(kù)的余弦相似度，相似度的值落在0到1的范圍內(nèi).我們可以將其解釋為在一個(gè)app中使用到第三方庫(kù)的概率，即P(libu|app).另一方面，通過app的描述文檔，我們使用TF-IDF計(jì)算app之間的相似度并且利用app的相似度得到app使用第三方庫(kù)的概率，概率表示為P(libc|app).因此，我們假設(shè)條件獨(dú)立，就可以通過貝葉斯定理將這兩個(gè)概率進(jìn)行整合.整合之后，對(duì)于給定的app及其描述，我們可以將其表示為：P(lib|app)=P(libu|app)*P(libc|app).我們將問題轉(zhuǎn)化為對(duì)于第三方庫(kù)來說，它被新的app調(diào)用的可能性是多少，這可由后驗(yàn)概率P(app|lib)給出.通過使用貝葉斯定理，可以得到：

P(app|lib)∝P(libu，libc|app)*P(app)=
P(libu|app)*P(libc|app)

(7)

其中，P(app)是我們看到app的先驗(yàn)概率，大小為1/M，M是app的總數(shù).這樣，我們可以選出具有最大P(app|lib)的第三方庫(kù).

5 實(shí) 驗(yàn)

在本節(jié)中，我們將介紹為評(píng)估提出的第三方庫(kù)推薦方法性能所進(jìn)行的實(shí)驗(yàn)研究和不同方法之間的對(duì)比實(shí)驗(yàn)，我們的實(shí)驗(yàn)是基于之前所構(gòu)造的現(xiàn)實(shí)世界的數(shù)據(jù)集.

5.1 實(shí)驗(yàn)設(shè)置

我們所有的實(shí)驗(yàn)部分都是在具有Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz的處理器和64.0GB內(nèi)存的Windows操作系統(tǒng)上進(jìn)行的.

5.2 數(shù)據(jù)集

本次實(shí)驗(yàn)的全部數(shù)據(jù)來自于AppBrain，這也是AppBrain上的數(shù)據(jù)首次被使用于該實(shí)驗(yàn)?zāi)康?因此，我們選擇的一些現(xiàn)有方法都不曾用于該數(shù)據(jù)集，這些方法會(huì)產(chǎn)生什么樣的效果也讓我們有所期待.AppBrain上包含很多的app及其調(diào)用的第三方庫(kù)，由于考慮數(shù)據(jù)量的大小以及矩陣的稀疏程度，我們選擇了其中的5274個(gè)app，一共包括了470個(gè)第三方庫(kù).同時(shí)我們也獲取了app以及第三方庫(kù)的相關(guān)描述.表1顯示了數(shù)據(jù)集中一個(gè)app的信息.表2顯示了該數(shù)據(jù)集的相關(guān)信息.

表1 App Gesture Call的信息Table 1 Information of App Gesture Call

數(shù)據(jù)預(yù)處理：對(duì)于文本數(shù)據(jù)，我們得到的原始文本數(shù)據(jù)包含了app的名字、類別、開發(fā)者以及描述等信息.第一步，我們選擇了描述信息.然后我們對(duì)描述信息進(jìn)行了分詞，去掉停用詞和非法字符等.剩下的詞最能用來代表描述app的功能.對(duì)于歷史調(diào)用數(shù)據(jù)，正如前面所提到的，我們?cè)谶@方面做了很多的工作，包括自己爬取數(shù)據(jù)并設(shè)計(jì)方法去篩選第三方庫(kù).最終，我們選擇使用AppBrain上的數(shù)據(jù)并且就此構(gòu)造數(shù)據(jù)集.之后，針對(duì)數(shù)據(jù)集我們構(gòu)造了app與第三方庫(kù)的調(diào)用矩陣，該矩陣是一個(gè)0/1矩陣，其中行表示app，列表示第三方庫(kù).

表2 數(shù)據(jù)集的狀態(tài)Table 2 Statistics of dataset

訓(xùn)練集與測(cè)試集：為了評(píng)估推薦性能，我們基于自己的數(shù)據(jù)集為每個(gè)實(shí)驗(yàn)構(gòu)建了一個(gè)訓(xùn)練集和一個(gè)測(cè)試集.首先，我們隨機(jī)選擇70%的app作為實(shí)驗(yàn)的訓(xùn)練集，剩下的部分則作為測(cè)試集.測(cè)試集當(dāng)中的app所包含的一部分第三方庫(kù)用于預(yù)測(cè)，另外一部分則用于訓(xùn)練.每個(gè)實(shí)驗(yàn)進(jìn)行10次實(shí)驗(yàn)，并將它們的平均值作為最終的結(jié)果.

5.3 評(píng)價(jià)指標(biāo)

在實(shí)驗(yàn)中，我們采用了兩種評(píng)價(jià)指標(biāo)用來評(píng)估對(duì)Android app進(jìn)行第三方庫(kù)推薦時(shí)的性能.分別是MAP以及NDCG.

MAP是指平均均值精度，它是信息檢索領(lǐng)域當(dāng)中常見的評(píng)價(jià)指標(biāo).當(dāng)測(cè)試集中app的數(shù)量為Atest時(shí)，推薦K個(gè)第三方庫(kù)的MAP值定義如下：

(8)

其中，Atest表示測(cè)試集app的數(shù)量，la表示appa所調(diào)用的第三方庫(kù)的數(shù)量，Ki表示出現(xiàn)在推薦列表中的a的第三方庫(kù)的數(shù)量，I(i)表示推薦列表中位置i的第三方庫(kù)是否被a所調(diào)用.

當(dāng)測(cè)試集中app的數(shù)量為時(shí)Atest，推薦K個(gè)第三方庫(kù)的NDCG值定義如下：

(9)

其中，IDCG表示IdealDCG，是指推薦列表中的最佳排列所對(duì)應(yīng)的分?jǐn)?shù).

5.4 比較方法

我們選擇了幾種常見的比較先進(jìn)的算法作為對(duì)比.其中包括基于文本的推薦和基于歷史調(diào)用數(shù)據(jù)的推薦等.

基于用戶的協(xié)同過濾(UBCF)：基于用戶的協(xié)同過濾算法是一種廣泛應(yīng)用于推薦系統(tǒng)的經(jīng)典算法.

基于物品的協(xié)同過濾(IBCF)：基于物品的協(xié)同過濾算法同樣是一種廣泛應(yīng)用于推薦系統(tǒng)的經(jīng)典算法，所不同的是計(jì)算物品之間的相似度.

基于主題模型LDA的推薦算法(LDA)：基于文本主題模型的推薦算法，通過使用LDA計(jì)算出每?jī)蓚€(gè)app描述文本的主題相似度，基于這些相似度生成第三方庫(kù)的推薦列表.

基于用戶的協(xié)同過濾與主題模型LDA的混合推薦算法(LDA+UBCF)：同上，我們通過將主題模型LDA與UBCF進(jìn)行整合得到混合推薦結(jié)果.

圖3 NDCG@KFig.3 NDCG@K圖4 MAP@KFig.4 MAP@K

圖3和圖4展示了我們所提出的混合推薦方法即TF-IDF+UBCF與其他的方法在NDCG@K，MAP@K這兩個(gè)指標(biāo)上的對(duì)比.UBCF基本上在這兩項(xiàng)指標(biāo)上都是差于其他的方法.同時(shí)，對(duì)比基于歷史調(diào)用方法和基于內(nèi)容的方法，我們可以得出基于文本描述的方法即LDA要表現(xiàn)的比基于用戶的協(xié)同過濾更加優(yōu)異，但卻要比IBCF在兩種指標(biāo)上略差，其原因是我們?cè)谧龅谌綆?kù)的推薦時(shí)，并沒有考慮到三方庫(kù)在移動(dòng)應(yīng)用中的優(yōu)先級(jí)，所以使用UBCF時(shí)可能會(huì)忽略掉優(yōu)先級(jí)較高的第三方庫(kù).而IBCF則是直接通過第三方庫(kù)之間的相似度關(guān)系進(jìn)行推薦，因此，使用IBCF的效果要優(yōu)于UBCF.此外，無論是基于歷史調(diào)用數(shù)據(jù)的方法還是基于內(nèi)容的方法在兩種指標(biāo)上都比混合方法效果差.同時(shí)我們的貝葉斯混合推薦方法也在所有方法中脫穎而出.幾種指標(biāo)的部分詳細(xì)數(shù)值如下表所示.

表3-表4顯示了各項(xiàng)指標(biāo)的具體數(shù)值.表中加粗的數(shù)據(jù)是給定K的最好結(jié)果，?表示在0.01水平上與最佳結(jié)果的差異性具有統(tǒng)計(jì)顯著性.從以上表格中看出，我們的混合推薦方法基本在所有指標(biāo)中都是最好的結(jié)果，并且在后兩個(gè)指標(biāo)上與其他方法幾乎都具有統(tǒng)計(jì)顯著性的差異.更具體點(diǎn)，在NDCG這個(gè)指標(biāo)上，當(dāng)K為40時(shí)，TF-IDF+UBCF比UBCF高8.86%，比LDA+UBCF高2.76%；在MAP上，當(dāng)K為40時(shí)，TF-IDF+UBCF比UBCF高7.35%，比LDA+UBCF高3.33%.

我們發(fā)現(xiàn)，在利用貝葉斯混合推薦方法進(jìn)行基于內(nèi)容的推薦時(shí)，挖掘到的相似移動(dòng)應(yīng)用的數(shù)量N對(duì)最終的推薦結(jié)果有著一定的影響，當(dāng)設(shè)置的相似app數(shù)量較少時(shí)，會(huì)導(dǎo)致推薦結(jié)果不夠完整，而當(dāng)我們將N設(shè)置較大時(shí)則會(huì)產(chǎn)生一些相關(guān)性不大的推薦結(jié)果.所以，設(shè)置適當(dāng)?shù)腘的大小對(duì)我們的工作來說是有必要的.為了研究N的大小對(duì)推薦結(jié)果的影響，我們將N的范圍設(shè)置為20到120，步長(zhǎng)為20.如圖5和圖6所示，當(dāng)N從20增加到60 時(shí)，NDCG和MAP值都相應(yīng)增加.

表3 5種方法的詳細(xì)NDCG值Table 3 Detailed NDCG values for the five methods

表4 5種方法的詳細(xì)MAP值Table 4 Detailed MAP values for the five methods

圖5 NDCG@KFig.5 NDCG@K

圖6 MAP@KFig.6 MAP@K

但是當(dāng)N從60增加到120時(shí)，兩種度量指標(biāo)都幾乎沒什么變化或者說在某個(gè)值附近浮動(dòng)，這是因?yàn)榕琶娇亢蟮囊苿?dòng)應(yīng)用有著越小的影響因子，當(dāng)這個(gè)排名值達(dá)到某個(gè)臨界點(diǎn)時(shí)，后面的推薦結(jié)果幾乎不影響整體的推薦性能.由此可以得出，在我們的貝葉斯混合推薦系統(tǒng)中，當(dāng)推薦的移動(dòng)應(yīng)用數(shù)量N不大于60時(shí)，推薦性能會(huì)隨著N的增加而增強(qiáng)；然而當(dāng)N繼續(xù)增加時(shí)，推薦系統(tǒng)基本趨于穩(wěn)定.

6 結(jié)論與未來工作

本文針對(duì)為移動(dòng)應(yīng)用推薦三方庫(kù)這一應(yīng)用場(chǎng)景，構(gòu)建了相應(yīng)的數(shù)據(jù)集.并在此基礎(chǔ)上提出了一種新的混合推薦方法，即使用貝葉斯理論集成了歷史調(diào)用和文本內(nèi)容信息.所提模型中集成的文本內(nèi)容可以在一定程度上緩解推薦系統(tǒng)中經(jīng)典的冷啟動(dòng)問題.在真實(shí)數(shù)據(jù)集上開展的實(shí)驗(yàn)，表明了本文所提方法的有效性.

下一步，我們將在推薦模型中進(jìn)一步利用數(shù)據(jù)集中的app以及第三方庫(kù)的標(biāo)簽與類別等信息，并將這些信息與當(dāng)前隱反饋數(shù)據(jù)加以整合，另外，將使用神經(jīng)網(wǎng)絡(luò)進(jìn)一步挖掘app與第三方庫(kù)的潛在關(guān)系.