I’ve enjoyed participating in Kaggle competitions since 2011. In every competition, I learned new things – new algorithms (Factorization Machine, Follow-the-Regularized-Leader), new tools (Vowpal Wabbit, XGBoost), and/or new domains. It’s been really helpful for me to be up-to-date in the fast evolving fields of Machine Learning and Data Science.
With Kaggler.com, I’d like to share my learning and experiences with others. Hope it can be useful to someone.
Last December, I teamed up with Michael once again to participate in the Deloitte Churn Prediction competition at Kaggle, where to predict which customers will leave an insurance company in the next 12 months.
It was a master competition, which is open to only master level Kagglers (top 0.2% out of 138K competitors), with $70,000 cash prizes for top 3 finishers.
We managed to do well and finished in 4th place out of 37 teams in spite of that we did not have much time due to projects at work and family events (especially for Michael, who became a dad during the competition).
Although we were little short to earn the prize, it was a fun experience working together with Michael, competing with other top competitors across the world, and climbing the leaderboard day by day.
I visualized our 60 day journey during the competition below, and here are some highlights (for us):
- Day 22-35: Dived into the competition, set up the github repo and S3 for collaboration, and climbed up the leaderboard quickly.
- Day 41-45: Second spurt. Dug in GBM and NN models. Michael’s baby girl was born on Day 48.
- Day 53-60: Last spurt. Ensembled all models. Improved our score every day, but didn’t have time to train the best models.
Once clicked the image above, it will show a motion chart where:
- X-axis: Competition day. From day 0 to day 60.
- Y-axis: AUC score.
- Colored circle: Each team. If clicked, it shows which team it represents.
- Right most legend: Competition day. You can drag up and down the number to see the chart on a specific day.
Initial positions of circles show the scores of their first submissions.
We took a rain check on this, but will win next time! 🙂
Recently Prof. Konrad Koerding at Northwestern University asked for an advice on his Facebook for one of his Ph.D student, who studies Computational Neuroscience but wants to pursue his career in Data Science. It reminded me of the time I was looking for such opportunities, and shared my thoughts (now posted on the webpage of his lab here). I decide to post it here too (with a few fixes) so that it can help others.
First, I’d like to say that Data Science is a relatively new field (like Computational Neuroscience), and you don’t need to feel bad to make the transition after your Ph.D. When I was out to the job market, I didn’t have any analytic background at all either.
I started my industrial career at one of analytic consulting companies, Opera Solutions in San Diego, where one of Nicolas‘ friends, Jacob, runs the R&D team of the company. Jacob did his Ph.D under the supervision of Prof. Michael Arbib at University of Southern California in Computational Neuroscience as well. During the interview, I was tested to prove my thought process, basic knowledges in statistics and Machine Learning, and programming, which I’d practiced through out my Ph.D everyday.
So, if he has a good Machine Learning background with programming skills (I’m sure that he does, based on the fact he’s your student), he can be competent to pursue his career in Data Science.
Tools in Data Science
R is similar to MATLAB except that it’s free. It is not a hardcore programming language and doesn’t take much time to learn. It comes with the latest statistical libraries and provides powerful plotting functions. There are many IDEs, which make easy to use R, but my favorite is R Studio. If you run R on the server with R Studio Server, you can access it from anywhere via your web browser, which is really cool. Although native R plotting functions are excellent by themselves, the ggplot2 library provides more eye-catching visualization.
For Python, Numpy + Scipy packages provides similar vector-matrix computation functionalities as MATLAB. For Machine Learning algorithms, you need Scikit-Learn, and for data handling, Pandas will make your life easy. For debugging and prototyping, iPython Notebook is really handy and useful.
SQL is an old technology but still widely used. Most of data are stored in the data warehouse, which can be accessed only via SQL or SQL equivalents (Oracle, Teradata, Netezza, etc.). Postgres and MySQL are powerful yet free, so it’s perfect to practice with.
Hints for Kaggle Data Mining Competitions
Fortunately, I had a chance to work with many of top competitors such as the 1st and 2nd place teams at Netflix competitions, and learn how they do at competitions. Here are some tips I found helpful.
1. Don’t jump into algorithms too fast.
Spend enough time to understand data. Algorithms are important, but no matter how good algorithm you use, garbage-in only leads to garbage-out. Many classification/regression algorithms assume the Gaussian distributed variables, and fail to make good predictions if you provide non-Gaussian distributed variables. So, standardization, normalization, non-linear transformation, discretization, binning are very important.
2. Try different algorithms and blend.
There is no universal optimal algorithm. Most of times (if not all), the winning algorithms are ensembles of many individual models with tens of different algorithms. Combining different kinds of models can improve prediction performance a lot. For individual models, I found Random Forest, Gradient Boosting Machine, Factorization Machine, Neural Network, Support Vector Machine, logistic/linear regression, Naive Bayes, and collaborative filtering are mostly useful. Gradient Boosting Machine and Factorization Machine are often the best individual models.
3. Optimize at last.
Each competition has a different evaluation metric, and optimizing algorithms to do the best for that metric can improve your chance to win. Two most popular metrics are RMSE and AUC (area under the ROC curve). Algorithms optimizing one metric is not the optimal for the other. Many open source algorithm implementations provide only RMSE optimization, so for AUC (or other metric) optimization, you need to implement it by yourself.