5 ms·

I think the issue is that the sentence "Many tasks cannot be specified easily and precisely in computer code but can be described in a sentence or two of natura

by lsy 4y ago

I think the issue is that the sentence "Many tasks cannot be specified easily and precisely in computer code but can be described in a sentence or two of natural language" is not, in fact, true. Natural language is a pretty fantastically bad interface for specifying unambiguous, repeatable, and reliable tasks, which is why most technical advancement has involved the introduction of expressive notations that clarify and constrain problems in a way natural language can't. And the bulk of this article predicts (I think correctly!) that if LLMs are to be used for more automation, they have to progress towards some form of "semantic codes", "task primitives", "abstractions", ie. notation. "Prompt engineering" is a form of reaching for notation, although I would say at this point it is more like "prompt guessing". However this prompts the question of why we are striving to create massive natural language models (with all the disadvantages of natural language) that we will then heavily constrain to perform tasks that can be performed by traditional computers with order-of-magnitude greater efficiency and reliability? Most of these "chaining" libraries are already engaged in asking the LLM to pretty-please output a standardized blob format that can be read by a Python harness, where we use the LLM to identify that something is e.g. an equation, and then pack it off to Wolfram or something. It seems like if you want to do this more than a few times, it's better to write a couple lines of code to do it much more cheaply.

catchnear4321 4y ago
After a few times, you could ask it to reduce its purpose to a couple of lines of code. Test the code, verify it. Maybe even deploy it. That’s more expensive than writing a couple of lines of code, more than deploying it, Sufficiently standardized, it will be significantly less expensive than paying someone to write a couple of lines of code, test it, deploy it, etc. Is this better than just writing a couple of lines of code? That’s a different question. At scale, this can absolutely be cheaper. Eventually.
manmal 4y ago
I think developing often used functions as plugins/task primitives as native code (i.e. tools that the LLM can use) would be a logical next step - as you expressed, I think. > It seems like if you want to do this more than a few times, it's better to write a couple lines of code to do it much more cheaply I think the problem is that natively written code will always suck at the planning part. An LLM can use the tools available to it (eg a web browser or Wolfram) in infinite ways, and hopefully in a way that will advance the task at hand. Maybe the natively written task primitives can become really big (eg a fully automatic web scraper) - great, now the LLM can gather info for its plans even faster.
qup 4y ago
> Natural language is a pretty fantastically bad interface for specifying unambiguous, repeatable, and reliable tasks I agree. I think people are fooled by the implicit knowledge that most humans have. They make decisions about the details, where in programming you have to tend to each detail. That's roughly equivalent effort in natural language. For some problems, probably harder in natural language. I still think it's a great advancement. It opens programming to the masses, and the LLM can probably teach you the things you need to know to advance your competency.
vidarh 4y ago
The big value is certainly in the less constrained stuff. Today I wanted to experiment with a hobby project, so I wrote a page of what I want to achieve. I then presented it to GPT4 as a "spec" and told it to act as a software architect and give me suggestions and ask for clarification. It gave me mostly good suggestions, asked a few good questions, and gave some feedback I disagreed with. I updated the spec to incorporate the good bits, clarified and firmed up the wording around the choices where it had made suggestions I disagreed with, and asked it to give another round of feedback. I turned around the draft 3 times, and it added value every time. I could have done that with a person, but then I'd need someone who was available then and there that I wasn't taking away from other stuff. To tie that to your points: This process was exactly an exercise in nailing down details that were missing because the short prose version was leaving huge gaps. I intend to need a back and forth of filling in detail each step toward an implementation for that reason. And I think this kind of tooling need to be built with that in mind: Write roughly what you need unless you already know how you want to express it in code. Ask for clarifications or a proposed plan. Iterate. Maybe with tooling giving examples of where it would head if prompted to fill in more detail. I sure as hell won't trust it to just blindly do a task for me from a brief problem statement at this point. Just as I wouldn't for most non-trivial tasks with most humans...
galaxyLogic 4y ago
AI must learn to understand code, not just copy it
furyofantares 4y ago
It's pretty often that people tell a programmer what they want in not-that-much natural language and then the programmer makes it happen. You do have to verify the programmer's work and often provide some corrections that may have been the result of unrecognized ambiguity, but it still ends up being vastly less natural language sent to the programmer than the amount of precise language the programmer ultimately specifies.
babyshake 4y ago
Yes, the problem is "easily and precisely" should just be "easily". Natural language tends to be easy but not precise, while computer code is precise but not easy. Obviously something like idiomatic Python or other similar examples are relatively easy, but a very advanced SQL query can be expressed with a relatively concise syntax but unless you are an expert is not at all easy to produce on your own compared to expressing what you want in natural language.

by lsy 4y ago

catchnear4321 4y ago

After a few times, you could ask it to reduce its purpose to a couple of lines of code. Test the code, verify it. Maybe even deploy it. That’s more expensive than writing a couple of lines of code, more than deploying it, Sufficiently standardized, it will be significantly less expensive than paying someone to write a couple of lines of code, test it, deploy it, etc. Is this better than just writing a couple of lines of code? That’s a different question. At scale, this can absolutely be cheaper. Eventually.

manmal 4y ago

I think developing often used functions as plugins/task primitives as native code (i.e. tools that the LLM can use) would be a logical next step - as you expressed, I think. > It seems like if you want to do this more than a few times, it's better to write a couple lines of code to do it much more cheaply I think the problem is that natively written code will always suck at the planning part. An LLM can use the tools available to it (eg a web browser or Wolfram) in infinite ways, and hopefully in a way that will advance the task at hand. Maybe the natively written task primitives can become really big (eg a fully automatic web scraper) - great, now the LLM can gather info for its plans even faster.

qup 4y ago

> Natural language is a pretty fantastically bad interface for specifying unambiguous, repeatable, and reliable tasks I agree. I think people are fooled by the implicit knowledge that most humans have. They make decisions about the details, where in programming you have to tend to each detail. That's roughly equivalent effort in natural language. For some problems, probably harder in natural language. I still think it's a great advancement. It opens programming to the masses, and the LLM can probably teach you the things you need to know to advance your competency.

vidarh 4y ago

The big value is certainly in the less constrained stuff. Today I wanted to experiment with a hobby project, so I wrote a page of what I want to achieve. I then presented it to GPT4 as a "spec" and told it to act as a software architect and give me suggestions and ask for clarification. It gave me mostly good suggestions, asked a few good questions, and gave some feedback I disagreed with. I updated the spec to incorporate the good bits, clarified and firmed up the wording around the choices where it had made suggestions I disagreed with, and asked it to give another round of feedback. I turned around the draft 3 times, and it added value every time. I could have done that with a person, but then I'd need someone who was available then and there that I wasn't taking away from other stuff. To tie that to your points: This process was exactly an exercise in nailing down details that were missing because the short prose version was leaving huge gaps. I intend to need a back and forth of filling in detail each step toward an implementation for that reason. And I think this kind of tooling need to be built with that in mind: Write roughly what you need unless you already know how you want to express it in code. Ask for clarifications or a proposed plan. Iterate. Maybe with tooling giving examples of where it would head if prompted to fill in more detail. I sure as hell won't trust it to just blindly do a task for me from a brief problem statement at this point. Just as I wouldn't for most non-trivial tasks with most humans...

galaxyLogic 4y ago

AI must learn to understand code, not just copy it

furyofantares 4y ago

It's pretty often that people tell a programmer what they want in not-that-much natural language and then the programmer makes it happen. You do have to verify the programmer's work and often provide some corrections that may have been the result of unrecognized ambiguity, but it still ends up being vastly less natural language sent to the programmer than the amount of precise language the programmer ultimately specifies.

babyshake 4y ago

Yes, the problem is "easily and precisely" should just be "easily". Natural language tends to be easy but not precise, while computer code is precise but not easy. Obviously something like idiomatic Python or other similar examples are relatively easy, but a very advanced SQL query can be expressed with a relatively concise syntax but unless you are an expert is not at all easy to produce on your own compared to expressing what you want in natural language.