Test A/B dwóch wersji modelu

Po wytrenowaniu nowego modelu niestandardowego możesz użyć funkcji A/B Testing, aby sprawdzić, jak nowy model sprawdza się w rzeczywistych warunkach w porównaniu z modelem, którego już używasz. Gdy potwierdzisz, że nowy model jest lepszy, możesz łatwo wdrożyć go u wszystkich użytkowników bez konieczności aktualizowania aplikacji.

Na tej stronie pokazujemy, jak przeprowadzić test A/B, który ocenia 2 wersje modelu obsługującego hipotetyczną funkcję wizualnego wyszukiwania roślin. Ta funkcja korzysta z niestandardowego modelu etykietowania obrazów, aby pomóc użytkownikom rozpoznawać gatunki roślin na podstawie ich zdjęć.

Załóżmy, że właśnie opublikowano nowy model etykietowania roślin plant_labeler_v2 i chcesz przeprowadzić eksperyment, który porówna go z obecnym modelem o nazwie plant_labeler_v1. Poniżej znajdziesz instrukcje konfigurowania eksperymentu, stosowania go i podejmowania działań na podstawie jego wyników.

1. Zdalne konfigurowanie modelu

Pierwszym krokiem w testowaniu modeli A/B jest zmodyfikowanie aplikacji tak, aby używała Remote Configparametru do określania, którego modelu ma używać. Początkowo ustawisz domyślną wartość tego parametru na model, którego aplikacja już używa, ale ponieważ nazwa modelu jest kontrolowana przez parametr konfigurowany zdalnie, możesz zmieniać i testować różne modele bez konieczności przesyłania użytkownikom aktualizacji aplikacji za każdym razem.

Jeśli więc opublikujesz obecny model pod nazwą plant_labeler_v1, w kodzie inicjowania aplikacji ustawisz plant_labeler_v1 jako wartość domyślną parametru plant_labeler_model, jak w tym przykładzie:

val remoteConfig = FirebaseRemoteConfig.getInstance()

val remoteConfigDefaults = HashMap<String, Any>()
remoteConfigDefaults["plant_labeler_model"] = "plant_labeler_v1"
Tasks.await(remoteConfig.setDefaultsAsync(remoteConfigDefaults))

remoteConfig.fetchAndActivate().addOnSuccessListener { success ->
    if (success) {
      // Okay to get remote values.
      // ...
    }
}

final FirebaseRemoteConfig remoteConfig = FirebaseRemoteConfig.getInstance();

Map<String, Object> remoteConfigDefaults = new HashMap<>();
remoteConfigDefaults.put("plant_labeler_model", "plant_labeler_v1");
Tasks.await(remoteConfig.setDefaultsAsync(remoteConfigDefaults));

remoteConfig.fetchAndActivate().addOnSuccessListener(
        new OnSuccessListener<Boolean>() {
            @Override
            public void onSuccess(Boolean success) {
                if (success) {
                  // Okay to get remote values.
                  // ...
                }
            }
        });

Następnie zmień kod konfiguracji modelu, aby wczytać model określony przez parametr plant_labeler_model:

val rcValue = remoteConfig.getValue("plant_labeler_model")
val remoteModelName = rcValue.asString()

// ...

val remoteModel = FirebaseRemoteModel.Builder(remoteModelName)
        .enableModelUpdates(true)
        .setInitialDownloadConditions(initialConditions)
        .setUpdatesDownloadConditions(updateConditions)
        .build()
FirebaseModelManager.getInstance().registerRemoteModel(remoteModel)

// Optionally configure a local model:
// https://firebase.google.com/docs/ml/android/use-custom-models#configure_a_local_model

FirebaseRemoteConfigValue rcValue = remoteConfig.getValue("plant_labeler_model");
String remoteModelName = rcValue.asString();

// ...

FirebaseRemoteModel remoteModel = new FirebaseRemoteModel.Builder(remoteModelName)
        .enableModelUpdates(true)
        .setInitialDownloadConditions(initialConditions)
        .setUpdatesDownloadConditions(updateConditions)
        .build();
FirebaseModelManager.getInstance().registerRemoteModel(remoteModel);

// Optionally configure a local model:
// https://firebase.google.com/docs/ml/android/use-custom-models#configure_a_local_model

Teraz, gdy aplikacja używa parametru Remote Config do określania, który model ma wczytać, możesz zmienić model, publikując nowy model i przypisując jego nazwę do parametru Remote Config. Ta funkcja umożliwia A/B Testing przypisywanie różnych modeli do różnych użytkowników w celu ich porównania.

Zanim przejdziesz dalej, dodaj też do kodu pobierania modelu ten fragment:

FirebaseModelManager.getInstance().downloadRemoteModelIfNeeded(remoteModel)
    .addOnSuccessListener {
        // If the model downloaded was specified by a remote parameter, log an
        // event, which will be our experiment's activation event.
        if (rcValue.source == FirebaseRemoteConfig.VALUE_SOURCE_REMOTE) {
            FirebaseAnalytics.getInstance(this).logEvent("nondefault_model_downloaded", null)
        }
    }

FirebaseModelManager.getInstance().downloadRemoteModelIfNeeded(remoteModel)
        .addOnSuccessListener(new OnSuccessListener<Void>() {
            @Override
            public void onSuccess(Void aVoid) {
                // If the model downloaded was specified by a remote parameter, log an
                // event, which will be our experiment's activation event.
                if (rcValue.getSource() == FirebaseRemoteConfig.VALUE_SOURCE_REMOTE) {
                    FirebaseAnalytics.getInstance(YourActivity.this)
                            .logEvent("nondefault_model_downloaded", null);
                }
            }
        });

Powyższy kod rejestruje niestandardowe zdarzenie Analytics, które później wykorzystasz jako zdarzenie aktywacji eksperymentu. Zdarzenie aktywacji to zdarzenie, które użytkownik musi wywołać, zanim zostanie uznany za uczestnika eksperymentu. Dzięki temu użytkownicy nie będą rejestrowani w teście A/B, dopóki ich urządzenia nie pobiorą niestandardowego modelu ML.

2. Określanie wartości docelowej

Następnym krokiem jest określenie, jak będziesz mierzyć skuteczność modelu, i upewnienie się, że aplikacja zbiera dane niezbędne do testowania, jak różne wersje modelu działają zgodnie z tym wskaźnikiem.

A/B Testing ma kilka wbudowanych danych, w tym przychody, dzienne zaangażowanie i utrzymanie użytkowników. Te dane są często przydatne do testowania różnych ścieżek UX lub dostrajania parametrów, ale mogą nie być odpowiednie do oceny modelu i przypadku użycia. W takiej sytuacji możesz spróbować zoptymalizować kampanię pod kątem niestandardowego zdarzenia Analytics.

Na przykładzie hipotetycznej funkcji wyszukiwania wizualnego roślin załóżmy, że wyświetlasz użytkownikowi wyniki wyszukiwania w kolejności zgodnej z pewnością modelu co do każdego wyniku. Jednym ze sposobów na sprawdzenie dokładności modelu jest sprawdzenie, jak często użytkownicy otwierali pierwszy wynik wyszukiwania.

Aby sprawdzić, który model najlepiej realizuje cel, jakim jest maksymalizacja kliknięć pierwszego wyniku, rejestruj zdarzenie niestandardowe za każdym razem, gdy użytkownik kliknie pierwszy element na liście wyników.

FirebaseAnalytics.getInstance(this).logEvent("first_result_opened", null)

FirebaseAnalytics.getInstance(YourActivity.this).logEvent("first_result_opened", null);

Wskaźnik, który testujesz, zależy ostatecznie od tego, jak Twoja aplikacja korzysta z modelu.

Na tym etapie możesz wdrożyć aplikację w Sklepie Play. Aplikacja będzie nadal korzystać z pierwotnego modelu, ale dodany kod Remote Config i Analytics umożliwi Ci eksperymentowanie z różnymi modelami przy użyciu tylko konsoli Firebase.

3. Przeprowadzanie eksperymentu A/B Testing

Gdy aplikacja jest już dostępna dla użytkowników i gromadzi dane analityczne, utwórz A/B Testingeksperyment, który pozwoli Ci sprawdzić, jak używanie nowego modelu wpływa na wyniki w porównaniu z obecnym modelem.

Aby utworzyć eksperyment:

1. Na stronie Zdarzenia w konsoli Firebase sprawdź, czy rejestrujesz odpowiednie zdarzenia Analytics: zdarzenie aktywacji i dane celu.

   Zanim zdarzenie pojawi się w Firebasekonsoli, aplikacja musi je zarejestrować co najmniej raz.

2. W konsoli Firebase otwórz sekcję A/B Testing.

3. Utwórz nowy eksperyment:

   1. Kliknij Utwórz eksperyment Remote Config.

   2. W sekcji Kierowanie:

      • Wybierz aplikację z listy.
      • Określ, ilu użytkowników ma wziąć udział w eksperymencie.
      • Wybierz zdarzenie aktywacji, które zaczęło być rejestrowane (w tym przykładzie nondefault_model_downloaded).

   3. W sekcji Cele wybierz dane celu określone w poprzedniej sekcji (w tym przykładzie first_result_opened) z listy danych celu i wybierz dodatkowe dane, które chcesz śledzić, np. przychody z zakupów lub użytkowników, u których nie wystąpiły awarie.

   4. W sekcji Wersje zdefiniuj 2 wersje:

      • Grupa kontrolna (utworzona automatycznie)
      • Eksperymentalne narzędzie do oznaczania roślin

      W przypadku grupy kontrolnej utwórz parametr plant_labeler_model i ustaw go na plant_labeler_v1. Użytkownicy przypisani do grupy kontrolnej będą korzystać ze starego modelu. (Nie ustawiaj parametru na (no change), ponieważ w aplikacji testujesz, czy używasz wartości zdalnej).

      W przypadku wariantu Experimental plant labeler ustaw parametr plant_labeler_model na plant_labeler_v2 (zakładając, że nowy model został opublikowany pod tą nazwą). Użytkownicy przypisani do tego wariantu będą korzystać z nowego modelu.

   

Uruchom eksperyment i pozwól mu działać przez kilka dni lub dłużej, aż A/B Testing wskaże zwycięzcę. Jeśli eksperyment nie wyłoni zwycięzcy, może być konieczne rozszerzenie go na większą liczbę użytkowników.

4. Wyświetlaj zwycięski wariant wszystkim użytkownikom

Gdy A/B Testing zbierze wystarczającą ilość informacji, aby wyłonić lidera – w tym przypadku wariant, który zmaksymalizował liczbę kliknięć najlepszego wyniku wyszukiwania – możesz zdecydować, czy chcesz wdrożyć zwycięski wariant (lub inny wariant) dla wszystkich użytkowników.

W sekcji A/B Testing Firebasekonsoli otwórz widok szczegółów zakończonego eksperymentu. W tym widoku możesz sprawdzić, jak każdy wariant wypadł na tle danych celu i wybranych danych dodatkowych. Na podstawie tych informacji możesz zdecydować, czy wdrożyć wiodącą wersję, czy inną.

Aby wdrożyć wariant dla wszystkich użytkowników, na stronie z informacjami o eksperymencie kliknij more_vert > Wdróż wariant. Gdy to zrobisz, wartość parametru plant_labeler_model będzie wynosić plant_labeler_v2 dla wszystkich użytkowników.

W przyszłej aktualizacji aplikacji zmień wartość domyślną parametru plant_labeler_model na plant_labeler_v2 i zaktualizuj dołączony model, jeśli go używasz. Użytkownicy korzystają już z najnowszego modelu, więc możesz wprowadzić tę aktualizację w ramach opublikowanej aplikacji w dogodnym dla siebie momencie, np. przy okazji następnej aktualizacji funkcji.