5 ms·

How do you guarantee consistency in implementation (esp. details) of AI functions across platforms and/or across time?

by kleiba 4y ago

Yoric 4y ago
Welcome to the post-API world, where your code can break just because... well, we're not sure, but it's related to AI, so everything is fine :)
- akiselev 4y ago
  Hello node, my old friend...
stavros 4y ago
AIs are basically a cheaper version of Mechanical Turk, so you can't guarantee anything. People still think about AIs as if they are computers, but they're closer to people. So, the question becomes "how do you guarantee that people will do the task you ask them to do?". Well, simply put: you can't.
- kleiba 4y ago
  I think you're analogy is off - Mechanical Turks are typically used for batches of offline tasks. Here, I see the problem that today, the AI will realize my AI function one way and if I recompile tomorrow, it might have slight but important implementation differences.
  - stavros 4y ago
    There is no "recompile". It literally changes invocation to invocation. It might do something one time and refuse the next, even based on the inputs.
    - kleiba 4y ago
      Exactly, that's my point.
- chatmasta 4y ago
  But you can certainly validate their output. It seems like that's where this shifts the problem to.
  - stavros 4y ago
    How? You can validate that it's right for some inputs, that doesn't mean it'll be right for all inputs.
    - chatmasta 4y ago
      I guess it depends on what you want it to do. If the goal is "output random strings of text between 10-15 characters," obviously that's easy to validate. But if you ask it to "output random Italian male names" then that's much harder to validate. Although I see what you mean about unconstrained inputs. If you can give it any number as an input then it's going to be difficult to validate, except at the most superficial level, eg "input 10, generates 10 items matching the expected constraint." I am skeptical that any real use case wouldn't effectively mean writing the validation code is as much work as just writing a single implementation (and testing it) in the first place.
      - stavros 4y ago
        I think most things that are hard for a computer to generate are also hard to validate. If you're lucky enough, you'll have an easy validation task, but usually it's very hard to programmatically check the model's work.
        chatmasta 4y ago
        Yeah I agree. I think that means that the best use case for this will be either generating junk data where some incorrectness is tolerable, or replacing humans for error-prone tasks that you would normally outsource, eg parsing a summary from a web page. Presumably if you're already farming out tasks to MechanicalTurk, you have systems in place for tolerating human error, so you can tune those same systems to tolerate AI error on the same tasks.
jlowin 4y ago
Honestly, it's hard! We try our best through a few strategies: - At this time Marvin is only tested with GPT-3.5 and GPT-4 to reduce the surface area of LLM differences. You're welcome to try others, but the prompts are optimized for performance of those two models - I expect that prompts optimized for one family of models will not automatically work with others, so as time allows we may end up with branching prompts based on your model choice. Marvin does a lot of work to manipulate the user prompt before sending it to the LLM so I think there's an excellent chance that we could deliver similar results for the same user input. - Even with GPT-3.5 and GPT-4 we see a remarkable difference between them, with 4 needing far less complex prompts than 3.5 to get the same result. However, given both the cost and availability of GPT-4, we decided to make 3.5 our default to make sure everyone can use the library. Therefore we do our best to make sure prompts work with 3.5 and expect that that is a good bet of compatibility with 4.
- akiselev 4y ago
  Can you offer the ability to commit the generated code? Only generate code if the function body is empty and write it back out to the Python source file which would allow users to check in functions and quickly regenerate them just by rerunning the executable.
  - jlowin 4y ago
    We have a related issue open (https://github.com/PrefectHQ/marvin/issues/64 https://github.com/PrefectHQ/marvin/issues/64) but haven't designed anything yet.
manojlds 4y ago
It's like moving from classical physics to quantum physics.

How do you guarantee consistency in implementation (esp. details) of AI functions across platforms and/or across time?

by kleiba 4y ago

How do you guarantee consistency in implementation (esp. details) of AI functions across platforms and/or across time?

Welcome to the post-API world, where your code can break just because... well, we're not sure, but it's related to AI, so everything is fine :)

akiselev 4y ago
Hello node, my old friend...

stavros 4y ago

AIs are basically a cheaper version of Mechanical Turk, so you can't guarantee anything. People still think about AIs as if they are computers, but they're closer to people. So, the question becomes "how do you guarantee that people will do the task you ask them to do?". Well, simply put: you can't.

kleiba 4y ago
I think you're analogy is off - Mechanical Turks are typically used for batches of offline tasks. Here, I see the problem that today, the AI will realize my AI function one way and if I recompile tomorrow, it might have slight but important implementation differences.
- stavros 4y ago
  There is no "recompile". It literally changes invocation to invocation. It might do something one time and refuse the next, even based on the inputs.
  - kleiba 4y ago
    Exactly, that's my point.
chatmasta 4y ago
But you can certainly validate their output. It seems like that's where this shifts the problem to.
- stavros 4y ago
  How? You can validate that it's right for some inputs, that doesn't mean it'll be right for all inputs.
  - chatmasta 4y ago
    I guess it depends on what you want it to do. If the goal is "output random strings of text between 10-15 characters," obviously that's easy to validate. But if you ask it to "output random Italian male names" then that's much harder to validate. Although I see what you mean about unconstrained inputs. If you can give it any number as an input then it's going to be difficult to validate, except at the most superficial level, eg "input 10, generates 10 items matching the expected constraint." I am skeptical that any real use case wouldn't effectively mean writing the validation code is as much work as just writing a single implementation (and testing it) in the first place.
    - stavros 4y ago
      I think most things that are hard for a computer to generate are also hard to validate. If you're lucky enough, you'll have an easy validation task, but usually it's very hard to programmatically check the model's work.
      - chatmasta 4y ago
        Yeah I agree. I think that means that the best use case for this will be either generating junk data where some incorrectness is tolerable, or replacing humans for error-prone tasks that you would normally outsource, eg parsing a summary from a web page. Presumably if you're already farming out tasks to MechanicalTurk, you have systems in place for tolerating human error, so you can tune those same systems to tolerate AI error on the same tasks.

jlowin 4y ago

Honestly, it's hard! We try our best through a few strategies: - At this time Marvin is only tested with GPT-3.5 and GPT-4 to reduce the surface area of LLM differences. You're welcome to try others, but the prompts are optimized for performance of those two models - I expect that prompts optimized for one family of models will not automatically work with others, so as time allows we may end up with branching prompts based on your model choice. Marvin does a lot of work to manipulate the user prompt before sending it to the LLM so I think there's an excellent chance that we could deliver similar results for the same user input. - Even with GPT-3.5 and GPT-4 we see a remarkable difference between them, with 4 needing far less complex prompts than 3.5 to get the same result. However, given both the cost and availability of GPT-4, we decided to make 3.5 our default to make sure everyone can use the library. Therefore we do our best to make sure prompts work with 3.5 and expect that that is a good bet of compatibility with 4.

akiselev 4y ago
Can you offer the ability to commit the generated code? Only generate code if the function body is empty and write it back out to the Python source file which would allow users to check in functions and quickly regenerate them just by rerunning the executable.
- jlowin 4y ago
  We have a related issue open (https://github.com/PrefectHQ/marvin/issues/64 https://github.com/PrefectHQ/marvin/issues/64) but haven't designed anything yet.

manojlds 4y ago

It's like moving from classical physics to quantum physics.