I see your point. I think it’s time to tell the specifics.
[Bob posts a problem about data classification]
Alice: You should use LLM. It especially suites your problem
Bob: In my understanding LLM is only strong where the context is large. If the context is small then using regex gives better result? Also, regex has advantages of high accuracy, fast, understandable and debuggable?
Alice: Not really. Also, regex cannot work with synonyms and it must be in form. LLM is trained on multiple data, so if you make good prompt then it’s much better
Bob: But the nature of catching synonyms is still depending on context. As the context is small then there is not much synonyms at the beginning. If even human cannot get them then how can machine recognize them?
Alice: You should try it first. You are reasoning too much
There are some notes:
By “regex” Bob actually means rule-based approach. He thought in the context of NLP people generally understand regex and rule-based approach as one
He mistakes synonym with homonym. Had he been aware of that he might have not said “the nature of catching synonyms is still depending on context”
These info are only revealed later on. I understand that at the time of saying these are enough for Alice to conclude that Bob needs to learn more. And again, I understand that she doesn’t want to waste time. But I think shutting down a conversation because of the experience state of the conversations partner is a sign of ad hominent. If she wants to save her time then she can just abandon the conversation. If she still want to give feedback while not having the burden to elaborate then she can tell Bob to read more about synonyms/context/LLM. Is that a correct thinking?
Oh, both of them are stuck in a false dichotomy. The right answer is obviously a mix of both. They could have a valid debate about budgets (both dev and runtime costs) and precision-recall tradeoffs, and long-tail utterances, and whether the problem is simple enough that it’s anywhere close to true that the rules will fit in someone’s head in order to be testable and debuggable. They can talk about what parts of the problem are best addressed by what tools. But a general discussion of “if we have only one tool, should it be a hammer or a screwdriver” is probably unhelpful.
“Just try it” is probably fairly costly to do, so I understand Bob’s reluctance. He’s wrong, because “try it” includes “learn enough about it to actually understand it’s strengths and weaknesses”. Alice is wrong because “you’re reasoning too much” is not what’s happening, and trying it is not an alternative to reasoning, it’s an aid to reasoning better.
I don’t find much use in trying to analyze whether Alice is trying to shut down the conversation, or whether Bob is confusing things that are basic enough that Alice is understandably frustrated and unable to give good advice on a practical level. Again, specifics of the discussion matter—is this a friendly, low-stakes brainstorm, or are they teammates trying to solve a specific problem, or is it some other relationship?
That said, I’m now shutting down this conversation :) I’ll read any further responses, but probably won’t further engage.
That said, I’m now shutting down this conversation :) I’ll read any further responses, but probably won’t further engage.
Thanks for your patience. Your response is by far the most useful one I have. I really appreciate that.
If you find replying a short sentence isn’t much burden, can you tell why you don’t want to continue this conversation? Is it because continuing it doesn’t stimulate your interest as you have on it in the beginning? Can you share why?
I don’t know that my reasons are all that legible, but some combination of:
I’ve now heard enough details that my curiosity about the framing of the discussion is satisfied.
I actually know quite a bit about the object-level discussion (having worked on large NLP projects, though before the dominance of LLMs), and I don’t think there’s much value to you or to me in trying to go deeper on a problem I’m not invested in.
My estimate of future enjoyment or education from further exploration of the topic is pretty low. I got good value from a small time/thought investment in early conversation, and it feels like we’ve passed the peak of marginal enjoyment for additional effort.
I’m still a little annoyed at the incorrect and wasteful generalization at the start, when the specifics dominate the interpretation that should be used.
Ok, that sounds a lot more harsh than I actually feel. I probably should have said “I think we’ve explored the overall question about Alice and Bob, and that’s all I was looking for in the first place.”
They could have a valid debate about budgets (both dev and runtime costs) and precision-recall tradeoffs, and whether the problem is simple enough that it’s anywhere close to true that the rules will fit in someone’s head in order to be testable and debuggable.
I’m not sure what “it’s anywhere close to true that the rules will fit in someone’s head in order to be testable and debuggable” means. I guess you just mean if the problem is simple enough then the rule-based approach is better. Is that correct?
I’ll assuming yes here. While Bob indeed doesn’t mention explicitly about budgets, I guess we can all assume that everyone wants budgets as low as possible. And since Bob thinks that since the context is small here, I think he thinks that the problem is simple enough, and if using the rule-based approach then the precision-recall tradeoffs won’t bee applied here. Overall, I think that in his mind the rule-based approach is the perfect tool for the problem.
They can talk about what parts of the problem are best addressed by what tools. But a general discussion of “if we have only one tool, should it be a hammer or a screwdriver” is probably unhelpful.
So while I really agree with this, I suppose the reason both sides stuck is because both assume that their tool has superiority over the other on the problem. Alice sees the problem and concludes that this must be a nail and can never be a screw, so obviously the screwdriver is bad. Bob sees the problem and concludes that this must be a screw and can never be a nail, so obviously the hammer is bad.
So I guess instead of arguing whether the solution should be a screwdriver or a hammer, they should argue on whether the problem is a screw or a nail. Perhaps it’s a combination of screw and nail. Bob does give more detail about the problem when he says “the context is small”, and I guess in his mind it’s a distinctive feature of a screw, but perhaps the reality is that it’s a shared feature of both. He sees the shank and mistakes it with the helical thread.
I see your point. I think it’s time to tell the specifics.
[Bob posts a problem about data classification]
Alice: You should use LLM. It especially suites your problem
Bob: In my understanding LLM is only strong where the context is large. If the context is small then using regex gives better result? Also, regex has advantages of high accuracy, fast, understandable and debuggable?
Alice: Not really. Also, regex cannot work with synonyms and it must be in form. LLM is trained on multiple data, so if you make good prompt then it’s much better
Bob: But the nature of catching synonyms is still depending on context. As the context is small then there is not much synonyms at the beginning. If even human cannot get them then how can machine recognize them?
Alice: You should try it first. You are reasoning too much
There are some notes:
By “regex” Bob actually means rule-based approach. He thought in the context of NLP people generally understand regex and rule-based approach as one
He mistakes synonym with homonym. Had he been aware of that he might have not said “the nature of catching synonyms is still depending on context”
These info are only revealed later on. I understand that at the time of saying these are enough for Alice to conclude that Bob needs to learn more. And again, I understand that she doesn’t want to waste time. But I think shutting down a conversation because of the experience state of the conversations partner is a sign of ad hominent. If she wants to save her time then she can just abandon the conversation. If she still want to give feedback while not having the burden to elaborate then she can tell Bob to read more about synonyms/context/LLM. Is that a correct thinking?
Oh, both of them are stuck in a false dichotomy. The right answer is obviously a mix of both. They could have a valid debate about budgets (both dev and runtime costs) and precision-recall tradeoffs, and long-tail utterances, and whether the problem is simple enough that it’s anywhere close to true that the rules will fit in someone’s head in order to be testable and debuggable. They can talk about what parts of the problem are best addressed by what tools. But a general discussion of “if we have only one tool, should it be a hammer or a screwdriver” is probably unhelpful.
“Just try it” is probably fairly costly to do, so I understand Bob’s reluctance. He’s wrong, because “try it” includes “learn enough about it to actually understand it’s strengths and weaknesses”. Alice is wrong because “you’re reasoning too much” is not what’s happening, and trying it is not an alternative to reasoning, it’s an aid to reasoning better.
I don’t find much use in trying to analyze whether Alice is trying to shut down the conversation, or whether Bob is confusing things that are basic enough that Alice is understandably frustrated and unable to give good advice on a practical level. Again, specifics of the discussion matter—is this a friendly, low-stakes brainstorm, or are they teammates trying to solve a specific problem, or is it some other relationship?
That said, I’m now shutting down this conversation :) I’ll read any further responses, but probably won’t further engage.
Thanks for your patience. Your response is by far the most useful one I have. I really appreciate that.
If you find replying a short sentence isn’t much burden, can you tell why you don’t want to continue this conversation? Is it because continuing it doesn’t stimulate your interest as you have on it in the beginning? Can you share why?
I don’t know that my reasons are all that legible, but some combination of:
I’ve now heard enough details that my curiosity about the framing of the discussion is satisfied.
I actually know quite a bit about the object-level discussion (having worked on large NLP projects, though before the dominance of LLMs), and I don’t think there’s much value to you or to me in trying to go deeper on a problem I’m not invested in.
My estimate of future enjoyment or education from further exploration of the topic is pretty low. I got good value from a small time/thought investment in early conversation, and it feels like we’ve passed the peak of marginal enjoyment for additional effort.
I’m still a little annoyed at the incorrect and wasteful generalization at the start, when the specifics dominate the interpretation that should be used.
Ok, that sounds a lot more harsh than I actually feel. I probably should have said “I think we’ve explored the overall question about Alice and Bob, and that’s all I was looking for in the first place.”
I see. Thanks for replying. I wonder if we move the topic to how your interest works, would that be your interest?
I’m not sure what “it’s anywhere close to true that the rules will fit in someone’s head in order to be testable and debuggable” means. I guess you just mean if the problem is simple enough then the rule-based approach is better. Is that correct?
I’ll assuming yes here. While Bob indeed doesn’t mention explicitly about budgets, I guess we can all assume that everyone wants budgets as low as possible. And since Bob thinks that since the context is small here, I think he thinks that the problem is simple enough, and if using the rule-based approach then the precision-recall tradeoffs won’t bee applied here. Overall, I think that in his mind the rule-based approach is the perfect tool for the problem.
So while I really agree with this, I suppose the reason both sides stuck is because both assume that their tool has superiority over the other on the problem. Alice sees the problem and concludes that this must be a nail and can never be a screw, so obviously the screwdriver is bad. Bob sees the problem and concludes that this must be a screw and can never be a nail, so obviously the hammer is bad.
So I guess instead of arguing whether the solution should be a screwdriver or a hammer, they should argue on whether the problem is a screw or a nail. Perhaps it’s a combination of screw and nail. Bob does give more detail about the problem when he says “the context is small”, and I guess in his mind it’s a distinctive feature of a screw, but perhaps the reality is that it’s a shared feature of both. He sees the shank and mistakes it with the helical thread.
I hope this make sense.