Comment by david-gpu
1 day ago
1. Compilation has typically not been deterministic. Even within the same exact compiler tool chain version.
2. Compilers and building tool chains change all the time. CI and automated testing catch any regressions. Tye same can be done with LLMs.
3. LLM code generation, with some work, can be made deterministic, if that mattered to somebody.
The amount of non-determinism in compiler and LLM output is so vast that even comparing them is silly.
Tests are not a one time thing. They need to be maintained, and if you use same LLM to do it, it will happily delete failing ones, so better use a seaparate agent, and be prepared for the bill.
> The amount of non-determinism in compiler and LLM output is so vast that even comparing them is silly.
What is that supposed to mean? Yes, LLMs are often considered to be non-deterministic because, in practice, they rely on systems with unstable floating point rounding. Likewise, compilers are often considered non-deterministic because, in practice, they often rely on systems with unstable thread execution order. Of course, those are both just implementation details. You can, albeit at the cost of things like performance, remove the hidden inputs. Computers are fundamentally deterministic! Anything that runs on computers must also be deterministic.
If you were to run a compiler or LLM on a Turing machine, they would both be 100% perfectly deterministic. We only see them as being non-deterministic because, in the real world, we run them on hardware that plays tricks with computation by introducing inputs via hidden side channels. But, again, those are implementation details. Compilers and LLMs are not defined by any particular implementation.
Nonsense. The "weights" in "models" refer to probabilities.
Even the implicit claim that they could deterministically produce "the" correct answer with 100% certainty doesn't withstand any scrutiny.
Nevermind problems posed in English prose, complicated or philosophical questions. Is the correct answer to 2+2 four, or is it 1+3? When you you have 2 apples and give me one apple, how many apples do you have now; one, or half as many as before? What is the correct answer? Without a spaghetti of arbitrary axioms in the system prompt? Even if you come up with something clever about apples, it even fails at "when is your birthday". When it is today, should I say "today" or say the date? Not even God could decide that.
Arguably, the specifications for a compiler is also such a mess of axioms, and you can split hairs and say "it's all random anyway", but you'll still use a seatbelt instead of silly string, so what gives?
For compilers, give or take, there is a correct output for a given input (under which I'll include config, options, the targeted architecture, whatever). With LLM there is no such thing even if you do infinite mental backflips, and there won't be, because there can't be. Even if you could perfect the compilers that are needed to make the software that trains and drives LLM deterministic, you cannot make LLM fully deterministic without making them not an LLM.
If you can find a way to encode what a compiler would do to programs into the weights of a model so that produces the output of a compiler that would be a cool and completely useless feat, because it would probably be bigger, slower and impossible to reason about. But it would still be cool and I would still try it out.
I am not suggesting the use of LLMs to replace compilers. I am proposing LLMs transforming detailed text-based specifications and design documents into code.
As for your understanding of how LLMs and compilers work, it does not match my experience working on either one, back in the day. I humbly suggest reading some of the literature on reproducible builds, as well as the conditions under which LLM inference is/isn't deterministic, as it is more complex than most people understand.
> Nonsense. The "weights" in "models" refer to probabilities.
No they don't. They refer to the weights used for weighted sums. The weights don't have to even between 0 and 1.