talk: competitive data science (i)

2019/09/25

Đây là nội dung bài talk của mình trong buổi meetup Trà đá 2^2, 25/08/2018, slide.


Trang 2: Phần lớn mọi người hẳn cũng khá quen thuộc với các sân chơi lập trình thi đấu, “competitive programming”, như Codeforces, IOI, hay ACM ICPC. “Competitive data science” (CDS) là một sân chơi có dạng như sau:


Trang 3 - 4: Ở một số platform như Kaggle, kết quả được quyết định như sau:

  1. Kaggle chia Test set thành hai phần, Public Test setPrivate Test set.

  2. Trong quá trình thi, bạn sẽ được biết “độ tốt” của mô hình, dựa vào hàm đánh giá, qua việc so sánh nhãn được dự đoán với nhãn thật sự của Public test set.

  3. Kết quả của cuộc thi sẽ được tính trên Private Test set, được công bố sau khi phần nộp bài kết thúc.

Hiển nhiên, việc tồn tại một quá trình “feedback” độ tốt của dự đoán trên tập Public Test set sau các lần nộp dự đoán sẽ dẫn đến việc để “lộ” thông tin về tập này. Một bài toán thú vị là: Làm sao để biết được phần nào trong Test set thuộc về Public, phần nào thuộc về Private? Thông thường, một cuộc thi trên Kaggle sẽ diễn ra trong khoảng 1-3 tháng, và số lần được nộp tối đa mỗi ngày là khoảng 5 lần, với bộ Test set có độ lớn trung bình khoảng vài trăm ngàn điểm dữ liệu.

Claim (with detailed analysis coming soon™): Trong “một số trường hợp”, việc được biết mô hình của mình có độ tốt như thế nào trên phần Public test set, một thí sinh, sau một số “ít” lần nộp dự đoán (ít hơn giới hạn của kỳ thi):

  1. Có thể biết được nhãn chính xác của tập Public test set

  2. Có thể biết được dữ liệu nào nằm trên tập Public, dữ liệu nào nằm trên tập Private

  3. Có thể có được một bộ Augmented training set, bao gồm Training set ban đầu và Public Test set và nhãn mới có được của tập này

Với các cuộc thi có độ cạnh tranh, việc thí sinh đoán biết được nhãn của Public test set để có thêm dữ liệu để huấn luyện là một ưu thế không nhỏ, và lợi dụng ưu thế này trực tiếp sẽ làm mất đi tính công bằng của kỳ thi. Về sau này, các cuộc thi trên Kaggle thường đi theo các hướng như sau:

  1. Hoặc là dùng “closed” Test set và buộc phải nộp chương trình: thí sinh được biết Training set, nhưng phải nộp chương trình, Kaggle dùng chương trình chạy mô hình và trả về kết quả.

  2. Hoặc là sử dụng các hàm đánh giá phức tạp: việc lộ thông tin thường đến từ các một lớp các hàm đánh giá đơn giản như accuaracy. Tuy nhiên, do vẫn có một quá trình feedback nên vẫn khó tránh khỏi việc bị lộ thông tin.


Trang 5 - 6: Thường thì các kỳ thi trên Kaggle sẽ được chia một cách “thô thiển” thành hai dạng: Dạng có nhiều dữ liệu và dạng có ít dữ liệu:


Trang 7: Bản thân việc tham dự các kỳ thi như thế này cũng là một bài toán tối ưu với mình.

Mục tiêu: Làm sao để có được kết quả càng cao càng tốt (hiển nhiên rồi).

Ràng buộc:

  1. Mình không có nhiều thời gian, không hợp với các cuộc thi ít dữ liệu, cần nhiều thời gian tìm hiểu để “feature engineering”.

  2. Mình không có máy móc với khả năng tính toán cao (lúc đấy mình chỉ có Macbook 2013, không có GPU)


Trang 8: Cuối cùng cũng có một kỳ thi như vậy, đến từ numer.ai.

Đây là một quỹ đầu tư, đến từ một đồng sáng lập của Renaissance Technologies (RenTec). Trong giới tài chính, RenTec là một huyền thoại sống và cũng rất “huyền bí”. Nói về RenTec thì không hết chuyện để kể. Người sáng lập RenTec làm Vật lý lý thuyết, bị chính phủ đuổi việc, về mở một quỹ đầu tư chỉ tuyển toàn dân Toán và Lý, và vô địch thiên hạ.

numer.ai nhìn thấy một khoảng cách lớn trong việc ứng dụng Machine learning vào tài chính, đó là dữ liệu. Phần lớn sự phát triển của Machine learning trong một thời gian rất ngắn gần đây dựa vào tính “mở” của cộng đồng:

  1. Các bộ dữ liệu mở (MNIST, ImageNet, etc.)

  2. Các khoá học miễn phí trực tuyến (Coursera, edX, Stanford Lagunita, etc.)

  3. Các quyển sách được tác giả mở trên internet cho mọi người đều có thể truy cập được (The Elements of Statistical learning, Deep learning, etc.)

  4. Các dự án phần mềm mã nguồn mở (Numpy/Scipy, ScikitLearn, Tensorflow, (Py)Torch, etc.)

Trong ngành tài chính thì dữ liệu phải mua, và dữ liệu có chất lượng thì rất đắt. numer.ai cho rằng chính điều này đã kéo lùi việc có được đột phá trong việc ứng dụng Machine learning vào ngành.

Họ tổ chức một cuộc thi hằng tuần bằng dữ liệu của họ. Điều thú vị là: Đây không phải là dạng dữ liệu tường minh, mà đã được “mã hoá”, tức là nếu chỉ nhìn vào dữ liệu thì bạn không biết được ý nghĩa của nó là gì: Các cột đã được chuyển hoá, sao cho phân bố cuối cùng trong từng cột dạng Uniform(0, 1).

Claim của numer.ai: Việc mã hoá như vậy một mặt bảo vệ được dữ liệu của họ, những vẫn có thể ứng dụng các mô hình Machine learning trên đó (mình khá hoài nghi về cái claim này).


Trang 9:

Một điểm hay với mình là do đây là cuộc thi theo tuần, nên thời gian để người chơi tập trung cho cuộc thi cũng không cần phải là quá nhiều, và cơ cấu giải thưởng cũng khá là “thoáng”: Top 100 người có thành tích tốt trong tuần sẽ được thưởng, với các mức thưởng khác nhau, tuỳ thuộc vào thứ hạng.

Claim của numer.ai: Họ không cần mô hình, họ chỉ cần kết quả của mô hình để có thể có lợi nhuận trên thị trường. Do vậy, người chơi chỉ phải nộp dự đoán của nhãn cho Test set.

Cũng nói thêm là với cơ cấu giải thưởng khá rộng và họ lại không đòi hỏi chương trình của mô hình, một người có thể “clone” nhiều tài khoản khác nhau để nộp nhiều lần cho cùng một dự đoán, cùng sinh ra từ một mô hình tốt, để có thể giành được nhiều giải thưởng hơn. Điều này cũng dẫn đến sự không công bằng. Chính vì lẽ đó nên numer.ai sử dụng metric quan tâm đến sự “đa dạng” của mô hình: Một lần nộp A xuất hiện sau lần nộp B, nếu như khá “tương đồng” với lần nộp B, thì thứ hạng của lần nộp A sẽ thấp hơn lần nộp B, nếu như các yếu tố khác là như nhau.

Bản thân mình nghĩ việc numer.ai khuyến khích việc người chơi sử dụng đa dạng các mô hình, một mặt vừa đảm bảo tính công bằng cho cuộc thi, mặt khác, quan trọng hơn, liên quan đến bài toán dưới đây.

Câu hỏi phỏng vấn: Vì sao việc sử dụng các mô hình khác nhau về bản chất (diversity) khi ensemble lại có thể giảm bias và giảm error cho mô hình cuối cùng?


Trang 12:

Điều tiên quyết ở kỳ thi này là mô hình phải được huấn luyện đủ nhanh, và ít nhất là trong một tuần phải đưa ra được vài lần dự đoán.

Mô hình cũng phải có tính khái quát cao, do trong thực tế cuộc thi thì phân bố trên Training set có vẻ khá “khác” với Test set. Đây cũng là một tình huống thường gặp trong thực tế.

Câu hỏi phỏng vấn: Nếu Training set có phân bố khác xa Test set, dẫn đến việc các phương pháp validation truyền thống như k-fold cross validation không hiệu quả, hướng giải quyết của bạn là gì?

Cũng bởi thế, các phương pháp “feature engineering” mình áp dụng trong cuộc thi này khá “phổ quát”, như t-sne, PCA, etc. Với thực tế là dữ liệu đã được làm nhiễu/áp một lớp mã hoá, cũng “khó” có cách có được một bộ “handcrafted features” đủ tốt.

Tuy nhiên, vẫn có những người chơi khác, như họ claim, rằng từ dữ liệu mã hoá thế này, vẫn có thể map nó với dữ liệu thực tế trên thị trường chứng khoán. Mình không có dữ liệu từ thị trường để kiểm tra ¯\_(ツ)_/¯

Chiến thuật của mình là sử dụng nhiều mô hình khác nhau, rồi ensemble chúng để có một mô hình tốt hơn.

Nhưng nếu chỉ nói về xgboost và việc chạy t-sne thế nào trên CPU cho hiệu quả thì hơi.. chán, vì trên các bài viết của những người chiến thắng trên Kaggle đã bàn về nó rất nhiều rồi. Sau đây, mình sẽ bàn về một trong số những mô hình cho mình kết quả tốt nhất trong kỳ thi đó, và đã kiếm về cho mình một món tiền X chữ số (shameless self-promotion).


Trang 13: Let’s talk Deep learning!