I have a lot of experience with this problem. The simplest way is via data munging in python/ pandas etc by finding what percent users convert/churn after doing an event N times within the first X days, and all the permutations thereof, using statistical tests around the change point. A more clever way is to use bayesian change point analysis.
The tricky thing is that these insights wind up being kind of obvious from the first analysis. You will find things like "users who use the software more are more likely convert." Other times these types of analysis will confirm what you already know. The tricky thing is making sure you have the right tagging/events and place to make sure you're getting at the right level of detail to get something worthwhile. It's very a much a garbage in garbage out type of thing.
Because the author draws a lot of parallels between computer science majors and physics majors, citing that physics majors are better prepared for the type of work ML requires. I am a physics major turned data scientist, and my argument is that I would have better prepared having been a CS major, given what the majority of my work requires. While in a CS major, a lot of data structures and algorithms haven't changed in 50 years either, you're much more likely to take electives with marketable skills or with up-to-date technologies (distributed systems, operating systems, OO/fp, databases, concurrency) that would've helped me in my day to day more than a math course or too did during my physics degree.
Doesn't really seem like the author spoke to a lot of actual physicists to write this article. Don't get me wrong, physics majors attract a certain type of intellect, but the vast majority of curriculum (quantum, EM, mechanics) are things THAT HAVE BARELY CHANGED IN THE PAST 50 YEARS. Meanwhile, CS majors come out much more prepared and hirable on the job market.
As far as the machine learning market goes, 90% of the projects require software engineering skills, the last 10% requires being able to go underneath the covers of linear algebra libraries, etc.
I just think the whole physics>cs degree for machine learning argument is not totally persuasive given my experience.
And this is thanks to Yann LeCun whose vast experience at Bell Labs experience has shown him how mixing engineer/business requirements/deadlines with research produces shitty results, and so he designed it this way.
I think one of the only companies doing this right, and that has the resources to do this right, is facebook, as they seperate AI research and teams that are focused on putting these things into production (i.e. ML engineers vs Ml researchers). Trying to combine these two things into the same role is resulting in continued confusion and frustration. I like this Stitchfix article as an overview (http://multithreaded.stitchfix.com/blog/2016/03/16/engineers...)
Not dangerous, in my experience. It doesn't take deep theoretical knowledge to provide value (i.e. value to a customer or to a business) through machine learning. Assuming here that one knows how to cross validate, check for overfitting, etc., and not shoot themselves in the foot.
EDIT: Note that it's still EXCEPTIONALLY difficult to provide true, lasting value to a given organization with this stuff and takes years of experience (note I didn't mention deep knowledge and experience with the latest techniques aboard the hype train).
I wish everyone on r/MachineLearning and those preparing for data science careers would read this comment and heed the advice of those of us who have actually spent time on data science teams and have experienced all of this first hand.
I read Murakami books not because they are entirely entertaining WHILE I'm reading them, but because the dream-like memory of the experience sticks in your mind for years.
The good news is you don't have to bookmark this blog because when you're writing scala and googling questions, it's going to come up on page one, because it's one of the best.
Yeah I mostly agree with this. There are some small wins though like how BigML allows you to export random forests into plain text node.js and you can just deploy in shitty php pipelines and boom you're doing machine learning.
I think the best part of this article is the approach to learning new things he presents--going beneath the surface, learning the fundamentals below the “API” layer (abstractly speaking). Really great explanation of that insight!
The part I am having trouble with, with ~5 years of real world data science experience in industry, is the implicit assumption that we all need or want to become good at deep learning.
In my experience, most businesses, at best, are still struggling with overfitting logistic regression in Excel let alone implementing/integrating it with a production code base. And we all know that toy ML models that sit on laptops create ZERO value beyond fodder for Board presentations or moving the CMO's agenda forward.
The fact of the matter is that the vast majority of businesses, with respect to statistics/ML, aren’t doing super duper basic shit (like a random forest microservice that scores some sort of transaction) that might increase some metric 10%. This is due to lack of sophisticated analytics infrastructure/bureaucracy/ lack of talent/ being too scared of statistics. Ultimately when you’re rolling out a machine learning product internally (I’m not talking about Azure/ other aws-model-training-as-a-service type things), the hardest part isn’t: “We need to increase our accuracy by 2% by using Restricted Convolutionallly Recurrent Bayesian Machines!” The hardest part is convincing people you need to integrate a new process into a “production” workflow, and then maintaining that process.