เวลาการคำนวณฟอเรสต์แบบสุ่มใน R

ฉันใช้แพ็คเกจปาร์ตี้ใน R ที่มี 10,000 แถวและ 34 คุณสมบัติและคุณสมบัติตัวประกอบบางอย่างมีมากกว่า 300 ระดับ เวลาในการคำนวณยาวเกินไป (ใช้เวลาประมาณ 3 ชั่วโมงและยังไม่เสร็จ)

ฉันต้องการทราบว่าองค์ประกอบใดมีผลกระทบอย่างใหญ่หลวงต่อเวลาการคำนวณของฟอเรสต์แบบสุ่ม มันมีปัจจัยหลายระดับหรือไม่ มีวิธีการใดที่ได้รับการปรับแต่งเพื่อปรับปรุงเวลาประมวลผล RF หรือไม่?

ความซับซ้อนโดยรวมของ RF เป็นสิ่งที่ต้องการ ; หากคุณต้องการเพิ่มความเร็วในการคำนวณคุณสามารถลองทำสิ่งต่อไปนี้:$\text{ntree}\cdot\text{mtry}\cdot(\text{# objects})\log( \text{# objects})$

1. ใช้randomForestแทนpartyหรือดีกว่าrangerหรือRborist(แม้ว่าทั้งสองยังไม่ผ่านการทดสอบการต่อสู้)
2. อย่าใช้สูตรคือเรียกแทนrandomForest(predictors,decision)randomForest(decision~.,data=input)
3. ใช้do.traceอาร์กิวเมนต์เพื่อดูข้อผิดพลาด OOB แบบเรียลไทม์ ntreeด้วยวิธีนี้คุณอาจพบว่าคุณสามารถลด
4. เกี่ยวกับปัจจัย RF (และวิธีการทรี) พยายามหาเซตย่อยที่ดีที่สุดของระดับจึงสแกนความเป็นไปได้ ; ด้วยเหตุนี้จึงค่อนข้างไร้เดียงสาปัจจัยนี้สามารถให้ข้อมูลมาก - ไม่พูดถึงว่าสุ่มป่าไม่กินปัจจัยที่มีมากกว่า 32 ระดับ บางทีคุณอาจใช้มันเป็นแบบสั่งซื้อ (และเทียบเท่ากับตัวแปรตัวเลขปกติสำหรับ RF) หรือจัดกลุ่มในบางกลุ่มโดยแยกคุณลักษณะนี้ออกเป็นหลาย ๆ$2^\text{(# of levels-1)}$
5. ตรวจสอบว่าคอมพิวเตอร์ของคุณไม่ได้ใช้ RAM หมดหรือไม่และใช้พื้นที่สว็อป ถ้าเป็นเช่นนั้นซื้อคอมพิวเตอร์ที่ใหญ่กว่า
6. สุดท้ายคุณสามารถแยกชุดย่อยของวัตถุและทำการทดลองเบื้องต้นในเรื่องนี้

เนื่องจาก randomForest เป็นชุดของรถลากอิสระที่ผ่านการฝึกอบรมเกี่ยวกับชุดย่อยของคุณสมบัติแบบสุ่มและบันทึกมันยืมตัวเองเพื่อขนาน combine()ฟังก์ชั่นในแพคเกจ randomForest จะตะเข็บกันป่าได้รับการฝึกฝนอย่างอิสระ นี่คือตัวอย่างของเล่น ในฐานะที่เป็นคำตอบของ @mpq คุณไม่ควรใช้สัญกรณ์สูตร แต่ผ่านใน dataframe / เมทริกซ์ของตัวแปรและเวกเตอร์ของผลลัพธ์ ฉันไร้ยางอายยกสิ่งเหล่านี้จากเอกสาร

library("doMC")
library("randomForest")
data(iris)

registerDoMC(4) #number of cores on the machine
darkAndScaryForest <- foreach(y=seq(10), .combine=combine ) %dopar% {
   set.seed(y) # not really needed
   rf <- randomForest(Species ~ ., iris, ntree=50, norm.votes=FALSE)
}

ฉันผ่านฟังก์ชั่นการรวม randomForest ไปยังพารามิเตอร์. combine ที่มีชื่อคล้ายกัน (ซึ่งควบคุมฟังก์ชั่นในเอาต์พุตของลูปด้านลงคือคุณไม่ได้รับอัตราความผิดพลาด OOB หรือความสำคัญของตัวแปรอนาถา

แก้ไข:

หลังจากอ่านโพสต์ใหม่ฉันรู้ว่าฉันไม่ได้พูดอะไรเกี่ยวกับปัญหา 34+ ปัจจัย คำตอบที่ไม่ได้คิดเอาไว้ว่า wholey สามารถใช้แทนตัวแปรไบนารีได้ นั่นคือแต่ละปัจจัยคอลัมน์ที่ถูกเข้ารหัส 0/1 ระดับปัจจัยเกี่ยวกับสถานะ / ไม่มีสถานะ ด้วยการเลือกตัวแปรบางอย่างจากปัจจัยที่ไม่สำคัญและนำออกคุณสามารถทำให้พื้นที่ของคุณมีขนาดใหญ่เกินไป

ฉันขอแนะนำลิงค์สองสามข้อ:

1) ลดจำนวนระดับของตัวแปรปัจจัย คือการเชื่อมโยงไปยังคำถามที่stackoverflowจะจัดการกับปัญหาที่คล้ายกันในขณะที่ใช้randomForestแพคเกจ มันเกี่ยวข้องกับการใช้เฉพาะระดับที่เกิดขึ้นบ่อยที่สุดและกำหนดระดับใหม่ให้กับระดับอื่นทั้งหมดที่เกิดขึ้นน้อยกว่า

ความคิดที่ว่ามันมาจากที่นี่: 2,009 KDD ท้าทายถ้วยช้า ข้อมูลสำหรับการแข่งขันครั้งนี้มีปัจจัยมากมายที่มีหลายระดับและอธิบายวิธีการที่ใช้ในการตัดข้อมูลลงจาก 50,000 แถว 15,000 คอลัมน์เพื่อให้ทำงานบนแล็ปท็อป RAM 2-core / 2GB

ข้อเสนอแนะสุดท้ายของฉันคือการดูปัญหาที่เกิดขึ้นตามที่แนะนำข้างต้นขนานกับอินสแตนซ์ hi-CPU Amazon EC2

ฉันไม่สามารถพูดถึงความเร็วของอัลกอริธึมเฉพาะใน R แต่ควรเห็นได้ชัดว่าอะไรทำให้เกิดการคำนวณที่ยาวนาน สำหรับต้นไม้แต่ละต้นในรถเข็นสาขาแต่ละแห่งกำลังมองหาการแยกไบนารีที่ดีที่สุด ดังนั้นสำหรับคุณสมบัติทั้ง 34 อย่างนั้นส่วนใหญ่ดูที่การแยกที่กำหนดโดยแต่ละระดับของตัวแปร ทวีคูณเวลาทำงานสำหรับแต่ละแยกในต้นไม้ด้วยจำนวนกิ่งในต้นไม้แล้วคูณด้วยจำนวนต้นไม้ในป่าและคุณใช้เวลานาน ใครจะรู้? อาจจะมีคอมพิวเตอร์ที่ใช้ความเร็วสูงซึ่งอาจใช้เวลาหลายปีกว่าจะเสร็จ

วิธีที่ดีที่สุดในการเร่งความเร็วของสิ่งต่าง ๆ ที่ฉันคิดว่าน่าจะรวมกันในบางระดับเพื่อให้แต่ละตัวแปรลดลงเหลือ 3 ถึง 5 ระดับแทนที่จะมากถึง 300 แน่นอนว่าสิ่งนี้ขึ้นอยู่กับความสามารถในการทำสิ่งนี้โดยไม่สูญเสียความสำคัญ ข้อมูลในข้อมูลของคุณ

หลังจากนั้นบางทีคุณสามารถดูว่ามีอัลกอริทึมที่ฉลาดที่สามารถเร่งเวลาการค้นหาสำหรับการแยกที่แต่ละโหนดของต้นไม้แต่ละต้น อาจเป็นได้ว่าที่ต้นไม้หนึ่ง ๆ การค้นหาแบบแยกเป็นการทำซ้ำการค้นหาที่ทำไว้แล้วสำหรับต้นไม้ก่อนหน้า ดังนั้นหากคุณสามารถบันทึกการแก้ปัญหาของการตัดสินใจแยกก่อนหน้านี้และระบุเวลาที่คุณทำซ้ำบางทีกลยุทธ์นั้นอาจประหยัดเวลาในการคำนวณเล็กน้อย