Những thách thức công nghiệp và Kaggle. Việc thu thập nhiều quan sát hơn và có quyền truy cập vào nhiều biến quan trọng hơn mô hình ưa thích?


56

Tôi hy vọng tiêu đề là tự giải thích. Trong Kaggle, hầu hết người chiến thắng sử dụng xếp chồng với đôi khi hàng trăm mô hình cơ sở, để tăng thêm vài% MSE, độ chính xác ... Nói chung, theo kinh nghiệm của bạn, mô hình lạ mắt quan trọng như xếp chồng so với thu thập dữ liệu nhiều hơn và nhiều tính năng hơn cho dữ liệu?


4
Nó hoàn toàn phụ thuộc vào việc bạn muốn một luồng tổng quát hữu ích có thể được đào tạo lại nhanh chóng (hoặc nhắm mục tiêu lại vào tập dữ liệu mới hoặc các tính năng mới) hay chỉ giành chiến thắng trong cuộc thi Kaggle cụ thể đó (trên tập dữ liệu tĩnh cụ thể đó, với khai thác rò rỉ, 'tính năng ma thuật' và tất cả). Đối với trước đây, một thuật toán có cùng độ chính xác của sân bóng với thời gian đào tạo thấp hơn nhiều và trên tập dữ liệu nhỏ hơn là 'tốt hơn'. Hãy tưởng tượng nếu Kaggle từng bắt đầu trừng phạt yêu cầu tính toán / bộ nhớ quá mức hoặc thời gian đào tạo, hoặc đưa nó vào như một phần của điểm nộp (tôi đề nghị họ nên có).
smci

2
Được lấy từ "Áp dụng học sâu vào các vấn đề trong thế giới thực" của Rasmus Rothe: "[V]] trong các tình huống trong thế giới thực, sẽ ít nói về việc thuật toán mới của bạn giảm hiệu suất thêm 1% so với phương pháp khác. là về việc xây dựng một hệ thống mạnh mẽ để giải quyết các nhiệm vụ cần thiết với độ chính xác đủ. "
beatngu13

Câu trả lời:


77

Nhân tiện, tôi đã thực hiện chuỗi thời gian dự báo SKU cho doanh số bán lẻ trong 12 năm nay. Hàng chục ngàn chuỗi thời gian trên hàng trăm hoặc hàng ngàn cửa hàng. Tôi muốn nói rằng chúng tôi đã làm Big Data từ trước khi thuật ngữ này trở nên phổ biến.×

Tôi luôn thấy rằng điều quan trọng nhất là hiểu dữ liệu của bạn . Nếu bạn không hiểu các trình điều khiển chính như Lễ phục sinh hoặc chương trình khuyến mãi, bạn sẽ phải chịu số phận. Thông thường, điều này dẫn đến việc hiểu rõ về doanh nghiệp cụ thể đủ để đặt câu hỏi chính xác và nói những điều chưa biết từ những điều chưa biết .

Khi bạn hiểu dữ liệu của mình, bạn cần phải làm việc để có được dữ liệu sạch . Tôi đã giám sát khá nhiều đàn em và thực tập viên, và một điều họ chưa bao giờ trải nghiệm trong tất cả các lớp thống kê và khoa học dữ liệu của họ là có bao nhiêu dữ liệu có thể có trong dữ liệu bạn có. Sau đó, bạn cần quay trở lại nguồn và cố gắng lấy nó để đưa ra dữ liệu tốt, hoặc cố gắng làm sạch nó, hoặc thậm chí chỉ cần vứt bỏ một số thứ. Thay đổi một hệ thống đang chạy để mang lại dữ liệu tốt hơn có thể khó khăn một cách đáng ngạc nhiên.

Khi bạn hiểu dữ liệu của mình và thực sự có dữ liệu sạch, bạn có thể bắt đầu thay đổi dữ liệu. Thật không may, vào thời điểm này, tôi thường thấy mình hết thời gian và tài nguyên.

Cá nhân tôi là một fan hâm mộ lớn của sự kết hợp mô hình ("xếp chồng"), ít nhất là theo nghĩa trừu tượng , ít kỹ thuật tính năng ưa thích, thường xuyên vượt qua ranh giới vào lãnh thổ - và ngay cả khi mô hình fancier của bạn hoạt động tốt hơn một chút, người ta thường thấy rằng những dự đoán thực sự tồi tệ trở nên tồi tệ hơn với một mô hình phức tạp hơn. Đây là một thỏa thuận trong ngành kinh doanh của tôi. Một dự báo thực sự tồi tệ có thể phá hủy hoàn toàn niềm tin trong toàn bộ hệ thống, vì vậy tính mạnh mẽ là cực kỳ cao trong danh sách ưu tiên của tôi. Số dặm của bạn có thể thay đổi.

Theo kinh nghiệm của tôi, có, kết hợp mô hình có thể cải thiện độ chính xác. Tuy nhiên, lợi ích thực sự lớn được thực hiện với hai bước đầu tiên: hiểu dữ liệu của bạn và làm sạch dữ liệu (hoặc nhận dữ liệu sạch ngay từ đầu).


4
@bendl, YMMV có nghĩa là Số dặm của bạnthể thay đổi . Tuyên bố của câu trước điều này có thể đúng hoặc không đúng hoặc ít hơn trong các trường hợp khác nhau.
Orphevs

2
106

2
Đừng bận tâm lớp học chỉ có kinh nghiệm. Có rất nhiều học viên trong ngành, những người có kinh nghiệm chủ yếu có bối cảnh tỷ lệ nhiễu cao như nhận dạng hình ảnh và cố gắng áp dụng các phương pháp tương tự cho các quy trình xã hội ồn ào như tuyển dụng, vì Chúa.
Cân bằng Brash

2
@Orphevs Nói cách khác, tuyên bố này có thể quá phù hợp với tình huống của tôi và không khái quát tốt. : P
JAD

2
(+1) Liên quan đến vấn đề làm sạch dữ liệu với học sinh mới, điều đáng chú ý là trong quá trình giáo dục chính thức của tôi, thật dễ dàng để nghĩ rằng làm sạch dữ liệu là điều xấu . Đó là, làm sạch dữ liệu có thể ảnh hưởng mạnh đến tỷ lệ lỗi loại I (đặc biệt là nếu có sai lệch trong quy trình làm sạch) và vì vậy chúng tôi đã được dạy về những nguy hiểm của việc làm sạch dữ liệu. Những bài học này không sai, nhưng tôi không nghĩ rằng giáo dục chính thức của tôi nhấn mạnh lợi ích của việc làm sạch dữ liệu, đặc biệt là trong trường hợp mô hình dự đoán.
Vách đá AB

42

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:

  1. Tên tính năng được băm nhân tạo để che giấu ý nghĩa của chúng
  2. 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.
  3. 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 , catboostTensorflow (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.


Lưu ý nhỏ, tôi nghĩ điểm đạn số 2 của bạn bị thiếu ở cuối câu?
mbrig

20

Từ kinh nghiệm của tôi, nhiều dữ liệu và nhiều tính năng quan trọng hơn so với mô hình huyền ảo nhất, xếp chồng nhất, điều chỉnh nhất, có thể đưa ra.

Nhìn vào các cuộc thi quảng cáo trực tuyến đã diễn ra. Các mô hình chiến thắng rất phức tạp, cuối cùng họ mất cả tuần để đào tạo (trên một tập dữ liệu rất nhỏ, so với tiêu chuẩn ngành). Trên hết, dự đoán trong một mô hình xếp chồng dài hơn trong một mô hình tuyến tính đơn giản. Trong cùng một chủ đề, hãy nhớ rằng Netflix không bao giờ sử dụng thuật toán 1M $ của nó vì chi phí kỹ thuật .

Tôi muốn nói rằng các cuộc thi khoa học dữ liệu trực tuyến là một cách tốt để một công ty biết "độ chính xác cao nhất (hoặc bất kỳ số liệu hiệu suất nào) có thể đạt được" bằng cách sử dụng dữ liệu họ thu thập (tại một số thời điểm). Lưu ý rằng đây thực sự là một vấn đề khó giải quyết! Nhưng, trong ngành công nghiệp, kiến ​​thức lĩnh vực, phần cứng và các hạn chế kinh doanh thường không khuyến khích việc sử dụng "mô hình ưa thích".


2
Đúng, đó cũng có thể là trường hợp quá trình thu thập dữ liệu luôn phát triển. Điều đó có nghĩa là các thuật toán hiện đang sử dụng sẽ bị lỗi thời (trên hết chi phí kỹ thuật hoặc thời gian đào tạo như bạn đã chỉ ra). Do đó, các thuật toán đơn giản hơn, nhanh hơn và linh hoạt hơn sẽ là cần thiết.
Tom

4
Tôi đã nghe một trong những điểm chính của bài đăng này được tóm tắt là "lựa chọn biến tốt sẽ luôn vượt qua lựa chọn mô hình tốt '
aginensky

14

Xếp chồng làm tăng đáng kể sự phức tạp và giảm khả năng diễn giải. Các mức tăng thường tương đối nhỏ để biện minh cho nó. Vì vậy, trong khi tập hợp có lẽ được sử dụng rộng rãi (ví dụ XGBoost), tôi nghĩ rằng việc xếp chồng là tương đối hiếm trong công nghiệp.


1
Điểm tốt. Khả năng diễn giải cực kỳ quan trọng trong các ứng dụng của tôi (người quản lý cửa hàng muốn hiểu lý do tại sao dự báo là gì), vì vậy các mô hình khó diễn giải có vấn đề.
S. Kolassa - Tái lập Monica

Cảm ơn những hiểu biết cá nhân Stephan. Trong khi tôi cho rằng khả năng diễn giải bị ảnh hưởng hoặc biến mất khi độ phức tạp của mô hình tăng lên, tôi không nghĩ đến những hạn chế về thời gian mà chắc chắn là cấp bách hơn trong một công ty. Mô hình ưa thích có thể có tỷ lệ tồi tệ nhất (độ chính xác đạt được) / (thời gian sử dụng).
Tom

8

Theo kinh nghiệm của tôi, việc thu thập dữ liệu tốt và các tính năng quan trọng hơn nhiều.

Các khách hàng chúng tôi làm việc cùng thường có rất nhiều dữ liệu và không phải tất cả dữ liệu ở định dạng có thể dễ dàng xuất hoặc dễ làm việc. Lô dữ liệu đầu tiên thường không hữu ích lắm; nhiệm vụ của chúng tôi là làm việc với khách hàng để tìm ra dữ liệu nào chúng tôi sẽ cần để làm cho mô hình trở nên hữu ích hơn. Đây là một quá trình rất lặp đi lặp lại.

Có rất nhiều thử nghiệm đang diễn ra và chúng ta cần các mô hình đó là:

  1. Nhanh chóng đào tạo
  2. Nhanh chóng để dự đoán (Cũng thường là một yêu cầu kinh doanh)
  3. Dễ giải thích

Điểm 3) đặc biệt quan trọng, bởi vì các mô hình dễ diễn giải sẽ dễ giao tiếp với khách hàng hơn và dễ nắm bắt hơn nếu chúng ta đã làm sai điều gì đó.


7

Đây là một cái gì đó không xuất hiện nhiều trên Kaggle:

  • bạn có nhiều biến hơn trong mô hình của mình và
  • mối quan hệ giữa các biến đó và đầu ra càng phức tạp hơn

các nguy cơ hơn bạn sẽ phải đối mặt trong cuộc đời của mô hình đó. Thời gian thường bị đóng băng trong các cuộc thi Kaggle hoặc có một cửa sổ thời gian ngắn trong tương lai nơi các giá trị của bộ kiểm tra xuất hiện. Trong ngành, mô hình đó có thể chạy trong nhiều năm. Và tất cả những gì có thể chỉ là một biến để đi haywire để toàn bộ mô hình của bạn đi vào địa ngục, ngay cả khi nó được xây dựng hoàn hảo. Tôi hiểu điều đó, không ai muốn xem một cuộc thi mà các đối thủ cạnh tranh cân bằng cẩn thận sự phức tạp của mô hình với rủi ro, nhưng ngoài công việc, công việc và chất lượng cuộc sống của bạn sẽ bị ảnh hưởng nếu xảy ra sự cố với mô hình mà bạn phụ trách. Ngay cả những người cực kỳ thông minh cũng không được miễn dịch. Lấy ví dụ, thất bại dự đoán xu hướng dịch cúm của Google . Thế giới đã thay đổi và họ không thấy nó đến.

Đối với câu hỏi của OP, " Nói chung, theo kinh nghiệm của bạn, việc mô hình hóa lạ mắt quan trọng như xếp chồng so với thu thập dữ liệu và nhiều tính năng hơn cho dữ liệu quan trọng như thế nào? " Vâng, tôi chính thức cũ, nhưng câu trả lời của tôi là trừ khi bạn có cơ sở hạ tầng mô hình thực sự mạnh mẽ, tốt hơn là có các mô hình đơn giản, với một bộ biến tối thiểu, trong đó mối quan hệ đầu vào-đầu ra tương đối đơn giản. Nếu một biến hầu như không cải thiện số liệu tổn thất của bạn, hãy bỏ qua nó. Hãy nhớ rằng đó là một công việc. Nhận những cú đá của bạn bên ngoài công việc trong các cuộc thi Kaggle nơi có ưu đãi "đi lớn hoặc về nhà".

Một ngoại lệ sẽ là nếu tình hình kinh doanh đòi hỏi một mức hiệu suất mô hình nhất định, ví dụ nếu công ty của bạn cần phải phù hợp hoặc đánh bại hiệu suất của đối thủ cạnh tranh để đạt được một số lợi thế (có thể là trong tiếp thị). Nhưng khi có mối quan hệ tuyến tính giữa hiệu suất mô hình và lợi nhuận kinh doanh, sự gia tăng độ phức tạp thường không biện minh cho lợi ích tài chính (xem " Netflix không bao giờ sử dụng Thuật toán 1 triệu đô la của nó do chi phí kỹ thuật " - xin lỗi @ RUser4512 vì đã trích dẫn tương tự bài báo). Tuy nhiên, trong một cuộc thi Kaggle, việc tăng thêm có thể giúp bạn tăng hàng trăm cấp bậc khi bạn vượt qua các giải pháp gần đó.


3

Một câu trả lời ngắn, đó là một câu trích dẫn mà tôi thích từ cuốn sách Deep Thinking của Gary Kasparov

Một quy trình thông minh đánh bại kiến ​​thức vượt trội và công nghệ vượt trội

Tôi làm việc chủ yếu với dữ liệu tài chính theo chuỗi thời gian và quá trình thu thập dữ liệu, làm sạch, xử lý dữ liệu và sau đó làm việc với các chủ sở hữu vấn đề để tìm ra những gì họ thực sự muốn làm, sau đó xây dựng các tính năng và mô hình để thử và giải quyết vấn đề và cuối cùng là xem xét lại quá trình để cải thiện cho lần tiếp theo.

Toàn bộ quá trình này lớn hơn tổng của các bộ phận của nó. Tôi có xu hướng đạt được hiệu suất khái quát hóa 'chấp nhận được' với hồi quy tuyến tính / logistic và nói chuyện với các chuyên gia tên miền để tạo ra các tính năng, dành thời gian tốt hơn so với việc dành thời gian phù hợp với mô hình của tôi với dữ liệu tôi có.

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.