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.
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 initialisation prompt is managed by the entrepreneur-user via the google docs document which is fetched in the model. See backlog item #214.
The initialisation prompt asks the common-user (not the entrepreneur-user) sequential questions at the very beginning of the common-user interaction with the app / model in order to save basic health and nutrition information and possibly other parameters about them. For example: age, weight, food allergies, fitness status, medical diagnoses (maybe even provide the ability for the common user to upload medical charts and imaging results so that a capable LLM can extract additional details about them).
User Story
As an entrepreneur-user,
I want an easy way to capture common-user data related to the common-user medical, nutritional and fitness status
so that I can provide the common-user with a customised agent.
Acceptance Criteria
[ ] The intialisation prompt includes questions about:
[ ] information such as age, weight etc.
[ ] personal nutritional information such as food allergies.
[ ] personal nutritional preferences (likes, dislikes).
[ ] personal information such as fitness, activity, mobility restrictions etc.
[ ] medical diagnoses such as certain persistent (chronic) conditions.
[ ] the goals of the common-user (what they want to achive).
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 initialisation prompt is managed by the entrepreneur-user via the google docs document which is fetched in the model. See backlog item #214.
The initialisation prompt asks the common-user (not the entrepreneur-user) sequential questions at the very beginning of the common-user interaction with the app / model in order to save basic health and nutrition information and possibly other parameters about them. For example: age, weight, food allergies, fitness status, medical diagnoses (maybe even provide the ability for the common user to upload medical charts and imaging results so that a capable LLM can extract additional details about them).
User Story
Acceptance Criteria
Definition of Done