임의 포리스트의 최적 트리 수는 예측 변수 수에 따라 달라 집니까?

예측 변수 수가 많은 경우 임의의 포리스트에 많은 수의 나무가 필요한 이유를 누군가가 설명 할 수 있습니까? 최적의 나무 수를 어떻게 결정할 수 있습니까?

랜덤 포레스트는 나무를 키우기 위해 배깅 (모두가 아닌 관찰 샘플 선택)과 랜덤 부분 공간 방법 (즉, 모든 특성이 아닌 피처 샘플 선택- 속성 bagging )을 사용합니다. 관측치 수가 많지만 나무 수가 너무 적 으면 일부 관측치는 한 번만 예측되거나 전혀 예측되지 않습니다. 예측 변수의 수가 많지만 트리의 수가 너무 적 으면 사용 된 모든 부분 공간에서 일부 기능이 이론적으로 누락 될 수 있습니다. 두 경우 모두 무작위 산림 예측력이 감소합니다. 그러나 마지막은 약간의 극단적 인 경우입니다. 부분 공간 선택은 각 노드에서 수행되기 때문입니다.

분류하는 동안 부분 공간 차원은 (기본적으로p는 예측 변수의 총 개수 임)는 작지만 트리에는 많은 노드가 포함되어 있습니다. 회귀 동안 하위 공간 차원은기본적으로p/3(충분히 큰)이지만 트리에는 더 적은 노드가 포함되어 있습니다. 따라서 임의 포리스트의 최적 트리 수는 극단적 인 경우에만 예측 변수 수에 따라 다릅니다.$\sqrt{p}$$p$$p/3$

알고리즘 의 공식 페이지에는 임의의 포리스트가 과적 합하지 않으며 원하는 수의 나무를 사용할 수 있다고 나와 있습니다. 그러나 Mark R. Segal (2004 년 4 월 14 일. "기계 학습 벤치 마크 및 임의 산림 회귀". 생물 정보학 및 분자 생물 통계 센터)는 일부 잡음이 많은 데이터 세트에 비해 적합하다는 것을 발견했습니다. 따라서 최적의 수를 얻으려면 ntree매개 변수 의 그리드에서 임의 포리스트를 훈련 하거나 (단순하지만 CPU를 많이 사용) 트리가 많은 나무로 하나의 임의 포리스트를 구축 keep.inbag하고 첫 번째 트리에 대한 가방 외부 (OOB) 오류율을 계산할 수 있습니다 ( n 이 1 에서으로 변경됨 ) 트리의 OOB 오류율 (보다 복잡하지만 CPU 소비는 적음)을 플롯합니다.$n$$n$$1$ntree

이 기사 에 따르면

그들은 임의의 숲이 64-128 그루 의 나무 사이에 많은 나무를 가져야한다고 제안한다 . 이를 통해 ROC AUC와 처리 시간 사이의 균형이 양호해야합니다.

1000 개 이상의 기능과 1000 개의 행이있는 경우 뭔가를 추가하고 싶습니다.

내 제안은 먼저 크로스 검증을 시작하기 전에 CPU와 램의 수를 감지하여 그들 사이의 비율을 찾아야한다고 제안합니다.

sikit learn python n_jobs=-1을 사용하면 모든 프로세스를 사용할 수 있지만 각 코어가 데이터를 복사하는 데 필요한 비용이 발생하면이 수식을 사용할 수 있습니다

ntree = sqrt (행 수 * 열 수) / numberofcpu