Clarification on Assistant Creation: Does Every User Generate an Assistant with OpenAI Retrieval Calls?

API
1

I’ve noticed an interesting behavior when testing our web application. In the playground, it seems that each time a user visits our web app and we call the retrieval API using the assistant, it creates a new assistant.

Is this expected behavior, or should we be reusing the same assistant for multiple user interactions on our web app? We want to ensure that we are using the OpenAI API correctly and efficiently. Your insights and clarification on this matter would be greatly appreciated!

3

An assistant can be shared.

Consider assistant as similar to a custom AI model, that carries with it unique system programming and features.

What should be assigned per-user is threads, and optimally a user can engage in and select between multiple threads like they do in ChatGPT.

2 Likes
4

I’m not really finding how to intuitively inquire on user specific threads, then… Without a List Threads method.

I see the user id stored by the Modify Thread example. And even with that… And a list threads method… I would need to list them all and then filter on metadata locally?

So am I to store all of each user’s thread IDs in my database and getThread one by one?

Any light shed on how to best approach would be greatly appreciated!

5
  • Consider: API is not made for you, it is made for your users
  • Do you want to provide every user ID you have to OpenAI
  • Do you want OpenAI to keep track of every conversation every user of yours had?
  • Do you want OpenAI to provide a list of conversation titles you can show in your GUI?
  • Do you want OpenAI to track how much to bill each of your customers?

At a certain point in that process of making all those solutions, OpenAI no longer needs you. They’ve made ChatGPT.

So as you can see, you still need to do all that per-user conversation recording. Then, when you have all that management in place, paying extra for a service that bills excess tokens for excessive code required seems kind of pointless when you can manage chat completions AI yourself…

6

The answer to each question is no. More so looking for help with the API… not philosophy on the viability of my use case.

My goal is that each assistant would be built with it’s own instruction… and retrieval functionality, to serve as a subject matter expert, which is “shared”. Some* users would have a single* ongoing conversation with the assistant, which forms an isolated context per user. Makes sense to me that this would be a thread… And not an individual assistant per user, as you e described.

So, I’m looking for a most efficient way to retrieve the thread designated for the user. With no thread listing in the assistants API beta… Seems I need to keep that threadId on hand to inquire on a specific thread. So, what is the purpose of putting the userId in the thread metadata, as shown in documentation for Modify Thread?

7

The metadata is all for your own use. You could put things there like the date and time of the user input, or the number of tokens you counted yourself. You can imagine that putting in your own user’s ID could be some sort of second level safety check you can use, just to make sure that messages from another user are never shown to the incorrect client.

There is no database retrieval on the metadata though, and the threads don’t have any kind of search feature either. So the utility is quite limited.

Do you want to show the recent conversations a user has had? You’d better remember all their threads and the assistant they might have been assigned. Want to show them a conversation title? You’d need to come up with some scheme for adding that as metadata. The more you envision what is actually needed for chatbot like functions, the more you see that the assistants API was only coded to provide a veneer of what is actually needed as a backend - an unmanageable conversation history. You simply have more complexity that you have to match up and coordinate between your own database and the contents that are kept by OpenAI…and soon realize the “why?” of it all…

1 Like
8

Believe it or not… also no to your two questions here. No conversation history or title necessary. User can’t navigate separate threads or thread history. Single thread per user… with a possibility to reset context.

I guess I will go back towards storing the thread ID to the user record upon creation of thread… And adding user specific context into run level instructions.

Thanks for the feedback.