* The errors ML systems make depend on the deployment data distribution, and this is almost never the same as your original validation data set.
* We should not deploy an ML system unless we understand and have quantified the errors it will make on the type of data we will use it with, and what the costs of those error are.
The above are part of the reason we do not yet have self-driving cars.
2/?

Why deploying large language models (LLMs) "in the wild" makes me uncomfortable:
* We have not thought enough about or quantified the types of errors that will be made, or their ramifications.
* Partly, this is because LLMs are trained using unsupervised learning. The relationship between what they are optimized for and what we actually want to use them for is unknown.
3/?

There are really nice benchmarks for LLMs that are trying to remedy this (e.g. https://gluebenchmark.com/tasks), but they are tiny in comparison to the amount of data wrangling done for training LLMs, and perhaps not representative of whatever crazy idea VCs have for LLMs.
4/4

@kristinmbranson Speaking with my engineering hat on, I like to think in terms of problem statement -> understand problem -> design appropriate solution.

Of course, that approach depends a lot on understanding the characteristics and best practices of various known solutions.

Do you think we're at the stage with LLMs that we can say things like: "These are the problems they are good at solving, and here are the best practices you should use when deploying."? Or is still too early?