Creating a context aware dedicated Assistant per user account

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

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!

1 Like

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

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?

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.

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