A/B testy modelu ML (część 1). Jak przygotować A/B testy?

Jeśli zajmujesz się dziedziną uczenia maszynowego, na pewno słyszałeś o testach A/B. Jest to najlepszy i najbardziej wiarygodny eksperyment, jaki możemy przeprowadzić, żeby potwierdzić dobre działanie naszego modelu.

W tym wpisie powiem więcej, co to są A/B testy i z czego się składają. Jest to pierwszy z serii trzech wpisów w tym temacie. Kolejne to:

I. Co to są A/B testy?

Testy A/B zostały wymyślone jako metoda testowania zmian na stronie internetowej lub w aplikacji. Najczęstszym ich zastosowaniem jest poprawa współczynnika konwersji poprzez określenie, która wersja strony działa lepiej, a następnie wykorzystanie tej wersji jako podstawy do dalszego rozwoju. Mogą być one również stosowane do testowania innych aspektów systemu, takich jak użyteczność, czytelność lub zapamiętywalność.

W teście A/B dwie wersje są pokazywane dwóm grupom użytkowników. Wyniki są mierzone dla każdej grupy, a następnie analizowane w celu sprawdzenia, czy różnice między grupami wystąpiły przypadkowo, czy też wynikały z jakiejś różnicy między wersjami tego, co było testowane.

W kontekście budowy modeli Machine Learning, A/B testy mogą być rozumiane szerzej – jako ostateczne potwierdzenie w świecie rzeczywistym, że nasz model działa lepiej niż dotychczasowe algorytmy lub działania człowieka. Możemy też A/B testować dwa różne modele lub ich wersje.

A/B testować można większość zastosowań Machine Learningu w różnych branżach, np. systemy predykcyjne, rekomendacyjne, czy to w świecie online, czy w świecie rzeczywistym, jak np. predykcje sprzedażowe.

Ważne jest, że w teście A/B porównujemy obie grupy w tym samym czasie, dzięki czemu jesteśmy w stanie uniknąć wpływu wszelkich zjawisk, które mogą np. niezależnie od modelu zwiększyć sprzedaż z powodu wyjątkowo dobrego okresu lub ją zmniejszyć z powodu kryzysu.

II. Przebieg A/B testów

Przebieg A/B testu składa się z następujących kroków:

Zaimlementowanie modelu na produkcji.
Podział przestrzeni działania modelu na dwie grupy.
Ustalenie zakresu eksperymentu.
Zbieranie danych.
Analiza ich i wyciągnięcie wniosków.

Poniżej schemat zapożyczony z testowania stron internetowych, ale zarys jest ten sam:

Źródło: https://venturebeat.com/marketing/why-most-ab-tests-give-you-bullshit-results/

Poniżej omówię szerzej punkty 2, 3 i 4.

A. Podział na grupy

Jak wspomniałem wyżej, kluczowe jest podzielenie interakcji z naszym modelem na dwie możliwie identyczne grupy. Chodzi o to, abyśmy mogli uniknąć jakiegokolwiek wpływu innych czynników na oba uzyskane rezultaty i aby dało się je porównać ze sobą.

Sytuacja jest względnie prosta, gdy mamy do czynienia ze stroną internetową o dość dużym ruchu, kiedy możemy każdemu odwiedzającemu użytkownikowi pokazać losowo jedną lub drugą wersję strony.

Sprawa staje się nieco bardziej skomplikowana, gdy chcemy trzymać się założenia, że jeden użytkownik zawsze dostanie tę samą wersję, niezależnie po ilu dniach odwiedzi stronę, ale z tym można sobie poradzić na przykład za pomocą plików cookies.

Wyzwaniem jest podział na grupy większych elementów, takich jak całe kampanie marketingowe lub sklepy. Wyobraźmy sobie, że nasz algorytm ML ma optymalizować kampanię marketingową danego produktu poprzez wyświetlanie na odpowiednich stronach internetowych. Aby porównanie było wiarygodne, powinniśmy stworzyć dokładnie taką samą kampanię, której nie optymalizuje nasz algorytm (tylko np. człowiek). Jednak w praktyce te kampanie nigdy nie będą identyczne, bo na przykład jeśli w jednej z nich wyświetlamy reklamę w danym miejscu na danej stronie, to druga kampania nie może w tym samym czasie skorzystać z tego miejsca.

Problem jest jeszcze trudniejszy, gdy kampania jest tworzona w jakiejś platformie, typu Facebook, która ma swoje algorytmy optymalizacyjne. Może się okazać, że będą one w jakiś sposób ingerować w nasz algorytm i wówczas porównanie dwóch kampanii w wiarygodny sposób będzie bardzo trudne.

Jak radzić sobie z tymi problemami, opowiadam w kolejnym artykule.

B. Ustalenie zakresu eksperymentu. Zadbanie o istotność statystyczną.

Istotność statystyczna wyniku to prawdopodobieństwo, że zaobserwowana różnica między dwiema grupami nie wynika z przypadku. Jest to ważne, gdy przeprowadzamy A/B testy, gdyż jeśli o to nie zadbamy, różnice w wynikach mogą być zupełnie przypadkowe i wówczas wyprowadzimy z nich błędne wnioski.

Wielkość próby zależy od poziomu ufności, jaki chcemy uzyskać oraz od planowanego czasu eksperymentów.

Ponieważ przeprowadzanie rzeczywistych A/B testów może być dość kosztowne, oszacowanie wielkości próby oraz czasu trwania eksperymentu warto zasymulować na danych historycznych albo obliczyć, korzystając z metod statystycznych i zakładanych rozkładów prawdopodobieństwa.

Polega to na tym, że najpierw wyznaczamy oczekiwane KPI naszego modelu, przykładowo zwiększenie konwersji o 5%. Następnie przeprowadzamy dla różnych długości eksperymentów i różnych wielkości próbek, np. 1000 symulacji dwóch modeli – jednego o współczynniku konwersji takim, jak dotychczas, a drugiego o 5% lepszego (losujemy z odpowiedniego rozkładu). Patrzymy, jakie w rzeczywistości osiągnięto różnice. Dla niektórych eksperymentów różnica wyników między obiema wersjami może wynosić 4%, dla innych 10%, a dla niektórych nawet drugi algorytm może wypaść gorzej. Dlatego dobieramy taką długość eksperymentu i wielkość próby, aby np. w 950/1000 przypadkach drugi algorytm był lepszy o co najmniej 2%.

To samo można obliczyć bez symulacji, jeśli wiemy, że wyniki modelu są dość dobrze symulowane przez pewien rozkład, np. normalny. Wówczas możemy przetestować hipotezę zerową, że drugi algorytm jest nie lepszy od pierwszego o co najmniej 5% i obliczyć teoretycznie wielkość próby, która nam pozwoli odrzucić hipotezę zerową np. z prawdopodobieństwem 95%.

C. Zbieranie danych z eksperymentu

Przy przebiegu eksperymentu gromadzimy dane o uzyskanych wynikach, a także wszelkie dodatkowe informacje o działaniu modelu, które nam pozwolą na późniejszą analizę jego jakości.

Gromadząc dane z eksperymentu, powinieneś z każdym eventem trzymać dodatkowo informację o tym, która wersja A/B systemu wygenerowała ten event.
Jeśli nie możesz sprawnie wdrożyć takiego narzędzia, ale możesz w łatwy sposób losowo wygenerować dwie grupy A/B, to można podział na A i B wykonać prostą deterministyczną funkcją np. id użytkownika modulo 2. Dzięki temu unikniesz konieczności trzymania przypisania do grupy A i B i synchronizacji tej informacji między różnymi modułami systemu.