Has anyone tried throwing their backend Swagger at this and made ChatGPT perform user story tests?
Native JSON Output from GPT-4
221–230 of 258 posts
Re: Native JSON Output from GPT-4
#222Earlier quoted context omitted.
Langchain added support for `function_call` args yesterday: * https://github.com/hwchase17/langchain/pull/6099/files * https://github.com/hwchase17/langchain/issues/6104 IMHO, this should make Langchain much easier and less chaotic to use.
It's only been added to the OpenAI interface. Function calling is really useful when used with agents. To include that to agents would require some redesign as the tool instructions should be removed from the prompt templates in favor of function definitions in the API request. The response parsing code would also be affected. I just hope they won't come up with yet another agent type.
Re: Native JSON Output from GPT-4
#223After reading the docs for the new ChatGPT function calling yesterday, it's structured and/or typed data for GPT input or output that's the key feature of these new models. The ReAct flow of tool selection that it provides is secondary. As this post notes, you don't even need to the full flow of passing a function result back to the model: getting structured data from ChatGPT in itself has a lot of fun and practical…
That SQL example is going to result in a catastrophe somewhere when someone uses it in their project. It is encouraging something very dangerous when allowed to run on untrusted inputs.
Re: Native JSON Output from GPT-4
#224Earlier quoted context omitted.
Yup. Is there a good/forgiving "drunken JSON parser" library that people like to use? Feels like it would be a useful (and separable) piece?
Honestly, I suspect asking GPT-4 to fix your JSON (in a new chat) is a good drunken JSON parser. We are only scraping the surface of what's possible with LLMs. If Token generation was free and instant we could come up with a giant schema of interacting model calls that generates 10 suggestions, iterates over them, ranks them and picks the best one, as silly as it sounds.
That's hilarious... if parsing GPT's JSON fails, keep asking GPT to fix it until it parses!
Re: Native JSON Output from GPT-4
#225I'm concerned that OpenAI's example documentation suggests using this to A) construct SQL queries and B) summarize emails, but that their example code doesn't include clear hooks for human validation before actions are called. For a recipe builder it's not so big a deal, but I really worry how eager people are to remove human review from these steps. It gets rid of a very important mechanism for reducing the risks of…
I don't understand why they have done this? Like, how did the conversations go when it was pointed out to them what a pretty darn bad idea it was to recommend connecting chatgpt directly to a SQL database?
I know we are supposed to assume incompetence over malice, but no one is that incompetent. They must have had the conversations, and chose to do it anyway.
Re: Native JSON Output from GPT-4
#226This was technically possible before. I think the approach used by many - myself included - is to simply embed results in a markdown code block and the match it with regex pattern. Then you just need to phrase the prompt to generate the desired output.
This is an example of that generating the arguments for the MongoDB's `db.runCommand()` function: https://aihelperbot.com/snippets/cliwx7sr80000jj0finjl46cp
Re: Native JSON Output from GPT-4
#227Earlier quoted context omitted.
This is cool! Are you using one-shot learning under the hood with a user provided example?
BTW: Here's a more performant version (fewer tokens) https://preview.promptjoy.com/apis/jNqCA2 that uses a smaller example but will still generate pretty good results.
This is still pretty fast - impressive! Are there any tricks you're doing to speed things up?
Re: Native JSON Output from GPT-4
#228I'm concerned that OpenAI's example documentation suggests using this to A) construct SQL queries and B) summarize emails, but that their example code doesn't include clear hooks for human validation before actions are called. For a recipe builder it's not so big a deal, but I really worry how eager people are to remove human review from these steps. It gets rid of a very important mechanism for reducing the risks of…
I don't understand why they have done this? Like, how did the conversations go when it was pointed out to them what a pretty darn bad idea it was to recommend connecting chatgpt directly to a SQL database? I know we are supposed to assume incompetence over malice, but no one is that incompetent. They must have had the conversations, and chose to do it anyway.
Perhaps they plan on having ChatGPT make a quick copy of your database, for your convenience of course.
Re: Native JSON Output from GPT-4
#229After reading the docs for the new ChatGPT function calling yesterday, it's structured and/or typed data for GPT input or output that's the key feature of these new models. The ReAct flow of tool selection that it provides is secondary. As this post notes, you don't even need to the full flow of passing a function result back to the model: getting structured data from ChatGPT in itself has a lot of fun and practical…
IIRC, there's a way to "force" LLMs to output proper JSON by adding some logic to the top token selection. I.e. in the randomness function (which OpenAI calls temperature) you'd never choose a next token that results in broken JSON. The only reason it wouldn't would be if the output exceeds the token limit. I wonder if OpenAI is doing something like this.
This is the best implementation I've seen, but only for Hugging Face models: https://github.com/1rgs/jsonformer
Re: Native JSON Output from GPT-4
#230Earlier quoted context omitted.
In my opinion the only way to use it safely is to ensure your AI only has access to data that the end user already has access to. At that point, prompt injection is no-longer an issue - because the AI doesn't need to hide anything. Giving GPT access to your entire database, but telling it not to reveal certain bits, is never going to work. There will always be side channel vulnerabilities in those systems.
> e.g. define a function called extract_data(name: string, birthday: string), or sql_query(query: string) This section in OpenAI's product announcement really irritates me because it's so obvious that the model should have access to a subset of API calls that themselves fetch the data, as opposed to giving the model raw access to SQL. You could have the same capabilities while eliminating a huge amount of risk. And O…
SQL doesn’t necessarily have to mean full database access.
I known it’s pretty common to have apps connect to a database with a db user with full access to do anything, but that’s definitely not the only way.
If you’re interested in being safer, it’s worth learning the security features built in to your database.