爲什麼mgcv中的bam對於某些數據很慢？

Question

我在mgcv中使用bam函數在多個數據集上擬合了相同的廣義相加模型。雖然對於我的大部分數據集合，合適的時間在10到20分鐘之內完成。對於少數數據集，運行需要超過10個小時才能完成。在緩慢的情況之間我找不到任何相似之處，最終的合適既不特別好也不壞，也不包含任何明顯的異常值。

我怎樣才能弄清楚爲什麼這些情況下適合度太慢？我怎麼能夠加速這些？

我的模型包含兩個光滑項（使用循環三次樣條基）和一些附加的數值和因子變量。估計總共300個係數（包括用於平滑項的係數）。我故意將節點數量保持在理論上最佳數值的信息之下，以加快擬合過程。我的數據集包含大約850k行。

這是函數調用：

bam(
    value 
    ~ 0 
    + weekday_x 
    + weekday 
    + time 
    + "a couple of factor variables encoding special events" 
    + delta:weekday 
    + s(share_of_year, k=length(knotsYear), bs="cc") 
    + s(share_of_year_x, k=length(knotsYear), bs="cc") 
    , knots=list(
     share_of_year=knotsYear 
     , share_of_year_x=knotsYear 
    ) 
    , family=quasipoisson() 
    , data=data 
) 

knotsYears包含26海里。

該模型在大多數情況下收斂速度相當快，但對於少數情況下收斂速度非常慢。

Answer 1

一個最可能的原因：「fREML」失敗

在上面像一個典型的模型，沒有張量平滑te或ti，我的經驗是，REML迭代某些情況下會失敗。

規範bam實現使用fast.REML.fit。這個例程的收斂測試需要一個修復，但是隨着Simon繼續前行，現在更關注discrete方法，他並不熱衷於修復它。固定版本（目前）只能用於測試擴展包，「哲源插件」，補充到我的博士論文。但是fast.REML.fit也不是那麼脆弱，而且這種融合失敗並不常見，否則一大堆報告會在2012年將這個問題修復。

以下只是幫助您進行檢查而不是修復。

讓fit成爲你的模型，需要10小時，檢查fit$outer.info。這給出了它所需的REML迭代次數以及像梯度和Hessian這樣的收斂信息。如果您看到iter = 200或任何說明「步驟失敗」等失敗的信息，那麼您就知道它爲何需要這麼長時間。但如果你看漸變，很可能你會發現它幾乎爲零。換句話說，REML迭代實際上已經收斂，但是fast.REML.fit未能檢測到它。

---

另一個檢查：「性能迭代」

由於正在擬合GAM不是AM（高斯響應相加模型），另外還有一個P-IRLS（懲罰迭代再稱重最小二乘）在REML迭代之外。是的，整個（規範）bam估計是一個雙循環嵌套，稱爲「性能迭代」。這也可能失敗，但是這樣的失敗更爲內在，並且可能不會被克服，因爲「性能迭代」不能保證收斂。因此，檢查fit$iter以查看它是否也非常大（在最壞的情況下它可能是200）。 mgcv手冊有一個專用章節?gam.convergence討論這種類型的收斂失敗，這是「外迭代」是理想的驅動原因。但是，對於大數據集，「外迭代」實施太昂貴。因此，承擔「性能迭代」。

mgcv有一個「跟蹤」選項。如果您在致電bam時設置control = gam.control(trace = TRUE)，偏差信息和迭代計數器將作爲「性能迭代」打印到屏幕上。這給你一個清晰的懲罰偏差路徑，所以你可以檢查它是在周圍騎車還是在某個時刻被困住。這比存儲在fit$iter中的單個迭代編號更具信息性。

---

也許試試新方法？

也許你想嘗試新的discrete = TRUE（2015年增加;論文在2017年正式發佈）。它使用了一個新的擬合迭代。我們很樂意測試它的實際融合能力，而不是老的方法。當使用它時，也打開「跟蹤」。如果它不能收斂，請考慮報告，但我們需要一個可重現的案例。