Test A/B dwóch wersji modelu

Po wytrenowaniu nowego modelu niestandardowego lub modelu AutoML Vision Edge możesz użyć: 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 po wprowadzeniu ulepszeń, możesz łatwo udostępnić nowy model wszystkim użytkownikom, bez konieczności aktualizowania aplikacji.

Na tej stronie dowiesz się, jak można przeprowadzić test A/B oceniający 2 wersje modelu, na którym opiera się hipotetyczna funkcja wizualnego wyszukiwania roślin. Ta funkcja wykorzystują własny model oznaczania obrazów, aby ułatwić użytkownikom identyfikację gatunków roślin zdjęcia, na których widać te zdjęcia.

Załóżmy, że właśnie opublikowano nowy model oznaczania roślin plant_labeler_v2 i chcesz przeprowadzić eksperyment, który go porównuje z obecnym modelem o nazwie plant_labeler_v1. Aby to zrobić: pokażemy, jak skonfigurować eksperyment, przeprowadzić go i podejmować działania na podstawie jego wyników.

1. Umożliwiaj zdalne konfigurowanie modelu

Pierwszym krokiem do testowania modeli A/B jest zmodyfikowanie aplikacji tak, aby używała Remote Config, aby określić model, którego używa. Początkowo domyślną wartością tego parametru będzie model, którego używa Twoja aplikacja już jest używany, ale ponieważ nazwa modelu jest sterowana zdalnie konfigurowalne parametry, można zmieniać model i eksperymentować z nimi bez konieczności każdorazowego przekazywania użytkownikom aktualizacji aplikacji.

Jeśli więc Twój bieżący model został opublikowany pod nazwą plant_labeler_v1, w kodzie inicjowania aplikacji należy ustawić plant_labeler_v1 jako domyślnej wartości parametru plant_labeler_model, jak w tym przykładzie:

Kotlin+KTX

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.
      // ...
    }
}

Java

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 metodę Parametr plant_labeler_model:

Kotlin+KTX

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/label-images-with-automl#configure-a-local-model-source
// https://firebase.google.com/docs/ml/android/use-custom-models#configure_a_local_model

Java

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/label-images-with-automl#configure-a-local-model-source
// https://firebase.google.com/docs/ml/android/use-custom-models#configure_a_local_model

Twoja aplikacja używa teraz parametru Remote Config do określenia, który model obciążenia, możesz go zmienić, publikując nowy model i przypisując mu na parametr Remote Config. Ta funkcja pozwala użytkownikowi A/B Testing przypisywać Aby porównać wyniki różnych użytkowników, należy uwzględnić różne modele.

Zanim przejdziesz dalej, dodaj też do pobranego modelu te elementy: kod:

Kotlin+KTX

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)
        }
    }

Java

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órego będziesz później używać jako zdarzenia aktywacji eksperymentu. Zdarzenie aktywacji to zdarzenie, musi zostać wywołane, zanim zostanie uznany za uczestnika eksperymentu. Ten pozwala zagwarantować, że użytkownicy nie będą uwzględniani w teście A/B, dopóki ich urządzenie zakończyli pobieranie niestandardowego modelu ML.

2. Wyznacz wskaźnik celu

Następnym krokiem jest określenie, jak mierzysz sukces modelu, oraz aby upewnić się, że aplikacja gromadzi dane niezbędne do przetestowania, różne wersje modelu radzą sobie na podstawie tych danych.

A/B Testing ma kilka wbudowanych danych, w tym przychody, dzienne dane zaangażowanie i utrzymanie użytkowników. Te dane są często przydatne podczas testowania za pomocą funkcji UX czy dostrajania parametrów, ale może to nie mieć sensu w celu oceny modelu i przypadku użycia. W takiej sytuacji możesz zamiast tego spróbować prowadzić optymalizację pod kątem niestandardowego zdarzenia Analytics.

Na przykładzie hipotetycznego wizualnego wyszukiwania roślin załóżmy, wyniki wyszukiwania zostały przedstawione użytkownikowi zgodnie z poziomem ufności modelu każdy wynik. Jednym ze sposobów sprawdzenia dokładności modelu jest na podstawie tego, jak często użytkownicy otwierali pierwszy wynik wyszukiwania.

Aby sprawdzić, który model najlepiej osiągnął cel maksymalizacji liczby kliknięć najlepszych wyników, rejestrujesz zdarzenie niestandardowe za każdym razem, gdy użytkownik kliknie pierwszy element w wynikach z listy.

Kotlin+KTX

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

Java

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

Ostateczny wynik testu zależy od tego, jak aplikacja model atrybucji.

Na tym etapie możesz wdrożyć aplikację w Sklepie Play. Aplikacja będzie nadal używać oryginalnego modelu. ale dodany kod Remote Config i Analytics pozwoli Ci eksperymentować z różnymi modelami tylko za pomocą konsoli Firebase.

3. Przeprowadź eksperyment A/B Testing

Gdy aplikacja jest już w katalogu i zbiera dane analityczne, utwórz eksperyment A/B Testing, który przetestuje efekty zastosowania nowego zamiast bieżącego.

Aby utworzyć eksperyment:

na stronie Wydarzenia, konsoli Firebase, sprawdź, czy rejestrujesz odpowiednie Zdarzenia Analytics: dane dotyczące zdarzenia aktywacji i celu.

Aplikacja musi zarejestrować każde zdarzenie co najmniej raz, zanim pojawi się ono Konsola Firebase.
W konsoli Firebase otwórz sekcję A/B Testing.
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 chcesz uwzględnić w eksperyment
  - Wybierz zdarzenie aktywacji, które zostało rozpoczęte (w tym przykładzie pobrany_model_niedomyślny).
3. W sekcji Cele wybierz dane celu określone w poprzedniej sekcji (w tym przykładzie: first_result_opened), z listy wskaźników celu oraz wybrać dodatkowe dane, np. przychody z zakupów czy liczba użytkowników, u których nie wystąpiła awaria.
4. W sekcji Wersje określ 2 warianty:
  - Grupa kontrolna (utworzona automatycznie)
  - Eksperymentalne narzędzie do oznaczania roślin
  W sekcji Grupa kontrolna utwórz plant_labeler_model i ustaw go na plant_labeler_v1 Użytkownicy przypisani do grupy kontrolnej będzie używać starego modelu. Nie ustawiaj parametru na (no change), ponieważ w aplikacji testujesz korzystanie z parametru wartość zdalna).
  
  W przypadku wariantu Eksperymentalne rośliny ustaw wartość plant_labeler_model parametr do plant_labeler_v2 (zakładając, że Twój nowy model został opublikowany pod tą nazwą). Użytkownicy przypisani do tego wariantu będą korzystać z nowego wariantu model atrybucji.

Rozpocznij eksperyment i prowadź przez co najmniej kilka dni, A/B Testing deklaruje lidera. Jeśli eksperyment nie pozwala określić zwycięzcy, może być konieczne rozszerzyć eksperyment na większą liczbę użytkowników.

4. Udostępnienie zwycięskiego wariantu wszystkim użytkownikom

Gdy A/B Testing zbierze wystarczającą ilość informacji, by zadeklarować leader – w tym przypadku wariant, który zmaksymalizował u góry strony wyników wyszukiwania kliknięć – możesz zdecydować, czy wdrożyć najlepszy wariant (lub inny wersję) wszystkim użytkownikom.

W sekcji A/B Testing konsoli Firebase otwórz szczegóły. ukończonego eksperymentu. W tym widoku możesz zobaczyć, jak każdy wariant skuteczność na podstawie danych celu i wybranych przez Ciebie danych dodatkowych. Dzięki tym informacjom możesz zdecydować, czy wdrożyć najlepszy wariant, jeszcze jedną wersję.

Aby udostępnić wariant dla wszystkich użytkowników, kliknij Wdróż wariant w stronie z informacjami o eksperymencie. Gdy to zrobisz, wartość parametru Parametr plant_labeler_model będzie miał wartość plant_labeler_v2 dla wszystkich użytkowników.

W przyszłej aktualizacji aplikacji trzeba zmienić domyślną wartość plant_labeler_model na plant_labeler_v2 i zaktualizuj pakiet a jeśli go używasz. Twoi użytkownicy używają już najnowszego modelu, więc możesz w dogodnym momencie przekazać ją do opublikowanej aplikacji, np. przy następnej aktualizacji funkcji.