Ailixir is an application that utilises LLMs and custom user input to generate AI agent prototypes specialised in fields such as health, economics, physics etc. The prototypes enable the user, which is an entrepreneur-developer, to compare the results produced by different LLMs.
MIT License
7
stars
1
forks
source link
Save answers provided to the initialisation prompt as custom user-context #222
The initialisation prompt is administered by the entrepreneur-user who is “forming” and deploying different instances of the app to perform as different types of agents for common-users of different backgrounds.
The components for custom context (Jan / Dave) are supposed to be administered only by common-users who do not have access to the initialisation prompt (Google Docs) but are the receivers of the questions included in that prompt when they log in to the app instance that is tied to a specific prompt or when the initialisation prompt gets updated by the entrepreneur-user.
entrepreneur-user:
Creates and deploys different instances of the same app / pipeline. One instance is the one we are creating that has to do with lifestyle advice for persistent health problems. The initialisation prompt asks from common users to provide details about their medical background. food preferences etc. The entrepreneur user, in the future, could take the same app backbone and after changing a) the link to the google docs where the initialisation prompt is hosted b) the links to the embeddings DB c) some custom prompts which in our case are unfortunately not easily decoupled from the codebase they could turn the app backbone into essentially a different app which is let’s say for a common-user who is a biologist and does research on sth. of that field. The initialisation prompt, the embeddings and the custom prompts should be different at that case. This is not our job though for this project. We are only focusing on making a) the backbone so that the app can accommodate several common-user use cases (person with persistent health problems, biologist, economist…) and b) we create just one instance of these as a POC.
common-user:
The common-user lives in the walled garden that the entrepreneur-user have created for them. They receive an app that has been tailored for their needs without being able to turn the app into something else (unlike with the entrepreneur user). The common-user has the option to pass custom context (chatGPT style) to the LLM through the custom context fields that Jan / Dave have built.
An analogy: if the common user was a single docker container the entrepreneur-user would be kubernetes.
More specific about this task
The asnwers entered by the common user as a result of their interaction with the agent who has been fed with the initialisation prompt [ See #214, #220 ] will need to be saved in some structured way in the system so that they can form the basis of the common-user medical / nutritional / fitness profile and then get combined with the custom scraped context and the LLM language delivery capabilities in order to customise the agent to each common-user.
Maybe it makes sense to use a tagging / keywording system routed to the database to allow this user information to easily be matched with other custom context derived by the scraped data.
Maybe this can be done via the embeddings.
This saved medical / nutritional / fitness / preferences profile will then inform the rest of the interaction of the common-user with the system.
User Story
As a common-user,
I want my answers to the initialization questions to be saved
so that the app can use this information to provide tailored responses.
Acceptance Criteria
[ ] User responses to the initialization prompt are saved as part of their custom context in the database or are turned into embeddings and stored in the Vector Store.
[ ] Documentation is provided on how the user inserted context coming from the initialisation promt is stored and utilized within the system.
[ ] [Testing if this has indeed worked] When the common user asks for what the agent knows about them, the agent can provide a list of data saved about them.
Definition of Done
[ ] The feature has been fully implemented.
[ ] The feature has been manually tested and works as expected without critical bugs.
[ ] The feature code is documented with clear explanations of its functionality and usage.
[ ] The feature code has been reviewed and approved by at least one team member.
[ ] The feature branches have been merged into the main branch and closed.
[ ] The feature utility, function and usage have been documented in the respective project wiki on github.
Domain
app backend
Description
General Intro
The initialisation prompt is administered by the entrepreneur-user who is “forming” and deploying different instances of the app to perform as different types of agents for common-users of different backgrounds.
The components for custom context (Jan / Dave) are supposed to be administered only by common-users who do not have access to the initialisation prompt (Google Docs) but are the receivers of the questions included in that prompt when they log in to the app instance that is tied to a specific prompt or when the initialisation prompt gets updated by the entrepreneur-user.
entrepreneur-user:
Creates and deploys different instances of the same app / pipeline. One instance is the one we are creating that has to do with lifestyle advice for persistent health problems. The initialisation prompt asks from common users to provide details about their medical background. food preferences etc. The entrepreneur user, in the future, could take the same app backbone and after changing a) the link to the google docs where the initialisation prompt is hosted b) the links to the embeddings DB c) some custom prompts which in our case are unfortunately not easily decoupled from the codebase they could turn the app backbone into essentially a different app which is let’s say for a common-user who is a biologist and does research on sth. of that field. The initialisation prompt, the embeddings and the custom prompts should be different at that case. This is not our job though for this project. We are only focusing on making a) the backbone so that the app can accommodate several common-user use cases (person with persistent health problems, biologist, economist…) and b) we create just one instance of these as a POC.
common-user:
The common-user lives in the walled garden that the entrepreneur-user have created for them. They receive an app that has been tailored for their needs without being able to turn the app into something else (unlike with the entrepreneur user). The common-user has the option to pass custom context (chatGPT style) to the LLM through the custom context fields that Jan / Dave have built.
An analogy: if the common user was a single docker container the entrepreneur-user would be kubernetes.
More specific about this task
The asnwers entered by the common user as a result of their interaction with the agent who has been fed with the initialisation prompt [ See #214, #220 ] will need to be saved in some structured way in the system so that they can form the basis of the common-user medical / nutritional / fitness profile and then get combined with the custom scraped context and the LLM language delivery capabilities in order to customise the agent to each common-user.
Maybe it makes sense to use a tagging / keywording system routed to the database to allow this user information to easily be matched with other custom context derived by the scraped data.
Maybe this can be done via the embeddings.
This saved medical / nutritional / fitness / preferences profile will then inform the rest of the interaction of the common-user with the system.
User Story
Acceptance Criteria
Definition of Done