Creating a context aware dedicated Assistant per user account

API
1

I am looking at leveraging Assistants to build a feature that requires specific context tied to individual accounts in my service (and it relates to an area that has historically been a human-intensive process).

To provide the context to the assistant, my plan of action is:

  1. Generate a dedicated assistant for each account. Map the Assistant ID to the user account somewhere in the DB etc.
  2. Train that assistant out of the box and then provide the user avenues to train the assistant on specifics based on their needs.

Essentially I am looking at one Assistant per user account in my service.

I am looking for some design pattern kind of feedback on the above approach. If this approach is not optimal, are there any better alternatives to make Assistants contextual behind a SaaS?

2 Likes
2

This post got a solid cold shoulder :slight_smile: I am adding some information on where I am with this one. I did implement it, and it works pretty well. I’m figuring out some file upload-related stuff and whether uploading once for one assistant can be made available to others based on their relationship.

If anyone is working on something similar, would love to learn more.

Cheers!

2 Likes
3

You can probably use the additional instruction in the Run to add additional context per user account. As for the file, the doc said that if you attach the file at message level that it will only be accessible to that thread. However, I have read others who have observed probably a bug related to this.

1 Like
4

Came here looking for a better understanding of how to approach something similar… But maybe not exactly the same.

My scenario would include assistants that are given instructions to hone them in on one of a handful of specific topics. A user finding each particular topic/assistant would start from base instructions and grow a user specific context of preferences within the topic across multiple visits back to the bot.

Let’s say the topic and movies and the assistant could learn that user 123 loves comedy. Another assistant knows music and learns user 123 loves rock while user 456 loves pop.

I’m torn between

a) Creating user specific assistants, provided instructions repeated across assistants as a base… Then replacing the user specific assistant with new instructions to include context as it grows.

Vs

B) A single, subject matter expert assistant… Where each user gets a thread. And user context is added into a run level instruction.

Option B is more intuitive to me. And the documentation gives a hint to support this. At the Modify Thread documentation, it’s suggested to store a user id in the metadata of the thread:

const updatedThread = await openai.beta.threads.update(
    "thread_abc123",
    {
      metadata: { modified: "true", user: "abc123" },
    }
  );

My problem is… How do I retrieve the thread associated with the user in a clean fashion. There’s no list threads method… If I want to fetch and filter. So, I’d need to store the thread ID belongings to the user on my side.
Then use retrieve thread by ID. So what’s the point of storing the userid in the thread then?

With option A… I can list assistants. So this changes how I can find a users context… without holding any IDs on my end.

I’m rambling maybe. Same same… but a little different?

5

You can store metadata on the thread and message level. Imagine a thread as a topic thread (like here) with your own post id format saved in the metadata. Now let say you let many users post message in the same thread, so you can save their user id in the message level to distinguish which message is created by which user when you retrieve the message list.

6

A level of indirection…

`class SubjectMatterExpertAssistant(MetaAssistant):

class UserAssistant (MetaAssistant) :
user_id:str = Field(…)
user_thread_id:str = Field(…)

class UserThread(MetaThread):
`
You can then iterate over UserAssistants finding the correct user_id and get to the thread. No need to store user_id separately

1 Like
7

Can you please share some steps on how you solved that problem?
Currently, I need to do something similar and I would like to get some insights.

8

hey gaurab!
i’ve been working on something quite similar and would love what you think about it.

would love to chat more. i’ve dm’d you!

9

So is the solution here to attribute a particular thread to a particular user, that way there is some level of isolation regarding user-specific documents?

10

Do we just have a new thread created for each user, wherein they have their own context for the assistant, and then store the threadID along with the userID?

11

UserID generates an assistantID and multiple threads within the assistantID, because each threadID is associated with the runID to get the run output. Meaning one conversation within 1 thread.

12

Hi Gaurab,

I’m looking to implement something similar with a focus on file search at a user specific level.

To be more specific, the idea is for users to upload personal transcripts and ask questions about them.

It sounds like an individual Assistant per user is the way to go for this use case.

I would love to learn more about the “file upload-related stuff” that you were figuring out.

Thanks!

13

Hi Bertina,

We do have dedicated assistants per account (in our service). Regarding " “file upload-related stuff,” there is a bunch of middleware/layer work that offloads managing files for us. If you have specific scenarios, feel free to message me directly. I won’t be able to discuss all the details here.

Best,
Gaurab

1 Like