quora文本匹配實驗簡單小結
- 2021 年 5 月 25 日
- AI
最近把kaggle quora的文本匹配比賽過了一下，第一名的結果的logloss為0.11左右，嘗試了一些論文和網文中的方案，這裡記錄一下：
1、預訓練模型秒殺matchzoo里的所有文本匹配模型；
2、matchzoo里的模型效果不是很好啊。。做了一些activation的替換之後效果上升很多，實現有問題；
3、colab升級pro之後盡量用tpu，速度比gpu快太多，節約很多時間，美中不足的是，huggingface的trainer對tpu基本沒有支援，雖然設計了參數，但是官方上的issue里提到沒有針對tpu內的循環計算進行優化，導致使用了tpu之後反而更慢了，我在使用pytorch-lightning的時候也遇到了這個問題，還是tensorflow支援的最好，畢竟都是google家自己的東西；
4、tpu的支援，torch有xla，tensorflow有直接的tpu介面無縫銜接keras，上收起來，torch的xla用起來真的挺費勁的，又要寫主函數，又要xla.spawn，模型記錄起來也很麻煩，所以後面用tpu的實驗我基本用tf.keras重寫了一遍；
後面的實驗基本上用的roberta和bert，matchzoo里的演算法就測試了esim，效果很差，大佬給的程式碼提分太多。
5、數據預處理仍舊是非常有必要的，沒有預處理的validation loss的第一個epoch的logloss大概是0.40+，進行預處理之後（郵箱格式標準化，轉義字元的刪除等等），第一個epochs的logloss下降到0.37，最終10個epochs的結果也是後者比前者高2~3個點（一開始用的gpu，跑的比較慢）；
6、nn對參數和超參數都非常敏感，尤其是複雜的模型，越複雜的模型越敏感，一個weight decay的係數大小就可以決定2~3個點的loss了，非常誇張，所以超參數調整要做，不行參考下kaggle上的一些現成的設置，還有label smooth，lr schedule之類的常見訓練技巧；
7、huggingface的trainer非常的方便，擴展性也很好，自定義loss，分層學習率之類的策略都可以通過繼承Trainer來實現，官方教程有寫，比較好的地方是fp16，多gpu計算，deepspped等加快訓練的功能都封裝好了可以直接調用避免了大量冗餘的程式碼，這一點的設計模式和pytorch-lightning幾乎一樣，閃電也涉及了很好的trainer封裝了這些煩人的過程；
8、超參數這類設置妥當之後，剩下的最重要的還是對數據的處理和抽取了，這點和lgb之類的模型基本一樣，使用一些比較好的祖傳參數設置好了之後，就去做特徵工程，這一點差異特別大，看了kaggle quora的第一名的解決方案，涉及到非常大量的細緻的特徵工程，0.11的loss簡直逆天，反正我用bert嘗試過各種方案基本上都沒能下0.20的logloss。。。
9、數據很重要的地方除了體現在文本數據的預處理和一些特徵工程之外（比如文本匹配問題中各種sentence pairs的距離計算的結果等等），還有一個非常顯著的方法是對當前語料繼續做mlm任務的pretrain 任務，效果非常明顯，第一個epoch的loss直接下降了6個點，但是pretrain任務的迭代次數太多效果反而差，太少效果也不明顯，我訓練了1個epoch和100個epochs的結果都比較一般，大概訓練10~20個epochs左右效果比較驚人；
10、後續還有幾個實驗沒跑，一個是多任務結果，mlm任務和text match的二分類任務一起跑，多任務的訓練方式還挺多，有的地方是每個任務分別交替訓練，我使用的方式是兩個任務一起訓練迭代，這個具體效果就不清楚了，目前暫時不知道val loss能到多少，但是從第一個epoch的loss來看，效果非常好，第一個epoch的text match的logloss就很低了，這個和之前的實驗結果不符，之前的一個文本匹配的比賽測試里多任務的效果很差，主要原因在於我當時用的是cosine similarity loss，和mlm的多分類的loss的量綱差異很大導致效果很不好；
11、還有一個就是多模態的bert了，冠軍方案沒有涉及到bert這類的模型，畢竟是很早之前的比賽那個時候huggingface還沒開源transformer估計，但是通過大量的特徵工程取得了很好的效果，比如說各種距離的計算，這類數據如果要囊括到bert中來就要走多模態的路子了，人工衍生的特徵走一個分支，文本對走bert，二者concat之後再進行交互得到最終的結果這樣，不知道效果如何，還沒開始寫；
12、text match模型其實都可以和bert結合起來的，只要把bert當作一個embedding來用就可以了
