One thing that's easy to miss about performance is that it depends on framing.
An example I like to give: optimizing a data processing program's runtime by 5x is obviously 5x speedup for everyone. But if, for some reason[0], this means it crashes and restarts more often, it stops looking like this to end users. If every restart means it needs to start from scratch, and it restarts 10 times on average now where it didn't restart before, the 5x speedup suddenly looks like 2x slowdown to end user.
In this sense, LLMs are already much more efficient than most CLI tools, by a combination of:
- User not having to remember the exact invocation, or even the name of the CLI tools
- LLM being able to run the CLI tools and chain them on its own
- LLM being able to self-correct in case it got things wrong, or when actual output show that user's idea was right, but the instructions were wrong
Prompting "okay, list those processes sorted by runtime and match them against these output files" is both faster to type than the actual commands, it also end-to-end completes much faster than doing it by hand.
--
[0] - And I don't mean a bug. Say it's some batch processing run on a cluster with aggressive resource usage management; 5x speedup means it runs much hotter than before, which may put it on the top of "kill list" for when the cluster managing code needs to free up some resources.
Electron just makes it easy, but it's long been the status quo. GP was right to mention branding. That's the driver.
There's a document I've seen floating on the Interwebz, a copy of HIG for ancient Windows version, I think one of the 3.x ones. I distinctly remember it for having a note somewhere basically recognizing that giving some of the theming/customization options in the API is a bad idea, but customers want to brand their apps, so what can one do.
This is one of the problems that I can't see being solved, because it's purely social - we'd have to have someone go and tell every entrepreneur out there that branding is a fucking stupid idea and you should not do it, and actually be taken seriously.
I can't even imagine a world in which that is possible.
Instinctive is a good way to describe it compared to generative LLMs. Jev gives you one instant answer, fast and usually correct but without nuance or any explanation. Human instincts work the same way.
You're describing external aspects but to me, "instinct" says much more about internal processes than the properties you mentioned, and I haven't seen anything that tells me how these models draw on anything similar to these internal processes to generate their outputs (at least not more than generic LLMs do)
I think System 1 is a great term. System 1 is fast, intuitive, and automatic. It describes decision-making that happens without explicit reasoning or deliberation. System 2 is the opposite: it's the more deliberate, "executive functioning" side of cognition -- the part that reasons through a problem before arriving at an answer. That's also what state-of-the-art LLMs do before they respond. Jev doesn’t do that kind of reasoning. It just decides.
I don't like anthropomorphizing terminology applied to LLMs, in general, so I kind of object to it on that grounds, rather than whether System 1 means "fast".
so whats the difference between this and a non-reasoning LLM, or just any generic classifier method that necessitates a new term? there is nothing more intuitive or automatic about jev or this than any of the other currently used AI models
The difference is the the joint embedding of actions and state which are fined tuned for certain outcomes. The bulk of the weights are just a forward pass on an LLM (Nemotron).
is that how jev works too? how do these differences make those approaches more "instinctive and emotional"? I know they're different on a technical level, I'm asking which characteristic difference necessitates the use of this loaded term from pop psych
It is. Processing tokens is the only time model has to do computation, and if you ask it a tough problem, there is some minimal amount of computation it needs to perform to process and solve it - pre-CoT in particular you could guarantee failure by forcing model to be concise, and thus giving it less computational budget than necessary to compute the answer.
(This is I think where people parroting out "stochastic parrot" are stuck even today - not realizing that "predicting next tokens" is hiding arbitrary computation underneath, with token stream acting as input and clock signal...)
Well, the question is, is it more like iPhone and book of engineers (one of the replies to your comment), or more like Astra and Enigma story from ~last 2 days here?
In the latter, there were comments like yours too, but there it turned out the people in question said so directly: they just vaguely pointed a model at Enigma ciphers and asked to maybe try and solve some unsolved ones, and with no further material input, the model went and did. In that case, it's absolutely fair to say, "LLM did it" and "humans not involved".
For the same reason I find it dishonest when math papers that relied heavily on AI only list a human as the author, even if the human didn't do much more than suggesting which problem the LLM should solve.
Copper price more than proximity. People don't strip wires for shits and giggles, they do it to sell the metal.
Bet you if copper price suddenly went up 10x, those ancient telegraph lines would disappear very quickly, one way or another (turns out, "criminals" and "junkies" and "entrepreneurs" are driven by similar incentives, they just sit at different points of the cost/risk tradeoff spectrum).
Hate to be cynical, but going by the stories a doctor in my personal circles tells me, "talked to me for an hour, ordered a ton of tests" could be more about billing the national healthcare fund for many tests, that may not be most useful, but carry best margins for the facility.
In my country, there's a big feud between cardiologists and radiologists right now, big enough to be a regular topic in national media. Inside sources tell me it has nothing to do with quality of care, and is entirely about the march of technology allowing radiologists to perform some diagnostics that previously required cardiological procedures, and those procedures happened to be the major funding source for the cardiology departments.
Which is why we need more doctors trained more cheaply who are earning less money. They have far too much labor power currently for a role that increasingly can be fulfilled by a pure “technician” style expertise.
Yes, but it's erupting now that it killed a golden goose for the "real doctors", and the problem here is not along the doctor/technician lines (radiology has doctors too), but along the specialty/hospital department divide, because those are effectively separate business units.
An example I like to give: optimizing a data processing program's runtime by 5x is obviously 5x speedup for everyone. But if, for some reason[0], this means it crashes and restarts more often, it stops looking like this to end users. If every restart means it needs to start from scratch, and it restarts 10 times on average now where it didn't restart before, the 5x speedup suddenly looks like 2x slowdown to end user.
In this sense, LLMs are already much more efficient than most CLI tools, by a combination of:
- User not having to remember the exact invocation, or even the name of the CLI tools
- LLM being able to run the CLI tools and chain them on its own
- LLM being able to self-correct in case it got things wrong, or when actual output show that user's idea was right, but the instructions were wrong
Prompting "okay, list those processes sorted by runtime and match them against these output files" is both faster to type than the actual commands, it also end-to-end completes much faster than doing it by hand.
--
[0] - And I don't mean a bug. Say it's some batch processing run on a cluster with aggressive resource usage management; 5x speedup means it runs much hotter than before, which may put it on the top of "kill list" for when the cluster managing code needs to free up some resources.
reply