Rõ ràng tôi không thể nói cho toàn bộ ngành công nghiệp, nhưng tôi làm việc trong ngành công nghiệp và đã cạnh tranh với Kaggle vì vậy tôi sẽ chia sẻ POV của mình.
Đầu tiên, bạn có quyền nghi ngờ rằng Kaggle không khớp chính xác với những gì mọi người đang làm trong ngành. Đây là một trò chơi, và tuân theo tay nghề, với rất nhiều hạn chế điên rồ. Ví dụ, trong hiện đang chạy Santander cạnh tranh:
- Tên tính năng được băm nhân tạo để che giấu ý nghĩa của chúng
- Tập hợp "đào tạo" được giới hạn một cách giả tạo để có ít hàng hơn các cột cụ thể để lựa chọn tính năng, độ mạnh mẽ và kỹ thuật chính quy sẽ không thể thiếu để thành công.
- Bộ được gọi là "kiểm tra" có phân phối khác biệt rõ rệt so với tập huấn luyện và hai bộ rõ ràng không phải là mẫu ngẫu nhiên trong cùng một quần thể.
Nếu ai đó đưa cho tôi một bộ dữ liệu như thế này tại nơi làm việc, tôi sẽ ngay lập tức đề nghị làm việc với họ về kỹ thuật tính năng để chúng tôi có thể nhận được các tính năng hữu ích hơn. Tôi sẽ đề nghị chúng ta sử dụng kiến thức miền để quyết định các thuật ngữ tương tác, ngưỡng, chiến lược mã hóa biến phân loại, v.v. Tiếp cận vấn đề theo cách đó rõ ràng sẽ hiệu quả hơn là cố gắng trích xuất ý nghĩa từ tệp xả do kỹ sư cơ sở dữ liệu tạo ra đào tạo về ML.
Hơn nữa, nếu bạn tìm hiểu, một cột số cụ thể hoàn toàn không phải là số mà là mã ZIP, bạn có thể lấy dữ liệu từ các nguồn dữ liệu của bên thứ 3 như Điều tra dân số Hoa Kỳ để tăng dữ liệu của bạn. Hoặc nếu bạn có một ngày, có thể bạn sẽ bao gồm giá đóng cửa S & P 500 cho ngày đó. Các chiến lược gia tăng bên ngoài như vậy đòi hỏi kiến thức chi tiết về tập dữ liệu cụ thể và kiến thức tên miền quan trọng nhưng thường có tỷ lệ hoàn trả lớn hơn nhiều so với cải tiến thuật toán thuần túy.
Vì vậy, sự khác biệt lớn đầu tiên giữa công nghiệp và Kaggle là trong công nghiệp, các tính năng (theo nghĩa của dữ liệu đầu vào) có thể thương lượng.
Một lớp khác biệt thứ hai là hiệu suất. Thông thường, các mô hình sẽ được triển khai để sản xuất theo một trong hai cách: 1) dự đoán mô hình sẽ được tính toán trước cho mỗi hàng trong bảng cơ sở dữ liệu rất lớn hoặc 2) một ứng dụng hoặc trang web sẽ truyền cho mô hình một hàng dữ liệu và cần một dự đoán trở lại trong thời gian thực. Cả hai trường hợp sử dụng đòi hỏi hiệu suất tốt. Vì những lý do này, bạn thường không thấy các mô hình có thể dự đoán chậm hoặc sử dụng một lượng bộ nhớ khổng lồ như K-Recent-Neighbor hoặc Extra Random Forests. Ngược lại, một hồi quy logistic hoặc mạng nơ ron có thể ghi được một loạt các bản ghi với một vài phép nhân ma trận và phép nhân ma trận có thể được tối ưu hóa cao với các thư viện phù hợp.Mặc dù tôi có thể nhận được +0,001 AUC nếu tôi xếp chồng lên một mô hình không tham số khác, tôi sẽ không vì thông lượng dự đoán và độ trễ sẽ giảm quá nhiều.
Cũng có một khía cạnh đáng tin cậy cho việc này - xếp chồng bốn thư viện bên thứ 3 hiện đại khác nhau, ví dụ LightGBM , xgboost , catboost và Tensorflow (trên GPU , tất nhiên) có thể giúp bạn giảm 0,01 trong MSE chiến thắng các cuộc thi Kaggle, nhưng đó là bốn thư viện khác nhau để cài đặt, triển khai và gỡ lỗi nếu có sự cố. Thật tuyệt nếu bạn có thể khiến tất cả những thứ đó hoạt động trên máy tính xách tay của mình, nhưng để nó chạy bên trong một Docker container chạy trên AWS thì lại là một câu chuyện hoàn toàn khác. Hầu hết các công ty không muốn đứng đầu một nhóm phát triển nhỏ chỉ để đối phó với các loại vấn đề triển khai này.
Điều đó nói rằng, xếp chồng vào bản thân nó không nhất thiết phải là một vấn đề lớn. Trong thực tế, xếp chồng một vài mô hình khác nhau, tất cả đều hoạt động tốt như nhau nhưng có ranh giới quyết định rất khác nhau là một cách tuyệt vời để có được một cú va chạm nhỏ trong AUC và một cú va chạm mạnh mẽ. Chỉ cần đừng ném quá nhiều bồn rửa vào nhà bếp không đồng nhất của bạn mà bạn bắt đầu có vấn đề triển khai.