A few things here, one is that getting them mixed up isn't the same as them ending up in the wrong place. Looking fruitlessly for a missing user with id 9287dfn9384f that has some support ticket only to find out later that this was their order ID and the wrong thing was put in a form (particularly if you ask users for something, I see 4 different IDs floating around, which is my customer/user/product/order/shipping id?). If the user id is "order_1239123" I know to go and look at the orders table, not "dance around all tables trying to find what on earth the id could relate to".
However there are two other ways this happens which come to mind:
1. HTTP API calls. There's a whole untyped layer going on here. You could have a PUT to set some content, and create a new entry if one doesn't exist - there's a place for a call to go to the wrong place but succeed. If two entities have the same structure but are different things this can be harder to spot.
2. Manual entry. This is the bigger one. Vast amounts of workflows have somewhere that a human does a thing, and that will go wrong at times. An excel file uploaded to the wrong place, the wrong header, the wrong bit typed on a form.
A counting up of numbers is a simple ID but awful for both of these, because now you have overlapping IDs across systems. Having larger random IDs takes you out of this risky area because at some point the chance of a collision is so low as to be not worth considering, however even small IDs with a prefix like "customer_001" and "order_001" quickly removes a source of problems.
I'm not saying any of this is the only solution, or that there aren't better ones, but I can see places where this kind of thing can easily happen in the real world and "prefix the ids with a type" is a very small and simple change that can help.
I would also note that this then becomes a front facing thing that ties you into something as well though, and not all types are as nice to make public.
He's not talking about intelligence though, he's saying it has no knowledge or understanding, whereas something like a decision tree or neural net object recognition model does.
He's not comparing them to humans, he attributes knowledge/understanding (enough to pass his bar for "is AI") to yolov5 models, xgboost trained trees and as far as I can tell closed source transformer based models too. But not ChatGPT.
RMS might say yes, here's from the linked page describing other things as having knowledge and understanding:
> There are systems which use machine learning to recognize specific important patterns in data. Their output can reflect real knowledge (even if not with perfect accuracy)—for instance, whether an image of tissue from an organism shows a certain medical condition, whether an insect is a bee-eating Asian hornet, whether a toddler may be at risk of becoming autistic, or how well a certain art work matches some artist's style and habits. Scientists validate the system by comparing its judgment against experimental tests. That justifies referring to these systems as “artificial intelligence.”
Thanks -- that's not at all clear in this post (nor is it clear from the link text that its target would include a more complete description of his position).
I've updated my comment in response to this. Basically: It seems his key test is "Is someone validating the output, trying to steer it towards ground truth?" And since the answer re ChatGPT and Claude is clearly "yes", then ChatGPT clearly does count as an AI with semantic understanding, by his definition.
You're assigning something different to his argument. Here's from the linked page
> There are systems which use machine learning to recognize specific important patterns in data. Their output can reflect real knowledge (even if not with perfect accuracy)—for instance, whether an image of tissue from an organism shows a certain medical condition, whether an insect is a bee-eating Asian hornet, whether a toddler may be at risk of becoming autistic, or how well a certain art work matches some artist's style and habits. Scientists validate the system by comparing its judgment against experimental tests. That justifies referring to these systems as “artificial intelligence.”
This is nowhere near arguing that it should be able to make new versions of itself.
An AI/person that can solve novel problems (either by teaching it or not) is a more general kind of intelligence than one that can not.
It's a a qualitatively better intelligence.
An intelligence that can solve problems that fall into its training set better is quantitatively better.
Likewise, an intelligence that learns faster is quantitatively better.
To give a concrete and simple example, take a simple network trained to recognized digits. The network can be of arbitrary quality, it can be robust or not, fast or slow, but it can't do more than digits.
Another NN that can learn to recognize more symbols is a more general kind of AI, which again introduces another set of qualitative measures, namely how much training does it need to learn a new symbol robustly.
'Intelligence' is a somewhat vague term as any of the previous measures I've defined could be called intelligence (training accuracy, learning speed, inference speed etc., coverage of training set).
You could claim a narrower kind of intelligence that exists without learning (which is what ChatGPT is and what you gave as example with the person that only has a short-term memory) is still intelligence, but then we are arguing semantics.
Inference only LLMs are clearly missing something and are lacking in generality.
They could be more general, sure, but this is all extremely far from his bar for classifying things as AI.
> To give a concrete and simple example, take a simple network trained to recognized digits. The network can be of arbitrary quality, it can be robust or not, fast or slow, but it can't do more than digits.
This is the kind of thing he would class as AI, but not LLMs.
> So why can they respond saying they don't know things?
Because sometimes, the tokens for "I don't know" are the most likely, given the prior context + the RLHF. LLMs can absolutely respond that they don't know something or that they were incorrect about sometimes, but I've only seen that happen after first pointing out that they're wrong, which changes the context window to one where such an admission of fault becomes probable.
I've actually had ChatGPT admit it was wrong by simply asking a question ("how is X achieved with what you described for Y"). It responded with "Oh, it's a great question which highlights how I was wrong: this is what really happens...": but still, it couldn't get there without me understanding the underlying truth (it was about key exchange in a particular protocol that I knew little about, but I know about secure messaging in general), and it would easily confuse less experienced engineers with fully confident sounding explanation.
For things I don't understand deeply, I can only look if it sounds plausible and realistic, but I can't have full trust.
The "language" it uses when it's wrong is still just an extension of the token-completion it does (because that's what text contains in many of the online discussions etc).
> I think it is fair to accept that other people trace the line somewhere else.
It's a pointless naming exercise, no better than me arguing that I'm going to stop calling it quicksort because sometimes it's not quick.
It's widely called this, it's exactly in line with how the field would use it. You can have your own definitions, it just makes talking to other people harder because you're refusing to accept what certain words mean to others - perhaps a fun problem given the overall complaint about LLMs not understanding the meaning of words.
However there are two other ways this happens which come to mind:
1. HTTP API calls. There's a whole untyped layer going on here. You could have a PUT to set some content, and create a new entry if one doesn't exist - there's a place for a call to go to the wrong place but succeed. If two entities have the same structure but are different things this can be harder to spot.
2. Manual entry. This is the bigger one. Vast amounts of workflows have somewhere that a human does a thing, and that will go wrong at times. An excel file uploaded to the wrong place, the wrong header, the wrong bit typed on a form.
A counting up of numbers is a simple ID but awful for both of these, because now you have overlapping IDs across systems. Having larger random IDs takes you out of this risky area because at some point the chance of a collision is so low as to be not worth considering, however even small IDs with a prefix like "customer_001" and "order_001" quickly removes a source of problems.
I'm not saying any of this is the only solution, or that there aren't better ones, but I can see places where this kind of thing can easily happen in the real world and "prefix the ids with a type" is a very small and simple change that can help.
I would also note that this then becomes a front facing thing that ties you into something as well though, and not all types are as nice to make public.
reply