h2o.GBM 在小型数据集上花费的时间太长

h2o.GBM taking too long on a small sized dataset

我有一个相当小的数据集(162,000 个观察值和 13 个属性) 我正在尝试使用 h2o.GBM 进行建模。响应变量是具有大量级别(~ 20,000 级别)的分类变量 该模型没有 运行 内存不足或出现任何错误,但它已经进行了将近 24 小时而没有任何进展(在 H2o.GBM 报告中说 0%) 我终于屈服并阻止了它。 我想知道我的超参数是否有问题,因为数据不是特别大。

这是我的代码:

library(h2o)
localH2O <- h2o.init(nthreads = -1, max_mem_size = "12g") 
train.h20 <- as.h2o(analdata_train) 

  gbm1 <- h2o.gbm(
                    y = response_var
                  , x = independ_vars
                  , training_frame = train.h20
                  , ntrees = 3    
                  , max_depth = 5  
                  , min_rows = 10  
                  , stopping_tolerance = 0.001    
                  , learn_rate = 0.1  
                  , distribution = "multinomial" 
  )

用 20,000 classes 训练一个 classifier 可能不是一个好主意——大多数 GBM 实现甚至不允许你这样做。您能否将 group/cluster 的 classes 分成较少数量的组,以便您可以训练具有较少数量的 classes 的模型?如果是这样,那么您可以分两个阶段进行训练——第一个模型将具有 K classes(假设您将 classes 聚类分为 K 个组)。然后,您可以训练辅助模型,进一步 class 将观察结果转化为原始 classes。

如果您的 classes 代表自然聚集成组层次结构的组,例如邮政编码或 ICD-10 医疗诊断代码,则这种类型的两阶段过程可能有意义。

如果您的用例确实需要您训练 20,000 class GBM(而且没有办法解决),那么您应该在 H2O 集群中使用更大的机器集群(目前还不清楚您当前使用的 CPU 数量)。 H2O GBM 应该能够完成训练,假设它有足够的内存和 CPU,但可能需要一段时间。

H2O GBM 多项式分类的工作方式是,当您要求将 1 棵树作为参数时,它实际上会在引擎盖下方的响应列中为每个级别构建一棵树。

因此,在您的情况下,1 棵树实际上意味着 20,000 棵树。

2 棵树实际上意味着 40,000 棵,依此类推...

(请注意,二项式分类案例采用了一种捷径,只为两者构建一棵树 类。)

所以...它可能会完成,但可能需要很长时间!