andras/great-ai
1
0
Fork 0
Code Issues Pull requests 1 Projects Releases 4 Packages Wiki Activity Actions

Merge branch 'main' of https://github.com/schmelczer/great-ai

Browse source
This commit is contained in:
Andras Schmelczer 2022-07-16 15:36:01 +02:00
commit f7c82ed0fe
No known key found for this signature in database
GPG key ID: 39260B5B0614A13E
26 changed files with 1002 additions and 288 deletions
Download patch file Download diff file Expand all files Collapse all files

BIN
docs/examples/simple-mag/confusion-matrix.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 57 KiB

BIN
docs/examples/simple-mag/mag-confusion.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 1.5 MiB

257
docs/examples/simple-mag/train.ipynb
View file

File diff suppressed because one or more lines are too long

65
docs/examples/simple/deploy.ipynb
View file

File diff suppressed because one or more lines are too long

BIN
docs/examples/simple/ss-confusion.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 2.7 MiB

657
docs/examples/simple/train.ipynb
View file

@ -122,19 +122,646 @@
] ]
}, },
{ {
"ename": "NameError", "data": {
"evalue": "name 'pd' is not defined", "text/html": [
"output_type": "error", "<div>\n",
"traceback": [ "<style scoped>\n",
"\u001b[0;31m---------------------------------------------------------------------------\u001b[0m", " .dataframe tbody tr th:only-of-type {\n",
"\u001b[0;31mNameError\u001b[0m Traceback (most recent call last)", " vertical-align: middle;\n",
"\u001b[1;32m/data/projects/great-ai/docs/examples/simple/train.ipynb Cell 6\u001b[0m in \u001b[0;36m<cell line: 18>\u001b[0;34m()\u001b[0m\n\u001b[1;32m <a href='vscode-notebook-cell:/data/projects/great-ai/docs/examples/simple/train.ipynb#ch0000005?line=2'>3</a>\u001b[0m optimisation_pipeline \u001b[39m=\u001b[39m GridSearchCV(\n\u001b[1;32m <a href='vscode-notebook-cell:/data/projects/great-ai/docs/examples/simple/train.ipynb#ch0000005?line=3'>4</a>\u001b[0m create_pipeline(),\n\u001b[1;32m <a href='vscode-notebook-cell:/data/projects/great-ai/docs/examples/simple/train.ipynb#ch0000005?line=4'>5</a>\u001b[0m {\n\u001b[0;32m (...)\u001b[0m\n\u001b[1;32m <a href='vscode-notebook-cell:/data/projects/great-ai/docs/examples/simple/train.ipynb#ch0000005?line=13'>14</a>\u001b[0m verbose\u001b[39m=\u001b[39m\u001b[39m1\u001b[39m,\n\u001b[1;32m <a href='vscode-notebook-cell:/data/projects/great-ai/docs/examples/simple/train.ipynb#ch0000005?line=14'>15</a>\u001b[0m )\n\u001b[1;32m <a href='vscode-notebook-cell:/data/projects/great-ai/docs/examples/simple/train.ipynb#ch0000005?line=15'>16</a>\u001b[0m optimisation_pipeline\u001b[39m.\u001b[39mfit(X, y)\n\u001b[0;32m---> <a href='vscode-notebook-cell:/data/projects/great-ai/docs/examples/simple/train.ipynb#ch0000005?line=17'>18</a>\u001b[0m results \u001b[39m=\u001b[39m pd\u001b[39m.\u001b[39mDataFrame(optimisation_pipeline\u001b[39m.\u001b[39mcv_results_)\n\u001b[1;32m <a href='vscode-notebook-cell:/data/projects/great-ai/docs/examples/simple/train.ipynb#ch0000005?line=18'>19</a>\u001b[0m results\u001b[39m.\u001b[39msort_values(\u001b[39m\"\u001b[39m\u001b[39mrank_test_score\u001b[39m\u001b[39m\"\u001b[39m)\n", " }\n",
"\u001b[0;31mNameError\u001b[0m: name 'pd' is not defined" "\n",
] " .dataframe tbody tr th {\n",
" vertical-align: top;\n",
" }\n",
"\n",
" .dataframe thead th {\n",
" text-align: right;\n",
" }\n",
"</style>\n",
"<table border=\"1\" class=\"dataframe\">\n",
" <thead>\n",
" <tr style=\"text-align: right;\">\n",
" <th></th>\n",
" <th>mean_fit_time</th>\n",
" <th>std_fit_time</th>\n",
" <th>mean_score_time</th>\n",
" <th>std_score_time</th>\n",
" <th>param_classifier__alpha</th>\n",
" <th>param_classifier__fit_prior</th>\n",
" <th>param_vectorizer__max_df</th>\n",
" <th>param_vectorizer__min_df</th>\n",
" <th>params</th>\n",
" <th>split0_test_score</th>\n",
" <th>split1_test_score</th>\n",
" <th>split2_test_score</th>\n",
" <th>mean_test_score</th>\n",
" <th>std_test_score</th>\n",
" <th>rank_test_score</th>\n",
" </tr>\n",
" </thead>\n",
" <tbody>\n",
" <tr>\n",
" <th>7</th>\n",
" <td>14.549476</td>\n",
" <td>0.361685</td>\n",
" <td>8.476837</td>\n",
" <td>0.222398</td>\n",
" <td>0.5</td>\n",
" <td>False</td>\n",
" <td>0.05</td>\n",
" <td>20</td>\n",
" <td>{'classifier__alpha': 0.5, 'classifier__fit_pr...</td>\n",
" <td>0.518061</td>\n",
" <td>0.514842</td>\n",
" <td>0.511599</td>\n",
" <td>0.514834</td>\n",
" <td>0.002638</td>\n",
" <td>1</td>\n",
" </tr>\n",
" <tr>\n",
" <th>10</th>\n",
" <td>11.235289</td>\n",
" <td>0.130426</td>\n",
" <td>4.092868</td>\n",
" <td>0.082518</td>\n",
" <td>0.5</td>\n",
" <td>False</td>\n",
" <td>0.1</td>\n",
" <td>20</td>\n",
" <td>{'classifier__alpha': 0.5, 'classifier__fit_pr...</td>\n",
" <td>0.513897</td>\n",
" <td>0.515661</td>\n",
" <td>0.507867</td>\n",
" <td>0.512475</td>\n",
" <td>0.003337</td>\n",
" <td>2</td>\n",
" </tr>\n",
" <tr>\n",
" <th>19</th>\n",
" <td>7.383645</td>\n",
" <td>0.138110</td>\n",
" <td>4.130709</td>\n",
" <td>0.250048</td>\n",
" <td>1</td>\n",
" <td>False</td>\n",
" <td>0.05</td>\n",
" <td>20</td>\n",
" <td>{'classifier__alpha': 1, 'classifier__fit_prio...</td>\n",
" <td>0.496825</td>\n",
" <td>0.501045</td>\n",
" <td>0.496854</td>\n",
" <td>0.498241</td>\n",
" <td>0.001983</td>\n",
" <td>3</td>\n",
" </tr>\n",
" <tr>\n",
" <th>11</th>\n",
" <td>10.435154</td>\n",
" <td>0.305144</td>\n",
" <td>3.882101</td>\n",
" <td>0.128886</td>\n",
" <td>0.5</td>\n",
" <td>False</td>\n",
" <td>0.1</td>\n",
" <td>100</td>\n",
" <td>{'classifier__alpha': 0.5, 'classifier__fit_pr...</td>\n",
" <td>0.493247</td>\n",
" <td>0.497814</td>\n",
" <td>0.502245</td>\n",
" <td>0.497769</td>\n",
" <td>0.003674</td>\n",
" <td>4</td>\n",
" </tr>\n",
" <tr>\n",
" <th>8</th>\n",
" <td>13.643193</td>\n",
" <td>0.310696</td>\n",
" <td>4.173707</td>\n",
" <td>0.142980</td>\n",
" <td>0.5</td>\n",
" <td>False</td>\n",
" <td>0.05</td>\n",
" <td>100</td>\n",
" <td>{'classifier__alpha': 0.5, 'classifier__fit_pr...</td>\n",
" <td>0.489609</td>\n",
" <td>0.495207</td>\n",
" <td>0.498154</td>\n",
" <td>0.494323</td>\n",
" <td>0.003544</td>\n",
" <td>5</td>\n",
" </tr>\n",
" <tr>\n",
" <th>22</th>\n",
" <td>7.048340</td>\n",
" <td>0.050070</td>\n",
" <td>3.172948</td>\n",
" <td>0.152418</td>\n",
" <td>1</td>\n",
" <td>False</td>\n",
" <td>0.1</td>\n",
" <td>20</td>\n",
" <td>{'classifier__alpha': 1, 'classifier__fit_prio...</td>\n",
" <td>0.487456</td>\n",
" <td>0.493865</td>\n",
" <td>0.491157</td>\n",
" <td>0.490826</td>\n",
" <td>0.002627</td>\n",
" <td>6</td>\n",
" </tr>\n",
" <tr>\n",
" <th>23</th>\n",
" <td>7.564685</td>\n",
" <td>0.146092</td>\n",
" <td>2.374111</td>\n",
" <td>0.285026</td>\n",
" <td>1</td>\n",
" <td>False</td>\n",
" <td>0.1</td>\n",
" <td>100</td>\n",
" <td>{'classifier__alpha': 1, 'classifier__fit_prio...</td>\n",
" <td>0.485160</td>\n",
" <td>0.494039</td>\n",
" <td>0.490127</td>\n",
" <td>0.489776</td>\n",
" <td>0.003633</td>\n",
" <td>7</td>\n",
" </tr>\n",
" <tr>\n",
" <th>20</th>\n",
" <td>7.172353</td>\n",
" <td>0.212599</td>\n",
" <td>3.747219</td>\n",
" <td>0.130217</td>\n",
" <td>1</td>\n",
" <td>False</td>\n",
" <td>0.05</td>\n",
" <td>100</td>\n",
" <td>{'classifier__alpha': 1, 'classifier__fit_prio...</td>\n",
" <td>0.481303</td>\n",
" <td>0.490002</td>\n",
" <td>0.488269</td>\n",
" <td>0.486524</td>\n",
" <td>0.003759</td>\n",
" <td>8</td>\n",
" </tr>\n",
" <tr>\n",
" <th>6</th>\n",
" <td>14.276345</td>\n",
" <td>0.456576</td>\n",
" <td>8.318859</td>\n",
" <td>0.268701</td>\n",
" <td>0.5</td>\n",
" <td>False</td>\n",
" <td>0.05</td>\n",
" <td>5</td>\n",
" <td>{'classifier__alpha': 0.5, 'classifier__fit_pr...</td>\n",
" <td>0.482429</td>\n",
" <td>0.487735</td>\n",
" <td>0.484888</td>\n",
" <td>0.485017</td>\n",
" <td>0.002168</td>\n",
" <td>9</td>\n",
" </tr>\n",
" <tr>\n",
" <th>2</th>\n",
" <td>14.902358</td>\n",
" <td>0.737693</td>\n",
" <td>5.975091</td>\n",
" <td>0.171150</td>\n",
" <td>0.5</td>\n",
" <td>True</td>\n",
" <td>0.05</td>\n",
" <td>100</td>\n",
" <td>{'classifier__alpha': 0.5, 'classifier__fit_pr...</td>\n",
" <td>0.469598</td>\n",
" <td>0.474490</td>\n",
" <td>0.473637</td>\n",
" <td>0.472575</td>\n",
" <td>0.002134</td>\n",
" <td>10</td>\n",
" </tr>\n",
" <tr>\n",
" <th>9</th>\n",
" <td>12.677349</td>\n",
" <td>0.145143</td>\n",
" <td>4.374204</td>\n",
" <td>0.175674</td>\n",
" <td>0.5</td>\n",
" <td>False</td>\n",
" <td>0.1</td>\n",
" <td>5</td>\n",
" <td>{'classifier__alpha': 0.5, 'classifier__fit_pr...</td>\n",
" <td>0.468872</td>\n",
" <td>0.476451</td>\n",
" <td>0.470921</td>\n",
" <td>0.472082</td>\n",
" <td>0.003201</td>\n",
" <td>11</td>\n",
" </tr>\n",
" <tr>\n",
" <th>5</th>\n",
" <td>13.423686</td>\n",
" <td>0.482872</td>\n",
" <td>8.008324</td>\n",
" <td>0.442975</td>\n",
" <td>0.5</td>\n",
" <td>True</td>\n",
" <td>0.1</td>\n",
" <td>100</td>\n",
" <td>{'classifier__alpha': 0.5, 'classifier__fit_pr...</td>\n",
" <td>0.465726</td>\n",
" <td>0.474548</td>\n",
" <td>0.471879</td>\n",
" <td>0.470718</td>\n",
" <td>0.003694</td>\n",
" <td>12</td>\n",
" </tr>\n",
" <tr>\n",
" <th>1</th>\n",
" <td>13.819117</td>\n",
" <td>0.838347</td>\n",
" <td>6.161175</td>\n",
" <td>0.336590</td>\n",
" <td>0.5</td>\n",
" <td>True</td>\n",
" <td>0.05</td>\n",
" <td>20</td>\n",
" <td>{'classifier__alpha': 0.5, 'classifier__fit_pr...</td>\n",
" <td>0.463395</td>\n",
" <td>0.473982</td>\n",
" <td>0.471262</td>\n",
" <td>0.469546</td>\n",
" <td>0.004489</td>\n",
" <td>13</td>\n",
" </tr>\n",
" <tr>\n",
" <th>4</th>\n",
" <td>13.281476</td>\n",
" <td>0.588822</td>\n",
" <td>8.335852</td>\n",
" <td>0.254627</td>\n",
" <td>0.5</td>\n",
" <td>True</td>\n",
" <td>0.1</td>\n",
" <td>20</td>\n",
" <td>{'classifier__alpha': 0.5, 'classifier__fit_pr...</td>\n",
" <td>0.458734</td>\n",
" <td>0.468053</td>\n",
" <td>0.464418</td>\n",
" <td>0.463735</td>\n",
" <td>0.003835</td>\n",
" <td>14</td>\n",
" </tr>\n",
" <tr>\n",
" <th>14</th>\n",
" <td>7.282247</td>\n",
" <td>0.444940</td>\n",
" <td>3.567094</td>\n",
" <td>0.044519</td>\n",
" <td>1</td>\n",
" <td>True</td>\n",
" <td>0.05</td>\n",
" <td>100</td>\n",
" <td>{'classifier__alpha': 1, 'classifier__fit_prio...</td>\n",
" <td>0.438189</td>\n",
" <td>0.450160</td>\n",
" <td>0.446180</td>\n",
" <td>0.444843</td>\n",
" <td>0.004978</td>\n",
" <td>15</td>\n",
" </tr>\n",
" <tr>\n",
" <th>17</th>\n",
" <td>7.098797</td>\n",
" <td>0.196241</td>\n",
" <td>3.838628</td>\n",
" <td>0.091128</td>\n",
" <td>1</td>\n",
" <td>True</td>\n",
" <td>0.1</td>\n",
" <td>100</td>\n",
" <td>{'classifier__alpha': 1, 'classifier__fit_prio...</td>\n",
" <td>0.436488</td>\n",
" <td>0.444503</td>\n",
" <td>0.445900</td>\n",
" <td>0.442297</td>\n",
" <td>0.004147</td>\n",
" <td>16</td>\n",
" </tr>\n",
" <tr>\n",
" <th>18</th>\n",
" <td>7.492791</td>\n",
" <td>0.288889</td>\n",
" <td>3.843224</td>\n",
" <td>0.073438</td>\n",
" <td>1</td>\n",
" <td>False</td>\n",
" <td>0.05</td>\n",
" <td>5</td>\n",
" <td>{'classifier__alpha': 1, 'classifier__fit_prio...</td>\n",
" <td>0.428196</td>\n",
" <td>0.431945</td>\n",
" <td>0.430160</td>\n",
" <td>0.430100</td>\n",
" <td>0.001531</td>\n",
" <td>17</td>\n",
" </tr>\n",
" <tr>\n",
" <th>21</th>\n",
" <td>7.229826</td>\n",
" <td>0.099823</td>\n",
" <td>3.656332</td>\n",
" <td>0.073780</td>\n",
" <td>1</td>\n",
" <td>False</td>\n",
" <td>0.1</td>\n",
" <td>5</td>\n",
" <td>{'classifier__alpha': 1, 'classifier__fit_prio...</td>\n",
" <td>0.403130</td>\n",
" <td>0.410170</td>\n",
" <td>0.409801</td>\n",
" <td>0.407700</td>\n",
" <td>0.003235</td>\n",
" <td>18</td>\n",
" </tr>\n",
" <tr>\n",
" <th>13</th>\n",
" <td>7.158370</td>\n",
" <td>0.169818</td>\n",
" <td>3.765632</td>\n",
" <td>0.082924</td>\n",
" <td>1</td>\n",
" <td>True</td>\n",
" <td>0.05</td>\n",
" <td>20</td>\n",
" <td>{'classifier__alpha': 1, 'classifier__fit_prio...</td>\n",
" <td>0.399237</td>\n",
" <td>0.412872</td>\n",
" <td>0.407982</td>\n",
" <td>0.406697</td>\n",
" <td>0.005640</td>\n",
" <td>19</td>\n",
" </tr>\n",
" <tr>\n",
" <th>16</th>\n",
" <td>7.064643</td>\n",
" <td>0.119529</td>\n",
" <td>3.810983</td>\n",
" <td>0.125897</td>\n",
" <td>1</td>\n",
" <td>True</td>\n",
" <td>0.1</td>\n",
" <td>20</td>\n",
" <td>{'classifier__alpha': 1, 'classifier__fit_prio...</td>\n",
" <td>0.388060</td>\n",
" <td>0.399247</td>\n",
" <td>0.396325</td>\n",
" <td>0.394544</td>\n",
" <td>0.004737</td>\n",
" <td>20</td>\n",
" </tr>\n",
" <tr>\n",
" <th>0</th>\n",
" <td>13.749660</td>\n",
" <td>0.465174</td>\n",
" <td>6.407841</td>\n",
" <td>0.549166</td>\n",
" <td>0.5</td>\n",
" <td>True</td>\n",
" <td>0.05</td>\n",
" <td>5</td>\n",
" <td>{'classifier__alpha': 0.5, 'classifier__fit_pr...</td>\n",
" <td>0.384852</td>\n",
" <td>0.386487</td>\n",
" <td>0.386796</td>\n",
" <td>0.386045</td>\n",
" <td>0.000853</td>\n",
" <td>21</td>\n",
" </tr>\n",
" <tr>\n",
" <th>3</th>\n",
" <td>15.954147</td>\n",
" <td>0.318013</td>\n",
" <td>6.337361</td>\n",
" <td>0.261697</td>\n",
" <td>0.5</td>\n",
" <td>True</td>\n",
" <td>0.1</td>\n",
" <td>5</td>\n",
" <td>{'classifier__alpha': 0.5, 'classifier__fit_pr...</td>\n",
" <td>0.369785</td>\n",
" <td>0.375645</td>\n",
" <td>0.375858</td>\n",
" <td>0.373763</td>\n",
" <td>0.002814</td>\n",
" <td>22</td>\n",
" </tr>\n",
" <tr>\n",
" <th>12</th>\n",
" <td>7.120198</td>\n",
" <td>0.050452</td>\n",
" <td>3.833905</td>\n",
" <td>0.069540</td>\n",
" <td>1</td>\n",
" <td>True</td>\n",
" <td>0.05</td>\n",
" <td>5</td>\n",
" <td>{'classifier__alpha': 1, 'classifier__fit_prio...</td>\n",
" <td>0.277741</td>\n",
" <td>0.280564</td>\n",
" <td>0.285337</td>\n",
" <td>0.281214</td>\n",
" <td>0.003135</td>\n",
" <td>23</td>\n",
" </tr>\n",
" <tr>\n",
" <th>15</th>\n",
" <td>7.497707</td>\n",
" <td>0.183054</td>\n",
" <td>3.870714</td>\n",
" <td>0.062888</td>\n",
" <td>1</td>\n",
" <td>True</td>\n",
" <td>0.1</td>\n",
" <td>5</td>\n",
" <td>{'classifier__alpha': 1, 'classifier__fit_prio...</td>\n",
" <td>0.255578</td>\n",
" <td>0.263381</td>\n",
" <td>0.266184</td>\n",
" <td>0.261714</td>\n",
" <td>0.004487</td>\n",
" <td>24</td>\n",
" </tr>\n",
" </tbody>\n",
"</table>\n",
"</div>"
],
"text/plain": [
" mean_fit_time std_fit_time mean_score_time std_score_time \\\n",
"7 14.549476 0.361685 8.476837 0.222398 \n",
"10 11.235289 0.130426 4.092868 0.082518 \n",
"19 7.383645 0.138110 4.130709 0.250048 \n",
"11 10.435154 0.305144 3.882101 0.128886 \n",
"8 13.643193 0.310696 4.173707 0.142980 \n",
"22 7.048340 0.050070 3.172948 0.152418 \n",
"23 7.564685 0.146092 2.374111 0.285026 \n",
"20 7.172353 0.212599 3.747219 0.130217 \n",
"6 14.276345 0.456576 8.318859 0.268701 \n",
"2 14.902358 0.737693 5.975091 0.171150 \n",
"9 12.677349 0.145143 4.374204 0.175674 \n",
"5 13.423686 0.482872 8.008324 0.442975 \n",
"1 13.819117 0.838347 6.161175 0.336590 \n",
"4 13.281476 0.588822 8.335852 0.254627 \n",
"14 7.282247 0.444940 3.567094 0.044519 \n",
"17 7.098797 0.196241 3.838628 0.091128 \n",
"18 7.492791 0.288889 3.843224 0.073438 \n",
"21 7.229826 0.099823 3.656332 0.073780 \n",
"13 7.158370 0.169818 3.765632 0.082924 \n",
"16 7.064643 0.119529 3.810983 0.125897 \n",
"0 13.749660 0.465174 6.407841 0.549166 \n",
"3 15.954147 0.318013 6.337361 0.261697 \n",
"12 7.120198 0.050452 3.833905 0.069540 \n",
"15 7.497707 0.183054 3.870714 0.062888 \n",
"\n",
" param_classifier__alpha param_classifier__fit_prior \\\n",
"7 0.5 False \n",
"10 0.5 False \n",
"19 1 False \n",
"11 0.5 False \n",
"8 0.5 False \n",
"22 1 False \n",
"23 1 False \n",
"20 1 False \n",
"6 0.5 False \n",
"2 0.5 True \n",
"9 0.5 False \n",
"5 0.5 True \n",
"1 0.5 True \n",
"4 0.5 True \n",
"14 1 True \n",
"17 1 True \n",
"18 1 False \n",
"21 1 False \n",
"13 1 True \n",
"16 1 True \n",
"0 0.5 True \n",
"3 0.5 True \n",
"12 1 True \n",
"15 1 True \n",
"\n",
" param_vectorizer__max_df param_vectorizer__min_df \\\n",
"7 0.05 20 \n",
"10 0.1 20 \n",
"19 0.05 20 \n",
"11 0.1 100 \n",
"8 0.05 100 \n",
"22 0.1 20 \n",
"23 0.1 100 \n",
"20 0.05 100 \n",
"6 0.05 5 \n",
"2 0.05 100 \n",
"9 0.1 5 \n",
"5 0.1 100 \n",
"1 0.05 20 \n",
"4 0.1 20 \n",
"14 0.05 100 \n",
"17 0.1 100 \n",
"18 0.05 5 \n",
"21 0.1 5 \n",
"13 0.05 20 \n",
"16 0.1 20 \n",
"0 0.05 5 \n",
"3 0.1 5 \n",
"12 0.05 5 \n",
"15 0.1 5 \n",
"\n",
" params split0_test_score \\\n",
"7 {'classifier__alpha': 0.5, 'classifier__fit_pr... 0.518061 \n",
"10 {'classifier__alpha': 0.5, 'classifier__fit_pr... 0.513897 \n",
"19 {'classifier__alpha': 1, 'classifier__fit_prio... 0.496825 \n",
"11 {'classifier__alpha': 0.5, 'classifier__fit_pr... 0.493247 \n",
"8 {'classifier__alpha': 0.5, 'classifier__fit_pr... 0.489609 \n",
"22 {'classifier__alpha': 1, 'classifier__fit_prio... 0.487456 \n",
"23 {'classifier__alpha': 1, 'classifier__fit_prio... 0.485160 \n",
"20 {'classifier__alpha': 1, 'classifier__fit_prio... 0.481303 \n",
"6 {'classifier__alpha': 0.5, 'classifier__fit_pr... 0.482429 \n",
"2 {'classifier__alpha': 0.5, 'classifier__fit_pr... 0.469598 \n",
"9 {'classifier__alpha': 0.5, 'classifier__fit_pr... 0.468872 \n",
"5 {'classifier__alpha': 0.5, 'classifier__fit_pr... 0.465726 \n",
"1 {'classifier__alpha': 0.5, 'classifier__fit_pr... 0.463395 \n",
"4 {'classifier__alpha': 0.5, 'classifier__fit_pr... 0.458734 \n",
"14 {'classifier__alpha': 1, 'classifier__fit_prio... 0.438189 \n",
"17 {'classifier__alpha': 1, 'classifier__fit_prio... 0.436488 \n",
"18 {'classifier__alpha': 1, 'classifier__fit_prio... 0.428196 \n",
"21 {'classifier__alpha': 1, 'classifier__fit_prio... 0.403130 \n",
"13 {'classifier__alpha': 1, 'classifier__fit_prio... 0.399237 \n",
"16 {'classifier__alpha': 1, 'classifier__fit_prio... 0.388060 \n",
"0 {'classifier__alpha': 0.5, 'classifier__fit_pr... 0.384852 \n",
"3 {'classifier__alpha': 0.5, 'classifier__fit_pr... 0.369785 \n",
"12 {'classifier__alpha': 1, 'classifier__fit_prio... 0.277741 \n",
"15 {'classifier__alpha': 1, 'classifier__fit_prio... 0.255578 \n",
"\n",
" split1_test_score split2_test_score mean_test_score std_test_score \\\n",
"7 0.514842 0.511599 0.514834 0.002638 \n",
"10 0.515661 0.507867 0.512475 0.003337 \n",
"19 0.501045 0.496854 0.498241 0.001983 \n",
"11 0.497814 0.502245 0.497769 0.003674 \n",
"8 0.495207 0.498154 0.494323 0.003544 \n",
"22 0.493865 0.491157 0.490826 0.002627 \n",
"23 0.494039 0.490127 0.489776 0.003633 \n",
"20 0.490002 0.488269 0.486524 0.003759 \n",
"6 0.487735 0.484888 0.485017 0.002168 \n",
"2 0.474490 0.473637 0.472575 0.002134 \n",
"9 0.476451 0.470921 0.472082 0.003201 \n",
"5 0.474548 0.471879 0.470718 0.003694 \n",
"1 0.473982 0.471262 0.469546 0.004489 \n",
"4 0.468053 0.464418 0.463735 0.003835 \n",
"14 0.450160 0.446180 0.444843 0.004978 \n",
"17 0.444503 0.445900 0.442297 0.004147 \n",
"18 0.431945 0.430160 0.430100 0.001531 \n",
"21 0.410170 0.409801 0.407700 0.003235 \n",
"13 0.412872 0.407982 0.406697 0.005640 \n",
"16 0.399247 0.396325 0.394544 0.004737 \n",
"0 0.386487 0.386796 0.386045 0.000853 \n",
"3 0.375645 0.375858 0.373763 0.002814 \n",
"12 0.280564 0.285337 0.281214 0.003135 \n",
"15 0.263381 0.266184 0.261714 0.004487 \n",
"\n",
" rank_test_score \n",
"7 1 \n",
"10 2 \n",
"19 3 \n",
"11 4 \n",
"8 5 \n",
"22 6 \n",
"23 7 \n",
"20 8 \n",
"6 9 \n",
"2 10 \n",
"9 11 \n",
"5 12 \n",
"1 13 \n",
"4 14 \n",
"14 15 \n",
"17 16 \n",
"18 17 \n",
"21 18 \n",
"13 19 \n",
"16 20 \n",
"0 21 \n",
"3 22 \n",
"12 23 \n",
"15 24 "
]
},
"execution_count": 4,
"metadata": {},
"output_type": "execute_result"
} }
], ],
"source": [ "source": [
"from sklearn.model_selection import GridSearchCV\n", "from sklearn.model_selection import GridSearchCV\n",
"import pandas as pd\n",
"\n", "\n",
"optimisation_pipeline = GridSearchCV(\n", "optimisation_pipeline = GridSearchCV(\n",
" create_pipeline(),\n", " create_pipeline(),\n",
@ -157,7 +784,7 @@
}, },
{ {
"cell_type": "code", "cell_type": "code",
"execution_count": null, "execution_count": 5,
"metadata": {}, "metadata": {},
"outputs": [ "outputs": [
{ {
@ -199,7 +826,7 @@
}, },
{ {
"cell_type": "code", "cell_type": "code",
"execution_count": null, "execution_count": 6,
"metadata": {}, "metadata": {},
"outputs": [ "outputs": [
{ {
@ -207,15 +834,15 @@
"output_type": "stream", "output_type": "stream",
"text": [ "text": [
"\u001b[38;5;39mFetching cached versions of small-domain-prediction\u001b[0m\n", "\u001b[38;5;39mFetching cached versions of small-domain-prediction\u001b[0m\n",
"\u001b[38;5;39mCopying file for small-domain-prediction-1\u001b[0m\n", "\u001b[38;5;39mCopying file for small-domain-prediction-2\u001b[0m\n",
"\u001b[38;5;39mCompressing small-domain-prediction-1\u001b[0m\n", "\u001b[38;5;39mCompressing small-domain-prediction-2\u001b[0m\n",
"\u001b[38;5;39mModel small-domain-prediction uploaded with version 1\u001b[0m\n" "\u001b[38;5;39mModel small-domain-prediction uploaded with version 2\u001b[0m\n"
] ]
}, },
{ {
"data": { "data": {
"text/plain": [ "text/plain": [
"'small-domain-prediction:1'" "'small-domain-prediction:2'"
] ]
}, },
"execution_count": 6, "execution_count": 6,

4
docs/thesis/chapters/0_abstract.tex
View file

@ -1,11 +1,11 @@
\begin{abstract} \begin{abstract}
\absdiv{Background} \absdiv{Background}
Despite its long-standing history, artificial intelligence (AI) has only recently started enjoying widespread industry awareness and adoption; partly thanks to the prevalence of accessible frameworks exposing state-of-the-art models through simple API-s. In order to achieve robust production deployments, the successful integration of AI components demands strong engineering methods. Concerningly, a tendency seems to be unfolding: even though industry professionals already have access to frameworks for deploying AI correctly and responsibly, case-studies and developer surveys have found that a large fraction of deployments do not follow best practices. Despite its long-standing history, artificial intelligence (AI) has only recently started enjoying widespread industry awareness and adoption; partly thanks to the prevalence of frameworks accessibly exposing state-of-the-art models. In order to achieve robust production deployments, the successful integration of AI components demands strong engineering methods. Concerningly, a tendency seems to be unfolding: even though professionals already have access to frameworks for deploying AI correctly and responsibly, case studies and developer surveys have found that a large fraction of deployments do not follow best practices.
\absdiv{Objective} \absdiv{Objective}
This thesis sets out to investigate the reasons behind the asymmetry between the adoption of accessible AI libraries and existing reusable solutions to robust deployments. A software framework called \textit{GreatAI} is designed which aims to facilitate \underline{G}eneral \underline{R}obust \underline{E}nd-to-end \underline{A}utomated \underline{T}rustworthy AI deployments while attempting to overcome the practical drawbacks of its predecessors. This thesis sets out to investigate the reasons behind the asymmetry between the adoption of accessible AI libraries and existing reusable solutions to robust deployments. A software framework called \textit{GreatAI} is designed which aims to facilitate \underline{G}eneral \underline{R}obust \underline{E}nd-to-end \underline{A}utomated \underline{T}rustworthy AI deployments while attempting to overcome the practical drawbacks of its predecessors.
\absdiv{Method} \absdiv{Method}
The utility of \textit{GreatAI} is validated using the principles of design science methodology through iteratively designing its API and implementation along with the text mining pipeline of a commercial product. Subsequently, interviews are conducted with practitioners for validating the generalisability of the design. The utility of \textit{GreatAI} is validated using the principles of design science methodology through iteratively designing its API and implementation in a case study of a commercial text mining pipeline. Subsequently, interviews are conducted with practitioners for validating the generalisability of the design.
\absdiv{Results} \absdiv{Results}
To do. To do.
\absdiv{Conclusions} \absdiv{Conclusions}

44
docs/thesis/chapters/1_introduction.tex
View file

@ -4,53 +4,31 @@ Artificial intelligence (AI) techniques have recently started enjoying widesprea
However, the successful integration of AI components into production-ready applications demands strong engineering methods in order to achieve robust deployments \cite{serban2020adoption}. That is why it is as important as ever to also focus on the quality and robustness of deployed models and software. For instance, the lack of a proper overview of the data transformation steps may lead to suboptimal performance and to introducing unintended biases which may contribute to the ever-increasing negative externality of misused AI \cite{o2016weapons}. However, the successful integration of AI components into production-ready applications demands strong engineering methods in order to achieve robust deployments \cite{serban2020adoption}. That is why it is as important as ever to also focus on the quality and robustness of deployed models and software. For instance, the lack of a proper overview of the data transformation steps may lead to suboptimal performance and to introducing unintended biases which may contribute to the ever-increasing negative externality of misused AI \cite{o2016weapons}.
Concerningly, a peculiar tendency seems to be unfolding: even though industry professionals already have access to numerous frameworks for deploying AI correctly and responsibly, case-studies and developer surveys have found that a considerable fraction of deployments do not follow best practices \cite{serban2020adoption,haakman2021ai,amershi2019software,de2019understanding,sculley2015hidden}. Utilising state-of-the-art machine-learning (ML) models has become reasonably simple; applying them properly is as difficult and nuanced as ever. Concerningly, a peculiar tendency seems to be unfolding: even though industry professionals already have access to numerous frameworks for deploying AI correctly and responsibly, case studies and developer surveys have found that a considerable fraction of deployments do not follow best practices \cite{serban2020adoption,haakman2021ai,amershi2019software,de2019understanding,sculley2015hidden}. Utilising state-of-the-art machine-learning (ML) models has become reasonably simple; applying them properly is as difficult and nuanced as ever.
This thesis sets out to investigate the reasons behind the apparent asymmetry between the adoption of accessible AI libraries and existing reusable solutions for robust AI deployments. It is hypothesised that the primary reason for the underwhelming adoption rate of best practices is the short supply or professionals equally proficient in the domains of both data science and software engineering. Nevertheless, even without their presence, practitioners could rely on frameworks for automated mature deployment processes. However, the barrier of entry for using such existing libraries is too high, especially when compared with the complexity of AI-libraries. This thesis sets out to investigate the reasons behind the apparent asymmetry between the adoption of accessible AI libraries and existing reusable solutions for robust AI deployments. It is hypothesised that the primary reason for the underwhelming adoption rate of best practices is the short supply of professionals equally proficient in the domains of both data science and software engineering. Nevertheless, even without their presence, practitioners could rely on frameworks for automated mature deployment processes. However, the barrier of entry for using such existing libraries is too high, especially when compared with the complexity of AI-libraries.
Therefore, a software framework --- called \textit{GreatAI} --- is designed and its design is presented in this thesis. The principal motivation behind the construction of \textit{GreatAI} is to facilitate the responsible and robust deployment of algorithms and models by designing an accessible API in an attempt to overcome the practical drawbacks of other, similar frameworks. Its name stands for its main aim: to assist easily creating \underline{G}eneral \underline{R}obust \underline{E}nd-to-end \underline{A}utomated, and \underline{T}rustworthy AI deployments. Therefore, a software framework --- called \textit{GreatAI}\footnote{\href{https://github.com/schmelczer/great-ai}{github.com/schmelczer/great-ai}} --- is designed and its design is presented in this thesis. The principal motivation behind the construction of \textit{GreatAI} is to facilitate the responsible and robust deployment of algorithms and models by designing an accessible API in an attempt to overcome the practical drawbacks of other, similar frameworks. Its name stands for its main aim: to assist easily creating \underline{G}eneral \underline{R}obust \underline{E}nd-to-end \underline{A}utomated, and \underline{T}rustworthy AI deployments.
The utility of \textit{GreatAI} is validated using the principles of design science methodology \cite{wieringa2014design} through iteratively designing its API and implementation along with the text mining pipeline for a commercial product in collaboration with ScoutinScience B.V. The goal of the aforementioned software suite is to evaluate technical transfer opportunities in scientific publications. Subsequently, interviews are conducted with practitioners for validating the generalisability of the design. The utility of \textit{GreatAI} is validated using the principles of design science methodology \cite{wieringa2014design} through iteratively designing its API and implementation in a case study concerning the text mining pipeline for a commercial product in collaboration with ScoutinScience B.V.\footnote{\href{https://scoutinscience.com/}{scoutinscience.com}} The goal of the aforementioned software suite is to evaluate technical transfer opportunities in scientific publications. Subsequently, interviews are conducted with practitioners for validating the generalisability of the design.
\section{Research questions} \section{Research questions}
I hypothesise that facilitating the adoption of AI deployment best practices is viable by finding less complex framework designs which are easier to adopt in order to decrease the negative externality of misused AI. This paper is set out to investigate this hypothesis by answering the following research questions. I hypothesise that facilitating the adoption of AI deployment best practices is viable by finding less complex framework designs which are easier to adopt in order to decrease the negative externality of misused AI. This paper is set out to investigate this hypothesis by answering the following research questions.
\begin{rqlist} \begin{rqlist}
\item Does the complexity of AI deployment frameworks hinder industrial projects? \item To what extent does the complexity of AI deployment frameworks hinder industrial applications?
\item What is an effective way of decreasing the complexity of existing frameworks? \item What API design techniques can be effectively applied in order to decrease the complexity of correctly deploying AI services?
\item Does \textit{GreatAI}'s design improve the efficiency of working with AI while also introducing best practices? \item To what extent can \textit{GreatAI} automatically implement AI deployment best practices?
\item Can the design of \textit{GreatAI} decrease the barrier of entry for applying best practices in other contexts? \item How adequate is the design of \textit{GreatAI} for helping to apply best practices in other contexts?
\end{rqlist} \end{rqlist}
In this case, complexity is used to refer to the difficulty faced by professionals (data scientists and software engineers alike) when integrating libraries with their solutions. This could also be described as the barrier of entry or steepness of the learning curve. If the aforementioned hypothesis is correct, the adoption of best practices can be efficiently increased by decreasing this complexity. In this case, complexity refers to the difficulty faced by professionals (data scientists and software engineers alike) when integrating libraries with their solutions. This could also be described as the barrier of entry or steepness of the learning curve. If the aforementioned hypothesis is correct, the adoption of best practices can be efficiently increased by decreasing this complexity.
AI deployment best practices entail the technical steps that ought to be taken in order to achieve robust, end-to-end, automated, and trustworthy deployments. These are detailed in Section \ref{section:requirements}. AI deployment best practices entail the technical steps that ought to be taken in order to achieve robust, end-to-end, automated, and trustworthy deployments. These are detailed in Section \ref{section:requirements}.
The existence question regarding the problem itself (\textbf{RQ1}) is answered by reviewing the literature of the more than 30 published case-studies. \textbf{RQ2} and \textbf{RQ3} are closely connected, the design and evaluation phases utilised to answer them follow an iterative process. They are examined in Chapter \ref{chapter:design} and Chapter \ref{chapter:case} respectively. The final evaluation step is to ascertain the capability of the framework design to generalise beyond a single subdomain and problem context. This question, \textbf{RQ4}, is investigated through interviews with industry professionals in Chapter \ref{chapter:interviews}. The existence question regarding the problem itself (\textbf{RQ1}) is answered by reviewing the literature of the more than 30 published case studies. \textbf{RQ2} and \textbf{RQ3} are closely connected, the design and evaluation phases utilised to answer them follow an iterative process. They are examined in Chapter \ref{chapter:design} and Chapter \ref{chapter:case} respectively. The final evaluation step is to ascertain the capability of the framework design to generalise beyond a single subdomain and problem context. This question, \textbf{RQ4}, is investigated through interviews with industry professionals in Chapter \ref{chapter:interviews}.
\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.
\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 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 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{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.
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.
\newpage
\section{Structure} \section{Structure}
The rest of the thesis is organised as follows: Chapter \ref{chapter:background} approaches the problem and the state-of-the-art from three perspectives: the trends of AI library API design, the experiences gained from practical applications, and a comparison of existing deployment options. Next, the methodology utilised for the subsequent chapters is described in Chapter \ref{chapter:methods}. The design cycle is broken into two chapters, Chapter \ref{chapter:design} and \ref{chapter:case}. The former clarifies the scope and describes the design principles, while the latter details the specifics of the practical use-case and the framework's interaction with it, and technological contributions of the novel design. The results are further validated by conducting interviews with industry professionals in Chapter \ref{chapter:interviews}. The thesis is concluded in Chapter \ref{chapter:conclusion}. The rest of the thesis is organised as follows: Chapter \ref{chapter:background} approaches the problem and the state-of-the-art from three perspectives: the trends of AI library API designs, the experiences gained from practical applications, and a comparison of existing deployment options. Next, the methodology utilised for the subsequent chapters is described in Chapter \ref{chapter:methods}. The design cycle is broken into two chapters, Chapter \ref{chapter:design} and \ref{chapter:case}. The former clarifies the scope and describes the design principles, while the latter details the specifics of the practical case study, the framework's interaction with it, and technological contributions of the novel design. The results are further validated by conducting interviews with industry professionals in Chapter \ref{chapter:interviews}. The thesis is concluded in Chapter \ref{chapter:conclusion}.

50
docs/thesis/chapters/2_background.tex
View file

@ -6,27 +6,27 @@ In the following, the context of the problem is presented from three perspective
\section{Accessible AI} \label{section:accessible-ai} \section{Accessible AI} \label{section:accessible-ai}
Most companies prefer not to develop new models but instead reuse prior ones \cite{bosch2021engineering} and they are able to do so increasingly easier. In recent years, there has been a proliferation of highly accessible AI libraries. For example, let us consider the domain of natural language processing (NLP). There are various options for finding AI solutions that work out of the box: FLAIR \cite{akbik2019flair} and Huggingface's transformers \cite{wolf2019huggingface} let developers access the state-of-the-art models and methods in only a couple of lines of code (in many cases 2 or 3). With the advent of fine-tuneable models such as BERT \cite{devlin2018bert} and its many improved variations, Huggingface enables developers to leverage vast amounts of knowledge learned by any particular model and fine-tune it for their specific use case. The API for this is also extremely accessible. Most companies prefer not to develop new models but instead reuse prior ones \cite{bosch2021engineering} and they are able to do so increasingly easier. In recent years, there has been a proliferation of highly accessible AI libraries. For example, let us consider the domain of natural language processing (NLP). There are various options for finding AI solutions that work out of the box: FLAIR \cite{akbik2019flair} and Huggingface's transformers \cite{wolf2019huggingface} let developers access the state-of-the-art models and methods in only a couple of lines of code (in many cases 2 or 3). Using transfer-learning, Huggingface enables developers to leverage vast amounts of knowledge learned by pretrained models (such as BERT \cite{devlin2018bert} and its many improved variations) and fine-tune them for their specific use case. The API exposing this is also extremely accessible.
It is not just these two packages, the list of readily available tools for language processing is vast: SpaCy \cite{srinivasa2018natural}, Gensim \cite{vrehuuvrek2011gensim}, and scikit-learn \cite{pedregosa2011scikit} are other great examples. The situation is similar in all subdomains of artificial intelligence: some domain expertise is --- admittedly --- beneficial but not a hard-requirement. This, combined with the exponentially increasing computing power affordably available to consumers and business alike \cite{sun2019summarizing}, results in AI that is accessible by many. It is not just these two packages, the list of readily available tools is vast: SpaCy \cite{srinivasa2018natural}, Gensim \cite{vrehuuvrek2011gensim}, and scikit-learn \cite{pedregosa2011scikit}, XGBoost \cite{Chen_2016} are other great examples. The situation is similar in all subdomains of artificial intelligence: some domain expertise is --- admittedly --- beneficial but not a hard-requirement. This, combined with the exponentially increasing computing power affordably available to consumers and business alike \cite{sun2019summarizing}, results in AI that is accessible by many.
\section{State of the industry} \label{section:industry} \section{State of the industry} \label{section:industry}
In contrast with this trend, the software landscape around packaging, deploying, and maintaining machine learning (ML) --- and in general --- data-heavy applications paints a different picture. Fortunately, the related issues and their ramifications have been already thoroughly investigated. In contrast with this trend, the software landscape around packaging, deploying, and maintaining machine learning (ML) --- and in general --- data-heavy applications paints a different picture. Fortunately, the related issues and their ramifications have been already thoroughly investigated.
When looking at ML code in practice through the lens of technical debt, Sculley et al. \cite{sculley2015hidden} emphasise the repercussions of writing \textit{glue code} between the algorithms and different systems or libraries and define it as an anti-pattern. The consequence of this is the advice against using generic libraries because their rigid API-s may inhibit improvements, cause lock-in, and result in large amounts of glue code. This is a recurring theme in discussions with industry professionals. When looking at ML\footnote{The terms AI and ML are often not differentiated and are used as synonyms in practice. For instance, see this study by the FDA \cite{food2019proposed}. ML is a well-defined subdomain of AI, however, most modern AI applications are also ML applications, hence, conflating the two terms may be slightly imprecise but usually not wrong.} code in practice through the lens of technical debt, Sculley et al. \cite{sculley2015hidden} emphasise the repercussions of writing \textit{glue code} between the algorithms and different systems or libraries and define it as an anti-pattern. The consequence of this is the advice against using generic libraries because their rigid API-s may inhibit improvements, cause lock-in, and result in large amounts of glue code. This is a recurring theme in discussions with industry professionals.
Haakman et al. \cite{haakman2021ai} interviewed 17 people at ING which is a well-known fintech company undergoing a digital transformation to embrace AI. They found that the existing tools for ML do not meet the particularities of the field. For instance, a Feature Engineer working in the Data \& Analytics department explained that regular spreadsheets are preferred over existing solutions like MLFlow for keeping track of experiment results. The reason behind this is simplicity. Additionally, multiple other interviewees described the need to self-develop (or highly-customize) dashboards for monitoring deployed models which results in many non-reusable solutions across the company for the same problem. The authors conclude that there is a research gap between the ever-improving SOTA techniques and the challenges of developing real-world ML systems. In short, additional tool support is needed for facilitating the ML lifecycle. Haakman et al. \cite{haakman2021ai} interviewed 17 people at ING which is a well-known fintech company undergoing a digital transformation to embrace AI. They found that the existing tools for ML do not meet the particularities of the field. For instance, a Feature Engineer working in the Data \& Analytics department explained that regular spreadsheets are preferred over existing solutions like MLFlow for keeping track of experiment results. The reason behind this is simplicity. Additionally, multiple other interviewees described the need to self-develop (or highly-customize) dashboards for monitoring deployed models which results in many non-reusable solutions across the company for the same problem. The authors conclude that there is a research gap between the ever-improving SOTA techniques and the challenges of developing real-world ML systems. In short, additional tool support is needed for facilitating the ML lifecycle.
In a case study at Microsoft, Amershi et al. \cite{amershi2019software} interviewed 14 people and surveyed another 551 AI and ML professionals from the company. One of the main concerns surfaced was relating to automation which is a vital cross-cutting concern, especially for testing. At the same time, a human-in-the-loop is still favoured. The survey data pointed out the difficulty posed by integrating AI, especially in the case of less experienced respondents. This was elaborated on by describing the preferences of software engineers as striving for elegant, abstract, modular, and simple systems; in contrast, data tends to be of large volume, context-specific and heterogeneous. Reconciling these inherent differences requires significant effort, nevertheless, Microsoft manages to overcome this with highly sophisticated internal infrastructure. In a case study at Microsoft, Amershi et al. \cite{amershi2019software} interviewed 14 people and surveyed another 551 AI and ML professionals from the company. One of the main concerns surfaced was relating to automation which is a vital cross-cutting concern, especially for testing. At the same time, a human-in-the-loop is still favoured. The survey data pointed out the difficulty posed by integrating AI, especially in the case of less experienced respondents. This was elaborated on by describing the preferences of software engineers as striving for elegant, abstract, modular, and simple systems; in contrast, data tends to be of large volume, context-specific and heterogeneous. Reconciling these inherent differences requires significant effort, nevertheless, Microsoft manages to overcome this with highly sophisticated internal infrastructure.
Using AI is not unique to large companies, in a study conducted with the collaboration of three startups \cite{de2019understanding}, the aim was to fill in the gap of understanding how professionals develop ML systems in small companies. Overall, the results showed they have similar priorities to that of large companies, including an emphasis on the online monitoring of deployed models. However, less structure is present in the development lifecycle, as one interviewee had explained: some steps are left out from time to time because they are forgotten about. Using AI is not unique to large companies, in a study conducted with the collaboration of three startups \cite{de2019understanding}, the aim was to fill in the gap of understanding how professionals develop ML systems in small companies. Overall, the results showed they have similar priorities to that of large companies, including an emphasis on the online monitoring of deployed models. However, less structure is present in the development lifecycle, as one interviewee had explained: some steps are left out from time to time because they are forgotten about.
%The paper does not give detail about the use or in-house development of ML tools.
Similarly, Thiée \cite{thiee2021systematic} describes the slow but ever-growing rate of ML adoption by small and medium-sized enterprises (SMEs). With the caveat that many more of these companies would wish to adopt data-driven approaches but are facing new challenges stemming from the domain's complexity. Similarly, Thiée \cite{thiee2021systematic} describes the slow but ever-growing rate of ML adoption by small and medium-sized enterprises (SMEs). With the caveat that many more of these companies would wish to adopt data-driven approaches but are facing new challenges stemming from the domain's complexity.
Serban et al. \cite{serban2020adoption,serban2021practices} describe the results of their global surveys aiming to ascertain the SOTA in how teams develop, deploy, and maintain ML systems. In \cite{serban2020adoption}, they compiled a set of 29 actionable best practices. These were analysed and validated with a survey of 313 participants to discover the adoption rate and relative importance of each best practice. For example, they determined the most important best practice to be \textit{logging production prediction traces}, however, the adoption was measured to be below 40\%. In more than three quarters of the cases, newcomers to AI reported that they \textit{partially} or \textit{not at all} follow best practices. This tendency decreases with more years of experience, reaching a minimum of just below 40\%. In a similar fashion, Serban et al. in \cite{serban2021practices}, identify another 14 best practices that concern trustworthy AI mainly through data governance. They strive to complement high-level checklists with actionable best practices. Analysing 42 survey responses reveals a familiar pattern. Most best practices have less than 50\% adoption. Serban et al. \cite{serban2020adoption,serban2021practices} describe the results of their global surveys aiming to ascertain the SOTA in how teams develop, deploy, and maintain ML systems. In \cite{serban2020adoption}, they compiled a set of 29 actionable best practices. These were analysed and validated with a survey of 313 participants to discover the adoption rate and relative importance of each best practice. For example, they determined the most important best practice to be \textit{logging production prediction traces}, however, the adoption was measured to be below 40\%. In more than three quarters of the cases, newcomers to AI reported that they \textit{partially} or \textit{not at all} follow best practices. This tendency decreases with more years of experience, reaching a maximum adoption rate of just above 60\%. In a similar fashion, Serban et al. in \cite{serban2021practices}, identify another 14 best practices that concern trustworthy AI mainly through data governance. They strive to complement high-level checklists with actionable best practices. Analysing 42 survey responses reveals a familiar pattern. Most best practices have less than 50\% adoption.
Finally, Bosch et al. \cite{bosch2021engineering} organise and structure the problem space of AI engineering research based on their 16 primary case-studies. The authors note the increasing and broad adoption of ML in the industry, while also emphasising that \textit{transition from prototype to production-quality deployment} proves to be challenging for many companies. Large amounts of software engineering expertise is required to create additional facilities for the application such as data pipelines, monitoring, and logging. They define \textit{deployment \& compliance} to be one of the four main categories of problems and describe it as highly underestimated and the source of ample struggle. Finally, Bosch et al. \cite{bosch2021engineering} organise and structure the problem space of AI engineering research based on their 16 primary case studies. The authors note the increasing and broad adoption of ML in the industry, while also emphasising that \textit{transition from prototype to production-quality deployment} proves to be challenging for many companies. Large amounts of software engineering expertise is required to create additional facilities for the application such as data pipelines, monitoring, and logging. They define \textit{deployment \& compliance} to be one of the four main categories of problems and describe it as highly underestimated and the source of ample struggle.
\section{Existing solutions} \label{section:existing} \section{Existing solutions} \label{section:existing}
@ -38,9 +38,11 @@ IBM's AutoAI \cite{wang2020autoai} promises to provide automation for the entire
SageMaker offers the most comprehensive suite of tools and service; most importantly it has a set of features called \textit{AWS SageMaker MLOps}. This provides easy and/or default implementations for industry best practices described by Serban et al. \cite{serban2020adoption,serban2021practices}. Among others, it promotes the use of CI/CD, model monitoring, tracing, model versioning, storing both data and models on shared infrastructure, numerous collaboration tools, etc. Nonetheless, SageMaker does not enjoy universal adoption as indicated by the survey data. The cause of this may be the lack of self-hosting option and its relatively high prices: many companies prefer on-premise hosting for privacy and financial reasons \cite{bosch2021engineering}. Additionally, vendor lock-in, and possibly --- in the case where it is not already used for the project --- the initial effort required for setting up AWS integration could be possible deterrents. SageMaker offers the most comprehensive suite of tools and service; most importantly it has a set of features called \textit{AWS SageMaker MLOps}. This provides easy and/or default implementations for industry best practices described by Serban et al. \cite{serban2020adoption,serban2021practices}. Among others, it promotes the use of CI/CD, model monitoring, tracing, model versioning, storing both data and models on shared infrastructure, numerous collaboration tools, etc. Nonetheless, SageMaker does not enjoy universal adoption as indicated by the survey data. The cause of this may be the lack of self-hosting option and its relatively high prices: many companies prefer on-premise hosting for privacy and financial reasons \cite{bosch2021engineering}. Additionally, vendor lock-in, and possibly --- in the case where it is not already used for the project --- the initial effort required for setting up AWS integration could be possible deterrents.
When it comes to open-source libraries, we can find the MLOps libraries of both TensorFlow and PyTorch: TensorFlow Extended (TFX) \cite{baylor2017tfx} and TorchX\footnote{\href{https://pytorch.org/torchx/latest/}{pytorch.org/torchx/latest}}. TFX comes with a more mature set of features with the caveat that initial time-investment is needed for their setup. The features of TorchX only concern the distributed deployment to a wide range of providers, including Kubernetes, AWS Batch, or Ray. There is no augmentation for the SE4ML best practices. Given the tight coupling between these libraries and their corresponding ML frameworks, they cannot generalise to models\footnote{The Open Neural Network Exchange (\href{https://onnx.ai/}{onnx.ai}) format could be an option for overcoming these incompatibilities, however, a more universal support is needed for seamless integration.} or algorithms of other frameworks and technologies. When it comes to open-source libraries, we can find the MLOps libraries of both TensorFlow and PyTorch: TensorFlow Extended (TFX) \cite{baylor2017tfx} and TorchX\footnote{\href{https://pytorch.org/torchx/latest/}{pytorch.org/torchx/latest}}. TFX comes with a more mature set of features with the caveat that initial time-investment is needed for their setup. The features of TorchX only concern the distributed deployment to a wide range of providers, including Kubernetes (K8s), AWS Batch, or Ray \cite{moritz2018ray}. There is no augmentation for the SE4ML best practices. Given the tight coupling between these libraries and their corresponding ML frameworks, they cannot generalise to models\footnote{The Open Neural Network Exchange (\href{https://onnx.ai/}{onnx.ai}) format could be an option for overcoming these incompatibilities, however, a more universal support is needed for seamless integration.} or algorithms of other frameworks and technologies.
Open-source platforms also exist such as MLflow and Seldon Core. They both rely on Kubernetes (k8s) to provide their features. MLflow puts more emphasis on the training phase (in deployment, it lacks a feedback loop which is essential to reach many of the best-practices), while Seldon Core focuses on the deployment stage. The latter comes integrated with a powerful explanation engine, Alibi Explain \cite{klaise2021alibi}. It also boasts the most comprehensive suite of features including outlier detection, online model selection (with multi-armed bandit theory), and distributed tracing. In short, it seems to be the ideal candidate for the title of \textit{framework for robust end-to-end AI deployments}. Its only downside is the amount of complexity propagated to its clients: it is built on top of Kubernetes, and relies on Helm, Ambasador/Istio, Prometheus, and Jaeger for its features. Hence, the first step in using it setting up a k8s cluster with all the required components, then when it comes to model deployment, a Kubernetes configuration file has to be created to make use of Seldon's Custom Resource Definition. These are smaller obstacles if the project is already built on top of k8s; however, even then, software engineers with strong cloud and DevOps background are actively required for using Seldon Core. Open-source platforms also exist such as MLflow and Seldon Core. They both rely on Kubernetes to provide their features. MLflow puts more emphasis on the training phase (in deployment, it lacks a feedback loop which is essential for reaching many of the best-practices), while Seldon Core focuses on the deployment stage. The latter comes integrated with a powerful explanation engine, Alibi Explain \cite{klaise2021alibi}. It also boasts the most comprehensive suite of features including outlier detection, online model selection (with multi-armed bandit theory), and distributed tracing. In short, it seems to be the ideal candidate for the title of \textit{framework for robust end-to-end AI deployments}. Its only downside is the amount of complexity propagated to its clients: it is built on top of Kubernetes, and relies on Helm, Ambasador/Istio, Prometheus, and Jaeger for its features. Hence, the first step in using it is setting up a K8s cluster with all the required components, then when it comes to model deployment, a Kubernetes configuration file has to be created to make use of Seldon's Custom Resource Definition. These are smaller obstacles if the project is already built on top of K8s; however, even then, software engineers with strong cloud and DevOps background are actively required for using Seldon Core.
Additionally, increasing attention is given to ML deployments in embedded systems both from a theoretical \cite{john2020ai} and practical \cite{prado2020bonseyes} point of view. Prado et al. \cite{prado2020bonseyes} survey the available deployment frameworks and end-to-end solutions including those for embedded devices. They note their inefficiencies that come from the lack of features and too much rigidity. They introduce their framework for embedded AI deployments which can be used out-of-the box but also lets the users easily replace and extend its pipeline with steps to fit their changing needs and advancements of the field. While Meenu et al. \cite{john2020ai} present and compare different architectural choices for large-scale deployments in edge-computing. They also note that: \textit{"...there is a need to consider and adapt well established SE practices which have been ignored or had a very narrow focus in ML literature"}.
\begin{table} \begin{table}
\centering \centering
@ -52,29 +54,31 @@ Open-source platforms also exist such as MLflow and Seldon Core. They both rely
\begin{tabular}{|l|c|c|c|c|c|c|c|} \begin{tabular}{|l|c|c|c|c|c|c|c|}
\hline \hline
& AutoAI & Azure ML & SageMaker & TFX & TorchX & MLflow & Seldon Core \\ \hline & AutoAI & Azure ML & SageMaker & TFX & TorchX & MLflow & Seldon Core \\ \hline
Open-source & & & & \checkmark & \checkmark & \checkmark & \checkmark \\ \hline Open-source\textsuperscript{1}& & & & \checkmark & \checkmark & \checkmark & \checkmark \\ \hline
Free & & & & \checkmark & \checkmark & \checkmark & \checkmark \\ \hline Self-hosted\textsuperscript{1}& & & & \checkmark & \checkmark & \checkmark & \checkmark \\ \hline
Vendor-agnostic & & & & \checkmark & \checkmark & \checkmark & \checkmark \\ \hline Vendor-agnostic\textsuperscript{2}& & & & \checkmark & \checkmark & \checkmark & \checkmark \\ \hline
AI-agnostic & & \checkmark & \checkmark & & & \checkmark & \checkmark \\ \hline AI-agnostic\textsuperscript{2}& & \checkmark & \checkmark & & & \checkmark & \checkmark \\ \hline
E2E feedback & & \checkmark & \checkmark & & & & \checkmark \\ \hline E2E feedback\textsuperscript{3}& & \checkmark & \checkmark & & & & \checkmark \\ \hline
Distributed monitoring & & \checkmark & \checkmark & \checkmark & \checkmark & \checkmark\textsuperscript{*} & \checkmark \\ \hline Distributed monitoring\textsuperscript{3}& & \checkmark & \checkmark & \checkmark & \checkmark & \checkmark\textsuperscript{*} & \checkmark \\ \hline
Online model selection & \checkmark & \checkmark & \checkmark & & & & \checkmark \\ \hline Online model selection\textsuperscript{3}& \checkmark\textsuperscript{*} & \checkmark & \checkmark & & & & \checkmark \\ \hline
Versioning & \checkmark & \checkmark & \checkmark & \checkmark & \checkmark & \checkmark & \checkmark \\ \hline Versioning\textsuperscript{3}& \checkmark & \checkmark & \checkmark & \checkmark & \checkmark & \checkmark & \checkmark \\ \hline
Quick setup & \checkmark & \checkmark & & & & & \\ \hline Quick setup\textsuperscript{4}& \checkmark & \checkmark & & & & & \\ \hline
No dependencies (k8s, cloud) & & & & & \checkmark & & \\ \hline No DevOps dependencies\textsuperscript{4}& & & & & \checkmark & & \\ \hline
\end{tabular}} \end{tabular}}
\begin{tablenotes} \begin{tablenotes}
\item[1] For privacy and accountability reasons. \cite{bosch2021engineering}
\item[2] Minimising required glue code. \cite{sculley2015hidden}
\item[3] Implementing best-practices. \cite{serban2020adoption,serban2021practices}
\item[4] Easy integration into existing processes. \cite{haakman2021ai,thiee2021systematic}
\item[*] Only partial support. \item[*] Only partial support.
\end{tablenotes} \end{tablenotes}
\end{threeparttable} \end{threeparttable}
\end{table} \end{table}
Table \ref{table:platform-comparison} shows a high-level overview about the general properties, and some of the features relating to the \textit{Deployment} stage of the CRISP-DM model \cite{wirth2000crisp}. It makes it apparent that there is a coexistence of persisting problems and their promised solutions. In summary, the problems expressed in Section \ref{section:industry} can be understood when looking at the available solutions. Table \ref{table:platform-comparison} shows a high-level comparison of frameworks along the dimensions in which practitioners reportedly face difficulties in the \textit{Deployment} stage of the CRISP-DM model \cite{wirth2000crisp}.
Additionally, increasing attention is given to ML deployments in embedded systems both from a theoretical \cite{john2020ai} and practical \cite{prado2020bonseyes} point of view. Prado et al. \cite{prado2020bonseyes} survey the available deployment frameworks and end-to-end solutions including those for embedded devices. They note their inefficiencies that come from the lack of features and too much rigidity. They introduce their framework for embedded AI deployments which can be used out-of-the box but also lets the users easily replace and extend its pipeline with steps to fit their changing needs and advancements of the field. While Meenu et al. \cite{john2020ai} present and compare different architectural choices for large-scale deployments in edge-computing. They also note that: \textit{"...there is a need to consider and adapt well established SE practices which have been ignored or had a very narrow focus in ML literature"}.
\section{Summary} \section{Summary}
The surveys and case-studies have shown the industry's continuous struggle to evolve their prototypes into robust and responsible production-ready deployments. Simultaneously, platforms aiming to help overcome this challenge already exist but lack widespread adoption. The frequently recurring explanations for not adopting pre-existing solutions surfaced in Section \ref{section:industry} revolve around their complexity and rigidity. These complaints are validated when looking at the available frameworks in Section \ref{section:existing}. While using AI has become more accessible than ever, deploying remains challenging owing to the lack of any \textit{easy-to-use framework for robust end-to-end AI deployments}. The surveys and case studies have shown the industry's continuous struggle to evolve their prototypes into robust and responsible production-ready deployments. Simultaneously, platforms aiming to help overcome this challenge already exist but lack widespread adoption. The frequently recurring explanations for not adopting existing solutions surfaced in Section \ref{section:industry} revolve around their complexity and rigidity. These complaints are validated when looking at the available frameworks in Section \ref{section:existing}. While using AI has become more accessible than ever, deploying remains challenging owing to the lack of any \textit{easy-to-use framework for robust end-to-end AI deployments}.
The coexistence of multiple major obstacles along with their promised solutions and the lack of their wide-spread adoption leads us to believe that current frameworks are inadequate for many contexts. There is an unmet need for accessible AI deployment methods. The revolution brought by FLAIR, HuggingFace, and similar libraries for the domain of ML remains unmatched in the domain of AI engineering. The coexistence of multiple major obstacles along with their promised solutions and the lack of their wide-spread adoption leads us to believe that current frameworks are inadequate for many contexts. There is an unmet need for accessible AI deployment methods. The revolution brought by FLAIR, HuggingFace, and similar libraries for the domain of ML remains unmatched in the domain of AI Engineering.

26
docs/thesis/chapters/3_methods.tex
View file

@ -4,24 +4,24 @@ The chosen methodology for this study is Design Science which emphasises the nee
As for the empirical cycle, the pragmatist approach is taken since the value of this research lies in its utility. Moreover, pragmatism adopts an engineering approach to research \cite{shull2007guide} which is inline with the philosophy of design science. Additionally, as no research method is without flaws, it is imperative to try to compensate their weaknesses by applying multiple methods. Hence, the study also relies on interviews with professionals for validating the design decisions of \textit{GreatAI}. As for the empirical cycle, the pragmatist approach is taken since the value of this research lies in its utility. Moreover, pragmatism adopts an engineering approach to research \cite{shull2007guide} which is inline with the philosophy of design science. Additionally, as no research method is without flaws, it is imperative to try to compensate their weaknesses by applying multiple methods. Hence, the study also relies on interviews with professionals for validating the design decisions of \textit{GreatAI}.
\section{Problem context}
The problem context is the difficulty in responsibly transitioning (while following best practices) from prototype industrial AI applications to production-ready deployments. With the possible treatment being libraries with high-level API-s and a set of default settings. It is important to note that \textit{GreatAI} is merely a proof-of-concept, and its aim is to serve as the proxy for the design decisions behind it. Through this, the design can be indirectly evaluated. Hopefully, a by-product will be a library that can be successfully applied to this problem context.
The practical cases used for the evaluation are further elaborated in Chapter \ref{chapter:case}. In short, they focus on individual components of a growing commercial platform with the aim of finding tech-transfer opportunities in academic publications. The main input of the system as a whole are individual PDF-files while the output is a list of metrics describing various aspects of the paper, such as interesting sentences, scientific domains, and the scientific contribution. The output also includes a predicted score used for ranking. This ranking is subsequently processed by the business developers of Technology Transfer Offices (TTO-s) of multiple Dutch and German universities who later give feedback on the results.
Overall, this problem context carries the properties of typical industry use-cases: it utilises a wide-range of text mining methods, contains complex interactions between the services, benefits from the integration of end-to-end feedback, and has to provide the clients with a platform that they can rely on in their organisation's core processes. Since the final ranking affects real people, explainability and robustness are also central questions.
\section{Design \& empirical cycles} \section{Design \& empirical cycles}
The aim of the project can be summarised using the terminology of design science in the following way: The problem context is the difficulty in responsibly transitioning (while following best practices) from prototype industrial AI applications to production-ready deployments. With the possible treatment being libraries with high-level API-s and a set of default settings. It is important to note that \textit{GreatAI} is merely a proof-of-concept, and its aim is to serve as the proxy for the design decisions behind it. Through this, the design can be indirectly evaluated. Hopefully, a by-product will be a library that can be effectively applied to this problem context.
The practical cases used for the evaluation are further elaborated in Chapter \ref{chapter:case}. In short, they focus on individual components of a growing commercial platform\footnote{\href{https://dashboard.scoutinscience.com/}{dashboard.scoutinscience.com}} with the aim of finding tech-transfer opportunities in academic publications. The main input of the system as a whole are PDF-files while the output is a list of metrics describing various aspects of each paper, such as interesting sentences, scientific domains, and the scientific contribution. The output also includes a predicted score used for ranking. This ranking is subsequently processed by the business developers of Technology Transfer Offices (TTO-s) of multiple Dutch and German universities who later give feedback on the results.
Overall, this problem context carries the properties of typical industry use-cases: it utilises a wide-range of natural language processing methods, contains complex interactions between the services, benefits from the integration of end-to-end feedback, and has to provide the clients with a platform that they can rely on in their organisation's core processes. Since the final ranking affects real people, explainability and robustness are also central questions.
The aim of \textit{GreatAI} can be summarised using the terminology of design science in the following way:
\textit{Facilitate the easy adoption of AI deployment best practices \textit{Facilitate the easy adoption of AI deployment best practices
by finding a less complex framework design by finding a less complex framework design
which is easier to adopt which is easier to adopt
to decrease the negative externality of misused AI.} 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 followed by refactoring larger AI-based applications using the finished framework. The treatment is finding a simpler design which still leads to high-quality deployments as defined in Section \ref{section:requirements}. \textbf{RQ2} and \textbf{RQ3} captures this process; for investigating the feedback acquired from iteratively working --- which is the definition of action research --- on the case will be 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.
To answer how well the design of \textit{GreatAI} can generalise (\textbf{RQ4}), interviews will be 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. \section{Generalisability}
\textit{GreatAI} might have the potential to bridge the gap between data science and software engineering. Stemming from the bidirectional nature of bridges, we can look at the framework from two perspectives: for professionals closer to the field of data science, it provides an automatic scaffolding of software facilities that are required for deploying, monitoring, and iterating on their models. For software engineers, it highlights the necessary steps required for robust and improvable deployments, while at the same time saves them from the grunt work of implementing these constructs. While most importantly, it serves as a proxy for the design decisions through which they can be tested and evaluated in their practical context. 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.
todo

26
docs/thesis/chapters/4_design.tex
View file

@ -1,6 +1,6 @@
\chapter{Designing the framework} \label{chapter:design} \chapter{Designing the framework} \label{chapter:design}
Providing the users with a high-level of abstraction is not unheard of in the domain of practical AI platforms. Many software-as-a-service products offer features for hiding the details of machine learning applications. However --- as we saw in Section \ref{section:existing} --- these tend to abstract away the details of both data science and AI-engineering, overall hindering the development process. The design proposed here aims to simplify only the deployment related concepts. Providing users with a high-level of abstraction is not unheard of in the domain of practical AI platforms. Many software-as-a-service products offer features for hiding the details of machine learning applications. However --- as we saw in Section \ref{section:existing} --- these tend to abstract away the details of both data science and AI-engineering, overall hindering the development process. The design proposed here aims to simplify only the deployment related concepts.
\section{Scope} \label{section:scope} \section{Scope} \label{section:scope}
@ -15,7 +15,27 @@ There have been attempts that at least partially address this issue, however, as
\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} 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}
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.
\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 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 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{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.
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.
\section{Design principles} \section{Design principles}
@ -45,6 +65,8 @@ This way, the library attempts to notify its user about the existence of these d
\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.
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 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.
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 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.

4
docs/thesis/chapters/5_case/2-stage.tex
View file

@ -12,6 +12,8 @@ Compared with Section \ref{section:simple-case}, this time around, the toolset o
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. 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. 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}. 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}.
@ -20,7 +22,7 @@ A formulaic expression is a phrase with zero or more slots that expresses a cert
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. 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 shortcoming, 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. 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 TODO

29
docs/thesis/chapters/5_case/features.tex
View file

@ -1,31 +1,24 @@
\section{Bridging \textbf{the gap} with GreatAI} \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 service, lastly we discuss the utility of helper functions. 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.
First, 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. 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} \subsection{Data}
There are two kinds of data storage need 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 train 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}{recreate the repository}. 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 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. 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 as certain version which is very much desired in the case of models. 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 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, automatically purging the cache, automatically deleting old remote version if requested are all present and come with recommended --- but easy to see and change --- configuration. 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{Utilities} \subsection{Deployment approach}
utilities: clean, language, parallel map \textit{Enable Parallel Training Experiments}
traces
\textit{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 % 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
@ -38,3 +31,13 @@ to do
% Argumetn/parameter names were confusing % Argumetn/parameter names were confusing
% offlinemode -> cacheonly mode % 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.

8
docs/thesis/chapters/5_case/introduction.tex
View file

@ -1,11 +1,11 @@
\chapter{The ScoutinScience platform} \label{chapter:case} \chapter{The ScoutinScience platform} \label{chapter:case}
The core product of ScoutinScience B.V. is its platform. The clients are technology-transfer offices of Dutch and German universities, government organisations (e.g.: Wetsus), and corporates (e.g.: Heraeus Group, Ruma Rubber B.V.) who wish to extend the scope of their R\&D activities. ScoutinScience connects to multiple data sources of academic publications and integrates them into a single database. Each new publication is evaluated with a suite of AI components that ultimately determine its technology transfer potential. Other features are also extracted that help the users get a quick overview of the authors, topics, and contributions of a given piece of research. The core product of \href{https://scoutinscience.com/}{ScoutinScience B.V.} is its platform. The clients are technology-transfer offices of Dutch and German universities, government organisations (e.g.: Wetsus), and corporates (e.g.: Heraeus Group, Ruma Rubber B.V.) who wish to extend the scope of their R\&D activities. ScoutinScience connects to multiple data sources of academic publications and integrates them into a single database. Each new publication is evaluated with a suite of AI components that ultimately determine its technology transfer potential. Other features are also extracted that help the users get a quick overview of the authors, topics, and contributions of a given piece of research.
Each client organisation gets to see a different filtered view of this database ranked by the predicted probability of technology transfer opportunities being present. The main motivation is to make these business developers' and other professionals work more efficient by showing them which papers have the largest likelihood of being considered interesting by them. Each client organisation gets to see a different filtered view of this database ranked by the predicted probability of technology transfer opportunities being present. The main motivation is to make these business developers' and other professionals work more efficient by showing them which papers have the largest likelihood of being considered interesting by them.
To achieve this, we have a service-based architecture \cite{kleppmann2017designing} on the backend, apart from the data integration, communication, and business logic, it is made up of services wrapping simpler (phrase-matching, Naive Bayes) and more sophisticated (conditional random fields, transformer) models. As we will soon see, these can also depend on each other, for instance, based on the predicted scientific domain, a different model may be applied for scoring the paper's certain aspects. To achieve this, we have a service-based architecture \cite{kleppmann2017designing} on the backend, apart from the data integration, communication, and business logic, it is made up of services wrapping simpler (phrase-matching, Naïve Bayes) and more sophisticated (conditional random fields, transformer) models. As we will soon see, these can also depend on each other, for instance, based on the predicted scientific domain, a different model can be chosen for scoring certain aspects of papers.
I was the first software engineer on the team which has grown considerably in the past two years. While architecting, designing, and integrating more and better models into our software solution, we noticed the same difficulties as described in Chapter \ref{chapter:background}. The gap between prototypes and production-ready services is larger than it seems. It is also larger than it should be. This motivated me to investigate the state-of-the-art and had found that it is insufficient in many cases. Since the ScoutinScience platform is a quite typical example of applying AI in the industry, it will serve as the real-life case, problem context, and testbed for attempting to design a solution which can advance the state-of-the-art. I was among the first engineers on the team which has grown considerably in the past two years. While architecting, designing, and integrating more and better models into our software solution, I experienced the same difficulties as described in Chapter \ref{chapter:background}. The gap between prototypes and production-ready services is larger than it seems. It is also larger than it should be. This motivated me to investigate the state-of-the-art and had found that it is insufficient in many cases. Since the ScoutinScience platform is a quite typical example of applying AI in the industry, it will serve as the real-life case, problem context, and testbed for attempting to design a solution which can advance the state-of-the-art.
In this chapter, the process of designing GreatAI is described along with how it fits into real-life use cases. First, a simple experiment is presented which leads to the implementation of a service, then, as the featureset of the library grows and matures, a more complex service is developed. Subsequently, the close to final library version is used to refactor existing ScoutinScinece services in order to further refine the API of GreatAI. Lastly, the final version of the design is presented and qualitatively evaluated to verify how well it satisfies the requirements described in Section \ref{section:requirements}. In this chapter, the process of designing \textit{GreatAI} is described along with how it fits into real-life use cases. First, a simple experiment is presented which leads to the implementation of a service, subsequently, as the feature-set of the library grows and matures, a more complex software service is developed. Lastly, the final version of the design is presented and qualitatively evaluated to verify how well it satisfies the requirements described in Section \ref{section:requirements}.

42
docs/thesis/chapters/5_case/naive-bayes.tex
View file

@ -1,10 +1,12 @@
\section{A simple case} \label{section:simple-case} \section{Domain classification with Naïve Bayes} \label{section:simple-case}
Using different models for slight variations of the same problem is quite commonplace in the industry. For instance, UberEats has a vast, hierarchical set of models for every country, region, and city for calculating the estimated time of delivery \cite{li2017scaling}. We have also found, that in order to best process an academic publication, knowing its domain is essential. The reason for this can be (among others) the wildly different vocabularies of different domains. For example, the term \textit{framework} in computer science almost always refers to a software artifact (usually implying high tech-transfer potential), while in every other domain, \textit{framework} is used to describe theoretical models that are less central to practical applications. Of course, it is not merely the meaning of the terms but more importantly, their distribution that varies significantly. Therefore, the topic of this section is to design and develop a domain prediction model for academic papers. Using different models for slight variations of the same problem is quite commonplace in the industry. For instance, UberEats has a vast, hierarchical set of models for every country, region, and city for calculating the estimated time of delivery \cite{li2017scaling}. We have also found, that in order to best process an academic publication, knowing its domain is essential. The reason for this can be (among others) the wildly different vocabularies of different domains. For example, the term \textit{framework} in computer science almost always refers to a software artifact (usually implying high tech-transfer potential), while in most other domains, \textit{framework} is used to describe theoretical models that are less central to practical applications. Of course, it is not merely the meaning of the terms but more importantly: their distribution that varies significantly. Therefore, the topic of this section is to design and develop a domain prediction model for academic papers.
\subsection{Background} \subsection{Background}
Fortunately, this is one of the oldest subjects of text classification. In fact, Maron introduced the Naive Bayes classifier in 1961 for exactly this purpose: classifying documents' subjects. To look at a more recent approach, SciBERT \cite{beltagy2019scibert} --- a BERT \cite{devlin2018bert} model pretrained on academic publications --- was also used for a similar task in which the domains of sentences have to be decided\footnote{\href{https://paperswithcode.com/sota/sentence-classification-on-paper-field}{paperswithcode.com/sota/sentence-classification-on-paper-field}}. It achieved an F1-score of $0.6571$ after being pretrained on the Semantic Scholar Corpus (SSC) \cite{Lo2020S2ORCTS} and finetuned on the train split of the Microsoft Academic Graph (MAG) dataset \cite{wang2019review}\footnote{SciBERT was applied to a preprocessed version of this dataset available at \href{https://github.com/allenai/scibert/tree/master/data/text_classification/mag}{github.com/allenai/scibert/tree/master/data/text\_classification/mag}}. Fortunately, this is one of the oldest text classification tasks. In fact, Maron introduced the Naïve Bayes classifier in 1961 \cite{maron1961automatic} for exactly this purpose: classifying documents' subjects. However, it is still an active problem when it comes to academic texts as indicated by Elsevier funded research carried out by Rivest et al. \cite{rivest2021level}. They created a 176-class classification problem for comparing bibliometric and deep-learning approaches but this comparison is made difficult because 44\% of the labels are \textit{assigned suboptimally} in the ground-truth dataset.
Prior work evaluated SciBERT \cite{beltagy2019scibert} --- a BERT \cite{devlin2018bert} model pretrained on academic publications --- on a simpler version of the task in which the domains of sentences\footnote{Sentences are more appropriate units for processing due to SciBERT's maximum token length of 512 (which comes from its attention mechanism's quadratic complexity \cite{vaswani2017attention}).} have to be decided\footnote{\href{https://paperswithcode.com/sota/sentence-classification-on-paper-field}{paperswithcode.com/sota/sentence-classification-on-paper-field}}. It achieved an F1-score of $0.6571$ after being pretrained on the Semantic Scholar Corpus (SSC) \cite{Lo2020S2ORCTS} and finetuned on the train split of the Microsoft Academic Graph (MAG) dataset \cite{wang2019review}\footnote{SciBERT was applied to a preprocessed version of this dataset available at \href{https://github.com/allenai/scibert/tree/master/data/text_classification/mag}{github.com/allenai/scibert/tree/master/data/text\_classification/mag}}. To the best of my knowledge, no other published work exists on this sentence-classification task. This may be explained by the lack of practical relevance and contrived nature (uniform label distribution) of the task as we will see in the next subsection.
\begin{displayquote} \begin{displayquote}
\textbf{Design note} After getting familiar with the context, it is time to focus on experimenting and developing our domain prediction service. At the same time, the difficulties encountered should be noted and integrated into GreatAI's design. \textbf{Design note} After getting familiar with the context, it is time to focus on experimenting and developing our domain prediction service. At the same time, the difficulties encountered should be noted and integrated into GreatAI's design.
@ -18,25 +20,25 @@ SciBERT's version of the MAG dataset has 84 thousand and 22.3 thousand sentences
\begin{figure} \begin{figure}
\centering \centering
\includegraphics[width=\linewidth]{figures/mag-distribution.png} \includegraphics[width=0.5\linewidth]{figures/mag-distribution.png}
\caption{Class distribution of the MAG \cite{wang2019review} dataset's 84000 sentences in its \textit{train} split.} \caption{Class distribution of the MAG \cite{wang2019review} dataset's 84000 sentences in its \textit{train} split.}
\label{fig:mag-distribtion} \label{fig:mag-distribtion}
\end{figure} \end{figure}
SSC is much larger: it contains over 80 million abstracts. Having more data certainly helps in sampling the term distribution more accurately, the law of diminishing returns apply, especially when using simple models. Therefore, the data will be randomly downsampled to leave us with a more manageable couple of hundred megabytes of abstracts. We can see the distribution of class labels in Figure \ref{fig:ss-distribution}. The dataset is considerably less balanced: \textit{medicine} is by far the most popular field. SSC is much larger: it contains over 80 million abstracts. Having more data certainly helps in sampling the term distribution more accurately, nonetheless, the law of diminishing returns apply, especially when using simple models. Therefore, the data will be randomly downsampled to leave us with a more manageable couple of hundreds of megabytes of abstracts. We can see the distribution of class labels in Figure \ref{fig:ss-distribution}. The dataset is considerably less balanced: \textit{medicine} is by far the most voluminous field.
\begin{figure} \begin{figure}
\centering \centering
\includegraphics[width=\linewidth]{figures/ss-distribution.png} \includegraphics[width=0.8\linewidth]{figures/ss-distribution.png}
\caption{Label distribution of the Semantic Scholar dataset \cite{Lo2020S2ORCTS}. The \textit{variable} refers to the position of the domain in the list of domains assigned to a paper.} \caption{Label distribution of the Semantic Scholar dataset \cite{Lo2020S2ORCTS}. Each publication may be assigned at most 3 domains.}
\label{fig:ss-distribution} \label{fig:ss-distribution}
\end{figure} \end{figure}
\begin{displayquote} \begin{displayquote}
\textbf{Where should we store this data?} "On my machine" seems like an easy answer. However, if we have a team working with the data or it has intrinsic value, it must be stored in an easy-to-access, potentially redundant way. Serban et al. \cite{serban2020adoption} expressed this need in the following best practice: \textit{Make Data Sets Available on Shared Infrastructure (private or public)}. Meanwhile, wherever data is stored, it should also be versioned to satisfy the next best practice: \textit{Use Versioning for Data, Model, Configurations and Training Scripts}. \textbf{Where should we store this data?} ``On my machine'' seems like an easy answer. However, if we have a team working with the data or it has intrinsic value, it must be stored in an easy-to-access, potentially redundant way. Serban et al. \cite{serban2020adoption} expressed this need in the following best practice: \textit{Make Data Sets Available on Shared Infrastructure (private or public)}. Meanwhile, wherever data is stored, it should also be versioned to satisfy the next best practice: \textit{Use Versioning for Data, Model, Configurations and Training Scripts}.
\end{displayquote} \end{displayquote}
MAG needs no further preprocessing if we aim to match SciBERT's setup \cite{beltagy2019scibert}. But since SSC contains a heap of metadata, the relevant parts have to be extracted and preprocessed. In this case, these are the the concatenation of the abstract's text, paper's title and the journal's name along with the paper's domains (there can be multiple domains for a single paper, it is a mulitlabel classification task). Lastly, the non-English entries are discarded because we only expect to process papers in English. MAG needs no further preprocessing if we aim to match SciBERT's setup \cite{beltagy2019scibert}. But since SSC contains a heap of metadata, the relevant parts have to be extracted and preprocessed. In this case, these are the concatenation of the abstract's text, paper's title and the journal's name along with the paper's domains (there can be multiple domains for a single paper, it is a multi-label classification task). Lastly, the non-English entries are discarded because we only expect to process papers in English.
\begin{displayquote} \begin{displayquote}
\textbf{How should we preprocess the data?} These simple processing steps (filter, map, project) are almost always present in the data science life-cycle. For example, cleaning the input text from various HTML, OCR, PDF, or \LaTeX \hskip 0.12cm extraction artifacts is almost always necessary for text analysis. This is captured in the AI best-practices collection under the following category: \textit{Write Reusable Scripts for Data Cleaning and Merging}. Also, the best practice of \textit{Test all Feature Extraction Code} is somewhat applicable: the applied processing steps must not introduce unwanted artifacts. \textbf{How should we preprocess the data?} These simple processing steps (filter, map, project) are almost always present in the data science life-cycle. For example, cleaning the input text from various HTML, OCR, PDF, or \LaTeX \hskip 0.12cm extraction artifacts is almost always necessary for text analysis. This is captured in the AI best-practices collection under the following category: \textit{Write Reusable Scripts for Data Cleaning and Merging}. Also, the best practice of \textit{Test all Feature Extraction Code} is somewhat applicable: the applied processing steps must not introduce unwanted artifacts.
@ -44,9 +46,11 @@ MAG needs no further preprocessing if we aim to match SciBERT's setup \cite{belt
\subsection{Methods} \subsection{Methods}
Since the aim is to classify papers to allow the ScoutinScience platform to select models which have been trained on a matching vocabulary (and domain), it seems reasonable that only considering the distribution (frequencies) of individual terms may be sufficient. To test this hypothesis, a unigram language model (Multinomial Naive Bayes) is constructed and its accuracy is compared with SciBERT's. The former definitely aligns with the advice to \textit{Use The Most Efficient Models}. Our aims are twofold: (1) to evaluate a sentence classification model on MAG and compare it with prior art; and (2) to retrain and apply this model for classifying publication metadata (including abstracts). This would allow the ScoutinScience platform to select an appropriate processing pipeline which has been trained on a matching vocabulary (and domain) for each publication.
Using the MNB implementation of scikit-learn \cite{pedregosa2011scikit}, it only took a couple of lines to create, hyperparameter-optimise, and test a text classifier. Including data loading and visualisations, it takes 71 LOC to be more precise. \footnote{The code is available at \href{https://github.com/ScoutinScience/great-ai/blob/main/examples/simple-mag/train.ipynb}{github.com/ScoutinScience/great-ai/blob/main/examples/simple-mag/train.ipynb}} This further proves relatively how simple it is to apply existing algorithms. The code can be considered for satisfying the \textit{Automate Hyper-Parameter Optimisation} best-practice, since it also implements an automated hyperparameter sweep. It seems reasonable that only considering the distribution (frequencies) of individual terms may be sufficient. To test this hypothesis, a unigram language model (Multinomial Naïve Bayes) is constructed and its accuracy is compared with SciBERT's. The former definitely aligns with the advice to \textit{Use The Most Efficient Models}\footnote{\href{https://se-ml.github.io/best_practices/02-efficient-models/}{se-ml.github.io/best\_practices/02-efficient-models}}.
Using the MNB implementation of scikit-learn \cite{pedregosa2011scikit}, it only took a couple of lines to create, hyperparameter-optimise, and test a text classifier. Including data loading and visualisations, it takes 71 lines of code (LOC) to be more precise. \footnote{The code is available at \href{https://great-ai.scoutinscience.com/tutorial/}{great-ai.scoutinscience.com/tutorial}.} This further proves relatively how simple it is to use standard packages. The code can be considered for satisfying the \textit{Automate Hyper-Parameter Optimisation} best-practice, since it also implements an automated hyperparameter sweep.
The sentences are tokenised into words and vectorised with TF-IDF (with logarithmic term frequency) \cite{buckley1985implementation}, the hyperparameters found via 3-fold cross-validation on the \textit{train} split lead to filtering out tokens which occur in fewer than 5 documents or more than 5\% of the documents. The sentences are tokenised into words and vectorised with TF-IDF (with logarithmic term frequency) \cite{buckley1985implementation}, the hyperparameters found via 3-fold cross-validation on the \textit{train} split lead to filtering out tokens which occur in fewer than 5 documents or more than 5\% of the documents.
@ -58,25 +62,25 @@ The sentences are tokenised into words and vectorised with TF-IDF (with logarith
\begin{figure} \begin{figure}
\centering \centering
\includegraphics[width=0.8\linewidth]{figures/confusion-matrix.png} \includegraphics[width=0.8\linewidth]{figures/mag-confusion.png}
\caption{Confusion matrix of a Naive Bayes classifier on the MAG dataset's sentences. The matrix is normalised column-wise. Notice, how most mistakes happen between semantically similar classes, for instance: \textit{politics} -- \textit{sociology} or \textit{business} -- \textit{economics}.} \caption{Confusion matrix of a Naïve Bayes classifier on the MAG dataset's sentences. The matrix is normalised column-wise. Notice, how most mistakes happen between semantically similar classes, for instance: \textit{politics} -- \textit{sociology} or \textit{business} -- \textit{economics}.}
\label{fig:mag-confusion} \label{fig:mag-confusion}
\end{figure} \end{figure}
\begin{figure} \begin{figure}
\centering \centering
\includegraphics[width=\linewidth]{figures/ss-confusion.png} \includegraphics[width=\linewidth]{figures/ss-confusion.png}
\caption{Confusion matrix of a Naive Bayes classifier on the SSC dataset's sentences. The matrix is normalised column-wise. Notice, how most mistakes happen between semantically similar classes, for instance: \textit{philosohpy} -- \textit{sociology} or \textit{history} -- \textit{art}.} \caption{Confusion matrix of a Naïve Bayes classifier on the SSC dataset's sentences. The matrix is normalised column-wise. Notice, how most mistakes happen between semantically similar classes, for instance: \textit{philosohpy} -- \textit{sociology} or \textit{history} -- \textit{art}.}
\label{fig:ss-confusion} \label{fig:ss-confusion}
\end{figure} \end{figure}
When this model is applied to the \textit{test} split of MAG, we get the confusion matrix of Figure \ref{fig:mag-confusion}. This Naive Bayes classifier achieves a whopping $0.6795$ F1-score. This is $3.4\%$ better than SciBERT's on the same dataset. Thus, it seems, MNB clearly outperforms SciBERT for this particular use-case: it is not only more accurate, its model is magnitudes smaller, while it is also considerably faster to train (or finetune in the case of SciBERT) and use. When this model is applied to the \textit{test} split of MAG, we get the confusion matrix of Figure \ref{fig:mag-confusion}. This Naïve Bayes classifier achieves a whopping $0.6795$ F1-score. This is $2.3\%$ more than SciBERT's on the same dataset. Thus, it seems, MNB clearly outperforms SciBERT for this particular use-case: it is not only more accurate, its model is magnitudes smaller, while it is also considerably faster to train (or finetune in the case of SciBERT) and use (its running time is in the order of milliseconds per publication). It also has no upper-limit on the input length. Thus, this experiment validates the choice of picking MNB for the task over SciBERT.
It is, of course, not entirely surprising that the sophisticated transformer architecture of SciBERT is not necessary for a plain task like this. Apart from phrases, the relation between separate words of a sentence do not carry nearly as much discriminative power as the identity of the terms\footnote{On a similar note, the independence assumption of Naive Bayes is often less wrong than it might seem \cite{hand2001idiot}.}, hence there is little reason for using an attention mechanism. The fact that SciBERT even works in any way on this task is already a testament to its general applicability. Nevertheless, this short experiment has proved that we can safely opt for using MNB for production. It is, of course, not entirely surprising that the sophisticated transformer architecture of SciBERT is not necessary for a plain task like this. Apart from phrases, the relation between separate words of a sentence do not carry nearly as much discriminative power as the identity of the terms\footnote{On a similar note, the independence assumption of Naïve Bayes is often less wrong than it might seem \cite{hand2001idiot}.}, hence there is little reason for using an attention mechanism. The fact that SciBERT even works in any way on this task is already a testament to its general applicability. Nevertheless, this short experiment has proved that we can safely opt for using MNB for production.
Since Multinomial Naive Bayes is best at returning a single label and SSC is has multiple labels per datapoint: for evaluation purposes, it is checked whether the returned label is contained in the labels of the ground truth. On this dataset, MNB achieves a significantly lower macro-average F1-score which is 0.49. The weighted-average F1 is 0.61 and the overall accuracy is 62\%. The large difference between the macro and weighted averages come from the unbalanced distribution of the labels, better performance could be achieved by uniformly sampling from each class. Since Multinomial Naïve Bayes is best at returning a single label and SSC has multiple labels per datapoint: for evaluation purposes, it is checked whether the returned label is contained in the labels of the ground truth. On this dataset, MNB achieves lower macro-average F1-score which is 0.59.\footnote{The code for this is available at \href{https://great-ai.scoutinscience.com/examples/simple/deploy}{great-ai.scoutinscience.com/examples/simple/deploy}.} The weighted-average F1 is 0.70 and the overall accuracy is also 70\%. The substantial difference between the macro and weighted averages come from the unbalanced distribution of the labels.
The lower F1-score is not surprising because there are more than twice as many classes in this dataset, Additionally, the mistakes made are defendable when we look at Figure \ref{fig:ss-confusion}: most of them are between close or related classes. The lower F1-score is not surprising because there are more than twice as many classes in this dataset, Additionally, the mistakes made are defensible when we look at Figure \ref{fig:ss-confusion}: most of them are between close or related classes.
\begin{displayquote} \begin{displayquote}
This is the usual point where papers conclude: a proof-of-concept/prototype has been built and its performance demonstrated, measured --- and usually --- explained. Nonetheless, in an industrial setting, our problem is far from being solved: it has yet to be deployed. This is the usual point where papers conclude: a proof-of-concept/prototype has been built and its performance demonstrated, measured --- and usually --- explained. Nonetheless, in an industrial setting, our problem is far from being solved: it has yet to be deployed.
@ -87,7 +91,7 @@ This is the usual point where papers conclude: a proof-of-concept/prototype has
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's easy to determine the most influential weights, thus, words. 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 ways, 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 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}.

2
docs/thesis/chapters/7_conclusion.tex
View file

@ -2,6 +2,8 @@
% even if you already implemented these solutions by hand, you no longer have to -> you have more time -> you can spend that time implementing more advanced best practices % even if you already implemented these solutions by hand, you no longer have to -> you have more time -> you can spend that time implementing more advanced best practices
\textit{GreatAI} might have the potential to bridge the gap between data science and software engineering. Stemming from the bidirectional nature of bridges, we can look at the framework from two perspectives: for professionals closer to the field of data science, it provides an automatic scaffolding of software facilities that are required for deploying, monitoring, and iterating on their models. For software engineers, it highlights the necessary steps required for robust and improvable deployments, while at the same time saves them from the menial work of implementing these constructs. While most importantly, it serves as a proxy for the design decisions through which they can be tested and evaluated in their practical context.
\section{Future work} \section{Future work}
\section{Concluding remarks} \section{Concluding remarks}

BIN
docs/thesis/figures/confusion-matrix.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 57 KiB

0
docs/thesis/figures/UL_PMS-kleur.eps → docs/thesis/figures/leiden-logo.eps
View file

BIN
docs/thesis/figures/mag-confusion.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 1.5 MiB

BIN
docs/thesis/figures/mag-distribution.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 29 KiB

After

Width:  |  Height:  |  Size: 208 KiB

Before After
Before After

BIN
docs/thesis/figures/ss-confusion.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 160 KiB

After

Width:  |  Height:  |  Size: 2.7 MiB

Before After
Before After

BIN
docs/thesis/figures/ss-distribution.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 64 KiB

After

Width:  |  Height:  |  Size: 792 KiB

Before After
Before After

2
docs/thesis/frontpage/frontpage.tex
View file

@ -25,7 +25,7 @@
\begin{tabular}[t]{p{3.5cm}@{\hspace{4mm}\vrule width 1.5pt\hspace{4mm}}l} \begin{tabular}[t]{p{3.5cm}@{\hspace{4mm}\vrule width 1.5pt\hspace{4mm}}l}
%Logo Leiden University %Logo Leiden University
\makebox(20,0)[t]{\includegraphics{../figures/UL_PMS-kleur.eps}} \makebox(20,0)[t]{\includegraphics{../figures/leiden-logo.eps}}
& &
\begin{minipage}[t]{12.25cm} \begin{minipage}[t]{12.25cm}
\begin{Huge} \begin{Huge}

7
docs/thesis/llncs.cls
View file

@ -196,6 +196,7 @@
\fi} \fi}
\newcommand\chapter{\clearpage \newcommand\chapter{\clearpage
\setcounter{section}{0}
\global\@topnum\z@ \global\@topnum\z@
\@afterindentfalse \@afterindentfalse
\secdef\@chapter\@schapter} \secdef\@chapter\@schapter}
@ -1086,8 +1087,8 @@ to0pt{\kern0.55\wd0\vrule height0.45\ht0\hss}\box0}}}}
\item[\hskip\labelsep{##3##1}]{##3##2\@thmcounterend\ }} \item[\hskip\labelsep{##3##1}]{##3##2\@thmcounterend\ }}
} }
\renewenvironment{abstract}{% \renewenvironment{abstract}{
\list{}{\advance\topsep by0.35cm\relax\small \list{}{\advance\topsep by 0.35cm\relax\small
\leftmargin=1cm \leftmargin=1cm
\labelwidth=\z@ \labelwidth=\z@
\listparindent=\z@ \listparindent=\z@
@ -1096,7 +1097,7 @@ to0pt{\kern0.55\wd0\vrule height0.45\ht0\hss}\box0}}}}
\item[\labelsep\bfseries] \item[\labelsep\bfseries]
\section*{Abstract} \section*{Abstract}
} }
{\endlist} {\endlist}
\newdimen\headlineindent % dimension for space between \newdimen\headlineindent % dimension for space between
\headlineindent=1.166cm % number and text of headings. \headlineindent=1.166cm % number and text of headings.

5
docs/thesis/main.tex
View file

@ -20,6 +20,7 @@
\renewcommand{\headrulewidth}{0pt} \renewcommand{\headrulewidth}{0pt}
\fancyfoot[C]{\thepage} \fancyfoot[C]{\thepage}
% 2-column bibliography
\makeatletter \makeatletter
\renewenvironment{thebibliography}[1] \renewenvironment{thebibliography}[1]
{\begin{multicols}{2}[\section*{\refname}]% {\begin{multicols}{2}[\section*{\refname}]%
@ -72,6 +73,10 @@
\end{shaded*} \end{shaded*}
} }
% Section numbering
\renewcommand\thechapter{\arabic{chapter}}
\renewcommand\thesection{\thechapter.\arabic{section}}
\renewcommand\thesubsection{\thesection.\arabic{subsection}}
\begin{document} \begin{document}

62
docs/thesis/ref.bib
View file

@ -527,3 +527,65 @@
year={2009}, year={2009},
publisher={Pearson Education} publisher={Pearson Education}
} }
@inproceedings{Chen_2016,
doi = {10.1145/2939672.2939785},
url = {https://doi.org/10.1145\%2F2939672.2939785},
year = 2016,
month = {aug},
publisher = {{ACM}},
author = {Tianqi Chen and Carlos Guestrin},
title = {{XGBoost}},
booktitle = {Proceedings of the 22nd {ACM} {SIGKDD} International Conference on Knowledge Discovery and Data Mining}
}
@article{food2019proposed,
title={Proposed regulatory framework for modifications to artificial intelligence/machine learning (AI/ML)-based software as a medical device (SaMD)},
author={Food and Drug Administration and others},
year={2019},
publisher={Department of Health and Human Services (United States)}
}
@inproceedings{moritz2018ray,
title={Ray: A distributed framework for emerging $\{$AI$\}$ applications},
author={Moritz, Philipp and Nishihara, Robert and Wang, Stephanie and Tumanov, Alexey and Liaw, Richard and Liang, Eric and Elibol, Melih and Yang, Zongheng and Paul, William and Jordan, Michael I and others},
booktitle={13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18)},
pages={561--577},
year={2018}
}
@article{rivest2021level,
title={level classification of scientific publications: A comparison of deep learning, direct citation and bibliographic coupling},
author={Rivest, Maxime and Vignola-Gagn{\'e}, Etienne and Archambault, {\'E}ric},
journal={PloS one},
volume={16},
number={5},
pages={e0251493},
year={2021},
publisher={Public Library of Science San Francisco, CA USA}
}
@article{maron1961automatic,
title={Automatic indexing: an experimental inquiry},
author={Maron, Melvin Earl},
journal={Journal of the ACM (JACM)},
volume={8},
number={3},
pages={404--417},
year={1961},
publisher={ACM New York, NY, USA}
}
@article{vaswani2017attention,
title={Attention is all you need},
author={Vaswani, Ashish and Shazeer, Noam and Parmar, Niki and Uszkoreit, Jakob and Jones, Llion and Gomez, Aidan N and Kaiser, {\L}ukasz and Polosukhin, Illia},
journal={Advances in neural information processing systems},
volume={30},
year={2017}
}
@misc{Procida_Diataxis_documentation_framework,
author = {Procida, Daniele},
title = {{Diátaxis documentation framework}},
url = {https://diataxis.fr/}
}