One relatively easy way to solve this could be to get a Codex model to transform the user request into a query for your database (e.g. SQL), by giving it the pseudo schema of your database, then query the database and return the results to chatGPT as the context of your user request (this is basically how bing chat works, as well):
For example:
User â App: âDoes the onion soup have mushrooms in it?â
App â OpenAI API (using codex model completion): âGiven this database schema: [insert the structure of your tables], write me a SQL query for this question: [insert user question]â.
OpenAI API â App: âHere is your Select statement: SELECT x, y, z FROM table1 JOIN table 2 ONâŚâ etc.
App â Restaurant Database: [execute SQL and retrieve results]
App â OpenAI API (using text model completion this time): âAct as the manager of a restaurant, who wants to answer user queries about the restaurant and only about the restaurant. Given the following user question and the related search results, respond to the user using only the results as context: User question: âDoes the onion soup have mushrooms in it?â - Search Results: [insert the results table of what the codex model gave you]â
OpenAI API - > App: âYes, our onion soup does contain traces of mushrooms. Do you not like them, would you like me to recommend alternative dishes without mushrooms?â
⌠and so on.
This is simplistic and youâd need to make sure you construct and tweak the right prompts, add error handling, maybe also use the moderation end point that OpenAI offers etc.
But roughly, this is how Iâd do it.
You can probably cache the returned SQL query, e.g. in Redis, based on the user question.
But the problem youâll have is that the question from the user wonât be repeated all that often (and if it does, it may be phrased differently and itâs then hard to tell if you still need the same SQL statement).
So while you may save the occasional API call this way, itâs probably rare and you still make actual API calls most of the time.
But at least in the case of a restaurant, you wonât expect that many people interacting with your chatbot so the volumes will be small and affordable.
For much larger use cases, you could perhaps work on extracting some sort of normalised version of every user request, to make it more likely to be matched with a cached SQL query. That may also decrease your API calls a bit, but thatâs trickier and also wonât be foolproof, not like exact API call requests in the non-ML world.
To offer another idea thatâs probably harder but more token efficient and safe than generating sql, you can get embeddings for your menu items and the services you offer, store them in a database, then chunk up the user input and get embeddings for that. Using cosine distance you get the k nearest items/services in your menu embeddings and include those in your system prompt.
Yes, each time you change your menu database youâll have to update the embeddings. Ideally menu changes dont happen that often, but no menu is so large that you couldnt get the whole thing chunked and embedded every day and be paying more than a few pennies. The chats are going to be your token-cost leader, with both an embedding request for the user input and then a completion request once youve put together your system message. That being said, i think this would overall be cheaper than making codex create queries, because then youâd need to be sending your whole schema along with every code completion request (every user message). Plus going through a remote sql server is going to add a ton of latency, if that was the plan.
Ah I see.
Yes, Iâm afraid you will probably have to pass in your schema every time, with every new completion. Your schema may not change, but the model API doesnât remember it.
Even with the new chat model, the API is âstatelessâ, i.e. it requires you to re-send your entire context with every request, even if you are continuing an existing conversation.
You could create a new âfine-tunedâ model, using OpenAIâs API to send training completions based on your menu and restaurant information, and then just query that.
But I donât know how accurate that would be.
No. ChatGPT cannot search a DB; but as mentioned, you can take the response from the API and use that response to drive actions which query the DB.
I do not recommend having the chatbot generate the SQL queries on the fly however. Itâs better, in my view wearing my systems engeerning hat, to write your own SQL queries because you cannot trust a text-generating language model to produce error free queries. Doing this adds a layer of complexity which is not necessary, in my view.
Can we add our own dataset over here? i have a CSV fileâŚin the above link they have added a dataset from huggingface datasets hub. So is it possible to modify the code slightly so that we can add our own datasetâŚif yes then pls tell me how to go about it. Thanks!
Iâve never used the collections before so I wouldnât know, sorry.
I imagine you would need to process your CSV file into an acceptable format which matches the JSON format they accept through the API. This is a very basic one below