5c982fcc2c
- Improvements to EntitlementsDomain & Services - Prechecks in Document domain - Add audit information to LicenseUsage
85 lines
4.4 KiB
Markdown
85 lines
4.4 KiB
Markdown
# Evie Overview
|
||
|
||
Owner: pieter Laroy
|
||
|
||
# Introduction
|
||
|
||
The Evie project (developed by AskEveAI) is a SAAS product that enables SMEs to easily introduce AI optimisations for both internal and external use. There are two big concepts:
|
||
|
||
- Catalogs: these allow tenants to store information about their organisations or enterprises
|
||
- Specialists: these allow tenants to perform logic into their processes, communications, …
|
||
|
||
As such, we could say we have an advanced RAG system tenants can use to optimise their workings.
|
||
|
||
## Multi-tenant
|
||
|
||
The application has a multi-tenant setup built in. This is reflected in:
|
||
|
||
- The Database:
|
||
- We have 1 public schema, in which general information is defined such as tenants, their users, domains, licenses, …
|
||
- We have a schema (named 1, 2, …) for each of the tenants defined in the system, containing all information on the tenant’s catalogs & documents, specialists & interactions, …
|
||
- File Storage
|
||
- We use S3-compatible storage
|
||
- A bucket is defined for each tenant, storing their specific documents, assets, …
|
||
|
||
That way, general information required for the operation of Evie is stored in the public schema, and specific and potentially sensitive information is nicely stored behind a Chinese wall for each of the tenants.
|
||
|
||
## Partners
|
||
|
||
We started to define the concept of a partner. This allows us to have partners that introduce tenants to Evie, or offer them additional functionality (specialists) or knowledge (catalogs). This concept is in an early stage at this point.
|
||
|
||
## Domains
|
||
|
||
In order to ensure a structured approach, we have defined several domains in the project:
|
||
|
||
- **User**: the user domain is used to store all data on partners, tenants, actual users.
|
||
- **Document**: the document domain is used to store all information on catalogs, documents, how to process documents, …
|
||
- **Interaction**: This domain allows us to define specialists, agents, … and to interact with the specialists and agents.
|
||
- **Entitlements**: This domain defines all license information, usage, …
|
||
|
||
# Project Structure
|
||
|
||
## Common
|
||
|
||
The common folder contains code that is used in different components of the system. It contains the following important pieces:
|
||
|
||
- **models**: in the models folder you can find the SQLAlchemy models used throughout the application. These models are organised in their relevant domains.
|
||
- **eveai_model**: some classes to handle usage, wrappers around standard LLM clients
|
||
- **langchain**: similar to eveai_model, but in the langchain library
|
||
- **services**: I started to define services to define reusable functionality in the system. There again are defined in their respective domains
|
||
- **utils**: a whole bunch of utility classes. Some should get converted to services classes in the future
|
||
- **utils/cache**: contains code for caching different elements in the application
|
||
|
||
## config
|
||
|
||
The config folder contains quite some configuration data (as the name suggests):
|
||
|
||
- **config.py**: general configuration
|
||
- **logging_config.py**: definition of logging files
|
||
- **model_config.py**: obsolete
|
||
- **type_defs**: contains the lists of definitions for several types used throughout the application. E.g. processor_types, specialist_types, …
|
||
- **All other folders**: detailed configuration of all the types defined in type_defs.
|
||
|
||
## docker
|
||
|
||
The docker folder contains the configuration and scripts used for all operations on configuring and building containers, distributing containers, …
|
||
|
||
## eveai_… folders
|
||
|
||
These are different components (containerized) of our application:
|
||
|
||
- **eveai_api**: The API of our application.
|
||
- **eveai_app**: The administrative interface of our application.
|
||
- **eveai_beat**: a means to install batch processes for our application.
|
||
- **eveai_chat**: obsolete at this moment
|
||
- **eveai_chat_workers**: celery based invocation of our specialists
|
||
- **eveai_client**: newly added. A desktop client to invoking specialists.
|
||
- **eveai_entitlements**: celery based approach to handling business events, measuring and updating usage, …
|
||
- **eveai_workers**: celery based approach to filling catalogs with documents (embedding)
|
||
|
||
## Remaining folders
|
||
|
||
- **integrations**: integrations to e.g. Wordpress and Zapier.
|
||
- **migrations**: SQLAlchemy database migration files (for public and tenant schema)
|
||
- **nginx**: configuration and static files for nginx
|
||
- **scripts**: various scripts used to start up components, to perform database operations, … |