Thank you for sharing this guide. I’m trying to understand how much we know about the typical thought process that is generating some of the common mistakes. I can’t speak to the specific motivations or goals of any individual in particular, but I’d speculate that if smart people are consistently appearing to make the same errors then there may be something more interesting going on that we can learn from.
I agree that avoiding compute-heavy steps is a good idea for those without a lot of prior ML experience. Even if you have (or expect to acquire) the resources to afford investing in a large training run, not knowing what you’re doing almost always incurs a significant cost overhead, and the long iteration cycles tend to bottleneck the number of experiments you can run during a sprint. However everyone knows that big GPU clusters can be quite challenging to work with from an engineering perspective and so experience doing e.g multi-gpu SFT tends to be helpful for developing tacit knowledge and skillsets which are highly sought after in industry roles. [1]
It’s less clear to me why someone would try to build on a highly technical method when they don’t meet the prerequisites to fully understand a paper’s approach and limitations. It could be driven by higher than average levels of self-belief and risk-tolerance, since some level of overconfidence can lead to better outcomes and faster growth than perfect calibration. The people who are equipped to properly evaluate and review complex work tend to be in short supply, but are disproportionately responsible for the most popular works, and it seems reasonable for someone who derives inspiration from a certain research direction to be naively excited about contributing to it. There’s a power law distribution in the public attention that each paper receives, with a tendency for more eyeballs to be placed on works that push the envelope of what’s possible in the field, which contradicts the intuition that rarity and prevalence should be inversely proportional.
It would be understandable if people who are primarily consumers of good solutions to hard technical problems have a tendency to underestimate how easy it is to generate them. And the best attempt of someone whose foundation isn’t quite there yet can look like cargo culting on surface level features instead of a reasonable extension to prior work. But I’m not satisfied with this explanation and would be interested in hearing other perspectives on why people tend to become susceptible to this category of errors.
One possible factor could be that in certain circles taking a pile of cash and setting it on fire makes you cool because it shows that you can do things which cost a lot of money, but thankfully the vast majority of researchers I know are quite responsible and strive to minimize waste, so I don’t think that’s what’s going on here. I do think it means we should be careful to mentally separate “startup founder with access to impressive million dollar cluster” from “person that is qualified to run and debug jobs on impressive million dollar cluster”.
Thank you for sharing this guide. I’m trying to understand how much we know about the typical thought process that is generating some of the common mistakes. I can’t speak to the specific motivations or goals of any individual in particular, but I’d speculate that if smart people are consistently appearing to make the same errors then there may be something more interesting going on that we can learn from.
I agree that avoiding compute-heavy steps is a good idea for those without a lot of prior ML experience. Even if you have (or expect to acquire) the resources to afford investing in a large training run, not knowing what you’re doing almost always incurs a significant cost overhead, and the long iteration cycles tend to bottleneck the number of experiments you can run during a sprint. However everyone knows that big GPU clusters can be quite challenging to work with from an engineering perspective and so experience doing e.g multi-gpu SFT tends to be helpful for developing tacit knowledge and skillsets which are highly sought after in industry roles. [1]
It’s less clear to me why someone would try to build on a highly technical method when they don’t meet the prerequisites to fully understand a paper’s approach and limitations. It could be driven by higher than average levels of self-belief and risk-tolerance, since some level of overconfidence can lead to better outcomes and faster growth than perfect calibration. The people who are equipped to properly evaluate and review complex work tend to be in short supply, but are disproportionately responsible for the most popular works, and it seems reasonable for someone who derives inspiration from a certain research direction to be naively excited about contributing to it. There’s a power law distribution in the public attention that each paper receives, with a tendency for more eyeballs to be placed on works that push the envelope of what’s possible in the field, which contradicts the intuition that rarity and prevalence should be inversely proportional.
It would be understandable if people who are primarily consumers of good solutions to hard technical problems have a tendency to underestimate how easy it is to generate them. And the best attempt of someone whose foundation isn’t quite there yet can look like cargo culting on surface level features instead of a reasonable extension to prior work. But I’m not satisfied with this explanation and would be interested in hearing other perspectives on why people tend to become susceptible to this category of errors.
One possible factor could be that in certain circles taking a pile of cash and setting it on fire makes you cool because it shows that you can do things which cost a lot of money, but thankfully the vast majority of researchers I know are quite responsible and strive to minimize waste, so I don’t think that’s what’s going on here. I do think it means we should be careful to mentally separate “startup founder with access to impressive million dollar cluster” from “person that is qualified to run and debug jobs on impressive million dollar cluster”.