Comment by baron3dl
7 hours ago
Sometimes when I get frustrated reading Opus/Fable 5+ output I pause my rage out briefly to wonder if it's because I'm just too dumb for the model or if the model is just terrible at English.
I'm not sure that telling it to "try explaining that again, simply and briefly" is helping my ego.
It's often simply misleading / bad writing. Here's one I just got about some crashes:
"If the crashes stop, the factory overclock is marginal; run a small negative offset."
This looks like it's saying: "If the crashes stop then we know the factory overclock is marginal." (This makes no sense.)
What it's trying to say is: "If the crashes stop then we can run a small negative offset, because the factory overlock is marginal."
What I would write: "If the crashes stop, we can avoid crashes by underclocking slightly. The speed difference between that and factory clock is marginal."
I'm guessing it's because the way the first one was written looks real smart and sophisticated, which I'm presuming the models are rewarded for, especially when they're fed all kinds of PhD papers and so on as high quality, high weight data
Is it possible that the first message is more information dense/less likely to be ambiguous than the latter? It’s clearly being selected for for some reason, maybe it’s an artifact of the tokenizer or specific training data, but I don’t know. If the use of jargon was complete cruft, I would expect it to be selected against during reinforcement learning
1 reply →
I suspect this happens due to optimising for reasoning... if you insert a few words, it will suddenly start to make more sense.
"If the crashes stop, (that means) the factory overclock is marginal; (so) run a small negative offset. (to confirm this hypothesis)"
The core thought is basically avoid crashes -> caused by marginal overclock -> apply small -offset to test. Which is exactly the order the sentence is in :P
I thought it meant "the factory overclock is marginal" in the sense of "borderline unstable"?
Same. I read it as "if the crashes stop [ when we test by reducing the clock ] then we know that the overclock applied by the factory is marginal [ ie it barely passed QC or maybe there wasn't proper QC to begin with ] so running with a small negative offset [ ie what we just tested ] can be expected to fix the problem for good". No idea if my reading is right given all the context I'm missing. Either way it's absolutely shit writing in the same way that golfed code is shit code (except when participating in a code golf competition).
This is my read, too.
I wonder if this is a result of them trying to cut token consumption by summarizing their RL training data, or maybe it's from how they anonymize user data for training.
Marginal - definition 2a: of, relating to, or situated at a margin or border.
Succinct and precise; a well crafted sentence. A marginal OC results in unpredictable crashes and can be corrected with a small offset; marginality describes the behavior and explains the solution.
Inscrutable clues casually conveyed can now be readily explained, at least, unlike the training data of [silence]. Brevity is the soul of wit, but perhaps also exasperated confusion.
I just started to use GPT models. it's incredible how this seemingly is not a problem in the OpenAI world
it's absolutely not just you, the text it produces causes my blood pressure to go up.
I'm constantly using the "Extract this in basic technical terms, be succinct and assume the reader has technical knowledge"."
Because good lord, does claude waffle when left to its own devices.
This is actually a new skill I've been working on. Learning how to elicit concise and simple speech from models (and from people to!).
Whenever I come to a wall of complicated text I kick into gear and think through getting it to distill this into the high-level useful bits that I actually need to know.
I guess I could create an actual agent skill for this :) And next-gen models might eventually be trained to simplify their output themselves...
too.
(sorry)