Merge branch 'main' of git.andr3h3nriqu3s.com:andr3/fyp-report
All checks were successful
continuous-integration/drone/push Build is passing
All checks were successful
continuous-integration/drone/push Build is passing
This commit is contained in:
commit
7505dc25e8
@ -187,10 +187,11 @@
|
||||
The web app is where users manage models, and data. The user will access the web app and configure the model, and manage that data set.
|
||||
|
||||
\subsection{JSON API}
|
||||
A big part of a software as a service is the ability to communicate with other services, nowadays, the way that systems communicate with each other is using mostly JSON and Rest APIs \cite{json-api-usage-stats}. Since the system will need to be communicated with other services to work as intended.
|
||||
|
||||
A big part of a SaaS is the ability to communicate with other services, nowadays, the way that systems communicate with each other is using mostly JSON and Rest APIs \cite{json-api-usage-stats}. Since the system will need to be communicated with other services to work as intended.
|
||||
|
||||
\subsection{Server Management}
|
||||
Since AI training is notoriously expensive the system cannot run on one server alone, as this would put too much strain in that server.
|
||||
Since AI training is notoriously expensive, the system cannot run on one server alone, as this would put too much strain in that server.
|
||||
The system needs to be able to distribute the load between the multiple servers.
|
||||
For that reason, the service needs to both be able to send training and prediction jobs to servers that have the resources to train models or predict classes from images.
|
||||
|
||||
@ -220,6 +221,18 @@
|
||||
\item{The user requests the classification or confirmation of an image}
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Webapp}
|
||||
|
||||
The goal of the project is to provide a software as a service platform for classification tasks with that in mind the service needs to have a way of controlling it. This will be achieved with a web interface.
|
||||
|
||||
The web-interface will have to manage:
|
||||
\begin{itemize}
|
||||
\item{User Data}
|
||||
\item{Model Data}
|
||||
\item{Dataset Data}
|
||||
% TODO maybe resourse data e.i. the resourses the system is using to manage everthing
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Generation Models}
|
||||
The system requires the generation of models \ref{fig:expandable_models_generator}. Generating all models based on one single model would decrease the complexity of the system, but it would not guarantee success.
|
||||
|
||||
@ -246,7 +259,13 @@
|
||||
|
||||
The TP when training the model decides when the training is finished, this could be when the training time has finished or if the model accuracy is not substantially increasing within the last training rounds.
|
||||
|
||||
During the training process the TP needs to also cache the dataset being used, this is because to create one model, the system might try to generate more than on model and match the best of the generated models with
|
||||
During the training process the TP needs to cache the dataset being used, this is because to create one model, the system might have to generate and train more than one model, during this process if the dataset is not cached then time is spent reloading the dataset into memory.
|
||||
|
||||
|
||||
\pagebreak
|
||||
\section{Design Choices}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user