Work on thesis
This commit is contained in:
parent
a8fa8fd11c
commit
71a0022ac7
25 changed files with 589 additions and 1236 deletions
|
|
@ -20,8 +20,14 @@ in order to decrease the negative externality of misused AI.}
|
||||||
|
|
||||||
However, before generalising, the design of the framework is iteratively refined using the feedback acquired from applying it in practical contexts which in this case is the research and development of a smaller and a more complex AI component using the work-in-progress framework. The treatment is finding a simple design (less cognitively straining to use) which still leads to high-quality deployments as defined in Section \ref{section:requirements}. Questions \textbf{RQ2} and \textbf{RQ3} capture this process; for investigating the feedback acquired from iteratively working on the case --- which is the definition of action research --- is of immense valuable.
|
However, before generalising, the design of the framework is iteratively refined using the feedback acquired from applying it in practical contexts which in this case is the research and development of a smaller and a more complex AI component using the work-in-progress framework. The treatment is finding a simple design (less cognitively straining to use) which still leads to high-quality deployments as defined in Section \ref{section:requirements}. Questions \textbf{RQ2} and \textbf{RQ3} capture this process; for investigating the feedback acquired from iteratively working on the case --- which is the definition of action research --- is of immense valuable.
|
||||||
|
|
||||||
\section{Generalisability}
|
\section{Applicability \& generalisability}
|
||||||
|
|
||||||
To answer how well the design of \textit{GreatAI} can generalise (\textbf{RQ4}), interviews are conducted from a population of software engineers and data scientists with varying levels of professional background. Since me and my colleagues are likely to have a bias for (or against) the proposed designs, the first step of checking its applicability in other practical contexts is to ask the opinion of non-affiliated fellow practitioners.
|
In order to conclusively answer \textbf{RQ3} and \textbf{RQ4}, interviews are conducted from a population of software engineers and data scientists with varying levels of professional background. Since me and my colleagues are likely to have a bias for (or against) the proposed design, the first step of checking its applicability in other practical contexts is to ask the opinion of non-affiliated practitioners.
|
||||||
|
|
||||||
todo
|
First, before their interview, interviewees are requested to complete a questionnaire about their last completed AI project; the questions come from a subset of the SE4ML survey. They are also advised to take a quick look at the tutorial page\footnote{\href{https://great-ai.scoutinscience.com/tutorial/}{great-ai.scoutinscience.com/tutorial}} of the documentation. The interviews are divided into two halves. In the first part, after a brief introduction, participants are asked to solve a real-world task by finishing a partially completed example application using GreatAI, they are also encouraged to think out loud so that their feedback can be noted. Successfully completing the task creates a system implementing a known number of best-practices. This way, the added value --- in terms of larger number of implemented best-practices --- can be quantitatively analysed by comparing the qualities of the finished implementation with the previously given answers.
|
||||||
|
|
||||||
|
Notes are taken throughout the interviews and subsequently extended using reflective journaling \cite{halcomb2006verbatim} combined with thematic coding. After which, the insights from the interviewed professionals are distilled using the techniques of thematic analysis \cite{fereday2006demonstrating} following the methodologies of \cite{cruz2019catalog} and \cite{haakman2021ai}. These insights can then be combined with the numerical results to explain and elaborate on them.
|
||||||
|
|
||||||
|
The second half consists of a short survey allowing to create the Technology Acceptance Model (TAM) \cite{davis1989perceived} of the problem context. The ultimate goal of the presented library is to help increase the adoption rate of best practices. In order to reach that goal, first, the library itself has to gain adoption. TAM and its numerous variations provide means of measuring users' willingness of adopting new technologies. TAM has been widely applied in literature \cite{marangunic2015technology} and due to its general psychological origins, it proves to be effective in other areas of technology, not just software \cite{riemenschneider2002explaining}.
|
||||||
|
|
||||||
|
The parsimonious version of TAM will be utilised which was measured to have similar predictive power to that of the original TAM while having fewer variables \cite{wu2011user}. Parsimonious TAM observes three interconnected human aspects that influence the actual behaviour (adoption): perceived usefulness, perceived ease of use, and intention to use. Participants are asked 10 questions corresponding to these aspects about their experience using GreatAI. The questionnaire is shown in Appendix \ref{appendix:questions}. The internal consistency of the answers is calculated using Chronbach's Alpha \cite{bland1997statistics} after which the responses are reflected upon.
|
||||||
|
|
|
||||||
|
|
@ -4,48 +4,46 @@ Providing users with a high-level of abstraction is not unheard of in the domain
|
||||||
|
|
||||||
\section{Scope} \label{section:scope}
|
\section{Scope} \label{section:scope}
|
||||||
|
|
||||||
As highlighted by several case studies in Chapter \ref{chapter:background}, the transition from prototypes to production-ready systems is often named as the source of unexpected struggle. Maybe it is not a coincidence that a significant portion of the SE4ML best practices should be implemented in this phase as well. Unfortunately, it is easy to gloss over them while tackling the underestimated difficulties of this \textit{transition}. Therefore, the aim of GreatAI is to ease this step of the life-cycle, consequently, its scope is limited to the \textit{transition} step.
|
As highlighted by several case studies in Chapter \ref{chapter:background}, the transition from prototypes to production-ready systems is often named as the source of unexpected struggle. Maybe it is not a coincidence that a significant portion of the SE4ML best practices should be implemented in this phase. Unfortunately, it is easy to gloss over them while tackling the underestimated difficulties of this \textit{transition}. Therefore, the aim of GreatAI is to ease this step of the life-cycle, consequently, its scope is limited to the \textit{transition} step.
|
||||||
|
|
||||||
There have been attempts that at least partially address this issue, however, as we have seen in Chapter \ref{chapter:background}, these have limitations either from the perspective of best practices, or stemming from their difficulty to be adopted. To have the best chance of providing an easy-to-adopt solution, the scope has to be well-defined and limited. Because to understand the API of a library, users first have to understand its aim, surface, and have to become familiar with the problems it solves. Thus, focusing only on the \textit{transition} step seems reasonable. This step is highlighted in Figure \ref{fig:scope}.
|
There have been attempts that at least partially address this issue, however, as we have seen in Chapter \ref{chapter:background}, these have limitations either from the perspective of best practices, or stemming from their difficulty to be adopted. To have the best chance of providing an easy-to-adopt solution, the scope has to be well-defined and limited. For understanding the API of a library, users first have to understand its aim, surface, and have to become familiar with the problems it solves. Thus, focusing only on the \textit{transition} step seems reasonable. This step is highlighted in Figure \ref{fig:scope}.
|
||||||
|
|
||||||
\begin{figure}
|
\begin{figure}
|
||||||
\centering
|
\centering
|
||||||
\includegraphics[width=\linewidth]{figures/scope.drawio.png}
|
\includegraphics[width=\linewidth]{figures/scope.drawio.png}
|
||||||
\caption{Usual process steps in the development life-cycle of a data-heavy software solution. The dashed arrows denote optional paths: after a prototype has been completed, there are multiple options for its deployment. The steps with blue background show the scope of GreatAI.}
|
\caption{Usual process steps in the development life-cycle of a data-heavy software solution. The dashed arrows denote optional paths: after a prototype has been completed, there are multiple options for its deployment. The steps with blue background show the primary scope of GreatAI.}
|
||||||
\label{fig:scope}
|
\label{fig:scope}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
It is interesting to mention that there is a proliferation\footnote{\href{https://xkcd.com/927/}{xkcd.com/927}} of platform/software as a service (PaaS/SaaS) products for deploying AI\footnote{Such as \href{https://mlem.ai/}{MLEM}, \href{https://streamlit.io/cloud}{Streamlit} or any AutoML SaaS platform, for example, \href{https://www.akkio.com/role/software-engineers}{Akkio} as these often have a one-click deployment feature as well.}. At first, these may look promising, however, they tend to only focus on getting code easily deployed in the cloud: AI best practices are not prioritised in this setup. Nevertheless, in many cases, it may be a suitable option to use such a service and these can also complement GreatAI as illustrated in Figure \ref{fig:scope}. First, the prototype is transformed into a GREAT service and materialised as a common software artifact implementing the best practices. Then, it is either deployed using a deployment SaaS, or by using the organisation's existing software deployment setup.
|
It is interesting to mention that there is a proliferation\footnote{\href{https://xkcd.com/927/}{xkcd.com/927}} of platform/software as a service (PaaS/SaaS) products for deploying AI\footnote{Such as \href{https://mlem.ai/}{MLEM}, \href{https://streamlit.io/cloud}{Streamlit} or any AutoML SaaS platform, for example, \href{https://www.akkio.com/role/software-engineers}{Akkio} as these often have a one-click deployment feature as well.}. At first, these may look promising, however, they tend to only focus on getting code easily deployed in the cloud: AI best practices are not prioritised in this setup. Nevertheless, in many cases, it may be a suitable option to use such a service and these can also complement GreatAI as illustrated in Figure \ref{fig:scope}: first, the prototype is transformed into a GREAT service and materialised as a common software artifact implementing the best practices. Then, it is either deployed using a deployment SaaS, or by using the organisation's existing software deployment setup.
|
||||||
|
|
||||||
\section{Requirements} \label{section:requirements}
|
\section{Requirements} \label{section:requirements}
|
||||||
|
|
||||||
The best practices (which will be referenced throughout the thesis) with which the \textit{GreatAI} design is concerned are a subset of those compiled by Serban et al. \cite{serban2020adoption}. The core requirements --- sets of covered best practices --- for a software solution that has the potential of improving our problem context are presented in the following along with some explanation and clarification of each of them.
|
The best practices (which are referenced throughout the thesis) with which the \textit{GreatAI} design is concerned are a subset of those compiled by Serban et al. \cite{serban2020adoption} and John et al. \cite{john2020architecting}. The core requirements --- set of covered best practices --- for a software solution that has the potential of improving our problem context are presented in the following along with some explanation and clarification of each of them.
|
||||||
|
|
||||||
\paragraph{General} Albeit not explicitly in the list of best practices, compatibility is vital in encouraging adoption. Large projects oftentimes end up depending on numerous packages, each of which may impose some restrictions on the code: since these all have to be satisfied simultaneously, this can result in severe constraints on the application.
|
\paragraph{General} Albeit not explicitly in the list of best practices, compatibility is vital in encouraging adoption. Large projects oftentimes end up depending on numerous packages, each of which may impose some restrictions on the code: since these all have to be satisfied simultaneously, this can result in severe constraints on the application.
|
||||||
|
|
||||||
The open-source scene of data-related libraries is vibrant. To take the example of data validation, there are at least 4 popular choices which offer varying but similar features: \href{https://github.com/SeldonIO/alibi-detect}{Alibi detect}, \href{https://github.com/PAIR-code/facets}{Facets}, \href{https://github.com/great-expectations/great_expectations}{Great Expectations}, and Data Linter \cite{hynes2017data}. The responsibility of choosing the most fitting solution falls on the user, thus, they should not be limited in this by \textit{GreatAI}.
|
The open-source scene of data-related libraries is vibrant. To take the example of data validation, there are at least 4 popular choices which offer varying but similar features: \href{https://github.com/SeldonIO/alibi-detect}{Alibi detect}, \href{https://github.com/PAIR-code/facets}{Facets}, \href{https://github.com/great-expectations/great_expectations}{Great Expectations}, and Data Linter \cite{hynes2017data}. The responsibility of choosing the most fitting solution falls on the user, thus, they should not be limited in this by \textit{GreatAI}. The programming language (PL) of the library should be its only non-general property. Fortunately, the de facto PL for data science is Python, hence, implementing the library in it should not significantly limit its applicability.
|
||||||
|
|
||||||
The programming language (PL) of the library should be its only non-general property. Fortunately, the de facto PL for data science is Python, hence, implementing the library in it should not significantly limit its applicability.
|
\paragraph{Robustness} in software development can be achieved by preparing the application to gracefully handle errors, even unexpected ones \cite{bishop1998robust}. Errors can and will happen in practice: storing and investigating what has led to them is required to prevent future ones. In the case of ML, errors might not be as obvious to detect as in more traditional applications (see the above mentioned data validators). Even if a single feature's value falls outside the expected distribution, unexpected results can happen. In cases where this might lead to real-world repercussions, extra care has to be taken to construct as many safe-guards as feasible. \textit{GreatAI} should support its clients in this.
|
||||||
|
|
||||||
\paragraph{Robustness} in software development can be achieved by preparing the application to gracefully handle errors, even unexpected ones \cite{bishop1998robust}. Errors can and will happen in practice: storing and investigating what has led to them is required to prevent future ones. In the case of ML, errors might not be as obvious to detect as in more traditional applications (see the above mentioned data validators). Even if a single feature's value falls outside the expected distribution, unexpected results can happen. In cases where this might lead to real-world repercussions, extra care has to be taken to construct as many safe-guards as feasible. \textit{GreatAI} should support its clients in doing so.
|
\paragraph{End-to-end} In this case, it refers to end-to-end feedback. That is, feedback should be gathered on the real-world performance of the system and this should be taken into account when designing/training the next iteration of the model. Static datasets may fail to capture the changing nature of real-life and can become outdated if they are not revised continuously. A well packaged deployment should make it trivial to integrate new training data.
|
||||||
|
|
||||||
\paragraph{End-to-end} In this case, it refers to end-to-end feedback. That is, feedback should be gathered on the real-world performance of the system, and this should be taken into account when designing/training the next iteration of the model. Static datasets may fail to capture the changing nature of real-life and can become outdated if they are not revised continuously. A well packaged deployment should make it trivial to integrate new training data.
|
|
||||||
|
|
||||||
\paragraph{Automated} The available time of data scientists and software engineers is limited and expensive. For this reason, humans should only be involved when their involvement is necessary. Steps in the development process that can be automated without negative consequences must be automated in order to achieve efficient development processes and let the experts focus on the issues that require their attention the most.
|
\paragraph{Automated} The available time of data scientists and software engineers is limited and expensive. For this reason, humans should only be involved when their involvement is necessary. Steps in the development process that can be automated without negative consequences must be automated in order to achieve efficient development processes and let the experts focus on the issues that require their attention the most.
|
||||||
|
|
||||||
\paragraph{Trustworthy} As detailed by the \textit{Ethics guidelines for trustworthy AI}\footnote{\href{https://digital-strategy.ec.europa.eu/en/library/ethics-guidelines-trustworthy-ai}{digital-strategy.ec.europa.eu/en/library/ethics-guidelines-trustworthy-ai}}, human oversight, transparency, and accountability are some of the key requirements for trustworthy AI applications. For increasing public acceptance and trust while minimising negative societal impact, trustworthiness is essential.
|
\paragraph{Trustworthy} As detailed by the \textit{Ethics guidelines for trustworthy AI}\footnote{\href{https://digital-strategy.ec.europa.eu/en/library/ethics-guidelines-trustworthy-ai}{digital-strategy.ec.europa.eu/en/library/ethics-guidelines-trustworthy-ai}}, human oversight, transparency, and accountability are some of the key requirements for trustworthy AI applications. For increasing public acceptance and trust while minimising negative societal impact, trustworthiness is essential.
|
||||||
|
|
||||||
These requirements were chosen stemming from their general importance and potential to be mostly handled (implemented) by a software framework\footnote{The terms \textit{framework} and \textit{library} are used interchangeably in this work stemming from their vague and often holistic differentiation.}. That is why, these provide an ideal initial direction for tackling the issue. Of course, these do not cover all best practices, for instance, the ones relating to organisational processes fall outside the realm of software engineering.
|
These requirements were chosen stemming from their general importance and potential to be mostly handled (implemented) by a software framework\footnote{The terms \textit{framework} and \textit{library} are used interchangeably in this work stemming from their vague and often holistic differentiation.}. That is why, these provide an ideal initial direction for tackling the issue. Of course, these do not cover all best practices, for instance, the ones relating to organisational processes fall outside the realm of computer science.
|
||||||
|
|
||||||
\section{Design principles}
|
\section{Design principles}
|
||||||
|
|
||||||
As implied in Section \ref{section:scope}, the Unix philosophy \cite{ritchie1978unix,salus1994quarter} of software design is followed. Most notably, the design goal that encourages to \textit{write programs that do one thing and do it well.}\footnote{Of course, \textit{write programs to work together} is also very much applicable, since allowing interoperability is one of the core requirements for GreatAI.}. Apart from providing a clear and simple picture of the intended use cases for the library, this is also in line with the main notion of \textit{A Philosophy of Software Design} \cite{ousterhout2018philosophy}: API-s should be narrow and deep. A narrow width refers to having a small exposed surface area, i.e. having a small number of functions and classes in the public API. While depth implies each of them accomplishing an involved, complex goal.
|
As implied in Section \ref{section:scope}, the Unix philosophy \cite{ritchie1978unix,salus1994quarter} of software design is followed. Most notably, the design goal that encourages to \textit{write programs that do one thing and do it well.}\footnote{Of course, \textit{write programs to work together} is also very much applicable, since allowing interoperability is one of the core requirements for GreatAI.}. Apart from providing a clear and simple picture of the intended use cases for the library, this is also in line with the main notion of \textit{A Philosophy of Software Design} \cite{ousterhout2018philosophy}: API-s should be narrow and deep. A narrow width refers to having a small exposed surface area, i.e. having a small number of functions and classes in the public API. While depth implies each of them accomplishing an involved, complex goal.
|
||||||
|
|
||||||
In a way, the API-s width is the price the users have to pay (the effort required for learning it) to use it, while the depth is analogous to the return they get from it. Having to learn little and being provided by a lot of functionality maximises return on investment, hence, developer experience (DX). The theoretical frameworks presented in \textit{The Programmer's Brain} \cite{hermans2021programmer} provides us with explanations and vocabulary from psychology for arguing about the cognitive aspects of API designs. In the following, two of them will be used for detailing the design principles: cognitive dimensions of code bases (CDCB) which is an extension of the cognitive dimensions of notation (CDN) framework \cite{blackwell2001cognitive}, and linguistic antipatterns \cite{arnaoudova2016linguistic}. The former comes with a set of dimensions which describe different (often competing) cognitive aspects of code that influence one's ability to perform certain tasks with it.
|
In a way, the width of an API is the price users have to pay (the effort required for learning it) to use it, while the depth is analogous to the return they get from it. Having to learn little and being provided by a lot of functionality maximises return on investment (ROI), hence, developer experience (DX). The theoretical frameworks presented in \textit{The Programmer's Brain} \cite{hermans2021programmer} provides us with explanations and vocabulary from psychology for arguing about the cognitive aspects of API designs. In the following, two of them will be used for detailing the design principles: cognitive dimensions of code bases (CDCB) which is an extension of the cognitive dimensions of notation (CDN) framework \cite{blackwell2001cognitive}, and linguistic antipatterns \cite{arnaoudova2016linguistic}. The former comes with a set of dimensions which describe different (often competing) cognitive aspects of code that influence one's ability to perform certain tasks with it.
|
||||||
|
|
||||||
While linguistic antipatterns provide guidelines for improving consistency and decreasing the false sense of consistency when there is none. Also, choosing the right names for identifiers can help activate information stored in the long-term memory which makes it quicker to comprehend and easier to reason about the code \cite{deissenboeck2006concise}. Finding the most accurate and useful names is harder than it first seems. Accuracy and usefulness are already often competing goals. The more precise the name, the longer and therefore less convenient to use \cite{butler2009relating}. In short, good names are key to good API-s; consciously considering the implications of names has to be an integral part of the design process.
|
Linguistic antipatterns provide guidelines for improving consistency and decreasing the false sense of consistency when there is none. Also, choosing the right names for identifiers can help activate information stored in the long-term memory which makes it quicker to comprehend and easier to reason about the code \cite{deissenboeck2006concise}. Finding the most accurate and useful names is harder than it first seems. Accuracy and usefulness are already often competing goals. The more precise the name, the longer and therefore less convenient to use \cite{butler2009relating}. In short, good names are key to good API-s; consciously considering the implications of names has to be an integral part of the design process.
|
||||||
|
|
||||||
Nonetheless, simple API-s come at a high technical cost. The library has to implement these in a way that still allows high-performance in production \cite{kleppmann2017designing} and avoids being tied to specific libraries or technologies. Inspiration for the latter may be gained from the pipelines of Prado et al. \cite{prado2020bonseyes}: they show that more freedom can be achieved with plug-and-play steps and preconfigured defaults.
|
Nonetheless, simple API-s come at a high technical cost. The library has to implement these in a way that still allows high-performance in production \cite{kleppmann2017designing} and avoids being tied to specific libraries or technologies. Inspiration for the latter may be gained from the ML pipelines of Prado et al. \cite{prado2020bonseyes}: they show that more freedom can be achieved with plug-and-play steps and preconfigured defaults.
|
||||||
|
|
||||||
Before diving into the concrete issues solved, let us detail the principles that should be used for implementing them in the scope of this framework.
|
Before diving into the concrete issues solved, let us detail the principles that should be used for implementing them in the scope of this framework.
|
||||||
|
|
||||||
|
|
@ -53,32 +51,32 @@ Before diving into the concrete issues solved, let us detail the principles that
|
||||||
|
|
||||||
Existing frameworks oftentimes suffer from the entanglement of numerous levels of abstractions. Instead of exposing each implementation detail and encouraging users to interact with most of them, many of these could be abstracted away. Where configuration may be helpful for advanced users, default values can still be chosen automatically while providing an override option where necessary.
|
Existing frameworks oftentimes suffer from the entanglement of numerous levels of abstractions. Instead of exposing each implementation detail and encouraging users to interact with most of them, many of these could be abstracted away. Where configuration may be helpful for advanced users, default values can still be chosen automatically while providing an override option where necessary.
|
||||||
|
|
||||||
For example, tracing the evaluations and the model versions used in a distributed fashion is very much expected of a trustworthy system. Hence, turning this feature on by default but allowing opting-out from it can result in less scaffolding required from the library's user. It also decreases their up-front cognitive load which by definition flattens the learning-curve \cite{hermans2021programmer}. Similar features can be imagined for providing an access API for the algorithms and for giving feedback, marking outliers, etc.
|
For example, tracing the evaluations and the model versions used in a distributed fashion is very much expected of a trustworthy system. Hence, turning this feature on by default but allowing opting-out from it can result in less scaffolding required from the library's users. It also decreases their up-front cognitive load which by definition flattens the learning-curve \cite{hermans2021programmer}. Similar features can be imagined for providing a service API for the algorithms and for giving feedback, marking outliers, etc.
|
||||||
|
|
||||||
Being \textit{automated} is listed as a requirement but it is imperative to only automate for simplifying and not for hiding decisions. More precisely, guessing must not be a part of automation. For instance --- an otherwise incredibly useful WebGL library --- TWGL.js\footnote{\href{https://twgljs.org/}{twgljs.org}} has a feature for automatically guessing the type of vectors based on their names. If it matches the \texttt{/colou?r/i} pattern, it is treated as a vector with 3 components\footnote{\href{https://github.com/greggman/twgl.js/blob/e3a8d0ed09f7f5cd4be0e4cb5976081c2b5013aa/src/attributes.js\#L139}{\tiny github.com/greggman/twgl.js/blob/e3a8d0ed09f7f5cd4be0e4cb5976081c2b5013aa/src/attributes.js\#L139}}. It is easy to imagine that this can help in certain scenarios, but it does so at the cost of immense confusion when renaming a variable breaks the application. In CDCB, this equates to scoring high on the dimension of \textit{Hidden dependencies} and low on \textit{Visibility}.
|
Being \textit{automated} is listed as a requirement but it is imperative to only automate for simplifying and not for hiding decisions. More precisely, guessing must not be a part of automation. For instance --- an otherwise incredibly useful WebGL library --- TWGL.js has a feature for automatically guessing the type of vectors based on their names. If it matches the \texttt{/colou?r/i} pattern, it is treated as a vector with 3 components\footnote{\href{https://github.com/greggman/twgl.js/blob/e3a8d0ed09f7f5cd4be0e4cb5976081c2b5013aa/src/attributes.js\#L139}{\tiny github.com/greggman/twgl.js/blob/e3a8d0ed09f7f5cd4be0e4cb5976081c2b5013aa/src/attributes.js\#L139}}. It is easy to imagine that this can help in certain scenarios, but it does so at the cost of immense confusion when correctly renaming a variable breaks the application. In CDCB, this equates to scoring high on the dimension of \textit{Hidden dependencies} and low on \textit{Visibility}.
|
||||||
|
|
||||||
Learning from this, any kind of guessing must be avoided for creating a pleasant API. However, this is in conflict with providing defaults for each configuration value. Even if these would be reasonable defaults derived from educated guesses, they are still merely guesses. Nevertheless, if the users are required to specify each configuration option, that leads to considerably more boilerplate code. This verbosity is captured by the \textit{Diffuseness} dimension of CDCB and, of course, should be minimised.
|
Learning from this, any kind of guessing must be avoided for creating a pleasant API. However, this is in conflict with providing defaults for each configuration value. Even if these would be reasonable defaults derived from educated guesses, they are still merely guesses. Nevertheless, if the users were required to specify each configuration option, that would lead to considerably more boilerplate code. This verbosity is captured by the \textit{Diffuseness} dimension of CDCB and, of course, should be minimised.
|
||||||
|
|
||||||
To resolve this conflict, GreatAI should have recommended values instead of defaults. This can mean a context object (as suggested in \cite{ousterhout2018philosophy}), which contains the result of each design decision that has to be made for a service's deployment. If not configured manually, the recommended values are applied, just like defaults. The values chosen for each parameter must be clearly highlighted. Coming from the library's single responsibility, the number of parameters should not be immense, hence, the user can be expected to comprehend them instead of just being overwhelmed and skimming it.
|
To resolve this conflict, GreatAI should have recommended values instead of defaults. This can mean a context object (as suggested in \cite{ousterhout2018philosophy}), which contains the result of each design decision that has to be made for a service's deployment. If not configured manually, the recommended values are applied automatically, just like defaults. The values chosen for each parameter must be clearly highlighted. Coming from the library's single responsibility, the number of parameters should not be immense, hence, the user can be expected to comprehend them instead of just being overwhelmed and skimming it.
|
||||||
|
|
||||||
This way, the library attempts to notify its user about the existence of these decisions but does not force them to manually decide. As a result, no initial configuration is needed for starting out with the library (high \textit{Provisionality}, low \textit{Diffuseness}) and the dependencies are not hidden since they are explicitly highlighted.
|
This way, the library attempts to notify its user about the existence of these decisions but does not force them to manually decide. As a result, no initial configuration is needed for starting out with the library (high \textit{Provisionality}, low \textit{Diffuseness}) and the dependencies are not hidden since they are explicitly highlighted.
|
||||||
|
|
||||||
\subsection{Documentation}
|
\subsection{Documentation}
|
||||||
|
|
||||||
For structuring the documentation, the diátaxis approach is taken \cite{Procida_Diataxis_documentation_framework} which prescribes dividing documentation into 4 parts along 2 axes: practical-theoretical and passive-active consumption. The four quadrants derived from this are tutorials, how-to guides, reference, and explanation.
|
For structuring the documentation, the \textit{Diátaxis} philosophy is preferred \cite{Procida_Diataxis_documentation_framework} which prescribes dividing documentation into 4 parts along 2 axes: practical-theoretical and passive-active consumption. The four quadrants derived from this are: tutorials, how-to guides, reference, and explanation.
|
||||||
|
|
||||||
Without a doubt, good documentation is a prerequisite for adoption. Documentation comes in multiple forms: modern integrated development environments (IDEs) tend to show a popup of a function's documentation when requested, at the same time a more comprehensive online documentation and example projects are also still expected. But descriptive error messages can be also viewed as documentation. The library should have quality documentation for all categories.
|
Without a doubt, good documentation is a prerequisite for adoption. Documentation can comes in many shapes: modern integrated development environments (IDEs) tend to show a popup of a function's documentation when requested (on mouse hover for instance), at the same time a more comprehensive online documentation and example projects are also still expected. But descriptive error messages can be also viewed as documentation. The library should have quality documentation for all categories.
|
||||||
|
|
||||||
Once again, we might notice two competing interests: the level-of-detail and the length of the documentation. For example, FastAPI\footnote{\href{https://fastapi.tiangolo.com/async/\#concurrent-burgers}{fastapi.tiangolo.com}}, a popular Python web framework, has extensive descriptions and explanations on all topics related to Python's import system, the HTTP protocol, concurrency, deployment, etc. The actual framework's documentation is sprinkled over these very broad topics. This is certainly helpful for beginners to acquire knowledge from a single place. Nevertheless, this high-level of accessibility actually hinders the process of finding the relevant sections (in CDCB, this shows a trade-off between the support of Searching and Comprehension tasks). My opinion is that linking to external resources about the library's domain are welcome, but the documentation must have a single responsibility: describing the library itself.
|
Once again, we might notice two competing interests: the level-of-detail and the length of the documentation. For example, FastAPI\footnote{\href{https://fastapi.tiangolo.com/async/\#concurrent-burgers}{fastapi.tiangolo.com}}, a popular Python web framework, has extensive descriptions and explanations on all topics related to Python's import system, the HTTP protocol, concurrency, deployment, etc. The actual framework's documentation is sprinkled over these very broad topics. This is certainly helpful for beginners to acquire knowledge from a single place. Nevertheless, this high-level of accessibility actually hinders the process of finding the relevant sections (in CDCB, this shows a trade-off between the support of \textit{Searching} and \textit{Comprehension} tasks). My (and Diátaxis') take is that linking to external resources about the library's domain are welcome, but the documentation must have a single responsibility: describing the library itself.
|
||||||
|
|
||||||
A large portion of software documentations is automatically generated from source code. This has the advantage of always keeping it in sync with code changes, however, it might also signal that the API is too large, since it is inconvenient for the developers to document it by hand.
|
A large portion of software documentations is automatically generated from source code. This has the advantage of always keeping it in sync with code changes, however, it might also signal that the API is too large because it is inconvenient for the developers to document it by hand. Striking the right balance between handcrafted and automatically extracted documentation may be a vital component of good documentation.
|
||||||
|
|
||||||
When it comes to example code, showing at least the minimal starter code, and the way of customising it has to be showcased front and centre. It is a well-known observation that developers only read documentation when they are stuck and there might be some merit to this. Making them not get stuck --- by providing a starter code from which they can explore the API using IntelliSense-like solutions --- should be preferred. For example, another widely popular Python web framework, Flask\footnote{\href{https://flask.palletsprojects.com/en/2.1.x/}{flask.palletsprojects.com/en/2.1.x}}, at this time, has 324 uniformly styled links on its landing page. Out of these, only 2 lead to the quick start code. Of course, it is not hidden, but I argue that the DX could be improved by displaying it more prominently.
|
When it comes to example code, showing at least the minimal starter code, and the way of customising it has to be showcased front and centre. It is a well-known observation that developers only read documentation when they are stuck and there might be some merit to this. Making them not get stuck --- by providing a starter code from which they can explore the API using IntelliSense-like solutions --- should be preferred. For example, another widely popular Python web framework, Flask\footnote{\href{https://flask.palletsprojects.com/en/2.1.x/}{flask.palletsprojects.com/en/2.1.x}}, at this time, has 324 homogeneously styled links on its landing page. Out of these, only 2 lead to the quick start code. Of course, it is not hidden, but I argue that the DX could be improved by displaying where to start more prominently.
|
||||||
|
|
||||||
\subsection{Developer experience}
|
\subsection{Developer experience}
|
||||||
|
|
||||||
Subjectively, the key to good DX is consistency and discoverability. To give an example, the MySQL connector's Python implementation\footnote{\href{https://dev.mysql.com/doc/connector-python/en/}{dev.mysql.com/doc/connector-python/en/}} has a cursor object which exposes a \texttt{fetchone} method. Even though this naming scheme is not conventional in Python since it does not follow \href{https://peps.python.org/pep-0008/}{PEP 8}, at least the API is logical: changing \texttt{sql\_cursor.fetchone()} to \texttt{sql\_cursor.fetchall()} returns all items instead of just one. Using good and consistent names is the key to good DX.
|
Subjectively, a key component of good DX is \textit{Progressive evaluation} through which development can become a highly iterative, experimental process. This is well understood by popular Data Science tools, such as Jupyter Notebooks. GreatAI also has to support some level of this, for example, in the form of auto-reload on code changes. Another key ingredients for good DX are consistency and discoverability. To give one more example, the MySQL connector's Python implementation\footnote{\href{https://dev.mysql.com/doc/connector-python/en/}{dev.mysql.com/doc/connector-python/en/}} has a cursor object which exposes a \texttt{fetchone} method. Even though this naming scheme is not conventional in Python since it does not follow \href{https://peps.python.org/pep-0008/}{PEP 8}, at least the API is intuitive: changing \texttt{sql\_cursor.fetchone()} to \texttt{sql\_cursor.fetchall()} returns all items instead of just one. Using good and consistent names is the key to good DX.
|
||||||
|
|
||||||
Also, Python codebases are rarely strictly object-oriented (OO), they are a mix of functional, data-driven, and OO programming. Consequently, relying on classes for grouping related functions is not always desirable. Therefore, it is even more imperative to name similar functions similarly. This helps discoverability and chunking \cite{hermans2021programmer} which amount to quicker comprehension.
|
At the same time, Python codebases are rarely strictly object-oriented (OO), they are a mix of the functional, data-driven, and OO paradigms. Consequently, relying on classes for grouping related functions is not always desirable. Therefore, it is even more imperative to name similar functions similarly. This helps discoverability and chunking \cite{hermans2021programmer} which amount to quicker comprehension.
|
||||||
|
|
||||||
There is one more reason to prefer consistency. Humans have a limited short-term memory (STM) \cite{miller1956magical}. Even though flags as function parameters are frowned upon by some \cite{martin2009clean}, they are useful, especially, when configuring libraries. However, if there is no convention for the default value of a flag, clients have to remember the flag's name and initial value at the same time, quickly overloading their STM. Thus, in the codebase, all defaults must be \texttt{False}. Sometimes, it can result in a \textit{disable} prefix, which turn into a double negation, users shouldn't ever encounter this themselves since the doubly-negated version is the default, thus when overriding it, it is only singly-negated. This approach also implies, that something may be recommended to be turned on by default.
|
There is one more reason to prefer consistency: humans have a limited short-term memory (STM) \cite{miller1956magical}. Even though flags as function parameters are frowned upon by some \cite{martin2009clean}, they are useful, especially, when configuring libraries. However, if there is no convention for the default value of a flag, clients have to remember the flag's name and initial value at the same time, quickly overloading their STM. Thus, in the codebase, all defaults must be \texttt{False}. Sometimes, it can result in a \textit{disable} prefix which may turn into a double negation, nevertheless, users should not ever encounter this themselves since the doubly-negated version is the default, thus when overriding it, it is only singly-negated. This approach also implies, that something may be recommended to be turned on by default.
|
||||||
|
|
|
||||||
|
|
@ -1,37 +0,0 @@
|
||||||
\section{A complex case}
|
|
||||||
|
|
||||||
Let us now turn our attention towards a more complex component. The ScoutinScience Dashboard contains a full-page evaluation view for each academic publication. On this, the known metadata, historical data about the paper's topics, social media mentions, a PDF viewer showing the document, and other augmentation tools are displayed. One of these is the \textit{interesting sentences} section, which aims to summarise the paper from a technology-transfer perspective.
|
|
||||||
|
|
||||||
The current approach uses a simple heuristic based on a set of phrases selected by business developers and extended with the help of a word2vec model \cite{mikolov2013efficient}. The user feedback deemed this implementation slightly helpful but not adequate for providing an accurate overview. Thus, this is the baseline that I attempt to improve on in this section.
|
|
||||||
|
|
||||||
\begin{displayquote}
|
|
||||||
Compared with Section \ref{section:simple-case}, this time around, the toolset of GreatAI is at our disposal. Hopefully, this will streamline the development and --- especially --- the deployment. Given its arguably higher complexity, this experiment falls closer to industrial use-cases, and hence, can give a more accurate feedback on how to further improve the API.
|
|
||||||
\end{displayquote}
|
|
||||||
|
|
||||||
\subsection{Background}
|
|
||||||
|
|
||||||
Automatic text summarisation (ATS) is one of earliest established problems of text analysis and boasts numerous promising results \cite{el2021automatic}. However, our problem requires generating a special type of summary: it must only concern a single aspect (tech-transfer) of the document. Aspect-based text summarisation has also seen some progress over the last decades \cite{berkovsky2008aspect,hayashi2021wikiasp}, but these approaches require concretely defined topics. Unfortunately, \textit{tech-transfer potential} is anything but a clear topic definition.
|
|
||||||
|
|
||||||
todo: extractive vs abstractive
|
|
||||||
|
|
||||||
Our numerous discussions and interviews with business developers over the last years made it clear that there is no universally agreed on definition for it. At least, all of them agrees that they know it when they see it. Additionally, most of them agree that they can confidently make a decision at the granularity of sentences. This gives rise to an obvious idea: show the experts something that they can annotate. Because the time of experts is valuable, and relevant sentences are few and far between, extra care needs to be taken to improve the ratio of positive examples in the dataset. The research of Iwatsuki Kenichi on formulaic expressions (FE) \cite{iwatsuki2020evaluation,iwatsuki2021extraction,iwatsuki2021communicative,iwatsuki2022extraction} provides a promising direction to do so.
|
|
||||||
|
|
||||||
A formulaic expression is a phrase with zero or more slots that expresses a certain intent. In the context of scientific texts, an example\footnote{Taken from the ground-truth data at \href{https://github.com/Alab-NII/FECFevalDataset/blob/master/human_evaluation/background.tsv}{github.com/Alab-NII/FECFevalDataset}} could be: \texttt{it was not until * that}. The asterisk can be substituted with multiple terms and the intention of this expression is (likely) to describe the \textit{History of the related topics}. Iwatsuki et al. identified a set of 39 intentions, compiled a manually labelled dataset \cite{iwatsuki2020evaluation}, and developed multiple approaches for automatically extracting and classifying formulaic expressions in large corpora \cite{iwatsuki2021communicative,iwatsuki2022extraction}.
|
|
||||||
|
|
||||||
\subsection{Methods}
|
|
||||||
|
|
||||||
In the following, we explore a 2-stage retrieval approach \cite{schutze2008introduction} commonly used in the field of information retrieval. The first stage is expected to filter out sentences that are certainly not relevant from a technology-transfer perspective using Iwatsuki's formulaic expression intention labels. Subsequently, the second stage utilises a fine-tuned SciBERT model to rank the remaining sentence based on a model learned from expert annotations.
|
|
||||||
|
|
||||||
This approach has multiple shortcomings, for the first stage, we must assume the independence of sentences and that the FE intentions are strongly correlated with the sought after aspect. Additionally, the reranking only considers the individual relevance of the sentences instead of the overall relevance (utility) of the summary. It is expected, that stemming from the length of the documents and the sparseness of the selected sentences, that any combination of them is likely to have low redundancy.
|
|
||||||
|
|
||||||
TODO
|
|
||||||
|
|
||||||
Finetuning SciBERT \cite{jurafsky2019speech}.
|
|
||||||
|
|
||||||
\subsection{Results}
|
|
||||||
|
|
||||||
For measuring the interrater agreement, Cohen's kappa \cite{cohen1960coefficient} is calculated as shown in Equation \ref{equation:kappa}.
|
|
||||||
|
|
||||||
\begin{equation} \label{equation:kappa}
|
|
||||||
\kappa_{agreement} \equiv \frac{p_{observed} - p_{expected}}{1 - p_{expected}} = 1 - \frac{1 - p_{observed}}{1 - p_{expected}}
|
|
||||||
\end{equation}
|
|
||||||
|
|
@ -1,43 +0,0 @@
|
||||||
\section{Bridging \textbf{the gap} with GreatAI}
|
|
||||||
|
|
||||||
This section briefly explores how the problems raised can be solved using GreatAI, and the API it provides to best fit the needs of its users. We first focus on the aspects of data, then, the automated wrapping of services, lastly we discuss the utility of helper functions.
|
|
||||||
|
|
||||||
Firstly, let us revisit the scope. As concluded in Section \ref{section:scope}, GreatAI should ease the \textit{transition} step between prototypes and production-ready deployments. However, this leaves open the question of what constitutes to this step? There are cross-cutting concerns such as the feature extraction code: for example, feature extraction is implemented and used in the training phase but it is also deployed alongside the model. The robustness criterion has to be met by this procedure after deployment even though its implementation is only in focus at the earlier stage of the project. Since having an untested function deployed into production can have severe repercussions, I believe, assuring its correctness lies within the scope of GreatAI.
|
|
||||||
|
|
||||||
\subsection{Data}
|
|
||||||
|
|
||||||
There are two kinds of data storage needs we need to address: training data and trained models. Because our code is probably already tracked under Git (and likely synced with GitHub), using the Git Large File Storage (LFS)\footnote{\href{https://git-lfs.github.com/}{https://git-lfs.github.com/}} might seem intriguing. However, it is a paid (and surprisingly expensive) service of GitHub especially when we factor in the expected sizes of the models and training data with the fact that the only way remove files counting towards our quota is to \href{https://docs.github.com/en/repositories/working-with-files/managing-large-files/removing-files-from-git-large-file-storage#git-lfs-objects-in-your-repository}{delete the repository}.
|
|
||||||
|
|
||||||
The Data Version Control (DVC)\footnote{\href{https://dvc.org/}{https://dvc.org/}} open-source project provides a nearly perfect solution. It comes with a command-line interface (CLI) inspired by git's, and it can be integrated with several backend storage servers. Its only downside is of course that it is one more tool that increases the complexity of the project and the initial setup time. If this is an acceptable price to pay, then I personally recommend opting for DVC. Nevertheless, if this may prohibit a team from properly handling data according to the best practices, I present a simpler solution in the following.
|
|
||||||
|
|
||||||
The complexity of an API can be decreased by relying on its users preexisting knowledge. Therefore, we can reuse familiar API-s, such as the \texttt{open()} method from Python. A method is proposed which provides the same interface, however, the backing storage for it is a mixture of local disk space, S3-compatible storage, MongoDB, or any other storage backend. It provides a superset of \texttt{open()}'s interface; the same parameters can be used with it.
|
|
||||||
|
|
||||||
Easing development isn't just about automating everything but also making the code easy to change (which is the \textit{Viscosity} dimension of CDCB). Going from opening a local file on the disk with the built-in open method, to opening a file from S3 is as easy as changing \texttt{with open('file.txt', 'w') as f: ...} to \texttt{with LargeFileS3('file.txt', 'w') as f: ...}. In the case of the latter, an additional \texttt{version} keyword argument can also be given to lock ourselves in using a certain version which is very much desired in the case of models.
|
|
||||||
|
|
||||||
The obstacles coming from the intertwined nature of different models is widely recognised \cite{sculley2015hidden,haakman2021ai,amershi2019software}. This can lead to non-monotonic error propagation, meaning that improvements in one part of the system might decrease the overall system quality \cite{amershi2019software}. The importance of schema versioning in an environment of rapidly changing models and transformations is highlighted and solved for a specific use-case in \cite{van2017versioning}.
|
|
||||||
|
|
||||||
The expected features: progress bar, caching, garbage collecting the cache, automatically deleting old remote version if requested are all present and come with recommended --- but easy to see and change --- configuration.
|
|
||||||
|
|
||||||
\subsection{Deployment approach}
|
|
||||||
|
|
||||||
% Should the order of the decorators matter? all except in one case, they're written in a way that the order doesn't matter even with the original semantics of decorators. In that one case, it cannot be written in that way. Instead of correcting a user's error, there's a mechanism looking for this error and the user is notified. Guessing the unspecified is cool, but correcting the wrong is not
|
|
||||||
|
|
||||||
to do
|
|
||||||
|
|
||||||
% During development, I wanted to check out which types of request fail -> log errors in traces
|
|
||||||
% Even production systems are not perfect, saving and letting the users filter on the errors is useful. e.g. they can correlate it with the input
|
|
||||||
|
|
||||||
% I use a toy example when quickly experimenting, it's important not to overfit on it ( moving it into the library would result in a online for it, so I have to consciously avoid that), but having a very simple
|
|
||||||
|
|
||||||
% Argumetn/parameter names were confusing
|
|
||||||
% offlinemode -> cacheonly mode
|
|
||||||
|
|
||||||
\subsection{Utilities}
|
|
||||||
|
|
||||||
It is easy to notice multiple recurring tasks when it comes to processing text. Cleaning it from various extraction artifacts and normalising characters is one of the most common. But splitting sentences, classifying its language, robustly lemmatizing are also surprisingly common tasks. Because having reusable and tested feature extraction code covers two best practices, it seems straightforward that a utility module could be created for this which can also be extensively tested by means of unit testing.
|
|
||||||
|
|
||||||
This is exactly the motivation behind \texttt{great\_ai.utilities}. Extra care has to be taken not to overfit these utilities on the cases considered in this chapter; I believe, these are versatile enough to be helpful in many text-related context. A conclusive answer to this assumption will be found during the interviews.
|
|
||||||
|
|
||||||
Implementing the unit tests uncovered multiple edge cases and even runtime errors, hence, the value in following the \textit{Test all Feature Extraction Code} best practice is cannot be doubted. There is one more best practice that should be partially covered here, especially, because it is useful both during batch inference, but also at training/feature extraction time: \textit{Enable Parallel Training Experiments}.
|
|
||||||
|
|
||||||
A function called \texttt{parallel\_map()} is implemented which closely mimicks the API of the built-in Python function: \texttt{map}. And it exemplifies how even a close to trivial function is able to improve the DX by magnitudes. Rooted in the global interpreter lock (GIL)\footnote{\href{https://wiki.python.org/moin/GlobalInterpreterLock}{wiki.python.org/moin/GlobalInterpreterLock}} of CPython, in almost all cases, multi-threading does not lead to higher performance of CPU-bound tasks. For this purpose, multiprocessing has to be used. Fortunately, the built-in \texttt{multiprocessing} library has a great API, however, it still takes about a dozen lines to do a parallel mapping task with a progressbar. This can deterr people (at least me) from taking advantage of more than just a single CPU core during explorative experimentation. With \texttt{parallel\_map()}, this challenge becomes a single-line, routine task.
|
|
||||||
|
|
@ -1,10 +0,0 @@
|
||||||
\input{chapters/5_case/introduction}
|
|
||||||
|
|
||||||
\input{chapters/5_case/naive-bayes}
|
|
||||||
\input{chapters/5_case/features}
|
|
||||||
|
|
||||||
\input{chapters/5_case/2-stage}
|
|
||||||
|
|
||||||
\input{chapters/5_case/refactoring}
|
|
||||||
|
|
||||||
\input{chapters/5_case/results}
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
\section{Refactoring with GreatAI}
|
|
||||||
4
docs/thesis/chapters/5_cases/main.tex
Normal file
4
docs/thesis/chapters/5_cases/main.tex
Normal file
|
|
@ -0,0 +1,4 @@
|
||||||
|
\input{chapters/5_cases/introduction}
|
||||||
|
\input{chapters/5_cases/naive-bayes}
|
||||||
|
\input{chapters/5_cases/scibert}
|
||||||
|
\input{chapters/5_cases/results}
|
||||||
|
|
@ -88,14 +88,111 @@ This is the usual point where papers conclude: a proof-of-concept/prototype has
|
||||||
|
|
||||||
\subsection{Deployment}
|
\subsection{Deployment}
|
||||||
|
|
||||||
First, an inference function needs to be written that can take an input on the fly and calculate a corresponding prediction. Since we aim to follow the best practices, namely: \textit{Explain Results and Decisions to Users} and \textit{Employ Interpretable Models When Possible}, giving an explanation of the results is expected. Fortunately, with our simple model it's easy to determine the most influential weights, thus, words. The last deployment step may be to provide access to our model for others.
|
First, an inference function needs to be written that can take an input on the fly and calculate a corresponding prediction. Since we aim to follow the best practices, namely: \textit{Explain Results and Decisions to Users} and \textit{Employ Interpretable Models When Possible}, giving an explanation of the results is expected. Fortunately, with our simple model it is easy to determine the most influential weights, thus, words; the explanations are derived by taking the top 5 tokens from the input text ranked by their feature weights. The last deployment step may be to provide access to our model for others.
|
||||||
|
|
||||||
\begin{displayquote}
|
\begin{displayquote}
|
||||||
\textbf{How do we provide an interface for the inference function?} We either have an offline or online inference workflow (or both). For the former, we have to provide a way to use it in batch processing; a simple Python function may be adequate for this purpose, though, allowing it to be easily (or automatically) parallelised would make its consumers' DX better. If it is an online-workflow, we must have a service running continuously and accepting input at any time. This can be achieved by a remote procedure call (RPC) interface, or more commonly, a web API. Developers usually refer to these as REST API-s, sometimes, they even follow the conventions of REST. Either way, we must develop a wrapper over the service in order to make it available for other internal/external consumers.
|
\textbf{How do we provide an interface for the inference function?} We either have an offline or online inference workflow (or both). For the former, we have to provide a way to use it in batch processing; a simple Python function may be adequate for this purpose, though, allowing it to be easily (or automatically) parallelised would make its consumers' DX better. If it is an online-workflow, we must have a service running continuously and accepting input at any time. This can be achieved by a remote procedure call (RPC) interface, or more commonly, a web API. Developers usually refer to these as REST API-s, sometimes, they even follow the conventions of REST. Either way, we must develop a wrapper over the service in order to make it available for other internal/external consumers.
|
||||||
\end{displayquote}
|
\end{displayquote}
|
||||||
|
|
||||||
According to the research on the adoption of best practices, this is where many real-world projects conclude. This happens to be \textbf{the gap}. Believing that solely focusing on the research and experiments is good enough is a fallacy: when following this approach, the deployment step ends up being a rushed attempt of wrapping the \textit{AI} and putting it in the production environment. This is inarguably a deployment. However, it follows very few of the best practices. This can lead to suboptimal real-life performance, lack of accountability, lack of opportunity to improve, and can overall lead to negative societal impact \cite{o2016weapons}.
|
According to the body of research on the adoption of best practices, this is where many real-world projects conclude. This also happens to be \textbf{the gap}. Believing that solely focusing on the research and experiments is good enough is a fallacy: when following this approach, the deployment step ends up being a rushed attempt of wrapping the \textit{AI} and putting it in the production environment. This is inarguably a deployment. However, it likely follows very few of the best practices which can lead to suboptimal real-life performance, lack of accountability, lack of opportunity to improve, and possibly an overall negative societal impact.
|
||||||
|
|
||||||
\begin{displayquote}
|
\begin{displayquote}
|
||||||
\textbf{How could we implement more best practices?} The most notable missing best practices are the lack of automated deployment, automated regression testing, online monitoring, persisting the traces, graceful error-handling, taking feedback on the results (if possible in the use-case), calculating the online accuracy based on the feedback, and retraining the model if necessary using novel data. These all correspond to a best practice.
|
\textbf{How could we implement more best practices?} The most notable missing best practices are the lack of automated deployment, automated regression testing, online monitoring, persisting the traces, graceful error-handling, taking feedback on the results (if possible in the use-case), calculating the online accuracy based on the feedback, and retraining the model if necessary using novel data. These all correspond to best practices.
|
||||||
\end{displayquote}
|
\end{displayquote}
|
||||||
|
|
||||||
|
\section{Bridging \textbf{the gap} with GreatAI}
|
||||||
|
|
||||||
|
First, let us revisit the library's scope for clarification. As concluded in Section \ref{section:scope}, GreatAI should ease the \textit{transition} step between prototypes and production-ready deployments. However, this leaves open the question of what constitutes to this step? There are cross-cutting concerns, for example, feature extraction is implemented and used in the training phase but it is also deployed alongside the model. The robustness criterion has to be met by this procedure even though its implementation is only in focus in the earlier stages of the project. Since having an untested function deployed into production can have severe repercussions, I conclude, assuring its correctness lies within the scope of GreatAI.
|
||||||
|
|
||||||
|
This section briefly explores how the problems raised can be solved using GreatAI, and the API it provides in order to best fit the needs of its users. We first focus on the aspects of data, then, the automated wrapping of services, lastly we discuss the utility of helper functions.
|
||||||
|
|
||||||
|
\subsection{Handling data} \label{subsection:large-file}
|
||||||
|
|
||||||
|
The obstacles coming from the intertwined nature of different models is widely recognised \cite{haakman2021ai,amershi2019software,sculley2015hidden}. This can lead to non-monotonic error propagation, meaning that improvements in one part of the system might decrease the overall system quality \cite{amershi2019software}. The importance of schema versioning in an environment of rapidly changing models and transformations is highlighted for a specific use-case in \cite{van2017versioning} and more generally by the \textit{Use Versioning for Data, Model, Configurations and Training Scripts} best practice. These emphasise the requirement for versioning models and in general, data.
|
||||||
|
|
||||||
|
There are two kinds of data storage needs we have to address: training data and trained models. Because our code is probably already tracked under Git (and \href{https://octoverse.github.com/#lets-look-back-at-the-code-and-communities-built-on-git-hub-this-year}{likely synchronised with GitHub}), using the Git Large File Storage (LFS)\footnote{\href{https://git-lfs.github.com/}{git-lfs.github.com}} might seem intriguing. However, it is a paid (and surprisingly expensive) service of GitHub especially when we factor in the expected sizes of the models and training data with the fact that the only way to remove files counting towards our quota is to \href{https://docs.github.com/en/repositories/working-with-files/managing-large-files/removing-files-from-git-large-file-storage#git-lfs-objects-in-your-repository}{delete the entire repository}.
|
||||||
|
|
||||||
|
An open-source tool, the Data Version Control (DVC)\footnote{\href{https://dvc.org/}{dvc.org}} provides a nearly perfect alternative. It comes with a command-line interface (CLI) inspired by Git's, and it can be integrated with several backend storage servers. Its only downside is, of course, that it is one more tool that increases the complexity of the project and the initial setup time. If this is an acceptable price to pay, then I personally recommend opting for DVC. Nevertheless, if this may prohibit a team\footnote{As was the case with MLFlow tracking in an ING team that we saw in Section \ref{section:industry}.} from properly handling data according to the best practices, I present a simpler solution.
|
||||||
|
|
||||||
|
The complexity of an API can be decreased by relying on its users preexisting knowledge and known patterns \cite{hermans2021programmer,ousterhout2018philosophy}. Therefore, we can reuse familiar API-s, such as the \texttt{open()} method from Python. Therefore, a method is proposed which provides the same interface, however, the backing storage can be a mixture of local disk space, S3-compatible storage, MongoDB, or any other storage backend. It provides a superset of \texttt{open()}'s interface\footnote{\href{https://docs.python.org/3/library/functions.html\#open}{docs.python.org/3/library/functions.html\#open}}; the same parameters can be used with it resulting in similar observed behaviour.
|
||||||
|
|
||||||
|
The expected features: versioning, progress bars, caching, garbage collecting the cache, automatically deleting old remote version are all present and come with recommended --- but easy to see and change --- configuration.
|
||||||
|
|
||||||
|
Easing development is not merely about automating everything but also making the code easy to change (which is the \textit{Viscosity} dimension of CDCB). Going from opening a local file on the disk with the built-in open method, to opening a file from S3 is as easy as changing \texttt{open('file.txt', 'w')} to \texttt{LargeFileS3('file.txt', 'w')}. In the case of the latter, an additional \texttt{version} keyword argument can also be given to lock ourselves in using a certain version which is very much desired in the case of models.
|
||||||
|
|
||||||
|
\subsection{Deployment approach}
|
||||||
|
|
||||||
|
Some of the expectations one might have for data-intensive (such as AI) software are similar to that for software in general. These are also captured by the best practices: \textit{Use Continuous Integration}, \textit{Automate Model Deployment}, \textit{Enable Automatic Roll Backs for Production Model} to name a few. It is important to notice that these have been already solved by software engineering, more specifically, by the DevOps paradigm \cite{leite2019survey}.
|
||||||
|
|
||||||
|
Inline with the findings of John et al. \cite{john2020architecting} on the SOTA of AI deployments, I suggest we wrap the applications in a format which is more compatible with existing DevOps tool-kits. Instead of reinventing the wheel, we should rely on more established DevOps best practices for implementing the SE4ML deployment best practices. Besides, organisations are expected to have their deployment processes for classical applications, thus, allowing them to reuse those for AI applications seems to be the most convenient approach.
|
||||||
|
|
||||||
|
Based on personal empirical evidence, three types of software artifacts are identified (in the context of Python) for which a wide range of established practices exist. WSGI server\footnote{\href{https://peps.python.org/pep-3333/}{peps.python.org/pep-3333}} compatible applications, executable scripts, and Docker Images\footnote{\href{https://docs.docker.com/registry/spec/manifest-v2-2/}{docs.docker.com/registry/spec/manifest-v2-2}}. To achieve this, GreatAI provides a compatibility layer between simple Python inference functions and all the above common artifacts. Taking functions as input for the first step is inline with the requirement to be \textbf{General}. Nevertheless, in order to also allow customisation, additional configuration, metadata, and behavioural specification can be given as well.
|
||||||
|
|
||||||
|
The main advantage of the wrapping approach is that it does not require any input from the clients (by default). I opted for a decorator which lets users wrap their function by adding a single additional line of code as shown in Listing \ref{listing:hello-world}. After which the created WSGI application can be accessed through the \texttt{greeter.app} property. A CLI script (\texttt{great-ai}), along with a \texttt{Dockerfile} are also provided to cover the other two deployment artifacts.
|
||||||
|
|
||||||
|
\begin{listing}[!ht]
|
||||||
|
\begin{minted}[
|
||||||
|
frame=lines,
|
||||||
|
framesep=2mm,
|
||||||
|
baselinestretch=1,
|
||||||
|
linenos
|
||||||
|
]{python}
|
||||||
|
from great_ai import GreatAI
|
||||||
|
|
||||||
|
@GreatAI.create
|
||||||
|
def greeter(name: str) -> str:
|
||||||
|
return f"Hello {name}!"
|
||||||
|
\end{minted}
|
||||||
|
\caption{Simplest example using GreatAI for wrapping a function. In practice, \texttt{greeter} probably would be the inference function of an ML model.}
|
||||||
|
\label{listing:hello-world}
|
||||||
|
\end{listing}
|
||||||
|
|
||||||
|
Coincidentally, deployment best practices can be easily implemented in this wrapper layer. In the first iteration these are: input validation, persisting traces, online monitoring, and generating documentation. Input validation may be used to \textit{Check that Input Data is Complete, Balanced and Well Distributed}. Traces are important for both \textit{Log Production Predictions with the Model's Version and Input Data} and \textit{Provide Audit Trails}. However, traces can also indirectly help \textbf{Robustness}, because even production systems cannot be expected to be perfect. Saving and letting the users filter on encountered errors while allowing them to correlate it with the input causing it is imperative for facilitating debugging.
|
||||||
|
|
||||||
|
Lastly, monitoring and documentation correspond with helping best practices: \textit{Continuously Monitor the Behaviour of Deployed Models} and \textit{Communicate, Align, and Collaborate With Others} respectively.
|
||||||
|
|
||||||
|
To allow customising the service's behaviour to fit different use-cases, the default configurations can be overridden by calling some functions of the library. An example of this can be seen in Listing \ref{listing:complex}, while more details of the semantics can be found in the documentation\footnote{\href{https://great-ai.scoutinscience.com/how-to-guides/create-service/}{great-ai.scoutinscience.com/how-to-guides/create-service}}.
|
||||||
|
|
||||||
|
\begin{listing}[!ht]
|
||||||
|
\begin{minted}[
|
||||||
|
frame=lines,
|
||||||
|
framesep=2mm,
|
||||||
|
baselinestretch=1,
|
||||||
|
linenos
|
||||||
|
]{python}
|
||||||
|
from great_ai import GreatAI, parameter, use_model, log_metric
|
||||||
|
|
||||||
|
@GreatAI.create
|
||||||
|
@parameter('positive_number', validate=lambda n: n > 0)
|
||||||
|
@use_model('secret-number', version='latest')
|
||||||
|
def add_to_secret_number(positive_number: int, model: int) -> int:
|
||||||
|
"""This docstring will be exported as documentation."""
|
||||||
|
log_metric('log directly into the Trace', positive_number * 2)
|
||||||
|
return secret + positive_number
|
||||||
|
|
||||||
|
assert add_number(1).output == 5
|
||||||
|
\end{minted}
|
||||||
|
\caption{A simple GreatAI service with behavioural customisations. In practice, the function would probably be the inference function for an ML model.}
|
||||||
|
\label{listing:complex}
|
||||||
|
\end{listing}
|
||||||
|
|
||||||
|
\subsection{Utilities}
|
||||||
|
|
||||||
|
It is easy to notice multiple recurring tasks when it comes to processing text. Cleaning it from various extraction artifacts and normalising characters is one of the most common. But splitting sentences, language tagging, robustly lemmatizing are also often recurring tasks. Because having reusable and tested feature extraction code covers two best practices, it seems straightforward that a utility module could be created for this which can also be extensively tested by means of unit testing.
|
||||||
|
|
||||||
|
This is exactly the motivation behind \texttt{great\_ai.utilities}. Extra care has to be taken not to overfit these utilities on the cases considered in this chapter; however, I believe these are versatile enough to be helpful in many text-related context. A conclusive answer to this assumption will be found during the interviews.
|
||||||
|
|
||||||
|
Implementing the unit tests uncovered multiple edge cases and even runtime errors, hence, the merit of \textit{Test all Feature Extraction Code} best practice is unequivocal. There is one more best practice that could be partially covered here, especially, because its solution also helps both during batch inference, but also at training/feature extraction time: \textit{Enable Parallel Training Experiments}.
|
||||||
|
|
||||||
|
A function called \texttt{parallel\_map()} is implemented which closely mimics the API of the built-in Python function: \texttt{map}. And it exemplifies how even a close to trivial function is able to improve the DX by magnitudes. Rooted in the global interpreter lock (GIL)\footnote{\href{https://wiki.python.org/moin/GlobalInterpreterLock}{wiki.python.org/moin/GlobalInterpreterLock}} of CPython, in almost all cases, multi-threading does not lead to higher performance of CPU-bound tasks. For this purpose, multiprocessing has to be used. Fortunately, the built-in \texttt{multiprocessing} library has a great API, however, it still takes about a dozen lines to do a parallel mapping task with a progress bar. This can deter people (at least me) from taking advantage of more than just a single CPU core during exploratory experimentation. With \texttt{parallel\_map()}, this challenge becomes a single-line, routine task.
|
||||||
|
|
||||||
|
\subsection{Summary}
|
||||||
|
|
||||||
|
After implementing some features of the library it can be already used for deploying the previously discussed domain prediction model. In this case, online prediction is expected, hence, the REST API-based deployment is chosen which is created by GreatAI and packaged in a Docker image. This image can be instantiated by the company's existing DevOps pipeline and cloud infrastructure. At the end, users can see one more tag in the header section of publication evaluations where they can also see the explanation behind the model's decision as seen in Figure \ref{fig:dashboard-domains}. Let us now explore how it fares in a more complex case.
|
||||||
|
|
||||||
|
\begin{figure}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=0.7\linewidth]{figures/dashboard-domains.png}
|
||||||
|
\caption{Screenshot of the domain prediction integrated into the ScoutinScience platform where it is used as a filtering option.}
|
||||||
|
\label{fig:dashboard-domains}
|
||||||
|
\end{figure}
|
||||||
|
|
@ -1,5 +1,29 @@
|
||||||
\section{Results}
|
\section{Results}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
\begin{figure}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=0.9\linewidth]{figures/greatai-header.png}
|
||||||
|
\caption{}
|
||||||
|
\label{fig:greatai-header}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
\begin{figure}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=1\textwidth]{figures/greatai-table.png}
|
||||||
|
\caption{}
|
||||||
|
\label{fig:greatai-table}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
\begin{figure}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=1\textwidth]{figures/greatai-parallel.png}
|
||||||
|
\caption{}
|
||||||
|
\label{fig:greatai-parallel}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
|
||||||
\begin{table}
|
\begin{table}
|
||||||
\centering
|
\centering
|
||||||
\caption{A subset of the AI lifecycle \href{https://se-ml.github.io/practices/}{best practices identified by Serban et al.} \cite{serban2020adoption,serban2021practices} and the level of support GreatAI provides for them. \textit{Full} requires no action from the user, \textit{Partial} requires at least some involvement, while \textit{Slight} provides some useful features but the client is still expected to make a significant effort.}
|
\caption{A subset of the AI lifecycle \href{https://se-ml.github.io/practices/}{best practices identified by Serban et al.} \cite{serban2020adoption,serban2021practices} and the level of support GreatAI provides for them. \textit{Full} requires no action from the user, \textit{Partial} requires at least some involvement, while \textit{Slight} provides some useful features but the client is still expected to make a significant effort.}
|
||||||
116
docs/thesis/chapters/5_cases/scibert.tex
Normal file
116
docs/thesis/chapters/5_cases/scibert.tex
Normal file
|
|
@ -0,0 +1,116 @@
|
||||||
|
\section{Text summarisation with SciBERT}
|
||||||
|
|
||||||
|
Let us now turn our attention towards a more complex component. The ScoutinScience Dashboard\footnote{\href{https://dashboard.scoutinscience.com/}{dashboard.scoutinscience.com}} contains a full-page evaluation view for each academic publication. On this, the known metadata, historical trends about the paper's topics, social media mentions, a PDF viewer showing the document, and other augmentation tools are displayed. One of these is the \textit{Highlights} section, which aims to summarise the paper from a technology-transfer perspective.
|
||||||
|
|
||||||
|
The current approach uses a simple heuristic based on a set of phrases selected by business developers and extended by the help of a word2vec model \cite{mikolov2013efficient}. The user feedback deemed this implementation slightly helpful but not adequate for providing an accurate overview. Thus, this is the baseline that I attempt to improve on in this section.
|
||||||
|
|
||||||
|
\begin{displayquote}
|
||||||
|
Compared with Section \ref{section:simple-case}, this time around, the toolset of GreatAI is available at our disposal. Hopefully, this will streamline the development and --- especially --- the deployment. Given its arguably higher complexity, the experiment falls closer to industrial use-cases, and hence, can give more accurate feedback on how to further improve the API.
|
||||||
|
\end{displayquote}
|
||||||
|
|
||||||
|
\subsection{Background}
|
||||||
|
|
||||||
|
Automatic text summarisation (ATS) is also one of the earliest established tasks of text analysis and boasts numerous promising results \cite{el2021automatic}. Text summarisation is usually divided into extractive and abstractive approaches. Even though the latter can lead to more fluent summaries, it is also prone to hallucinate content that is unfaithful to the input \cite{maynez2020faithfulness}. For this reason, extractive techniques are preferred in this case.
|
||||||
|
|
||||||
|
Our problem requires generating a special type of summary: it must only concern a single aspect (tech-transfer) of the document. Aspect-based text summarisation has also seen some progress over the last decades \cite{berkovsky2008aspect,hayashi2021wikiasp} but these methods require concretely defined topics. Unfortunately, \textit{tech-transfer potential} is anything but a clear topic definition.
|
||||||
|
|
||||||
|
Numerous discussions and interviews with business developers over the last two years made it clear that there is no universally agreed on definition for it. At least, all of them agree that they know it when they see it. Additionally, most of them agree that they can confidently make a decision at the granularity of sentences. This gives rise to an obvious idea: show the experts something that they can annotate. Because the time of experts is valuable, and relevant sentences are few and far between, extra care needs to be taken to improve the ratio of positive examples in the dataset. The research of Iwatsuki Kenichi on formulaic expressions (FE) \cite{iwatsuki2020evaluation,iwatsuki2021extraction,iwatsuki2021communicative,iwatsuki2022extraction} provides a promising direction to do so.
|
||||||
|
|
||||||
|
A formulaic expression is a phrase with zero or more ``slots'' which when filled appropriately, leads to expressing a certain intent. In the context of scientific texts, an example\footnote{Taken from the ground-truth data available at \href{https://github.com/Alab-NII/FECFevalDataset/blob/master/human_evaluation/background.tsv}{github.com/Alab-NII/FECFevalDataset}.} could be: \texttt{it was not until * that}. The asterisk can be substituted with multiple terms and the intention of this expression is (likely) to describe the \textit{History of the related topics}. Iwatsuki et al. identified a set of 39 intentions, compiled a manually labelled dataset \cite{iwatsuki2020evaluation}, and developed multiple approaches for automatically extracting and classifying formulaic expressions in large corpora \cite{iwatsuki2021communicative,iwatsuki2022extraction}.
|
||||||
|
|
||||||
|
\subsection{Methods}
|
||||||
|
|
||||||
|
In order to compile our dataset, experts are asked to judge sentences that passed an \textit{intention check}. This pooling approach is commonly used in the field of information retrieval \cite{schutze2008introduction}. The filtering stage is expected to sieve out sentences that are probably not relevant from a technology-transfer perspective using Iwatsuki's formulaic expression intention labels. Subsequently, relevance judgements --- in the form of \textit{interesting} or \textit{not interesting} labels --- are gathered for these sentences. This method turns the extractive summarisation into a binary classification task for which a SciBERT model \cite{beltagy2019scibert} can be finetuned. Ultimately, the summaries are derived from sentences that are selected by the classifier trained on the experts' annotations.
|
||||||
|
|
||||||
|
We have to note two possible shortcomings of this setup: firstly, we assume the FE intentions are strongly correlated with the sought-after aspect, this may or may not be true. secondly, only the individual relevance of the sentences is considered instead of the overall relevance (utility) of the summary. Nonetheless, it is expected that stemming from the length of the documents and the sparseness of the selected sentences, that any combination of them is likely to have low redundancy.
|
||||||
|
|
||||||
|
\subsection{Results}
|
||||||
|
|
||||||
|
For the first iteration, 1500 sentences were selected for 2 experts to annotate in a binary fashion according to strict guidelines. An example is shown in Figure \ref{fig:annotator}. Afterwards, for measuring the interrater agreement, Cohen's kappa \cite{cohen1960coefficient} is calculated as shown in Equation \ref{equation:kappa}. Which turns out to be \textbf{0.4310} for the two annotators. This happens to be just above the lower end of \textit{moderate agreement}. However, we have to note that the original quality ranges are often criticised for being too relaxed \cite{mchugh2012interrater}. However, in the case of summarisation, Verberne et al. \cite{verberne2018creating} argue that reasonable end-quality can be reached even when the interrater agreement is low. The ground truth is determined by taking the logical disjunction of the annotations.
|
||||||
|
|
||||||
|
\begin{figure}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=0.75\linewidth]{figures/annotator.png}
|
||||||
|
\caption{Annotator UI showing a single sentence and the two possible labels that can be assigned to it based on its relevance to technology transfer.}
|
||||||
|
\label{fig:annotator}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
\begin{equation} \label{equation:kappa}
|
||||||
|
\kappa_{agreement} \equiv \frac{p_{observed} - p_{expected}}{1 - p_{expected}} = 1 - \frac{1 - p_{observed}}{1 - p_{expected}}
|
||||||
|
\end{equation}
|
||||||
|
|
||||||
|
The next step is finetuning SciBERT with the help of HuggingFace transformers \cite{wolf2019huggingface}. The data are divided into training and test split with a ratio of 4:1. From the train split, a validation split is also derived which is used for early stopping. The objective function is the macro-averaged F1-score and the early stopping patience is 5 epochs. The learning rate is $5 \times 10^{-5}$ and AdamW \cite{loshchilov2017decoupled} is used for optimisation with a weight decay of 0.05. The code can be found in the documentation\footnote{\href{https://great-ai.scoutinscience.com/examples/scibert/train/}{great-ai.scoutinscience.com/examples/scibert/train/}}, it is surprisingly slightly shorter than the code of Section \ref{section:simple-case}.
|
||||||
|
|
||||||
|
\begin{displayquote}
|
||||||
|
\textbf{Reproducability} Reproducible experiments are generally preferred. It is easy to forget to set some seeds values and, for example, end up with different datapoints in the test-train splits. To facilitate reproducability, it would be useful to reset the seeds of each imported library's random number generators (RNG) when GreatAI is configured. Thus, a feature has been added to detect and reset RNG-s of installed and imported libraries. This certainly will not solve the reproducibility crisis \cite{hutson2018artificial} on its own, however, in some cases, it can result in one fewer step to miss.
|
||||||
|
\end{displayquote}
|
||||||
|
|
||||||
|
\begin{displayquote}
|
||||||
|
\textbf{Utility of LargeFiles-s} For the purposes of the documentation, the finetuning was conducted in the Google Colab online environment which is excellent for providing anyone with GPU-time for free. However, notebook environments are ephemeral, resulting in the need to manually upload and download all relevant data whenever a new virtual machine (VM) instance is granted. The \texttt{LargeFile} implementation alleviated this problem by handling the uploads and downloads automatically.
|
||||||
|
\end{displayquote}
|
||||||
|
|
||||||
|
The best validation results were achieved after 8 epoch which was slightly more than expected but is presumably due to the weight decay. The confusion matrix on the test split can be seen in Figure \ref{fig:scibert-confusion}: regardless the subjectiveness of the task, SciBERT manages to achieve good quality which is indicated by a macro-averaged F1-score of \textbf{0.89}.
|
||||||
|
|
||||||
|
\begin{figure}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=0.4\linewidth]{figures/scibert-confusion.png}
|
||||||
|
\caption{Confusion matrix of the fine-tuned SciBERT model on the \textit{summary candidate sentences} dataset. The values are globally normalised and represent percentages.}
|
||||||
|
\label{fig:scibert-confusion}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
Let us check how well the selected sentences correspond with the tech-transfer potential. Users and in-house experts can rate publications (from a tech-transfer perspective) by assigning them to one of four categories: \texttt{A}, \texttt{B}, \texttt{C}, and \texttt{D} with \texttt{A} being the most and \texttt{D} the least promising. This feedback is stored and used for analytic and training purposes. Since both the feedback grade and the ``highlights'' are supposed to reflect the same aspect of papers, therefore, we can reasonably expect some correlation between them.
|
||||||
|
|
||||||
|
Figure \ref{fig:histograms} shows the ratio of summary candidate sentences as predicted by the finetuned model in 4 categories (grades) of papers. The two datasets come from non-overlapping sets of papers, hence, the results come solely from the model's ability to generalise. It is interesting to see that the Spearman's rank correlation coefficient \cite{spearman1961proof} between the normalised ``highlights'' counts and the ratings of papers is \textbf{0.4584} and is statistically significant ($P = 5.4 \times 10^{-74}$). This proves the presence of a monotonic association. For context, the correlation between the grades and the number of sentences found by the baseline approach is 0.05597 ($P = 0.03$).
|
||||||
|
|
||||||
|
\begin{figure}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=0.85\linewidth]{figures/highlights-histograms.png}
|
||||||
|
\caption{Distribution of mean predicted summary candidate sentence counts in 4 categories. Category \texttt{A} correspond to the most, while \texttt{D} to the least interesting papers based on median user feedback. The sample size is 1406 (\texttt{D}=715, \texttt{C}=309, \texttt{B}=198, \texttt{A}=184). The histograms are on the same scale.}
|
||||||
|
\label{fig:histograms}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
We can conclude that the classifier's output is indicative of the publications' tech-transfer potential. To implement the summarisation, at most the top 7 selected sentences are chosen as ranked by their log-probabilities. They are subsequently reordered according to their position in the text. As a quasi-explanation, the tokens' attention scores are visualised and overlaid on the highlighted sentences. The \textit{i}-th token's visualised attention comes from summing up the attention weights of each of the last layer's heads between the \texttt{[CLS]} and the \textit{i}-th token. To improve the end-user experience, a high-pass filter and a stop-word list is applied to the scores in order not to highlight the syntax-related tokens (punctuation, determiners). The service --- after being integrated into the dashboard --- can be seen in Figure \ref{fig:dashboard-highlights}.
|
||||||
|
|
||||||
|
\subsection{Deployment}
|
||||||
|
|
||||||
|
\begin{displayquote}
|
||||||
|
In order to get insights into their inner workings, HuggingFace models can be given \texttt{output\_attentions=True} in their constructor which results in a new property becoming accessible on the results for querying the attentions. The only issue with it is that it is a 5-dimensional matrix which makes exploring and understanding it non-obvious. In short, it has very low \textit{Discoveribility}. For example, the attentions for the UI are calculated with this expression:
|
||||||
|
\begin{minted}[
|
||||||
|
baselinestretch=1,
|
||||||
|
]{python}
|
||||||
|
np.sum(result.attentions[-1].numpy()[0], axis=0)[0][1:-1]
|
||||||
|
\end{minted}
|
||||||
|
Even though the operation is conceptually simple, because of the opaque datastructure, this is anything but obvious to comprehend. Therefore, it is clear that this needs to be avoided in my library design; it has to have a clear and discoverable API which can be achieved by the use of typehints, descriptive property names, and docstrings.
|
||||||
|
\end{displayquote}
|
||||||
|
|
||||||
|
\begin{figure}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=0.9\linewidth]{figures/dashboard-highlights.png}
|
||||||
|
\caption{The tech-transfer summary of an academic publication (\cite{bruns2022deep}). The titles and sentences can be clicked for navigating the paper on the right, while some explanation is provided by the highlighted words the opacity of which corresponds to their attention weights.}
|
||||||
|
\label{fig:dashboard-highlights}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
\section{Improving GreatAI}
|
||||||
|
|
||||||
|
\subsection{Caching}
|
||||||
|
|
||||||
|
Sustainability is an increasingly important concern of ethical AI \cite{van2021sustainable}. Without discussing the pros and cons of the green computing movement \cite{10.1145/1400181.1400186}, we can still agree that computing time should not be wasted. To this end, caching the results of expensive operations has to be considered in an AI deployment. The highlights service is often called multiple times with the same parameters from different other services. With each operation taking up to a couple of seconds, implementing caching can lead to vastly faster response times and an overall more socially conscious deployment.
|
||||||
|
|
||||||
|
\subsection{Revisiting \texttt{parallel\_map}}
|
||||||
|
|
||||||
|
Even though most inference functions are CPU-bound, turns out, sometimes they involve IO, especially, when relying on the results of other, remote models. This means that a significant performance improvement can be achieved by implementing some inference functions asynchronously \cite{tilkov2010node}. Thus, GreatAI also has to support decorating both regular (synchronous) and asynchronous functions. There is one notable consequence of this: the batch processing feature also has to be compatible with \texttt{async} inference functions. Batch processing is still a useful feature since it is likely that async inference functions are both IO (remote calls) and CPU (local evaluation) heavy at the same time, thus, they can benefit from multi-core parallelisation.
|
||||||
|
|
||||||
|
However, the standard library's \texttt{multiprocessing}, the third party \texttt{multiprocess} \cite{mckerns2012building}, and, another popular library, \texttt{joblib}\footnote{\href{https://joblib.readthedocs.io/en/latest/}{joblib.readthedocs.io/en/latest}} all lack the support for efficiently parallelising async functions. For this reason, \texttt{parallel\_map} is reimplemented to create an event-loop in each worker process to keep the efficiency of non-blocking IO while also providing parallelisation for the CPU-bound sections of code.
|
||||||
|
|
||||||
|
\subsection{Integration}
|
||||||
|
|
||||||
|
Apart from supporting \texttt{async} calls, there are a couple of more step that can be taken to help integrating any service with a GreatAI deployment. This is implemented by the \texttt{call\_remote\_great\_ai()} function which hides the networking required to call a GreatAI instance's REST API. It takes care of validation, automatic retries, serialisation, and deserialisation.
|
||||||
|
|
||||||
|
Additionally, a REST API is generated with its accompanying \href{https://swagger.io/specification/}{OpenAPI schema} and served with a \href{https://swagger.io/}{Swagger} template. It also contains metadata about the function, for instance, its docstring, version, and version of its registered models concatenated in order to be SemVer\footnote{\href{https://semver.org/}{semver.org}} compatible. These can be seen in Figure \ref{fig:greatai-api}. This, combined with a \texttt{/version} endpoint for programmatic access and validation of the service's metadata proved to be key features when integrating the \textit{Highlights service} into ScoutinScience's service-based architecture.
|
||||||
|
|
||||||
|
\begin{figure}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=0.75\linewidth]{figures/greatai-api.png}
|
||||||
|
\caption{Documentation of the automatically scaffolded REST API of a GreatAI service. Notice, how its version string includes its registered models in a SemVer compliant way: \texttt{0.0.1+small-domain-prediction-v11}.}
|
||||||
|
\label{fig:greatai-api}
|
||||||
|
\end{figure}
|
||||||
26
docs/thesis/chapters/appendix.tex
Normal file
26
docs/thesis/chapters/appendix.tex
Normal file
|
|
@ -0,0 +1,26 @@
|
||||||
|
\appendix
|
||||||
|
\chapter{TAM questionnaire} \label{appendix:questions}
|
||||||
|
|
||||||
|
Following the methodology for parsimonious TAM of Wu et al. \cite{wu2011user}, each statement can be rated on a 7-point Likert scale.
|
||||||
|
|
||||||
|
\paragraph{Perceived usefulness (PU)}
|
||||||
|
\begin{enumerate}
|
||||||
|
\item I believe the use of \textit{GreatAI} improves the quality of AI deployments.
|
||||||
|
\item I believe the use of \textit{GreatAI} would increase my productivity.
|
||||||
|
\item I believe the use of \textit{GreatAI} can lead to robust and trustworthy deployments.
|
||||||
|
\item Overall, I found \textit{GreatAI} useful when working with AI.
|
||||||
|
\end{enumerate}
|
||||||
|
|
||||||
|
\paragraph{Perceived ease of use (PEOU)}
|
||||||
|
\begin{enumerate}
|
||||||
|
\item I found the \textit{GreatAI} easy to learn.
|
||||||
|
\item I found it is easy to employ \textit{GreatAI} in practice.
|
||||||
|
\item I found it is easy to integrate \textit{GreatAI} into an existing project.
|
||||||
|
\item Overall, I found \textit{GreatAI} easy to use.
|
||||||
|
\end{enumerate}
|
||||||
|
|
||||||
|
\paragraph{Intention to use (ITU)}
|
||||||
|
\begin{enumerate}
|
||||||
|
\item Assuming \textit{GreatAI} is applicable to my task, I predict that I will use it on a regular basis in the future.
|
||||||
|
\item Overall, I intend to use the \textit{GreatAI} in my personal or professional projects.
|
||||||
|
\end{enumerate}
|
||||||
7
docs/thesis/comments.txt
Normal file
7
docs/thesis/comments.txt
Normal file
|
|
@ -0,0 +1,7 @@
|
||||||
|
% I use a toy example when quickly experimenting, it's important not to overfit on it ( moving it into the library would result in a online for it, so I have to consciously avoid that), but having a very simple
|
||||||
|
|
||||||
|
% Argumetn/parameter names were confusing
|
||||||
|
% offlinemode -> cacheonly mode
|
||||||
|
|
||||||
|
% Should the order of the decorators matter? all except in one case, they're written in a way that the order doesn't matter even with the original semantics of decorators. In that one case, it cannot be written in that way. Instead of correcting a user's error, there's a mechanism looking for this error and the user is notified. Guessing the unspecified is cool, but correcting the wrong is not
|
||||||
|
|
||||||
BIN
docs/thesis/figures/annotator.png
Normal file
BIN
docs/thesis/figures/annotator.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 920 KiB |
BIN
docs/thesis/figures/dashboard-domains.png
Normal file
BIN
docs/thesis/figures/dashboard-domains.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 66 KiB |
BIN
docs/thesis/figures/dashboard-highlights.png
Normal file
BIN
docs/thesis/figures/dashboard-highlights.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 795 KiB |
BIN
docs/thesis/figures/greatai-api.png
Normal file
BIN
docs/thesis/figures/greatai-api.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 114 KiB |
BIN
docs/thesis/figures/greatai-header.png
Normal file
BIN
docs/thesis/figures/greatai-header.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 104 KiB |
BIN
docs/thesis/figures/greatai-parallel.png
Normal file
BIN
docs/thesis/figures/greatai-parallel.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 210 KiB |
BIN
docs/thesis/figures/greatai-table.png
Normal file
BIN
docs/thesis/figures/greatai-table.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 190 KiB |
BIN
docs/thesis/figures/highlights-histograms.png
Normal file
BIN
docs/thesis/figures/highlights-histograms.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 36 KiB |
BIN
docs/thesis/figures/scibert-confusion.png
Normal file
BIN
docs/thesis/figures/scibert-confusion.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
File diff suppressed because it is too large
Load diff
|
|
@ -1,4 +1,4 @@
|
||||||
\documentclass[runningheads]{llncs}
|
\documentclass{report}
|
||||||
|
|
||||||
\usepackage{graphicx}
|
\usepackage{graphicx}
|
||||||
\usepackage{pdfpages}
|
\usepackage{pdfpages}
|
||||||
|
|
@ -12,7 +12,15 @@
|
||||||
\usepackage{framed}
|
\usepackage{framed}
|
||||||
\usepackage{quoting}
|
\usepackage{quoting}
|
||||||
\usepackage{xcolor}
|
\usepackage{xcolor}
|
||||||
|
\usepackage{minted}
|
||||||
|
|
||||||
|
\usepackage[a4paper,
|
||||||
|
bindingoffset=0,
|
||||||
|
left=3cm,
|
||||||
|
right=3cm,
|
||||||
|
top=3cm,
|
||||||
|
bottom=4cm,
|
||||||
|
footskip=1.5cm]{geometry}
|
||||||
|
|
||||||
% Header & footer
|
% Header & footer
|
||||||
\pagestyle{fancy}
|
\pagestyle{fancy}
|
||||||
|
|
@ -78,6 +86,56 @@
|
||||||
\renewcommand\thesection{\thechapter.\arabic{section}}
|
\renewcommand\thesection{\thechapter.\arabic{section}}
|
||||||
\renewcommand\thesubsection{\thesection.\arabic{subsection}}
|
\renewcommand\thesubsection{\thesection.\arabic{subsection}}
|
||||||
|
|
||||||
|
\makeatletter
|
||||||
|
\renewcommand\small{%
|
||||||
|
\@setfontsize\small\@ixpt{11}%
|
||||||
|
\abovedisplayskip 8.5\p@ \@plus3\p@ \@minus4\p@
|
||||||
|
\abovedisplayshortskip \z@ \@plus2\p@
|
||||||
|
\belowdisplayshortskip 4\p@ \@plus2\p@ \@minus2\p@
|
||||||
|
\def\@listi{\leftmargin\leftmargini
|
||||||
|
\parsep 0\p@ \@plus1\p@ \@minus\p@
|
||||||
|
\topsep 8\p@ \@plus2\p@ \@minus4\p@
|
||||||
|
\itemsep0\p@}%
|
||||||
|
\belowdisplayskip \abovedisplayskip
|
||||||
|
}
|
||||||
|
|
||||||
|
\frenchspacing
|
||||||
|
\widowpenalty=10000
|
||||||
|
\clubpenalty=10000
|
||||||
|
|
||||||
|
\setlength\footnotesep{12\p@}
|
||||||
|
\setlength\textfloatsep{8mm\@plus 2\p@ \@minus 4\p@}
|
||||||
|
\setlength\intextsep {8mm\@plus 2\p@ \@minus 2\p@}
|
||||||
|
|
||||||
|
\setcounter{secnumdepth}{2}
|
||||||
|
|
||||||
|
\renewcommand\@pnumwidth{2em}
|
||||||
|
\renewcommand\@tocrmarg{3.5em}
|
||||||
|
\setcounter{tocdepth}{1}
|
||||||
|
\setlength{\parskip}{0.55em}
|
||||||
|
\linespread{1.2}
|
||||||
|
|
||||||
|
\def\@dottedtocline#1#2#3#4#5{%
|
||||||
|
\ifnum #1>\c@tocdepth \else
|
||||||
|
\vskip \z@ \@plus.2\p@
|
||||||
|
{\leftskip #2\relax \rightskip \@tocrmarg \advance\rightskip by 0pt plus 2cm
|
||||||
|
\parfillskip -\rightskip \pretolerance=10000
|
||||||
|
\parindent #2\relax\@afterindenttrue
|
||||||
|
\interlinepenalty\@M
|
||||||
|
\leavevmode
|
||||||
|
\@tempdima #3\relax
|
||||||
|
\advance\leftskip \@tempdima \null\nobreak\hskip -\leftskip
|
||||||
|
{#4}\nobreak
|
||||||
|
\leaders\hbox{$\m@th
|
||||||
|
\mkern \@dotsep mu\hbox{.}\mkern \@dotsep
|
||||||
|
mu$}\hfill
|
||||||
|
\nobreak
|
||||||
|
\hb@xt@\@pnumwidth{\hfil\normalfont \normalcolor #5}%
|
||||||
|
\par}%
|
||||||
|
\fi}
|
||||||
|
\makeatother
|
||||||
|
|
||||||
|
|
||||||
\begin{document}
|
\begin{document}
|
||||||
|
|
||||||
\includepdf[pages=-]{frontpage/frontpage.pdf}
|
\includepdf[pages=-]{frontpage/frontpage.pdf}
|
||||||
|
|
@ -88,10 +146,12 @@
|
||||||
\input{chapters/2_background}
|
\input{chapters/2_background}
|
||||||
\input{chapters/3_methods}
|
\input{chapters/3_methods}
|
||||||
\input{chapters/4_design}
|
\input{chapters/4_design}
|
||||||
\input{chapters/5_case/main}
|
\input{chapters/5_cases/main}
|
||||||
\input{chapters/6_interviews}
|
\input{chapters/6_interviews}
|
||||||
\input{chapters/7_conclusion}
|
\input{chapters/7_conclusion}
|
||||||
|
|
||||||
|
\input{chapters/appendix}
|
||||||
|
|
||||||
\clearpage
|
\clearpage
|
||||||
\bibliographystyle{splncs04}
|
\bibliographystyle{splncs04}
|
||||||
\bibliography{ref}
|
\bibliography{ref}
|
||||||
|
|
|
||||||
|
|
@ -585,7 +585,221 @@
|
||||||
}
|
}
|
||||||
|
|
||||||
@misc{Procida_Diataxis_documentation_framework,
|
@misc{Procida_Diataxis_documentation_framework,
|
||||||
author = {Procida, Daniele},
|
author = {Procida, Daniele},
|
||||||
title = {{Diátaxis documentation framework}},
|
title = {{Diátaxis documentation framework}},
|
||||||
url = {https://diataxis.fr/}
|
url = {https://diataxis.fr/}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{davis1989perceived,
|
||||||
|
title={Perceived usefulness, perceived ease of use, and user acceptance of information technology},
|
||||||
|
author={Davis, Fred D},
|
||||||
|
journal={MIS quarterly},
|
||||||
|
pages={319--340},
|
||||||
|
year={1989},
|
||||||
|
publisher={JSTOR}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{marangunic2015technology,
|
||||||
|
title={Technology acceptance model: a literature review from 1986 to 2013},
|
||||||
|
author={Maranguni{\'c}, Nikola and Grani{\'c}, Andrina},
|
||||||
|
journal={Universal access in the information society},
|
||||||
|
volume={14},
|
||||||
|
number={1},
|
||||||
|
pages={81--95},
|
||||||
|
year={2015},
|
||||||
|
publisher={Springer}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{wu2011user,
|
||||||
|
title={User acceptance of wireless technology in organizations: A comparison of alternative models},
|
||||||
|
author={Wu, Chin-Shan and Cheng, Fei-Fei and Yen, David C and Huang, Yu-Wen},
|
||||||
|
journal={Computer Standards \& Interfaces},
|
||||||
|
volume={33},
|
||||||
|
number={1},
|
||||||
|
pages={50--58},
|
||||||
|
year={2011},
|
||||||
|
publisher={Elsevier}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{riemenschneider2002explaining,
|
||||||
|
title={Explaining software developer acceptance of methodologies: a comparison of five theoretical models},
|
||||||
|
author={Riemenschneider, Cynthia K. and Hardgrave, Bill C. and Davis, Fred D.},
|
||||||
|
journal={IEEE transactions on Software Engineering},
|
||||||
|
volume={28},
|
||||||
|
number={12},
|
||||||
|
pages={1135--1145},
|
||||||
|
year={2002},
|
||||||
|
publisher={IEEE}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{bland1997statistics,
|
||||||
|
title={Statistics notes: Cronbach's alpha},
|
||||||
|
author={Bland, J Martin and Altman, Douglas G},
|
||||||
|
journal={Bmj},
|
||||||
|
volume={314},
|
||||||
|
number={7080},
|
||||||
|
pages={572},
|
||||||
|
year={1997},
|
||||||
|
publisher={British Medical Journal Publishing Group}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{halcomb2006verbatim,
|
||||||
|
title={Is verbatim transcription of interview data always necessary?},
|
||||||
|
author={Halcomb, Elizabeth J and Davidson, Patricia M},
|
||||||
|
journal={Applied nursing research},
|
||||||
|
volume={19},
|
||||||
|
number={1},
|
||||||
|
pages={38--42},
|
||||||
|
year={2006},
|
||||||
|
publisher={Elsevier}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{fereday2006demonstrating,
|
||||||
|
title={Demonstrating rigor using thematic analysis: A hybrid approach of inductive and deductive coding and theme development},
|
||||||
|
author={Fereday, Jennifer and Muir-Cochrane, Eimear},
|
||||||
|
journal={International journal of qualitative methods},
|
||||||
|
volume={5},
|
||||||
|
number={1},
|
||||||
|
pages={80--92},
|
||||||
|
year={2006},
|
||||||
|
publisher={SAGE Publications Sage CA: Los Angeles, CA}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{cruz2019catalog,
|
||||||
|
title={Catalog of energy patterns for mobile applications},
|
||||||
|
author={Cruz, Luis and Abreu, Rui},
|
||||||
|
journal={Empirical Software Engineering},
|
||||||
|
volume={24},
|
||||||
|
number={4},
|
||||||
|
pages={2209--2235},
|
||||||
|
year={2019},
|
||||||
|
publisher={Springer}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{leite2019survey,
|
||||||
|
title={A survey of DevOps concepts and challenges},
|
||||||
|
author={Leite, Leonardo and Rocha, Carla and Kon, Fabio and Milojicic, Dejan and Meirelles, Paulo},
|
||||||
|
journal={ACM Computing Surveys (CSUR)},
|
||||||
|
volume={52},
|
||||||
|
number={6},
|
||||||
|
pages={1--35},
|
||||||
|
year={2019},
|
||||||
|
publisher={ACM New York, NY, USA}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{mckerns2012building,
|
||||||
|
title={Building a framework for predictive science},
|
||||||
|
author={McKerns, Michael M and Strand, Leif and Sullivan, Tim and Fang, Alta and Aivazis, Michael AG},
|
||||||
|
journal={arXiv preprint arXiv:1202.1056},
|
||||||
|
year={2012}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{tilkov2010node,
|
||||||
|
title={Node. js: Using JavaScript to build high-performance network programs},
|
||||||
|
author={Tilkov, Stefan and Vinoski, Steve},
|
||||||
|
journal={IEEE Internet Computing},
|
||||||
|
volume={14},
|
||||||
|
number={6},
|
||||||
|
pages={80--83},
|
||||||
|
year={2010},
|
||||||
|
publisher={IEEE}
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{john2020architecting,
|
||||||
|
title={Architecting AI Deployment: A Systematic Review of State-of-the-art and State-of-practice Literature},
|
||||||
|
author={John, Meenu Mary and Holmstr{\"o}m Olsson, Helena and Bosch, Jan},
|
||||||
|
booktitle={International Conference on Software Business},
|
||||||
|
pages={14--29},
|
||||||
|
year={2020},
|
||||||
|
organization={Springer}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{maynez2020faithfulness,
|
||||||
|
title={On faithfulness and factuality in abstractive summarization},
|
||||||
|
author={Maynez, Joshua and Narayan, Shashi and Bohnet, Bernd and McDonald, Ryan},
|
||||||
|
journal={arXiv preprint arXiv:2005.00661},
|
||||||
|
year={2020}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{mchugh2012interrater,
|
||||||
|
title={Interrater reliability: the kappa statistic},
|
||||||
|
author={McHugh, Mary L},
|
||||||
|
journal={Biochemia medica},
|
||||||
|
volume={22},
|
||||||
|
number={3},
|
||||||
|
pages={276--282},
|
||||||
|
year={2012},
|
||||||
|
publisher={Medicinska naklada}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{verberne2018creating,
|
||||||
|
title={Creating a reference data set for the summarization of discussion forum threads},
|
||||||
|
author={Verberne, Suzan and Krahmer, Emiel and Hendrickx, Iris and Wubben, Sander and van Den Bosch, Antal},
|
||||||
|
journal={Language Resources and Evaluation},
|
||||||
|
volume={52},
|
||||||
|
number={2},
|
||||||
|
pages={461--483},
|
||||||
|
year={2018},
|
||||||
|
publisher={Springer}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{loshchilov2017decoupled,
|
||||||
|
title={Decoupled weight decay regularization},
|
||||||
|
author={Loshchilov, Ilya and Hutter, Frank},
|
||||||
|
journal={arXiv preprint arXiv:1711.05101},
|
||||||
|
year={2017}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{spearman1961proof,
|
||||||
|
title={The proof and measurement of association between two things.},
|
||||||
|
author={Spearman, Charles},
|
||||||
|
year={1961},
|
||||||
|
publisher={Appleton-Century-Crofts}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{bruns2022deep,
|
||||||
|
title={Deep learning-based whole-heart segmentation in 4D contrast-enhanced cardiac CT},
|
||||||
|
author={Bruns, Steffen and Wolterink, Jelmer M and van den Boogert, Thomas PW and Runge, Jurgen H and Bouma, Berto J and Henriques, Jos{\'e} P and Baan, Jan and Viergever, Max A and Planken, R Nils and I{\v{s}}gum, Ivana},
|
||||||
|
journal={Computers in biology and medicine},
|
||||||
|
volume={142},
|
||||||
|
pages={105191},
|
||||||
|
year={2022},
|
||||||
|
publisher={Elsevier}
|
||||||
|
}
|
||||||
|
|
||||||
|
@misc{hutson2018artificial,
|
||||||
|
title={Artificial intelligence faces reproducibility crisis},
|
||||||
|
author={Hutson, Matthew},
|
||||||
|
year={2018},
|
||||||
|
publisher={American Association for the Advancement of Science}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{van2021sustainable,
|
||||||
|
title={Sustainable AI: AI for sustainability and the sustainability of AI},
|
||||||
|
author={van Wynsberghe, Aimee},
|
||||||
|
journal={AI and Ethics},
|
||||||
|
volume={1},
|
||||||
|
number={3},
|
||||||
|
pages={213--218},
|
||||||
|
year={2021},
|
||||||
|
publisher={Springer}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{10.1145/1400181.1400186,
|
||||||
|
author = {Kurp, Patrick},
|
||||||
|
title = {Green Computing},
|
||||||
|
year = {2008},
|
||||||
|
issue_date = {October 2008},
|
||||||
|
publisher = {Association for Computing Machinery},
|
||||||
|
address = {New York, NY, USA},
|
||||||
|
volume = {51},
|
||||||
|
number = {10},
|
||||||
|
issn = {0001-0782},
|
||||||
|
url = {https://doi.org/10.1145/1400181.1400186},
|
||||||
|
doi = {10.1145/1400181.1400186},
|
||||||
|
abstract = {Are you ready for a personal energy meter?},
|
||||||
|
journal = {Commun. ACM},
|
||||||
|
month = {oct},
|
||||||
|
pages = {11–13},
|
||||||
|
numpages = {3}
|
||||||
}
|
}
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue