Thực tiễn tốt nhất để mã hóa các tính năng phân loại cho Cây quyết định?

Khi mã hóa các tính năng phân loại cho hồi quy tuyến tính, có một quy tắc: số lượng người giả nên ít hơn một lần so với tổng số cấp độ (để tránh cộng tuyến).

Có tồn tại một quy tắc tương tự cho Cây quyết định (đóng gói, tăng cường) không? Tôi đang hỏi điều này bởi vì một thực tiễn tiêu chuẩn trong Python dường như là mở rộng ncác cấp độ thành các hình nnộm (sklearns ' OneHotEncoderhoặc Pandas' pd.get_dummies) xuất hiện dưới mức tối ưu đối với tôi.

Bạn muốn đề xuất những cách thực hành tốt nhất nào để mã hóa các tính năng Phân loại cho Cây quyết định?

— Sergei Bushmanov
nguồn

Câu trả lời:

Có vẻ như bạn hiểu rằng bạn có thể có ncác cấp độ, trái ngược với n-1, bởi vì không giống như trong hồi quy tuyến tính, bạn không cần phải lo lắng về tình trạng hoàn hảo.

(Tôi đang xem xét điều này từ phối cảnh R, nhưng tôi cho rằng nó giống với Python.) Điều đó phụ thuộc vào một vài điều, chẳng hạn như 1) gói nào bạn đang sử dụng và 2) bạn có bao nhiêu cấp độ yếu tố.

1) Nếu bạn đang sử dụng randomForestgói R , thì nếu bạn có <33 cấp độ yếu tố thì bạn có thể tiếp tục và để chúng trong một tính năng nếu bạn muốn. Đó là bởi vì trong triển khai rừng ngẫu nhiên của R, nó sẽ kiểm tra xem mức độ yếu tố nào nên ở một bên của sự phân chia và bên kia (ví dụ: 5 cấp độ của bạn có thể được nhóm lại ở bên trái và 7 có thể được nhóm lại bên nhau bên phải). Nếu bạn chia tính năng phân loại ra thành các hình nnộm, thì thuật toán sẽ không có tùy chọn này theo ý của nó.

Rõ ràng nếu gói đặc biệt bạn đang sử dụng không thể xử lý các tính năng phân loại thì bạn chỉ cần tạo ncác biến giả.

2) Như tôi đã nói ở trên, việc triển khai rừng ngẫu nhiên của R chỉ có thể xử lý 32 cấp độ yếu tố - nếu bạn có nhiều hơn mức đó thì bạn cần phải chia các yếu tố của mình thành các tập hợp nhỏ hơn hoặc tạo một biến giả cho mỗi cấp độ.

— Tchotchke
nguồn

Cảm ơn! Tôi có hiểu đúng về bạn không: trừ khi tôi đang lập mô hình trong R, trong đó các tính năng phân loại randomForestđược mã hóa tự động, tôi nên đi với người ngiả vì cộng tác không phải là vấn đề đối với RF?

— Sergey Bushmanov

Có nhiều danh mục được mã hóa nhị phân 32 cấp sẽ có hành vi hơi khác nhau trong cây, vì RF sẽ chỉ chọn trong số các cột nhị phân đó, thay vì chọn cột đơn của yếu tố có nhiều cấp. Sự khác biệt tinh tế này có nghĩa là sự phân chia trên các cột nhị phân sẽ ít thông tin hơn so với việc phân tách trên cột yếu tố, vì chỉ có một lựa chọn (0/1) so với (1 / {2,3}, {2.1} / 3 ) v.v.

— Sycorax nói Phục hồi lại

@ user777 Đây không phải là vấn đề có hơn 32 biến. Đó là một vấn đề của việc không có các biến danh mục "được nhóm" trong Python sklearn... Nói một cách thực tế, có bằng chứng (kinh nghiệm thực tế, nghiên cứu, v.v.) rằng các biến "giả" sẽ hoạt động kém hơn các biến phân loại "được nhóm" [trong R]

— Serge Bushmanov

Về mặt lý thuyết, chúng ta có thể mong đợi những người không được nhóm sẽ hoạt động kém hơn một chút, bởi vì bạn đang cho mô hình kém linh hoạt hơn. Trong trường hợp được nhóm, nếu thực sự tốt hơn khi coi tính năng đó là không được nhóm, thì mô hình sẽ có thể làm điều đó (bằng cách đặt một nhóm ở một bên, và sau đó tất cả các nhóm còn lại ở bên kia). Tuy nhiên, trên thực tế, tôi sẽ ngạc nhiên nếu có nhiều sự khác biệt (đặc biệt là trong trường hợp RF, nơi bạn đang tạo ra rất nhiều cây)

— Tchotchke

Tôi thấy việc triển khai RandomForest sử dụng các tính năng có nhiều mức yếu tố (> 15) chậm như đã đề cập, nhưng cũng mang lại hiệu suất mô hình tầm thường. Tôi đoán rằng một số lượng rất lớn các phân chia có thể sẽ làm giảm sự phân rã dự định của cây trong đoàn. ExtraTrees và Rborist chỉ thử một mẫu con của các phân chia catagorical trong mỗi nút. Điều đó có thể giúp giải mã và chắc chắn tốc độ. Do đó, một loạt các giải pháp giữa "RandomForest thử bất kỳ phân tách nào" và "biến giả giả sklern chỉ thử phân tách 1-vs-rest" là có thể. Ngoài ra các cụm khác nhau của nhiều cấp độ thành ít cấp độ có thể hiển thị hữu ích.

— Soren Havelund Welling

Có một cách tiếp cận khác để xử lý các biến phân loại được gọi là mã hóa mục tiêu / tác động.

Trong sơ đồ này, ý tưởng là mã hóa tính năng bằng cách sử dụng một cột float duy nhất trong đó giá trị là giá trị trung bình của biến mục tiêu trên tất cả các hàng chia sẻ danh mục. Điều này đặc biệt hữu ích cho các mô hình dựa trên cây vì nó áp đặt mối quan hệ thứ tự trong tính năng (nghĩa là các giá trị ở bên phải của danh mục có phản ứng trung bình cao hơn giá trị ở bên trái) và giúp phân chia không gian dự đoán dễ dàng hơn.

Đây là một lời giải thích hay về chủ đề này:
https://towardsdatascience.com/why-you-should-try-mean-encoding-17057262cd0

Và đây là một liên kết đến bài báo ban đầu đề xuất mã hóa: http://helios.mm.di.uoa.gr/~rouvas/ssi/sigkdd/sigkdd.vol3.1/barreca.pdf

Có một số chi tiết khác để tránh ước tính giá trị trung bình trong các loại có số lượng thấp và cũng có một mô hình khác, CatBoost, đề xuất một giải pháp cho xu hướng được giới thiệu bởi mã hóa này, nhưng theo kinh nghiệm của tôi, đó là một cách đơn giản và rất hữu ích để mã hóa các biến phân loại cardinality cao .

— Ludecan
nguồn