An End-to-End AutoML Solution for Tabular Data at KaggleDays
ai.googleblog.com
An End-to-End AutoML Solution for Tabular Data at KaggleDays
1–10 of 38 posts
Re: An End-to-End AutoML Solution for Tabular Data at KaggleDays
#2I'm interested to know how easy this for regular people (software engineers with just a little knowledge of data science) to use.
This part stands out:
"our team spent most of time monitoring jobs and and waiting for them to finish. Our solution for second place on the final leaderboard required 1 hour on 2500 CPUs"
Before I got to this part, I had assumed using AutoML would involve only reformatting the training/validation data, and then letting a single job run its course. Why does something that's 'automatic' need people to run multiple jobs?
Anyone know why they used CPUs instead of GPUs/TPUs? If they're distributing the computation over 100s of CPUs, then it's clear the computations can be done in parallel.
Re: An End-to-End AutoML Solution for Tabular Data at KaggleDays
#3I'm interested to know how easy this for regular people (software engineers with just a little knowledge of data science) to use. This part stands out: "our team spent most of time monitoring jobs and and waiting for them to finish. Our solution for second place on the final leaderboard required 1 hour on 2500 CPUs" Before I got to this part, I had assumed using AutoML would involve only reformatting the training/val…
(I'm a researcher in ML/DL.)
> Anyone know why they used CPUs instead of GPUs/TPUs?
Cost and resource availability.
They're distributing each computation on a different CPU, not distributing each computation over multiple CPUs.
It would be faster to have each computation run on a CPU + GPU, but that would be very very expensive, and hard to schedule.
GPUs/TPUs are also only faster for sufficiently large networks and sufficiently large batch sizes. There's a large fixed cost to send data to/from the CPU, and for smaller networks, it's often not worth running it on a GPU. No idea if this was the case here.
Re: An End-to-End AutoML Solution for Tabular Data at KaggleDays
#4Slightly misleading as it wasn't a traditional competition. The same page shows it at about the 75th percentile in "real" ones.
Re: An End-to-End AutoML Solution for Tabular Data at KaggleDays
#5Does someone know what process they use for feature engineering?
Re: An End-to-End AutoML Solution for Tabular Data at KaggleDays
#6Does someone know what process they use for feature engineering?
from the diagram on that page it looks like it is automated https://2.bp.blogspot.com/-kIut-J_oCmI/XNRSSXIyZ3I/AAAAAAAAE...
Re: An End-to-End AutoML Solution for Tabular Data at KaggleDays
#7Slightly misleading as it wasn't a traditional competition. The same page shows it at about the 75th percentile in "real" ones.
still pretty good for almost zero effort on human side
Re: An End-to-End AutoML Solution for Tabular Data at KaggleDays
#8> Erkut Aykutlug and Mark Peng used XGBoost with creative feature engineering whereas AutoML uses both neural network and gradient boosting tree (TFBT) with automatic feature engineering and hyperparameter tuning.
It's hilarious that gradient boosted descent tree beat Google's fancy AutoML-generated neural networks.
Re: An End-to-End AutoML Solution for Tabular Data at KaggleDays
#9> Erkut Aykutlug and Mark Peng used XGBoost with creative feature engineering whereas AutoML uses both neural network and gradient boosting tree (TFBT) with automatic feature engineering and hyperparameter tuning. It's hilarious that gradient boosted descent tree beat Google's fancy AutoML-generated neural networks.
yes, and i bet they didn't use 2500 CPUs either
Re: An End-to-End AutoML Solution for Tabular Data at KaggleDays
#10Can automl be replicated outside of google cloud?