Compare commits

..

252 commits
v0.0.3 ... main

Author SHA1 Message Date
c55eba2077 Add max deps and bump old ones
All checks were successful
Publish documentation / publish (push) Successful in 51s
Check / Test on Python 3.10 (push) Successful in 1m1s
Check / Lint, format & type checks (push) Successful in 1m9s
Check / Test on Python 3.11 (push) Successful in 51s
Check / Test on Python 3.12 (push) Successful in 58s
Check / Test on Python 3.13 (push) Successful in 55s
2026-06-06 22:29:16 +01:00
2403a20ed0 Update cycle
All checks were successful
Publish documentation / publish (push) Successful in 1m4s
Check / Test on Python 3.10 (push) Successful in 1m16s
Check / Lint, format & type checks (push) Successful in 1m22s
Check / Test on Python 3.11 (push) Successful in 1m0s
Check / Test on Python 3.12 (push) Successful in 1m5s
Check / Test on Python 3.13 (push) Successful in 1m8s
2026-06-06 21:57:41 +01:00
7eb507d3c3 Run on modern python 2026-06-06 21:57:34 +01:00
7cafa11a83 Fix CI 2026-06-06 21:57:27 +01:00
8faee98ec6 Modernise
Some checks failed
Publish documentation / publish (push) Successful in 58s
Check / Lint, format & type checks (push) Failing after 1m2s
Check / Test on Python 3.10 (push) Successful in 1m9s
Check / Test on Python 3.9 (push) Successful in 50s
2026-06-06 21:39:06 +01:00
4c6441182b Migrate to forgejo
Some checks failed
Check / Lint, format & type checks (push) Failing after 42s
Check / Test on Python 3.10 (push) Failing after 47s
Publish documentation / publish (push) Successful in 55s
Check / Test on Python 3.9 (push) Failing after 42s
2026-06-06 19:41:38 +01:00
828f8a9231
Fix erroneous mypy warning 2022-11-05 11:12:34 +01:00
9321539ee7
Add final fixes 2022-10-01 11:15:28 +02:00
238131525a
Render pdf 2022-09-18 16:13:59 +02:00
a73881a28e
Minor consistency improvements 2022-09-18 16:13:51 +02:00
790db8bb40
Refine and clarify the content 2022-09-18 15:53:11 +02:00
83b5db4860
Stop opening too many terminals 2022-09-17 20:19:37 +02:00
ec64a0b5f1
Raise error instead of trying to fix bad names.
Thanks for the advice, @radl97
2022-09-17 20:19:23 +02:00
04c3486b83
Clarify some phrasing in the thesis 2022-09-11 19:37:20 +02:00
4653ef3459
Improve thesis based on comments from @suzanv 2022-09-04 18:44:10 +02:00
2c8c5cf589
Fix layout 2022-09-04 17:06:39 +02:00
eded50a667
Add scibert confusion figure 2022-09-04 17:05:17 +02:00
4eac2ae88d
Add docker link 2022-09-04 17:04:59 +02:00
b2c76c78c1
Update thesis with first feedback from @jstvssr 2022-08-23 17:31:56 +02:00
37b51428fb
Render first final draft 2022-08-21 20:37:17 +02:00
386b1affeb
Proofread and improve thesis 2022-08-21 20:35:38 +02:00
b5a69fea67
Proofread documentation 2022-08-20 12:57:16 +02:00
08a40bfaaf
Finish first draft 2022-08-19 16:36:28 +02:00
35d400a9ed
Add some results improve grammar 2022-08-14 20:36:06 +02:00
7d3fcc0705
Bump version 2022-08-13 16:56:13 +02:00
3a1c3d40de
Sanitize large-file filenames 2022-08-13 16:55:52 +02:00
2f750c2478
Fix error messages 2022-08-13 16:55:34 +02:00
955f0ceacc
Fix error on missing app 2022-08-13 16:55:23 +02:00
ce84719acb
Update survey processing 2022-08-13 16:53:51 +02:00
682812e016
Add survey results 2022-08-13 13:39:30 +02:00
49968691cc
Fix traces table filtering for string arguments 2022-08-11 16:49:19 +02:00
83e111f088
Fix lint 2022-08-07 19:37:45 +02:00
807bf46a99
Bump version 2022-08-07 14:13:46 +02:00
3b0dd85670
Make chart smaller 2022-08-07 14:13:24 +02:00
e717234f66
Improve log_metric for use in Notebooks 2022-08-07 14:13:11 +02:00
58286f6f1c
Improve TinyDB performance for *_ground_truth 2022-08-07 14:12:43 +02:00
f382390291
Improve thesis' fluency 2022-08-06 20:12:47 +02:00
a549f3e131
Update explanation page 2022-08-06 20:06:12 +02:00
69f2f6dc2f
Proofread first half of the thesis 2022-08-04 15:59:32 +02:00
573ada2d63
Work on thesis 2022-08-02 20:33:09 +02:00
5a143b4026 Merge branch 'main' of github.com:schmelczer/great-ai 2022-07-29 19:15:29 +02:00
71a0022ac7
Work on thesis 2022-07-29 19:15:07 +02:00
6bed8c365c
Update README.md 2022-07-29 17:20:39 +02:00
a8fa8fd11c
Fix unlink incompatibility for real 2022-07-29 13:36:28 +02:00
8ab5de6b19
Fix unlinks 2022-07-29 13:20:14 +02:00
fc251281a8
Extend install instructions 2022-07-29 13:13:58 +02:00
a86da4112a
Bump version 2022-07-29 13:13:36 +02:00
f8db199996
Make codebase compatible with Python 3.7 2022-07-29 13:05:05 +02:00
2ad06e8b38
Reformat file 2022-07-29 12:59:48 +02:00
55f1599a7a
Setup tox 2022-07-29 12:59:41 +02:00
18c6ba62bb
Copy async_lru for Python 3.7 compatibility 2022-07-29 12:57:16 +02:00
2b7188b1b8
Minor fixes 2022-07-29 11:05:37 +02:00
4d55499548
Fix default context value 2022-07-29 10:52:23 +02:00
85d079fab8
Try compatibility with Python 3.7 2022-07-29 09:50:06 +02:00
10b41aadac
Improve aspect ratio 2022-07-29 09:49:46 +02:00
c26104532b
Bump version 2022-07-25 15:41:33 +02:00
1c73ac03e4
Fix tests 2022-07-24 20:28:24 +02:00
e8b07b4f5a
Improve the PR-curve's semantics 2022-07-24 15:42:23 +02:00
e881bfbfbe
Improve landing page 2022-07-24 15:41:56 +02:00
871e4ec866
Fix best practices hyphenation 2022-07-24 15:40:57 +02:00
b902e46f63
Resize images 2022-07-24 15:39:31 +02:00
43b4b5478b
Fix typo 2022-07-17 17:34:16 +02:00
4f97884032
Bump version 2022-07-17 17:14:07 +02:00
d8a8d52bc5
Add documentation for SciBERT example 2022-07-17 17:13:35 +02:00
ae217490aa
Don't showcase data 2022-07-17 13:09:39 +02:00
d0c5f5b2a4
Document LargeFiles 2022-07-16 16:22:22 +02:00
f7c82ed0fe
Merge branch 'main' of https://github.com/schmelczer/great-ai 2022-07-16 15:36:01 +02:00
adcd300fa4
Minor docs fixes 2022-07-16 15:35:46 +02:00
50531d60ea
Improve thesis, take Suzan's feedback into account 2022-07-16 15:26:26 +02:00
a035caec4f
Increase figure sizes 2022-07-16 15:14:35 +02:00
0dd5b6e8f4
Improve docstrings 2022-07-16 13:53:52 +02:00
eb143917be
Fix typing 2022-07-16 12:28:01 +02:00
8cd3449cff
Fix exception serialisation error 2022-07-16 12:27:05 +02:00
f1a1de5469
Add percentages 2022-07-16 12:26:38 +02:00
4b919ee757
Fix notebooks, improve charts 2022-07-16 12:23:17 +02:00
9999b7ef29
Fix typos and improve docs 2022-07-15 20:03:13 +02:00
1f08f94684
Improve installation guide 2022-07-15 17:59:56 +02:00
aa31d2bb0a
Fix typos 2022-07-15 17:50:26 +02:00
aa548f0074
Improve layout 2022-07-15 17:07:41 +02:00
4debf1cf93
Fix dev instructions 2022-07-15 17:01:16 +02:00
2d35bb1f70
Fix readme on PyPI 2022-07-13 20:33:26 +02:00
041eefc401
Fix issues from @angyaloliver's feedback 2022-07-13 20:23:56 +02:00
584d746447
Merge branches 'main' and 'main' of github.com:schmelczer/great-ai 2022-07-13 19:56:41 +02:00
b9daa7bc4c
Update demos 2022-07-13 19:56:10 +02:00
20457b5c93
Update README.md 2022-07-13 14:41:33 +02:00
f12e924df3
Add video 2022-07-13 14:38:13 +02:00
d79d417f82
Update README.md 2022-07-13 14:32:58 +02:00
7a71510cca
Remove scrapingh & fix broken links 2022-07-13 13:07:23 +02:00
489b9d19e2
Add scibert example 2022-07-13 12:57:49 +02:00
03765e1aca
Fix parallelism not working 2022-07-13 12:45:11 +02:00
1dcf5bb3af
Improve docs 2022-07-13 12:44:57 +02:00
446f1c021a
Remove clutter in image 2022-07-13 08:47:35 +02:00
d6865e2aec
Add sequence labelling output 2022-07-13 08:47:23 +02:00
6106816999
Refactor 2022-07-13 08:33:22 +02:00
0585a4e4f9
Improve docs 2022-07-12 21:50:42 +02:00
4e07161a16
Improve docs 2022-07-12 21:50:03 +02:00
b1a66cb579
Minor fixes 2022-07-12 19:17:10 +02:00
8c7a31a513
Add docstrings 2022-07-12 19:16:13 +02:00
a1846a240e
Fix test on windows 2022-07-12 19:13:21 +02:00
83a9bf3ee8
Add installation guide 2022-07-12 19:12:56 +02:00
74bacb5a56
Update simple examples 2022-07-12 19:12:40 +02:00
ce19e5f05a
Improve readme add og-image 2022-07-12 16:02:59 +02:00
dc1a36edac
Improve tutorial 2022-07-12 16:00:20 +02:00
b1d6a09cfe
Bump version 2022-07-12 09:03:22 +02:00
68c7da38b8
Remove timestamp from logs in notebooks 2022-07-11 19:32:45 +02:00
8d1ad9a242
Add more documentation 2022-07-11 19:20:13 +02:00
7165174f4f
Document and reformat 2022-07-11 19:16:03 +02:00
44e5b66e2d
Update readme 2022-07-11 17:27:45 +02:00
fb601dfba1
Allow execution times over 1 second 2022-07-11 16:40:17 +02:00
7aeb015bb1
Fix disappearing table on empty result set 2022-07-11 15:37:47 +02:00
6d57622ce3
Improve remote call 2022-07-11 14:11:20 +02:00
5800557168
Proofread document 2022-07-11 14:11:03 +02:00
0ee71d7be4
Update version 2022-07-11 14:10:54 +02:00
96eb0e0e4a
Remove favicon from schema 2022-07-11 14:10:47 +02:00
dda4e55f9e
Match Healthcheck with remote_call timeout 2022-07-11 12:10:52 +02:00
43345f5851
Fix wrong path 2022-07-11 12:10:39 +02:00
18ef86aeef
Fix formatting 2022-07-11 09:01:14 +02:00
4e890d8054
Move files 2022-07-11 09:01:06 +02:00
c046d64a98
Move files 2022-07-10 19:48:22 +02:00
b97b20ba88
Improve docs 2022-07-10 19:43:39 +02:00
c974409fce
Update tags 2022-07-10 19:39:10 +02:00
cb605798ab
Update tests 2022-07-10 19:38:35 +02:00
00568ca6d3
Document utilities 2022-07-10 19:37:45 +02:00
2b378114aa
Add some docstrings 2022-07-10 13:21:08 +02:00
63a45989f4
Improve documentation 2022-07-09 23:10:21 +02:00
51f6f7174b
Remove miliseconds from logs 2022-07-09 23:08:43 +02:00
272ec7acc6
Update docker image 2022-07-09 21:50:22 +02:00
01c496ec2e
Add custom repr string for better notebook DX 2022-07-09 21:33:31 +02:00
286ede5fd3
Add simpler parallel_map 2022-07-09 21:33:14 +02:00
7db1503a45
Add logo 2022-07-09 20:53:02 +02:00
349d4b4201
Remove magic from ipynb before serving 2022-07-09 20:52:45 +02:00
bf7982c56b
Use favicon 2022-07-09 20:52:29 +02:00
378047e622
Production improvements 2022-07-09 12:34:21 +02:00
7bd2e89070
Add CNAME 2022-07-08 21:56:12 +02:00
d18cbf880e
Update version 2022-07-08 21:41:34 +02:00
a07b0bbc2e Merge branch 'main' of github.com:schmelczer/great-ai 2022-07-08 21:41:16 +02:00
4b2731858a
Update names 2022-07-08 21:38:50 +02:00
0e81df1ef5
Update overview 2022-07-08 21:38:38 +02:00
f1f40e8727
Add progress 2022-07-08 20:33:40 +02:00
7c99305afb
Fix function 2022-07-08 20:33:33 +02:00
299d644bc4
Replace aiohttp with httpx 2022-07-08 20:30:57 +02:00
46ffe7a70e
Start documentation 2022-07-08 20:29:22 +02:00
c06862ab76
Improve CLI 2022-07-08 13:38:26 +02:00
b2b7332b52
Fix delete issue 2022-07-08 13:38:06 +02:00
c2d2bf49f1
Improve CLI 2022-07-08 13:27:25 +02:00
65ec6d6f9b
Do no supress exception 2022-07-08 13:27:16 +02:00
9abf20f6a0
Create codeql-analysis.yml 2022-07-08 11:46:35 +02:00
9aa53056ad
Whoops 2022-07-08 11:34:30 +02:00
ea540e859e
Add better instructions 2022-07-08 11:29:10 +02:00
ef751358f5
Fix conflict 2022-07-08 11:29:05 +02:00
98903305e8
Add missing file 2022-07-08 11:28:59 +02:00
7e2be76e4a
Update actions 2022-07-08 11:20:20 +02:00
b995da5d80
Update links 2022-07-08 11:09:38 +02:00
c39feeee53 Setup docs page 2022-07-08 10:56:42 +02:00
dadbe24c82 Renaming and minor improvements 2022-07-08 10:05:33 +02:00
00714bef4e Improve batch processing API 2022-07-08 09:37:08 +02:00
1d30fd730a Remove match names 2022-07-08 09:09:46 +02:00
a9b8a0172a Stop wasting money 2022-07-08 09:04:47 +02:00
f7c852951e Update configfile API 2022-07-08 08:59:24 +02:00
d29694b1a2 Update table 2022-07-08 08:58:30 +02:00
8c461b0f37 Update severities 2022-07-08 08:58:00 +02:00
d4133f7e81 Merge branch 'main' of https://github.com/ScoutinScience/great-ai 2022-07-07 17:21:44 +02:00
b6c7a4b7ca Remove options from GreatAI.create 2022-07-07 17:19:11 +02:00
612f3ac5e1 Improve types 2022-07-07 16:50:10 +02:00
e416c22d76 Merge pull request #4 from ScoutinScience/dependabot/github_actions/EnricoMi/publish-unit-test-result-action-2
Bump EnricoMi/publish-unit-test-result-action from 1 to 2
2022-07-07 14:42:27 +02:00
7a4e75ff63 Fix lint 2022-07-07 14:29:05 +02:00
a84f899a14 Lint tests 2022-07-07 14:13:16 +02:00
72ab627a34 Fix typing and minor issues 2022-07-07 14:12:44 +02:00
2db2253578 Update test style 2022-07-05 13:14:05 +02:00
f188724d4b Add Flit and change namer 2022-07-05 10:45:51 +02:00
50db7b8cb2 Fix batch tests 2022-07-04 23:09:03 +02:00
aba8676d53 Make cross platform 2022-07-04 21:33:37 +02:00
21357a9841 Fix packaging 2022-07-04 21:13:35 +02:00
00cc8225c5 Move files 2022-07-04 19:31:15 +02:00
3cf28379e8 Move folders 2022-07-04 18:54:32 +02:00
ba2e252759 Test on all OS-es 2022-07-04 18:53:38 +02:00
dependabot[bot]
995f49e362 Bump EnricoMi/publish-unit-test-result-action from 1 to 2
Bumps [EnricoMi/publish-unit-test-result-action](https://github.com/EnricoMi/publish-unit-test-result-action) from 1 to 2.
- [Release notes](https://github.com/EnricoMi/publish-unit-test-result-action/releases)
- [Commits](https://github.com/EnricoMi/publish-unit-test-result-action/compare/v1...v2)

---
updated-dependencies:
- dependency-name: EnricoMi/publish-unit-test-result-action
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
2022-07-04 16:53:22 +00:00
8e95efb54e Add test 2022-07-04 15:45:46 +02:00
3cc8fd6a4c Fix tests 2022-07-04 15:45:28 +02:00
94c9a39042 Create LICENSE 2022-07-04 14:58:31 +02:00
134fc780d4 Add doctest support 2022-07-04 14:22:00 +02:00
411af60e57 Add dev-requirements 2022-07-04 14:21:31 +02:00
f160b07163 Move files 2022-07-04 13:55:44 +02:00
d2af1b8151 Add missing version argument 2022-07-04 13:35:33 +02:00
78ab9044fe Update version 2022-07-04 09:29:11 +02:00
e59f545718 Cache get 2022-07-04 09:28:35 +02:00
c5012e43a4 Show model version on dashboard 2022-07-04 09:28:29 +02:00
9e183bbfc0 Fix renames 2022-07-04 09:28:09 +02:00
d971ea054f Store model versions globally 2022-07-04 09:27:43 +02:00
3e2afbe3eb Rename folder 2022-07-04 09:26:53 +02:00
bb1077d45f Add exceptions 2022-07-04 08:47:52 +02:00
92a0b0ba55 Add basic tests 2022-07-04 08:47:37 +02:00
896c26cef4 Extract variable 2022-07-04 08:47:26 +02:00
9ac60e7e0a Fix async tracing context 2022-07-04 08:47:17 +02:00
41214be575 Fiz name of decorated functions 2022-07-03 17:47:49 +02:00
fb88036c88 Fix missing logo 2022-07-03 17:47:31 +02:00
ee06b27e93 Fix missing space 2022-07-03 17:47:23 +02:00
fdc014ada9 Release new version 2022-07-03 16:17:48 +02:00
58d318dd0e Serialize BaseModel 2022-07-03 16:17:27 +02:00
6f9e18f0c5 Fix table UI 2022-07-03 16:17:13 +02:00
4bdf711218 Add basic async support 2022-07-03 16:16:46 +02:00
623e81cdcb Serialise BaseModels 2022-07-03 16:05:19 +02:00
2f4d203446 Fix hanging bug by adding manager 2022-07-03 16:01:52 +02:00
ad1b2a20ef Try fixing test 2022-07-03 14:56:01 +02:00
d2c0acc900 Try debugging 2022-07-03 14:32:05 +02:00
64f260ab1c Remove trailing slash 2022-07-03 13:55:10 +02:00
4f59a53af5 Add more colors 2022-07-03 13:54:52 +02:00
92c185cb0a Change emoji 2022-07-03 13:54:35 +02:00
d9a18ac982 Print default values 2022-07-03 13:54:29 +02:00
1f4bfd2a24 Try fixing zombie processes 2022-07-03 13:54:15 +02:00
0d9d60e5f1 Try debug hanging process 2022-07-03 13:46:58 +02:00
32bb77d4d6 Try debugging hanging 2022-07-03 13:32:42 +02:00
05fe47e037 Try debugging stuck tests 2022-07-03 13:08:48 +02:00
e85edf4222 Debug stuck tests 2022-07-03 12:57:05 +02:00
c76342534a Improve serialization 2022-07-03 12:25:56 +02:00
7d774f37be Remove 3.7 support 2022-07-02 23:01:53 +02:00
2ba4690e12 Minor fixes 2022-07-02 21:57:09 +02:00
31f5bab2f4 Loosen requriements 2022-07-02 09:59:32 +02:00
513b1df984 Loosen requirements 2022-07-02 09:34:08 +02:00
f4e69bf32e Add overrides for threaded_parallel_map 2022-07-02 08:27:31 +02:00
36956b472e Add testing on Python 3.7 2022-07-02 08:27:11 +02:00
aa3131dcc1 Remove logging and leave it up to the user 2022-07-02 08:26:26 +02:00
2e12947429 Don't leave threads running 2022-07-02 00:13:25 +02:00
9866b88faf Fix exception handling 2022-07-01 23:50:31 +02:00
835f9b4ba0 Fix import 2022-07-01 23:13:32 +02:00
45a2058bf0 Update version 2022-07-01 22:43:32 +02:00
a40f456e39 Add error handling to parallel map 2022-07-01 22:43:08 +02:00
cbe843220a Add default values for conf 2022-07-01 22:42:31 +02:00
076f676f4f Format 2022-07-01 21:10:38 +02:00
6a50f87abe Add builtin deserialization 2022-07-01 20:34:47 +02:00
8692cc60ee Add support for raw results 2022-07-01 20:31:35 +02:00
c1d32741c1 Improve CPU usage 2022-07-01 19:57:24 +02:00
b56273e267 Simplify API 2022-07-01 19:50:43 +02:00
8f1418c346 Support more types for freezing 2022-07-01 19:50:26 +02:00
c8fbced859 Improve argument typechecking 2022-07-01 19:50:03 +02:00
0ff0b49a79 Add threaded parallel_map 2022-06-30 17:22:16 +02:00
154cc52fa6 Improve parallel map API 2022-06-30 16:54:01 +02:00
5dc85905b4 Update version 2022-06-29 09:14:48 +02:00
3e393bf362 Improve parallel map 2022-06-29 09:14:35 +02:00
3a8d357e3c Update version 2022-06-28 18:38:04 +02:00
77e12d3b15 Add example 2022-06-28 18:37:30 +02:00
da89e5eb25 Add chunk 2022-06-28 18:37:17 +02:00
0e5608b3a0 Fix lint 2022-06-28 18:36:43 +02:00
1556106cf0 Make colors optional 2022-06-28 18:27:22 +02:00
d9e862af6b Improve parallel map 2022-06-28 18:27:07 +02:00
cab34de326 Remove clutter 2022-06-28 18:25:18 +02:00
e53afb07bc Improve API 2022-06-26 23:31:15 +02:00
d40e22707a Fix failed message's retry count 2022-06-26 21:13:58 +02:00
57e8cc40e3 Export trace 2022-06-26 21:13:39 +02:00
8f55dbff27 Update version 2022-06-26 20:21:57 +02:00
b57a044aa1 Fix missing data in local install 2022-06-26 20:11:57 +02:00
1018d9c6b4 Fix bug 2022-06-26 20:03:26 +02:00
363 changed files with 15943 additions and 6457 deletions

View file

@ -1,6 +1,5 @@
.env .env
.git .git
__pycache__
.cache .cache
.mypy_cache .mypy_cache
.pytest_cache .pytest_cache
@ -11,6 +10,9 @@ Dockerfile
.github .github
.vscode .vscode
docs docs
!docs/hello_world.py
scripts scripts
tests tests
mkdocs.yaml
**/.mypy_cache
**/__pycache__
**/tracing_database.json

View file

@ -0,0 +1,57 @@
name: Publish on DockerHub
on:
push:
tags: ['*']
workflow_dispatch:
jobs:
publish:
runs-on: docker
steps:
- name: Checkout
uses: actions/checkout@v4
# The `docker` runner image is node-based and may not ship the docker CLI
# that the docker/* actions below drive; install it idempotently, as the
# sibling repos do for their Docker jobs.
- name: Ensure Docker CLI
run: |
set -eux
if ! command -v docker >/dev/null 2>&1; then
ARCH=$(uname -m)
curl -fsSL --retry 3 --retry-connrefused \
"https://download.docker.com/linux/static/stable/${ARCH}/docker-27.5.1.tgz" \
| tar xz --strip-components=1 -C /usr/local/bin docker/docker
fi
docker --version
# Marketplace actions must be referenced by full URL: this instance's
# DEFAULT_ACTIONS_URL points at code.forgejo.org, so only bare `actions/*`
# names resolve to GitHub automatically.
- name: Set up QEMU
uses: https://github.com/docker/setup-qemu-action@v3
- name: Set up Docker Buildx
uses: https://github.com/docker/setup-buildx-action@v3
- name: Log in to Docker Hub
uses: https://github.com/docker/login-action@v3
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_PASSWORD }}
- name: Extract metadata for the Docker image
id: meta
uses: https://github.com/docker/metadata-action@v5
with:
images: schmelczera/great-ai
- name: Build and push
uses: https://github.com/docker/build-push-action@v6
with:
context: .
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
platforms: linux/amd64,linux/arm64

View file

@ -0,0 +1,52 @@
name: Publish documentation
on:
push:
branches: [main]
paths:
- 'docs/**'
- 'great_ai/**'
- 'mkdocs.yaml'
- '.forgejo/workflows/docs.yml'
workflow_dispatch:
concurrency:
group: pages
cancel-in-progress: false
jobs:
publish:
runs-on: docker
steps:
- uses: actions/checkout@v4
with:
# The mkdocs git-revision-date plugin reads each page's git history.
fetch-depth: 0
- name: Install uv
run: |
curl -LsSf https://astral.sh/uv/install.sh | sh
echo "$HOME/.local/bin" >> "$GITHUB_PATH"
- name: Set up Python
run: uv python install 3.10
- name: Install dependencies
run: |
uv venv --python 3.10
uv pip install '.[dev]'
- name: Build documentation
run: |
. .venv/bin/activate
mkdocs build
# The old workflow ran `mkdocs gh-deploy` (GitHub Pages); on this instance
# built sites are rsynced into the host /pages mount that nginx serves,
# via the shared ci-actions/deploy-pages action — same as photos/reconcile.
- name: Deploy to pages mount
if: github.ref == 'refs/heads/main'
uses: http://forgejo:3000/andras/ci-actions/deploy-pages@main
with:
source: site
target: great-ai

View file

@ -0,0 +1,28 @@
name: Publish on PyPI
on:
push:
tags: ['*']
workflow_dispatch:
jobs:
publish:
runs-on: docker
steps:
- uses: actions/checkout@v4
- name: Install uv
run: |
curl -LsSf https://astral.sh/uv/install.sh | sh
echo "$HOME/.local/bin" >> "$GITHUB_PATH"
- name: Set up Python
run: uv python install 3.10
# Forgejo cannot use PyPI trusted publishing (OIDC), so authenticate with
# an API token, the same way the sibling repos publish their packages.
- name: Build and publish
env:
FLIT_USERNAME: __token__
FLIT_PASSWORD: ${{ secrets.PYPI_TOKEN }}
run: uvx flit publish

View file

@ -0,0 +1,73 @@
name: Check
on:
push:
branches: [main, dev]
pull_request:
branches: [main, dev]
workflow_dispatch:
concurrency:
group: ${{ gitea.workflow }}-${{ gitea.ref }}
cancel-in-progress: true
jobs:
lint:
name: Lint, format & type checks
runs-on: docker
steps:
- uses: actions/checkout@v4
- name: Install uv
run: |
curl -LsSf https://astral.sh/uv/install.sh | sh
echo "$HOME/.local/bin" >> "$GITHUB_PATH"
- name: Set up Python
run: uv python install 3.10
- name: Install dependencies
# --seed gives the venv its own pip, which scripts/check-python.sh shells
# out to for its linters; '.[dev]' provides the rest (mypy resolves the
# package's own imports against the installed tree).
run: |
uv venv --seed --python 3.10
uv pip install '.[dev]'
- name: Check code and formatting
run: |
. .venv/bin/activate
scripts/check-python.sh great_ai tests
test:
name: Test on Python ${{ matrix.python-version }}
runs-on: docker
strategy:
fail-fast: false
matrix:
# pyproject declares >= 3.7, but uv's standalone CPython and the current
# dependency floors (scikit-learn/numpy now require >= 3.9) no longer
# build on the older interpreters, so we test the current supported set.
# The windows leg of the old GitHub matrix is dropped: this Forgejo
# instance only has a Linux `docker` runner.
python-version: ['3.10', '3.11', '3.12', '3.13']
steps:
- uses: actions/checkout@v4
- name: Install uv
run: |
curl -LsSf https://astral.sh/uv/install.sh | sh
echo "$HOME/.local/bin" >> "$GITHUB_PATH"
- name: Set up Python ${{ matrix.python-version }}
run: uv python install ${{ matrix.python-version }}
- name: Install dependencies
run: |
uv venv --python ${{ matrix.python-version }}
uv pip install '.[dev]'
- name: Run tests
run: |
. .venv/bin/activate
pytest --doctest-modules --asyncio-mode=strict

View file

@ -1,6 +0,0 @@
version: 2
updates:
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "daily"

View file

@ -1,39 +0,0 @@
name: Publish on DockerHub
on:
push:
tags:
- '*'
jobs:
publish:
runs-on: ubuntu-latest
steps:
- name: Set up QEMU
uses: docker/setup-qemu-action@v2
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2
- name: Log in to Docker Hub
uses: docker/login-action@v2
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_PASSWORD }}
- name: Checkout
uses: actions/checkout@v3
- name: Extract metadata for the Docker image
id: meta
uses: docker/metadata-action@v4
with:
images: schmelczera/great-ai
- name: Build and push
uses: docker/build-push-action@v3
with:
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
platforms: linux/amd64,linux/arm64

View file

@ -1,29 +0,0 @@
name: Publish on PyPI
on:
push:
tags:
- '*'
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Python 3.9.2
uses: actions/setup-python@v2
with:
python-version: 3.9.2
- name: Install pypa/build
run: python -m pip install build --user
- name: Build a binary wheel and a source tarball
run: python -m build --sdist --wheel --outdir dist/
- name: Publish distribution to PyPI
uses: pypa/gh-action-pypi-publish@master
with:
user: __token__
password: ${{ secrets.PYPI_API_TOKEN }}

View file

@ -1,94 +0,0 @@
name: Test
on:
workflow_dispatch:
push:
branches:
- main
- dev
jobs:
test:
name: Build and test on Python ${{ matrix.python-version }}
runs-on: ubuntu-latest
strategy:
matrix:
python-version: ["3.8.12", "3.9.12", "3.10.4"]
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Setup Python ${{ matrix.python-version }}
uses: actions/setup-python@v2
with:
python-version: ${{ matrix.python-version }}
- name: Install dependencies
run: |
python3 -m pip install --upgrade pip setuptools pytest pytest-cov pytest-subtests pytest-asyncio
pip install .
- name: Check code and formatting
run: scripts/check-python.sh .
- name: Run tests
run: python3 -m pytest --cov=. --cov-report=xml --junit-xml pytest.xml --asyncio-mode=strict || true
- name: Upload results
if: always()
uses: actions/upload-artifact@v2
with:
name: Unit test coverage (Python ${{ matrix.python-version }})
path: "*.xml"
sonar:
name: Analyse Python project with SonarQube
needs: test
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
with:
fetch-depth: 0
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install .
rm -rf build
- name: Download test results
uses: actions/download-artifact@v2
with:
path: artifacts
- uses: sonarsource/sonarqube-scan-action@master
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
with:
args: >
-Dsonar.projectKey=great-ai
-Dsonar.login=${{ secrets.SONAR_TOKEN }}
-Dsonar.verbose=true
-Dsonar.python.coverage.reportPaths=artifacts/*/coverage.xml
-Dsonar.coverage.exclusions=**/external/**/*
-Dsonar.exclusions=**/external/**/*,artifacts/**/*
publish-test-results:
name: Publish unit test results
needs: test
runs-on: ubuntu-latest
if: always()
steps:
- name: Download artifacts
uses: actions/download-artifact@v2
with:
path: artifacts
- name: Publish results
uses: EnricoMi/publish-unit-test-result-action@v1
with:
files: artifacts/*/pytest.xml

2
.gitignore vendored
View file

@ -8,3 +8,5 @@ __pycache__
.ipynb_checkpoints .ipynb_checkpoints
*.egg-info *.egg-info
build build
tracing_database.json
.tox

24
.vscode/settings.json vendored
View file

@ -1,28 +1,33 @@
{ {
"cSpell.words": [ "cSpell.words": [
"alru",
"Analyse", "Analyse",
"András",
"basereload", "basereload",
"boto", "boto",
"botocore", "botocore",
"Convolutional", "Convolutional",
"datatable", "datatable",
"deduplicated",
"displaylogo", "displaylogo",
"downsample", "downsample",
"fastapi", "fastapi",
"finalise", "finalise",
"finalised", "finalised",
"gridfs", "gridfs",
"httpx",
"iloc", "iloc",
"initialisation", "initialisation",
"initialised", "initialised",
"initialising", "initialising",
"inplace", "inplace",
"ipynb", "ipynb",
"joblib", "langcodes",
"lemmatize", "lemmatize",
"levelname", "levelname",
"levelno", "levelno",
"matplotlib", "matplotlib",
"miniters",
"Multinomial", "Multinomial",
"multiprocess", "multiprocess",
"nbconvert", "nbconvert",
@ -31,11 +36,13 @@
"organisation's", "organisation's",
"Parcoords", "Parcoords",
"plotly", "plotly",
"pretrained",
"proba", "proba",
"pydantic", "pydantic",
"pymongo", "pymongo",
"pyplot", "pyplot",
"redoc", "redoc",
"scibert",
"serialise", "serialise",
"sklearn", "sklearn",
"starlette", "starlette",
@ -47,6 +54,7 @@
"tickvals", "tickvals",
"tinydb", "tinydb",
"tqdm", "tqdm",
"unchunk",
"uvicorn", "uvicorn",
"Vectorizer", "Vectorizer",
"xmargin", "xmargin",
@ -59,8 +67,18 @@
"**/.mypy_cache": true, "**/.mypy_cache": true,
"**/.pytest_cache": true, "**/.pytest_cache": true,
"**/*.egg-info": true, "**/*.egg-info": true,
"**/*.cache": true "**/*.cache": true,
"**/*.tox": true,
"**/tracing_database.json": true
}, },
"notebook.output.textLineLimit": 400, "notebook.output.textLineLimit": 400,
"python.defaultInterpreterPath": ".env/bin/python" "python.defaultInterpreterPath": ".env/bin/python",
"python.testing.pytestArgs": ["tests"],
"editor.rulers": [88],
"python.linting.flake8Enabled": false,
"python.linting.pylintEnabled": false,
"python.linting.mypyEnabled": true,
"python.testing.unittestEnabled": false,
"python.testing.pytestEnabled": true,
"editor.wordWrap": "on"
} }

33
.vscode/tasks.json vendored
View file

@ -4,30 +4,49 @@
{ {
"label": "Format and lint", "label": "Format and lint",
"type": "shell", "type": "shell",
"command": "source .env/bin/activate && scripts/format-python.sh .", "command": "source .env/bin/activate && scripts/format-python.sh great_ai docs tests",
"windows": { "windows": {
"command": ".env\\bin\\activate.bat; scripts\\format-python.sh ." "command": ".env\\bin\\activate.bat; scripts\\format-python.sh great_ai docs tests"
}, },
"group": "test", "group": "test",
"presentation": { "presentation": {
"reveal": "always", "reveal": "always",
"panel": "new" "showReuseMessage": false,
"panel": "shared"
}, },
"options": { "options": {
"cwd": "${workspaceFolder}" "cwd": "${workspaceFolder}"
} }
}, },
{ {
"label": "Test", "label": "Test (quick)",
"type": "shell", "type": "shell",
"command": "source .env/bin/activate && python3 -m pytest .", "command": "source .env/bin/activate && python3 -m pytest . --doctest-modules --asyncio-mode=strict",
"windows": { "windows": {
"command": ".env\\bin\\activate.bat; python3 -m pytest ." "command": ".env\\bin\\activate.bat; python3 -m pytest . --doctest-modules --asyncio-mode=strict"
}, },
"group": "test", "group": "test",
"presentation": { "presentation": {
"reveal": "always", "reveal": "always",
"panel": "new" "showReuseMessage": false,
"panel": "shared"
},
"options": {
"cwd": "${workspaceFolder}"
}
},
{
"label": "Test (all Python versions)",
"type": "shell",
"command": "source .env/bin/activate && python3 -m tox",
"windows": {
"command": ".env\\bin\\activate.bat; python3 -m tox"
},
"group": "test",
"presentation": {
"reveal": "always",
"showReuseMessage": false,
"panel": "shared"
}, },
"options": { "options": {
"cwd": "${workspaceFolder}" "cwd": "${workspaceFolder}"

View file

@ -1,12 +1,14 @@
# syntax=docker/dockerfile:1.4
FROM python:3.10.4-slim-bullseye FROM python:3.10.4-slim-bullseye
LABEL org.opencontainers.image.title="GreatAI package wrapper container" LABEL org.opencontainers.image.title="GreatAI package wrapper image"
LABEL org.opencontainers.image.vendor="ScoutinScience B.V." LABEL org.opencontainers.image.vendor="ScoutinScience B.V."
LABEL org.opencontainers.image.authors="andras@schmelczer.dev" LABEL org.opencontainers.image.authors="andras@schmelczer.dev"
LABEL org.opencontainers.image.source="https://github.com/ScoutinScience/great-ai" LABEL org.opencontainers.image.source="https://github.com/schmelczer/great-ai"
SHELL ["/bin/bash", "-c"]
ENV ENVIRONMENT=production ENV ENVIRONMENT=production
EXPOSE 6060
# curl is needed for the healthcheck # curl is needed for the healthcheck
# build-essentials are needed for building packages # build-essentials are needed for building packages
@ -21,16 +23,24 @@ RUN python3 -m pip --no-cache-dir install --upgrade pip &&\
rm -rf great_ai rm -rf great_ai
HEALTHCHECK \ HEALTHCHECK \
--interval=10s \ --interval=30s \
--timeout=60s \ --timeout=180s \
--start-period=30s \ --start-period=60s \
--retries=5 \ --retries=5 \
CMD [ "curl", "--fail", "http://localhost:6060/health" ] CMD [ "curl", "--fail", "http://localhost:6060/health" ]
WORKDIR /app WORKDIR /app
VOLUME /app COPY <<EOF hello_world.py
from great_ai import GreatAI
\
@GreatAI.create
def hello_world(name: str) -> str:
"""Learn more about GreatAI at https://great-ai.scoutinscience.com"""
return f"Hello {name}!"
EOF
COPY docs/hello_world.py . EXPOSE 6060
VOLUME /app
ENTRYPOINT ["/usr/local/bin/python3", "-m", "great_ai"] ENTRYPOINT ["/usr/local/bin/python3", "-m", "great_ai"]
CMD ["hello_world.py"] CMD ["hello_world.py"]

674
LICENSE Normal file
View file

@ -0,0 +1,674 @@
GNU GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The GNU General Public License is a free, copyleft license for
software and other kinds of works.
The licenses for most software and other practical works are designed
to take away your freedom to share and change the works. By contrast,
the GNU General Public License is intended to guarantee your freedom to
share and change all versions of a program--to make sure it remains free
software for all its users. We, the Free Software Foundation, use the
GNU General Public License for most of our software; it applies also to
any other work released this way by its authors. You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
them if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it in new
free programs, and that you know you can do these things.
To protect your rights, we need to prevent others from denying you
these rights or asking you to surrender the rights. Therefore, you have
certain responsibilities if you distribute copies of the software, or if
you modify it: responsibilities to respect the freedom of others.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must pass on to the recipients the same
freedoms that you received. You must make sure that they, too, receive
or can get the source code. And you must show them these terms so they
know their rights.
Developers that use the GNU GPL protect your rights with two steps:
(1) assert copyright on the software, and (2) offer you this License
giving you legal permission to copy, distribute and/or modify it.
For the developers' and authors' protection, the GPL clearly explains
that there is no warranty for this free software. For both users' and
authors' sake, the GPL requires that modified versions be marked as
changed, so that their problems will not be attributed erroneously to
authors of previous versions.
Some devices are designed to deny users access to install or run
modified versions of the software inside them, although the manufacturer
can do so. This is fundamentally incompatible with the aim of
protecting users' freedom to change the software. The systematic
pattern of such abuse occurs in the area of products for individuals to
use, which is precisely where it is most unacceptable. Therefore, we
have designed this version of the GPL to prohibit the practice for those
products. If such problems arise substantially in other domains, we
stand ready to extend this provision to those domains in future versions
of the GPL, as needed to protect the freedom of users.
Finally, every program is threatened constantly by software patents.
States should not allow patents to restrict development and use of
software on general-purpose computers, but in those that do, we wish to
avoid the special danger that patents applied to a free program could
make it effectively proprietary. To prevent this, the GPL assures that
patents cannot be used to render the program non-free.
The precise terms and conditions for copying, distribution and
modification follow.
TERMS AND CONDITIONS
0. Definitions.
"This License" refers to version 3 of the GNU General Public License.
"Copyright" also means copyright-like laws that apply to other kinds of
works, such as semiconductor masks.
"The Program" refers to any copyrightable work licensed under this
License. Each licensee is addressed as "you". "Licensees" and
"recipients" may be individuals or organizations.
To "modify" a work means to copy from or adapt all or part of the work
in a fashion requiring copyright permission, other than the making of an
exact copy. The resulting work is called a "modified version" of the
earlier work or a work "based on" the earlier work.
A "covered work" means either the unmodified Program or a work based
on the Program.
To "propagate" a work means to do anything with it that, without
permission, would make you directly or secondarily liable for
infringement under applicable copyright law, except executing it on a
computer or modifying a private copy. Propagation includes copying,
distribution (with or without modification), making available to the
public, and in some countries other activities as well.
To "convey" a work means any kind of propagation that enables other
parties to make or receive copies. Mere interaction with a user through
a computer network, with no transfer of a copy, is not conveying.
An interactive user interface displays "Appropriate Legal Notices"
to the extent that it includes a convenient and prominently visible
feature that (1) displays an appropriate copyright notice, and (2)
tells the user that there is no warranty for the work (except to the
extent that warranties are provided), that licensees may convey the
work under this License, and how to view a copy of this License. If
the interface presents a list of user commands or options, such as a
menu, a prominent item in the list meets this criterion.
1. Source Code.
The "source code" for a work means the preferred form of the work
for making modifications to it. "Object code" means any non-source
form of a work.
A "Standard Interface" means an interface that either is an official
standard defined by a recognized standards body, or, in the case of
interfaces specified for a particular programming language, one that
is widely used among developers working in that language.
The "System Libraries" of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form. A
"Major Component", in this context, means a major essential component
(kernel, window system, and so on) of the specific operating system
(if any) on which the executable work runs, or a compiler used to
produce the work, or an object code interpreter used to run it.
The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities. However, it does not include the work's
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work. For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.
The Corresponding Source need not include anything that users
can regenerate automatically from other parts of the Corresponding
Source.
The Corresponding Source for a work in source code form is that
same work.
2. Basic Permissions.
All rights granted under this License are granted for the term of
copyright on the Program, and are irrevocable provided the stated
conditions are met. This License explicitly affirms your unlimited
permission to run the unmodified Program. The output from running a
covered work is covered by this License only if the output, given its
content, constitutes a covered work. This License acknowledges your
rights of fair use or other equivalent, as provided by copyright law.
You may make, run and propagate covered works that you do not
convey, without conditions so long as your license otherwise remains
in force. You may convey covered works to others for the sole purpose
of having them make modifications exclusively for you, or provide you
with facilities for running those works, provided that you comply with
the terms of this License in conveying all material for which you do
not control copyright. Those thus making or running the covered works
for you must do so exclusively on your behalf, under your direction
and control, on terms that prohibit them from making any copies of
your copyrighted material outside their relationship with you.
Conveying under any other circumstances is permitted solely under
the conditions stated below. Sublicensing is not allowed; section 10
makes it unnecessary.
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological
measure under any applicable law fulfilling obligations under article
11 of the WIPO copyright treaty adopted on 20 December 1996, or
similar laws prohibiting or restricting circumvention of such
measures.
When you convey a covered work, you waive any legal power to forbid
circumvention of technological measures to the extent such circumvention
is effected by exercising rights under this License with respect to
the covered work, and you disclaim any intention to limit operation or
modification of the work as a means of enforcing, against the work's
users, your or third parties' legal rights to forbid circumvention of
technological measures.
4. Conveying Verbatim Copies.
You may convey verbatim copies of the Program's source code as you
receive it, in any medium, provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice;
keep intact all notices stating that this License and any
non-permissive terms added in accord with section 7 apply to the code;
keep intact all notices of the absence of any warranty; and give all
recipients a copy of this License along with the Program.
You may charge any price or no price for each copy that you convey,
and you may offer support or warranty protection for a fee.
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified
it, and giving a relevant date.
b) The work must carry prominent notices stating that it is
released under this License and any conditions added under section
7. This requirement modifies the requirement in section 4 to
"keep intact all notices".
c) You must license the entire work, as a whole, under this
License to anyone who comes into possession of a copy. This
License will therefore apply, along with any applicable section 7
additional terms, to the whole of the work, and all its parts,
regardless of how they are packaged. This License gives no
permission to license the work in any other way, but it does not
invalidate such permission if you have separately received it.
d) If the work has interactive user interfaces, each must display
Appropriate Legal Notices; however, if the Program has interactive
interfaces that do not display Appropriate Legal Notices, your
work need not make them do so.
A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
"aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit. Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate.
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms
of sections 4 and 5, provided that you also convey the
machine-readable Corresponding Source under the terms of this License,
in one of these ways:
a) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by the
Corresponding Source fixed on a durable physical medium
customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by a
written offer, valid for at least three years and valid for as
long as you offer spare parts or customer support for that product
model, to give anyone who possesses the object code either (1) a
copy of the Corresponding Source for all the software in the
product that is covered by this License, on a durable physical
medium customarily used for software interchange, for a price no
more than your reasonable cost of physically performing this
conveying of source, or (2) access to copy the
Corresponding Source from a network server at no charge.
c) Convey individual copies of the object code with a copy of the
written offer to provide the Corresponding Source. This
alternative is allowed only occasionally and noncommercially, and
only if you received the object code with such an offer, in accord
with subsection 6b.
d) Convey the object code by offering access from a designated
place (gratis or for a charge), and offer equivalent access to the
Corresponding Source in the same way through the same place at no
further charge. You need not require recipients to copy the
Corresponding Source along with the object code. If the place to
copy the object code is a network server, the Corresponding Source
may be on a different server (operated by you or a third party)
that supports equivalent copying facilities, provided you maintain
clear directions next to the object code saying where to find the
Corresponding Source. Regardless of what server hosts the
Corresponding Source, you remain obligated to ensure that it is
available for as long as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission, provided
you inform other peers where the object code and Corresponding
Source of the work are being offered to the general public at no
charge under subsection 6d.
A separable portion of the object code, whose source code is excluded
from the Corresponding Source as a System Library, need not be
included in conveying the object code work.
A "User Product" is either (1) a "consumer product", which means any
tangible personal property which is normally used for personal, family,
or household purposes, or (2) anything designed or sold for incorporation
into a dwelling. In determining whether a product is a consumer product,
doubtful cases shall be resolved in favor of coverage. For a particular
product received by a particular user, "normally used" refers to a
typical or common use of that class of product, regardless of the status
of the particular user or of the way in which the particular user
actually uses, or expects or is expected to use, the product. A product
is a consumer product regardless of whether the product has substantial
commercial, industrial or non-consumer uses, unless such uses represent
the only significant mode of use of the product.
"Installation Information" for a User Product means any methods,
procedures, authorization keys, or other information required to install
and execute modified versions of a covered work in that User Product from
a modified version of its Corresponding Source. The information must
suffice to ensure that the continued functioning of the modified object
code is in no case prevented or interfered with solely because
modification has been made.
If you convey an object code work under this section in, or with, or
specifically for use in, a User Product, and the conveying occurs as
part of a transaction in which the right of possession and use of the
User Product is transferred to the recipient in perpetuity or for a
fixed term (regardless of how the transaction is characterized), the
Corresponding Source conveyed under this section must be accompanied
by the Installation Information. But this requirement does not apply
if neither you nor any third party retains the ability to install
modified object code on the User Product (for example, the work has
been installed in ROM).
The requirement to provide Installation Information does not include a
requirement to continue to provide support service, warranty, or updates
for a work that has been modified or installed by the recipient, or for
the User Product in which it has been modified or installed. Access to a
network may be denied when the modification itself materially and
adversely affects the operation of the network or violates the rules and
protocols for communication across the network.
Corresponding Source conveyed, and Installation Information provided,
in accord with this section must be in a format that is publicly
documented (and with an implementation available to the public in
source code form), and must require no special password or key for
unpacking, reading or copying.
7. Additional Terms.
"Additional permissions" are terms that supplement the terms of this
License by making exceptions from one or more of its conditions.
Additional permissions that are applicable to the entire Program shall
be treated as though they were included in this License, to the extent
that they are valid under applicable law. If additional permissions
apply only to part of the Program, that part may be used separately
under those permissions, but the entire Program remains governed by
this License without regard to the additional permissions.
When you convey a copy of a covered work, you may at your option
remove any additional permissions from that copy, or from any part of
it. (Additional permissions may be written to require their own
removal in certain cases when you modify the work.) You may place
additional permissions on material, added by you to a covered work,
for which you have or can give appropriate copyright permission.
Notwithstanding any other provision of this License, for material you
add to a covered work, you may (if authorized by the copyright holders of
that material) supplement the terms of this License with terms:
a) Disclaiming warranty or limiting liability differently from the
terms of sections 15 and 16 of this License; or
b) Requiring preservation of specified reasonable legal notices or
author attributions in that material or in the Appropriate Legal
Notices displayed by works containing it; or
c) Prohibiting misrepresentation of the origin of that material, or
requiring that modified versions of such material be marked in
reasonable ways as different from the original version; or
d) Limiting the use for publicity purposes of names of licensors or
authors of the material; or
e) Declining to grant rights under trademark law for use of some
trade names, trademarks, or service marks; or
f) Requiring indemnification of licensors and authors of that
material by anyone who conveys the material (or modified versions of
it) with contractual assumptions of liability to the recipient, for
any liability that these contractual assumptions directly impose on
those licensors and authors.
All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10. If the Program as you
received it, or any part of it, contains a notice stating that it is
governed by this License along with a term that is a further
restriction, you may remove that term. If a license document contains
a further restriction but permits relicensing or conveying under this
License, you may add to a covered work material governed by the terms
of that license document, provided that the further restriction does
not survive such relicensing or conveying.
If you add terms to a covered work in accord with this section, you
must place, in the relevant source files, a statement of the
additional terms that apply to those files, or a notice indicating
where to find the applicable terms.
Additional terms, permissive or non-permissive, may be stated in the
form of a separately written license, or stated as exceptions;
the above requirements apply either way.
8. Termination.
You may not propagate or modify a covered work except as expressly
provided under this License. Any attempt otherwise to propagate or
modify it is void, and will automatically terminate your rights under
this License (including any patent licenses granted under the third
paragraph of section 11).
However, if you cease all violation of this License, then your
license from a particular copyright holder is reinstated (a)
provisionally, unless and until the copyright holder explicitly and
finally terminates your license, and (b) permanently, if the copyright
holder fails to notify you of the violation by some reasonable means
prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is
reinstated permanently if the copyright holder notifies you of the
violation by some reasonable means, this is the first time you have
received notice of violation of this License (for any work) from that
copyright holder, and you cure the violation prior to 30 days after
your receipt of the notice.
Termination of your rights under this section does not terminate the
licenses of parties who have received copies or rights from you under
this License. If your rights have been terminated and not permanently
reinstated, you do not qualify to receive new licenses for the same
material under section 10.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or
run a copy of the Program. Ancillary propagation of a covered work
occurring solely as a consequence of using peer-to-peer transmission
to receive a copy likewise does not require acceptance. However,
nothing other than this License grants you permission to propagate or
modify any covered work. These actions infringe copyright if you do
not accept this License. Therefore, by modifying or propagating a
covered work, you indicate your acceptance of this License to do so.
10. Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically
receives a license from the original licensors, to run, modify and
propagate that work, subject to this License. You are not responsible
for enforcing compliance by third parties with this License.
An "entity transaction" is a transaction transferring control of an
organization, or substantially all assets of one, or subdividing an
organization, or merging organizations. If propagation of a covered
work results from an entity transaction, each party to that
transaction who receives a copy of the work also receives whatever
licenses to the work the party's predecessor in interest had or could
give under the previous paragraph, plus a right to possession of the
Corresponding Source of the work from the predecessor in interest, if
the predecessor has it or can get it with reasonable efforts.
You may not impose any further restrictions on the exercise of the
rights granted or affirmed under this License. For example, you may
not impose a license fee, royalty, or other charge for exercise of
rights granted under this License, and you may not initiate litigation
(including a cross-claim or counterclaim in a lawsuit) alleging that
any patent claim is infringed by making, using, selling, offering for
sale, or importing the Program or any portion of it.
11. Patents.
A "contributor" is a copyright holder who authorizes use under this
License of the Program or a work on which the Program is based. The
work thus licensed is called the contributor's "contributor version".
A contributor's "essential patent claims" are all patent claims
owned or controlled by the contributor, whether already acquired or
hereafter acquired, that would be infringed by some manner, permitted
by this License, of making, using, or selling its contributor version,
but do not include claims that would be infringed only as a
consequence of further modification of the contributor version. For
purposes of this definition, "control" includes the right to grant
patent sublicenses in a manner consistent with the requirements of
this License.
Each contributor grants you a non-exclusive, worldwide, royalty-free
patent license under the contributor's essential patent claims, to
make, use, sell, offer for sale, import and otherwise run, modify and
propagate the contents of its contributor version.
In the following three paragraphs, a "patent license" is any express
agreement or commitment, however denominated, not to enforce a patent
(such as an express permission to practice a patent or covenant not to
sue for patent infringement). To "grant" such a patent license to a
party means to make such an agreement or commitment not to enforce a
patent against the party.
If you convey a covered work, knowingly relying on a patent license,
and the Corresponding Source of the work is not available for anyone
to copy, free of charge and under the terms of this License, through a
publicly available network server or other readily accessible means,
then you must either (1) cause the Corresponding Source to be so
available, or (2) arrange to deprive yourself of the benefit of the
patent license for this particular work, or (3) arrange, in a manner
consistent with the requirements of this License, to extend the patent
license to downstream recipients. "Knowingly relying" means you have
actual knowledge that, but for the patent license, your conveying the
covered work in a country, or your recipient's use of the covered work
in a country, would infringe one or more identifiable patents in that
country that you have reason to believe are valid.
If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.
A patent license is "discriminatory" if it does not include within
the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License. You may not convey a covered
work if you are a party to an arrangement with a third party that is
in the business of distributing software, under which you make payment
to the third party based on the extent of your activity of conveying
the work, and under which the third party grants, to any of the
parties who would receive the covered work from you, a discriminatory
patent license (a) in connection with copies of the covered work
conveyed by you (or copies made from those copies), or (b) primarily
for and in connection with specific products or compilations that
contain the covered work, unless you entered into that arrangement,
or that patent license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as excluding or limiting
any implied license or other defenses to infringement that may
otherwise be available to you under applicable patent law.
12. No Surrender of Others' Freedom.
If conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot convey a
covered work so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you may
not convey it at all. For example, if you agree to terms that obligate you
to collect a royalty for further conveying from those to whom you convey
the Program, the only way you could satisfy both those terms and this
License would be to refrain entirely from conveying the Program.
13. Use with the GNU Affero General Public License.
Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed
under version 3 of the GNU Affero General Public License into a single
combined work, and to convey the resulting work. The terms of this
License will continue to apply to the part which is the covered work,
but the special requirements of the GNU Affero General Public License,
section 13, concerning interaction through a network will apply to the
combination as such.
14. Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of
the GNU General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the
Program specifies that a certain numbered version of the GNU General
Public License "or any later version" applies to it, you have the
option of following the terms and conditions either of that numbered
version or of any later version published by the Free Software
Foundation. If the Program does not specify a version number of the
GNU General Public License, you may choose any version ever published
by the Free Software Foundation.
If the Program specifies that a proxy can decide which future
versions of the GNU General Public License can be used, that proxy's
public statement of acceptance of a version permanently authorizes you
to choose that version for the Program.
Later license versions may give you additional or different
permissions. However, no additional obligations are imposed on any
author or copyright holder as a result of your choosing to follow a
later version.
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided
above cannot be given local legal effect according to their terms,
reviewing courts shall apply local law that most closely approximates
an absolute waiver of all civil liability in connection with the
Program, unless a warranty or assumption of liability accompanies a
copy of the Program in return for a fee.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
state the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <https://www.gnu.org/licenses/>.
Also add information on how to contact you by electronic and paper mail.
If the program does terminal interaction, make it output a short
notice like this when it starts in an interactive mode:
<program> Copyright (C) <year> <name of author>
This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, your program's commands
might be different; for a GUI interface, you would use an "about box".
You should also get your employer (if you work as a programmer) or school,
if any, to sign a "copyright disclaimer" for the program, if necessary.
For more information on this, and how to apply and follow the GNU GPL, see
<https://www.gnu.org/licenses/>.
The GNU General Public License does not permit incorporating your program
into proprietary programs. If your program is a subroutine library, you
may consider it more useful to permit linking proprietary applications with
the library. If this is what you want to do, use the GNU Lesser General
Public License instead of this License. But first, please read
<https://www.gnu.org/licenses/why-not-lgpl.html>.

View file

@ -1,18 +1,61 @@
# GreatAI # <img src="https://raw.githubusercontent.com/schmelczer/great-ai/main/docs/media/logo.png" alt="logo of great-ai" width=60 /> GreatAI
**work in progress, do not use!** > Easily transform your prototype AI code into production-ready software.
[![Test](https://github.com/ScoutinScience/great_ai/actions/workflows/test.yml/badge.svg)](https://github.com/ScoutinScience/great_ai/actions/workflows/check.yml) [![Quality Gate Status](https://sonar.scoutinscience.com/api/project_badges/measure?project=great-ai&metric=alert_status)](https://sonar.scoutinscience.com/dashboard?id=great-ai) [![Publish on PyPI](https://github.com/ScoutinScience/great_ai/actions/workflows/publish.yaml/badge.svg)](https://github.com/ScoutinScience/great_ai/actions/workflows/publish.yaml) [![Publish on DockerHub](https://github.com/ScoutinScience/great_ai/actions/workflows/docker.yaml/badge.svg)](https://github.com/ScoutinScience/great_ai/actions/workflows/docker.yaml) [![PyPI version](https://badge.fury.io/py/great-ai.svg)](https://badge.fury.io/py/great-ai)
[![Downloads](https://pepy.tech/badge/great-ai/month)](https://pepy.tech/project/great-ai)
[![Docker Pulls](https://img.shields.io/docker/pulls/schmelczera/great-ai)](https://hub.docker.com/repository/docker/schmelczera/great-ai)
[![Test](https://github.com/schmelczer/great-ai/actions/workflows/test.yml/badge.svg)](https://github.com/schmelczer/great-ai/actions/workflows/test.yml)
[![Sonar line coverage](https://sonar.scoutinscience.com/api/project_badges/measure?project=great-ai&metric=coverage)](https://sonar.scoutinscience.com/dashboard?id=great-ai)
[![Sonar LoC](https://sonar.scoutinscience.com/api/project_badges/measure?project=great-ai&metric=ncloc)](https://sonar.scoutinscience.com/dashboard?id=great-ai)
Applying AI is becoming increasingly more accessible, but many case studies have shown that these applications are often deployed poorly. This may lead to suboptimal performance and to introducing unintended biases. GreatAI helps fix this by allowing you to easily transform your prototype AI code into production-ready software.
## Find `great-ai` on [DockerHub](https://hub.docker.com/repository/docker/schmelczera/great-ai) ## Example
```sh ```sh
docker run -p6060:6060 schmelczera/great-ai pip install great-ai
``` ```
Find the dashboard at [http://localhost:6060](http://localhost:6060/dashboard/). Create a new file called `demo.py`
```python
from great_ai import GreatAI
@GreatAI.create
def greeter(name: str) -> str:
return f"Hello {name}!"
```
Start it by executing `great-ai demo.py`, and find the dashboard at [http://localhost:6060](http://localhost:6060/dashboard).
![demo screen capture](https://raw.githubusercontent.com/schmelczer/great-ai/main/docs/media/demo.gif)
That's it. Your GreatAI service is _nearly_ ready for production use. Many of the [SE4ML best practices](https://se-ml.github.io) are configured and implemented automatically (of course, these can be customised as well).
[Check out the full documentation here](https://great-ai.scoutinscience.com).
## Why is this GREAT?
![scope of GreatAI](https://raw.githubusercontent.com/schmelczer/great-ai/main/docs/media/scope-simple.drawio.svg)
GreatAI fits between the prototype and deployment phases of your AI development lifecycle. This is highlighted in blue in the diagram. Here, several best practices can be automatically implemented, aiming to achieve the following attributes:
- **G**eneral: use any Python library without restriction
- **R**obust: have error-handling and well-tested utilities out-of-the-box
- **E**nd-to-end: utilise end-to-end feedback as a built-in, first-class concept
- **A**utomated: focus only on what actually requires your attention
- **T**rustworthy: deploy models that you and society can confidently trust
## Why GreatAI?
There are other existing solutions aiming to facilitate this phase. [Amazon SageMaker](https://aws.amazon.com/sagemaker) and [Seldon Core](https://www.seldon.io/solutions/open-source-projects/core) provide the most comprehensive suite of features. If you have the opportunity to use them, do that because they're great.
However, [research indicates](https://great-ai.scoutinscience.com) that professionals rarely use them. This may be due to their inherent setup and operational complexity. **GreatAI is designed to be as simple to use as possible.** Its straightforward, high-level API and sensible default configuration make it easy to start using. Despite its relative simplicity over Seldon Core, it still implements many of the [SE4ML best practices](https://se-ml.github.io), and thus, can meaningfully improve your deployment without requiring prohibitively great effort.
## [Learn more](https://great-ai.scoutinscience.com)
[Check out the full documentation here](https://great-ai.scoutinscience.com).
## Find `great-ai` on [PyPI](https://pypi.org/project/great-ai/) ## Find `great-ai` on [PyPI](https://pypi.org/project/great-ai/)
@ -20,15 +63,41 @@ Find the dashboard at [http://localhost:6060](http://localhost:6060/dashboard/).
pip install great-ai pip install great-ai
``` ```
```python ## Find `great-ai` on [DockerHub](https://hub.docker.com/repository/docker/schmelczera/great-ai)
from great_ai import GreatAI
@GreatAI.create ```sh
def hello_world(name: str) -> str: docker run -p6060:6060 schmelczera/great-ai
return f"Hello {name}!"
``` ```
> Create a new file called `main.py`
Deploy by executing `python3 -m great-ai main.py` ## Contribute
Find the dashboard at [http://localhost:6060](http://localhost:6060/dashboard/). Contributions are welcome.
### Install for development
```sh
python3 -m venv --copies .env
source .env/bin/activate
pip install --upgrade flit pip
flit install --symlink
```
### Develop
```sh
scripts/format-python.sh great_ai docs tests
```
> Format code.
```sh
python3 -m pytest --doctest-modules --asyncio-mode=strict .
```
> Run tests.
```sh
mkdocs serve
```
> Serve documentation.

1
docs/CNAME Normal file
View file

@ -0,0 +1 @@
great-ai.scoutinscience.com

View file

@ -1,16 +0,0 @@
# **S**coutinScience **U**tilitie**S** for text processing [![Lint and test ScoutinScience utilities](https://github.com/ScoutinScience/platform/actions/workflows/sus-general.yaml/badge.svg)](https://github.com/ScoutinScience/platform/actions/workflows/sus-general.yaml)
## Exports
- [clean](src/sus/clean.py)
- [language](src/sus/clean.py)
- [unique](src/sus/unique.py)
- [parallel_map](src/sus/parallel_map.py)
- [evaluate_ranking](src/sus/evaluate_ranking/evaluate_ranking.py)
- [get_sentences](src/sus/get_sentences.py)
## Development
- Optional booleans must have a default value of `False`.
- No imports in top-level `__init__.py`, in order to not load anything unnecessary automatically
- Should only be updated through a PR

View file

@ -0,0 +1,75 @@
# Additional files in the repository
In order to give you a smooth experience while comprehending this example, all non-notebook files are presented on this page in one place. In reality, these files should be in your project's top-level directory.
## config.ini
```ini title="config.ini"
ENVIRONMENT = DEVELOPMENT
ENVIRONMENT = ENV:ENVIRONMENT
MONGO_CONNECTION_STRING=ENV:MONGO_CONNECTION_STRING
MONGO_DATABASE=highlights
AWS_REGION_NAME = eu-west-2
AWS_ACCESS_KEY_ID = MY_DEFAULT_AWS_ACCESS_KEY_ID_FOR_DEVELOPMENT
AWS_SECRET_ACCESS_KEY = MY_DEFAULT_AWS_SECRET_ACCESS_KEY_FOR_DEVELOPMENT
LARGE_FILES_BUCKET_NAME = my-orgs-large-files
AWS_REGION_NAME = ENV:AWS_REGION_NAME
AWS_ACCESS_KEY_ID = ENV:AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY = ENV:AWS_SECRET_ACCESS_KEY
LARGE_FILES_BUCKET_NAME = ENV:LARGE_FILES_BUCKET_NAME
```
> All necessary configuration which is read by [great_ai.utilities.ConfigFile][]. This will resolve values starting with `ENV:` from your environment variables.
## requirements.txt
```requirements.txt title="requirements.txt"
torch==1.12.0
transformers==4.20.1
numpy==1.23.0
```
> Usually, it is recommended to pin (freeze) the library versions on which we depend. This file is referenced by the [Dockerfile](#dockerfile).
## Dockerfile
```Dockerfile title="Dockerfile"
FROM schmelczera/great-ai:v0.1.6
COPY requirements.txt ./
RUN pip install --no-cache-dir --requirement requirements.txt
COPY . ./
RUN large-file --backend s3 --secrets s3.ini --cache scibert-highlights
CMD ["deploy.ipynb"]
```
> This is used by the CD pipeline to create the production deployment of the service.
## .dockerignore
```dockerignore title=".dockerignore"
.cache
.git
data
.gitignore
.env
.vscode
.dockerignore
Dockerfile
.mypy_cache
.gitignore
**/__pycache__
**/.DS_Store
README.md
```
> It is useful not to send, for example, the `.cache` folder used by LargeFile to the docker daemon; this will speed up your local build times substantially.
!!! Note ".gitignore"
A very similar looking `.gitignore` file should also be present.

File diff suppressed because one or more lines are too long

View file

@ -0,0 +1,324 @@
{
"cells": [
{
"cell_type": "markdown",
"metadata": {},
"source": [
"# Create an inference function\n",
"\n",
"Everything is ready to wrap the previously trained model and deploy it. \n",
"\n",
"First, we need to configure the LargeFileBackend, the TracingDatabase and GreatAI."
]
},
{
"cell_type": "code",
"execution_count": 1,
"metadata": {},
"outputs": [
{
"name": "stderr",
"output_type": "stream",
"text": [
"\u001b[38;5;226mThe value of `ENVIRONMENT` contains the \"ENV` prefix but `ENVIRONMENT` is not defined as an environment variable, using the default value defined above (`DEVELOPMENT`)\u001b[0m\n",
"\u001b[38;5;226mEnvironment variable ENVIRONMENT is not set, defaulting to development mode ‼️\u001b[0m\n",
"\u001b[38;5;39mMongoDbDriver has been already configured: skipping initialisation\u001b[0m\n",
"\u001b[38;5;39mLargeFileS3 has been already configured: skipping initialisation\u001b[0m\n",
"\u001b[38;5;39mGreatAI (v0.1.6): configured ✅\u001b[0m\n",
"\u001b[38;5;39m 🔩 tracing_database: MongoDbDriver\u001b[0m\n",
"\u001b[38;5;39m 🔩 large_file_implementation: LargeFileS3\u001b[0m\n",
"\u001b[38;5;39m 🔩 is_production: False\u001b[0m\n",
"\u001b[38;5;39m 🔩 should_log_exception_stack: True\u001b[0m\n",
"\u001b[38;5;39m 🔩 prediction_cache_size: 4096\u001b[0m\n",
"\u001b[38;5;39m 🔩 dashboard_table_size: 100\u001b[0m\n",
"\u001b[38;5;226mYou still need to check whether you follow all best practices before trusting your deployment.\u001b[0m\n",
"\u001b[38;5;226m> Find out more at https://se-ml.github.io/practices\u001b[0m\n"
]
}
],
"source": [
"from great_ai.utilities import ConfigFile\n",
"from great_ai.large_file import LargeFileS3\n",
"from great_ai import configure, MongoDbDriver\n",
"\n",
"configuration = ConfigFile(\"config.ini\")\n",
"\n",
"LargeFileS3.configure_credentials_from_file(configuration)\n",
"MongoDbDriver.configure_credentials_from_file(configuration)\n",
"\n",
"configure(\n",
" dashboard_table_size=100, # traces are small, we can show many\n",
" prediction_cache_size=4096, # predictions are expensive, cache them\n",
")"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"For a pleasant developer experience, we create some typed models that will show up in the automatically generated OpenAPI schema specification and will also provide runtime type validation."
]
},
{
"cell_type": "code",
"execution_count": 2,
"metadata": {},
"outputs": [],
"source": [
"from typing import List\n",
"from pydantic import BaseModel\n",
"\n",
"\n",
"class Attention(BaseModel):\n",
" weight: float\n",
" token: str\n",
"\n",
"\n",
"class EvaluatedSentence(BaseModel):\n",
" score: float\n",
" text: str\n",
" explanation: List[Attention]"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Even though `@use_model` caches the remote files locally and it also handles deserialising objects, we only use it to store a directory. In this case, it gives back a path, the path to that directory. So, we need to load the files from that folder ourselves. In order to only load it once per process, we create a small model loader helper function.\n",
"\n",
"> This is usually not needed, however, when we can outsmart `dill` so for optimisation purposes, we do it."
]
},
{
"cell_type": "code",
"execution_count": 3,
"metadata": {},
"outputs": [
{
"name": "stderr",
"output_type": "stream",
"text": [
"\u001b[38;5;39mLatest version of scibert-highlights is 0 (from versions: 0)\u001b[0m\n",
"\u001b[38;5;39mFile scibert-highlights-0 found in cache\u001b[0m\n"
]
}
],
"source": [
"from great_ai import use_model\n",
"from pathlib import Path\n",
"from typing import Tuple\n",
"from transformers import (\n",
" PreTrainedModel,\n",
" PreTrainedTokenizer,\n",
")\n",
"from transformers import (\n",
" AutoConfig,\n",
" AutoModelForSequenceClassification,\n",
" AutoTokenizer,\n",
")\n",
"\n",
"_tokenizer: PreTrainedTokenizer = None\n",
"_loaded_model: PreTrainedModel = None\n",
"\n",
"\n",
"@use_model(\"scibert-highlights\", version=\"latest\", model_kwarg_name=\"model_path\")\n",
"def get_tokenizer_and_model(\n",
" model_path: Path, original_model: str = \"allenai/scibert_scivocab_uncased\"\n",
") -> Tuple[PreTrainedTokenizer, PreTrainedModel]:\n",
" global _tokenizer, _loaded_model\n",
"\n",
" if _tokenizer is None:\n",
" _tokenizer = AutoTokenizer.from_pretrained(original_model)\n",
"\n",
" if _loaded_model is None:\n",
" config = AutoConfig.from_pretrained(\n",
" model_path, output_hidden_states=True, output_attentions=True\n",
" )\n",
" _loaded_model = AutoModelForSequenceClassification.from_pretrained(\n",
" model_path, config=config\n",
" )\n",
"\n",
" return _tokenizer, _loaded_model"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Finally, implement the inference function."
]
},
{
"cell_type": "code",
"execution_count": 4,
"metadata": {},
"outputs": [],
"source": [
"from great_ai import GreatAI\n",
"from great_ai.utilities import clean\n",
"\n",
"import re\n",
"import numpy as np\n",
"import torch\n",
"from transformers.modeling_outputs import SequenceClassifierOutput\n",
"\n",
"\n",
"@GreatAI.create\n",
"def find_highlights(sentence: str) -> EvaluatedSentence:\n",
" \"\"\"Get the interestingness prediction of the input sentence using SciBERT.\n",
"\n",
" Run the SciBERT model in inference mode and evaluate the sentence.\n",
" Additionally, provide explanation in the form of the last layer's sum attention\n",
" between `[CLS]` and the other tokens.\n",
" \"\"\"\n",
"\n",
" tokenizer, loaded_model = get_tokenizer_and_model()\n",
" sentence = clean(sentence, convert_to_ascii=True, remove_brackets=True)\n",
"\n",
" tensors = tokenizer(sentence, return_tensors=\"pt\", truncation=True, max_length=512)\n",
"\n",
" with torch.inference_mode():\n",
" result: SequenceClassifierOutput = loaded_model(**tensors)\n",
" positive_likelihood = torch.nn.Softmax(dim=1)(result.logits)[0][1]\n",
" tokens = tensors[\"input_ids\"][0]\n",
"\n",
" attentions = np.sum(result.attentions[-1].numpy()[0], axis=0)[0][1:-1]\n",
" # Tuple of `torch.FloatTensor` (one for each layer) of shape\n",
" # `(batch_size, num_heads, sequence_length, sequence_length)`.\n",
"\n",
" explanation = []\n",
"\n",
" token_attentions = list(zip(attentions, tokens[1:-1]))\n",
" for token in re.split(r\"([ .,])\", sentence):\n",
" token = token.strip()\n",
" if not token:\n",
" continue\n",
" bert_tokens = tokenizer(\n",
" token, return_tensors=\"pt\", truncation=True, max_length=512\n",
" )[\"input_ids\"][0][\n",
" 1:-1\n",
" ] # truncation=True needed to fix `RuntimeError: Already borrowed`\n",
" weight = 0\n",
" for t1 in bert_tokens:\n",
" if not token_attentions:\n",
" break\n",
" a, t2 = token_attentions.pop(0)\n",
" assert t1 == t2, sentence\n",
" weight += a\n",
" explanation.append(\n",
" Attention(\n",
" token=token if token in \".,\" else \" \" + token, weight=round(weight, 4)\n",
" )\n",
" )\n",
" if not token_attentions:\n",
" break\n",
"\n",
" return EvaluatedSentence(\n",
" score=positive_likelihood, text=sentence, explanation=explanation\n",
" )"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"A simple test to see everything works. Note that the models list is filled by the `@use_model` call even though it's not on the main inference function."
]
},
{
"cell_type": "code",
"execution_count": 5,
"metadata": {},
"outputs": [
{
"data": {
"text/plain": [
"(Trace[EvaluatedSentence]({'created': '2022-07-16T18:47:29.581701',\n",
" 'exception': None,\n",
" 'feedback': None,\n",
" 'logged_values': { 'arg:sentence:length': 51,\n",
" 'arg:sentence:value': 'Our solution has outperformed the '\n",
" 'state-of-the-art.'},\n",
" 'models': [{'key': 'scibert-highlights', 'version': 0}],\n",
" 'original_execution_time_ms': 7127.2063,\n",
" 'output': { 'explanation': [ {'token': ' Our', 'weight': 0.3993},\n",
" {'token': ' solution', 'weight': 0.3481},\n",
" {'token': ' has', 'weight': 0.2945},\n",
" {'token': ' outperformed', 'weight': 0.4011},\n",
" {'token': ' the', 'weight': 0.1484},\n",
" {'token': ' state-of-the-art', 'weight': 0.5727},\n",
" {'token': '.', 'weight': 7.775}],\n",
" 'score': 0.9991180300712585,\n",
" 'text': 'Our solution has outperformed the state-of-the-art.'},\n",
" 'tags': ['find_highlights', 'online', 'development'],\n",
" 'trace_id': '56e20e94-79df-4793-ae61-d20820ebe2d3'}),\n",
" Trace[EvaluatedSentence]({'created': '2022-07-16T18:47:37.020275',\n",
" 'exception': None,\n",
" 'feedback': None,\n",
" 'logged_values': { 'arg:sentence:length': 36,\n",
" 'arg:sentence:value': 'Their solution did not perform '\n",
" 'well.'},\n",
" 'models': [{'key': 'scibert-highlights', 'version': 0}],\n",
" 'original_execution_time_ms': 170.7057,\n",
" 'output': { 'explanation': [ {'token': ' Their', 'weight': 1.1475},\n",
" {'token': ' solution', 'weight': 0.8205},\n",
" {'token': ' did', 'weight': 0.3254},\n",
" {'token': ' not', 'weight': 0.2921},\n",
" {'token': ' perform', 'weight': 0.4293},\n",
" {'token': ' well', 'weight': 0.2772},\n",
" {'token': '.', 'weight': 4.4723}],\n",
" 'score': 0.12305451184511185,\n",
" 'text': 'Their solution did not perform well.'},\n",
" 'tags': ['find_highlights', 'online', 'development'],\n",
" 'trace_id': '7fcf8271-1738-4025-8305-d5a1e5100aea'}))"
]
},
"execution_count": 5,
"metadata": {},
"output_type": "execute_result"
}
],
"source": [
"if __name__ == \"__main__\":\n",
" find_highlights(\n",
" \"Our solution has outperformed the state-of-the-art.\"\n",
" ), find_highlights(\"Their solution did not perform well.\")"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"In this case, the service is built as a docker image, pushed to our image registry and subsequent rolling update is performed in the production cluster.\n",
"To check out the Dockerimage, go to [the additional files page](/examples/scibert/additional-files)."
]
}
],
"metadata": {
"kernelspec": {
"display_name": "Python 3.10.4 ('.env': venv)",
"language": "python",
"name": "python3"
},
"language_info": {
"codemirror_mode": {
"name": "ipython",
"version": 3
},
"file_extension": ".py",
"mimetype": "text/x-python",
"name": "python",
"nbconvert_exporter": "python",
"pygments_lexer": "ipython3",
"version": "3.10.4"
},
"orig_nbformat": 4,
"vscode": {
"interpreter": {
"hash": "02dd6d3afbfa9fbbe1037d64ad9014965528a1ccad21929d6e72f466389a68ad"
}
}
},
"nbformat": 4,
"nbformat_minor": 2
}

View file

@ -0,0 +1,50 @@
# Summarising scientific publications from a tech-transfer perspective
This is a simplified example illustrating how `great-ai` is used in practice at [ScoutinScience](https://www.scoutinscience.com/){ target=_blank }. The subpages show `great-ai` in action by going over the lifecycle of fine-tuning and deploying a BERT-based software service.
??? note "Propriety data"
The purpose of this example is to show you different ways in which `great-ai` can assist you. The exact NLP task being solved is not central. Stemming from this and from the difficult nature of obtaining appropriate training data, the propriety dataset used for the experiments is not shared.
## Objectives
1. You will see how the [great_ai.utilities](/reference/utilities) can integrate into your Data Science workflow.
2. You will see how [great_ai.large_file](/reference/large-file) can be used to version and store your trained model.
3. You will see how [GreatAI][great_ai.GreatAI] should be used to prepare your model for a robust and responsible deployment.
4. You will see multiple ways of customising your deployment.
## Overview
One of the core features of the ScoutinScience platform is summarising research papers from a tech-transfer perspective. In short, extractive summarisation is preferred using a binary classifier trained on clients' judgement of sentence interestingness. Thus, documents are sentences, and the expected output is a binary label showing whether a sentence is "worthy" of being in the tech-transfer summary. Explaining each decision is imperative since ScoutinScience embraces applying only explainable AI (XAI) methods wherever feasible.
!!! success
You are ready to start the tutorial. Feel free to return to the [summary](#summary) section once you're finished.
<div style="display: flex; justify-content: space-evenly;" markdown>
[:material-database: Examine data](data.ipynb){ .md-button .md-button--primary }
[:fontawesome-solid-chart-simple: Train model](train.ipynb){ .md-button .md-button--primary }
[:material-cloud-tags: Deploy service](deploy.ipynb){ .md-button .md-button--primary }
</div>
## Summary
### [Data notebook](data.ipynb)
We load and analyse the data by calculating inter-rater reliability and checking the feasibility of using an AI-based approach by testing the accuracy of a trivial baseline method.
### [Training notebook](train.ipynb)
We simply fine-tune SciBERT.
After training and evaluating a model, it is exported using [great_ai.save_model][]. For more info, check out [the configuration how-to page](/how-to-guides/configure-service).
### [Deployment notebook](deploy.ipynb)
We customise the GreatAI configuration, create custom caching for the model and implement an inference function that can be hardened by wrapping it in a [GreatAI][great_ai.GreatAI] instance. We also extract the attention weights as a quasi-explanation.
Finally, we test the model's inference function through the GreatAI dashboard. [The only thing left is to deploy the hardened service properly.](/how-to-guides/use-service)
#### [Additional files](additional-files.md)
There are some other files required for deploying the notebook. For example, the config file for S3 and MongoDB or a Dockerfile for building a custom image. These are gathered and shown on a separate page.

View file

@ -0,0 +1,374 @@
{
"cells": [
{
"cell_type": "markdown",
"metadata": {},
"source": [
"# Fine-tune SciBERT\n",
"\n",
"We are planning to do a simple classification task on scientific text. For that, [SciBERT](https://github.com/allenai/scibert) is an ideal model to fine-tune since it has been pretrained of academic publications.\n",
"\n",
"This notebook was updated so that it can run in [Google Colab](https://colab.research.google.com/).\n",
"\n",
"First, we need to install the dependencies."
]
},
{
"cell_type": "code",
"execution_count": 1,
"metadata": {
"executionInfo": {
"elapsed": 2529,
"status": "ok",
"timestamp": 1656596749103,
"user_tz": -120
},
"id": "j7l0nD9hDQbB",
"outputId": "88a9931b-396a-4cf1-c659-8a7b098b3cdd"
},
"outputs": [],
"source": [
"!pip install transformers datasets great-ai > /dev/null"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Load the training data from S3. (We have uploaded this to S3 in the `data` notebook.)"
]
},
{
"cell_type": "code",
"execution_count": 2,
"metadata": {},
"outputs": [
{
"name": "stderr",
"output_type": "stream",
"text": [
"\u001b[38;5;39mLatest version of summary-train-dataset-small is 0 (from versions: 0)\u001b[0m\n",
"\u001b[38;5;39mFile summary-train-dataset-small-0 found in cache\u001b[0m\n"
]
}
],
"source": [
"from great_ai.large_file import LargeFileS3\n",
"import json\n",
"\n",
"LargeFileS3.configure_credentials_from_file(\"config.ini\")\n",
"\n",
"with LargeFileS3(\"summary-train-dataset-small\", encoding=\"utf-8\") as f:\n",
" # splitting training and test data is done later by `datasets`\n",
" X, y = json.load(f)"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Finetune SciBERT, for more info about this step, check out [HuggingFace](https://huggingface.co/docs/transformers/training).\n",
"If you're only here for `great-ai`, feel free to skip the next cell."
]
},
{
"cell_type": "code",
"execution_count": 22,
"metadata": {
"executionInfo": {
"elapsed": 118131,
"status": "ok",
"timestamp": 1656593941974,
"user_tz": -120
},
"id": "AL3etUQ3LtKN",
"outputId": "fe00589f-64dd-4b70-e612-3873b504c00a"
},
"outputs": [
{
"data": {
"application/vnd.jupyter.widget-view+json": {
"model_id": "9c57de70e68a41ecbde5093bd671715a",
"version_major": 2,
"version_minor": 0
},
"text/plain": [
" 0%| | 0/1 [00:00<?, ?ba/s]"
]
},
"metadata": {},
"output_type": "display_data"
},
{
"data": {
"text/html": [
"\n",
" <div>\n",
" \n",
" <progress value='130' max='650' style='width:300px; height:20px; vertical-align: middle;'></progress>\n",
" [130/650 01:43 < 07:01, 1.23 it/s, Epoch 10/50]\n",
" </div>\n",
" <table border=\"1\" class=\"dataframe\">\n",
" <thead>\n",
" <tr style=\"text-align: left;\">\n",
" <th>Epoch</th>\n",
" <th>Training Loss</th>\n",
" <th>Validation Loss</th>\n",
" <th>F1</th>\n",
" </tr>\n",
" </thead>\n",
" <tbody>\n",
" <tr>\n",
" <td>1</td>\n",
" <td>0.586800</td>\n",
" <td>0.512138</td>\n",
" <td>0.719101</td>\n",
" </tr>\n",
" <tr>\n",
" <td>2</td>\n",
" <td>0.411600</td>\n",
" <td>0.416675</td>\n",
" <td>0.849057</td>\n",
" </tr>\n",
" <tr>\n",
" <td>3</td>\n",
" <td>0.245600</td>\n",
" <td>0.417070</td>\n",
" <td>0.864000</td>\n",
" </tr>\n",
" <tr>\n",
" <td>4</td>\n",
" <td>0.147800</td>\n",
" <td>0.575878</td>\n",
" <td>0.852459</td>\n",
" </tr>\n",
" <tr>\n",
" <td>5</td>\n",
" <td>0.056800</td>\n",
" <td>0.474259</td>\n",
" <td>0.896552</td>\n",
" </tr>\n",
" <tr>\n",
" <td>6</td>\n",
" <td>0.022500</td>\n",
" <td>0.754236</td>\n",
" <td>0.843137</td>\n",
" </tr>\n",
" <tr>\n",
" <td>7</td>\n",
" <td>0.001000</td>\n",
" <td>0.857636</td>\n",
" <td>0.834783</td>\n",
" </tr>\n",
" <tr>\n",
" <td>8</td>\n",
" <td>0.000500</td>\n",
" <td>0.920232</td>\n",
" <td>0.869565</td>\n",
" </tr>\n",
" <tr>\n",
" <td>9</td>\n",
" <td>0.000300</td>\n",
" <td>0.970790</td>\n",
" <td>0.877193</td>\n",
" </tr>\n",
" <tr>\n",
" <td>10</td>\n",
" <td>0.000300</td>\n",
" <td>0.948689</td>\n",
" <td>0.862385</td>\n",
" </tr>\n",
" </tbody>\n",
"</table><p>"
],
"text/plain": [
"<IPython.core.display.HTML object>"
]
},
"metadata": {},
"output_type": "display_data"
},
{
"name": "stderr",
"output_type": "stream",
"text": [
"...\n",
"Deleting older checkpoint [models/checkpoint-39] due to args.save_total_limit\n",
"***** Running Evaluation *****\n",
" Num examples = 100\n",
" Batch size = 32\n",
"Saving model checkpoint to models/checkpoint-117\n",
"Configuration saved in models/checkpoint-117/config.json\n",
"Model weights saved in models/checkpoint-117/pytorch_model.bin\n",
"Deleting older checkpoint [models/checkpoint-52] due to args.save_total_limit\n",
"***** Running Evaluation *****\n",
" Num examples = 100\n",
" Batch size = 32\n",
"Saving model checkpoint to models/checkpoint-130\n",
"Configuration saved in models/checkpoint-130/config.json\n",
"Model weights saved in models/checkpoint-130/pytorch_model.bin\n",
"Deleting older checkpoint [models/checkpoint-78] due to args.save_total_limit\n",
"\n",
"\n",
"Training completed. Do not forget to share your model on huggingface.co/models =)\n",
"\n",
"\n",
"Loading best model from models/checkpoint-65 (score: 0.896551724137931).\n"
]
}
],
"source": [
"from transformers import (\n",
" AutoModelForSequenceClassification,\n",
" AutoTokenizer,\n",
" DataCollatorWithPadding,\n",
" Trainer,\n",
" TrainingArguments,\n",
" EarlyStoppingCallback,\n",
")\n",
"from pathlib import Path\n",
"import numpy as np\n",
"from datasets import Dataset, load_metric\n",
"\n",
"MODEL = \"allenai/scibert_scivocab_uncased\"\n",
"BATCH_SIZE = 32\n",
"\n",
"tokenizer = AutoTokenizer.from_pretrained(MODEL)\n",
"model = AutoModelForSequenceClassification.from_pretrained(MODEL, num_labels=2)\n",
"data_collator = DataCollatorWithPadding(tokenizer=tokenizer)\n",
"\n",
"\n",
"def tokenize_function(v):\n",
" return tokenizer(v[\"text\"])\n",
"\n",
"\n",
"dataset = (\n",
" Dataset.from_dict({\"text\": X, \"label\": y})\n",
" .map(lambda v: tokenizer(v[\"text\"], truncation=True), batched=True)\n",
" .remove_columns(\"text\")\n",
" .train_test_split(test_size=0.2, shuffle=True) # test is actually validation\n",
")\n",
"\n",
"f1_score = load_metric(\"f1\")\n",
"\n",
"\n",
"def compute_metrics(p):\n",
" pred, labels = p\n",
" pred = np.argmax(pred, axis=1)\n",
" return f1_score.compute(predictions=pred, references=labels)\n",
"\n",
"\n",
"training_args = TrainingArguments(\n",
" output_dir=Path(\"models\"),\n",
" per_device_train_batch_size=BATCH_SIZE,\n",
" per_device_eval_batch_size=BATCH_SIZE,\n",
" save_total_limit=5,\n",
" num_train_epochs=50,\n",
" save_strategy=\"epoch\",\n",
" evaluation_strategy=\"epoch\",\n",
" logging_strategy=\"epoch\",\n",
" weight_decay=0.01,\n",
" metric_for_best_model=\"f1\",\n",
" load_best_model_at_end=True,\n",
")\n",
"\n",
"result = Trainer(\n",
" model=model,\n",
" args=training_args,\n",
" train_dataset=dataset[\"train\"],\n",
" eval_dataset=dataset[\"test\"],\n",
" data_collator=data_collator,\n",
" compute_metrics=compute_metrics,\n",
" callbacks=[EarlyStoppingCallback(early_stopping_patience=5)],\n",
").train()"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"The best macro F1-score on the test set is **0.89** which is (not surprisingly) substantially more than the SVM achieved. We have a great model, it's time to deploy it. But first, we have to store it in a secure place."
]
},
{
"cell_type": "code",
"execution_count": 44,
"metadata": {
"executionInfo": {
"elapsed": 25368,
"status": "ok",
"timestamp": 1656594537509,
"user": {
"displayName": "Schmelczer András",
"userId": "08401926777942666437"
},
"user_tz": -120
},
"id": "fyNKltdquZSP",
"outputId": "e8c2cbb1-78e1-41a3-b7cf-b0cd573bc45d"
},
"outputs": [
{
"name": "stderr",
"output_type": "stream",
"text": [
"Configuration saved in pretrained/config.json\n",
"Model weights saved in pretrained/pytorch_model.bin\n"
]
},
{
"name": "stdout",
"output_type": "stream",
"text": [
" adding: pretrained/ (stored 0%)\n",
" adding: pretrained/config.json (deflated 49%)\n",
" adding: pretrained/pytorch_model.bin (deflated 7%)\n"
]
}
],
"source": [
"from great_ai import save_model\n",
"\n",
"# save Torch model to local disk\n",
"model.save_pretrained(\"pretrained\")\n",
"\n",
"# upload model from local disk to S3\n",
"# (because the S3 credentials have been already set, `save_model` will use LargeFileS3)\n",
"save_model(\"pretrained\", key=\"scibert-highlights\")"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"Next: [Part 3](/examples/scibert/deploy)"
]
}
],
"metadata": {
"kernelspec": {
"display_name": "Python 3.10.4 ('.env': venv)",
"language": "python",
"name": "python3"
},
"language_info": {
"codemirror_mode": {
"name": "ipython",
"version": 3
},
"file_extension": ".py",
"mimetype": "text/x-python",
"name": "python",
"nbconvert_exporter": "python",
"pygments_lexer": "ipython3",
"version": "3.10.4"
},
"vscode": {
"interpreter": {
"hash": "02dd6d3afbfa9fbbe1037d64ad9014965528a1ccad21929d6e72f466389a68ad"
}
}
},
"nbformat": 4,
"nbformat_minor": 0
}

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.5 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 208 KiB

File diff suppressed because one or more lines are too long

View file

@ -0,0 +1,233 @@
{
"cells": [
{
"cell_type": "markdown",
"metadata": {},
"source": [
"# Simple example: data engineering\n",
"\n",
"Here, we solve a problem similar to the tutorial's but with an explainable Naive Bayes classifier and more best practices. In short, we train a domain classifier on the [semantic scholar dataset](https://api.semanticscholar.org/corpus) by taking full advantage of `great-ai`. Subsequently, we create a production-ready deployment.\n",
"\n",
"![position of this step in the lifecycle](/media/scope-data.svg)\n",
"> The blue boxes show the steps of a typical AI-development lifecycle implemented in this notebook.\n",
"\n",
"Since the true scope of `great-ai` is the phase between proof-of-concept code and production-ready service, it is predominantly used in the [deployment notebook](/examples/simple/deploy). Feel free to skip there, or continue reading if you'd like to see the full picture.\n",
"\n",
"### Extract\n",
"\n",
"This can be achieved by downloading a public dataset (such as in this case), or by having a Data Engineer setup and give us access to the organisation's data.\n",
"\n",
"In this example, we download the semantic scholar dataset from a public S3 bucket."
]
},
{
"cell_type": "code",
"execution_count": 1,
"metadata": {},
"outputs": [],
"source": [
"MAX_CHUNK_COUNT = 4"
]
},
{
"cell_type": "code",
"execution_count": 2,
"metadata": {},
"outputs": [
{
"data": {
"text/plain": [
"'Processing 4 out of the 6002 available chunks'"
]
},
"execution_count": 2,
"metadata": {},
"output_type": "execute_result"
}
],
"source": [
"import urllib.request\n",
"from random import shuffle\n",
"\n",
"manifest = (\n",
" urllib.request.urlopen(\n",
" \"https://s3-us-west-2.amazonaws.com/ai2-s2-research-public/\"\n",
" \"open-corpus/2022-02-01/manifest.txt\"\n",
" )\n",
" .read()\n",
" .decode()\n",
") # a list of available chunks separated by '\\n' characters\n",
"\n",
"lines = manifest.split()\n",
"shuffle(lines)\n",
"chunks = lines[:MAX_CHUNK_COUNT]\n",
"\n",
"f\"\"\"Processing {len(chunks)} out of the {\n",
" len(manifest.split())\n",
"} available chunks\"\"\""
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"### Transform\n",
"\n",
"- Filter out non-English abstracts using `great_ai.utilities.predict_language`\n",
"- Project it to only keep the necessary components (text and labels), clean the textual content using `great_ai.utilities.clean`\n",
"- We will speed up processing using `great_ai.utilities.simple_parallel_map`."
]
},
{
"cell_type": "code",
"execution_count": 3,
"metadata": {},
"outputs": [
{
"name": "stderr",
"output_type": "stream",
"text": [
"100%|██████████| 4/4 [04:22<00:00, 65.51s/it] \n"
]
}
],
"source": [
"from typing import List, Tuple\n",
"import json\n",
"import gzip\n",
"from great_ai.utilities import (\n",
" simple_parallel_map,\n",
" clean,\n",
" is_english,\n",
" predict_language,\n",
" unchunk,\n",
")\n",
"\n",
"\n",
"def preprocess_chunk(chunk_key: str) -> List[Tuple[str, List[str]]]:\n",
" response = urllib.request.urlopen(\n",
" f\"https://s3-us-west-2.amazonaws.com/ai2-s2-research-public/\"\n",
" f\"open-corpus/2022-02-01/{chunk_key}\"\n",
" ) # a gzipped JSON Lines file\n",
"\n",
" decompressed = gzip.decompress(response.read())\n",
" decoded = decompressed.decode()\n",
" chunk = [json.loads(line) for line in decoded.split(\"\\n\") if line]\n",
"\n",
" # Transform\n",
" return [\n",
" (\n",
" clean(\n",
" f'{c[\"title\"]} {c[\"paperAbstract\"]} '\n",
" f'{c[\"journalName\"]} {c[\"venue\"]}',\n",
" convert_to_ascii=True,\n",
" ), # The text is cleaned to remove common artifacts\n",
" c[\"fieldsOfStudy\"],\n",
" ) # Create pairs of `(text, [...domains])`\n",
" for c in chunk\n",
" if (c[\"fieldsOfStudy\"] and is_english(predict_language(c[\"paperAbstract\"])))\n",
" ]\n",
"\n",
"\n",
"preprocessed_data = unchunk(\n",
" simple_parallel_map(preprocess_chunk, chunks, concurrency=4)\n",
")"
]
},
{
"cell_type": "code",
"execution_count": 4,
"metadata": {},
"outputs": [],
"source": [
"X, y = zip(*preprocessed_data) # X is the input, y is the expected output"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"### Load\n",
"\n",
"Upload the dataset (or a part of it) to a central repository using `great_ai.add_ground_truth`. This step automatically tags each data-point with a split label according to the ratios we set. Additional tags can be also given.\n",
"\n",
"#### Production-ready backend\n",
"\n",
"The MongoDB driver is automatically configured if `mongo.ini` exists with the following scheme:\n",
"\n",
"```ini\n",
"mongo_connection_string=mongodb://localhost:27017/\n",
"mongo_database=my_great_ai_db\n",
"```\n",
"> You can install MongoDB from [here](https://www.mongodb.com/docs/manual/installation) or [use it as a service](https://www.mongodb.com/cloud/atlas/register)\n",
"\n",
"Otherwise, TinyDB is used which is just a local JSON file."
]
},
{
"cell_type": "code",
"execution_count": 5,
"metadata": {},
"outputs": [
{
"name": "stderr",
"output_type": "stream",
"text": [
"\u001b[38;5;226mEnvironment variable ENVIRONMENT is not set, defaulting to development mode ‼️\u001b[0m\n",
"\u001b[38;5;226mCannot find credentials files, defaulting to using ParallelTinyDbDriver\u001b[0m\n",
"\u001b[38;5;226mThe selected tracing database (ParallelTinyDbDriver) is not recommended for production\u001b[0m\n",
"\u001b[38;5;226mCannot find credentials files, defaulting to using LargeFileLocal\u001b[0m\n",
"\u001b[38;5;39mGreatAI (v0.1.6): configured ✅\u001b[0m\n",
"\u001b[38;5;39m 🔩 tracing_database: ParallelTinyDbDriver\u001b[0m\n",
"\u001b[38;5;39m 🔩 large_file_implementation: LargeFileLocal\u001b[0m\n",
"\u001b[38;5;39m 🔩 is_production: False\u001b[0m\n",
"\u001b[38;5;39m 🔩 should_log_exception_stack: True\u001b[0m\n",
"\u001b[38;5;39m 🔩 prediction_cache_size: 512\u001b[0m\n",
"\u001b[38;5;39m 🔩 dashboard_table_size: 50\u001b[0m\n",
"\u001b[38;5;226mYou still need to check whether you follow all best practices before trusting your deployment.\u001b[0m\n",
"\u001b[38;5;226m> Find out more at https://se-ml.github.io/practices\u001b[0m\n"
]
}
],
"source": [
"from great_ai import add_ground_truth\n",
"\n",
"add_ground_truth(X, y, train_split_ratio=0.8, test_split_ratio=0.2)"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"### Next: [Part 2](/examples/simple/train)"
]
}
],
"metadata": {
"kernelspec": {
"display_name": "Python 3.10.4 ('.env': venv)",
"language": "python",
"name": "python3"
},
"language_info": {
"codemirror_mode": {
"name": "ipython",
"version": 3
},
"file_extension": ".py",
"mimetype": "text/x-python",
"name": "python",
"nbconvert_exporter": "python",
"pygments_lexer": "ipython3",
"version": "3.10.4"
},
"orig_nbformat": 4,
"vscode": {
"interpreter": {
"hash": "02dd6d3afbfa9fbbe1037d64ad9014965528a1ccad21929d6e72f466389a68ad"
}
}
},
"nbformat": 4,
"nbformat_minor": 2
}

File diff suppressed because one or more lines are too long

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.7 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 792 KiB

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long

11
docs/explanation.md Normal file
View file

@ -0,0 +1,11 @@
# Explanation
A lot more details and discussion about the problem context and approaches of GreatAI, along with its evaluation, can be found in my thesis.
<div style="display: flex; justify-content: center;">
<img src="/media/thesis-frontpage.png" style="height: 500px;" alt="front page"/>
</div>
<div style="display: flex; justify-content: space-evenly;" markdown>
[::fontawesome-solid-graduation-cap: Download](thesis/main.pdf){ .md-button .md-button--primary download="greatai_schmelczer.pdf" }
</div>

View file

@ -1,6 +0,0 @@
from great_ai import GreatAI
@GreatAI.create
def hello_world(name: str) -> str:
return f"Hello {name}!"

View file

@ -0,0 +1,91 @@
# How to call remote GreatAI instances
Microservices architecture (or [SOA](https://en.wikipedia.org/wiki/Service-oriented_architecture)) work well with ML applications. This is because their interfaces are usually very narrow, while the functionality provided is quite comprehensive. Hence, drawing the boundaries of responsibilities is more straightforward in the case of ML services than in the case of more traditional business applications. For this reason, it is common to have a tree of models (preferably wrapped in GreatAI instances) communicating with each other.
Although regular HTTP POST requests could be sent to each service's `/predict` endpoint, `great-ai` comes with two convenience functions: [call_remote_great_ai][great_ai.call_remote_great_ai] and [call_remote_great_ai_async][great_ai.call_remote_great_ai_async] to wrap this request. These provide you with some level of robustness and deserialisation.
!!! note "Inside notebooks"
The async variant, [call_remote_great_ai_async][great_ai.call_remote_great_ai_async], requires a running event loop while the synchronous variant disallows other running event-loops. Therefore, when running inside a Jupyter Notebook, always call [call_remote_great_ai_async][great_ai.call_remote_great_ai_async].
## Simple example
Let's create two processes: a server and a client.
### Server
```python title="server.py"
from great_ai import GreatAI
from asyncio import sleep
@GreatAI.create
async def slow_greeter(your_name):
await sleep(2)
return f'Hi {your_name}!'
```
> Run this in development mode by executing `great-ai server.py` or `python3 -m great_ai server.py` if you're on Windows and [`great-ai` is not in your `PATH`](/how-to-guides/install).
### Client
```python title="client.py"
from great_ai import call_remote_great_ai
names = ['Olivér', 'Balázs', 'András']
results = [
call_remote_great_ai(
'http://localhost:6060',
{
'your_name': name
}
).output #(1)
for name in names
]
print(results)
```
1. Only return the outputs, so we don't clutter up the terminal.
> Run this script as a regular Python script by executing `python3 client.py`.
![screenshot of result](/media/remote-sync.png){ loading=lazy }
As you can see, everything worked as expected. There is one way to improve it, though.
## An `async` example
Let's send multiple requests simultaneously to speed up the overall execution time. To do this, we will use the [call_remote_great_ai_async][great_ai.call_remote_great_ai_async] function.
??? note "Why is this possible?"
Note that in `server.py`, the inference function is declared `async`. This means that multiple "copies" of it can run at the same time in the same thread. Since there is no CPU bottleneck, the server has a quite large throughput (requests responded to per second), but its latency will stay around 2 seconds due to the async `sleep` command.
If your great-ai server is not `async`, higher throughput can be achieved by running multiple instances of it, either manually or by running it with multiple `uvicorn` workers like this: `ENVIRONMENT=production great-ai server.py --worker_count 4`
### Async client
```python title="async-client.py"
from great_ai import call_remote_great_ai_async
import asyncio
names = ['Olivér', 'Balázs', 'András']
async def main():
futures = [
call_remote_great_ai_async(
'http://localhost:6060',
{
'your_name': name
}
) for name in names
]
results = await asyncio.gather(*futures)
print([r.output for r in results])
asyncio.run(main())
```
> Replace `client.py` with this async client. Note that although async support is significantly more streamlined in recent Python versions, it still requires a bit more boilerplate than its synchronous counterpart.
![screenshot of result](/media/remote-async.png){ loading=lazy }
This also works and might be considerably quicker in some use cases.

View file

@ -0,0 +1,102 @@
# How to configure GreatAI
GreatAI aims to provide reasonable defaults wherever possible. The current configuration is always prominently displayed (and updated) on the dashboard and in the command-line start-up banner.
## Using [great_ai.configure][]
You can override any of the default settings by calling [great_ai.configure][]. If you don't call `configure`, the default settings are applied on the first call to most `great-ai` functions.
!!! warning
You must call [great_ai.configure][] before calling (or decorating with) any other `great-ai` function. However, importing other functions before calling [great_ai.configure][] is permitted.
```python title="configure-demo.py"
from great_ai import configure, RouteConfig
import logging
configure(
version='1.0.0',
log_level=logging.INFO,
seed=2,
should_log_exception_stack=False,
prediction_cache_size=0, #(1)
disable_se4ml_banner=True,
dashboard_table_size=200,
route_config=RouteConfig( #(2)
feedback_endpoints_enabled=False,
dashboard_enabled=False
)
)
```
1. Completely disable caching.
2. The unspecified routes are enabled by default.
## Using remote storage
The only aspect that cannot be automated is choosing the backing storage for the database and file storage.
Right now, you have 3 options for storing the models and large datasets: [LargeFileLocal][great_ai.large_file.LargeFileLocal], [LargeFileMongo][great_ai.large_file.LargeFileMongo], and [LargeFileS3][great_ai.large_file.LargeFileS3].
Without explicit configuration, [LargeFileLocal][great_ai.large_file.LargeFileLocal] is selected by default. This one still version-controls your files but it only stores them in a local path (which of course can be a remote volume attached by [NFS](https://en.wikipedia.org/wiki/Network_File_System){ target=_blank }, [HDFS](https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html){ target=_blank }, etc.).
!!! important
If your working directory contains a `mongo.ini` or `s3.ini` file, an attempt is made to auto-configure [LargeFileMongo][great_ai.large_file.LargeFileMongo] or [LargeFileS3][great_ai.large_file.LargeFileS3] respectively.
To use [LargeFileMongo][great_ai.large_file.LargeFileMongo] or [LargeFileS3][great_ai.large_file.LargeFileS3] explicitly, configure them before calling any other `great-ai` function.
### S3-compatible
```toml title="s3.ini"
aws_region_name = eu-west-2
aws_access_key_id = MY_AWS_ACCESS_KEY # ENV:MY_AWS_ACCESS_KEY would also work
aws_secret_access_key = MY_AWS_SECRET_KEY
large_files_bucket_name = bucket-for-models
```
```python title="use-s3.py"
from great_ai.large_file import LargeFileS3
from great_ai import save_model
LargeFileS3.configure_credentials_from_file('s3.ini') #(1)
model = [4, 3]
save_model(model, 'my-model')
```
1. This line isn't strictly necessary because if `s3.ini` (or `mongo.ini`) is available in the current working directory, they are automatically used to configure their respective LargeFile implementations/databases.
??? note "Departing from AWS"
With the `aws_endpoint_url` argument, it is possible to use any other S3-compatible service such as [Backblaze](https://www.backblaze.com/){ target=_blank }. In that case, it would be `aws_endpoint_url=https://s3.us-west-002.backblazeb2.com`.
### GridFS
[GridFS](https://www.mongodb.com/docs/manual/core/gridfs/#:~:text=GridFS%20is%20a%20specification%20for,chunk%20as%20a%20separate%20document.){ target=_blank } specifies how to store files in MongoDB. The official MongoDB server and many compatible implementations support it.
```toml title="mongo.ini"
MONGO_CONNECTION_STRING=mongodb://localhost:27017 # this is the default value
# if `MONGO_CONNECTION_STRING` is specified, this default is overridden
MONGO_CONNECTION_STRING=ENV:MONGO_CONNECTION_STRING
MONGO_DATABASE=my-database # it is automatically created if it doesn't exist
```
```python title="use-mongo.py"
from great_ai.large_file import LargeFileMongo
from great_ai import save_model
LargeFileMongo.configure_credentials_from_file('mongo.ini')
model = [4, 3]
save_model(model, 'my-model')
```
!!! note "Simplifying config files"
You can combine `mongo.ini` or `s3.ini` with your application's config file because the unneeded keys are ignored by the `configure_credentials_from_file` method.
## Using a database
By default, a thread-safe version of [TinyDB](https://tinydb.readthedocs.io/en/latest/){ target=_blank } is utilised for saving the prediction traces into a local file. Unfortunately, for most production needs, this method is not suitable.
### MongoDB
Currently, only MongoDB is supported as a production-ready `TracingDatabase`. In order to use it, you have to either place a file named `mongo.ini` in your working directory or explicitly call either [MongoDbDriver.configure_credentials_from_file][great_ai.MongoDbDriver] or [MongoDbDriver.configure_credentials][great_ai.MongoDbDriver.configure_credentials].

View file

@ -0,0 +1,120 @@
# How to create a GreatAI service
The core value of `great-ai` lies in its [GreatAI][great_ai.GreatAI] class. To take advantage of it, you need to create an instance wrapping your code.
Let's say that you have the following greeter function:
```python title="greeter.py"
def my_greeter_function(your_name):
return f'Hi {your_name}!'
```
You can simply decorate (wrap) this function using the [@GreatAI.create][great_ai.GreatAI.create] factory.
```python title="greeter.py"
from great_ai import GreatAI
@GreatAI.create
def greeter(your_name):
return f'Hi {your_name}!'
```
??? info "Why not simply use `@GreatAI?`"
The purpose of [@GreatAI.create][great_ai.GreatAI.create] is simply to provide you with type-checking through MyPy, Pylance, and similar libraries. However, the overloading support for `__new__` is lacking in MyPy. Thus, a static factory method is used instead.
## With types
Even though it's not required by GreatAI, [type annotating your codebase](https://realpython.com/python-type-checking/){ target=_blank } can save you from lots of trivial mistakes; that's why it's highly advised. Simply add the expected types to your function's signature.
```python title="type_safe_greeter.py"
from great_ai import GreatAI
@GreatAI.create
def type_safe_greeter(your_name: str) -> str:
return f'Hi {your_name}!'
```
This not only allows you to statically type-check your code, but by default, GreatAI will check it during runtime as well using [typeguard](https://github.com/agronholm/typeguard){ target=_blank }.
## With async
Asynchronous code can result in immense performance gains in some instances. For example, you might rely on a third-party service, do database access, or [call a remote GreatAI instance](/how-to-guides/call-remote). In these cases, you can make your function `async` without any other changes.
```python title="async_greeter.py"
from great_ai import GreatAI
from asyncio import sleep
@GreatAI.create
async def async_greeter(your_name: str) -> str:
await sleep(2) # simulate IO-bound operation
return f'Hi {your_name}!'
```
## With decorators
GreatAI can decorate already decorated functions. The only restriction is that [@GreatAI.create][great_ai.GreatAI.create] must come last. There are two built-in decorators that you can use to customise your function, but you can use any third-party decorator as well.
### Using `@use_model`
If you have previously saved a model with [save_model][great_ai.save_model], you can inject it into your function by calling [@use_model][great_ai.use_model].
```python title="greeter_with_model.py"
from great_ai import GreatAI, use_model
@GreatAI.create
@use_model('name_of_my_model', version='latest') #(1)
def type_safe_greeter(your_name: str, model) -> str:
return f'Hi {your_name}!'
assert type_safe_greeter('Andras').output == 'Hi Andras'
```
1. By default, the parameter named `model` will be replaced by the loaded model. This behaviour can be customised by setting the `model_kwarg_name`. This way, even multiple models can be injected into a single function.
!!! important
You must call [@use_model][great_ai.use_model] before [@GreatAI.create][great_ai.GreatAI.create]. Note that decorators are applied starting from the bottom-most one. Feel free to use [@use_model][great_ai.use_model] in other places of the codebase, and it works equally well outside GreatAI services.
### Using `@parameter`
If you wish to turn off logging or specify custom validation for your parameters, you can use the [@parameter][great_ai.parameter] decorator.
!!! note
By default, all parameters that are not affected by an explicit [@parameter][great_ai.parameter] or [@use_model][great_ai.use_model] are automatically decorated with [@parameter][great_ai.parameter] when [@GreatAI.create][great_ai.GreatAI.create] is called.
```python title="greeter_with_validation.py"
from great_ai import GreatAI, use_model
@GreatAI.create
@parameter('your_name', disable_logging=True)
def type_safe_greeter(your_name: str, model) -> str:
return f'Hi {your_name}!'
assert type_safe_greeter('Andras').output == 'Hi Andras'
```
!!! important
You must call [@parameter][great_ai.parameter] before [@GreatAI.create][great_ai.GreatAI.create]. Note that decorators are applied starting from the bottom-most one. Feel free to use [@parameter][great_ai.parameter] in other places of the codebase, and it works equally well outside GreatAI services.
## Complex example
The following example summarises the options you have when instantiating a GreatAI service.
```python title="complex.py"
from great_ai import save_model, GreatAI, parameter, use_model, log_metric
save_model(4, 'secret-number') #(1)
@GreatAI.create
@parameter('positive_number', validate=lambda n: n > 0, disable_logging=True)
@use_model('secret-number', version='latest', model_kwarg_name='secret')
def add_number(positive_number: int, secret: int) -> int:
log_metric(
'log directly into the returned Trace',
positive_number * 2
)
return positive_number + secret
assert add_number(1).output == 5
```
1. Refer to [the configuration page](/how-to-guides/configure-service) for specifying where to store your models.

View file

@ -0,0 +1,69 @@
# How to manage training data
In order to simplify your training data management, `great-ai` provide two complementing approaches for inputting new data points.
## Upload data
At the start of your experiments' first iteration, after you've gathered suitable samples for training, you can call [great_ai.add_ground_truth][]. This automatically stores a timestamp and also allows you to assign tags to the data. Using these attributes, [great_ai.query_ground_truth][] can be called to get a filtered view of the training data.
!!! important "Train-test-validation splits"
It is a best practice to lock away the test split of your data that is only used for the final quality assessment. This prevents you from accidentally training on it or inadvertently tuning the model to have the highest accuracy metrics on the test split. This, of course, may lead to dubious results; hence, care must be taken to avoid it.
With [great_ai.add_ground_truth][], there is an option to tag the samples with `train`, `test`, and `validation` randomly, following a predefined distribution. This happens as soon as they're written in the database. Later, these can be queried by providing the name of the appropriate tags.
The nice thing about this is that the 'input-expected output' pairs are stored as traces. Thus, they behave exactly like regular prediction traces.
```python
from great_ai import add_ground_truth
add_ground_truth(
[1, 2],
['odd', 'even'],
tags='my_tag',
train_split_ratio=1, #(1)
test_split_ratio=1
)
```
1. Note that the ratios don't have to add up to 1. They are just weights. There is also a `validation_split_ratio` which is 0 by default.
```python
>>> from great_ai import query_ground_truth
>>> query_ground_truth('my_tag')
[Trace[str]({'created': '2022-07-12T18:36:12.825706',
'exception': None,
'feedback': 'odd', #(1)
'logged_values': {'input': 1}, #(2)
'models': [],
'original_execution_time_ms': 0.0,
'output': 'odd',
'tags': ['ground_truth', 'test', 'my_tag'], #(3)
'trace_id': '4fcf2ce6-a172-469d-94b2-874577655814'}),
Trace[str]({'created': '2022-07-12T18:36:12.825706',
'exception': None,
'feedback': 'even',
'logged_values': {'input': 2},
'models': [],
'original_execution_time_ms': 0.0,
'output': 'even',
'tags': ['ground_truth', 'train', 'my_tag'],
'trace_id': 'abee0671-beb9-4284-8c3b-c65e5836ce38'})]
```
1. Expected output. This can also be accessed through the `.output` property.
2. The input value is stored here.
3. Notice how `ground_truth` is always included as a tag when using [great_ai.add_ground_truth][].
## Get feedback
After the initial data gathering, end-to-end feedback can also be integrated into the dataset.
The scaffolded REST API contains endpoints for managing traces and their feedbacks.
![screenshot of swagger](/media/feedback.png){ loading=lazy }
When [great_ai.query_ground_truth][] is executed, it implicitly filters for traces that have feedback. Therefore, both the `ground_truth` and the `online` traces that have received feedback are returned. No matter the origin of the data, it can be accessed using the same API.
## Remove clutter
Traces can be deleted either through the REST API or by calling [great_ai.delete_ground_truth][]. The latter provides the same interface as [great_ai.query_ground_truth][] except it deletes the matched points.

View file

@ -0,0 +1,53 @@
# Installation guide
Provided you already have [Python3](https://www.python.org/downloads/){ target=_blank } (and pip) installed, simply execute:
```sh
pip install great-ai
```
> Python 3.7 or later is required.
This will work on all major operating systems.
## Google Colab
In order to use GreatAI in [Google Colab](https://colab.research.google.com){ target=_blank }, you need to downgrade `pyyaml` to a Colab compatible version. [See related StackOverflow question](https://stackoverflow.com/questions/69564817/typeerror-load-missing-1-required-positional-argument-loader-in-google-col){ target=_blank }.
```sh
pip install great-ai pyyaml==5.4.1
```
> This will make GreatAI work in Colab.
## Command-line tools
After installation, `great-ai` and `large-file` are available as commands. The former is required for deploying your application, while the latter lets you manage models and datasets from your terminal.
??? note "Snakes & kebabs"
The library is called `great-ai`; therefore, its command-line entry point is also called `great-ai`. However, Python module names cannot contain hyphens, that's why you have to `import great_ai` with an underscore. The `great-ai` CLI tool is also available as `python3 -m great_ai`.
To help with the confusion, a CLI executable called `great_ai` (and `large_file`) are also installed. Thus, if you prefer, you can always refer to GreatAI using its underscored name variant (`great_ai`).
!!! warning "Windows"
On Windows, you might encounter a similar warning from `pip`:
> `WARNING: The scripts great-ai.exe, great_ai.exe, large-file.exe and large_file.exe are installed in 'C:\Users\...\Scripts', which is not on PATH.`
> `Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.`
This means that `great-ai.exe` and `large-file.exe` are not in your `PATH`. Either add their containing directory ('C:\Users\...\Scripts' in this case) to your `PATH` or use `python3 -m great_ai` and `python3 -m great_ai.large_file` instead of the exe-s.
## Update
If you wish to update to the latest version, execute:
```sh
pip install --upgrade great-ai
```
## Bleeding edge
You can also install the latest (usually unreleased) version from GitHub.
```sh
pip install --upgrade git+https://github.com/schmelczer/great-ai.git
```
> Python 3.7 or later is required.

View file

@ -0,0 +1,114 @@
# How to use LargeFiles
The functions [save_model][great_ai.use_model] and [@use_model][great_ai.use_model] wrap LargeFile instances. Hence, besides configuring [LargeFile](/reference/large-file), users have few reasons to use LargeFiles directly.
## Motivation
Often, especially when working with data-heavy applications, large files can proliferate in a repository. Version controlling them is an obvious next step. However, GitHub's git LFS implementation [doesn't support deleting](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) large files, making it easy for them to eat-up the LFS quota and explode the size of your repos.
[DVC](https://dvc.org/) is a viable alternative; however, it requires users to learn to use one more CLI tool.
??? note "Using LargeFile-s directly (usually not needed)"
LargeFile doesn't require users to learn too much new. It is a nearly exact copy of Python's built-in `open()` function, with which users are undoubtedly already familiar.
## Simple example
```python
from great_ai.large_file import LargeFileS3
LargeFileS3.configure_credentials({
"aws_region_name": "your_region_like_eu-west-2",
"aws_access_key_id": "YOUR_ACCESS_KEY_ID",
"aws_secret_access_key": "YOUR_VERY_SECRET_ACCESS_KEY",
"large_files_bucket_name": "create_a_bucket_and_put_its_name_here",
})
# Creates a new version and deletes the older version
# leaving the three most recently used intact
with LargeFileS3("test.txt", "w", keep_last_n=3) as f:
for i in range(100000):
f.write('test\n')
# The latest version is returned by default
# but an optional `version` keyword argument can be provided as well
with LargeFileS3("test.txt", "r") as f: #(1)
print(f.readlines()[0])
```
1. The latest version is already in the local cache; no download is required.
### More details
`LargeFile` behaves like an opened file (in the background, it is a temp file after all). Binary reads and writes are supported along with the [different keywords `open()` accepts](https://docs.python.org/3/library/functions.html#open){ target=_blank }.
The local cache can be configured with these properties:
```python
LargeFileS3.cache_path = Path('.cache')
LargeFileS3.max_cache_size = "30 GB"
```
#### I only need a path
In case you only need a path to the (proxy of the) remote file, this pattern can be applied:
```python
path_to_model = LargeFileS3("folder-of-my-bert-model", version=31).get()
```
> This will first download the file/folder into your local cache folder. Then, it returns a `Path` object to the local version. Which can be turned into a string with `str(path_to_model)`.
The same approach works for uploads:
```python
LargeFileS3("folder-of-my-bert-model").push('path_to_local/folder_or_file')
```
> This way, both regular files and folders can be handled. The uploaded file is called **folder-of-my-bert-model**, the local name is ignored.
Lastly, all version of the remote object can be deleted by calling `LargeFileS3("my-file").delete()`. It will still reside in your local cache afterwards; its deletion will happen next time your local cache has to be pruned.
## From the command-line
The main reason for using the `large-file` or `python3 -m great_ai.large_file` commands is to upload or download models from the terminal. For example, when building a docker image, it is best practice to cache the referred models.
### Setup
Create an .ini file (or use *~/.aws/credentials*). It may look like this:
```ini
aws_region_name = your_region_like_eu-west-2
aws_access_key_id = YOUR_ACCESS_KEY_ID
aws_secret_access_key = YOUR_VERY_SECRET_ACCESS_KEY
large_files_bucket_name = my_large_files
```
### Upload some files
```sh
large-file --backend s3 --secrets secrets.ini \
--push my_first_file.json folder/my_second_file my_folder
```
> Only the filename is used as the S3 name; the rest of the path is ignored.
!!! important "Using MongoDB"
The possible values for `--backend` are `s3`, `mongo`, and `local`. The latter doesn't need credentials. It only versions and stores your files in a local folder. MongoDB, on the other hand, requires a `mongo_connection_string` and a `mongo_database` to be specified. For storing large files, it uses the [GridFS](https://www.mongodb.com/docs/manual/core/gridfs){ target=_blank } specification.
### Download some files to the local cache
This can be useful when building a Docker image, for example. This way, the files can already reside inside the container and need not be downloaded later.
```sh
large-file --backend s3 --secrets ~/.aws/credentials \
--cache my_first_file.json:3 my_second_file my_folder:0
```
> Versions may be specified by using `:`-s.
### Delete remote files
```sh
large-file --backend s3 --secrets ~/.aws/credentials \
--delete my_first_file.json
```

View file

@ -0,0 +1,131 @@
# How to perform prediction with GreatAI
After [creating a GreatAI service](/how-to-guides/create-service) by wrapping your prediction function, and optionally [configuring it](/how-to-guides/configure-service), it's time to do some prediction.
Let's take the following example:
```python title="greeter.py"
from great_ai import GreatAI
@GreatAI.create
def greeter(your_name: str) -> str:
return f'Hi {your_name}!'
```
## One-off prediction
Even though `greeter` is now an instance of [GreatAI][great_ai.GreatAI], you can continue using it as a regular function.
```python
>>> greeter('Bob')
Trace[str]({'created': '2022-07-11T14:31:46.183764',
'exception': None,
'feedback': None,
'logged_values': {'arg:your_name:length': 3, 'arg:your_name:value': 'Bob'},
'models': [],
'original_execution_time_ms': 0.0381,
'output': 'Hi Bob!',
'tags': ['greeter', 'online', 'development'],
'trace_id': '7c284fd7-7f0d-4464-b5f8-3ef126df34af'})
```
As you can see, the original return value is wrapped in a [Trace][great_ai.Trace] object (which is also persisted in your database of choice). You can access the original value under the `output` property.
## Online prediction
Likely, the main way you would like to expose your model is through an HTTP API. [@GreatAI.create][great_ai.GreatAI.create] scaffolds many REST API endpoints for your model and creates a [FastAPI](https://fastapi.tiangolo.com/){ target=_blank } app available under [GreatAI.app][great_ai.GreatAI]. This can be served using [uvicorn](https://www.uvicorn.org/){ target=_blank } or any other [ASGI server](https://asgi.readthedocs.io/en/latest/){ target=_blank }.
Since most ML code lives in [Jupyter](https://jupyter.org/){ target=_blank } notebooks, therefore, deploying a notebook containing the inference function is supported. To achieve this, `uvicorn` is wrapped by the `great-ai` command-line utility, which &mdash; among others &mdash; takes care of feeding a notebook into `uvicorn`. It also supports auto-reloading.
### In development
```sh
great-ai greeter.py
```
!!! success
Your model is accessible at [localhost:6060](http:/127.0.0.1:6060){ target=_blank }.
Some configuration options are also supported.
```sh
great-ai greeter.py --port 8000 --host 127.0.0.1 --timeout_keep_alive 10
```
??? note "More options"
For more options (but no Notebook support), simply use [uvicorn](https://www.uvicorn.org/){ target=_blank } for starting your app (available at `greeter.app`).
### In production
There are three main approaches for deploying a GreatAI service.
#### Manual deployment
The app is run in *production-mode* if the value of the `ENVIRONMENT` environment variable is set to `production`.
```sh
ENVIRONMENT=production great-ai greeter.py
```
Simply run `ENVIRONMENT=production great-ai deploy.ipynb` in the command-line of a production machine.
> This is the crudest approach; however, it might be fitting for some contexts.
#### Containerised deployment
Run the notebook directly in a container or create a service for it using your favourite container orchestrator.
```sh
docker run -p 6060:6060 --volume `pwd`:/app --rm \
schmelczera/great-ai deploy.ipynb
```
> You can replace ``pwd`` with the path to your code's folder.
#### Use a Platform-as-a-Service
Similar to the previous approach, your code will run in a container. However, instead of manually managing it, you can just choose from a plethora of PaaS providers (such as [AWS ECS](https://aws.amazon.com/ecs/){ target=_blank }, [DO App platform](https://www.digitalocean.com/products/app-platform){ target=_blank }, [MLEM](https://mlem.ai/){ target=_blank }, [Streamlit](https://streamlit.io/){ target=_blank }) that take a Docker image as a source and handle the rest of the deployment.
To this end, you can also create a custom Docker image. It is especially useful if you have third-party dependencies, such as [PyTorch](https://pytorch.org/){ target=_blank } or [TensorFlow](https://www.tensorflow.org/){ target=_blank }.
```Dockerfile
FROM schmelczera/great-ai:latest
# Remove this block if you don't have a requirements.txt
COPY requirements.txt ./
RUN pip install --no-cache-dir --requirement requirements.txt
# If you store your models in S3 or GridFS, it may be a
# good idea to cache them in the image so that you don't
# have to download it each time a container starts
RUN large-file --backend s3 --secrets s3.ini --cache my-domain-predictor
# Add your application code to the image
COPY . .
# The default ENTRYPOINT is great-ai; specify its argument using CMD
CMD ["deploy.ipynb"]
```
## Batch prediction
Processing larger amounts of data on a single machine is made easy by the [GreatAI][great_ai.GreatAI]'s [process_batch][great_ai.GreatAI.process_batch] method. This relies on multiprocessing ([parallel_map][great_ai.utilities.parallel_map.parallel_map.parallel_map]) to take full advantage of all available CPU-cores.
```python
>>> greeter.process_batch(['Alice', 'Bob'])
[Trace[str]({'created': '2022-07-11T14:36:37.119183',
'exception': None,
'feedback': None,
'logged_values': {'arg:your_name:length': 5, 'arg:your_name:value': 'Alice'},
'models': [],
'original_execution_time_ms': 0.1251,
'output': 'Hi Alice!',
'tags': ['greeter', 'online', 'development'],
'trace_id': '90ffa15f-e839-41c4-8e7a-3211168bc138'}),
Trace[str]({'created': '2022-07-11T14:36:37.166659',
'exception': None,
'feedback': None,
'logged_values': {'arg:your_name:length': 3, 'arg:your_name:value': 'Bob'},
'models': [],
'original_execution_time_ms': 0.0571,
'output': 'Hi Bob!',
'tags': ['greeter', 'online', 'development'],
'trace_id': 'f48e94c7-0815-48b3-a864-41349d3dae84'})]
```

File diff suppressed because one or more lines are too long

119
docs/index.md Normal file
View file

@ -0,0 +1,119 @@
<div style="display: flex; justify-content: space-between; align-items: center;">
<h1 style="margin: 0">Overview of GreatAI</h1>
<img src="media/logo.png" width=80>
</div>
[![PyPI version](https://badge.fury.io/py/great-ai.svg)](https://badge.fury.io/py/great-ai)
[![Downloads](https://pepy.tech/badge/great-ai/month)](https://pepy.tech/project/great-ai)
[![Docker Pulls](https://img.shields.io/docker/pulls/schmelczera/great-ai)](https://hub.docker.com/repository/docker/schmelczera/great-ai)
[![Test](https://github.com/schmelczer/great-ai/actions/workflows/test.yml/badge.svg)](https://github.com/schmelczer/great-ai/actions/workflows/test.yml)
[![Sonar line coverage](https://sonar.scoutinscience.com/api/project_badges/measure?project=great-ai&metric=coverage)](https://sonar.scoutinscience.com/dashboard?id=great-ai)
[![Sonar LoC](https://sonar.scoutinscience.com/api/project_badges/measure?project=great-ai&metric=ncloc)](https://sonar.scoutinscience.com/dashboard?id=great-ai)
Applying AI is becoming increasingly easier, but many case studies have shown that these applications are often deployed poorly. This may lead to suboptimal performance and to introducing [unintended biases](https://en.wikipedia.org/wiki/Weapons_of_Math_Destruction){ target=_blank }. GreatAI helps fix this by allowing you to ==easily transform your prototype AI code into production-ready software==.
??? quote "Case studies"
"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."
&mdash; [John et al.](https://ieeexplore.ieee.org/abstract/document/9359253){ target=_blank }
"Finally, we have found that existing tools to aid Machine Learning development do not address the specificities of different projects, and thus, are seldom adopted by teams." &mdash; [Haakman et al.](https://link.springer.com/article/10.1007/s10664-021-09993-1){ target=_blank }
"Because a mature system might end up being (at most) 5% machine learning code and (at least) 95% glue code, it may be less costly to create a clean native solution rather than re-use a generic package." &mdash; [Sculley et al.](https://www.researchgate.net/profile/Todd-Phillips/publication/319769912_Hidden_Technical_Debt_in_Machine_Learning_Systems/links/61e716d68d338833e37a7fd6/Hidden-Technical-Debt-in-Machine-Learning-Systems.pdf){ target=_blank }
"For example, practice 25 is very important for "Traceability", yet relatively weakly adopted. We expect that the results from this type of analysis can, in the future, provide useful guidance for practitioners in terms of aiding them to assess their rate of adoption for each practice and to create roadmaps for improving their processes. &mdash; [Serban et al.](https://dl.acm.org/doi/abs/10.1145/3382494.3410681?casa_token=uCFz0dtDR6gAAAAA:4_8OMJ-5njwopYkB1KSGAu9JfbNq4nfa8LRE0fj84ckjfo-GgtcYQivZTGxal3M4haoA8r_xwpw){ target=_blank }
## Features
- [x] Save prediction traces of each prediction, including arguments and model versions
- [x] Save feedback and merge it into a ground-truth database
- [x] Version and store models and data on shared infrastructure *(MongoDB GridFS, S3-compatible storage, shared volume)*
- [x] Automatically scaffolded custom REST API (and OpenAPI schema) for easy integration
- [x] Input validation
- [x] Sensible cache-policy
- [x] Graceful error handling
- [x] Seamless support for both synchronous and asynchronous inference methods
- [x] Easy integration with remote GreatAI instances
- [x] Built-in parallelisation (with support for multiprocessing, async, and mixed modes) for batch processing
- [x] Well-tested utilities for common NLP tasks (cleaning, language-tagging, sentence-segmentation, etc.)
- [x] A simple, unified configuration interface
- [x] Fully-typed API for [Pylance](https://github.com/microsoft/pylance-release){ target=_blank } and [MyPy](http://mypy-lang.org){ target=_blank } support
- [x] Auto-reload for development
- [x] Docker support for deployment
- [x] Deployable Jupyter Notebooks
- [x] Dashboard for online monitoring and analysing traces
- [x] Active support for Python 3.7, 3.8, 3.9, and 3.10
## Roadmap
- [ ] Prometheus & Grafana integration
- [ ] Well-tested feature extraction code for non-NLP data
- [ ] Support for direct file input
- [ ] Support for PostgreSQL
## Hello world
```sh
pip install great-ai
```
```python title="demo.py"
from great_ai import GreatAI
@GreatAI.create #(1)
def greeter(name: str) -> str: #(2)
return f"Hello {name}!"
```
1. `@GreatAI.create` wraps your `greeter` function with a `GreatAI` instance. The function will behave very similarly but:
1. its return value becomes a `Trace[str]`,
2. it gets a `process_batch` method for supporting parallel execution,
3. and it can be deployed using the `great-ai` command-line tool.
2. [Typing functions](https://docs.python.org/3/library/typing.html){ target=_blank } is recommended in general, however, not required for GreatAI to work.
??? note
In practice, `greeter` could be an inference function of some AI/ML application. But it could also just wrap a black-box solution of some SaaS. Either way, it is [imperative to have continuous oversight](https://digital-strategy.ec.europa.eu/en/library/ethics-guidelines-trustworthy-ai){ target=_blank } of the services you provide and the data you process, especially in the context of AI/ML applications.
```sh title="terminal"
great-ai demo.py
```
> Navigate to [localhost:6060](http://127.0.0.1:6060) in your browser.
![demo screen capture](media/demo.gif){ loading=lazy }
!!! success
Your GreatAI service is ready for production use. Many of the [SE4ML best practices](https://se-ml.github.io){ target=_blank } are configured and implemented automatically. To have full control over your service and to understand what else you might need to do in your use case, continue reading this documentation.
## Why is this GREAT?
![scope of GreatAI](media/scope-simple.drawio.svg)
GreatAI fits between the prototype and deployment phases of your (or your organisation's) AI development lifecycle. This is highlighted in blue in the diagram. Here, several best practices can be automatically implemented, aiming to achieve the following attributes:
- **G**eneral: use any Python library without restriction
- **R**obust: have error-handling and well-tested utilities out-of-the-box
- **E**nd-to-end: utilise end-to-end feedback as a built-in, first-class concept
- **A**utomated: focus only on what actually requires your attention
- **T**rustworthy: deploy models that you and society can confidently trust
## Why GreatAI?
There are other existing solutions aiming to facilitate this phase. [Amazon SageMaker](https://aws.amazon.com/sagemaker){ target=_blank } and [Seldon Core](https://www.seldon.io/solutions/open-source-projects/core){ target=_blank } provide the most comprehensive suite of features. If you have the opportunity to use them, do that because they're great.
However, research indicates that professionals rarely use them. This may be due to their inherent setup and operational complexity. ==GreatAI is designed to be as simple to use as possible.== Its straightforward, high-level API and sensible default configuration make it extremely easy to start using. Despite its relative simplicity over Seldon Core, it still implements many of the [SE4ML best practices](https://se-ml.github.io){ target=_blank }, and thus, can meaningfully improve your deployment without requiring prohibitively great effort.
<div style="display: flex; justify-content: space-evenly; flex-wrap: wrap;" markdown>
[:fontawesome-brands-python: Find it on PyPI](https://pypi.org/project/great-ai){ .md-button .md-button--primary }
[:fontawesome-brands-docker: Find it on DockerHub](https://hub.docker.com/repository/docker/schmelczera/great-ai){ .md-button .md-button--primary }
[:fontawesome-solid-laptop-code: Check out the tutorial](/tutorial){ .md-button .md-button--primary }
</div>
## Production use
GreatAI has been battle-tested on the core platform services of [ScoutinScience](https://www.scoutinscience.com/){ target=_blank }.
[![ScoutinScience logo](media/scoutinscience.svg#only-light){ loading=lazy }
![ScoutinScience logo](media/scoutinscience-white.svg#only-dark){ loading=lazy }](https://www.scoutinscience.com/){ target=_blank }

BIN
docs/media/annotator.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 920 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 82 KiB

BIN
docs/media/demo.gif Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.5 MiB

BIN
docs/media/demo.mp4 Normal file

Binary file not shown.

Binary file not shown.

After

Width:  |  Height:  |  Size: 77 KiB

BIN
docs/media/favicon.ico Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

BIN
docs/media/feedback.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 46 KiB

BIN
docs/media/logo.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 84 KiB

BIN
docs/media/og-image.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 112 KiB

BIN
docs/media/remote-async.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 160 KiB

BIN
docs/media/remote-sync.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 154 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 41 KiB

View file

@ -1,4 +1,4 @@
<svg host="65bd71144e" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="1181px" height="281px" viewBox="-0.5 -0.5 1181 281" content="&lt;mxfile&gt;&lt;diagram id=&quot;ccudx8biEBM-x_P_p45R&quot; name=&quot;Page-1&quot;&gt;1VrbcuI4EP0aqpIHUr5gA49sYGa3KqlJFbs1k0fZFkYV2/JIIsH79duy5bsJBhySzUMstaS2pD59uiUzMu/D/XeG4u0j9XAwMjRvPzKXI8MwdMuAh5QkmcSaK4HPiJeJ9FKwJv9iJdSUdEc8zGsdBaWBIHFd6NIowq6oyRBj9K3ebUOD+ltj5OOWYO2ioC39STyxzaQzY1rK/8TE3+Zv1u151hKivLNaCd8ij75VROZqZN4zSkVWCvf3OJCbl+9LNu7bgdZiYgxHos8ANWMuknxt2IOlqmpEI3j8sRVhADUdihsaCWUPfQL19vvUFDjdMVepVMYViPlY9ZpkIvmyyjA1x++YhliwBDowHCBBXuv7jpT5/KJfuUIoqEV2L1jN5RUFO6V0ZNiBUEurbYX9e0fzhjFPF72ADvok3peNUPLl84nhmFEXc449iWwkUK4YppTpznq2dhwwEMuimwQk8jAzodPblgi8jlG6hW/gRXUzOHQHPb0HpxAg98VnUvpjJ0ANVnKubGW9Z6tXzATev2sH1WrO7WyIclwzx/Fb6QY6vCyVbasuoGmX284+EaywTpb8goqWV55l5c7Kq8t9tXGZVGtPmBGYIWZKeBbyzTbyjc9CvnkQ+U4JzSFcYZliX0Pu7x3hRBAaHfSEQtyagsNyyY3St4p8wDVYJfJvD/oQ2AMFAQ6oz1AIg+OKFWttFfMec7YN2eM8COnD+JE+0+p+ZHb4Ud6n6kezAdxodg3On7SRb30W8ifXQv5qHweUoQzyYCkbhRJL2f82sosOkcPlI1SJkrMjgQcwH8Rt1i7BkYs/12U2JAjuKexN+mpTd5CODbWrFfkm/ZNhSzD6gistmmavFt+GcT7LagSxLuezP8j5dPNKQazptR7iW+zlSvdE/CrVQO250lJqlJWkUmkGxV5UYLWpYD40FaRDF4yhpNIhpiQSvKL5SQpKIMyMOgtPZlrDlJnG0rDF1HrZ2vqgXPNvhiASyjQzZQze5JEu7tEgOxVUJODyMMFog5lkhfSM5OGvlql+KbqYTqbHc97JR+W8+uTr8oV2Nb7ID/4DE0aLEaZ2gxGMhgmzeapR1XN1Q5Gl1xVZzdiRra6l6FIKM+xhKUy3j+dOSwxZT5I6BPiDhCqKPMS84wkPZT6KCE8TJiRfCzPbUo/3y3BOJlOji0ybc7pZJ3zhhQQyONgd7UfMs8ISv0L59lSqvEp21TdBP+GAok+OJ0kFOQ2dJBWscO4RpZO88nKFDw+T17lXB+eSnj7vYD37Oqw3s+okMm0Grt6s1zjW2no/1juDmDov8hqYkWlG6tn0ATk4x0p/7ygukJGTq9S6DaBGzZts3Ok0HSeLQbxmfpyq/+Ey5UPydLr4C/55KXWHODVim2HXCK3hrU/pQ7smK988PqweM+JdvLwQmhWxcO9u29nu/5GRC/wep+QcTB15ZyeY7CHSTu09MF1wcIn4hrIwvdyAY4igx5MEOLh4O1emCGOGkSd3hGP2SlzcD5AApSxwfxE8GJfi4Sr2v/SS8PLrhiICl0H3udp2UQQuosWREPwxFxWtwDmeWt3Z1qkReKw3FPU8d5wTgbs+KJyMmfzQ7uEN2gUlcTd2/ALrXeGCWT8cei+76VkwQTbIFWkqEjokyohTbGUYz6+L1bFLxvKEqljuYC7GMYOhwJP81BB5/S+RJ9Bf/iuC6V0d6vOOaxnro65liu/3p1/LnEhnfb5FnsOvPb1Ka3uVPjgpHth1qJa/hMgYqvw9ibn6Dw==&lt;/diagram&gt;&lt;/mxfile&gt;"> <svg host="65bd71144e" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="1181px" height="281px" viewBox="-0.5 -0.5 1181 281" content="&lt;mxfile&gt;&lt;diagram id=&quot;ccudx8biEBM-x_P_p45R&quot; name=&quot;Page-1&quot;&gt;3VrbcuI4EP0aqpKHpHzBBh7ZwMxuVVKTKnZrJo+yJUAV2/JIIsH79duy5bsJ5jqZ5QFLLaktqfucbgkG9kO4/cpRvH5imAQDy8DbgT0bWJZpWSN4KEmSScYjLVhxinWnUrCg/xItNLR0QzERtY6SsUDSuC70WRQRX9ZkiHP2Xu+2ZEH9rTFakZZg4aOgLf1OsVzrVeTLUvI/CV2t8zeb7iRrCVHeWa9ErBFm7xWRPR/YD5wxmZXC7QMJ1Obl+5KN+7KjtZgYJ5HsM0DPWMgkXxvBsFRdjVgEjz/WMgygZkJxySKp7WEOod5+n56CYBvua5WWNhHiK6J7DTORelllmJ7jV8JCInkCHTgJkKRv9X1H2nyrol+5QijoRXYvWM/lDQUbrXRguYHUS6tthftzw/KGO5EuegodzGG8LRuhtFLPZ05iznwiBMHKs5FEuWKYUqY769nacfCBWBX9JKARJtyGTu9rKskiRukWvgOK6mbw2AZ64kevECD/dcWV9NtGghqi5ULbyvnIVm+ES7L90A661Z642RANXDv34/cSBia8LJWtqxAwjNNt5x7orLBOnvyAipFXXlTl3smrs221cZZUa8+EU5gh4Vp4lOfbbc+3fpXn2zs93ytd8xxQmKW+byD/54YKKimLdiKhELem4PFccqP1zaMV+DVYJVrd7sQQ2AMFAQnYiqMQBscVK9baKubdB7Yl3ZI8CJnnwZE5Nuo4sjtwlPep4mh8BhiNr8H5w7bnO7/K84fX8vz5Ng4YR5nLg6VcFCpfyr7bnl10iDyhHqFOlLwNDTC4+Vlgs/ApiXzy20PGcRqhpwsy7oUgY9pXCj1NrGEk1gTnSrdU/ijVQO2l0lJqVJWkUmmGsl4AdtoAnpwbwOnQKecoqXSIGY2kqGh+VoLSEcZWnTuHY6Nhykxjadhiar1s7VwoQ/ybI4hfKjlMcS6a6O9iDANySslkAkCFCUZLwhWW05MNJv/D/HI0HO3PL4eXyi/N4edFuXE1lOeH7DPDvIXjkdvAsdUwYTZPPap6hm0ocsy6IqfJ+NnqWopOJR7LPS/xmO7+PGVGIMNIUkAAHpSroggjjvcnF4yvUERFmpwg9VqY2Zph0S+bOJgCrS4KbM7pZpGIKQ4pZEuwO8a3WGSFGXmD8u2hBHeNTKZ3MnzAYcAc7k9tCnI6d2pTsMKxx4FO8srLFT7cTV7HHtOPJT1z0sF67nVYb+zUSWTUDFy9Wa9xhHTNfqx3BDF1Xpo1fEYlBymy2SPySO4r/dFRXNYiL1dpdBtAj5o02bgTNB3ngbOgZrKfqv8RKlFD6iQ4/Qu+cErdIUmN2GbYBUILeOtz+jCuyco3T4/zp4x4p6+vlGVFIv3723aO+jsycuG/+yk5d6aOvLPTmdxzpJ3GR850wnEjEkvGw/QiAQ4Pku1PEuC4gTe+ShHuOEFY7Ygg/I36pJ9DgitlgfuT+IOVtgfBAwsYT6dimx4yiaX7VeTL9KOONJKzV1JpMQx3Pv1yqmddxZNOvdo7/bqhiOVl+H6ptp0Uy4u4syeYX+aiohWC70ZOd952aCy/MxuKep5gjonlXT8DHOwzOTowWaJNID+XsXqjZXcQP+2mZ8olXSJfpklN6NEoo2C5VglBfsmrD3AqK0iYzgo8IuRdzGEoMK44NNhe+n7nkxCpbrVG93XQTDquipxLXRUVv98fflV0IDH2+S3yGKbuCVijDVjzWoiFavlPiIzryv+T2PP/AA==&lt;/diagram&gt;&lt;/mxfile&gt;">
<defs/> <defs/>
<g> <g>
<path d="M 331 140 L 379.63 140" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/> <path d="M 331 140 L 379.63 140" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/>
@ -18,7 +18,7 @@
</div> </div>
</div> </div>
</foreignObject> </foreignObject>
<text x="274" y="156" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="12px" text-anchor="middle"> <text x="274" y="157" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="12px" text-anchor="middle">
Preprocessed data Preprocessed data
</text> </text>
</switch> </switch>
@ -50,13 +50,13 @@
</g> </g>
<path d="M 526 140 L 560.63 140" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/> <path d="M 526 140 L 560.63 140" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/>
<path d="M 565.88 140 L 558.88 143.5 L 560.63 140 L 558.88 136.5 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/> <path d="M 565.88 140 L 558.88 143.5 L 560.63 140 L 558.88 136.5 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/>
<path d="M 376 180 L 396 100 L 536 100 L 516 180 Z" fill="#1ba1e2" stroke="#006eaf" stroke-miterlimit="10" pointer-events="all"/> <path d="M 376 180 L 396 100 L 536 100 L 516 180 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/>
<g transform="translate(-0.5 -0.5)"> <g transform="translate(-0.5 -0.5)">
<switch> <switch>
<foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"> <foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;">
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 140px; margin-left: 377px;"> <div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 140px; margin-left: 377px;">
<div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"> <div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;">
<div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"> <div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">
<b> <b>
<font style="font-size: 14px"> <font style="font-size: 14px">
Exploration &amp; Exploration &amp;
@ -70,21 +70,21 @@
</div> </div>
</div> </div>
</foreignObject> </foreignObject>
<text x="456" y="144" fill="#ffffff" font-family="Helvetica" font-size="12px" text-anchor="middle"> <text x="456" y="144" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="12px" text-anchor="middle">
Exploration &amp;... Exploration &amp;...
</text> </text>
</switch> </switch>
</g> </g>
<path d="M 639.5 190 L 639.92 240 Q 640 250 650 250 L 743.63 250" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" stroke-dasharray="3 3" pointer-events="stroke"/> <path d="M 639.5 190 L 639.92 240 Q 640 250 650 250 L 743.63 250" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" stroke-dasharray="3 3" pointer-events="stroke"/>
<path d="M 748.88 250 L 741.88 253.5 L 743.63 250 L 741.88 246.5 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/> <path d="M 748.88 250 L 741.88 253.5 L 743.63 250 L 741.88 246.5 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/>
<path d="M 567 105 C 567 96.72 599.46 90 639.5 90 C 658.73 90 677.17 91.58 690.77 94.39 C 704.36 97.21 712 101.02 712 105 L 712 175 C 712 183.28 679.54 190 639.5 190 C 599.46 190 567 183.28 567 175 Z" fill="#1ba1e2" stroke="#006eaf" stroke-miterlimit="10" pointer-events="all"/> <path d="M 567 105 C 567 96.72 599.46 90 639.5 90 C 658.73 90 677.17 91.58 690.77 94.39 C 704.36 97.21 712 101.02 712 105 L 712 175 C 712 183.28 679.54 190 639.5 190 C 599.46 190 567 183.28 567 175 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/>
<path d="M 712 105 C 712 113.28 679.54 120 639.5 120 C 599.46 120 567 113.28 567 105" fill="none" stroke="#006eaf" stroke-miterlimit="10" pointer-events="all"/> <path d="M 712 105 C 712 113.28 679.54 120 639.5 120 C 599.46 120 567 113.28 567 105" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/>
<g transform="translate(-0.5 -0.5)"> <g transform="translate(-0.5 -0.5)">
<switch> <switch>
<foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"> <foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;">
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 143px; height: 1px; padding-top: 153px; margin-left: 568px;"> <div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 143px; height: 1px; padding-top: 153px; margin-left: 568px;">
<div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"> <div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;">
<div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"> <div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">
<font style="font-size: 14px"> <font style="font-size: 14px">
Trained models  &amp; prototype inference code Trained models  &amp; prototype inference code
</font> </font>
@ -92,7 +92,7 @@
</div> </div>
</div> </div>
</foreignObject> </foreignObject>
<text x="640" y="156" fill="#ffffff" font-family="Helvetica" font-size="12px" text-anchor="middle"> <text x="640" y="157" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="12px" text-anchor="middle">
Trained models  &amp; protot... Trained models  &amp; protot...
</text> </text>
</switch> </switch>
@ -151,13 +151,13 @@
</text> </text>
</switch> </switch>
</g> </g>
<path d="M 740 60 L 760 0 L 950 0 L 930 60 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="none"/> <path d="M 740 60 L 760 0 L 950 0 L 930 60 Z" fill="#1ba1e2" stroke="#006eaf" stroke-miterlimit="10" pointer-events="none"/>
<g transform="translate(-0.5 -0.5)"> <g transform="translate(-0.5 -0.5)">
<switch> <switch>
<foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"> <foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;">
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 208px; height: 1px; padding-top: 30px; margin-left: 741px;"> <div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 208px; height: 1px; padding-top: 30px; margin-left: 741px;">
<div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"> <div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;">
<div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: none; white-space: normal; overflow-wrap: normal;"> <div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: none; white-space: normal; overflow-wrap: normal;">
<b style="font-size: 14px"> <b style="font-size: 14px">
Transforming into Transforming into
<br/> <br/>
@ -169,7 +169,7 @@
</div> </div>
</div> </div>
</foreignObject> </foreignObject>
<text x="845" y="34" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="12px" text-anchor="middle"> <text x="845" y="34" fill="#ffffff" font-family="Helvetica" font-size="12px" text-anchor="middle">
Transforming into... Transforming into...
</text> </text>
</switch> </switch>
@ -178,22 +178,22 @@
<path d="M 845 218.88 L 841.5 211.88 L 845 213.63 L 848.5 211.88 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="none"/> <path d="M 845 218.88 L 841.5 211.88 L 845 213.63 L 848.5 211.88 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="none"/>
<path d="M 845 190 L 845 213.63" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="none"/> <path d="M 845 190 L 845 213.63" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="none"/>
<path d="M 845 218.88 L 841.5 211.88 L 845 213.63 L 848.5 211.88 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="none"/> <path d="M 845 218.88 L 841.5 211.88 L 845 213.63 L 848.5 211.88 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="none"/>
<path d="M 767.5 105 C 767.5 96.72 802.2 90 845 90 C 865.55 90 885.27 91.58 899.8 94.39 C 914.33 97.21 922.5 101.02 922.5 105 L 922.5 175 C 922.5 183.28 887.8 190 845 190 C 802.2 190 767.5 183.28 767.5 175 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="none"/> <path d="M 767.5 105 C 767.5 96.72 802.2 90 845 90 C 865.55 90 885.27 91.58 899.8 94.39 C 914.33 97.21 922.5 101.02 922.5 105 L 922.5 175 C 922.5 183.28 887.8 190 845 190 C 802.2 190 767.5 183.28 767.5 175 Z" fill="#1ba1e2" stroke="#006eaf" stroke-miterlimit="10" pointer-events="none"/>
<path d="M 922.5 105 C 922.5 113.28 887.8 120 845 120 C 802.2 120 767.5 113.28 767.5 105" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="none"/> <path d="M 922.5 105 C 922.5 113.28 887.8 120 845 120 C 802.2 120 767.5 113.28 767.5 105" fill="none" stroke="#006eaf" stroke-miterlimit="10" pointer-events="none"/>
<g transform="translate(-0.5 -0.5)"> <g transform="translate(-0.5 -0.5)">
<switch> <switch>
<foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"> <foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;">
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 153px; height: 1px; padding-top: 153px; margin-left: 769px;"> <div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 153px; height: 1px; padding-top: 153px; margin-left: 769px;">
<div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"> <div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;">
<div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: none; white-space: normal; overflow-wrap: normal;"> <div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: none; white-space: normal; overflow-wrap: normal;">
<font style="font-size: 14px"> <font style="font-size: 14px">
Artifact combining the model with deplyoment best-practices Artifact combining the model with deplyoment best practices
</font> </font>
</div> </div>
</div> </div>
</div> </div>
</foreignObject> </foreignObject>
<text x="845" y="156" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="12px" text-anchor="middle"> <text x="845" y="157" fill="#ffffff" font-family="Helvetica" font-size="12px" text-anchor="middle">
Artifact combining the mod... Artifact combining the mod...
</text> </text>
</switch> </switch>

Before

Width:  |  Height:  |  Size: 19 KiB

After

Width:  |  Height:  |  Size: 19 KiB

Before After
Before After

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 14 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 14 KiB

View file

@ -0,0 +1,125 @@
<svg host="65bd71144e" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="1161px" height="96px" viewBox="-0.5 -0.5 1161 96" content="&lt;mxfile&gt;&lt;diagram id=&quot;ccudx8biEBM-x_P_p45R&quot; name=&quot;Page-1&quot;&gt;3VhLc9owEP41zKSHZPwAA8cESHpoppmhM02Owl5sTWXJkQWY/vqubAnbvJJS8phywNrVev2t9tuV7I4/Sos7SbLkXkTAOp4TFR1/3PE81/P6eNGadaUZ9I0iljQyRrViSn+DUTpGu6AR5C1DJQRTNGsrQ8E5hKqlI1KKVdtsLlj7qRmJYUcxDQnb1f6kkUpMFDYsrf8KNE7sk91gWM2kxBqbSPKERGLVUPmTjj+SQqhqlBYjYHrx7LpU990emN0Ak8DVa24wiHO1trFBhKEakQuOl5tEpQwlF4dzwZXJh9tFGQqqHs2cHj/h2LnqGWmsM+5YYW2EXYwGdi4WMjQwfJNWImMwVt1KpQE2bjNx3YFIQck1GkhgRNFlO1fEpDze2G1ufRAUgXiOoaffc66Gjd+gcmCoGjhtfxVm46JeaBw0MNWqcvn3p8JEvCRsYaB3vIBh7DczHMSqXLlKobPQylrwvBB24jIv83ONBu4gK+pJ62VMFNERhM8LmlNFBbd+EWLluv04VO9AmMmTQfX2gbowqCY8phxAUh5/OQhri7JYRJkeIqUIY8BELEmKhhm6wQSA3J57qCduVglVMM1ISbwV9qstwtMCbAdyj5F3CVJBcZSYlmBOi1EDI67qTrJhWdLoIsPeYSa3aHeEY4N/LXeOD3y0Ra2FRsFrsa74Uvqrku/ulrxt+G9d871B/2iVV5jOUeXdg1W+r/Jmp1f5eXrFpMiYkKRqErgoAUl1gVT/e3tBNcVnub6kZuufLSiLsKQ/UaOZhhR4CIebzP/Zez6w+bjBsR3u5N0MkKHrMgSMQLshPCIyepmcQsaE07wkN9FAMaJERPl7snEb08V0nV9HKcVqw/V0xrD8jmfacrwLQUh9hi7jT6FEMSVk+im3ze2N5AxUHn4klZ23oPIPSXg+FzItO6WDm414mcWZFNEi1By+lEAivUA5yCXFxLxnV73/hkT99NTzynnGRgJ3tRKK786IC56xa+jn5Q/1uZLiFzRmHCeYXN+eh8TBB5LYnkXe/TR4+kvj1jnwxSOlrdPWmTJ4myNkL2hlsv+6F8UdP33XOern5KMoivV3hcq8/jrjT/4A&lt;/diagram&gt;&lt;/mxfile&gt;">
<defs/>
<g>
<path d="M 250 47.5 L 303.63 47.5" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/>
<path d="M 308.88 47.5 L 301.88 51 L 303.63 47.5 L 301.88 44 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/>
<path d="M 0 95 L 20 0 L 260 0 L 240 95 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/>
<g transform="translate(-0.5 -0.5)">
<switch>
<foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;">
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 258px; height: 1px; padding-top: 48px; margin-left: 1px;">
<div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;">
<div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">
<b>
<font style="font-size: 18px">
Data acquisition
</font>
</b>
<br/>
<font style="font-size: 15px">
(Data Engineering)
</font>
</div>
</div>
</div>
</foreignObject>
<text x="130" y="51" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="12px" text-anchor="middle">
Data acquisition...
</text>
</switch>
</g>
<path d="M 550 47.5 L 603.63 47.5" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/>
<path d="M 608.88 47.5 L 601.88 51 L 603.63 47.5 L 601.88 44 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/>
<path d="M 300 95 L 320 0 L 560 0 L 540 95 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/>
<g transform="translate(-0.5 -0.5)">
<switch>
<foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;">
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 258px; height: 1px; padding-top: 48px; margin-left: 301px;">
<div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;">
<div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">
<font>
<b style="font-size: 18px">
<font style="font-size: 18px">
Exploration &amp;
<br/>
model building
</font>
</b>
<br/>
<font style="font-size: 15px">
(Data Science)
</font>
</font>
</div>
</div>
</div>
</foreignObject>
<text x="430" y="51" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="12px" text-anchor="middle">
Exploration &amp;...
</text>
</switch>
</g>
<path d="M 900 95 L 920 0 L 1160 0 L 1140 95 Z" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/>
<g transform="translate(-0.5 -0.5)">
<switch>
<foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;">
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 258px; height: 1px; padding-top: 48px; margin-left: 901px;">
<div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;">
<div style="display: inline-block; font-size: 14px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">
<b style="font-size: 18px">
Deploy with standard
<br/>
organisational methods
</b>
<br/>
<font style="font-size: 15px">
(SysAdmin, DevOps,
<br/>
or deployment SaaS)
</font>
</div>
</div>
</div>
</foreignObject>
<text x="1030" y="52" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="14px" text-anchor="middle">
Deploy with standard...
</text>
</switch>
</g>
<path d="M 600 95 L 620 0 L 860 0 L 840 95 Z" fill="#1ba1e2" stroke="#006eaf" stroke-miterlimit="10" pointer-events="all"/>
<g transform="translate(-0.5 -0.5)">
<switch>
<foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;">
<div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 258px; height: 1px; padding-top: 48px; margin-left: 601px;">
<div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;">
<div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">
<b style="font-size: 18px">
Transforming into
<br/>
production-ready service
</b>
<br/>
<font style="font-size: 15px">
(MLOps)
</font>
</div>
</div>
</div>
</foreignObject>
<text x="730" y="51" fill="#ffffff" font-family="Helvetica" font-size="12px" text-anchor="middle">
Transforming into...
</text>
</switch>
</g>
<path d="M 850 47.5 L 903.63 47.5" fill="none" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="stroke"/>
<path d="M 908.88 47.5 L 901.88 51 L 903.63 47.5 L 901.88 44 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-miterlimit="10" pointer-events="all"/>
</g>
<switch>
<g requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"/>
<a transform="translate(0,-5)" xlink:href="https://www.diagrams.net/doc/faq/svg-export-text-problems" target="_blank">
<text text-anchor="middle" font-size="10px" x="50%" y="100%">
Viewer does not support full SVG 1.1
</text>
</a>
</switch>
</svg>

After

Width:  |  Height:  |  Size: 9.8 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 14 KiB

1
docs/media/scope.svg Normal file

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 14 KiB

View file

@ -0,0 +1,122 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 26.2.1, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
<svg version="1.1" id="Group_805" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="0 0 369.5 67.2" style="enable-background:new 0 0 369.5 67.2;" xml:space="preserve" fill="white">
<style type="text/css">
.st0{clip-path:url(#SVGID_00000084499246685778113730000005394386986623376315_);fill:#14C9C0;}
.st1{clip-path:url(#SVGID_00000084499246685778113730000005394386986623376315_);fill:#ffffff;}
</style>
<g>
<defs>
<rect id="SVGID_1_" width="369.5" height="67.2" />
</defs>
<clipPath id="SVGID_00000094609971218746498830000013677106623865950620_">
<use xlink:href="#SVGID_1_" style="overflow:visible;" />
</clipPath>
<path id="Path_549" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#14C9C0;" d="
M14.4,22.4l6.1-0.5c-0.3-2.3-1.7-4.4-3.7-5.6c-2-1.2-4.4-1.8-6.8-1.6c-2.4,0-4.6,0.8-6.5,2.2c-1.9,1.4-3,3.6-2.9,5.9
c-0.1,2.2,1,4.3,2.9,5.5c2,1.2,4.2,2.1,6.5,2.7c3.4,1.1,5.1,2.1,5.1,3.2c0,1-0.5,1.9-1.4,2.4c-0.9,0.6-1.9,0.9-3,0.8
c-1.1,0.1-2.1-0.2-3.1-0.7c-0.9-0.4-1.4-1.3-1.5-2.3L0,34.7c0.1,2.4,1.5,4.6,3.6,5.8c2.2,1.3,4.7,2,7.3,1.9c2.5,0,5-0.7,7.1-2.1
c2-1.3,3.2-3.6,3.2-6c0-2.1-1-4.1-2.8-5.2c-2-1.1-4-2-6.2-2.6c-1.3-0.4-2.5-0.9-3.8-1.4c-1.1-0.6-1.7-1.4-1.7-2.2
c0-0.9,0.4-1.8,1.1-2.4c0.7-0.6,1.6-0.9,2.5-0.8c0.9-0.1,1.8,0.2,2.6,0.6C13.8,20.7,14.3,21.5,14.4,22.4 M44.7,34.3
c-3.2,3-8.1,2.9-11.2-0.2c-3.1-3.1-3.2-8.2,0-11.4c0,0,0,0,0,0c3.1-3.1,8.1-3.2,11.2-0.2l3.9-4.2c-1.3-1.2-2.7-2.1-4.4-2.8
c-1.6-0.6-3.3-0.9-5-0.9c-7.6,0-13.8,6.2-13.8,13.8c0,7.6,6.2,13.8,13.8,13.8c1.7,0,3.4-0.3,5-0.9c1.6-0.6,3.1-1.6,4.4-2.8
L44.7,34.3z M124.6,20.5h7.8v-5.4h-7.8V0l-6.1,1.2v40.4h6.1L124.6,20.5z" />
<path id="Path_550" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#14C9C0;" d="
M143.7,19.2L143.7,19.2l0-4.2l-6.1,1.2v3.5h0v21.9h6.1V19.2z" />
<path id="Path_551" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#14C9C0;" d="
M243.6,19.2L243.6,19.2l0-4.1l-6.1,1.2v3.5h0v21.9h6.1L243.6,19.2z" />
<path id="Path_552" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#14C9C0;" d="
M110.7,29V15.1h0V15l-6.1,1.2v3.5h0v9.6c0,4-3.2,7.2-7.2,7.2c-4,0-7.2-3.2-7.2-7.2v-1.1l-6.1,1.2c0.3,7.3,6.4,13.1,13.7,12.8
C105.1,42,110.7,36.1,110.7,29 M84.2,19.8l6.1-1.2v-3.5l0,0V15l-6.1,1.2V19.8L84.2,19.8L84.2,19.8z" />
<path id="Path_553" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#14C9C0;" d="
M369.5,30.7c0.1-2.1-0.2-4.2-0.7-6.3c-0.7-2.1-1.8-4.1-3.3-5.7c-5.6-5.5-14.5-5.5-20,0c-2.6,2.5-4,6-4,9.6c-0.1,4.1,1.8,7.9,5,10.4
c1.4,1.1,2.9,2,4.6,2.5c1.7,0.6,3.5,0.9,5.3,0.9c4.7,0.1,9.2-2,12-5.7l-4.8-3.1c-1.1,1.4-2.6,2.4-4.3,3c-1.6,0.6-3.3,0.7-5,0.5
c-1.6-0.2-3.2-0.9-4.5-1.9c-1.3-1.1-2.3-2.5-2.7-4.2L369.5,30.7z M363.3,25.8h-16c0.5-1.7,1.6-3.1,3-4.1c1.4-1.1,3.2-1.7,5-1.7
c1.8,0,3.5,0.6,4.9,1.6C361.7,22.6,362.8,24.1,363.3,25.8 M323.8,34.1c-3.1-3.1-3.2-8.2,0-11.4c0,0,0,0,0,0
c3.1-3.1,8.1-3.2,11.2-0.2l3.9-4.2c-1.3-1.2-2.7-2.1-4.4-2.8c-1.6-0.6-3.3-0.9-5-0.9c-7.6,0-13.8,6.2-13.8,13.8c0,0,0,0,0,0
c0,7.6,6.2,13.8,13.8,13.8c1.7,0,3.4-0.3,5-0.9c1.6-0.6,3.1-1.6,4.4-2.8l-3.9-4.2C331.9,37.3,326.9,37.2,323.8,34.1 M303.9,41.6
h6.1v-14c0.1-2.8-0.7-5.6-2.2-7.9c-1.3-2-3.2-3.5-5.4-4.3c-2.1-0.9-4.4-1.1-6.7-0.7c-2.3,0.3-4.4,1.3-6.1,2.9V15l-6.1,1.2v0.4h0v25
h6.1v-14c-0.1-2,0.8-3.9,2.3-5.3c2.8-2.3,7-2.3,9.8,0c1.5,1.3,2.4,3.3,2.3,5.3L303.9,41.6z M255.4,30.7h22.3
c0.1-2.1-0.2-4.2-0.7-6.3c-0.7-2.1-1.8-4.1-3.3-5.7c-5.6-5.5-14.5-5.5-20,0c-2.6,2.5-4,6-4,9.6c-0.1,4.1,1.8,7.9,5,10.4
c1.4,1.1,2.9,2,4.6,2.5c1.7,0.6,3.5,0.9,5.3,0.9c4.7,0.1,9.2-2,12-5.7l-4.8-3.1c-1.1,1.4-2.6,2.4-4.3,3c-1.6,0.6-3.3,0.7-5,0.5
c-1.6-0.2-3.2-0.9-4.5-1.9C256.8,33.8,255.8,32.4,255.4,30.7 M255.6,25.8c0.5-1.7,1.6-3.1,3-4.1c1.4-1.1,3.2-1.7,5-1.7
c1.8,0,3.5,0.6,4.9,1.6c1.5,1,2.6,2.4,3,4.2H255.6z M217.1,34.1c-3.1-3.1-3.2-8.2,0-11.4c0,0,0,0,0,0c3.1-3.1,8.1-3.2,11.2-0.2
l3.9-4.2c-1.3-1.2-2.7-2.1-4.4-2.8c-1.6-0.6-3.3-0.9-5-0.9c-7.6,0-13.8,6.2-13.8,13.8c0,7.6,6.2,13.8,13.8,13.8
c1.7,0,3.4-0.3,5-0.9c1.6-0.6,3.1-1.6,4.4-2.8l-3.9-4.2C225.2,37.3,220.2,37.2,217.1,34.1 M190.4,22.8c0-0.9,0.4-1.8,1.1-2.4
c0.7-0.6,1.6-0.9,2.5-0.8c0.9-0.1,1.8,0.2,2.6,0.6c0.8,0.5,1.3,1.3,1.5,2.2l6.1-0.5c-0.3-2.3-1.7-4.4-3.7-5.6
c-2-1.2-4.4-1.8-6.8-1.6c-2.4,0-4.6,0.8-6.5,2.2c-1.9,1.4-3,3.6-2.9,5.9c-0.1,2.2,1,4.3,2.9,5.5c2,1.2,4.2,2.1,6.5,2.7
c3.4,1.1,5.1,2.1,5.1,3.2c0,1-0.5,1.9-1.4,2.4c-0.9,0.6-1.9,0.9-3,0.8c-1.1,0.1-2.1-0.2-3.1-0.7c-0.9-0.4-1.4-1.3-1.5-2.3l-6.1,0.2
c0.1,2.4,1.5,4.6,3.6,5.8c2.2,1.3,4.7,2,7.3,1.9c2.5,0,5-0.7,7.1-2.1c2-1.3,3.2-3.6,3.2-6c0-2.1-1-4.1-2.8-5.2c-2-1.1-4-2-6.2-2.6
c-1.3-0.4-2.5-0.9-3.8-1.4C191,24.4,190.4,23.6,190.4,22.8 M172,41.7h6.1v-14c0.1-2.8-0.7-5.6-2.2-7.9c-1.3-2-3.2-3.5-5.4-4.3
c-2.1-0.9-4.4-1.1-6.7-0.7c-2.3,0.3-4.4,1.3-6.1,2.9V15l-6.1,1.2v0.1h0v25.3h6.1v-14c-0.1-2,0.8-3.9,2.3-5.3c2.8-2.3,7-2.3,9.8,0
c1.5,1.3,2.4,3.3,2.3,5.3L172,41.7z" />
<path id="Path_554" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M94.5,25.3l-1-5.2l-14.1,2.8l0.3,1.4l-1.5,0.3c-0.6-2.3-1.9-4.3-3.5-5.9c-5.4-5.4-14.1-5.4-19.5,0c-2.6,2.6-4.1,6.1-4.1,9.8
c0,7.6,6.1,13.8,13.7,13.8c3.7,0,7.2-1.5,9.8-4.1c2.6-2.5,4.1-6.1,4.1-9.7c0-0.5,0-1-0.1-1.6l1.5-0.3l0.3,1.5L94.5,25.3z
M72.4,28.4c0.1,1.9-0.6,3.8-1.9,5.3c-3,3.1-8.1,3.2-11.2,0.2c-0.1-0.1-0.1-0.1-0.2-0.2c-1.3-1.5-1.9-3.3-1.9-5.3
c-0.1-1.9,0.6-3.8,1.9-5.3c1.5-1.6,3.5-2.5,5.7-2.4c2.1-0.1,4.2,0.8,5.6,2.4C71.8,24.6,72.4,26.5,72.4,28.4" />
<path id="Path_555" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M71.2,64.6h-4L66.4,67h-1.8l3.9-10.2h1.6L73.9,67h-1.9L71.2,64.6z M67.8,63.2h3L69.2,59L67.8,63.2z" />
<rect id="Rectangle_1378" x="78.1" y="56.8" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" width="1.8" height="10.2" />
<rect id="Rectangle_1379" x="84.4" y="62" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" width="3.7" height="1.4" />
<path id="Path_556" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="M92.5,67
V56.8H96c0.9-0.1,1.9,0.2,2.6,0.7c0.6,0.5,1,1.3,0.9,2.1c0,0.5-0.1,0.9-0.4,1.3c-0.3,0.4-0.7,0.7-1.1,0.9c0.5,0.1,1,0.4,1.3,0.8
c0.3,0.4,0.5,1,0.5,1.5c0.1,0.8-0.3,1.7-0.9,2.2c-0.8,0.6-1.7,0.8-2.6,0.8L92.5,67z M94.3,61.1H96c0.5,0,0.9-0.1,1.3-0.4
c0.3-0.3,0.5-0.7,0.5-1.1c0-0.4-0.1-0.8-0.4-1.1c-0.4-0.3-0.9-0.4-1.3-0.3h-1.7V61.1z M94.3,62.4v3.2h2c0.5,0,0.9-0.1,1.3-0.4
c0.6-0.6,0.6-1.7,0-2.3c-0.3-0.3-0.7-0.5-1.1-0.5L94.3,62.4z" />
<path id="Path_557" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M110.2,64.6h-4l-0.8,2.4h-1.9l3.9-10.2h1.6l3.9,10.2H111L110.2,64.6z M106.7,63.2h3l-1.5-4.2L106.7,63.2z" />
<path id="Path_558" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M122.3,64.4c0-0.4-0.2-0.8-0.5-1c-0.5-0.3-1.1-0.6-1.7-0.7c-0.7-0.2-1.3-0.5-2-0.8c-0.9-0.4-1.4-1.3-1.4-2.3c0-0.8,0.4-1.6,1-2
c0.8-0.6,1.7-0.8,2.6-0.8c0.7,0,1.3,0.1,1.9,0.4c0.5,0.2,1,0.6,1.3,1.1c0.3,0.5,0.5,1,0.5,1.6h-1.8c0-0.5-0.2-0.9-0.5-1.3
c-0.4-0.3-0.9-0.5-1.4-0.5c-0.5,0-1,0.1-1.4,0.4c-0.3,0.2-0.5,0.6-0.5,1c0,0.4,0.2,0.7,0.5,0.9c0.5,0.3,1.1,0.6,1.7,0.7
c0.7,0.2,1.3,0.5,1.9,0.8c0.4,0.3,0.8,0.6,1.1,1c0.2,0.4,0.3,0.9,0.3,1.4c0,0.8-0.3,1.6-1,2c-0.8,0.5-1.7,0.8-2.7,0.8
c-0.7,0-1.4-0.1-2-0.4c-0.6-0.2-1.1-0.6-1.4-1.1c-0.3-0.5-0.5-1.1-0.5-1.7h1.8c0,0.5,0.2,1,0.6,1.3c0.5,0.3,1.1,0.5,1.7,0.5
c0.5,0,1-0.1,1.4-0.4C122.1,65.1,122.3,64.8,122.3,64.4" />
<path id="Path_559" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M134.4,62.5h-4.2v3.1h4.9V67h-6.7V56.8h6.6v1.4h-4.9v2.8h4.2L134.4,62.5z" />
<path id="Path_560" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M139.5,67V56.8h3c0.8,0,1.7,0.2,2.4,0.6c0.7,0.4,1.3,1,1.6,1.7c0.4,0.8,0.6,1.7,0.6,2.5v0.5c0,0.9-0.2,1.8-0.6,2.6
c-0.4,0.7-0.9,1.3-1.6,1.7c-0.8,0.4-1.6,0.6-2.5,0.6L139.5,67z M141.3,58.2v7.4h1.2c0.8,0.1,1.6-0.3,2.1-0.9
c0.5-0.7,0.8-1.6,0.8-2.5v-0.6c0.1-0.9-0.2-1.8-0.7-2.5c-0.5-0.6-1.3-0.9-2.1-0.9L141.3,58.2z" />
<path id="Path_561" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M165.2,58.2H162V67h-1.8v-8.8h-3.2v-1.4h8.1V58.2z" />
<path id="Path_562" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M175.4,62.5h-4.2v3.1h4.9V67h-6.7V56.8h6.6v1.4h-4.9v2.8h4.2L175.4,62.5z" />
<path id="Path_563" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M188.2,63.7c0,1-0.5,1.9-1.2,2.6c-0.8,0.6-1.8,1-2.8,0.9c-0.8,0-1.5-0.2-2.2-0.6c-0.6-0.4-1.1-1-1.4-1.6c-0.4-0.8-0.5-1.6-0.5-2.5
v-1c0-0.9,0.2-1.7,0.5-2.6c0.3-0.7,0.8-1.3,1.5-1.7c0.7-0.4,1.4-0.6,2.2-0.6c1,0,2,0.3,2.7,0.9c0.7,0.7,1.2,1.6,1.2,2.6h-1.8
c0-0.6-0.2-1.2-0.6-1.6c-0.4-0.4-1-0.5-1.5-0.5c-0.7,0-1.4,0.3-1.8,0.8c-0.5,0.7-0.7,1.6-0.6,2.5v0.9c-0.1,0.9,0.2,1.8,0.6,2.5
c0.4,0.6,1,0.9,1.7,0.9c0.6,0,1.1-0.1,1.6-0.5c0.4-0.4,0.6-1,0.7-1.6L188.2,63.7z" />
<path id="Path_564" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M200.8,67H199v-4.5h-4.6V67h-1.8V56.8h1.8v4.3h4.6v-4.3h1.8L200.8,67z" />
<path id="Path_565" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M219.2,58.2H216V67h-1.8v-8.8h-3.2v-1.4h8.1V58.2z" />
<path id="Path_566" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M227.2,63.1h-2V67h-1.8V56.8h3.6c1-0.1,1.9,0.2,2.7,0.8c0.7,0.6,1,1.4,1,2.3c0,0.6-0.2,1.2-0.5,1.7c-0.4,0.5-0.8,0.8-1.4,1.1
l2.3,4.3V67h-1.9L227.2,63.1z M225.2,61.7h1.8c0.5,0,1-0.1,1.4-0.5c0.3-0.3,0.5-0.8,0.5-1.2c0-0.5-0.1-0.9-0.5-1.3
c-0.4-0.3-0.9-0.5-1.4-0.5h-1.9L225.2,61.7z" />
<path id="Path_567" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M241,64.6h-4l-0.8,2.4h-1.8l3.9-10.2h1.6l3.9,10.2h-1.9L241,64.6z M237.6,63.2h3L239,59L237.6,63.2z" />
<path id="Path_568" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M255.9,67h-1.8l-4.6-7.3V67h-1.8V56.8h1.8l4.6,7.3v-7.3h1.8L255.9,67z" />
<path id="Path_569" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M266.2,64.4c0-0.4-0.2-0.8-0.5-1c-0.5-0.3-1.1-0.6-1.7-0.7c-0.7-0.2-1.3-0.5-2-0.8c-0.9-0.4-1.4-1.3-1.4-2.3c0-0.8,0.4-1.6,1-2
c0.8-0.6,1.7-0.8,2.6-0.8c0.7,0,1.3,0.1,1.9,0.4c0.5,0.2,1,0.6,1.3,1.1c0.3,0.5,0.5,1,0.5,1.6h-1.8c0-0.5-0.2-0.9-0.5-1.3
c-0.4-0.3-0.9-0.5-1.4-0.5c-0.5,0-1,0.1-1.4,0.4c-0.3,0.2-0.5,0.6-0.5,1c0,0.4,0.2,0.7,0.5,0.9c0.5,0.3,1.1,0.6,1.7,0.7
c0.7,0.2,1.3,0.5,1.9,0.8c0.4,0.3,0.8,0.6,1.1,1c0.2,0.4,0.3,0.9,0.3,1.4c0,0.8-0.3,1.6-1,2c-0.8,0.5-1.7,0.8-2.7,0.8
c-0.7,0-1.4-0.1-2-0.4c-0.6-0.2-1.1-0.6-1.4-1.1c-0.3-0.5-0.5-1.1-0.5-1.7h1.8c0,0.5,0.2,1,0.6,1.3c0.5,0.3,1.1,0.5,1.7,0.5
c0.5,0,1-0.1,1.4-0.4C266,65.1,266.2,64.8,266.2,64.4" />
<path id="Path_570" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M278.3,62.7h-4.1V67h-1.8V56.8h6.5v1.4h-4.7v3h4.1L278.3,62.7z" />
<path id="Path_571" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M289.2,62.5H285v3.1h4.9V67h-6.7V56.8h6.6v1.4H285v2.8h4.2L289.2,62.5z" />
<path id="Path_572" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#ffffff;" d="
M298,63.1h-2V67h-1.8V56.8h3.6c1-0.1,1.9,0.2,2.7,0.8c0.7,0.6,1,1.4,1,2.3c0,0.6-0.2,1.2-0.5,1.7c-0.4,0.5-0.8,0.8-1.4,1.1l2.3,4.3
V67H300L298,63.1z M296,61.7h1.8c0.5,0,1-0.1,1.4-0.5c0.3-0.3,0.5-0.8,0.5-1.2c0-0.5-0.1-0.9-0.5-1.3c-0.4-0.3-0.9-0.5-1.4-0.5H296
L296,61.7z" />
</g>
</svg>

After

Width:  |  Height:  |  Size: 12 KiB

View file

@ -0,0 +1,121 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 26.2.1, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
<svg version="1.1" id="Group_805" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="0 0 369.5 67.2" style="enable-background:new 0 0 369.5 67.2;" xml:space="preserve">
<style type="text/css">
.st0{clip-path:url(#SVGID_00000084499246685778113730000005394386986623376315_);fill:#14C9C0;}
.st1{clip-path:url(#SVGID_00000084499246685778113730000005394386986623376315_);fill:#161615;}
</style>
<g>
<defs>
<rect id="SVGID_1_" width="369.5" height="67.2" />
</defs>
<clipPath id="SVGID_00000094609971218746498830000013677106623865950620_">
<use xlink:href="#SVGID_1_" style="overflow:visible;" />
</clipPath>
<path id="Path_549" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#14C9C0;" d="
M14.4,22.4l6.1-0.5c-0.3-2.3-1.7-4.4-3.7-5.6c-2-1.2-4.4-1.8-6.8-1.6c-2.4,0-4.6,0.8-6.5,2.2c-1.9,1.4-3,3.6-2.9,5.9
c-0.1,2.2,1,4.3,2.9,5.5c2,1.2,4.2,2.1,6.5,2.7c3.4,1.1,5.1,2.1,5.1,3.2c0,1-0.5,1.9-1.4,2.4c-0.9,0.6-1.9,0.9-3,0.8
c-1.1,0.1-2.1-0.2-3.1-0.7c-0.9-0.4-1.4-1.3-1.5-2.3L0,34.7c0.1,2.4,1.5,4.6,3.6,5.8c2.2,1.3,4.7,2,7.3,1.9c2.5,0,5-0.7,7.1-2.1
c2-1.3,3.2-3.6,3.2-6c0-2.1-1-4.1-2.8-5.2c-2-1.1-4-2-6.2-2.6c-1.3-0.4-2.5-0.9-3.8-1.4c-1.1-0.6-1.7-1.4-1.7-2.2
c0-0.9,0.4-1.8,1.1-2.4c0.7-0.6,1.6-0.9,2.5-0.8c0.9-0.1,1.8,0.2,2.6,0.6C13.8,20.7,14.3,21.5,14.4,22.4 M44.7,34.3
c-3.2,3-8.1,2.9-11.2-0.2c-3.1-3.1-3.2-8.2,0-11.4c0,0,0,0,0,0c3.1-3.1,8.1-3.2,11.2-0.2l3.9-4.2c-1.3-1.2-2.7-2.1-4.4-2.8
c-1.6-0.6-3.3-0.9-5-0.9c-7.6,0-13.8,6.2-13.8,13.8c0,7.6,6.2,13.8,13.8,13.8c1.7,0,3.4-0.3,5-0.9c1.6-0.6,3.1-1.6,4.4-2.8
L44.7,34.3z M124.6,20.5h7.8v-5.4h-7.8V0l-6.1,1.2v40.4h6.1L124.6,20.5z" />
<path id="Path_550" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#14C9C0;" d="
M143.7,19.2L143.7,19.2l0-4.2l-6.1,1.2v3.5h0v21.9h6.1V19.2z" />
<path id="Path_551" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#14C9C0;" d="
M243.6,19.2L243.6,19.2l0-4.1l-6.1,1.2v3.5h0v21.9h6.1L243.6,19.2z" />
<path id="Path_552" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#14C9C0;" d="
M110.7,29V15.1h0V15l-6.1,1.2v3.5h0v9.6c0,4-3.2,7.2-7.2,7.2c-4,0-7.2-3.2-7.2-7.2v-1.1l-6.1,1.2c0.3,7.3,6.4,13.1,13.7,12.8
C105.1,42,110.7,36.1,110.7,29 M84.2,19.8l6.1-1.2v-3.5l0,0V15l-6.1,1.2V19.8L84.2,19.8L84.2,19.8z" />
<path id="Path_553" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#14C9C0;" d="
M369.5,30.7c0.1-2.1-0.2-4.2-0.7-6.3c-0.7-2.1-1.8-4.1-3.3-5.7c-5.6-5.5-14.5-5.5-20,0c-2.6,2.5-4,6-4,9.6c-0.1,4.1,1.8,7.9,5,10.4
c1.4,1.1,2.9,2,4.6,2.5c1.7,0.6,3.5,0.9,5.3,0.9c4.7,0.1,9.2-2,12-5.7l-4.8-3.1c-1.1,1.4-2.6,2.4-4.3,3c-1.6,0.6-3.3,0.7-5,0.5
c-1.6-0.2-3.2-0.9-4.5-1.9c-1.3-1.1-2.3-2.5-2.7-4.2L369.5,30.7z M363.3,25.8h-16c0.5-1.7,1.6-3.1,3-4.1c1.4-1.1,3.2-1.7,5-1.7
c1.8,0,3.5,0.6,4.9,1.6C361.7,22.6,362.8,24.1,363.3,25.8 M323.8,34.1c-3.1-3.1-3.2-8.2,0-11.4c0,0,0,0,0,0
c3.1-3.1,8.1-3.2,11.2-0.2l3.9-4.2c-1.3-1.2-2.7-2.1-4.4-2.8c-1.6-0.6-3.3-0.9-5-0.9c-7.6,0-13.8,6.2-13.8,13.8c0,0,0,0,0,0
c0,7.6,6.2,13.8,13.8,13.8c1.7,0,3.4-0.3,5-0.9c1.6-0.6,3.1-1.6,4.4-2.8l-3.9-4.2C331.9,37.3,326.9,37.2,323.8,34.1 M303.9,41.6
h6.1v-14c0.1-2.8-0.7-5.6-2.2-7.9c-1.3-2-3.2-3.5-5.4-4.3c-2.1-0.9-4.4-1.1-6.7-0.7c-2.3,0.3-4.4,1.3-6.1,2.9V15l-6.1,1.2v0.4h0v25
h6.1v-14c-0.1-2,0.8-3.9,2.3-5.3c2.8-2.3,7-2.3,9.8,0c1.5,1.3,2.4,3.3,2.3,5.3L303.9,41.6z M255.4,30.7h22.3
c0.1-2.1-0.2-4.2-0.7-6.3c-0.7-2.1-1.8-4.1-3.3-5.7c-5.6-5.5-14.5-5.5-20,0c-2.6,2.5-4,6-4,9.6c-0.1,4.1,1.8,7.9,5,10.4
c1.4,1.1,2.9,2,4.6,2.5c1.7,0.6,3.5,0.9,5.3,0.9c4.7,0.1,9.2-2,12-5.7l-4.8-3.1c-1.1,1.4-2.6,2.4-4.3,3c-1.6,0.6-3.3,0.7-5,0.5
c-1.6-0.2-3.2-0.9-4.5-1.9C256.8,33.8,255.8,32.4,255.4,30.7 M255.6,25.8c0.5-1.7,1.6-3.1,3-4.1c1.4-1.1,3.2-1.7,5-1.7
c1.8,0,3.5,0.6,4.9,1.6c1.5,1,2.6,2.4,3,4.2H255.6z M217.1,34.1c-3.1-3.1-3.2-8.2,0-11.4c0,0,0,0,0,0c3.1-3.1,8.1-3.2,11.2-0.2
l3.9-4.2c-1.3-1.2-2.7-2.1-4.4-2.8c-1.6-0.6-3.3-0.9-5-0.9c-7.6,0-13.8,6.2-13.8,13.8c0,7.6,6.2,13.8,13.8,13.8
c1.7,0,3.4-0.3,5-0.9c1.6-0.6,3.1-1.6,4.4-2.8l-3.9-4.2C225.2,37.3,220.2,37.2,217.1,34.1 M190.4,22.8c0-0.9,0.4-1.8,1.1-2.4
c0.7-0.6,1.6-0.9,2.5-0.8c0.9-0.1,1.8,0.2,2.6,0.6c0.8,0.5,1.3,1.3,1.5,2.2l6.1-0.5c-0.3-2.3-1.7-4.4-3.7-5.6
c-2-1.2-4.4-1.8-6.8-1.6c-2.4,0-4.6,0.8-6.5,2.2c-1.9,1.4-3,3.6-2.9,5.9c-0.1,2.2,1,4.3,2.9,5.5c2,1.2,4.2,2.1,6.5,2.7
c3.4,1.1,5.1,2.1,5.1,3.2c0,1-0.5,1.9-1.4,2.4c-0.9,0.6-1.9,0.9-3,0.8c-1.1,0.1-2.1-0.2-3.1-0.7c-0.9-0.4-1.4-1.3-1.5-2.3l-6.1,0.2
c0.1,2.4,1.5,4.6,3.6,5.8c2.2,1.3,4.7,2,7.3,1.9c2.5,0,5-0.7,7.1-2.1c2-1.3,3.2-3.6,3.2-6c0-2.1-1-4.1-2.8-5.2c-2-1.1-4-2-6.2-2.6
c-1.3-0.4-2.5-0.9-3.8-1.4C191,24.4,190.4,23.6,190.4,22.8 M172,41.7h6.1v-14c0.1-2.8-0.7-5.6-2.2-7.9c-1.3-2-3.2-3.5-5.4-4.3
c-2.1-0.9-4.4-1.1-6.7-0.7c-2.3,0.3-4.4,1.3-6.1,2.9V15l-6.1,1.2v0.1h0v25.3h6.1v-14c-0.1-2,0.8-3.9,2.3-5.3c2.8-2.3,7-2.3,9.8,0
c1.5,1.3,2.4,3.3,2.3,5.3L172,41.7z" />
<path id="Path_554" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M94.5,25.3l-1-5.2l-14.1,2.8l0.3,1.4l-1.5,0.3c-0.6-2.3-1.9-4.3-3.5-5.9c-5.4-5.4-14.1-5.4-19.5,0c-2.6,2.6-4.1,6.1-4.1,9.8
c0,7.6,6.1,13.8,13.7,13.8c3.7,0,7.2-1.5,9.8-4.1c2.6-2.5,4.1-6.1,4.1-9.7c0-0.5,0-1-0.1-1.6l1.5-0.3l0.3,1.5L94.5,25.3z
M72.4,28.4c0.1,1.9-0.6,3.8-1.9,5.3c-3,3.1-8.1,3.2-11.2,0.2c-0.1-0.1-0.1-0.1-0.2-0.2c-1.3-1.5-1.9-3.3-1.9-5.3
c-0.1-1.9,0.6-3.8,1.9-5.3c1.5-1.6,3.5-2.5,5.7-2.4c2.1-0.1,4.2,0.8,5.6,2.4C71.8,24.6,72.4,26.5,72.4,28.4" />
<path id="Path_555" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M71.2,64.6h-4L66.4,67h-1.8l3.9-10.2h1.6L73.9,67h-1.9L71.2,64.6z M67.8,63.2h3L69.2,59L67.8,63.2z" />
<rect id="Rectangle_1378" x="78.1" y="56.8" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" width="1.8" height="10.2" />
<rect id="Rectangle_1379" x="84.4" y="62" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" width="3.7" height="1.4" />
<path id="Path_556" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="M92.5,67
V56.8H96c0.9-0.1,1.9,0.2,2.6,0.7c0.6,0.5,1,1.3,0.9,2.1c0,0.5-0.1,0.9-0.4,1.3c-0.3,0.4-0.7,0.7-1.1,0.9c0.5,0.1,1,0.4,1.3,0.8
c0.3,0.4,0.5,1,0.5,1.5c0.1,0.8-0.3,1.7-0.9,2.2c-0.8,0.6-1.7,0.8-2.6,0.8L92.5,67z M94.3,61.1H96c0.5,0,0.9-0.1,1.3-0.4
c0.3-0.3,0.5-0.7,0.5-1.1c0-0.4-0.1-0.8-0.4-1.1c-0.4-0.3-0.9-0.4-1.3-0.3h-1.7V61.1z M94.3,62.4v3.2h2c0.5,0,0.9-0.1,1.3-0.4
c0.6-0.6,0.6-1.7,0-2.3c-0.3-0.3-0.7-0.5-1.1-0.5L94.3,62.4z" />
<path id="Path_557" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M110.2,64.6h-4l-0.8,2.4h-1.9l3.9-10.2h1.6l3.9,10.2H111L110.2,64.6z M106.7,63.2h3l-1.5-4.2L106.7,63.2z" />
<path id="Path_558" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M122.3,64.4c0-0.4-0.2-0.8-0.5-1c-0.5-0.3-1.1-0.6-1.7-0.7c-0.7-0.2-1.3-0.5-2-0.8c-0.9-0.4-1.4-1.3-1.4-2.3c0-0.8,0.4-1.6,1-2
c0.8-0.6,1.7-0.8,2.6-0.8c0.7,0,1.3,0.1,1.9,0.4c0.5,0.2,1,0.6,1.3,1.1c0.3,0.5,0.5,1,0.5,1.6h-1.8c0-0.5-0.2-0.9-0.5-1.3
c-0.4-0.3-0.9-0.5-1.4-0.5c-0.5,0-1,0.1-1.4,0.4c-0.3,0.2-0.5,0.6-0.5,1c0,0.4,0.2,0.7,0.5,0.9c0.5,0.3,1.1,0.6,1.7,0.7
c0.7,0.2,1.3,0.5,1.9,0.8c0.4,0.3,0.8,0.6,1.1,1c0.2,0.4,0.3,0.9,0.3,1.4c0,0.8-0.3,1.6-1,2c-0.8,0.5-1.7,0.8-2.7,0.8
c-0.7,0-1.4-0.1-2-0.4c-0.6-0.2-1.1-0.6-1.4-1.1c-0.3-0.5-0.5-1.1-0.5-1.7h1.8c0,0.5,0.2,1,0.6,1.3c0.5,0.3,1.1,0.5,1.7,0.5
c0.5,0,1-0.1,1.4-0.4C122.1,65.1,122.3,64.8,122.3,64.4" />
<path id="Path_559" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M134.4,62.5h-4.2v3.1h4.9V67h-6.7V56.8h6.6v1.4h-4.9v2.8h4.2L134.4,62.5z" />
<path id="Path_560" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M139.5,67V56.8h3c0.8,0,1.7,0.2,2.4,0.6c0.7,0.4,1.3,1,1.6,1.7c0.4,0.8,0.6,1.7,0.6,2.5v0.5c0,0.9-0.2,1.8-0.6,2.6
c-0.4,0.7-0.9,1.3-1.6,1.7c-0.8,0.4-1.6,0.6-2.5,0.6L139.5,67z M141.3,58.2v7.4h1.2c0.8,0.1,1.6-0.3,2.1-0.9
c0.5-0.7,0.8-1.6,0.8-2.5v-0.6c0.1-0.9-0.2-1.8-0.7-2.5c-0.5-0.6-1.3-0.9-2.1-0.9L141.3,58.2z" />
<path id="Path_561" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M165.2,58.2H162V67h-1.8v-8.8h-3.2v-1.4h8.1V58.2z" />
<path id="Path_562" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M175.4,62.5h-4.2v3.1h4.9V67h-6.7V56.8h6.6v1.4h-4.9v2.8h4.2L175.4,62.5z" />
<path id="Path_563" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M188.2,63.7c0,1-0.5,1.9-1.2,2.6c-0.8,0.6-1.8,1-2.8,0.9c-0.8,0-1.5-0.2-2.2-0.6c-0.6-0.4-1.1-1-1.4-1.6c-0.4-0.8-0.5-1.6-0.5-2.5
v-1c0-0.9,0.2-1.7,0.5-2.6c0.3-0.7,0.8-1.3,1.5-1.7c0.7-0.4,1.4-0.6,2.2-0.6c1,0,2,0.3,2.7,0.9c0.7,0.7,1.2,1.6,1.2,2.6h-1.8
c0-0.6-0.2-1.2-0.6-1.6c-0.4-0.4-1-0.5-1.5-0.5c-0.7,0-1.4,0.3-1.8,0.8c-0.5,0.7-0.7,1.6-0.6,2.5v0.9c-0.1,0.9,0.2,1.8,0.6,2.5
c0.4,0.6,1,0.9,1.7,0.9c0.6,0,1.1-0.1,1.6-0.5c0.4-0.4,0.6-1,0.7-1.6L188.2,63.7z" />
<path id="Path_564" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M200.8,67H199v-4.5h-4.6V67h-1.8V56.8h1.8v4.3h4.6v-4.3h1.8L200.8,67z" />
<path id="Path_565" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M219.2,58.2H216V67h-1.8v-8.8h-3.2v-1.4h8.1V58.2z" />
<path id="Path_566" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M227.2,63.1h-2V67h-1.8V56.8h3.6c1-0.1,1.9,0.2,2.7,0.8c0.7,0.6,1,1.4,1,2.3c0,0.6-0.2,1.2-0.5,1.7c-0.4,0.5-0.8,0.8-1.4,1.1
l2.3,4.3V67h-1.9L227.2,63.1z M225.2,61.7h1.8c0.5,0,1-0.1,1.4-0.5c0.3-0.3,0.5-0.8,0.5-1.2c0-0.5-0.1-0.9-0.5-1.3
c-0.4-0.3-0.9-0.5-1.4-0.5h-1.9L225.2,61.7z" />
<path id="Path_567" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M241,64.6h-4l-0.8,2.4h-1.8l3.9-10.2h1.6l3.9,10.2h-1.9L241,64.6z M237.6,63.2h3L239,59L237.6,63.2z" />
<path id="Path_568" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M255.9,67h-1.8l-4.6-7.3V67h-1.8V56.8h1.8l4.6,7.3v-7.3h1.8L255.9,67z" />
<path id="Path_569" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M266.2,64.4c0-0.4-0.2-0.8-0.5-1c-0.5-0.3-1.1-0.6-1.7-0.7c-0.7-0.2-1.3-0.5-2-0.8c-0.9-0.4-1.4-1.3-1.4-2.3c0-0.8,0.4-1.6,1-2
c0.8-0.6,1.7-0.8,2.6-0.8c0.7,0,1.3,0.1,1.9,0.4c0.5,0.2,1,0.6,1.3,1.1c0.3,0.5,0.5,1,0.5,1.6h-1.8c0-0.5-0.2-0.9-0.5-1.3
c-0.4-0.3-0.9-0.5-1.4-0.5c-0.5,0-1,0.1-1.4,0.4c-0.3,0.2-0.5,0.6-0.5,1c0,0.4,0.2,0.7,0.5,0.9c0.5,0.3,1.1,0.6,1.7,0.7
c0.7,0.2,1.3,0.5,1.9,0.8c0.4,0.3,0.8,0.6,1.1,1c0.2,0.4,0.3,0.9,0.3,1.4c0,0.8-0.3,1.6-1,2c-0.8,0.5-1.7,0.8-2.7,0.8
c-0.7,0-1.4-0.1-2-0.4c-0.6-0.2-1.1-0.6-1.4-1.1c-0.3-0.5-0.5-1.1-0.5-1.7h1.8c0,0.5,0.2,1,0.6,1.3c0.5,0.3,1.1,0.5,1.7,0.5
c0.5,0,1-0.1,1.4-0.4C266,65.1,266.2,64.8,266.2,64.4" />
<path id="Path_570" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M278.3,62.7h-4.1V67h-1.8V56.8h6.5v1.4h-4.7v3h4.1L278.3,62.7z" />
<path id="Path_571" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M289.2,62.5H285v3.1h4.9V67h-6.7V56.8h6.6v1.4H285v2.8h4.2L289.2,62.5z" />
<path id="Path_572" style="clip-path:url(#SVGID_00000094609971218746498830000013677106623865950620_);fill:#161615;" d="
M298,63.1h-2V67h-1.8V56.8h3.6c1-0.1,1.9,0.2,2.7,0.8c0.7,0.6,1,1.4,1,2.3c0,0.6-0.2,1.2-0.5,1.7c-0.4,0.5-0.8,0.8-1.4,1.1l2.3,4.3
V67H300L298,63.1z M296,61.7h1.8c0.5,0,1-0.1,1.4-0.5c0.3-0.3,0.5-0.8,0.5-1.2c0-0.5-0.1-0.9-0.5-1.3c-0.4-0.3-0.9-0.5-1.4-0.5H296
L296,61.7z" />
</g>
</svg>

After

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 73 KiB

View file

@ -1,118 +0,0 @@
# [open(S3)](https://pypi.org/project/open-large/)
Storing, versioning, and downloading files from S3 made as easy as using `open()` in Python. Caching included.
## Motivation
Oftentimes, especially when working with data-heavy applications, large files can proliferate in a repository. Version controlling them is an obvious next step, however, GitHub's git LFS implementation [doesn't support the deletion](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) of large files, making it easy for them to eat-up the LFS quota and explode the size of your repos.
## Solution
```
pip install open-large
```
### Simple example
```python
from large_file import LargeFileS3
LargeFileS3.configure_credentials({
"aws_region_name": "your_region_like_eu-west-2",
"aws_access_key_id": "YOUR_ACCESS_KEY_ID",
"aws_secret_access_key": "YOUR_VERY_SECRET_ACCESS_KEY",
"large_files_bucket_name": "create_a_bucket_and_put_its_name_here",
})
# Creates a new version and deletes the older version leaving the 3 most recently used intact
with LargeFileS3("test.txt", "w", keep_last_n=3) as f:
for i in range(100000):
f.write('test\n')
# By default the latest version is returned
# but an optional `version` keyword argument can be provided as well
with LargeFileS3("test.txt", "r") as f:
print(f.readlines()[0])
```
> Automatically creates a file, writes to it, uploads it to S3, and then queries the most recent version of it.
> In this case, the latest version is already in the local cache, no download is required.
### More details
`LargeFile` behaves like an opened file (in the background it is a temp file after all). Binary reading and writing is supported along with the [different keywords](https://docs.python.org/3/library/functions.html#open) `open()` accepts.
The local cache can be configured with these properties:
```python
LargeFile.cache_path = Path('.cache')
LargeFile.max_cache_size = "30 GB"
```
#### I only need a path
In case you only need a path to the "remote" file, this pattern can be applied:
```python
path_to_model = LargeFile("folder-of-my-bert-model", version=31).get()
```
> This will first download the file/folder into your local cache folder. Then, it returns a `Path` object to the local version. Which can be turned into a string with `str(path_to_model)`.
The same approach works for uploads:
```python
LargeFile("folder-of-my-bert-model").push('path_to_local/folder_or_file')
```
> This way, both regular files and folders can be handled. The uploaded file is called **folder-of-my-bert-model**, the local name is ignored.
Lastly, all version of the remote object can be deleted by calling `LargeFile("my-file").delete()`. It will still reside in your local cache afterwards, its deletion will happen next time your local cache has to be pruned.
### Command-line example
The package can be used as a module from the command-line to give you more flexibility.
#### Setup
Create an .ini file (or use _~/.aws/credentials_). It may look like this:
```ini
aws_region_name = your_region_like_eu-west-2
aws_access_key_id = YOUR_ACCESS_KEY_ID
aws_secret_access_key = YOUR_VERY_SECRET_ACCESS_KEY
large_files_bucket_name = my_large_files
endpoint_url = this is optional, for backblaze, use this: https://s3.us-west-002.backblazeb2.com
```
> Just like in [example secrets](example_secrets.ini).
#### Print the expected options
```sh
python3 -m large_file --help
```
#### Upload some files
```sh
python3 -m large_file --backend s3 --secrets secrets.ini --push my_first_file.json folder/my_second_file my_folder
```
> Only the filename is used as the S3 name, the rest of the path is ignored.
#### Download some files to the local cache
This can be useful when building a Docker image for example. This way, the files can already reside inside the container and need not be downloaded later.
```sh
python3 -m large_file --backend s3 -secrets ~/.aws/credentials --cache my_first_file.json:3 my_second_file my_folder:0
```
> Versions may be specified by using `:`-s.
#### Delete remote files
```sh
python3 -m large_file --backend s3 --secrets ~/.aws/credentials --delete my_first_file.json
```

27
docs/overrides/main.html Normal file
View file

@ -0,0 +1,27 @@
{% extends "base.html" %}
{% block extrahead %}
<meta property="og:title" content="">
<meta property="og:site_name" content="">
<meta property="og:url" content="">
<meta property="og:description" content="Transform your prototype AI code into production-ready software.">
<meta property="og:type" content="">
<meta property="og:image" content=https://great-ai.scoutinscience.com/media/og-image.png>
<style>
.jupyter-wrapper a {
color: var(--md-typeset-a-color) !important;
}
</style>
{% endblock %}
{% block content %}
{% if page.nb_url %}
<a href="{{ page.nb_url }}" title="Download Notebook" class="md-content__button md-icon">
{% include ".icons/material/download.svg" %}
</a>
{% endif %}
{{ super() }}
{% endblock content %}

70
docs/reference/index.md Normal file
View file

@ -0,0 +1,70 @@
# GreatAI reference
```python
from great_ai import *
```
## Core
::: great_ai.GreatAI
options:
filters: ['!__init__']
show_root_heading: true
::: great_ai.configure
options:
show_root_heading: true
::: great_ai.save_model
options:
show_root_heading: true
::: great_ai.use_model
options:
show_root_heading: true
::: great_ai.parameter
options:
show_root_heading: true
::: great_ai.log_metric
options:
show_root_heading: true
## Remote calls
::: great_ai.call_remote_great_ai
options:
show_root_heading: true
::: great_ai.call_remote_great_ai_async
options:
show_root_heading: true
## Ground-truth
::: great_ai.add_ground_truth
options:
show_root_heading: true
::: great_ai.query_ground_truth
options:
show_root_heading: true
::: great_ai.delete_ground_truth
options:
show_root_heading: true
## Tracing databases
::: great_ai.TracingDatabaseDriver
options:
show_root_heading: true
::: great_ai.MongoDbDriver
options:
show_root_heading: true
::: great_ai.ParallelTinyDbDriver
options:
show_root_heading: true

View file

@ -0,0 +1,23 @@
# LargeFile
```python
from great_ai.large_file import *
```
For more details about using LargeFiles, check out the [how to guide](/how-to-guides/large-file/).
::: great_ai.large_file.LargeFileLocal
options:
show_root_heading: true
::: great_ai.large_file.LargeFileS3
options:
show_root_heading: true
::: great_ai.large_file.LargeFileMongo
options:
show_root_heading: true
::: great_ai.large_file.LargeFileBase
options:
show_root_heading: true

View file

@ -0,0 +1,45 @@
# Utilities
```python
from great_ai.utilities import *
```
## NLP tools
Well-tested tools that can be used in production with confidence. The toolbox of feature-extraction functions is expected to grow to cover other domains as well.
::: great_ai.utilities.clean
::: great_ai.utilities.get_sentences
::: great_ai.utilities.language.predict_language
::: great_ai.utilities.language.english_name_of_language
::: great_ai.utilities.language.is_english
::: great_ai.utilities.evaluate_ranking.evaluate_ranking
## Parallel processing
Multiprocessing and multithreading-based parallelism with support for `async` functions. Its main purpose is to implement [great_ai.GreatAI.process_batch][], however, the parallel processing functions are also convenient for covering other types of mapping needs with a friendlier API than [joblib](https://joblib.readthedocs.io/en/latest/parallel.html){ target=_blank } or [multiprocess](https://pypi.org/project/multiprocess/){ target=_blank }.
::: great_ai.utilities.simple_parallel_map
options:
show_root_heading: true
::: great_ai.utilities.parallel_map.parallel_map
::: great_ai.utilities.threaded_parallel_map
options:
show_root_heading: true
## Composable parallel processing
Because both [threaded_parallel_map][great_ai.utilities.parallel_map.threaded_parallel_map.threaded_parallel_map] and [parallel_map][great_ai.utilities.parallel_map.parallel_map.parallel_map] have a streaming interface, it is easy to compose them and end up with, for example, a process for each CPU core with its own thread-pool or event-loop. Longer pipelines are also easy to imagine. The chunking methods help in these compositions.
::: great_ai.utilities.chunk
::: great_ai.utilities.unchunk
## Operations
::: great_ai.utilities.ConfigFile
options:
show_root_heading: true
::: great_ai.utilities.get_logger
options:
show_root_heading: true

25
docs/reference/views.md Normal file
View file

@ -0,0 +1,25 @@
# View models
::: great_ai.Trace
options:
show_root_heading: true
::: great_ai.RouteConfig
options:
show_root_heading: true
::: great_ai.ClassificationOutput
options:
show_root_heading: true
::: great_ai.MultiLabelClassificationOutput
options:
show_root_heading: true
::: great_ai.RegressionOutput
options:
show_root_heading: true
::: great_ai.SequenceLabelingOutput
options:
show_root_heading: true

View file

@ -1,90 +0,0 @@
{
"cells": [
{
"cell_type": "code",
"execution_count": 1,
"metadata": {},
"outputs": [
{
"data": {
"text/plain": [
"Trace(trace_id='07719c28-e248-43f8-a652-608c49ad5a17', created='2022-06-26T07:55:30.587753', original_execution_time_ms=178.268, logged_values={'arg:text:value': 'I love chemical compounds and nuclear fission.', 'arg:text:length': 46, 'arg:target_confidence:value': 50}, models=[Model(key='small-domain-prediction', version=0)], exception=None, output={'labels': [{'label': 'Physics', 'confidence': 28.0, 'explanation': ['nuclear', 'chemical', 'fission', 'compounds', 'love']}, {'label': 'Chemistry', 'confidence': 22.0, 'explanation': ['chemical', 'compounds', 'nuclear', 'fission', 'love']}]}, feedback=None, tags=['predict_domain', 'online', 'development'])"
]
},
"execution_count": 1,
"metadata": {},
"output_type": "execute_result"
}
],
"source": [
"from great_ai import call_remote_great_ai_async\n",
"\n",
"\n",
"await call_remote_great_ai_async(\n",
" \"http://localhost:6060\", {\"text\": \"I love chemical compounds and nuclear fission.\"}\n",
")"
]
},
{
"cell_type": "code",
"execution_count": 1,
"metadata": {},
"outputs": [
{
"name": "stdout",
"output_type": "stream",
"text": [
"<_UnixSelectorEventLoop running=True closed=False debug=False>\n"
]
},
{
"ename": "Exception",
"evalue": "Already running in an event loop, you have to call call_remote_great_ai_async.",
"output_type": "error",
"traceback": [
"\u001b[0;31m---------------------------------------------------------------------------\u001b[0m",
"\u001b[0;31mException\u001b[0m Traceback (most recent call last)",
"\u001b[1;32m/data/projects/great_ai/docs/remote-test/remote.ipynb Cell 1'\u001b[0m in \u001b[0;36m<cell line: 4>\u001b[0;34m()\u001b[0m\n\u001b[1;32m <a href='vscode-notebook-cell:/data/projects/great_ai/docs/remote-test/remote.ipynb#ch0000000?line=0'>1</a>\u001b[0m \u001b[39mfrom\u001b[39;00m \u001b[39mgreat_ai\u001b[39;00m \u001b[39mimport\u001b[39;00m call_remote_great_ai\n\u001b[0;32m----> <a href='vscode-notebook-cell:/data/projects/great_ai/docs/remote-test/remote.ipynb#ch0000000?line=3'>4</a>\u001b[0m call_remote_great_ai(\u001b[39m'\u001b[39;49m\u001b[39mhttp://localhost:6060\u001b[39;49m\u001b[39m'\u001b[39;49m, {\n\u001b[1;32m <a href='vscode-notebook-cell:/data/projects/great_ai/docs/remote-test/remote.ipynb#ch0000000?line=4'>5</a>\u001b[0m \u001b[39m'\u001b[39;49m\u001b[39mtext\u001b[39;49m\u001b[39m'\u001b[39;49m: \u001b[39m'\u001b[39;49m\u001b[39mI love chemical compounds and nuclear fission.\u001b[39;49m\u001b[39m'\u001b[39;49m\n\u001b[1;32m <a href='vscode-notebook-cell:/data/projects/great_ai/docs/remote-test/remote.ipynb#ch0000000?line=5'>6</a>\u001b[0m })\n",
"File \u001b[0;32m/data/projects/great_ai/src/great_ai/great_ai/remote/call_remote_great_ai.py:17\u001b[0m, in \u001b[0;36mcall_remote_great_ai\u001b[0;34m(base_uri, data, retry_count)\u001b[0m\n\u001b[1;32m 15\u001b[0m \u001b[39mtry\u001b[39;00m:\n\u001b[1;32m 16\u001b[0m \u001b[39mprint\u001b[39m(asyncio\u001b[39m.\u001b[39mget_running_loop())\n\u001b[0;32m---> 17\u001b[0m \u001b[39mraise\u001b[39;00m \u001b[39mException\u001b[39;00m(\u001b[39mf\u001b[39m\u001b[39m'\u001b[39m\u001b[39mAlready running in an event loop, you have to call \u001b[39m\u001b[39m{\u001b[39;00mcall_remote_great_ai_async\u001b[39m.\u001b[39m\u001b[39m__name__\u001b[39m\u001b[39m}\u001b[39;00m\u001b[39m.\u001b[39m\u001b[39m'\u001b[39m)\n\u001b[1;32m 18\u001b[0m \u001b[39mexcept\u001b[39;00m \u001b[39mRuntimeError\u001b[39;00m:\n\u001b[1;32m 19\u001b[0m \u001b[39mpass\u001b[39;00m\n",
"\u001b[0;31mException\u001b[0m: Already running in an event loop, you have to call call_remote_great_ai_async."
]
}
],
"source": [
"from great_ai import call_remote_great_ai\n",
"\n",
"\n",
"call_remote_great_ai(\n",
" \"http://localhost:6060\", {\"text\": \"I love chemical compounds and nuclear fission.\"}\n",
")"
]
}
],
"metadata": {
"kernelspec": {
"display_name": "Python 3.10.4 ('.env': venv)",
"language": "python",
"name": "python3"
},
"language_info": {
"codemirror_mode": {
"name": "ipython",
"version": 3
},
"file_extension": ".py",
"mimetype": "text/x-python",
"name": "python",
"nbconvert_exporter": "python",
"pygments_lexer": "ipython3",
"version": "3.10.4"
},
"orig_nbformat": 4,
"vscode": {
"interpreter": {
"hash": "d88b0dd276e3f918f7798b7e97af2e3c2f843817b9e5b55a9df0a682ffd80f44"
}
}
},
"nbformat": 4,
"nbformat_minor": 2
}

Binary file not shown.

Before

Width:  |  Height:  |  Size: 57 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 29 KiB

File diff suppressed because one or more lines are too long

View file

@ -0,0 +1,11 @@
"How many years of software engineering experience do you have?","How many years of data science experience do you have?","Write reusable scripts for data cleaning and merging","Make datasets available on shared infrastructure","Use versioning for data, model, configurations and training scripts","Continuously monitor the behaviour of deployed models","Log production predictions with the models version and input data","Store models in a single format for ease of use","Equip with web interface, package image, provide REST API","Provide simple API for serving batch and real-time requests","Integration with existing data infrastructure","Querying, visualising and understanding metrics and event logging","Allow experimentation with the inference code","Keep the models API and documentation together","Parallelise feature extraction","Cache predictions","Async support for top-down chaining models"
"3","1","Strongly agree","Agree","Strongly agree","Neither agree nor disagree","Strongly agree","Strongly agree","Strongly agree","Strongly agree","Strongly agree","Strongly agree","Strongly agree","Strongly agree","Strongly agree","Neither agree nor disagree","Strongly agree"
"6","2","Neither agree nor disagree","Agree","Neither agree nor disagree","Agree","Agree","Neither agree nor disagree","Disagree","Strongly disagree","Disagree","Strongly disagree","Disagree","Strongly disagree","Disagree","Strongly agree","Strongly disagree"
"1","5","Strongly disagree","Disagree","Disagree","Strongly disagree","Disagree","Strongly disagree","Strongly disagree","Neither agree nor disagree","Strongly disagree","Disagree","Neither agree nor disagree","Agree","Strongly disagree","Strongly disagree","Disagree"
"3","3","Agree","Agree","Disagree","Neither agree nor disagree","Agree","Not applicable","Not applicable","Neither agree nor disagree","Agree","Disagree","Agree","Strongly agree","Not applicable","Neither agree nor disagree","Agree"
"1","7","Neither agree nor disagree","Disagree","Neither agree nor disagree","Disagree","Strongly disagree","Not applicable","Not applicable","Disagree","Strongly disagree","Disagree","Disagree","Neither agree nor disagree","Strongly disagree","Strongly agree","Not applicable"
"6","0","Strongly agree","Strongly agree","Agree","Neither agree nor disagree","Agree","Strongly agree","Agree","Strongly agree","Agree","Strongly agree","Disagree","Strongly agree","Agree","Strongly agree","Not applicable"
"2","2","Disagree","Neither agree nor disagree","Agree","Strongly agree","Neither agree nor disagree","Disagree","Strongly agree","Disagree","Disagree","Agree","Neither agree nor disagree","Neither agree nor disagree","Not applicable","Disagree","Strongly agree"
"1","2","Disagree","Neither agree nor disagree","Disagree","Agree","Disagree","Strongly disagree","Strongly agree","Strongly agree","Strongly disagree","Disagree","Agree","Strongly disagree","Not applicable","Strongly disagree","Strongly disagree"
"0","1","Strongly disagree","Disagree","Strongly disagree","Disagree","Strongly disagree","Disagree","Agree","Strongly disagree","Disagree","Strongly disagree","Disagree","Strongly disagree","Disagree","Disagree","Strongly disagree"
"7","1","Strongly agree","Strongly agree","Agree","Strongly agree","Agree","Agree","Strongly agree","Strongly disagree","Strongly agree","Not applicable","Agree","Agree","Strongly agree","Strongly agree","Agree"
1 How many years of software engineering experience do you have? How many years of data science experience do you have? Write reusable scripts for data cleaning and merging Make datasets available on shared infrastructure Use versioning for data, model, configurations and training scripts Continuously monitor the behaviour of deployed models Log production predictions with the model’s version and input data Store models in a single format for ease of use Equip with web interface, package image, provide REST API Provide simple API for serving batch and real-time requests Integration with existing data infrastructure Querying, visualising and understanding metrics and event logging Allow experimentation with the inference code Keep the model’s API and documentation together Parallelise feature extraction Cache predictions Async support for top-down chaining models
2 3 1 Strongly agree Agree Strongly agree Neither agree nor disagree Strongly agree Strongly agree Strongly agree Strongly agree Strongly agree Strongly agree Strongly agree Strongly agree Strongly agree Neither agree nor disagree Strongly agree
3 6 2 Neither agree nor disagree Agree Neither agree nor disagree Agree Agree Neither agree nor disagree Disagree Strongly disagree Disagree Strongly disagree Disagree Strongly disagree Disagree Strongly agree Strongly disagree
4 1 5 Strongly disagree Disagree Disagree Strongly disagree Disagree Strongly disagree Strongly disagree Neither agree nor disagree Strongly disagree Disagree Neither agree nor disagree Agree Strongly disagree Strongly disagree Disagree
5 3 3 Agree Agree Disagree Neither agree nor disagree Agree Not applicable Not applicable Neither agree nor disagree Agree Disagree Agree Strongly agree Not applicable Neither agree nor disagree Agree
6 1 7 Neither agree nor disagree Disagree Neither agree nor disagree Disagree Strongly disagree Not applicable Not applicable Disagree Strongly disagree Disagree Disagree Neither agree nor disagree Strongly disagree Strongly agree Not applicable
7 6 0 Strongly agree Strongly agree Agree Neither agree nor disagree Agree Strongly agree Agree Strongly agree Agree Strongly agree Disagree Strongly agree Agree Strongly agree Not applicable
8 2 2 Disagree Neither agree nor disagree Agree Strongly agree Neither agree nor disagree Disagree Strongly agree Disagree Disagree Agree Neither agree nor disagree Neither agree nor disagree Not applicable Disagree Strongly agree
9 1 2 Disagree Neither agree nor disagree Disagree Agree Disagree Strongly disagree Strongly agree Strongly agree Strongly disagree Disagree Agree Strongly disagree Not applicable Strongly disagree Strongly disagree
10 0 1 Strongly disagree Disagree Strongly disagree Disagree Strongly disagree Disagree Agree Strongly disagree Disagree Strongly disagree Disagree Strongly disagree Disagree Disagree Strongly disagree
11 7 1 Strongly agree Strongly agree Agree Strongly agree Agree Agree Strongly agree Strongly disagree Strongly agree Not applicable Agree Agree Strongly agree Strongly agree Agree

View file

@ -0,0 +1,11 @@
"I believe the use of GreatAI improves the quality of AI deployments.","I believe the use of GreatAI would increase my productivity.","I believe the use of GreatAI can lead to robust and trustworthy deployments.","Overall, I found GreatAI useful when working with AI.","I found the GreatAI easy to learn.","I found it is easy to employ GreatAI in practice.","I found it is easy to integrate GreatAI into an existing project.","Overall, I found GreatAI easy to use.","Assuming GreatAI is applicable to my task, I predict that I will use it on a regular basis in the future.","Overall, I intend to use the GreatAI in my personal or professional projects."
"7","7","7","7","7","7","7","7","7","7"
"7","7","6","7","5","6","7","6","7","7"
"4","4","5","6","6","5","4","4","5","4"
"6","7","6","7","7","6","7","6","7","6"
"7","7","6","7","4","5","5","5","6","6"
"6","6","6","6","6","6","6","6","6","6"
"6","6","6","4","5","7","6","6","7","7"
"7","6","6","6","4","5","3","5","5","6"
"4","5","5","5","7","2","3","3","3","3"
"7","7","7","7","5","6","5","6","7","7"
1 I believe the use of GreatAI improves the quality of AI deployments. I believe the use of GreatAI would increase my productivity. I believe the use of GreatAI can lead to robust and trustworthy deployments. Overall, I found GreatAI useful when working with AI. I found the GreatAI easy to learn. I found it is easy to employ GreatAI in practice. I found it is easy to integrate GreatAI into an existing project. Overall, I found GreatAI easy to use. Assuming GreatAI is applicable to my task, I predict that I will use it on a regular basis in the future. Overall, I intend to use the GreatAI in my personal or professional projects.
2 7 7 7 7 7 7 7 7 7 7
3 7 7 6 7 5 6 7 6 7 7
4 4 4 5 6 6 5 4 4 5 4
5 6 7 6 7 7 6 7 6 7 6
6 7 7 6 7 4 5 5 5 6 6
7 6 6 6 6 6 6 6 6 6 6
8 6 6 6 4 5 7 6 6 7 7
9 7 6 6 6 4 5 3 5 5 6
10 4 5 5 5 7 2 3 3 3 3
11 7 7 7 7 5 6 5 6 7 7

Binary file not shown.

After

Width:  |  Height:  |  Size: 165 KiB

1297
docs/surveys/surveys.ipynb Normal file

File diff suppressed because one or more lines are too long

View file

@ -1,16 +1,18 @@
\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 libraries that accessibly expose state-of-the-art models. However, the transition from prototypes to production-ready AI applications is still a source of struggle across the industry. Even though professionals already have access to frameworks for deploying AI, case studies and developer surveys have found that many deployments do not follow best practices.
\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.
\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.
\absdiv{Results}
To do.
\absdiv{Conclusions}
To do.
\keywords{SE4ML \and AI engineering \and Trustworthy AI \and Deployment \and Text mining} \absdiv{Objective}
This thesis investigates the causes of and presents a possible solution to the asymmetry between the adoption of libraries for \textit{applying} and those for \textit{deploying} AI. The potential solution is validated through designing a software framework called \textit{GreatAI}, which aims to facilitate \underline{G}eneral \underline{R}obust \underline{E}nd-to-end \underline{A}utomated \underline{T}rustworthy deployments while attempting to overcome the practical drawbacks of earlier similar tools, e.g., \textit{Seldon Core}, \textit{AWS SageMaker}, and \textit{TensorFlow Extended}.
\absdiv{Methods}
\textit{GreatAI} serves as a proxy for exploring the proposed design decisions; moreover, its initial focus is limited to the domain of natural language processing (NLP). Its design is created by applying the principles of design science methodology through iteratively shaping it in two case studies of a commercial NLP pipeline. Subsequently, interviews are conducted with ten practitioners to assess its applicability and generalisability.
\absdiv{Results}
\textit{GreatAI} helps implement 33 best practices through an accessible interface. These target the transition between the prototype and production phases of the AI development lifecycle. Feedback from professional data scientists and software engineers showed that ease of use and functionality are equally important in deciding to adopt deployment technologies, and the proposed framework was rated positively in both dimensions.
\absdiv{Conclusions}
Increasing the overall maturity of industrial AI deployments by devising APIs with ease of adoption in mind is proved to be feasible. While \textit{GreatAI} mainly focuses on NLP, the results show that the development and deployment of trustworthy AI services, in general, can be assisted by frameworks prioritising easy adoption while still streamlining the implementation of various best practices.
\end{abstract} \end{abstract}

View file

@ -1,56 +1,34 @@
\chapter{Introduction} \chapter{Introduction}
Artificial intelligence (AI) techniques have recently started enjoying widespread industry awareness and adoption; the use of AI is increasingly prevalent in all sectors \cite{wirtz2019artificial,bosch2021engineering}. The reasons behind this are manifold \cite{jordan2015machine}, to name a few: recent breakthroughs in deep-learning, increased public awareness, abundance of available data, access to powerful low-cost commodity hardware, education, but most interestingly, the rise of high-level libraries making ready-to-use state-of-the-art (SOTA) models easily available. The latter practically abolishes the barrier of entry for applying AI --- and with that --- can help use-cases in many areas. Artificial intelligence (AI) techniques have recently started enjoying widespread industry awareness and adoption; the use of AI is increasingly prevalent in all sectors \cite{wirtz2019artificial,bosch2021engineering}. The reasons behind this are manifold \cite{jordan2015machine}, to name a few: recent breakthroughs in deep learning (DL), increased public awareness, an abundance of available data, access to powerful low-cost commodity hardware, education, but most interestingly, the rise of high-level libraries making ready-to-use state-of-the-art (SOTA) models easily available. The latter radically lowers the barrier of entry for applying AI --- and with that --- can help use cases in various areas.
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, to achieve robust deployments, the successful integration of AI components into production-ready applications demands strong engineering methods \cite{serban2020adoption}. That is why it is as essential as ever to also focus on the quality of deployed models and software. For instance, the lack of a proper overview of data transformation steps may lead to suboptimal performance and to introducing unintended biases, which might 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 does 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 correctly is as intricate 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 industry 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 to achieve some level of automation and maturity in their deployment processes. However, the barrier of entry for using such existing libraries is too high, especially when compared with the simplicity 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, we design a software framework called \href{https://github.com/schmelczer/great-ai}{\textit{GreatAI}} and present it 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 a more 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 examined and refined using the principles of design science methodology \cite{wieringa2014design} through iteratively designing its API and implementation in two case studies concerning the natural language processing (NLP) pipeline of a commercial product in collaboration with \href{https://scoutinscience.com/}{ScoutinScience B.V.} The goal of the aforementioned software suite is to evaluate technology-transfer opportunities in scientific publications. Subsequently, interviews are conducted with practitioners to validate the broader applicability and generalisability of the design.
The choice of case study subject is no coincidence; while working on the ScoutinScience Platform for the last two years, my colleagues and I have increasingly noticed the same recurring challenges in deploying and operating AI/ML pipelines. This has motivated me to pursue a general solution. Considering that the company's predominant field is NLP, the case studies, and hence, the prototype of \textit{GreatAI} will also focus primarily on deploying NLP models. Nonetheless, the motivation for creating a general solution for all AI/ML contexts remains and will be taken into account every step of the way.
\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. We hypothesise that facilitating the adoption of AI deployment best practices is viable by finding less complex framework\footnote{The terms \textit{framework} and \textit{library} will be used interchangeably in this work stemming from their vague and often holistic differentiation.} designs that are easier to adopt in order to decrease the negative externality of misused AI. This paper investigates the 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 deploying AI 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 suitable 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 third-party 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 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 more than 30 published case studies in Chapter \ref{chapter:background}. \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 Chapters \ref{chapter:design} and \ref{chapter:case} respectively. The final evaluation step is to ascertain the capability of the framework's 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 recent 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 studies and the framework's interaction with them. The contributions of the novel design and obtained results are shown and further validated by conducting interviews with industry professionals in Chapter \ref{chapter:interviews}. The thesis is concluded in Chapter \ref{chapter:conclusion}.

View file

@ -1,48 +1,38 @@
\chapter{Background} \label{chapter:background} \chapter{Background} \label{chapter:background}
Despite the long-standing history of artificial intelligence (AI), industry awareness and adoption has only recently started to meaningfully catch up \cite{wirtz2019artificial}. At the same time, more regulations and guidelines are being published, for instance, the Ethics guidelines for trustworthy AI by the European Commission's High-Level Expert Group on 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}}. This contains seven key requirements, including human agency and oversight, technical robustness, safety, transparency, and accountability. When it comes to accountability, there are meaningful advances being made \cite{raji2020closing}, however, in the case of the other requirements, the situation is more nuanced. Thankfully, the domain of software engineering for machine learning (SE4ML)\footnote{Both in practice and in the literature, this is sometimes also referred to as \textit{AI engineering} and has a large intersection with --- or arguably is the same as --- \textit{MLOps}.} has been working towards finding ways to assist data scientists in ensuring these (and more) expectations are met by their software. Despite the long-standing history of artificial intelligence, industry awareness and adoption have only recently started to catch up meaningfully \cite{wirtz2019artificial}. At the same time, more regulations and guidelines are being published, for instance, the Ethics guidelines for trustworthy AI by the European Commission's High-Level Expert Group on 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}}. This contains seven key requirements, including human agency and oversight, technical robustness, safety, transparency, and accountability. When it comes to accountability, clear advances are being made \cite{raji2020closing}; however, in the case of the other requirements, the situation is more nuanced. Thankfully, the field of software engineering for machine learning (SE4ML)\footnote{Both in practice and literature, this is sometimes also referred to as \textit{AI Engineering} and has a large intersection with, or arguably is the same as, \textit{MLOps}.} has been working towards finding ways to assist data scientists and software engineers in ensuring these (and more) expectations are met by their software.
In the following, the context of the problem is presented from three perspectives. Starting with its possible cause: the democratisation of state-of-the-art AI algorithms and models. Subsequently, the challenges encountered when applying AI in practice is outlined by case studies and survey data. Lastly, the existing approaches and solutions are introduced. In the following, the context of the problem is presented from three perspectives. Starting with its possible cause: the democratisation of state-of-the-art AI/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 \cite{russell2010artificial}, hence, conflating the two terms may be slightly imprecise but usually not wrong.} architectures and models. Subsequently, the challenges encountered when applying AI in practice are outlined by case studies and survey data. Lastly, the existing approaches and solutions are introduced.
\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 easily. In recent years, there has been a proliferation of highly accessible AI-libraries, many of which provide reusable models. For example, let us consider the domain of natural language processing. There are various options for finding AI solutions that work out of the box: FLAIR \cite{akbik2019flair} and Hugging Face's transformers \cite{wolf2019huggingface} let developers access state-of-the-art models and methods in only a couple of lines of code (in many cases 2 or 3). Using transfer-learning, Hugging Face enables its users 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 libraries, the list of readily available solutions is vast: SpaCy \cite{srinivasa2018natural}, Gensim \cite{vrehuuvrek2011gensim}, scikit-learn \cite{pedregosa2011scikit}, and 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 businesses 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 to 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 already been 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 AI/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 APIs 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, 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-customise) dashboards for monitoring deployed models, resulting 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 a 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 corporations; 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 explained: some steps are left out from time to time because they are forgotten. Similarly, Thiée \cite{thiee2021systematic} described 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.
%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.
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} described 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. 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\%. Furthermore, Serban et al., in \cite{serban2021practices}, identified another 14 best practices that concern trustworthy AI, mainly through data governance. They strove to complement high-level checklists with actionable best practices. Analysing 42 survey responses revealed a familiar pattern: most best practices had 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. John et al. \cite{john2020architecting} compared and contrasted recent scientific and grey literature on AI deployments from which they extracted concrete challenges and practices. They also observed that most companies are placing many more models into production than in previous years. Additionally, they pointed out that numerous deployment techniques are absent from contemporary literature, which is speculated to be caused by the immaturity of deployment processes employed in academia. Because for instance, most models in scientific literature experience only initial deployment and are not constantly replaced or refreshed as their performance degrades over time.
Finally, in a follow-up study to \cite{john2020architecting}, Bosch et al. \cite{bosch2021engineering} organised and structured the problem space of AI engineering research based on their 16 primary case studies. The authors noted the increasing and broad adoption of ML in the industry while also emphasising that the \textit{transition from prototype to production-quality deployment} proves to be challenging for many companies. Solid software engineering expertise is required to create additional facilities for the application, such as data pipelines, monitoring, and logging. They defined \textit{deployment \& compliance} to be one of the four main categories of problems and described it as highly underestimated and the source of ample struggle.
\section{Existing solutions} \label{section:existing} \section{Existing solutions} \label{section:existing}
From the previous section, it is noticeable that given enough resources and at the scale of 4195 AI professionals, Microsoft managed to create a comprehensive in-house solution. A similar impression is given by Uber \cite{li2017scaling}; they built a highly sophisticated infrastructure using techniques from distributed and high-performance computing. Though, the authors note that even this solution has its shortcomings in the form rigidity (number of supported libraries and model types) but it still allows the easy extension of the system. It is noticeable that given enough resources and at the scale of 4195 AI professionals, Microsoft managed to create a comprehensive in-house solution. A similar impression is given by Uber \cite{li2017scaling}; they built a highly sophisticated infrastructure using techniques from distributed and high-performance computing. Though the authors note that this solution still has shortcomings in the form of rigidity (number of supported libraries and model types), it also allows for the easy extension of the system. Given the nature of the concerns and the amount of available resources, it is not surprising that both high-tech Fortune 500 companies needed to and did overcome the problems presented by deploying AI. We can learn from their approaches; nonetheless, using them may be infeasible for individuals and SMEs. Thus, the issues remain for the majority of practitioners.
Given the nature of problems faced and amount of available resources, it is not surprising the both of these high-tech, Fortune 500 companies needed to, and did overcome the problems presented by deploying AI. We can learn from their approaches, nonetheless, using them may be infeasible for individuals and SMEs, thus, the issues remain for the majority of practitioners. Luckily, the open-source scene of AI/ML/DS tools, libraries, frameworks, and platforms is thriving. Additionally, there is a considerable number of closed-source --- usually platforms-as-a-service (PaaS) --- solutions next to them. Let us look at some prominent examples. \begin{table}[H]
IBM's AutoAI \cite{wang2020autoai} promises to provide automation for the entire machine learning lifecycle, including deployment. It is a closed-sourced, paid service which --- from their documentation --- seems to focus mostly on non-technical users by providing them with a UI for authoring models. The restrictions caused by the encapsulation of the entire process can be severe. The challenges of integration were emphasised above \cite{sculley2015hidden}. Additionally, an engineer working on Microsoft's comparable solution, the Azure ML Studio, highlighted that once users gain enough understanding of ML, such visual tools can get in their way, and they may need to seek out other solutions \cite{amershi2019software}. Unfortunately, the main value proposition of Azure ML Studio is also to provide a UI for laypeople, and it has also been set to be retired by 2024. Its successor is Azure Machine Learning which shares many similarities with AWS's SageMaker suite \cite{joshi2020amazon}.
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.
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.
\begin{table}
\centering \centering
\begin{threeparttable} \begin{threeparttable}
\caption{High-level comparison of popular AI deployment platforms and libraries.} \caption{High-level comparison of popular AI deployment platforms and libraries.}
@ -52,29 +42,45 @@ 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,john2020architecting}
\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. Luckily, the open-source scene of AI/ML/DS tools, libraries, frameworks, and platforms is thriving. Additionally, there is a considerable number of closed-source --- usually platforms-as-a-service (PaaS) --- solutions next to them. Let us look at some prominent examples. 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"}. IBM's AutoAI \cite{wang2020autoai} promises to provide automation for the entire machine learning lifecycle, including deployment. It is a closed-sourced, paid service which --- from their documentation --- seems to focus primarily on non-technical users by providing them with a graphical user interface (GUI) for authoring models. The restrictions caused by the encapsulation of the entire process can be severe: the challenges of integration were emphasised above \cite{sculley2015hidden}. Additionally, an engineer working on Microsoft's comparable solution, the Azure ML Studio, highlighted that once users gain enough understanding of ML, such visual tools can get in their way, and they may need to seek out other solutions \cite{amershi2019software}. Unfortunately, the main value proposition of Azure ML Studio is also to provide a GUI for laypeople, and it has also been set to be retired by 2024. Its successor is Azure Machine Learning which shares many similarities with AWS's SageMaker suite \cite{joshi2020amazon}.
SageMaker offers the most comprehensive suite of tools and services; most importantly, it has a set of features called \textit{AWS SageMaker MLOps}. This provides easy and/or default implementations for multiple industry best practices described in \cite{serban2020adoption,serban2021practices,john2020ai}. Among others, it promotes using 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 a 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 likely 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 (K8s), AWS Batch, or Ray \cite{moritz2018ray}. There is no augmentation for most deployment best practices. Given the tight coupling between these libraries and their corresponding ML frameworks, they cannot generalise to models or algorithms of other frameworks and technologies. The Open Neural Network Exchange\footnote{\href{https://onnx.ai/}{onnx.ai}} format could be an option for overcoming these incompatibilities. However, wider support would be needed for seamless integration.
Open-source platforms also exist, such as MLflow and Seldon Core. They both rely on Kubernetes to provide their features. MLflow emphasises 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, Ambassador/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 must be created to use Seldon's Custom Resource Definition. These are minor obstacles if the project is already built on top of K8s; however, even then, software engineers with solid cloud and DevOps backgrounds are actively required to use 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 the inefficiencies of these 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 users easily replace and extend its pipeline to fit their changing needs and advancements in the field.
At the same time, 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 software engineering practices which have been ignored or had a very narrow focus in ML literature''}. In summary, the issues expressed in Section \ref{section:industry} can be understood when looking at the available solutions.
\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 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 easy-to-adopt 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 widespread adoption, leads us to believe that current frameworks are inadequate for many contexts, especially in cases where teams lack the background in cloud, operations, and more generally, software engineering. Thus, the answer to \textbf{RQ1} is that the complexity of deploying AI can severely hinder industrial applications even in the presence of existing frameworks. There is an unmet need for accessible AI deployment methods. The revolution brought by FLAIR, Hugging Face, and similar libraries for the domain of AI/ML remains unmatched in the field of AI Engineering and MLOps.

View file

@ -1,27 +1,45 @@
\chapter{Methods} \label{chapter:methods} \chapter{Methods} \label{chapter:methods}
The chosen methodology for this study is Design Science which emphasises the need to design and investigate artifacts in their context \cite{wieringa2014design}. It consists of a design and an empirical cycle. The purpose of the former is to improve a problem context with a new or redesigned artifact. While in the latter, the problem is investigated and its potential treatment is validated concurrently. The design cycle shares similarities with Action Research \cite{davison2004principles}, where the researchers attempt to solve a real-world problem while simultaneously studying the experience of solving said problem. The chosen methodology for this study is Design Science which emphasises the need to design and investigate artifacts in their contexts \cite{wieringa2014design}. It consists of a design and an empirical cycle. The purpose of the former is to improve a problem context with a new or redesigned artifact, while in the latter, the problem is investigated, and its potential treatment is validated concurrently. This strategy seems fitting for our problem in consequence of its practical nature.
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}. The design cycle shares similarities with Action Research \cite{davison2004principles} in which researchers attempt to solve a real-world problem while simultaneously studying the experience of solving said problem. 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 happens to be in line with the philosophy of design science. Additionally, as no research method is without flaws, it is imperative to try to compensate for their weaknesses by applying multiple methods. Hence, the study also relies on interviews with professionals to validate the design decisions and determine the generalisability of \textit{GreatAI}.
\section{Problem context} \section{Design cycle}
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 aim of \textit{GreatAI} can be summarised using the terminology of design science in the following way:
\textit{Facilitate the adoption of AI deployment best practices
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}
The aim of the project can be summarised using the terminology of design science in the following way:
\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. The problem context is the difficulty of responsibly transitioning (while following best practices) from prototype industrial AI applications to production-ready deployments. With the possible treatment being libraries with high-level APIs 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 a 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.
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. 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 which aims to find tech-transfer opportunities in academic publications. The primary input of the system as a whole is a set PDF files, while the output is a list of metrics describing various aspects of each paper, such as interesting sentences, scientific domains, and contributions. The result also includes a predicted score used for ranking. This ranking is subsequently processed by the business developers of Technology Transfer Offices (TTOs) of multiple Dutch and German universities, who later give feedback on the results.
\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. Overall, this problem context carries the properties of typical industry use cases: it utilises a wide range of natural language processing (NLP) 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 within their organisation's core processes. Since the final ranking affects real people, explainability and robustness are also central questions.
\begin{figure}
\centering
\includegraphics[width=.9\linewidth]{figures/design-cycle.drawio.png}
\captionsetup{width=.9\linewidth}
\caption{Implementation of the design cycle of design science \cite{wieringa2014design} for our problem context of AI/ML deployments. The thinner arrows denote smaller but more frequent iterations.}
\label{fig:design-cycle}
\end{figure}
The goal is to find a simpler, less cognitively-straining-to-use design that still leads to high-quality deployments, the definition of which will be described in Section \ref{section:requirements}. Before generalising, the framework's design is iteratively refined using the feedback acquired from applying it in practical contexts, which in this case are the research and development of a smaller and a more complex AI component using the work-in-progress framework.
The design cycle summarising the research approach is shown in Figure \ref{fig:design-cycle} indicating the role of the case studies. The concerns arisen in the \textit{Treatment validation} iterations and their short discussions are highlighted in the form of \textit{Design notes}. Afterwards, they are addressed in the following \textit{Treatment design} iteration. This way, the issues are immediately considered and the proposed solutions can be traced back to the problems prompting their introduction.
\section{Applicability \& generalisability} \label{section:interview-setup}
To conclusively answer \textbf{RQ3} and \textbf{RQ4}, we conduct interviews with software engineers and data scientists with varying levels of professional background. The interview candidates were recruited from the recommendations of my acquaintances, who were kindly asked to seek out people from their professional networks with any connection to AI/ML. After the first few interviews, participants were also asked to suggest other candidates, preferably from different subfields. After two iterations of reaching out to potential interviewees personally, ten engineers and researchers eventually responded positively and participated in the study. Albeit the sample size is small, it still represents a wide range of organisation types: experts were included from startups, consultancies, government organisations, and research companies.
First, before their interview, participants are requested to complete a questionnaire (shown in Appendix \ref{appendix:practices}) about their last completed AI project; the questions refer to the best practices implemented by \textit{GreatAI}. They are also advised to take a quick look at the tutorial page of the documentation.
The interviews are divided into two halves. In the first part, after a brief introduction, interviewees are asked to solve a real-world deployment task by finishing a partially completed example project\footnote{Available at \href{https://github.com/schmelczer/great-ai-interview-task}{github.com/schmelczer/great-ai-interview-task}. The training part of the task has already been done, and the participants only have to deploy the trained classifier.} using \textit{GreatAI}. This is a more straightforward instance of the AI development lifecycle presented in the \textit{GreatAI} tutorials. They are also encouraged to think aloud so their feedback can be noted. Successfully completing the task creates a system implementing a known number of best practices. This way, the added value --- in terms of a larger number of implemented best practices --- can be quantitatively analysed by comparing the qualities of the finished implementation with the previously given answers. The target duration for the interviews is approximately one and a half hours.
We follow the guidelines proposed by Halcomb et al. \cite{halcomb2006verbatim} for collecting information from interviews and reporting it. This reflexive, iterative process starts by recording participants (with their permission) and concurrent note-taking. Reflective journaling is immediately done post-interview, which is subsequently extended and revised by listening to the recordings. Afterwards, we interpret the gathered information by applying the methodology of thematic analysis \cite{alhojailan2012thematic}. Thematic analysis is an iterative qualitative investigation technique consisting of labelling, correlating, and structuring the central recurring topics raised during discussions. It has been successfully used in previous software engineering studies for extracting emergent patterns \cite{haakman2021ai,cruz2019catalog}.
The second half of the one-on-one sessions consists of a short survey allowing us to create the Technology Acceptance Model (TAM) \cite{davis1989perceived} of the problem context. The ultimate goal of the presented library is to help increase the adoption rate of best practices. In order to reach that goal, first, the library itself has to gain adoption. TAM and its numerous variations provide means of measuring users' willingness of adopting new technologies. TAM has been widely applied in literature \cite{marangunic2015technology}, and due to its general psychological origins, it proves to be effective in other areas of technology, not just software \cite{riemenschneider2002explaining}.
We employ the parsimonious version of TAM, which has been measured to have similar predictive power to that of the original TAM while having fewer variables \cite{wu2011user}. Parsimonious TAM observes three interconnected human aspects that influence the actual behaviour (adoption): \textit{perceived usefulness}, \textit{perceived ease of use}, and \textit{intention to use}. Participants are asked ten questions corresponding to these aspects of their experience using \textit{GreatAI}. The questionnaire is shown in Appendix \ref{appendix:questions}. The internal consistency of the answers is calculated using Cronbach's Alpha \cite{bland1997statistics}, after which we reflect on the responses.

View file

@ -1,62 +1,111 @@
\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 context of practical AI/ML platforms. Many software-as-a-service products offer features for hiding the technicalities of machine learning. However --- as we discussed 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 tackle and simplify only the deployment-related concepts.
\section{Scope} \label{section:scope} \section{Scope} \label{section:scope}
As highlighted by several case studies in Chapter \ref{chapter:background}, the transition from prototypes to production-ready systems is often named as the source of unexpected struggle. Maybe it is not a coincidence that a significant portion of the SE4ML best practices should be implemented in this phase as well. Unfortunately, it is easy to gloss over them while tackling the underestimated difficulties of this \textit{transition}. Therefore, the aim of GreatAI is to ease this step of the life-cycle, consequently, its scope is limited to the \textit{transition} step. As highlighted by several case studies in Chapter \ref{chapter:background}, the transition from prototypes to production-ready systems is often named as the source of unexpected struggle. Maybe it is not a coincidence that a significant portion of the SE4ML best practices should be implemented in this phase. Unfortunately, it is easy to gloss over them while tackling the underestimated difficulties of this \textit{transition}. Therefore, the aim of \textit{GreatAI} is to ease this step of the lifecycle. Consequently, its scope is limited to the \textit{transition} step.
There have been attempts that at least partially address this issue, however, as we have seen in Chapter \ref{chapter:background}, these have limitations either from the perspective of best practices, or stemming from their difficulty to be adopted. To have the best chance of providing an easy-to-adopt solution, the scope has to be well-defined and limited. Because to understand the API of a library, users first have to understand its aim, surface, and have to become familiar with the problems it solves. Thus, focusing only on the \textit{transition} step seems reasonable. This step is highlighted in Figure \ref{fig:scope}. There have been attempts that at least partially address this issue; however, as we saw in Chapter \ref{chapter:background}, these have limitations either from the perspective of best practices or stemming from their difficulty in being adopted. The scope has to be well-defined and limited to provide the best chance of providing an easy-to-adopt solution. To understand the API of a library, users first need to understand its aim and surface and have to become familiar with the problems it solves. Thus, limiting the focus solely to the \textit{transition} step seems reasonable. This step is highlighted in Figure \ref{fig:scope}.
\begin{figure} \begin{figure}
\centering \centering
\includegraphics[width=\linewidth]{figures/scope.drawio.png} \includegraphics[width=\linewidth]{figures/scope.drawio.png}
\caption{Usual process steps in the development life-cycle of a data-heavy software solution. The dashed arrows denote optional paths: after a prototype has been completed, there are multiple options for its deployment. The steps with blue background show the scope of GreatAI.} \captionsetup{width=.9\linewidth}
\caption{Usual process steps (based on \cite{john2020architecting}) in the development lifecycle of a data-heavy software solution. The dashed arrows denote optional paths: after a prototype has been completed, there are multiple options for its deployment. The steps with blue background show the primary scope of \textit{GreatAI}.}
\label{fig:scope} \label{fig:scope}
\end{figure} \end{figure}
It is interesting to mention that there is a proliferation\footnote{\href{https://xkcd.com/927/}{xkcd.com/927}} of platform/software as a service (PaaS/SaaS) products for deploying AI\footnote{Such as \href{https://mlem.ai/}{MLEM} 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 \href{https://xkcd.com/927/}{there is a proliferation} 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 intriguing. 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 \textit{GreatAI} as illustrated in Figure \ref{fig:scope}: first, the prototype is transformed into a \textit{GREAT} service and materialised as a common software artifact implementing best practices. Then, it is either deployed using a deployment SaaS or the organisation's existing software deployment setup.
\section{Design principles} \section{Requirements} \label{section:requirements}
As implied in Section \ref{section:scope}, the Unix philosophy \cite{ritchie1978unix,salus1994quarter} of software design is followed. Most notably, the design goal that encourages to \textit{write programs that do one thing and do it well.}\footnote{Of course, \textit{write programs to work together} is also very much applicable, since allowing interoperability is one of the core requirements for GreatAI.}. Apart from providing a clear and simple picture of the intended use cases for the library, this is also in line with the main notion of \textit{A Philosophy of Software Design} \cite{ousterhout2018philosophy}: API-s should be narrow and deep. A narrow width refers to having a small exposed surface area, i.e. having a small number of functions and classes in the public API. While depth implies each of them accomplishing an involved, complex goal. The best practices (which are referenced throughout the thesis) with which the design is concerned are a subset of those compiled by Serban et al. \cite{serban2020adoption,serban2021practices} and John et al. \cite{john2020architecting}. The core requirements --- set of covered best practices --- for a software solution that has the potential to improve our problem context are presented in the following, along with some explanation and clarification for each of them.
In a way, the API-s width is the price the users have to pay (the effort required for learning it) to use it, while the depth is analogous to the return they get from it. Having to learn little and being provided by a lot of functionality maximises return on investment, hence, developer experience (DX). The theoretical frameworks presented in \textit{The Programmer's Brain} \cite{hermans2021programmer} provides us with explanations and vocabulary from psychology for arguing about the cognitive aspects of API designs. In the following, two of them will be used for detailing the design principles: cognitive dimensions of code bases (CDCB) which is an extension of the cognitive dimensions of notation (CDN) framework \cite{blackwell2001cognitive}, and linguistic antipatterns \cite{arnaoudova2016linguistic}. The former comes with a set of dimensions which describe different (often competing) cognitive aspects of code that influence one's ability to perform certain tasks with it. \paragraph{General} Albeit not explicitly in the list of best practices, compatibility is vital in encouraging adoption. Large projects frequently 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.
While linguistic antipatterns provide guidelines for improving consistency and decreasing the false sense of consistency when there is none. Also, choosing the right names for identifiers can help activate information stored in the long-term memory which makes it quicker to comprehend and easier to reason about the code \cite{deissenboeck2006concise}. Finding the most accurate and useful names is harder than it first seems. Accuracy and usefulness are already often competing goals. The more precise the name, the longer and therefore less convenient to use \cite{butler2009relating}. In short, good names are key to good API-s; consciously considering the implications of names has to be an integral part of the design process. The open-source scene of data-related libraries is vibrant. To take the example of data validation, there are at least four 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}. On the contrary, the programming language (PL) of the library may be its only non-general property. Fortunately, the de facto PL for data science is Python, so implementing the library in it should not significantly limit its applicability.
Nonetheless, simple API-s come at a high technical cost. The library has to implement these in a way that still allows high-performance in production \cite{kleppmann2017designing} and avoids being tied to specific libraries or technologies. Inspiration for the latter may be gained from the pipelines of Prado et al. \cite{prado2020bonseyes}: they show that more freedom can be achieved with plug-and-play steps and preconfigured defaults. \paragraph{Robustness} In software development, robustness can be achieved by preparing the application to handle errors gracefully, 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 safeguards as practicable. \textit{GreatAI} should support its clients in this.
Before diving into the concrete issues solved, let us detail the principles that should be used for implementing them in the scope of this framework. \paragraph{End-to-end} In this case, it refers to end-to-end feedback. That is, feedback should be gathered on the system's real-world performance, which 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 in the \href{https://digital-strategy.ec.europa.eu/en/library/ethics-guidelines-trustworthy-ai}{\textit{Ethics guidelines for 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.
The requirements were chosen stemming from their general importance and potential to be mostly implemented by a software framework. That is why these provide an ideal initial direction for tackling the issue. Of course, these do not cover all best practices; for instance, the ones relating to organisational processes fall outside the realm of computer science.
\section{Design principles} \label{section:principles}
Before diving into the concrete issues being solved, let us detail the principles we use while implementing their solutions. As implied in Section \ref{section:scope}, the Unix philosophy \cite{ritchie1978unix,salus1994quarter} of software design is followed. Most notably, the design goal that encourages to \textit{write programs that do one thing and do it well}. Apart from providing a clear and simple picture of the intended use cases for the library, this is also in line with the main notion of \textit{A Philosophy of Software Design} \cite{ousterhout2018philosophy}: APIs should be narrow and deep.
A narrow width refers to having a small exposed surface area, i.e. having a small number of functions and classes in the public API. In contrast, depth implies that each accomplishes an involved, complex goal. In a way, the width of an API is the price users have to pay (the effort required for learning it) to use it, while the depth is analogous to the return they get from it. Having to learn little and being provided with a lot of functionality maximises return on investment (ROI), hence, developer experience (DX).
Moreover, the theoretical frameworks presented in \textit{The Programmer's Brain} \cite{hermans2021programmer} provides us with explanations and vocabulary from psychology for arguing about the cognitive aspects of API design. In the following, two of them will be used for detailing the design principles: cognitive dimensions of code bases (CDCB) which is an extension of the cognitive dimensions of notation (CDN) framework \cite{blackwell2001cognitive}, and linguistic anti-patterns \cite{arnaoudova2016linguistic}. The former comes with a set of dimensions describing different (often competing) cognitive aspects of code that influence one's ability to perform specific tasks.
Linguistic anti-patterns provide guidelines for improving consistency and decreasing the false sense of consistency when there is none. Also, choosing the right names for identifiers can help activate information stored in the long-term memory, making it quicker to comprehend and easier to reason about the code \cite{deissenboeck2006concise}. Finding the most accurate and useful names is more challenging than it first seems. Accuracy and usefulness are already often competing goals: the more precise the name, the longer and, therefore, less convenient to use \cite{butler2009relating}. In short, good names are essential to good APIs; consciously considering the implications of names must be an integral part of the design process.
Nonetheless, simple APIs come with a high technical cost. The library has to implement these in a way that still allows for high performance in production \cite{kleppmann2017designing} and avoids being tied to specific libraries or technologies. Inspiration for the latter may be gained from the ML pipelines of Prado et al. \cite{prado2020bonseyes}: they show that more freedom can be achieved with plug-and-play steps and preconfigured defaults.
\subsection{Default configuration} \subsection{Default configuration}
Existing frameworks oftentimes suffer from the entanglement of numerous levels of abstractions. Instead of exposing each implementation detail and encouraging users to interact with most of them, many of these could be abstracted away. Where configuration may be helpful for advanced users, default values can still be chosen automatically while providing an override option where necessary. Existing frameworks frequently suffer from the entanglement of numerous levels of abstractions.\footnote{\href{https://grugbrain.dev/\#grug-on-apis}{grugbrain.dev/\#grug-on-apis}} Instead of exposing each implementation detail and encouraging users to interact with most of them, these can be abstracted away in a more high-level layer. Even where configuration may be helpful for advanced users, default values can still be chosen automatically while providing an override option where necessary.
For example, tracing the evaluations and the model versions used in a distributed fashion is very much expected of a trustworthy system. Hence, turning this feature on by default but allowing opting-out from it can result in less scaffolding required from the library's user. It also decreases their up-front cognitive load which by definition flattens the learning-curve \cite{hermans2021programmer}. Similar features can be imagined for providing an access API for the algorithms and for giving feedback, marking outliers, etc. For example, tracing the evaluations and the model versions used in a distributed fashion is very much expected of a trustworthy system. Hence, turning this feature on by default but allowing opting-out from it can result in less scaffolding required from the library's users. It also decreases their up-front cognitive load, which by definition flattens the learning-curve \cite{hermans2021programmer}. Similar features can be imagined for providing a service API for the algorithms, giving feedback, marking outliers, and more.
Being \textit{automated} is listed as a requirement but it is imperative to only automate for simplifying and not for hiding decisions. More precisely, guessing must not be a part of automation. For instance --- an otherwise incredibly useful WebGL library --- TWGL.js\footnote{\href{https://twgljs.org/}{twgljs.org}} has a feature for automatically guessing the type of vectors based on their names. If it matches the \texttt{/colou?r/i} pattern, it is treated as a vector with 3 components\footnote{\href{https://github.com/greggman/twgl.js/blob/e3a8d0ed09f7f5cd4be0e4cb5976081c2b5013aa/src/attributes.js\#L139}{\tiny github.com/greggman/twgl.js/blob/e3a8d0ed09f7f5cd4be0e4cb5976081c2b5013aa/src/attributes.js\#L139}}. It is easy to imagine that this can help in certain scenarios, but it does so at the cost of immense confusion when renaming a variable breaks the application. In CDCB, this equates to scoring high on the dimension of \textit{Hidden dependencies} and low on \textit{Visibility}. Being \textit{automated} is listed as a requirement, but it is imperative to only automate for simplifying and not for hiding decisions. More precisely, guessing must not be a part of automation. For instance --- an otherwise handy WebGL library --- TWGL.js, has a feature for automatically guessing the type of vectors based on their names. Suppose it matches the \texttt{/colou?r/i} pattern. In that case, it is treated as a vector with three components\footnote{\href{https://github.com/greggman/twgl.js/blob/e3a8d0ed09f7f5cd4be0e4cb5976081c2b5013aa/src/attributes.js\#L139}{\tiny github.com/greggman/twgl.js/blob/e3a8d0ed09f7f5cd4be0e4cb5976081c2b5013aa/src/attributes.js\#L139}}. It is easy to imagine that this can help in certain scenarios. Still, it does so at the cost of immense confusion when correctly renaming a variable breaks the application. In CDCB, this equates to scoring high on the dimension of \textit{Hidden dependencies} and low on \textit{Visibility}.
Learning from this, any kind of guessing must be avoided for creating a pleasant API. However, this is in conflict with providing defaults for each configuration value. Even if these would be reasonable defaults derived from educated guesses, they are still merely guesses. Nevertheless, if the users are required to specify each configuration option, that leads to considerably more boilerplate code. This verbosity is captured by the \textit{Diffuseness} dimension of CDCB and, of course, should be minimised. Learning from this, any guessing must be avoided to create a pleasant API. However, this conflicts with providing defaults for each configuration value. Even if these would be reasonable defaults derived from educated guesses, they are still merely guesses. Nevertheless, if the users were required to specify each configuration option, that would lead to vastly more boilerplate code. This verbosity is captured by the \textit{Diffuseness} dimension of CDCB and, of course, should be minimised.
To resolve this conflict, GreatAI should have recommended values instead of defaults. This can mean a context object (as suggested in \cite{ousterhout2018philosophy}), which contains the result of each design decision that has to be made for a service's deployment. If not configured manually, the recommended values are applied, just like defaults. The values chosen for each parameter must be clearly highlighted. Coming from the library's single responsibility, the number of parameters should not be immense, hence, the user can be expected to comprehend them instead of just being overwhelmed and skimming it. To resolve this conflict, \textit{GreatAI} should have recommended values instead of defaults. This can mean a context object (as suggested in \cite{ousterhout2018philosophy}), which contains the result of each design consideration that has to be made for a service's deployment. If not configured manually, the recommended values are applied automatically, just like defaults. However, the values chosen for each parameter must be clearly highlighted. Coming from the library's single responsibility, the number of parameters should not be immense; hence, the user can be expected to comprehend them instead of just being overwhelmed and skipping them.
This way, the library attempts to notify its user about the existence of these decisions but does not force them to manually decide. As a result, no initial configuration is needed for starting out with the library (high \textit{Provisionality}, low \textit{Diffuseness}) and the dependencies are not hidden since they are explicitly highlighted. This way, the library attempts to notify its user about the existence of these decisions but does not force them to decide manually. As a result, no initial configuration is needed for starting out with the library (high \textit{Provisionality}, low \textit{Diffuseness}), and the dependencies are not hidden since they are explicitly highlighted.
\subsection{Documentation} \subsection{Documentation}
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. Little value can be derived from software without good documentation; undoubtedly, good documentation is a prerequisite for adoption. Documentations come in many shapes: modern integrated development environments (IDEs) tend to show a popup of a function's description when requested (for instance, on mouse hover), but at the same time, a more comprehensive online manual and example projects are also still expected. Descriptive error messages can also be viewed as documentation.
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. The library must have quality documentation for all categories. Accordingly, for structuring it, the \textit{Diátaxis} philosophy is preferred \cite{Procida_Diataxis_documentation_framework} which prescribes dividing documentation into 4 parts along 2 axes: practical-theoretical and passive-active consumption. The four quadrants derived from this are tutorials, how-to guides, references, and explanations.
A large portion of software documentations is automatically generated from source code. This has the advantage of always keeping it in sync with code changes, however, it might also signal that the API is too large, since it is inconvenient for the developers to document it by hand. 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, and more. The actual framework's documentation is sprinkled over these overly broad topics. This is undoubtedly helpful for beginners to acquire knowledge from a single place. Yet, this high level of accessibility actually hinders the process of finding the relevant sections; in CDCB, this shows a trade-off between the support of \textit{Searching} and \textit{Comprehension} tasks. Diátaxis' take is that linking to external resources about the library's domain is welcome, but the documentation must have a single responsibility: describing the library itself.
When it comes to example code, showing at least the minimal starter code, and the way of customising it has to be showcased front and centre. It is a well-known observation that developers only read documentation when they are stuck and there might be some merit to this. Making them not get stuck --- by providing a starter code from which they can explore the API using IntelliSense-like solutions --- should be preferred. For example, another widely popular Python web framework, Flask\footnote{\href{https://flask.palletsprojects.com/en/2.1.x/}{flask.palletsprojects.com/en/2.1.x}}, at this time, has 324 uniformly styled links on its landing page. Out of these, only 2 lead to the quick start code. Of course, it is not hidden, but I argue that the DX could be improved by displaying it more prominently. A large portion of software documentations is automatically generated from source code, and this has the advantage of always keeping it in sync with code changes. However, it might also signal that the API is too large because it is inconvenient for the developers to document it by hand. Striking the right balance between handcrafted and automatically extracted documentation may be a vital component of good documentation.
When it comes to example code, showing at least a minimal starter code and the way of customising it has to be showcased front and centre. It is a well-known observation that developers only read the documentation when they are stuck, and there might be some merit to this. Helping them not get stuck --- by providing a starter code from which they can explore the API using IntelliSense-like solutions --- should be preferred. Take the example of another widely popular Python web framework, Flask\footnote{\href{https://flask.palletsprojects.com/en/2.1.x/}{flask.palletsprojects.com/en/2.1.x}}, at this time, has 324 homogeneously styled links on its landing page. Out of these, only two lead to the quick-start code. Of course, it is not hidden, but we argue that the DX could be improved by displaying where to start more prominently.
\subsection{Developer experience} \subsection{Developer experience}
Subjectively, the key to good DX is consistency and discoverability. To give an example, the MySQL connector's Python implementation\footnote{\href{https://dev.mysql.com/doc/connector-python/en/}{dev.mysql.com/doc/connector-python/en/}} has a cursor object which exposes a \texttt{fetchone} method. Even though this naming scheme is not conventional in Python since it does not follow \href{https://peps.python.org/pep-0008/}{PEP 8}, at least the API is logical: changing \texttt{sql\_cursor.fetchone()} to \texttt{sql\_cursor.fetchall()} returns all items instead of just one. Using good and consistent names is the key to good DX. Subjectively, a key component of good DX is \textit{Progressive evaluation} through which development can become a highly iterative, experimental process. This is well-understood by popular data science tools, such as Jupyter Notebooks. \textit{GreatAI} also has to support some level of this, for example, in the form of auto-reload on code changes. Further key ingredients of good DX are consistency and discoverability. To give one more example, the MySQL connector's Python implementation\footnote{\href{https://dev.mysql.com/doc/connector-python/en/}{dev.mysql.com/doc/connector-python/en}} has a cursor object which exposes a \texttt{fetchone} method. Even though this naming scheme is not conventional in Python since it does not follow \href{https://peps.python.org/pep-0008/}{PEP 8}, at least the API is intuitive: changing \texttt{sql\_cursor.fetchone()} to \texttt{sql\_cursor.fetchall()} returns all items instead of just one. Using good and consistent names is the key to good DX.
Also, Python codebases are rarely strictly object-oriented (OO), they are a mix of functional, data-driven, and OO programming. Consequently, relying on classes for grouping related functions is not always desirable. Therefore, it is even more imperative to name similar functions similarly. This helps discoverability and chunking \cite{hermans2021programmer} which amount to quicker comprehension. At the same time, Python codebases are rarely strictly object-oriented (OO). They are a mix of the functional, data-driven, and OO paradigms. Consequently, relying on classes for grouping related functions is not always desirable; therefore, it is even more imperative to name similar functions similarly. This helps discoverability and chunking \cite{hermans2021programmer}, which amounts to quicker comprehension.
There is one more reason to prefer consistency. Humans have a limited short-term memory (STM) \cite{miller1956magical}. Even though flags as function parameters are frowned upon by some \cite{martin2009clean}, they are useful, especially, when configuring libraries. However, if there is no convention for the default value of a flag, clients have to remember the flag's name and initial value at the same time, quickly overloading their STM. Thus, in the codebase, all defaults must be \texttt{False}. Sometimes, it can result in a \textit{disable} prefix, which turn into a double negation, users shouldn't ever encounter this themselves since the doubly-negated version is the default, thus when overriding it, it is only singly-negated. This approach also implies, that something may be recommended to be turned on by default. There is one more reason to prefer consistency: humans have limited short-term memory (STM) \cite{miller1956magical}. Even though flags as function parameters are frowned upon by some \cite{martin2009clean}, they can be useful, especially when configuring libraries. However, if there is no convention for the default value of a flag, clients have to remember the flag's name and initial value simultaneously, quickly overloading their STM. Thus, in the codebase, all defaults must be the same, let us say, \texttt{False}. Sometimes, it can result in a \textit{disable} prefix, which may turn into a double negation. Nevertheless, users should never encounter this since the doubly-negated version is the default; thus, it is only singly negated when overriding it. This approach also implies that something may be recommended to be turned on by default.
\section{Architecture} \label{section:architecture}
Although API design has been the central subject so far, it is worth remembering that APIs are usually expected to have corresponding implementations. \textit{GreatAI} is no exception. As laid out in Section \ref{section:principles}, we strive for narrow and deep interfaces; thus, it is time to address the \textit{depth} component.
\textit{GreatAI} stands on the shoulders of numerous open-source packages and integrates them to provide its various features. The most fundamental dependencies and the entire library in context are shown in Figure \ref{fig:technologies}. Given a Python script or a Jupyter notebook, \textit{GreatAI} transforms the specified prediction functions into a production-ready deployment, deployable either as a Docker image, WSGI-server, or an executable relying on \texttt{uvicorn}. The complete list of dependencies can be found in the repository\footnote{\href{https://github.com/schmelczer/great-ai/blob/main/pyproject.toml}{github.com/schmelczer/great-ai/blob/main/pyproject.toml}}.
\begin{figure}
\centering
\includegraphics[width=0.65\linewidth]{figures/technologies.png}
\captionsetup{width=.9\linewidth}
\caption{A very high-level overview of \texttt{GreatAI} in its context. The main dependencies are also highlighted.}
\label{fig:technologies}
\end{figure}
The general theme in the implementation is that each explicit best practice should have its distinct, loosely-coupled functions or classes. When collaboration opportunities arise, such as persisting the model versions (\nth{1} component) into prediction traces (\nth{2} component), there are three primary conduits for realising them. These are the \texttt{context} object responsible for the global configuration per process, the \texttt{FunctionMetadataStore} specifying the expected behaviour of each prediction function, and finally the \texttt{TracingContext} that is created anew for each prediction input (session).
After refining the framework with feedback gathered from case studies and users, we will end up with the core architecture presented in Figure \ref{fig:architecture}. The implementation is mixed-paradigm, combining the expressiveness of functional and the design patterns of object-oriented programming (OOP) in order to maintain an overall low complexity. Reflection is also utilised, especially for run-time type-checking and generating the API definitions and dashboard components. Regardless, the architecture is still presented with a syntax similar to the class diagrams of UML2 \cite{Rumbaugh2004} because it provides the freedom to express even the non-OOP design aspects.
For the sake of brevity, Figure \ref{fig:architecture} does not show all fields, and some related entities have been combined, e.g. the \textit{GroundTruthAPI} box represents the \texttt{add\_ground\_truth}, \texttt{query\_ground\_truth}, and \texttt{delete\_ground\_truth} functions. The client project can also access most of the presented entities, but these optional dependency arrows are not shown in the diagram. The \texttt{utilities} submodule is also left unexpanded; almost all of its functions are orthogonal with the exception of \texttt{parallel\_map}. The latter follows a textbook producer-consumer model facilitated by queues and event signals \cite{wang2020producer}.
\begin{figure}
\centering
\includegraphics[width=\linewidth]{figures/architecture.png}
\captionsetup{width=.9\linewidth}
\caption{The core architecture of \textit{GreatAI} illustrated with syntax loosely-based on UML2 \cite{Rumbaugh2004}. Given its framework nature, the expected client project and the actor integrating it are highlighted; the associations between the framework and the client project are achieved through the use of decorators.}
\label{fig:architecture}
\end{figure}

View file

@ -1,35 +0,0 @@
\section{A complex case}
Let us now turn our attention towards a more complex component. The ScoutinScience Dashboard contains a full-page evaluation view for each academic publication. On this, the known metadata, historical data about the paper's topics, social media mentions, a PDF viewer showing the document, and other augmentation tools are displayed. One of these is the \textit{interesting sentences} section, which aims to summarise the paper from a technology-transfer perspective.
The current approach uses a simple heuristic based on a set of phrases selected by business developers and extended with the help of a word2vec model \cite{mikolov2013efficient}. The user feedback deemed this implementation slightly helpful but not adequate for providing an accurate overview. Thus, this is the baseline that I attempt to improve on in this section.
\begin{displayquote}
Compared with Section \ref{section:simple-case}, this time around, the toolset of GreatAI is at our disposal. Hopefully, this will streamline the development and --- especially --- the deployment. Given its arguably higher complexity, this experiment falls closer to industrial use-cases, and hence, can give a more accurate feedback on how to further improve the API.
\end{displayquote}
\subsection{Background}
Automatic text summarisation (ATS) is one of earliest established problems of text analysis and boasts numerous promising results \cite{el2021automatic}. However, our problem requires generating a special type of summary: it must only concern a single aspect (tech-transfer) of the document. Aspect-based text summarisation has also seen some progress over the last decades \cite{berkovsky2008aspect,hayashi2021wikiasp}, but these approaches require concretely defined topics. Unfortunately, \textit{tech-transfer potential} is anything but a clear topic definition.
Our numerous discussions and interviews with business developers over the last years made it clear that there is no universally agreed on definition for it. At least, all of them agrees that they know it when they see it. Additionally, most of them agree that they can confidently make a decision at the granularity of sentences. This gives rise to an obvious idea: show the experts something that they can annotate. Because the time of experts is valuable, and relevant sentences are few and far between, extra care needs to be taken to improve the ratio of positive examples in the dataset. The research of Iwatsuki Kenichi on formulaic expressions (FE) \cite{iwatsuki2020evaluation,iwatsuki2021extraction,iwatsuki2021communicative,iwatsuki2022extraction} provides a promising direction to do so.
A formulaic expression is a phrase with zero or more slots that expresses a certain intent. In the context of scientific texts, an example\footnote{Taken from the ground-truth data at \href{https://github.com/Alab-NII/FECFevalDataset/blob/master/human_evaluation/background.tsv}{github.com/Alab-NII/FECFevalDataset}} could be: \texttt{it was not until * that}. The asterisk can be substituted with multiple terms and the intention of this expression is (likely) to describe the \textit{History of the related topics}. Iwatsuki et al. identified a set of 39 intentions, compiled a manually labelled dataset \cite{iwatsuki2020evaluation}, and developed multiple approaches for automatically extracting and classifying formulaic expressions in large corpora \cite{iwatsuki2021communicative,iwatsuki2022extraction}.
\subsection{Methods}
In the following, we explore a 2-stage retrieval approach \cite{schutze2008introduction} commonly used in the field of information retrieval. The first stage is expected to filter out sentences that are certainly not relevant from a technology-transfer perspective using Iwatsuki's formulaic expression intention labels. Subsequently, the second stage utilises a fine-tuned SciBERT model to rank the remaining sentence based on a model learned from expert annotations.
This approach has multiple 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.
TODO
Finetuning SciBERT \cite{jurafsky2019speech}.
\subsection{Results}
For measuring the interrater agreement, Cohen's kappa \cite{cohen1960coefficient} is calculated as shown in Equation \ref{equation:kappa}.
\begin{equation} \label{equation:kappa}
\kappa_{agreement} \equiv \frac{p_{observed} - p_{expected}}{1 - p_{expected}} = 1 - \frac{1 - p_{observed}}{1 - p_{expected}}
\end{equation}

View file

@ -1,40 +0,0 @@
\section{Bridging \textbf{the gap} with GreatAI}
This section briefly explores how the problems raised can be solved using GreatAI, and the API it provides to best fit the needs of its users. We first focus on the aspects of data, then, the automated wrapping of service, 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.
\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}.
The Data Version Control (DVC)\footnote{\href{https://dvc.org/}{https://dvc.org/}} open-source project provides a nearly perfect solution. It comes with a command-line interface (CLI) inspired by git's, and it can be integrated with several backend storage servers. Its only downside is of course that it is one more tool that increases the complexity of the project and the initial setup time. If this is an acceptable price to pay, then I personally recommend opting for DVC. Nevertheless, if this may prohibit a team from properly handling data according to the best practices, I present a simpler solution in the following.
The complexity of an API can be decreased by relying on its users preexisting knowledge. Therefore, we can reuse familiar API-s, such as the \texttt{open()} method from Python. A method is proposed which provides the same interface, however, the backing storage for it is a mixture of local disk space, S3-compatible storage, MongoDB, or any other storage backend. It provides a superset of \texttt{open()}'s interface; the same parameters can be used with it.
Easing development isn't just about automating everything but also making the code easy to change (which is the \textit{Viscosity} dimension of CDCB). Going from opening a local file on the disk with the built-in open method, to opening a file from S3 is as easy as changing \texttt{with open('file.txt', 'w' as f: ...} to \texttt{with LargeFileS3('file.txt', 'w' as f: ...}. In the case of the latter, an additional \texttt{version} keyword argument can also be given to lock ourselves in using as certain version which is very much desired in the case of models.
The obstacles coming from the intertwined nature of different models is widely recognised \cite{sculley2015hidden,haakman2021ai,amershi2019software}. This can lead to non-monotonic error propagation, meaning that improvements in one part of the system might decrease the overall system quality \cite{amershi2019software}. The importance of schema versioning in an environment of rapidly changing models and transformations is highlighted and solved for a specific use-case in \cite{van2017versioning}.
The expected features: progress bar, caching, 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.
\subsection{Utilities}
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
to do
% During development, I wanted to check out which types of request fail -> log errors in traces
% Even production systems are not perfect, saving and letting the users filter on the errors is useful. e.g. they can correlate it with the input
% I use a toy example when quickly experimenting, it's important not to overfit on it ( moving it into the library would result in a online for it, so I have to consciously avoid that), but having a very simple
% Argumetn/parameter names were confusing
% offlinemode -> cacheonly mode

View file

@ -1,11 +0,0 @@
\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.
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.
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.
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}.

View file

@ -1,10 +0,0 @@
\input{chapters/5_case/introduction}
\input{chapters/5_case/naive-bayes}
\input{chapters/5_case/features}
\input{chapters/5_case/2-stage}
\input{chapters/5_case/refactoring}
\input{chapters/5_case/results}

View file

@ -1,97 +0,0 @@
\section{A simple case} \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.
\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}}.
\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.
\end{displayquote}
\subsection{Data}
Two datasets will be considered for the experiments. SciBERT's MAG and the SSC. The former is used to compare the results with SciBERT's, while the latter is utilised for training a model for production purposes because it has 19 labels compared with MAG's 7 and it also contains abstracts instead of just sentences, thus, it is more fitting for our use-case.
SciBERT's version of the MAG dataset has 84 thousand and 22.3 thousand sentences in its train and test splits respectively. These are mostly in English and have all punctuation and casing removed. Each sentence is classified as belonging to one of seven fields. Figure \ref{fig:mag-distribtion} shows that the classes have a uniform distribution.
\begin{figure}
\centering
\includegraphics[width=\linewidth]{figures/mag-distribution.png}
\caption{Class distribution of the MAG \cite{wang2019review} dataset's 84000 sentences in its \textit{train} split.}
\label{fig:mag-distribtion}
\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.
\begin{figure}
\centering
\includegraphics[width=\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.}
\label{fig:ss-distribution}
\end{figure}
\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}.
\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.
\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.
\end{displayquote}
\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}.
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.
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.
\begin{displayquote}
\textbf{What could be automated here?} As discussed in Section \ref{section:accessible-ai}, libraries exposing algorithms and state-of-the-art models can already be considered mature and accessible. In this case, only scikit-learn was utilised, but subjectively, most popular libraries have a similarly easy to use use API. Therefore, I see no urgent need for further action regarding the \textit{experimentation} step of the life-cycle in connection with the AI best practices.
\end{displayquote}
\subsection{Results \& Discussion}
\begin{figure}
\centering
\includegraphics[width=0.8\linewidth]{figures/confusion-matrix.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}.}
\label{fig:mag-confusion}
\end{figure}
\begin{figure}
\centering
\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}.}
\label{fig:ss-confusion}
\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.
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.
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.
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.
\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.
\end{displayquote}
\subsection{Deployment}
First, an inference function needs to be written that can take an input on the fly and calculate a corresponding prediction. Since we aim to follow the best practices, namely: \textit{Explain Results and Decisions to Users} and \textit{Employ Interpretable Models When Possible}, giving an explanation of the results is expected. Fortunately, with our simple model it's easy to determine the most influential weights, thus, words. The last deployment step may be to provide access to our model for others.
\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.
\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}.
\begin{displayquote}
\textbf{How could we implement more best practices?} The most notable missing best practices are the lack of automated deployment, automated regression testing, online monitoring, persisting the traces, graceful error-handling, taking feedback on the results (if possible in the use-case), calculating the online accuracy based on the feedback, and retraining the model if necessary using novel data. These all correspond to a best practice.
\end{displayquote}

View file

@ -1 +0,0 @@
\section{Refactoring with GreatAI}

View file

@ -1,38 +0,0 @@
\section{Results}
\begin{table}
\centering
\caption{A subset of the AI lifecycle \href{https://se-ml.github.io/practices/}{best practices identified by Serban et al.} \cite{serban2020adoption,serban2021practices} and the level of support GreatAI provides for them. \textit{Full} requires no action from the user, \textit{Partial} requires at least some involvement, while \textit{Slight} provides some useful features but the client is still expected to make a significant effort.}
\label{table:best-practices}
\begin{tabular}{p{7cm}@{\hskip 0.5cm}c@{\hskip 0.5cm}c}
\hline
\textbf{Best practice} & \textbf{Implementation} & \textbf{Level of support} \\\hline
Use Sanity Checks for All External Data Sources & \texttt{great\_ai.parameter} & Partial \\\hline
Check that Input Data is Complete, Balanced and Well Distributed & Type-checked input & Slight \\\hline
Write Reusable Scripts for Data Cleaning and Merging & \texttt{great\_ai.utilities} & Partial \\\hline
Make Data Sets Available on Shared Infrastructure (private or public) & \texttt{great\_ai.large\_file} & Full \\\hline
Test all Feature Extraction Code & \texttt{great\_ai.utilities} & Partial \\\hline
Employ Interpretable Models When Possible & \texttt{great\_ai} & Slight \\\hline
Enable Parallel Training Experiments & \texttt{great\_ai.parallel\_map} & Partial \\\hline
Continuously Measure Model Quality and Performance & \texttt{great\_ai} & Full \\\hline
Use Versioning for Data, Model, Configurations and Training Scripts & \texttt{great\_ai.large\_file} & Full \\\hline
Run Automated Regression Tests & \texttt{great\_ai} & Full \\\hline
Use Continuous Integration & Docker Images \& scripts & Partial \\\hline
Use Static Analysis to Check Code Quality & Typed API & Partial \\\hline
Assure Application Security & GreatAI is audited & Partial \\\hline
Automate Model Deployment & Docker Images \& scripts & Partial \\\hline
TODO: Enable Shadow Deployment & GreatAI & Full \\\hline
Continuously Monitor the Behaviour of Deployed Models & \texttt{great\_ai} & Full \\\hline
Enable Automatic Roll Backs for Production Models & Docker Images & Partial \\\hline
Log Production Predictions with the Model's Version and Input Data & GreatAI & Full \\\hline
Explain Results and Decisions to Users & GreatAI & Slight \\\hline
\end{tabular}
\end{table}
Table \ref{table:best-practices} summarises the implemented best practices.

View file

@ -0,0 +1,14 @@
\chapter{The ScoutinScience Platform} \label{chapter:case}
The core product of ScoutinScience B.V.\footnote{\href{https://scoutinscience.com/}{scoutinscience.com}} is its Platform\footnote{\href{https://dashboard.scoutinscience.com/}{dashboard.scoutinscience.com}}. The clients are Technology Transfer Offices of Dutch and German universities, government organisations (e.g. Wetsus), and corporations (e.g. Heraeus Group and 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 markers 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 highest chance of being considered interesting by them.
To achieve this, we have a service-based architecture \cite{kleppmann2017designing} on the backend-side --- 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 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 were described in Chapter \ref{chapter:background}. The gap between prototypes and production-ready services is larger than it seems, and it is also larger than it should be. This has motivated me to investigate the state-of-the-art, and I have found that it is insufficient in many cases. Since the ScoutinScience Platform is a 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 that can hopefully advance the state-of-the-art.
This chapter describes the process of designing \textit{GreatAI} and how it fits into real-life use cases. First, a simple experiment is presented which investigates a Naïve Bayes classifier's \cite{maron1961automatic} accuracy at predicting the fields of papers. This leads to the implementation of a software service that is deployed to production. Subsequently, as the feature set of the library grows and matures, a more complex component is developed concerning text-summarisation with SciBERT \cite{beltagy2019scibert}. After implementing each case, the insights gained are fed back into the library's design.
\input{chapters/5_cases/naive-bayes}
\input{chapters/5_cases/scibert}

View file

@ -0,0 +1,201 @@
\section{Domain classification with Naïve Bayes} \label{section:simple-case}
Using different models for slight variations of the same problem is 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. One of the reasons for this can be 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). In contrast, 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 classifier for academic papers.
\subsection{Background}
Fortunately, this is one of the oldest text classification tasks. In fact, Maron introduced the Naïve Bayes classifier in 1961 \cite{maron1961automatic} for precisely 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. However, 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 fine-tuned 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 our knowledge, no other published work exists on this sentence classification task. This may be explained by the task's lack of practical relevance and contrived nature (uniform label distribution), as we will see in the following subsection.
\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 \textit{GreatAI}'s design.
\end{displayquote}
\subsection{Data}
\begin{figure}
\centering
\includegraphics[width=0.45\linewidth]{figures/mag-distribution.png}
\captionsetup{width=.9\linewidth}
\caption{Class distribution of the MAG \cite{wang2019review} dataset's 84000 sentences in its \textit{train} split.}
\label{fig:mag-distribtion}
\end{figure}
Two datasets are considered for the experiments: SciBERT's MAG and the SSC. The former is used to compare the results with SciBERT's, while the latter is utilised for training a model for production purposes because it has 19 labels compared to MAG's 7, and it also contains abstracts instead of just sentences; thus, it is more fitting for our practical use case.
SciBERT's version of the MAG dataset has 84,000 and 22,300 sentences in its train and test splits, respectively. These are mostly in English and have all punctuation and casing removed. Each sentence is classified as belonging to one of seven fields. Figure \ref{fig:mag-distribtion} shows that the classes have a uniform distribution.
\begin{figure}[H]
\centering
\includegraphics[width=0.8\linewidth]{figures/ss-distribution.png}
\captionsetup{width=.9\linewidth}
\caption{Label distribution of the Semantic Scholar dataset \cite{Lo2020S2ORCTS}. Each publication may be assigned at most three labels.}
\label{fig:ss-distribution}
\end{figure}
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 applies, especially when using simple models. Therefore, the data are randomly downsampled to give us 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{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}.
\end{displayquote}
MAG needs no further preprocessing if we aim to match SciBERT's setup \cite{beltagy2019scibert}. However, since SSC contains heaps of metadata, the relevant parts have to be extracted and preprocessed. In this case, these are the concatenation of the abstract's text and the paper's title 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}
\textbf{How should we preprocess the data?} These simple processing steps (filter, map, project) are almost always present in the data science lifecycle. For example, cleaning the input text from various HTML, OCR, PDF, or \LaTeX \hskip 0.12cm extraction artifacts is normally necessary for text analysis. This is captured in the \href{https://se-ml.github.io/practices}{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 side-effects.
\end{displayquote}
\subsection{Methods}
Our aims are twofold: (1) to evaluate a sentence classification model on MAG and compare it with the 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.
It seems reasonable that only considering the distribution (frequencies) of individual terms may be sufficient. For testing this hypothesis, a unigram language model --- Multinomial Naïve Bayes (MNB) --- is constructed, and its accuracy is compared with SciBERT's. The former definitely aligns with the advice to \textit{Use The Most Efficient Models}. Using the MNB implementation of scikit-learn \cite{pedregosa2011scikit}, it only took 71 lines of code to create, hyperparameter optimise, and test a text classifier.\footnote{The code is available at \href{https://great-ai.scoutinscience.com/tutorial/}{great-ai.scoutinscience.com/tutorial}.} This further proves 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 10-fold cross-validation on the \textit{train} split lead to filtering out tokens which occur in fewer than five documents or more than 5\% of the documents.
\begin{displayquote}
\textbf{What could be automated here?} As discussed in Section \ref{section:accessible-ai}, libraries exposing algorithms and even SOTA models can already be considered mature and accessible. In this case, only scikit-learn was utilised, but subjectively, most popular libraries have a similarly easy-to-use API. Therefore, there seems to be no urgent need for further action regarding the \textit{experimentation} step of the lifecycle in connection with the AI best practices.
\end{displayquote}
\subsection{Results \& Discussion}
\begin{figure}
\centering
\includegraphics[width=0.9\linewidth]{figures/mag-confusion.png}
\captionsetup{width=.9\linewidth}
\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}
\end{figure}
\begin{figure}
\centering
\includegraphics[width=\linewidth]{figures/ss-confusion.png}
\captionsetup{width=.9\linewidth}
\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}
\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 Naïve Bayes classifier achieves a whopping $0.6795$ F1 score, which is $2.3\%$ more than SciBERT's on the same dataset. Thus, it seems that MNB clearly outperforms SciBERT for this particular use case: it is not only more accurate, but its model is magnitudes smaller. At the same time, it is also considerably faster to train (or fine-tune 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 choosing 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 straightforward task like this. Apart from phrases, the relations between separate words of a sentence do not carry nearly as much discriminative power as the identity of the terms \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 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 a lower macro-average than on MAG, with an F1-score of 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 comes from the unbalanced distribution of the labels. The lower F1-score is not surprising because this dataset has more than twice as many classes. Additionally, the mistakes made are defensible when we look at Figure \ref{fig:ss-confusion}: most of them are between related domains.
\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.
\end{displayquote}
\subsection{Deployment}
First, an inference function needs to be written to take input on the fly and calculate a corresponding prediction. Since we aim to follow the best practices \textit{Explain Results and Decisions to Users} and \textit{Employ Interpretable Models When Possible}, explaining the results is expected. Fortunately, with our simple model, it is easy to determine the most influential weights, thus, words. The explanations are derived by taking the top five tokens from the input text ranked by their feature weights. The last deployment step is to provide access to our model for others.
\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 improve its consumers' DX. 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 APIs, and sometimes, they even follow the conventions of REST. Either way, we must develop a wrapper over the service to make it available to other internal/external consumers.
\end{displayquote}
According to the body of research on the adoption of best practices, this is where many real-world projects conclude. This also happens to be \textbf{the gap}. Believing that solely focusing on the research and experiments is good enough is a fallacy: when following this approach, the deployment step ends up being a rushed attempt of wrapping the \textit{AI} and putting it in the production environment. This is, inarguably, a deployment. However, it likely follows very few of the best practices, which can lead to suboptimal real-life performance, lack of accountability, lack of opportunity to improve, and possibly an overall negative societal impact.
\begin{displayquote}
\textbf{How could we implement more best practices?} The most notable missing software/operations features are the lack of automated deployment, automated regression testing, online monitoring, persisting prediction traces, graceful error-handling, taking feedback on the results (if possible in the use case), calculating the online accuracy based on the feedback, and retraining the model if necessary using novel data. These all correspond to best practices.
\end{displayquote}
\section{Bridging the gap with GreatAI}
Let us first revisit the library's scope for clarification. As concluded in Section \ref{section:scope}, \textit{GreatAI} should ease the \textit{transition} step between prototypes and production-ready deployments. However, this leaves open the question of what constitutes this step. There are cross-cutting concerns; for example, feature extraction is implemented and used in the training phase, but it is also deployed alongside the model. The robustness criterion has to be met by this procedure even though its implementation is only in focus in the earlier stages of the project. Since having an untested function deployed into production can have severe repercussions, we can conclude that assuring its correctness lies within the scope of \textit{GreatAI}. Henceforth, cross-cutting concerns should be covered.
This section briefly explores how the problems raised can be solved using \textit{GreatAI} and the API it provides to best fit the needs of its users. We first focus on the aspects of data, then we discuss the utility of helper functions, and lastly, the automated wrapping of services.
\subsection{Handling data} \label{subsection:large-file}
The obstacles coming from the intertwined nature of different models are widely recognised \cite{haakman2021ai,amershi2019software,sculley2015hidden}. This can lead to non-monotonic error propagation, meaning that improvements in one part of the system might decrease the overall system quality \cite{amershi2019software}. The importance of schema versioning in an environment of rapidly changing models and transformations is highlighted for a specific use case in \cite{van2017versioning} and more generally by the \textit{Use Versioning for Data, Model, Configurations and Training Scripts} best practice. These emphasise the requirement for versioning models and, in general, data.
We must address two data storage needs: training data and trained models. Proper version control is one of the most basic expectations for commercial codebases. Based on developer surveys, it is likely that our code is already tracked under Git and synchronised with GitHub\footnote{\href{https://octoverse.github.com/\#lets-look-back-at-the-code-and-communities-built-on-git-hub-this-year}{octoverse.github.com/\#lets-look-back-at-the-code-and-communities-built-on-git-hub-this-year}}. Therefore, using Git Large File Storage (LFS) might seem intriguing. However, it is a paid (and surprisingly expensive) service of GitHub, especially when we factor in the expected sizes of the models and training data with the fact that the only way to remove files counting towards our quota is to delete the entire repository\footnote{\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}{docs.github.com/en/repositories/working-with-files/managing-large-files/removing-files-from-git-large-file-storage}}.
An open-source tool, the Data Version Control (DVC)\footnote{\href{https://dvc.org/}{dvc.org}} provides a nearly perfect alternative. It comes with a command-line interface (CLI) inspired by Git's and 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 we highly recommend opting for DVC. Nevertheless, if this may prohibit a team\footnote{As was the case with MLFlow tracking in an ING team described in Section \ref{section:industry}.} from properly handling data according to the best practices, we present a simpler solution.
The complexity of an API can be decreased by relying on its users' preexisting knowledge, and known patterns \cite{hermans2021programmer,ousterhout2018philosophy}. Therefore, we can reuse familiar APIs, such as the \texttt{open()} method from Python. Therefore, a method is proposed which provides the same interface; however, the backing storage can be a mixture of local disk space, S3-compatible storage, MongoDB, or any other storage backend. It provides a superset of \texttt{open()}'s interface\footnote{\href{https://docs.python.org/3/library/functions.html\#open}{docs.python.org/3/library/functions.html\#open}}: the same parameters can be used with it resulting in similar observed behaviour. The expected features: versioning, progress bars, caching, garbage collecting the cache, and automatically deleting old remote versions are all present and come with recommended --- but easy to see and change --- configuration.
Easing development is not merely about automating everything but also about making the code easy to change (which is the \textit{Viscosity} dimension of CDCB). Going from opening a local file on the disk with the built-in open method, to opening a file from S3 is as easy as changing \texttt{open(`file.txt', `w')} to \texttt{LargeFileS3(`file.txt', `w')}. In the case of the latter, an additional \texttt{version} keyword argument can also be given to lock ourselves in using a specific version which can be desirable in the case of models.
\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 are some of the most common. But splitting sentences, language tagging, and robustly lemmatising are also often recurring tasks. Because having reusable and tested feature extraction code covers two best practices, it seems straightforward that a utility module could be created for this, which could be extensively tested through unit testing.
This is exactly the motivation behind \texttt{great\_ai.utilities}. Extra care has to be taken not to overfit these utilities on the cases considered in this chapter; however, we believe these are versatile enough to be helpful in many text-related contexts. A conclusive answer to this assumption will be found during the interviews.
Implementing the unit tests uncovered multiple edge cases and even runtime errors; hence, the merit of \textit{Test all Feature Extraction Code} best practice is unequivocal. There is one more best practice that could be partially covered here, especially because its solution also helps both during batch inference but also at training/feature extraction time: \textit{Enable Parallel Training Experiments}.
A function called \texttt{parallel\_map()} is also implemented which closely mimics the API of the built-in Python function: \texttt{map}. Furthermore, it exemplifies how even a close to trivial function can 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 standard \texttt{multiprocessing} library has a great API. However, doing a parallel mapping task with a progress bar still takes about a dozen lines. This can deter people (at least me) from taking advantage of more than just a single CPU core during exploratory experimentation. With \texttt{parallel\_map()}, this challenge becomes a one-liner routine task.
\subsection{Deployment approach}
Some of the expectations one might have for data-intensive (such as AI) software are similar to that for software in general. These are also captured by the best practices: \textit{Use Continuous Integration}, \textit{Automate Model Deployment}, and \textit{Enable Automatic Roll Backs for Production Model} to name a few. It is important to notice that these have already been solved by software engineering, more specifically, by the DevOps paradigm \cite{leite2019survey}.
In line with the findings of John et al. \cite{john2020architecting} on the SOTA of AI deployments, we suggest wrapping the applications in a format more compatible with existing DevOps toolkits. Instead of reinventing the wheel, we should rely on more established DevOps best practices for implementing the SE4ML deployment best practices. Besides, organisations are expected to have their deployment processes for classical applications; thus, allowing them to reuse those for AI applications seems to be the most convenient approach.
Based on personal experiences, three types of software artifacts are identified (in the context of Python) for which a wide range of established practices exist. WSGI server\footnote{\href{https://peps.python.org/pep-3333/}{peps.python.org/pep-3333}} compatible applications, executable scripts, and Docker Images\footnote{\href{https://docs.docker.com/registry/spec/manifest-v2-2/}{docs.docker.com/registry/spec/manifest-v2-2}}. To achieve this, \textit{GreatAI} provides a compatibility layer between simple Python inference functions and all the abovementioned common artifacts. Taking functions as input for the first step also satisfies the requirement to be \textbf{General}. Nevertheless, to also allow customisation, additional configuration, metadata, and behavioural specification can be given as well.
\begin{listing}[h]
\begin{minted}[
frame=lines,
framesep=2mm,
baselinestretch=1,
linenos
]{python}
from great_ai import GreatAI
@GreatAI.create
def greeter(name: str) -> str:
return f"Hello {name}!"
\end{minted}
\captionsetup{width=.9\linewidth}
\caption{Simplest example using \textit{GreatAI} for wrapping a function. In practice, \texttt{greeter} could be the inference function of an ML model.}
\label{listing:hello-world}
\end{listing}
The main advantage of the wrapping approach is that it does not require any input from the clients (by default). We opted for a decorator \cite{gamma1995design}, which lets users wrap their function by adding a single additional line of code as shown in Listing \ref{listing:hello-world}. After which, the created WSGI application can be accessed through the \texttt{greeter.app} property where \texttt{greeter} is the identifier of the user-defined function. A CLI script (\texttt{great-ai}), along with a \texttt{Dockerfile} are also provided to cover the other two deployment artifacts.
\begin{listing}[h]
\begin{minted}[
frame=lines,
framesep=2mm,
baselinestretch=1,
linenos
]{python}
from great_ai import save_model, GreatAI, parameter, use_model, log_metric
# this could have been called in another script
save_model('special_number', 405)
@GreatAI.create
@parameter('positive_number', validate=lambda n: n > 0)
@use_model('special_number', version='latest', model_kwarg_name='special')
def add_to_special_number(positive_number: int, special: int) -> int:
"""This docstring will be parsed and exported as documentation."""
log_metric('log directly into the Trace', positive_number ** 2)
return special + positive_number
assert add_number(12).output == 417
\end{minted}
\captionsetup{width=.9\linewidth,position=top,skip=-20pt}
\caption{A simple \textit{GreatAI} service with behavioural customisations.}
\label{listing:complex}
\end{listing}
\newpage
Coincidentally, deployment best practices can be easily implemented in this wrapper layer. In the first iteration, these are input validation, persisting traces, online monitoring, and generating documentation. Input validation may be used to \textit{Check that Input Data is Complete, Balanced and Well Distributed}. Traces are essential for both \textit{Log Production Predictions with the Model's Version and Input Data} and \textit{Provide Audit Trails}. However, traces can also indirectly help \textbf{Robustness} because even production systems cannot be expected to be perfect. Saving and letting the users filter on encountered errors while allowing them to correlate those with the inputs producing them is imperative for facilitating debugging. Lastly, monitoring and documentation correspond with helping best practices: \textit{Continuously Monitor the Behaviour of Deployed Models} and \textit{Communicate, Align, and Collaborate With Others} respectively.
To allow customising the service's behaviour to fit different use cases, the default configurations can be overridden by calling some library functions. An example of this can be seen in Listing \ref{listing:complex}, while more details of the semantics can be found in the documentation\footnote{\href{https://great-ai.scoutinscience.com/how-to-guides/create-service/}{great-ai.scoutinscience.com/how-to-guides/create-service}}.
\subsection{Summary}
\begin{figure}[H]
\centering
\includegraphics[width=0.8\linewidth]{figures/dashboard-domains.png}
\captionsetup{width=.9\linewidth}
\caption{Screenshot of the domain prediction integrated into the ScoutinScience Dashboard, where it is used as a filtering option.}
\label{fig:dashboard-domains}
\end{figure}
After implementing some features of the library, it can already be used for deploying the previously discussed domain prediction model. In this case, online prediction is expected; hence, the REST API-based deployment is chosen, which is created by \texttt{@GreatAI.create} and packaged into a Docker image. This image can be instantiated by the company's existing DevOps pipeline and cloud infrastructure. In the end, users can see one more tag in the header section of publication evaluations, where they can also see the explanation behind the model's decision as demonstrated in Figure \ref{fig:dashboard-domains}. Let us now explore how the framework fares in a more complex case.

View file

@ -0,0 +1,168 @@
\newpage
\section{Text summarisation with SciBERT} \label{section:complex-case}
The ScoutinScience Dashboard contains a full-page evaluation view for academic publications. On this, the known metadata, historical trends about the paper's topics, social media mentions, a PDF viewer showing the document, and other augmentation tools are displayed. One of these is the \textit{Highlights} section, which aims to summarise the paper from a technology-transfer perspective.
The current approach uses a simple heuristic based on a set of phrases selected by business developers and extended with the help of a word2vec model \cite{mikolov2013efficient}. The user feedback deemed this implementation slightly helpful but inadequate for providing an accurate overview. Thus, this is the baseline we attempt to improve on in this section.
\begin{displayquote}
Compared with Section \ref{section:simple-case}, this time around, the toolset of \textit{GreatAI} is available at our disposal. Hopefully, this will streamline the development and --- especially --- the deployment. Given its arguably higher complexity, the experiment falls closer to industrial use cases and hence, can give more accurate feedback on how to further improve the API.
\end{displayquote}
\subsection{Background}
Automatic text summarisation (ATS) is also one of the earliest established tasks of text analysis and boasts numerous promising results \cite{el2021automatic}. Text summarisation is usually divided into extractive and abstractive approaches. Even though the latter can lead to more fluent summaries, it is also prone to hallucinate content that is unfaithful to the input \cite{maynez2020faithfulness}. For this reason, extractive techniques are preferred in this case.
Our problem requires generating a special type of summary: it must only concern a single aspect (tech-transfer) of the document. Aspect-based text summarisation has also seen some progress over the last decades \cite{berkovsky2008aspect,hayashi2021wikiasp}, but these methods require concretely defined topics. Unfortunately, \textit{tech-transfer potential} is anything but a clear topic definition.
Numerous discussions and interviews with business developers over the last two years made it clear that there is no universally agreed-on definition of it. At least all of them agree that they know it when they see it. Additionally, most of them agree that they can confidently make a decision on the granularity of sentences. This gives rise to an obvious idea: show the experts something they can annotate. Because experts' time 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 (FEs) \cite{iwatsuki2020evaluation,iwatsuki2021extraction,iwatsuki2021communicative,iwatsuki2022extraction} provides a promising direction to do so.
A formulaic expression is a phrase with zero or more ``slots'' which, when filled appropriately, leads to expressing a certain intent. In the context of scientific text, an example\footnote{Taken from the ground truth data available at \href{https://github.com/Alab-NII/FECFevalDataset/blob/master/human_evaluation/background.tsv}{github.com/Alab-NII/FECFevalDataset}.} could be: \texttt{it was not until * that}. The asterisk can be substituted with multiple terms, and the intention of this expression is (likely) to describe the \textit{History of the related topics}. Iwatsuki et al. identified a set of 39 intentions, compiled a manually labelled dataset \cite{iwatsuki2020evaluation}, and developed multiple approaches for automatically extracting and classifying formulaic expressions in large corpora \cite{iwatsuki2021communicative,iwatsuki2022extraction}.
\subsection{Methods}
In order to compile a new dataset, experts are asked to judge sentences that passed an \textit{intention check}. This pooling approach is commonly used in information retrieval \cite{schutze2008introduction}. The filtering is expected to sieve out sentences that are probably not relevant from a technology-transfer perspective using Iwatsuki's formulaic expression intention classes. Subsequently, relevance judgements --- in the form of \textit{interesting} or \textit{not interesting} labels --- are gathered for the remaining sentences. Figure \ref{fig:annotator} shows an example of the annotation task. Our method turns the extractive summarisation into a binary classification task for which a SciBERT model \cite{beltagy2019scibert} can be fine-tuned. Ultimately, the summaries are derived from sentences selected by the classifier trained on the experts' annotations.
\begin{figure}[h]
\centering
\includegraphics[width=0.75\linewidth]{figures/annotator.png}
\captionsetup{width=.9\linewidth}
\caption{The annotator GUI showing a single sentence and the two labels that can be assigned based on its relevance to technology-transfer.}
\label{fig:annotator}
\end{figure}
We have to note two possible shortcomings of this setup: firstly, the FE intentions are assumed to be strongly correlated with the sought-after \textit{tech-transfer opportunities} aspect. This may or may not be true. Secondly, only the individual relevance of the sentences is considered instead of the overall relevance (utility) of the summary. Nonetheless, we expect that stemming from the length of the documents, and the sparseness of the selected sentences, any combination of them is likely to have low redundancy.
\subsection{Results}
For the first iteration, 1500 sentences were selected for two experts to annotate in a binary fashion according to strict guidelines. Afterwards, for measuring the interrater agreement, we calculated Cohen's kappa \cite{cohen1960coefficient} as shown in Equation \ref{equation:kappa}, which turned out to be \textbf{0.43} for the two annotators. This happens to be just above the lower end of \textit{moderate agreement}. Even though the original quality ranges are sometimes criticised for being too relaxed for the medical domain \cite{mchugh2012interrater}, some leniency is acceptable for many NLP tasks due to their subjectiveness. Regardless, in the case of summarisation, Verberne et al. \cite{verberne2018creating} argue that reasonable end-quality can be reached even when the interrater agreement is relatively low. The ground truth is determined by taking the logical disjunction of the annotations. This is reasonable because the annotators have dissimilar backgrounds and likely judged slightly different aspects of the sentences.
\begin{equation} \label{equation:kappa}
\kappa_{agreement} \equiv \frac{p_{observed} - p_{expected}}{1 - p_{expected}} = 1 - \frac{1 - p_{observed}}{1 - p_{expected}}
\end{equation}
\begin{displayquote}
\textbf{Reproducibility} Reproducible experiments are generally preferred. It is easy to forget to set some seed values and, for example, end up with different data points in the test-train splits during training and validation in a Continuous Integration (CI) pipeline, thus, data leakage. For facilitating reproducibility, it would be useful to reset the seeds of each imported library's random number generators (RNGs) when \textit{GreatAI} is configured. Thus, a feature has been added to detect and reset RNGs of installed and imported libraries. This certainly will not solve the reproducibility crisis \cite{hutson2018artificial} on its own; however, in some cases, it can result in one fewer step to miss.
\end{displayquote}
\begin{figure}[h]
\centering
\includegraphics[width=0.7\linewidth]{figures/scibert-confusion.png}
\captionsetup{width=.9\linewidth}
\caption{Confusion matrix of the fine-tuned SciBERT model on the \textit{summary candidate sentences} dataset.}
\label{fig:scibert-confusion}
\end{figure}
The next step is fine-tuning SciBERT with the help of Hugging Face \texttt{transformers} \cite{wolf2019huggingface}. The data are divided into training and test splits with a ratio of 4:1. A validation split, used for early stopping, is also derived from the train split. The objective function is the F1-score of the positive class, and the early stopping patience is five epochs. The learning rate is $5 \times 10^{-5}$ and AdamW \cite{loshchilov2017decoupled} is used for optimisation with a weight decay of 0.05. The code can be found in the documentation\footnote{\href{https://great-ai.scoutinscience.com/examples/scibert/train/}{great-ai.scoutinscience.com/examples/scibert/train}}, it is surprisingly slightly shorter than the code of Section \ref{section:simple-case}.
\begin{displayquote}
\textbf{Utility of LargeFiles} For the purposes of the documentation, the fine-tuning was conducted in the Google Colab online environment, which is excellent for providing anyone with GPU time for free. However, notebook environments are ephemeral, resulting in the need to manually upload and download all relevant data whenever a new virtual machine instance is granted. The \texttt{LargeFile} implementation alleviated this problem by automatically handling the uploads and downloads. Of course, first, backwards compatibility had to be solved for Python 3.7, the only available environment in Colab.
\end{displayquote}
\begin{table}[ht]
\centering
\begin{threeparttable}
\caption{Accuracty metrics of the fine-tuned SciBERT model on the \textit{summary candidate sentences} dataset.}
\label{table:scibert-pr}
\setlength{\tabcolsep}{0.75em} % for the horizontal padding
{\renewcommand{\arraystretch}{1.2} % for the vertical padding
\begin{tabular}{|l|r|r|r|}
\hline
{} & \textbf{Precision} & \textbf{Recall} & \textbf{Support} \\\hline
\textsc{non-relevant} & 0.93 & 0.83 & 191 \\\hline
\textsc{relevant} & 0.73 & 0.88 & 109 \\\hline
\end{tabular}}
\end{threeparttable}
\end{table}
Let us check how well the selected sentences correspond with the tech-transfer potential. Users and in-house experts can rate publications (from a tech-transfer perspective) by assigning them to one of four categories: \texttt{A}, \texttt{B}, \texttt{C}, and \texttt{D} with \texttt{A} being the most and \texttt{D} the least promising. This feedback is stored and used for analytic and training purposes. Since both the feedback grade and the relevant (summary candidate) sentences are supposed to reflect the same aspect of papers, we can reasonably expect some correlation between the grades and relevant sentence counts.
\begin{figure}[h]
\centering
\includegraphics[width=0.9\linewidth]{figures/highlights-histograms.png}
\captionsetup{width=.9\linewidth}
\caption{Distribution of mean predicted summary candidate sentence counts (refered to as \textit{highlights}) in 4 categories. Category \texttt{A} corresponds to the most, while \texttt{D} to the least interesting papers based on mean user feedback. The sample size is 1406 (\texttt{D}=715, \texttt{C}=309, \texttt{B}=198, \texttt{A}=184). The histograms are on the same scale but shifted vertically according to the grade to which they correspond.}
\label{fig:histograms}
\end{figure}
The best validation results were achieved after eight epochs which is slightly more than expected but is presumably due to the weight decay. The confusion matrix on the test split can be seen in Figure \ref{fig:scibert-confusion}, and the per class accuracy metrics in Table \ref{table:scibert-pr}. Despite the task's subjective definition, SciBERT achieves good quality, indicated by an F1-score of \textbf{0.80}.
Figure \ref{fig:histograms} shows the ratio of summary candidate sentences as predicted by the fine-tuned model in 4 categories (grades) of papers. This dataset does not overlap with the training data; hence, the results come solely from the model's ability to generalise. It is interesting to see that the Spearman's rank correlation coefficient \cite{spearman1961proof} between the normalised ``highlights'' counts and the ratings of papers is \textbf{0.4784} and is statistically significant ($P = 5.4 \times 10^{-74}$). This proves the presence of a monotonic association. For context, the correlation between the grades and the number of sentences chosen by the baseline approach is 0.06597 ($P = 0.03$). We can conclude that the classifier's output is indicative of publications' tech-transfer potential.
\begin{figure}[t]
\centering
\includegraphics[width=\linewidth]{figures/dashboard-highlights.png}
\captionsetup{width=.9\linewidth}
\caption{The tech-transfer summary of an academic publication (\cite{bruns2022deep}). The titles and sentences can be clicked to navigate the paper on the right. Meanwhile, some explanation is provided by the highlighted words, the opacity of which corresponds to their attention weights.}
\label{fig:dashboard-highlights}
\end{figure}
\subsection{Deployment}
To implement the summarisation, at most, the top 7 selected sentences are chosen as ranked by their log probabilities. They are subsequently reordered according to their position in the text. As a quasi-explanation, the tokens' attention scores are visualised and overlaid on the highlighted sentences. The \textit{i}-th token's visualised attention comes from summing up the attention weights of each of the last layer's heads between the \texttt{[CLS]} and the \textit{i}-th token. To improve the end-user experience, a high-pass filter and a stop-word list are applied to the scores to avoid highlighting the syntax-related tokens (punctuation, determiners). The service --- after being integrated into the Dashboard --- can be seen in Figure \ref{fig:dashboard-highlights}.
\begin{displayquote}
\textbf{Design inspiration} In order to get insights into their inner workings, Hugging Face models can be given \texttt{output\_attentions=True} in their constructor, which results in a new property becoming accessible on the results for querying the attentions. The only issue with it is that it is a 5-dimensional matrix which makes exploring and understanding it non-obvious. In short, it has very low \textit{Discoveribility}. For example, the attention weights for the GUI are calculated with this expression:
\begin{minted}[
baselinestretch=1,
]{python}
np.sum(result.attentions[-1].numpy()[0], axis=0)[0][1:-1]
\end{minted}
Even though the operation is conceptually simple, because of the opaque data structure, this is anything but obvious to comprehend. Therefore, it is clear that this needs to be avoided in our library design; it has to have an explicit and discoverable API that can be achieved using type hints, descriptive property names, and docstrings.
\end{displayquote}
\section{Improving GreatAI}
After having solved two problems by implementing two standalone services and integrating them into an existing ecosystem while relying on \textit{GreatAI} as a primary tool, a wide variety of insights have been gained. In the next couple of subsections, the extra features and design decisions that were motivated by the \textit{Highlights (summarisation) service} are presented. After which, the final surface of the API is described, which will be evaluated by its relation to the deployment best practices \cite{serban2020adoption,serban2021practices,john2020architecting,john2020ai} in the next chapter.
\subsection{Caching}
Sustainability is an increasingly crucial concern of ethical AI \cite{van2021sustainable}. Without discussing the pros and cons of the green computing movement \cite{10.1145/1400181.1400186}, we can still agree that computing time should not be wasted. To this end, caching the results of expensive operations has to be considered in any AI deployment. In this case, the \textit{Highlights service} is often called multiple times from different other services with the same parameters. With each operation taking up to a couple of seconds, implementing caching can lead to vastly faster response times and an overall more socially conscious deployment.
\subsection{Revisiting \texttt{parallel\_map}}
Even though most inference functions are CPU-bound (or GPU-bound), it turns out that sometimes they involve IO, especially when relying on the results of other remote models. This means a significant performance improvement can be achieved by implementing some inference functions asynchronously \cite{tilkov2010node}. Thus, \textit{GreatAI} also has to support decorating both regular (synchronous) and asynchronous functions. One notable consequence is that the batch processing feature must also be compatible with \texttt{async} inference functions. Batch processing is still a helpful feature since it is likely that async inference functions are both IO (remote calls) and CPU (local evaluation) constrained at the same time. Thus, they can benefit from multi-core parallelisation.
However, the standard library's \texttt{multiprocessing}, the third party \texttt{multiprocess} \cite{mckerns2012building}, and, another popular library, \texttt{joblib}\footnote{\href{https://joblib.readthedocs.io/en/latest/}{joblib.readthedocs.io/en/latest}} all lack the support for efficiently parallelising async functions. For this reason, \texttt{parallel\_map} was reimplemented to create an event-loop in each worker process to keep the efficiency of non-blocking IO while also providing parallelisation for the CPU-bound sections of code.
\subsection{Human integration}
\begin{figure}
\centering
\includegraphics[width=\textwidth]{figures/greatai-header.png}
\captionsetup{width=.9\linewidth}
\caption{The header of the automatically generated dashboard of the service from Section \ref{section:simple-case}. A generated documentation is shown on the left, while the histogram of response times is rendered on the right. The current configuration is prominently displayed on the bottom.}
\label{fig:greatai-header}
\end{figure}
Even though the REST API of \textit{GreatAI} services exposes all necessary features\footnote{Such as providing feedback per prediction, complexly filtering and sorting traces, create-read-update-delete (CRUD) operations for the feedbacks and traces, accessing live monitoring info (current configuration, versions, cache statistics), etc.} which are great for programmatic access, these are not ideal for direct human consumption. To ease the introduction of \textit{GreatAI} services, a rudimentary dashboard is --- optionally --- generated. The dashboard's main features can be observed in Figures \ref{fig:greatai-header}, \ref{fig:greatai-table}, and \ref{fig:greatai-parallel}. The diagrams and filterable/sortable table are interconnected and are automatically updated; the reactive behaviour is provided by the Dash framework \cite{shammamah_hossain-proc-scipy-2019}.
\begin{figure}
\centering
\includegraphics[width=\textwidth]{figures/greatai-table.png}
\captionsetup{width=.9\linewidth}
\caption{A dynamically updating, tabular view of traces matching a user-defined filter. Useful for exploring historical predictions or debugging the cause of exceptions (which are also searchable). The filters set in the table affect the other diagrams of the dashboard.}
\label{fig:greatai-table}
\end{figure}
\begin{figure}
\centering
\includegraphics[width=\textwidth]{figures/greatai-parallel.png}
\captionsetup{width=.9\linewidth}
\caption{A parallel coordinates view of the traces displayed in the table above. Adding new axes is as easy as calling \texttt{log\_metric} inside the inference function.}
\label{fig:greatai-parallel}
\end{figure}
\subsection{Programmatic integration}
Apart from supporting \texttt{async} calls, a couple more steps can be taken to help integrate any service with a \textit{GreatAI} deployment. This is implemented by the \texttt{call\_remote\_great\_ai} function which hides the networking required to call a \textit{GreatAI} instance's REST API. It takes care of validation, automatic retries, serialisation, and deserialisation. It comes with the added benefit of encouraging decoupled services because the friction of integrating them is no longer noticeable, which is beneficial for human collaboration \cite{hasselbring2002component}.
Additionally, a REST API is generated with its accompanying OpenAPI schema\footnote{\href{https://swagger.io/specification}{swagger.io/specification}} and served with a \href{https://swagger.io/}{Swagger} template. It also contains metadata about the function, for instance, its docstring, version, and version of its registered models concatenated in order to be SemVer\footnote{\href{https://semver.org/}{semver.org}} compatible. These can be seen in Figure \ref{fig:greatai-api}. This, combined with a \texttt{/version} HTTP endpoint for programmatic access and validation of the service's metadata, proved to be valuable features when integrating the \textit{Highlights service} into ScoutinScience's service-based architecture.
\begin{figure}
\centering
\includegraphics[width=\linewidth]{figures/greatai-api.png}
\captionsetup{width=.9\linewidth}
\caption{Documentation of the automatically scaffolded REST API of a \textit{GreatAI} service. Notice, how its version string includes its registered models in a SemVer compliant way: \texttt{0.0.1+small-domain-prediction-v11}.}
\label{fig:greatai-api}
\end{figure}

View file

@ -1,3 +0,0 @@
\chapter{Interviews} \label{chapter:interviews}
\section{Threats to validity}

View file

@ -0,0 +1,199 @@
\chapter{Results \& discussion} \label{chapter:interviews}
It should not be surprising that neither data scientists nor software engineers can be replaced by software libraries. However, a non-negligible subset of their processes can be partially or fully automated, especially when it comes to packaging and deploying AI/ML services. The objective was to design a library with an API that finds the balance between being simple enough to adopt without friction yet useful enough to be adopted. Simplicity is subjective and will be discussed separately in Section \ref{section:interviews}. For now, let us look at the utility of \textit{GreatAI}.
\section{Features} \label{section:features}
For answering \textbf{RQ3} --- \textit{To what extent can \textit{GreatAI} automatically implement AI deployment best practices?} --- a comparison is presented in the following, demonstrating a subset of best practices that can be implemented/scaffolded/configured with little user input; hence, through a simple and streamlined API. Tables \ref{table:best-practices-1} and \ref{table:best-practices-2} summarise the implemented best practices in the context of methods found by prior surveys of scientific and grey literature \cite{serban2020adoption,serban2021practices,john2020architecting}.
In order to show an accurately nuanced representation, a \textit{Level of support} is determined for each best practice on a scale of \textit{Partially supported}, \textit{Supported}, and \textit{Fully automated}. For instance, \textit{Use static analysis to check code quality} from Table \ref{table:best-practices-1} is \textit{Supported} because the entire public interface of \textit{GreatAI} is correctly typed (including generics and asynchronous coroutines) and compatible with \href{https://mypy.readthedocs.io/en/stable/index.html#}{\texttt{mypy}} and \href{https://marketplace.visualstudio.com/items?itemName=ms-python.vscode-pylance}{\texttt{Pylance}}. This means that when \textit{GreatAI} is used in any Python project, various tools can be applied to statically check the soundness of the project's integration with \textit{GreatAI}. However, if the library's user does not use type hints in their code and it contains a more complex control flow, it can only be partially type-checked. In short, this best practice is supported, and a considerable part of it is already implemented by \textit{GreatAI}, but clients should still keep in mind that they might also need to make an effort to implement it fully.
This is not the case for \textit{Log production predictions with the model's version and input data} because, by default, it is automatically implemented when calling \texttt{@GreatAI.create}. Users can still specify the exact expected behaviour, e.g., where to store traces, additional metrics to log, or disabling the logging of sensitive input. Nevertheless, the best practice is already implemented reasonably well without input from the library's user.
\begin{table}
\centering
\begin{threeparttable}
\caption{A subset of AI lifecycle best practices and the level of support \textit{GreatAI} provides for them. The level of support is one of \textit{Fully automated} (\checkmark\checkmark), which means that no action is required from the user, \textit{Supported} (\checkmark) only automates the reasonably automatable aspects, while \textit{Partially supported} ($\sim$) provides some useful features, but the client is expected to build on top of these.}
\label{table:best-practices-1}
{\renewcommand{\arraystretch}{1.2} % for the vertical padding
\begin{tabular}{P{7cm}@{\hskip 0.5cm}l@{\hskip 0cm}c} \hline
\textbf{Best practice} & \textbf{Implementation} & \textbf{Support} \\\hline
Use sanity checks for all external data sources\textsuperscript{1} & \texttt{@parameter} & \checkmark \\\hline
Check that input data is complete, balanced, and well-distributed\textsuperscript{1} & \texttt{@parameter} & $\sim$ \\\hline
Write reusable scripts for data cleaning and merging (for NLP)\textsuperscript{1} & \texttt{utilities} & \checkmark\checkmark \\\hline
Make datasets available on shared infrastructure\textsuperscript{1} & \texttt{large\_file} & \checkmark\checkmark \\\hline
Test all feature extraction code (for NLP)\textsuperscript{1} & \texttt{utilities} & \checkmark\checkmark \\\hline
Employ interpretable models when possible\textsuperscript{1} & \texttt{views} & $\sim$ \\\hline
Continuously measure model quality and performance\textsuperscript{1, 2} & Feedback API & \checkmark \\\hline
Use versioning for data, model, configurations and training scripts\textsuperscript{1, 2} & \texttt{@use\_model}, versioning & \checkmark\checkmark \\\hline
Run automated regression tests\textsuperscript{1} & \texttt{*\_ground\_truth} & \checkmark \\\hline
Use continuous integration\textsuperscript{1} & Docker Image, WSGI application & \checkmark \\\hline
Use static analysis to check code quality\textsuperscript{1} & Fully typed API with generics & \checkmark \\\hline
Assure application security\textsuperscript{1} & Code is automatically audited & $\sim$ \\\hline
Automate model deployment, enable shadow deployment\textsuperscript{1, 2} & Docker Image \& scripts & \checkmark \\\hline
Enable automatic rollbacks for production models\textsuperscript{1, 2} & Docker Image \& scripts & $\sim$ \\\hline
Continuously monitor the behaviour of deployed models\textsuperscript{1, 2} & Dashboard, metrics endpoints & \checkmark\checkmark \\\hline
Log production predictions with the model's version and input data\textsuperscript{1} & \texttt{@GreatAI.create} & \checkmark\checkmark \\\hline
\end{tabular}}
\begin{tablenotes}
\item[1] SE4ML best practices from Table 2 of \cite{serban2020adoption}, and Table 1 of \cite{serban2021practices}.
\item[2] Reported state-of-the-art and state-of-practice practices from Tables 2, 3, and 4 of \cite{john2020architecting}.
\end{tablenotes}
\end{threeparttable}
\end{table}
\begin{table}
\centering
\begin{threeparttable}
\caption{A subset of AI lifecycle best practices and the level of support \textit{GreatAI} provides for them. The level of support is one of \textit{Fully automated} (\checkmark\checkmark), which means that no action is required from the user, \textit{Supported} ($\checkmark$) only automates the reasonably automatable aspects, while \textit{Partially supported} ($\sim$) provides some useful features but the client is expected to build on top of these.}
\label{table:best-practices-2}
{\renewcommand{\arraystretch}{1.2} % for the vertical padding
\begin{tabular}{P{7cm}@{\hskip 0.5cm}l@{\hskip 0cm}c} \hline
\textbf{Best practice} & \textbf{Implementation} & \textbf{Support} \\\hline
Execute validation techniques: error rates and cross-validation\textsuperscript{2} & \texttt{*\_ground\_truth} & \checkmark \\\hline
% Track models, dependencies, experiments, versions\textsuperscript{2} & \texttt{great\_ai.use\_model}, Dashboard & \checkmark\checkmark \\\hline
Store models in a single format for ease of use\textsuperscript{2} & \texttt{save\_model} & \checkmark\checkmark \\\hline
Rewrite from data analysis to industrial development language\textsuperscript{2} & Jupyter Notebook deployment & \checkmark \\\hline
Equip with web interface, package image, provide REST API\textsuperscript{2} & \texttt{@GreatAI.create} & \checkmark\checkmark \\\hline
Provide simple API for serving batch and real-time requests\textsuperscript{2} & \texttt{@GreatAI.create} & \checkmark\checkmark \\\hline
For reproducibility, use standard runtime and configuration files\textsuperscript{2} & \texttt{utilities.ConfigFile}, Dockerfile & \checkmark \\\hline
Integration with existing data infrastructure\textsuperscript{2} & GridFS, S3 support & \checkmark\checkmark \\\hline
Select ML solution fully integrated with databases\textsuperscript{2} & MongoDB, PostgreSQL support & \checkmark\checkmark \\\hline
Querying, visualising and understanding metrics and event logging\textsuperscript{2} & Dashboard, Traces API & \checkmark\checkmark \\\hline
% Monitor status and performance\textsuperscript{1, 2} & Dashboard, Status (metadata) API & \checkmark\checkmark \\\hline
Measure accuracy of deployed model to ensure data drifts are noticed\textsuperscript{2} & Feedback API & \checkmark \\\hline
Apply automation to trigger model retraining\textsuperscript{2} & Feedback API & $\sim$ \\\hline
% Employ Agile, DevOps-style workflows, allow automatic rollback\textsuperscript{2} & Docker Image, WSGI application & \checkmark \\\hline
% Deploy different versions of same application\textsuperscript{2} & Complex versioning support & $\sim$ \\\hline
Allow experimentation with the inference code\textsuperscript{3} & Development mode \& auto-reload & \checkmark\checkmark \\\hline
Keep the model and its documentation together\textsuperscript{3} & Dashboard and Swagger & \checkmark\checkmark \\\hline
Parallelise feature extraction\textsuperscript{3} & \texttt{parallel\_map} & \checkmark\checkmark \\\hline
Cache predictions\textsuperscript{3} & \texttt{@GreatAI.create} & \checkmark\checkmark \\\hline
Allow robustly composing inference functions\textsuperscript{3} & All decorators support async & \checkmark\checkmark \\\hline
Implement standard schemas for common prediction tasks\textsuperscript{3} & \texttt{views} & \checkmark \\\hline
\end{tabular}}
\begin{tablenotes}
\item[2] Reported state-of-the-art and state-of-practice practices from Tables 2, 3, and 4 of \cite{john2020architecting}.
\item[3] Additional software engineering best practices applicable to AI/ML deployments encountered while designing and using \textit{GreatAI}.
\end{tablenotes}
\end{threeparttable}
\end{table}
\FloatBarrier
In Table \ref{table:best-practices-2}, we added six additional best practices, which are generally well-known software engineering considerations that are also applicable to AI/ML deployments. These had not explicitly made it into the aforementioned surveys; however, according to the insights gained from Sections \ref{section:simple-case} and \ref{section:complex-case}, implementing them has a positive effect on deployment quality. In future research, attention could be given to their level of industry-wide adoption and quantitative utility.
Quantifying the number of implemented best practices would be misleading since their scope and importance cover a wide range; furthermore, there is some overlap between the different studies and even within the studies. However, it is still clear that a large number of best practices (17) can be given a \textit{Fully automated} implementation by \textit{GreatAI}'s design, and many others (16) can be augmented by the library. This proves the feasibility of designing simple APIs using the techniques of Chapter \ref{chapter:design} for decreasing the complexity of correctly deploying AI services while still implementing various best practices (\textbf{RQ2}).
\section{Interviews} \label{section:interviews}
One of the central takeaways of Section \ref{section:existing} is that, for example, Seldon Core is useful for implementing or helping to implement most of the best practices. Regardless, it also has an initial threshold that must be surmounted before implementing even a single one. According to the adoption rate surveys, this may discourage a large portion of practitioners from using it or other similar frameworks. The presented solution offers a different mix of features: the initial threshold is virtually non-existent; hence, best practices can be applied immediately. But at the same time, it only covers a more limited range of practices.
Our hypothesis is that the latter approach aligns better with the expectations of professionals. To verify this, we conducted a series of interviews with the cooperation of ten industry practitioners with varying levels of Software Engineering (SE) and Data Science (DS) experience. In this section, the question of generalisability (\textbf{RQ4}) is investigated using the interview methodology described in Section \ref{section:interview-setup}. The participants were gathered through the recommendations of my friends and colleagues. All of the final interviewees have had at least some expertise in both DS (with a median of 2.5 years) and SE (with a median of 2 years).
\subsection{Best practices survey} \label{subsection:best-practices-survey-results}
The practitioners were first asked to fill out a questionnaire about their latest AI/ML project involving deployment. This point-in-time measurement (shown in Appendix \ref{appendix:practices}) served as a baseline for the deployment quality they are used to. Analysing the results show that the amount of software engineering experience has a moderately strong correlation ($r_{Pearson} = 0.67$ with $p = 0.0033$) with the overall number and extent of implemented deployment best practices. This is illustrated in Figure \ref{fig:adoption}. Interestingly but unsurprisingly, there is no similar statistically significant relationship regarding the amount of data science experience.
The y-axis of Figure \ref{fig:adoption} is calculated by discarding the \textit{Not applicable} answers and projecting the 5-point Likert scale to a range from 0 to 1, which is subsequently averaged over all questions. The overall mean adoption rate/extent is just above 0.5, which equates to the \textit{Neither agree nor disagree} label. These data are in line with the findings of Serban et al. \cite{serban2020adoption}.
Because the survey's 15 questions were compiled from the \textit{Fully automated} rows of Tables \ref{table:best-practices-1} and \ref{table:best-practices-2}, that means that when using \textit{GreatAI}, they are all implemented automatically. Consequently, the adoption rate/extent is doubled immediately just by wrapping the inference function with \texttt{@GreatAI.create}: this is the added value of \textit{GreatAI}\footnote{As explained earlier, measuring quality as a function of best practice count would be dubious. Thus, the achieved magnitude of the doubling is irrelevant; however, the direction of change is not.}. Moreover, this provides further evidence for answering \textbf{RQ3} showing the extent of automatically implemented practices over non-\textit{GreatAI} deployments.
\begin{figure}
\centering
\includegraphics[width=0.6\linewidth]{figures/best-practices.png}
\captionsetup{width=.9\linewidth}
\caption{Best practices adoption rate as a function of Software Engineering (SE) and Data Science (DS) experience. SE experience is shown on the horizontal axis, while the point sizes denote the practitioners' experience in DS. The correlation between the axes is significant ($r_{Pearson} = 0.67$ with $p = 0.0033$).}
\label{fig:adoption}
\end{figure}
\subsection{Technology acceptance}
\begin{table}[H]
\centering
\captionsetup{width=.9\linewidth}
\caption{Technology acceptance model survey (presented in Appendix \ref{appendix:questions}, sample size = 10) results per variable. The input values range from 1 to 7.}
\label{table:tam}
{\renewcommand{\arraystretch}{1.1} % for the vertical padding
\begin{tabular}{|r|l|l|l|} \hline
& \textbf{Perceived ease of use} & \textbf{Perceived utility} & \textbf{Intention to use} \\\hline
\textbf{Median} & 5.8 & 6.4 & 6.3 \\\hline
\textbf{Mean} & 5.5 & 6.1 & 6.0 \\\hline
\textbf{Standard deviation} & 1.0 & 0.9 & 1.3 \\\hline
\textbf{Cronbach's alpha} & 0.77 & 0.88 & 0.95 \\\hline
\end{tabular}}
\end{table}
The participants filled out a form (shown in Appendix \ref{appendix:questions}) after finishing their first deployment with \textit{GreatAI} to provide data for creating the technology acceptance model of the problem context. The survey contained ten questions from three categories, which could be rated on a 7-point Likert scale. The summary of the answers is presented in Table \ref{table:tam}. The high Cronbach's alpha values indicate strong internal consistency \cite{nunnally1994psychometric} for each TAM dimension; thus, averaging the responses per category is semantically meaningful.
Following the methodology of \cite{cruz2019catalog}, the connections between the Perceived Utility (PU), Perceived Ease Of Use (PEOU), and Intention To Use (ITU) dimensions of TAM were analysed. Two statistically significant ($P \leq 0.05$) correlations were uncovered: between PU and ITU ($r_{Pearson} = 0.81$ with $p = 0.0048$); and PEOU and ITU ($r_{Pearson} = 0.80$ with $p = 0.0068$). Learning from the findings of prior case studies, it is reasonable to believe that both the \textit{perceived utility} and the \textit{perceived ease of use} play an equally important role in influencing professionals' \textit{intention to use} the deployment framework.
The assessment of \textit{ease of use} lags behind the rest, but it is still quite high. It may be possible that PEOU would go up with further use. Nevertheless, the high \textit{perceived utility} implies that \textit{GreatAI} shows its value early on. This, combined with the correlations uncovered within the context's technology acceptance model, validates the hypothesis that focusing on good API design is just as necessary as providing practical features.
\subsection{Task solving \& exit interviews}
In order to give qualitative depth to the previously presented quantitative results, it is time to discuss the main segment of the interviews. The participants' backgrounds covered a vast and fascinating cross-section of industrial AI/ML. The financial sector was represented by a researcher working on market prediction models for the Hungarian State Treasury and two people building an upcoming digital bank's core services. Image processing contexts were illustrated by professionals predicting Sun activity at the European Space Agency and different ones creating pose-recognition at a startup for people with disabilities using 3D cameras. Moreover, investigating companies' AI use as part of due diligence processes and intrusion detection from network packet traces are just some of the other core activities the interviewees had been doing recently.
Stemming from this diversity, these semi-structured interviews could be expected to provide valuable insights into the generalisability of \textit{GreatAI}. The methodology of Section \ref{section:interview-setup} was followed by applying reflective journaling and thematic analysis. After labelling each aspect of the feedback, and two iterations of merging redundant or related topics, we ended up with three overarching themes: \textit{Functionality}, \textit{API}, and \textit{Responsibility to adopt}. As we will soon see, these correspond to the \textit{perceived utility}, \textit{perceived ease of use}, and \textit{intention to use} components of TAM fairly well.
\paragraph{Functionality} The library's feature-set was complimented during most interviews, with one participant noting that, although the overall number of features is relatively small, most of them are utilised in most cases. Similarly, the \texttt{utilities} submodule was appreciated for helping greatly in the interview task, but non-NLP researchers noted its likely inadequacy for their area. Still, they would like to see ``bundle'' or ``toolbox''-style modules for their fields because it would save them from a lot of copy-pasting.
The effortless parallel feature extraction and large file handling support were highlighted multiple times for the reason that the particular interviewees had not encountered other libraries providing these features. Other concrete features, such as the searchable \textit{exceptions} column in the Dashboard's table and the \textit{feedback} mechanism, were also popular. One professional highlighted the latter for coercing users to consider a human-in-the-loop approach which was said to be often expected in modern systems.
When reflecting on the framework from a bird's eye view, the generality and extensibility of the API were emphasised. As explained by a senior engineer, this is mainly because once you commit to using it, it is important not to find yourself at a dead end for a specific use case forcing you to look for a different library. However, two participants also noted that for complete generality, \texttt{MATLAB} support would be necessary. Regarding non-functional features, private hosting (especially in banking and government), open-source auditability, and good scalability (by means of an external database) were the top subjects of praise.
\paragraph{API} Regarding the surface through which clients interact with the library, the feedback is also positive but more nuanced. Many participants liked that the functions' behaviour is easy to guess from their names. The decorator syntax caused minor confusion but consulting the documentation solved the issues in all three cases. The CLI app \texttt{great-ai} was appreciated for having a close to trivial signature; the participant noted that she strives to use as few CLI commands as feasible. Surprisingly, even the practitioners with more data science background appreciated the Docker support. Nonetheless, one expert had a feature request for a configuration GUI because his colleagues are used to handling MATLAB App Designer applications.
The recurring theme of the discussions focused on the question of ``\textit{How simple is too simple?}''. The argument is that an API cannot be simpler than the domain in which it exists. More precisely, it can only be simpler at the cost of losing transparency. Let us take the example of saving models using \texttt{save\_model()}. If a project is set up correctly, it either has an initial \texttt{configure()} call to the storage provider backend, or it has an appropriately named credentials file in the project's root, for instance, \texttt{s3.ini} or \texttt{mongo.ini}. Once set up, it is trivial to use as long as we do not divert from the happy path. However, if an issue arises, such as an upgrade or migration of MongoDB, debugging the application is non-trivial for its lack of transparency.
In other words, we could say that the average (cognitive) complexity is low while the worst-case is as high --- if not higher --- than without using \texttt{save\_model()}. This proved to be somewhat controversial. However, ultimately, optimising the happy path of the AI/ML development lifecycle was deemed worthwhile by the participants in most cases. With the argument that the majority of the time spent during a project is spent on this path anyway. However, this raises the question of who exactly are the target users of \textit{GreatAI} and who will fix arising issues?
\paragraph{Responsibility to adopt} Let us first look at some insightful anecdotes that surfaced during the interviews. Especially in more research-oriented environments, production deployment pipelines can be of questionable robustness. This phenomenon was demonstrated by one account of a simple single-machine deployment pipeline: it is an interplay of \texttt{cron} jobs calling a series of shell and MATLAB scripts resembling a Rube Goldberg machine. But connecting a couple of Google Colab accounts to a GitHub repository and Weights\&Biases\footnote{\href{https://wandb.ai/site}{wandb.ai}} to implement parallel model training can also be found in the wild.
Moreover, various research companies were mentioned that for multiple years used to or still have an R\&D department consisting solely of data scientists. In one extreme case, the staff was described as more than 30 data scientists and 0 other technical employees. In such a setup, it is unreasonable to expect even professionals to have the capabilities and focus to set up the required foundation for handling all best practices. All but one interviewee verified this assumption. They also referred to their previous projects, which usually required many researchers and experts from various fields, and too often, software engineers had not been prioritised to be included.
Doing software engineering without software engineers is difficult. \textit{GreatAI} is not a viable replacement for any well-trained expert, though it is still better than nothing. During the interviews, we realised that the likely underlying reason for not employing AI engineers or software engineers as part of AI/ML projects is a lack of awareness. This was theorised by some and demonstrated by six participants who had, even though followed some, not explicitly sought out information on AI deployment best practices. Thus, raising awareness --- especially by presenting a value proposition, e.g. lower maintenance costs and better long-term quality --- might be crucial for improving AI deployments in general. Verifying this hypothesis could be a worthwhile direction for future research.
During the larger discussions, \textit{GreatAI} was deemed appropriate for raising awareness since it showcases how even a simple library is able to implement a lot of best practices. Additionally, it was noted that it could also be considered for one-person projects where --- by definition --- it is admissible to have no SE expert on the ``team''. To further help such cases, integrating a one-click Heroku\footnote{\href{https://www.heroku.com/}{heroku.com}} app deployment was also recommended to simplify the entire last portion of the lifecycle.
\subsection{Discussion of interviews}
The overall takeaway from this is that most features were well-received, and the high mean value of \textit{perceived utility} is credible. The criticism of being NLP-centric is also justified: the initial scope of the proof-of-principle framework was limited to this domain. Nonetheless, learning the experts' opinion that they wish to have a similarly specific solution to their problem contexts is reassuring because it proves that the API is not only generalisable but is expected to be generalised. At the same time, it is crucial to admit that no one-size-fits-all solution can exist for such a diverse domain. Therefore, allowing customisability and easy extension of the system must remain central design questions.
Regarding the API's level of abstraction, we have to agree with the experts that the problem of deployment cannot be ``magically'' solved by a trivial API. However, solving deployment problems can be streamlined, at least in simpler cases. At the same time, the complex ones can be left to the professionals with relevant knowledge. This parallels the AI-libraries that have inspired \textit{GreatAI}. For instance, Hugging Face \texttt{transformers} streamlines fine-tuning and applying SOTA models, but it does not provide any facilities to help you create the next SOTA architecture because that is a vastly more complex task that most users are not expected to tackle.
In order to reach its goal of improving best practice adoption, \textit{GreatAI} can help raise awareness by presenting a verifiable value proposition, i.e. a couple of lines of code can already result in more maintainable, robust, high-quality deployments. This might prompt users or technical decision-makers to invest more in software engineering in AI/ML projects. Additionally, it can help the effectiveness of AI/software engineers by handling the grunt work of implementing some best practices, leaving them with more resources to focus on the complex and creative aspects of \textit{GREAT} deployments.
In summary, the answer to \textit{How suitable is the design of GreatAI for helping to apply best practices in other contexts?} (\textbf{RQ4}) is --- unsurprisingly --- subjective. Combining the high value of \textit{intention to use} from Table \ref{table:tam}, the generally positive feedback regarding the library's added value, and the numerous feature requests for fitting it to specific needs, we conclude that there is some chance of suitability for generalisability. The existence of this potential is already exciting and presents an opportunity for experimenting with building on the design of \textit{GreatAI}.
\subsection{Threats to validity}
Two potential threats to the validity of the experiments and their results are identified. Firstly, the claimed utility of the framework derived in Subsection \ref{subsection:best-practices-survey-results} does not take into account the practical significance of the implemented features and, therefore, may be subject to bias. However, the \textit{perceived utility} evaluations indicate that the participating engineers and scientists identify practical value in the features of \textit{GreatAI}. Nevertheless, in the future, we intend to extend the range of implemented best practices, which would in turn, give higher confidence about the achievable quantitative improvement through using the library.
Secondly, the survey answers and, in general, the interviewees may be subject to bias. The small sample size of practitioners can reasonably lead to some groups being over- or under-represented. The presence of selection bias is also plausible. These could be mitigated by gathering more data in future research. Coming from the exploratory nature of this analysis, many insights could be gained from the collected data. However, for confidently generalising the results, more data are needed.
\section{Future work}
The primary purpose of the library was to serve as a proxy through which its design decisions could be tested and evaluated in their practical context. For this reason, its design aimed to be a proof-of-principle for validating hypotheses and answering research questions. After successfully doing that, it has been turned into a practical software library suitable for production-use\footnote{Available at \href{https://pypi.org/project/great-ai/}{pypi.org/project/great-ai} and \href{https://hub.docker.com/repository/docker/schmelczera/great-ai}{hub.docker.com/repository/docker/schmelczera/great-ai}.}.
The library's main limitations come from its bias toward NLP deployments. This is not unreasonable given the design's exploratory nature and the context of the case studies. Nevertheless, future work must focus on introducing and balancing support for many more fields' deployments. Although \textit{GreatAI} has already proved its utility, it has also shown that generalising and extending its functionality would be worthwhile. Therefore, many potential improvements are presented below.
\subsection{More ML domains and modalities}
The cases presented in Chapter \ref{chapter:case} revolved around NLP. This, of course, heavily influenced the design process. The two most notable effects can be found in the REST API's \texttt{/predict} endpoint and some \texttt{utilities} functions. The former is streamlined to accept JSON-compatible data (which caters to textual and tabular data), while the latter gives robust feature extraction support only for textual input. However, in practice, sound, image, and video are also widely taken as input. Furthermore, with the rise of multimodal models \cite{gao2020survey}, even different combinations of them may be simultaneously taken as input.
Supporting the easy, direct upload of larger non-JSON files --- e.g. by saving them to S3 and showing a preview of them on the Dashboard's traces table --- and extending \texttt{utilities} to handle multimedia formats should be sufficient for counteracting the NLP bias. Hence, widely expanding the scope of applicability of \textit{GreatAI}. As we have seen in Section \ref{section:architecture}, the architecture is otherwise adequately general; therefore, incremental extensions can be applied.
\subsection{More best practices}
In order to greatly simplify its API, each \textit{GreatAI} Trace is a single document with a well-defined schema that clients can also extend by calling \texttt{log\_metric}. MongoDB provides a convenient (and popular) method for persisting such documents; however, if there is some existing database in the environment, storing Traces in that can be favourable. PostgreSQL \cite{momjian2001postgresql} is a popular choice, and it also features good JSON document support. Hence, introducing first-class integration for PostgreSQL could benefit some clients.
Data-intensive services can fall into three broad categories: online systems, batch processing, and stream processing (near-teal-time systems) \cite{kleppmann2017designing}. As of yet, \textit{GreatAI} only provides streamlined support for the first two. Thus, developer experience could be improved by providing simple, direct integration with popular message queues/protocols, such as \href{https://kafka.apache.org/}{Apache Kafka} \cite{kreps2011kafka}, \href{https://aws.amazon.com/sqs/}{AWS SQS} \cite{garfinkel2007evaluation}, or \href{https://www.amqp.org/}{AMQP} \cite{vinoski2006advanced}. Moreover, some metrics of \textit{GreatAI}, such as the cache statistics, versions, and derived data from traces, can already be conveniently queried from its REST API. Nevertheless, adding support for the de facto standard metric gathering tool, Prometheus\footnote{\href{https://prometheus.io/}{prometheus.io}}, could save the library's users from one more integration step.
The common theme among the opportunities mentioned above is that they could be implemented reasonably well without any user input, which aligns with the library's philosophy. Of course, the open-source nature of \textit{GreatAI} already allows anyone to provide support for a wide range of integrations. Additionally, the scope could be reasonably extended, i.e. more practices could be incorporated by including more criteria next to the \textit{GREAT} ones.

View file

@ -1,7 +1,15 @@
\chapter{Conclusion} \label{chapter:conclusion} \chapter{Conclusion} \label{chapter:conclusion}
% 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 Concerned by the asymmetry between the industry's adoption of accessible AI/ML-libraries and existing solutions for their robust deployment, we investigated this phenomenon's causes and potential resolution. When looking at various recent case studies, a recurring theme was revealed: \textit{transitioning} from prototypes to production-ready AI/ML deployments is a source of adversity for small and large enterprises alike. Even though several frameworks and platforms exist for facilitating this step, surveys on the execution of best practices continue to expose the industry's shortcomings. This signals that existing libraries are underutilised, which may lead to poor deployments that underperform or develop issues that go unnoticed and might inflict societal harm.
\section{Future work} We hypothesised that presenting a library which implements best practices and is also optimised for ease of adoption could help increase the overall quality of industrial AI/ML deployments. To test this, we designed and implemented a framework based on the principles of cognitive science and the prior art of software design. Subsequently, we tested and refined the design in an iterative process. First, we developed and deployed a model for classifying the domains of academic publications. Then, we fine-tuned and deployed a SciBERT model for generating publications' technology-transfer summaries. \textit{GreatAI} had been proven helpful; therefore, after feeding back the insights gained into its design, we turned it into an open-source library. Furthermore, \textit{GreatAI} has been successfully integrated into every production deployment of ScoutinScience since then and receives thousands of monthly downloads.
\section{Concluding remarks} During the refinement of the framework, six previously unaddressed AI/ML deployment best practices were identified. Including these, the framework fully implements 17 best practices while it provides support for another 16. We validated the value provided by implementing or helping to implement these practices through interviews with ten industry professionals from various subfields.
The interview participants completed two questionnaires, the results of one of which indicated that using \textit{GreatAI} in an example task increased the number of implemented best practices, on average, by 49\% compared with their latest project. We also calculated the technology acceptance model of the context; a significantly strong correlation was measured between the \textit{perceived ease of use}, the \textit{perceived utility} and the \textit{intention to use} dimensions. Overall, proving that ease of use is just as important as core functionality when adopting AI deployment frameworks.
The open-ended exit interviews revealed that value can be derived from the library even in its current form and that the API's design has the opportunity to generalise to other fields of industrial AI/ML applications. However, they also highlighted that adoption issues do not necessarily come from a lack of willingness but a lack of awareness. Even if the returns achievable from good deployments are well worth the investment. Nevertheless, this value proposition needs to be conveyed and proved to data science professionals and technical decision-makers; and \textit{GreatAI} might just be the ideal candidate for doing that.
\textit{GreatAI} may 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 needed for robust and improvable deployments. At the same time, it also saves them from the menial work of manually implementing these constructs. While most importantly, it proves that increasing the adoption rate of AI/ML deployment best practices is feasible by designing narrower and deeper APIs.
Good deployments benefit all of us. Accordingly, continued research into the means of good deployments remains crucial. However, next to that --- as the presented results have shown --- better deployments can also be achieved by facilitating the \textit{transition} step of the AI lifecycle with a focus on adoptability. Having automated implementations, even if for just the straightforward best practices, leaves professionals additional time to tackle the more complex deployment challenges and fewer opportunities to miss critical steps. Overall, resulting in more general, robust, end-to-end, automated, and trustworthy AI deployments.

View file

@ -0,0 +1,52 @@
\appendix
\chapter{Best practices assessment} \label{appendix:practices}
Similarly to the approach of \cite{serban2020adoption}, participants are asked about their team's level of adoption of AI/ML deployment best practices. The questions come from the entries of Tables \ref{table:best-practices-1} and \ref{table:best-practices-2} where \textit{GreatAI} was determined to provide a support level of \textit{Fully automated}.
\textbf{How well did the previous AI deployment that you collaborated on implement the following best practices?} \textit{Each statement can be rated on a 5-point Likert scale or as ``Not applicable''.}
\begin{enumerate}
\item Write reusable scripts for data cleaning and merging
\item Make datasets available on shared infrastructure
\item Use versioning for data, model, configurations and training scripts
\item Continuously monitor the behaviour of deployed models
\item Log production predictions with the model's version and input data
\item Store models in a single format for ease of use
\item Equip with a web interface, package image, provide REST API
\item Provide simple API for serving batch and real-time requests
\item Integration with existing data infrastructure
\item Querying, visualising and understanding metrics and event logging
\item Allow experimentation with the inference code
\item Keep the model and its documentation together
\item Parallelise feature extraction
\item Cache predictions
\item Allow robustly composing inference functions
\end{enumerate}
\chapter{TAM questionnaire} \label{appendix:questions}
Following the methodology for the parsimonious technology acceptance model of Wu et al. \cite{wu2011user}, each statement can be rated on a 7-point Likert scale.
\paragraph{Perceived usefulness (PU)}
\begin{enumerate}
\item I believe the use of \textit{GreatAI} improves the quality of AI deployments.
\item I believe the use of \textit{GreatAI} would increase my productivity.
\item I believe the use of \textit{GreatAI} can lead to robust and trustworthy deployments.
\item Overall, I found \textit{GreatAI} useful when working with AI.
\end{enumerate}
\paragraph{Perceived ease of use (PEOU)}
\begin{enumerate}
\item I found the \textit{GreatAI} easy to learn.
\item I found it is easy to employ \textit{GreatAI} in practice.
\item I found it is easy to integrate \textit{GreatAI} into an existing project.
\item Overall, I found \textit{GreatAI} easy to use.
\end{enumerate}
\paragraph{Intention to use (ITU)}
\begin{enumerate}
\item Assuming \textit{GreatAI} is applicable to my task, I predict that I will use it on a regular basis in the future.
\item Overall, I intend to use the \textit{GreatAI} in my personal or professional projects.
\end{enumerate}

Binary file not shown.

After

Width:  |  Height:  |  Size: 920 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 779 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 165 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 57 KiB

Some files were not shown because too many files have changed in this diff Show more