Tại sao sử dụng xác nhận chéo phân tầng? Tại sao điều này không làm hỏng lợi ích liên quan đến phương sai?


29

Tôi đã nói rằng có lợi khi sử dụng xác nhận chéo phân tầng, đặc biệt khi các lớp phản hồi không cân bằng. Nếu một mục đích của xác thực chéo là để giải thích tính ngẫu nhiên của mẫu dữ liệu đào tạo ban đầu của chúng tôi, thì chắc chắn mỗi lần xếp có cùng phân phối lớp sẽ hoạt động chống lại điều này trừ khi bạn chắc chắn tập huấn luyện ban đầu của bạn có phân phối lớp đại diện.

Là logic của tôi thiếu sót?

EDIT Tôi quan tâm đến việc phương pháp này có làm hỏng lợi ích của CV hay không. Tôi có thể thấy lý do tại sao cần thiết nếu bạn có một mẫu nhỏ / các lớp rất không cân bằng / cả hai để tránh không có một đại diện duy nhất của lớp phụ trong một lần.

Bài báo Táo-Táo trong các nghiên cứu kiểm chứng chéo: Cạm bẫy trong đo lường hiệu suất phân loại đưa ra trường hợp phân tầng tốt, nhưng tất cả các đối số dường như lên tới 'Phân tầng cung cấp một biện pháp bảo vệ và nhất quán hơn' nhưng không cần phải có biện pháp bảo vệ dữ liệu.

Có phải câu trả lời đơn giản là "Chúng tôi sử dụng nó khi cần thiết vì chúng tôi hiếm khi có đủ dữ liệu." ?

Câu trả lời:


18

Bootstrapping tìm cách mô phỏng hiệu quả của việc vẽ một mẫu mới từ dân số và không tìm cách đảm bảo các bộ thử nghiệm riêng biệt (dư lượng sau khi N lấy mẫu N thay thế).

Xác thực chéo RxK đảm bảo K lần kiểm tra riêng biệt nhưng sau đó được lặp lại R lần cho các phân vùng ngẫu nhiên khác nhau để cho phép các giả định độc lập giữ cho K-CV, nhưng điều này bị mất khi lặp lại.

Xác thực chéo phân tầng vi phạm nguyên tắc rằng các nhãn kiểm tra không bao giờ nên được xem xét trước khi thống kê được tính toán, nhưng điều này thường được cho là vô hại vì tác động duy nhất là cân bằng các nếp gấp, nhưng nó dẫn đến mất tính đa dạng ( mất phương sai không mong muốn). Nó di chuyển xa hơn từ ý tưởng Boostrap về việc xây dựng một mẫu tương tự như những gì bạn rút ra một cách tự nhiên từ toàn bộ dân số. Có thể cho rằng phân tầng lý do chính rất quan trọng là để giải quyết các khiếm khuyết trong các thuật toán phân loại, vì chúng quá dễ bị sai lệch bởi sự biểu hiện quá mức hoặc dưới mức của các lớp. Một thuật toán sử dụng các kỹ thuật cân bằng (bằng cách chọn hoặc cân) hoặc tối ưu hóa một biện pháp chính xác cơ hội (Kappa hoặc tốt nhất là Thông tin) ít bị ảnh hưởng bởi điều này, mặc dù các thuật toán như vậy có thể '

Việc buộc mỗi nếp gấp phải có ít nhất m thể hiện của mỗi lớp, đối với một số m nhỏ, là một cách thay thế cho phân tầng hoạt động cho cả Bootstrapping và CV. Nó có một xu hướng làm mịn, làm cho các nếp gấp có xu hướng cân bằng hơn so với dự kiến.

Tái hiện và đa dạng: Nếu các phân loại đã học trên các nếp gấp đào tạo được sử dụng cho phản ứng tổng hợp không chỉ là ước tính lỗi tổng quát hóa, độ cứng của CV, Bootstrap phân tầng và CV phân tầng dẫn đến mất tính đa dạng và có khả năng phục hồi, so với Bootstrap, bắt buộc Bootstrap và buộc CV.


Có thể xin vui lòng cung cấp một số tài liệu tham khảo về cách bootstrap phân tầng "không thành công" trong đó buộc bootstrap "tốt hơn" không?
usεr11852 nói Phục hồi Monic

16

Có lẽ bạn có thể nghĩ về nó theo cách này. Giả sử bạn có một bộ dữ liệu trong đó có 100 mẫu, 90 trong lớp 'A' và 10 trong lớp 'B'. Trong thiết kế không cân bằng này nếu bạn thực hiện các nhóm ngẫu nhiên bình thường, bạn có thể kết thúc việc xây dựng các mô hình với số lượng cực kỳ ít (hoặc NGAY CẢ KHÔNG!) Từ lớp 'B'. Nếu bạn đang xây dựng một mô hình được đào tạo về dữ liệu có rất ít hoặc thậm chí không có lớp nào khác, làm thế nào bạn có thể mong đợi nó dự đoán nhóm hiếm hơn một cách hiệu quả? Xác thực chéo phân tầng cho phép ngẫu nhiên nhưng cũng đảm bảo các bộ dữ liệu không cân bằng này có một số cả hai lớp.

Để làm dịu những lo ngại về việc sử dụng CV phân tầng với bộ dữ liệu 'cân bằng' hơn, hãy xem xét một ví dụ sử dụng mã R.

require(mlbench)
require(caret)
require(cvTools)

# using the Sonar dataset (208 samples)
data(Sonar)

# see the distribution of classes are very well balanced
prop.table(table(Sonar$Class))

> prop.table(table(Sonar$Class))

M         R 
0.5336538 0.4663462 

# stratified
# set seed for consistency
# caret::createFolds does stratified folds by default
set.seed(123)
strat <- createFolds(Sonar$Class, k=10)

# non-stratified using cvTools
set.seed(123)
folds <- cvFolds(nrow(Sonar), K=10, type="random")
df <- data.frame(fold = folds$which, index = folds$subsets)
non_strat <- lapply(split(df, df$fold), FUN=function(x) x$index)

# calculate the average class distribution of the folds
strat_dist <- colMeans(do.call("rbind", lapply(strat, FUN = function(x) prop.table(table(Sonar$Class[x])))))
    non_strat_dist <- colMeans(do.call("rbind", lapply(non_strat, FUN = function(x) prop.table(table(Sonar$Class[x])))))
strat_dist
> strat_dist
M         R 
0.5338312 0.4661688 
non_strat_dist
> non_strat_dist
M         R 
0.5328571 0.4671429 

Như bạn có thể thấy, trong một tập dữ liệu được cân bằng tốt, các nếp gấp sẽ có phân phối tương tự ngẫu nhiên. Do đó CV phân tầng chỉ đơn giản là một biện pháp đảm bảo trong những trường hợp này. Tuy nhiên, để giải quyết phương sai, bạn sẽ cần xem xét các phân phối của mỗi lần. Trong một số trường hợp (thậm chí bắt đầu từ 50-50), bạn có thể có các nếp gấp có tỷ lệ chia 30-70 một cách ngẫu nhiên (bạn có thể chạy mã ở trên và thấy điều này thực sự xảy ra!). Điều này có thể dẫn đến một mô hình hoạt động kém hơn bởi vì nó không có đủ một lớp để dự đoán chính xác nó do đó làm tăng phương sai CV tổng thể. Điều này rõ ràng quan trọng hơn khi bạn có các mẫu 'giới hạn' trong đó bạn có nhiều khả năng có sự khác biệt rất lớn trong phân phối.

Bây giờ với các bộ dữ liệu rất lớn, sự phân tầng có thể không cần thiết vì các nếp gấp sẽ đủ lớn để vẫn có khả năng chứa ít nhất một tỷ lệ tốt của lớp 'hiếm hơn'. Tuy nhiên, thực sự không có tổn thất tính toán và không có lý do thực sự để từ bỏ sự phân tầng nếu các mẫu của bạn không cân bằng cho dù bạn có bao nhiêu dữ liệu theo quan điểm cá nhân của tôi.


Vâng, điều này làm cho ý nghĩa hoàn toàn. Tuy nhiên, đây là một trường hợp rất cụ thể và bạn đang thực hiện nó để giải thích cho việc thiếu dữ liệu. Nếu bạn có 10.000 mẫu, bạn sẽ làm điều đó? Câu hỏi của tôi là, lý tưởng và cung cấp đủ dữ liệu, nó có phải là một ý tưởng tốt?
James Owers

1
@kungfujam, nó phụ thuộc vào mức độ mất cân bằng dữ liệu của bạn. Ngay cả với lượng dữ liệu khổng lồ, bạn có thể kết thúc với rất ít lớp khác (ngẫu nhiên). Có một số nghiên cứu liên quan đến điều này. Mặc dù một chút hẹn hò, Kohavi báo cáo rằng stratifcation is generally a better scheme, both in terms of bias and variance, when compared to regular cross-validation. Không có sơ đồ lấy mẫu hoàn hảo nhưng trong phân tầng thiết kế không cân bằng là một cách tiếp cận tốt.
cdeterman

Cảm ơn vì điều này. Tôi vừa tìm thấy tờ giấy Kohavi. Cu nhưng quy. Tôi có thể thấy rằng trong các lớp học chung không được cân bằng hoàn hảo và dữ liệu bị hạn chế => phân tầng nói chung là tốt hơn ... nhưng với sự cân bằng hợp lý tôi cảm thấy như thể đó là một sự vi phạm!
James Owers

@kungfujam, phần nào bạn coi là vi phạm? Các nếp gấp k được chọn ngẫu nhiên trừ khi chúng đặc biệt yêu cầu một tỷ lệ nhất định của các nhóm khác nhau. Bạn có thể nghĩ về nó như là ngẫu nhiên tạo các nếp gấp của bạn từ mỗi nhóm và kết hợp chúng lại với nhau cho một lần tổng hợp do đó giữ lại sự ngẫu nhiên mà bạn quan tâm. Với một sự cân bằng hợp lý (ví dụ 60% -40%), có khả năng các nếp gấp của bạn sẽ có tỷ lệ tương tự dù có hoặc không có sự phân tầng (một số biến thể của khóa học).
cdeterman

1
Tôi cảm thấy như nó đánh bại điểm. Mẫu ban đầu của bạn là "ngẫu nhiên". Do đó, tôi nghĩ rằng CV đáng lẽ phải thử và giải thích cho việc này, tạo ra các mô hình khác nhau và dẫn bạn tạo ra một mô hình mạnh mẽ hơn để thay đổi bằng cách xử phạt các mô hình thay đổi khi dữ liệu đầu vào thay đổi. Nếu bạn giới hạn các nếp gấp của bạn để phù hợp với tỷ lệ của mẫu ban đầu, tôi cảm thấy như ở một khía cạnh nào đó bạn đang ngăn nó làm điều đó. Bạn cũng có thể tạo ra một mô hình với độ lệch thấp hơn, nhưng tôi cho rằng nó sẽ có phương sai cao hơn.
James Owers
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.