Hacker News Reader

Comment by kleiba | Hacker News Reader

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

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.

But you can certainly validate their output. It seems like that's where this shifts the problem to.

How? You can validate that it's right for some inputs, that doesn't mean it'll be right for all inputs.

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.

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.

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.

Yes, exactly. You basically have to design your processes as if you were dealing with humans, because you more or less are.

Yeah, and that's not an argument against this kind of system, since it's obviously cheaper and more scalable than any human. (And I don't think you're arguing against it as a valid use case anyway.) But it will be interesting to see how this kind of "programming" paradigm seeps into the various software ecosystems.

I think we'll have two workflows, one that is pure programming, and one that is AI/fuzzy, basically AI "modules". Same way you interface with people today, really.

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.

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.

Exactly, that's my point.

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 :)

Hello node, my old friend...

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.

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.

We have a related issue open (https://github.com/PrefectHQ/marvin/issues/64) but haven't designed anything yet.

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

Reply on news.ycombinator.com