Nondeterminism's not the problem
16 points by nickmonad
16 points by nickmonad
Is setting the temperature to zero enough to make an LLM deterministic? There's a lot of parallel numericalcomputation that is likely scheduled differently in each execution. Is it possible that operations accumulate different rounding errors, and that those errors compound to produce different results?
Not according to this: https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/
Nice mental model.
Back in the days when natural language translation was based on deterministic dictionaries and rules it was expected that with a long enough set of rules the machine would just translate ideally.
It happens that no matter how much they tried, a true language to language mapping is too subtle, ever changing and culture rooted to be created by hand. So, they gave up and built LLMs.
So fundamentally, compiler is so predictable because we learn to speak its language. While LLMs translate from one to another which is inherently lossy and, as we've just recited, solved with tech invented after the probabilistic turn.
And this is good. One more different tool for different tasks, right?
I guess an extreme determinism-vs-semantics distinguisher would be «SHA512 of each 4KiB block of source, as x86-64 machine code» — absolutely deterministic, absolutely standartised, absolutely semantic-less… LLMs are less deterministic and closer to having semantics than that, and easier to get something somewhat useful, so it's semantics not determinism.
ETA: when I say standartised, I mean compiler behaviour, target is somewhat scary but mostly documented.
Nondeterminism is still the problem, not that prompts lack semantics.
"In the future programmers will only write specs and the LLMs will regenerate the code every time like a compiler." "You don't review the compiler output, why review the LLM output?"
I've made both those arguments against LLMs, and at the time, I was assured by the pro-LLM side that those were silly! No one would ever do that! Yet, it's common for both to be true. But to the second argument, I counter with "You mean you need discipline to review the LLM output? Just like you need discipline to write safe C code?"
Why do you think nondeterminism is still the problem?
It seems to me that your blog post is still expressing a nondeterminism argument, just focusing on the nondeterminism of program behavior as opposed to compiler output.
Sorry, I’m not following. Can you elaborate? I didn’t say anything about making program behavior nondeterministic, only about making compiler output nondeterministic in a way that doesn’t change program behavior (according to the language semantics).
You believe the "real problem" is that LLMs make no promises about a prompt which lacks semantics. Isn't that another way of saying that the prompt does not determine the behavior of the program in a predictable way?
Absolutely, but “determine the behavior of the program in a predictable way” is not the same thing as being deterministic. As I showed in the post, it’s easy to make a deterministic LLM. Prompts to that deterministic LLM still definitely do not determine the behavior of the program in a predictable way.