5 ms·
I do a lot of data science work for various business problems. No deep learning image whatevers. Just understanding how processes work and influencing decisions
by spywaregorilla 4y ago
I do a lot of data science work for various business problems. No deep learning image whatevers. Just understanding how processes work and influencing decisions. I can't relate to a lot of what this person is saying.
> Sometimes, I was so scientifically sound that the business lost money. I automated a hyperparameter tuning procedure that split training and validation sets into many folds based on time and picked hyperparameters that averaged best performance across all the sets. I only realized how silly this was in hindsight. I should have taken the hyperparameters that yielded the best model for the latest evaluation set.
What's silly here is thinking that the minor adjustment of hyper parameters from set to set is likely to make a difference. This might hold for some niche deep learning problems but it sounds later on like she isn't doing this. I rarely see an optuna parameter optimization affect the AUC of a model by more than 0.02 vs arbitrary choices. Most business problems tend to be pretty simple. I just can't imagine this parameter choice makes a difference.
> I have done enough research on production ML now to know that it pays to simply overfit to the most recent data and constantly retrain. Successful companies do this.
Nonsense. Dangerous nonsense.
> It puzzles me when people say that small companies can’t retrain every day because they don’t have FAANG-style budgets. It costs a few dollars, at best, to retrain many xgboost or scikit-learn models. Most models are not large language models. I learned this circuitously, while doing research in ML monitoring.
This is accurate. I find it weird that people feel the need to retrain models so frequently though. Context matters I guess. But then they talk about data drift...
> Anecdotes like this really get me in a tizzy. I think it’s because what I thought were important and interesting problems are now, sadly, only interesting. Researchers think distribution shift is very important, but model performance problems that stem from natural distribution shift suddenly vanish with retraining.
It sounds like this person is just retraining their models at a high frequency until a hyper parameter search randomly produces something that looks good on an evaluation set. I don't see any evidence of them ACTUALLY EVALUATING THEIR PERFORMANCE. The missing piece to all of this is taking the predictions they made with this process and seeing how it compared to the unseen future outcomes in retrospect. If you think you're fine because you make a new model every day that works for yesterday's data, which they openly imply is overfit to that period, you might just be making a new mistake every day. A good AUC or R2 on your evaluation set doesn't guarantee that it'll be good on new data.
> I had a hard time finding the gold nugget in data drift, the practical problem. Now it seems obvious: data and engineering issues—instances of sudden drifts—trigger model performance drops. Maybe yesterday’s job to generate content-related features failed, so we were stuck with old content-related features. Maybe a source of data was corrupted, so a bunch of features became null-valued.
What? This seems pretty crazy to me. You should have alarm bells built in that freak out if important features are turning up null or corrupted. This person seems to have no idea if their model is working! They just know it worked for yesterday. They allude to doing this later on, but even then... broken data pipelines is not what people typically mean by data drift.
I see no discussion of real performance evaluation, understanding how the models work, or how to make real use of the model outputs.
- toto444 4y agoThanks for writing this. I had it on my mind but am usually too lazy to write long comments. I am a data scientist and I do some ML at work that is actually core the business (Learn To Rank for an aggregator). Whenever I read some article about data science on HN I can never relate to what they say. 'Data drift' sounds like some BS one tells their manager when they don't understand what's really happening. > I have done enough research on production ML now to know that it pays to simply overfit to the most recent data and constantly retrain. Successful companies do this. As long as they are not AB tested statement likes these are worthless. I recently tried updating a model daily vs weekly and it made aboslutely no difference so why would I care ? Anyway, thanks for your comment I know I'm not alone.
- shreya_shankar 4y agoOriginal post author here. Thanks for taking the time to write this---it made me realize that I should have discussed the nature of tasks I was working with in my post, especially because different tasks/datasets have different behaviors under the same model choices. The overfitting phenomenon I've seen at the companies I work/have worked with are all doing some kind of ranking. None use auc to evaluate---in fact, I don't see many production models evaluated with auc because usually some threshold is fixed before deployment, or the client has their own threshold they will act on. Re: hparamaters varying the metric---a point on the ROC can change a lot while the auc stays relatively the same, especially in class imbalance settings. Re data validation---at large companies with 10s-100s of models with hundreds of thousands of features, often data gets corrupted. Alarm bells do go off but there is alarm fatigue. Furthermore, not all Task MLEs are Platform MLEs and vice versa...a lot of people have to build tools to monitor ML pipelines they don't own. Anyways I really appreciate your comment & it made me realize how ML people have vastly different experiences. I will clarify assumptions on the task & evaluation next time I write :)
- spywaregorilla 4y agoHey, cool to get a response. I'm never in the space of creating tens, let alone hundreds of different models. I'm curious what this means > usually some threshold is fixed before deployment, or the client has their own threshold they will act on. Why would anyone do this? I mean I don't care too much about which metrics they choose to use but this seems like a really weird choice to me as its blind to any of the typical confusion matrix outcomes you see in the model validation. I am very curious to know if you track model performance on new data made in retrospect. The frequent retraining is foreign to me. I get that its not hard to do but I would feel really uncomfortable if my models changed in a meaningful way from day to day. Maybe it's just because my models tend to deal with the outcomes of natural physical processes