Test A/B dwóch wersji modelu

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

Na tej stronie pokazujemy, jak przeprowadzić test A/B, który porównuje 2 wersje modelu wykorzystywanego w hipotetycznej funkcji wyszukiwania roślin na podstawie obrazu. Ta funkcja korzysta z niestandardowego modelu etykietowania obrazów, aby ułatwić użytkownikom identyfikację gatunków roślin na podstawie ich zdjęć.

Załóżmy, że właśnie opublikowałeś nowy model etykietowania roślin, plant_labeler_v2 i chcesz przeprowadzić eksperyment, który porówna go z Twoim bieżącym modelem o nazwie plant_labeler_v1. Poniżej znajdziesz instrukcje konfigurowania eksperymentu, jego przeprowadzania i działania na podstawie wyników.

1. Konfigurowanie modelu zdalnie

Pierwszym krokiem do przeprowadzenia testów A/B modeli jest zmodyfikowanie aplikacji w taki sposób, aby używała parametru Remote Config, który określa, którego modelu ma używać. Początkowo wartość domyślna tego parametru będzie odpowiadać modelowi, którego używa już aplikacja. Ponieważ jednak nazwa modelu jest kontrolowana przez parametr konfigurowalny zdalnie, możesz zmieniać i eksperymentować z różnymi modelami bez konieczności wysyłania aktualizacji aplikacji do użytkowników za każdym razem.

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

Kotlin

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 załadować model określony przez parametr plant_labeler_model:

Kotlin

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

Teraz, gdy Twoja 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. Dzięki tej funkcji możesz przypisywać różne modele różnym użytkownikom w celu ich porównania.A/B Testing

Zanim przejdziesz dalej, dodaj do kodu pobierania modelu te informacje:

Kotlin

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 zdarzenie niestandardowe Analytics, którego później użyjesz jako zdarzenie aktywacji eksperymentu. Zdarzenie aktywacyjne to zdarzenie, które użytkownik musi wywołać, aby zostać uznany za uczestnika eksperymentu. Dzięki temu użytkownicy nie będą rejestrowani w testach A/B, dopóki ich urządzenie nie skończy pobierania niestandardowego modelu ML.

2. Określanie danych docelowych

Następnie zdecyduj, jak będziesz mierzyć skuteczność modelu i upewnij się, że Twoja aplikacja zbiera dane potrzebne do testowania skuteczności różnych wersji modelu na podstawie tego wskaźnika.

A/B Testing zawiera kilka wbudowanych danych, m.in. przychody, codzienne zaangażowanie i utrzymanie użytkowników. Te dane są często przydatne do testowania różnych przepływów interfejsu użytkownika lub do dokładnego dostosowania parametrów, ale mogą nie mieć sensu w przypadku oceny modelu i przypadku użycia. W takim przypadku możesz spróbować zoptymalizować kampanię pod kątem niestandardowego zdarzenia Analytics.

Weźmy na przykład hipotetyczną funkcję wyszukiwania roślin na podstawie obrazu. Załóżmy, że wyniki wyszukiwania są prezentowane użytkownikowi w kolejności zgodnej z poziomem pewności modelu w przypadku każdego wyniku. Jednym ze sposobów na oszacowanie dokładności modelu jest sprawdzenie, jak często użytkownicy otwierają pierwszy wynik wyszukiwania.

Aby sprawdzić, który model najlepiej spełniał cel maksymalizacji liczby kliknięć najlepszych wyników, za każdym razem, gdy użytkownik klika pierwszy element na liście wyników, rejestrujesz zdarzenie niestandardowe.

Kotlin

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

Java

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

Dane, które testujesz, zależą od tego, jak aplikacja korzysta z modelu.

Teraz możesz wdrożyć aplikację w Sklepie Play. Twoja aplikacja będzie nadal używać pierwotnego modelu, ale dodany przez Ciebie kod Remote Config i Analytics umożliwi Ci eksperymentowanie z różnymi modelami za pomocą tylko konsoli Firebase.

3. Przeprowadzanie eksperymentu A/B Testing

Teraz, gdy aplikacja jest w rękach użytkowników i zbiera dane analityczne, utwórz eksperyment A/B Testing, który sprawdzi, jaki będzie efekt zastosowania nowego modelu zamiast obecnego.

Aby utworzyć eksperyment:

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

Zanim zdarzenie pojawi się w konsoli Firebase, aplikacja musi je zarejestrować co najmniej raz.
W konsoli Firebase otwórz sekcję A/B Testing.
Tworzenie nowego eksperymentu:
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 eksperymencie
  - Wybierz zdarzenie aktywacji, które zaczęło się rejestrować (w tym przykładzie jest to nondefault_model_downloaded).
3. W sekcji Cele wybierz z listy danych celowych dane docelowe określone w poprzedniej sekcji (w tym przykładzie first_result_opened) i wybierz dodatkowe dane, które chcesz śledzić, np. przychody z zakupów lub liczbę użytkowników bez awarii.
4. W sekcji Wersje zdefiniuj 2 wersje:
  - Grupa kontrolna (utworzona automatycznie)
  - Eksperymentalny etykietownik roślin
  W grupie kontrolnej utwórz parametr plant_labeler_model i przypisz mu wartość 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 Eksperymentalny etykietownik do roślin 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 sprawdź jego wyniki przez kilka dni lub dłużej, aż A/B Testing wyznaczy lidera. Jeśli eksperyment nie może określić lidera, konieczne może być rozszerzenie eksperymentu na większą liczbę użytkowników.

4. Wdrożenie zwycięskiego wariantu u wszystkich użytkowników

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

W sekcji A/B Testing konsoli Firebase otwórz widok szczegółów zakończonego eksperymentu. W tym widoku możesz sprawdzić, jak każdy wariant wypadł pod względem danych docelowych i wybranych danych dodatkowych. Mając te informacje, możesz zdecydować, czy wdrożyć wariant, który wygrywa, czy inny.

Aby wdrożyć wariant dla wszystkich użytkowników, na stronie ze szczegółami eksperymentu kliknij > Wdrożyć wariant. Po wykonaniu tej czynności 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 model w pakiecie, jeśli go używasz. Użytkownicy korzystają już z najnowszego modelu, więc możesz przesłać tę aktualizację jako część opublikowanej aplikacji, gdy tylko będzie to wygodne, na przykład podczas następnej aktualizacji funkcji.