An open question these days is what the role of task-specific / finetuned models will be. I can only think of three scenarios where it makes sense to work on task-specific models.
The first scenario is if you have private (e.g., legal, medical, business) data not found on the web that you want the model to know. And you have to have a decent amount of it—if it’s only a little bit, it'll be much easier to put it into a long-context model or retrieve it. Even if the best models today can’t do long-context or retrieval well, they probably will be able to in a few years.
The second scenario is if you are doing a domain-specific task and care a lot about doing it with low latency or low cost. For example, codex is a great use case, since you only need the coding ability and you want people to be able to use it at scale, quickly and cheaply. This makes sense because if you’re only doing one domain, you don’t need as many model parameters as general models do (less memorization required).
These two scenarios make sense because emergent performance on private tasks is not achievable by scaling (scenario 1), and scenario 2 by definition doesn’t want larger models.
The final scenario to use task-specific models is if you want to get the best possible performance on a task and can easily ride the wave of the next GPT-N+1 model (e.g., you are using a finetuning API from another provider, which will presumably get better as the provider trains better models).
In most other scenarios, it seems dangerous to focus on domain-specific models. For example, let’s say you train a model on some specific task and it beats GPT-4 this year. That is satisfying in the short run. However, with every GPT-n+1 could potentially beat your task-specific model due to scale enabling better reasoning, better access to tail knowledge, etc. We have seen this time and time again in the past (e.g., PubMedGPT and GPT-3 finetuned on GSM8K surpassed by PaLM). To me this is an obvious instance of The Bitter Lesson but would love to hear if I’ve missed anything.