Test A/B dwóch wersji modelu

Po wytrenowaniu nowego modelu niestandardowego możesz użyć A/B Testing, aby sprawdzić, jak nowy model działa 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 pomagać użytkownikom w identyfikowaniu gatunków roślin na podstawie ich zdjęć.

Załóżmy, że właśnie opublikowano nowy model etykietowania roślinplant_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. Zdalna konfiguracja modelu

Pierwszym krokiem w testowaniu modeli A/B jest zmodyfikowanie aplikacji, aby używała parametru Remote Config 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 do kodu pobierania modelu ten wiersz:

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 wskaźnika celu

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 rodzajów danych, m.in. 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 zamiast tego spróbować optymalizować pod kątem niestandardowego zdarzenia Analytics.

Załóżmy, że w przypadku hipotetycznej funkcji wizualnego wyszukiwania roślin wyświetlasz użytkownikowi wyniki wyszukiwania w kolejności zgodnej z poziomem ufności modelu w odniesieniu 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 liczby 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);

Testowana wartość zależy od tego, jak 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 A/B Testing eksperymentu

Gdy aplikacja jest już dostępna dla użytkowników i gromadzi dane analityczne, utwórz A/B Testingeksperyment, który 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 Firebase konsoli, aplikacja musi je zarejestrować co najmniej raz.

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

3. Tworzenie nowego eksperymentu:

   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órego rejestrowanie zostało rozpoczęte (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 liczbę użytkowników, u których nie wystąpiły awarie.

   4. W sekcji Wersje zdefiniuj 2 wersje:

      • Grupa kontrolna (utworzona automatycznie)
      • Eksperymentalny program do etykietowania 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 lidera. Jeśli eksperyment nie może wyłonić lidera, być może musisz rozszerzyć go na większą liczbę użytkowników.

4. Wyświetlanie zwycięskiego wariantu wszystkim użytkownikom

Gdy A/B Testing zgromadzi wystarczającą ilość informacji, aby wyłonić najlepszy wariant – 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) u wszystkich użytkowników.

W sekcji A/B Testing Firebasekonsoli otwórz widok szczegółów zakończonego eksperymentu. W tym widoku możesz sprawdzić skuteczność poszczególnych wariantów na podstawie danych dotyczących celu i wybranych danych dodatkowych. Dzięki tym informacjom 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ń domyślną wartość parametru plant_labeler_model na plant_labeler_v2 i zaktualizuj dołączony model, jeśli go używasz. Użytkownicy korzystają już jednak z najnowszego modelu, więc możesz wprowadzić tę aktualizację w ramach opublikowanej aplikacji, kiedy tylko Ci to odpowiada, np. przy okazji kolejnej aktualizacji funkcji.