我与导师的聊天记录
雖然導(dǎo)師遠(yuǎn)在馬來西亞，但是每次都是很耐心的回答我的問題，真的是非常感激啦！
我就想記錄下來，自己提出的問題，老師給我的解答，算是我研究生生涯的很大一部分生活了吧！
噢~ 還有就是，這些都是微信聊天記錄呦！！！
20190919
提問：
https://blog.csdn.net/qq_38412868/article/details/83748553
這里面提到的LSTM實(shí)現(xiàn)的方式
比如一條路勁：U1 -> f1 ->f2 ->f3 -> f4 -> f5
訓(xùn)練時(shí)X：U1 f1 f2 f3 f4
Y：f1 f2 f3 f4 f5
會(huì)得到5個(gè)cell輸出： c1、c2、c3、c4、c5
則損失函數(shù)：Loss = sum( ( [c1 c2 c3 c4 c5] - [f1 f2 f3 f4 f5] ) **2 )
這樣計(jì)算損失的方式是否可取，這樣好像就不需要負(fù)采樣了。
我感覺這樣的計(jì)算方式挺合理的。
但是 是不是進(jìn)行訓(xùn)練的時(shí)候必須有正樣本和負(fù)樣本？
采用負(fù)樣本的目的是為了把推薦問題看成一個(gè)二分類問題嗎？
老師回答：
負(fù)采樣訓(xùn)練不是一般性機(jī)器學(xué)習(xí)模型必備的
但是在我們的問題里，最后評(píng)估模型質(zhì)量的那些measure，是評(píng)估模型是否能將positive樣本的估分比negative樣本的估分高
因此在訓(xùn)練的過程中，我們就要引入negative樣本，在訓(xùn)練數(shù)據(jù)上優(yōu)化使得正樣本比負(fù)樣本的評(píng)分高
這么做是因?yàn)檫@一類型的推薦問題大家公認(rèn)的評(píng)估方式?jīng)Q定的。
如果做推薦評(píng)分預(yù)測(cè)問題，模型評(píng)估的時(shí)候就只是估計(jì)分?jǐn)?shù)的誤差，那么訓(xùn)練的時(shí)候就不需要用負(fù)樣本了
20190920
提問：
LSTM的五個(gè)狀態(tài)進(jìn)行concatenate處理后5*8 的向量轉(zhuǎn)換為8 的向量時(shí)：
使用 [40,20,8] 還是直接使用 [40,8]
是不是數(shù)據(jù)量很大的時(shí)候才采用塔形（減半）的方式設(shè)置MLP，數(shù)據(jù)量少的時(shí)候一個(gè)全連接層就可以了。
老師回答：
使用 [40,20,8] 還是直接使用 [40,8] 這個(gè)不好說，都是測(cè)試完才知道效果，我會(huì)先實(shí)驗(yàn)第一種減半的方法
20190923
1、評(píng)估階段：（假設(shè)user embedding=8）用LSTM對(duì)用戶信任路徑做處理，將每個(gè)hidden state進(jìn)行concatenate得到path embedding 8*5，通過MLP處理得到 path embedding 8，與user embedding進(jìn)行向量內(nèi)積得到鏈路預(yù)測(cè)用戶得分，這里可能需要對(duì)score用sigmoid函數(shù)處理。
2、Loss計(jì)算：（有一丟丟印象，但還是沒有理解這里的計(jì)算）還有一個(gè)很重要的問題就是，如果這樣計(jì)算損失的話，評(píng)估階段使用的MLP里面的參數(shù)并沒有在訓(xùn)練階段的到訓(xùn)練。
老師回答：
這里可能需要對(duì)score用sigmoid函數(shù)處理 -》 這個(gè)沒問題，最后需要得到一個(gè)預(yù)測(cè)分?jǐn)?shù)值的時(shí)候，一般都是會(huì)通過sigmoid
評(píng)估階段使用的MLP里面的參數(shù)并沒有在訓(xùn)練階段的到訓(xùn)練 -》 沒理解你的意思，訓(xùn)練和測(cè)試用的模型要是一樣的架構(gòu)，同一個(gè)模型
因?yàn)樽詈笠粚邮禽敵鲆粋€(gè)概率，一般一定會(huì)通過一層用sigmoid當(dāng)激活函數(shù)的MLP。只是在這層（d=8）前是否還有別的MLP（如d=20）可以自己試驗(yàn)一下，不好說效果好不好
測(cè)試和訓(xùn)練的模型，最后一層都放一個(gè)sigmoid的mlp
還有目前訓(xùn)練的時(shí)候，對(duì)于6個(gè)節(jié)點(diǎn)的路徑，記得先寫成 利用1預(yù)測(cè)2，利用(1, 2) 預(yù)測(cè) 3， 利用(1,2,3) 預(yù)測(cè)4 。。。 我前天發(fā)給你的兩篇論文應(yīng)該都是這樣訓(xùn)練
雖然我覺得這樣模型間接的知道了(1,2) 后是 3了，因?yàn)橛袀€(gè)訓(xùn)練數(shù)據(jù)是(1,2,3) 。但是大部分這一類論文都還用這種方法
提問：
不知道我理解的對(duì)不對(duì)？
老師回答：
數(shù)學(xué)上是對(duì)的 但是實(shí)現(xiàn)的時(shí)候這樣算會(huì)很慢。要像上次說的那樣算S_1->2的時(shí)候P和U要是矩陣，相當(dāng)于要是數(shù)據(jù)里有100個(gè)像你寫的S_1->2的公式計(jì)算，程序里要把這100個(gè)拼成一次計(jì)算
20191004
匯報(bào)：
結(jié)論：
老師回復(fù)：
我想在數(shù)據(jù)里filter掉長度小于6的信任路徑。只訓(xùn)練那些長度6的信任路徑，如果某個(gè)用戶一條長度6的信任路徑也沒有，那么對(duì)他的推薦就退化成SAMN。
可以先統(tǒng)計(jì)下，這13957個(gè)用戶里，有多少能又長度6的路徑的
就是以某個(gè)用戶為起點(diǎn)的路徑，長度有6的，那這個(gè)用戶就算有信任路徑。統(tǒng)計(jì)下，有多少用戶有信任路徑
cici：
我統(tǒng)計(jì)了一下有564個(gè)用戶有長度為6信任路徑，有點(diǎn)少
老師：
那看來效果不好跟這個(gè)路徑數(shù)太少應(yīng)該有關(guān)系。之前你跑實(shí)驗(yàn)的時(shí)候，一個(gè)用戶最多幾條路徑呢？
這564個(gè)用戶有長度為6信任路徑，又一共有幾條？
cici：
為每個(gè)用戶均勻采樣50條路徑，其中564個(gè)用戶存在長度為6的路徑，一共50*13957=697850條路徑中有29979條路徑是長度為6
20191005
匯報(bào)：
結(jié)論：
老師回復(fù)：
這個(gè)想法沒有問題。先試一下推薦訓(xùn)練1次trust訓(xùn)練1次的效果，再試試推薦訓(xùn)練10次trust訓(xùn)練1次這樣。可以把整個(gè)訓(xùn)練過程中，trust部分和推薦部分的loss畫折線圖看一下趨勢(shì)
提問：
一些我的理解不知道對(duì)不對(duì)：
MLP的最后一層，如果是一個(gè)輸出的0-1分類問題，一般使用sigmoid激活函數(shù)；
如果是多個(gè)輸出的分類問題（比如手寫數(shù)字分類），一般使用softmax激活函數(shù)；
而在本實(shí)驗(yàn)中，是通過LSTM的每個(gè)狀態(tài)的concat中學(xué)習(xí)路徑的表示，最后一層應(yīng)該是不需要使用激活函數(shù)的。
老師回復(fù)：
這里數(shù)學(xué)理論上是不需要在最后加激活函數(shù)了
但是實(shí)際實(shí)現(xiàn)里要加sigmoid，來保證計(jì)算機(jī)計(jì)算的時(shí)候的數(shù)值穩(wěn)定性
https://www.tensorflow.org/api_docs/python/tf/nn/sigmoid_cross_entropy_with_logits 如果是TensorFlow的話，我們做的這種問題需要訓(xùn)練negative sample的，一般會(huì)用這個(gè)loss
你看他的說明里面模型最后的輸出就先傳到sigmoid再傳入loss
這樣在計(jì)算每一個(gè)sample的時(shí)候，能保證輸出一定在[0,1]這個(gè)range里。如果不加這個(gè)限制，在一些異常數(shù)據(jù)點(diǎn)上，或者出現(xiàn)梯度爆炸問題的時(shí)候，可能有一些輸出值特別大
比如超過了計(jì)算機(jī)的數(shù)值范圍，導(dǎo)致結(jié)果是nan。這種情況蠻常見的，不一定是程序?qū)戝e(cuò)。有可能就是剃度爆炸了。所以一般最后還是加上sigmoid再傳入loss函數(shù)了
匯報(bào)：
Trust部分對(duì)MLP改進(jìn)：
1 * 128、2 * 128、3 * 128使用一層，未使用激活函數(shù)未使用dropout。
4 * 128、5 * 128使用兩層，中間層激活函數(shù)使用Relu，為防止過擬合設(shè)置keep_prob=0.75。最后一層未使用激活函數(shù)未使用dropout。
結(jié)論：
性能只有了短暫的提升，很奇怪
所以說，現(xiàn)在的問題是信任預(yù)測(cè)這個(gè)任務(wù)采用目前的方式得不到很好的效果。對(duì)推薦任務(wù)沒有起到很好的輔助效果。
接下來我也不知道該從那個(gè)部分對(duì)信任任務(wù)進(jìn)行改進(jìn)了。。。
老師回復(fù)：
最早做的那個(gè)版本，是不是NCF，然后信任部分不是用路徑而是類似NCF做法？
就是推薦部分和信任部分其實(shí)都是NCF？
cici：
是的，推薦部分和信任部分都是NCF
老師：
剛才你匯報(bào)的路徑29979條，不好說這個(gè)數(shù)據(jù)量夠不夠。但是只分布在500多個(gè)用戶，確實(shí)有些問題。
我想現(xiàn)在你試試用SAMN當(dāng)推薦部分，信任部分用之前寫的NCF版的信任邊預(yù)測(cè)。這樣的結(jié)果看看如何。
以路徑建模寫代碼會(huì)比較麻煩，再嘗試更復(fù)雜的路徑方法前。先拿之前的部分代碼和現(xiàn)在的合起來看看效果，會(huì)比較容易點(diǎn)
cici：
可以的，那我這樣試一試。
20191012
匯報(bào)：
老師：
我看了兩個(gè)結(jié)果。總結(jié)來說，兩個(gè)任務(wù)一起學(xué)習(xí)的話，信任部分是越來越差的。但是如果單獨(dú)學(xué)習(xí)信任部分，NCF的架構(gòu)又是能看到recall逐漸變好
我覺得 兩個(gè)任務(wù)間共享參數(shù)的方法 以及multi-task優(yōu)化的方法。這兩塊我明天想想一些方法試一下，看看能不能實(shí)現(xiàn)trust在多任務(wù)學(xué)習(xí)的時(shí)候也有提升
現(xiàn)在這個(gè)模型設(shè)計(jì)，應(yīng)該只有直接共享最底層item embedding這做了共享。挺粗糙的
cici：
對(duì)，只有直接共享user embedding。
https://blog.csdn.net/weixin_37913042/article/details/102498802 我也看了一些文章，然后，然后好像也不是很清楚該怎么改進(jìn)
老師：
我們其實(shí)是這里的硬共享。比較初期，在上面的layer那沒有共享學(xué)習(xí)，所以有問題也還說得過去。我想一下上面層如何共享.
我把下一步的想法，發(fā)郵件給你了
修改模型的時(shí)候要哪里不清楚，直接問我
以后發(fā)實(shí)驗(yàn)結(jié)果也可以用郵件附件發(fā)給我，微信經(jīng)常查看以前的word文件就失效打不開了
cici：
嗯！好的！
20191012
cici：
“ 注意這個(gè)shared layer的參數(shù)是共享的，即它定義的embedding size就是用戶的總數(shù) ” 這里“embedding size就是用戶的總數(shù)”沒太理解.
還有一個(gè)問題是這個(gè)共享操作，只能在向量輸入MLP之前做，因?yàn)檩斎氲組LP的向量是user和item的concate（推薦）、user1和user2的concate（信任），所以沒有你說的第三點(diǎn)，將共享操作分享到第二層、第三層等等。
老師：
embedding size不是指的dimension。那句話的意思就是要是在左邊和右邊的用戶如果是同一個(gè)id即同一個(gè)用戶，那么傳到share 層的時(shí)候這兩個(gè)embedding要乘以同一個(gè)權(quán)重，加上同一個(gè)bias
第二個(gè)問題，就只做一次共享操作先試試好了
cici：
好的，我清楚了！
20191015
cici：
老師，我把結(jié)果發(fā)你郵箱啦！
20191016
老師：
我看文檔看不出問題。你告訴我代碼在服務(wù)器上的路徑，我今天下課看一下
cici：
/home/lyli/MNCF/MNCF3.py
老師：
明天白天你看看51行這是不是應(yīng)該是input_dim=num_users？這兩部分share的是user吧
現(xiàn)在已經(jīng)很晚了，不需要急著看
cici：
嗯，對(duì)的 應(yīng)該是user，
老師：
我明早再看看其他部分
cici：
好的，真是麻煩老師了
20191017
cici：
老師，單把那里改正確的話，還是有問題。主要是，X操作采用元素相乘就沒問題，池化操作和cancate就有問題，理論上來說不應(yīng)該這樣。
老師：
我今早寫了個(gè)版本，急著上課沒法給你
這個(gè)用concate操作結(jié)果救市政策的那種
這個(gè)用concate操作結(jié)果就是正常的那種
但是我為了找出問題，把模型簡(jiǎn)化掉了。ncf里的矩陣分解部分刪掉了
我不經(jīng)常用keras寫代碼。我看你的實(shí)現(xiàn)，可能的問題是共享層那里用的是Embedding
應(yīng)該要用Dense才對(duì)吧。然后我這個(gè)文件里的52行的Dense創(chuàng)建的Shared_User_Layer，在rec和trust部分同時(shí)被調(diào)用
當(dāng)然這樣把MF刪掉了，性能應(yīng)該變差了。你可以試試再把MF部分加上去會(huì)怎么樣
cici：
老師：
你說的有道理，我查了keras的dense，不帶embedding功能。用keras實(shí)現(xiàn)共享功能，得自己定義共享參數(shù)為embedding
我再看看其他部分有沒問題
cici：
我用keras主要是原作者用了keras，我怕我用tensorflow重寫一遍的話，有些地方可能會(huì)寫錯(cuò)，就直接在上面接著改了！
老師：
沒關(guān)系，這個(gè)基于NCF的版本只是拿來測(cè)試下想法，最后的模型應(yīng)該會(huì)擺脫NCF。到時(shí)候再考慮要不要用別的寫也來得及
cici：
好的
20191105
cici：
我之前遇到
RuntimeError: [enforce fail at CPUAllocator.cpp:64] . DefaultCPUAllocator: can’t allocate memory: you tried to allocate 15851784844900 bytes. Error code 12 (Cannot allocate memory)
這個(gè)問題
然后我就百度pytorch如何使用GPU
然后我就在代碼里加了CUDA，把模型放到GPU上運(yùn)算
然后就出現(xiàn)了這個(gè)問題：RuntimeError: CUDA out of memory. Tried to allocate 14763.13 GiB (GPU 3; 10.73 GiB total capacity; 165.28 MiB already allocated; 9.61 GiB free; 10.72 MiB cached)
然后我覺得GPU上內(nèi)存應(yīng)該是能滿足一般需求了的吧是我的model太大的原因嗎？？？
之前一個(gè)可以運(yùn)行的demo是160，686個(gè)link，這個(gè)有899，322個(gè)link Ls：
老師：
根據(jù)提示是方法寫的不對(duì)，要加載1TB的數(shù)據(jù)到GPU：Tried to allocate 14763.13 GiB
你看下數(shù)據(jù)切割有沒問題，一般會(huì)把train數(shù)據(jù)分batch訓(xùn)練，每個(gè)batch的數(shù)據(jù)加載到GPU上
https://zhuanlan.zhihu.com/p/30934236
每次只把這個(gè)data.to(device)
cici：
好，我改改方法！
20191109
cici：
老師我將最近的結(jié)果發(fā)您郵箱啦！
總結(jié)
- 上一篇： Android官方开发文档Trainin
- 下一篇： Android官方开发文档Trainin