aitech-pbr2022/08_ci_cd_uczenie_maszynowe.ipynb

Przygotowanie do projektu badawczo-rozwojowego

8. Ciągła integracja i ewaluacja w projektach opartych na uczeniu maszynowym [wykład]

Filip Graliński (2022)

Ciągła integracja i ewaluacja w projektach opartych na uczeniu maszynowym

Dobre praktyki w tradycyjnej inżynierii oprogramowania

Ciągła integracja

Ciągła integracja (_continuous integration, CI) to praktyka stosowana w tworzeniu oprogramowania polegają na częstym integrowaniu kodu opracowywanego przez programistów, zautomatyzowanym budowaniu oprogramowania i poddawaniu go testom.

Ciągłe wdrażanie

Ciągłe wdrażanie (_continuous deployment, CD) automatyzuje również proces wdrażania oprogramowania. Oznacza to, że również procedura wdrażania musi zostać wyrażona jako kod przechowywany w systemie kontroli wersji.

Ciągła integracja/ciągłe wdrożenie zazwyczaj współwystępuje z metodyką DevOps.

CI/CD/DevOps w jednym zdaniu: robię to tak często, że to „nic takiego”.

CI/CD a uczenie maszynowe

Dodanie do systemu modułów opartych na uczeniu maszynowym bardzo komplikuje proces CI/CD:

• modele uczenia maszynowego (np. sieci neuronowe) powstają na bazie kodu źródłowego odpowiedzialnego za uczenie i danych uczących,
• osobny kod jest odpowiedzialny za inferencję,
• choć kod odpowiedzialny za uczenie i inferencję w miarę możliwości powinny podlegać standardowej metodologii testowania (np. testy jednostkowe), to ostatecznie testy systemów opartych na uczeniu maszynowym nie mają postaci zerojedynkowej
• … raczej system może uzyskać lepszy albo gorszy wynik,
• wdrożenie (a przynajmniej uczenie) wymaga często dużych zasobów obliczeniowych i specjalnego sprzętu (karty graficzne).

Przy czym chcielibyśmy zachować „złote” zasady CI/CD.

Wprowadzenie uczenia maszynowego do oprogramowania na tyle zmienia sytuację, że mówi się o MLOps zamiast DevOps.

Proces CI/CD rozszerzony o uczenie maszynowe

Testowanie systemów opartych na uczeniu maszynowym

Podobnie jak w wypadku tradycyjnego oprogramowania testowanie modeli uczenia maszynowego przyjmuje wiele form:

• testy jednostkowe fragmentu kodu odpowiedzialnego za uczenie i inferencję,
• testy uczenia i inferencji na spreparowanych danych
  • _corner cases
  • uczenia „w kółko” na jednym przykładzie (czy funkcja kosztu spada do zera?)
• testy inferencji na danych „śmieciowych” (czy system jest w stanie „przetrwać” wszystko?)
• testy efektywności, przepustowości itp.
• … lecz ostatecznie najistotniejsza jest odpowiedź na pytanie, jak dobry jest wynik na danych zbliżonych do rzeczywistych (ewaluacja)

Ewaluacja

Rodzaje ewaluacji:

• testy „na ludziach”,
  • testy A/B, analiza zachowania użytkownika
  • ewaluacja manualna, np. test MOS (_mean-opinion score)
• ewaluacja automatyczna
  • ewaluacja według wzoru
  • ewaluacja wyuczana przy użyciu uczenia maszynowego (!)

Ostateczne kryterium ewaluacji: _money in the bank, a właściwie _utility in the bank (por. aksjomatyczna teoria użyteczności sformułowana przez Johna von Neumanna i Oskara Morgensterna).

Psychologiczne pułapki oceniania

• efekt pierwszeństwa — _błędy pojawiające się na początku wypracowania oceniane są surowiej niż błędy na końcu wypracowania

• efekt świeżości

• efekt „aureoli” — _mamy skłonność do przypisywania innych pozytywnych cech ludziom atrakcyjnym fizycznie

• wpływ nastroju na ocenianie — _w pochmurne dni ludzie gorzej oceniają stan gospodarki niż w słoneczne

Słabości „potocznej” matematyki

Czy symptom świadczy o chorobie?

|         |           | choroba |               |
|         |           | obecna  | nieobecna     |
|---------+-----------+---------+---------------|
| symptom | obecny    | 37      | 33            |
|         | nieobecny | 17      | 13            |

85% przepytanych pielęgniarek doszło do wniosku, że istnieje związek między symptomem a chorobą.

Korelacja jest przez ludzi przeceniana, regresja do średniej — niedoceniania

Jak uniknąć pułapek oceniania?

• stosować obiektywne miary,
• najlepiej wymyślić syntetyczną funkcję oceny (pojedyncza liczba),
• jeśli to możliwe, stosować automatyczną ewaluację.

Konkretny sposób ewaluacji nazywamy miarą lub metryką ewaluacji. (Uwaga: nie ma nic wspólnego z terminami stosowanymi w matematyce!).

Definicja metryki ewaluacji

Ewaluację przeprowadzamy na ciągu danych wejściowych $(x)_i$ biorąc pod uwagę oczekiwane wyjście $(y)_i$ i rzeczywiste wyjście z systemu $(\hat{y})_i$. Funkcja (metryka, miara) ewaluacji $\mu$ powinna zwrócić skalarną wartość określającą jakość systemu, innymi słowy:

$$\mu \colon X^{n} \times Y^{n} \times \hat{Y}^{n} \to \mathcal{R},$$

gdzie $X$ jest zbiorem możliwych wejść, $Y$ — zbiorem możliwych specyfikacji oczekiwanych wyjść, $\hat{Y}$ — zbiorem możliwych wyjść (na ogół $Y = \hat{Y}$, ale mogą być sytuacje, gdzie specyfikacja oczekiwanego wyjścia jest bardziej skomplikowana).

Olbrzymia większość metryk ewaluacji nie bierze pod uwagę wejścia, lecz jedynie porównuje wyjście z systemu z oczekiwanym wyjściem, a zatem schemat upraszcza się do:

$$\mu \colon Y^{n} \times \hat{Y}^{n} \to \mathcal{R}.$$

Metryka ewaluacji — przykłady

Jedną z najprostszych metryk ewaluacji jest dokładność (_accuracy) jest to po prostu odsetek przypadków, gdy wyjście z systemu jest identyczne z oczekiwanym wyjściem.

Narzędzie ewaluacyjne GEval ma zaimplementowane kilkadziesiąt (!) metryk ewaluacji

-m,--metric METRIC       Metric to be used, e.g.:RMSE, MSE, MAE, SMAPE,
                         Pearson, Spearman, Accuracy, LogLoss, Likelihood,
                         F1.0, F2.0, F0.25, Macro-F1.0, Macro-F2.0,
                         Macro-F0.25, MultiLabel-F1.0, MultiLabel-F2.0,
                         MultiLabel-F0.25, Mean/MultiLabel-F1.0,
                         Probabilistic-MultiLabel-F1.0,
                         Probabilistic-MultiLabel-F2.0,
                         Probabilistic-MultiLabel-F0.25,
                         MultiLabel-Likelihood, MAP, NDCG@3, BLEU, GLEU
                         ("Google GLEU" not the grammar correction metric),
                         WER, CER (Character-Error Rate), WAR, CAR
                         (Character-Accuracy Rate (1-CER)), NMI, ClippEU,
                         LogLossHashed, LikelihoodHashed, PerplexityHashed,
                         BIO-F1, BIO-Weighted-F1, BIO-F1-Labels,
                         TokenAccuracy, SegmentAccuracy, Soft-F1.0, Soft-F2.0,
                         Soft-F0.25, Probabilistic-Soft-F1.0,
                         Probabilistic-Soft-F2.0, Probabilistic-Soft-F0.25,
                         Probabilistic-Soft2D-F1.0, Probabilistic-Soft2D-F2.0,
                         Probabilistic-Soft2D-F0.25, Soft2D-F1.0, Soft2D-F2.0,
                         Soft2D-F0.25, Haversine, CharMatch, Improvement@0.5,
                         MacroAvg/Likelihood, MSE-Against-Interval,
                         RMSE-Against-Interval, MAE-Against-Interval,
                         BLEU:lm<\s+|[a-z0-9]+> (BLEU on lowercased strings,
                         only Latin characters and digits considered)

Jakie własności ma dobra miara ewaluacji?

• spełnia zdroworozsądkowe aksjomaty

  • w szczególności dla przypadków brzegowych
  • jest stabilna

• koreluje z ludzką oceną

  • a tak naprawdę z preferencjami użytkowników

Ewaluacja ewaluacji! — czyli metaewaluacja

Z powrotem do CI/CD

Ewaluację można zatem traktować jako rozszerzenie procesu testowania oprogramowania. Ewaluacja nigdy nie powinna być jednorazowym procesem, powinna być wpleciona w proces CI/CD. Możemy więc mówić o ciągłej ewaluacji.

Potrzeba ciągłego procesu, by upewnić się, że nasz system oparty na uczeniu maszynowym:

• jest lepszy od prostego punktu odniesienia (_naive baseline),
• jest lepszy od rozwiązań konkurencji,
• jest lepszy od systemu, który mieliśmy wczoraj, tydzień temu, rok temu…

Dobór metryki ewaluacji — tłumaczenie maszynowe

Jaka metryka jest najlepsza do oceny systemu tłumaczenia maszynowego?

To zależy!

Scanariusz A. Automatyczne tłumaczenie jest używane przez osoby nieznające języka docelowego w celu zrozumienia oryginalnego tekstu.

Scenariusz B. Oczekujemy bardzo dobrej jakości tłumaczenia. Tłumaczenia maszynowe są poprawiane przez profesjonalnych tłumaczy, tłumaczenie maszynowe służy do przyspieszenia procesu.

W scenariuszu A można zastosować standardowe metryki tłumaczenia maszynowego sprawdzające, na ile w tłumaczeniu zachowane elementy tłumaczenia referencyjnego, np. BLEU albo — lepiej — COMET, natomiast w scenariuszu B lepiej zastosować odległość edycyjną w celu oszacowania kosztu korekty.

Przykład systemu ewaluacji — GEval i Gonito

GEval to biblioteka w języku Haskell oraz narzędzie do ewaluacji uruchamiane z wiersza poleceń, zaś Gonito to oparta na bibliotece GEval aplikacja webowa, platforma do ewaluacji wyzwań uczenia maszynowego.

System na produkcji, a my nie znamy oczekiwanych wartości!

Estymacja jakości

Uruchomiliśmy nasz system w wersji produkcyjnej, skąd wiemy, że system zachowuje się poprawnie?

Można anotować lub poprawiać manualnie próbki danych produkcyjnych, rozszerzać w ten sposób zbiory testowe i dokonywać na nich ewaluacji.

Można też stosować metody estymacji jakości (_quality estimation), tzn. przewidywać jakość wyłącznie na podstawie wyjścia (bez znajomości oczekiwanego wyjścia). Na przykład w systemie tłumaczenia maszynowego można w tym celu stosować model języka docelowego.

Zadania proponowane na laboratoria

Zadanie 1.

Skonfigurujcie minimalne zadanie uczenia maszynowego na dowolnym serwerze ciągłej integracji (Jenkins, GitLabCI, GitHub Actions itp.). Zadanie powinno obejmować wyuczenie prostego modelu i ewaluację.

Zadanie 2.

Dokonajcie konwersji wybranego zbioru danych do standardu wyzwania Gonito. Zob. szczegółowe instrukcje odnośnie do tworzenia wyzwania.

Zadanie 3.

Dopiszcie nowe przypadki testowe dla wybranej metryki ewaluacji w programie GEval. Zob. przykład testów dla nowej metryki (od pliku test/Spec.hs).