Test A/B dwóch wersji modelu

Po wytrenowaniu nowego modelu niestandardowego lub modelu AutoML Vision Edge możesz skorzystać z testów A/B, aby sprawdzić, jak dobrze nowy model radzi sobie w rzeczywistych warunkach w porównaniu z modelem, którego już używasz. Po potwierdzeniu, że nowy model stanowi ulepszenie, możesz łatwo udostępnić go wszystkim użytkownikom bez konieczności aktualizacji aplikacji.

Na tej stronie pokazano, jak można przeprowadzić test A/B oceniający dwie wersje modelu obsługującego hipotetyczną funkcję wizualnego wyszukiwania roślin. Ta funkcja wykorzystuje niestandardowy model etykietowania obrazów, aby pomóc użytkownikom identyfikować gatunki 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 bieżącym modelem o nazwie plant_labeler_v1 . Poniższe kroki pokazują, jak skonfigurować eksperyment, przeprowadzić go i podjąć działania w oparciu o wyniki.

1. Spraw, aby Twój model był konfigurowany zdalnie

Pierwszym krokiem do testowania A/B modeli jest zmodyfikowanie aplikacji w taki sposób, aby korzystała z parametru Zdalnej konfiguracji w celu ustalenia, jakiego modelu używa. Początkowo ustawisz domyślną wartość tego parametru na model, którego już używa Twoja aplikacja, ale ponieważ nazwą modelu steruje zdalnie konfigurowany parametr, możesz zmieniać i eksperymentować z różnymi modelami bez konieczności przesyłania aktualizacji aplikacji do swojego użytkowników za każdym razem.

Tak więc, jeśli opublikowałeś swój bieżący model pod nazwą plant_labeler_v1 , w kodzie inicjalizacji aplikacji ustaw plant_labeler_v1 jako domyślną wartość parametru plant_labeler_model , jak w poniższym przykładzie:

Szybki

let remoteConfig = RemoteConfig.remoteConfig()
let defaults = [
    "plant_labeler_model": "plant_labeler_v1" as NSObject,
    // ...
]
remoteConfig.setDefaults(defaults)
remoteConfig.fetchAndActivate()

Cel C

FIRRemoteConfig *remoteConfig = [FIRRemoteConfig remoteConfig];
NSDictionary<NSString *, NSObject *> *defaults = @{
  @"plant_labeler_model" : (NSObject *)@"plant_labeler_v1",
  // ...
};
[remoteConfig setDefaults:defaults];
[remoteConfig fetchAndActivateWithCompletionHandler:nil];

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

Szybki

let rcValue = remoteConfig.configValue(forKey: "plant_labeler_model")
guard let remoteModelName = rcValue.stringValue else { return }

// ...

let remoteModel = RemoteModel(
    name: remoteModelName,
    allowsModelUpdates: true,
    initialConditions: initialConditions,
    updateConditions: updateConditions
)
ModelManager.modelManager().register(remoteModel)

// Optionally configure a local model:
// https://firebase.google.com/docs/ml/ios/label-images-with-automl#configure-a-local-model-source
// https://firebase.google.com/docs/ml/ios/use-custom-models#configure_a_local_model

Cel C

FIRRemoteConfigValue *rcValue = [remoteConfig configValueForKey:@"plant_labeler_model"];
NSString *remoteModelName = [rcValue stringValue];

// ...

FIRRemoteModel *remoteModel = [[FIRRemoteModel alloc] initWithName:remoteModelName
                                                allowsModelUpdates:YES
                                                 initialConditions:initialConditions
                                                  updateConditions:updateConditions];
[[FIRModelManager modelManager] 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 aplikacja używa parametru Remote Config do określenia, który model ma zostać załadowany, możesz zmienić model, po prostu publikując nowy model i przypisując jego nazwę do parametru Remote Config. Ta funkcja umożliwia testowanie A/B przypisywanie różnych modeli różnym użytkownikom w celu ich porównania.

Zanim będziesz kontynuować, dodaj także do kodu pobierania modelu następujący dodatek:

Szybki

NotificationCenter.default.addObserver(
    forName: .firebaseMLModelDownloadDidSucceed,
    object: nil,
    queue: nil
) { [weak self] notification in
    guard let _ = self,
        let userInfo = notification.userInfo,
        let model = userInfo[ModelDownloadUserInfoKey.remoteModel.rawValue]
            as? RemoteModel,
        model.name == remoteModelName
        else { return }
    // If the model downloaded was specified by a remote parameter, log an
    // event, which will be our experiment's activation event.
    if rcValue.source == .remote {
        Analytics.logEvent("nondefault_model_downloaded", parameters: nil)
    }
}

Cel C

__weak typeof(self) weakSelf = self;

[NSNotificationCenter.defaultCenter
    addObserverForName:FIRModelDownloadDidSucceedNotification
                object:nil
                 queue:nil
            usingBlock:^(NSNotification *_Nonnull note) {
              if (weakSelf == nil | note.userInfo == nil) {
                return;
              }

              FIRRemoteModel *model = note.userInfo[FIRModelDownloadUserInfoKeyRemoteModel];
              if ([model.name isEqualToString:remoteModelName] &&
                  rcValue.source == FIRRemoteConfigSourceRemote) {
                // If the model downloaded was specified by a remote parameter, log an
                // event, which will be our experiment's activation event.
                [FIRAnalytics logEventWithName:@"nondefault_model_downloaded" parameters:nil];
              }
            }];

Powyższy kod rejestruje niestandardowe zdarzenie Analytics, które wykorzystasz później jako zdarzenie w eksperymencie wydarzenie aktywacyjne . Zdarzenie aktywacyjne to zdarzenie, które użytkownik musi wywołać, zanim zostanie uznany za część eksperymentu. Dzięki temu użytkownicy nie zostaną zarejestrowani w teście A/B, dopóki ich urządzenie nie zakończy pobierania niestandardowego modelu ML.

2. Określ metrykę celu

Następnym krokiem jest podjęcie decyzji, w jaki sposób zmierzysz sukces swojego modelu i upewnienie się, że aplikacja zbiera dane niezbędne do przetestowania, jak dobrze różne wersje modelu radzą sobie z tą metryką.

Testy A/B mają kilka wbudowanych wskaźników, w tym przychody, dzienne zaangażowanie i utrzymanie użytkowników. Metryki te są często przydatne do testowania różnych przepływów UX lub dostrajania parametrów, ale mogą nie mieć sensu przy ocenie modelu i przypadku użycia. W tej sytuacji możesz zamiast tego spróbować przeprowadzić optymalizację pod kątem niestandardowego zdarzenia Analytics.

Używając jako przykładu hipotetycznej funkcji wizualnego wyszukiwania roślin, załóżmy, że przedstawiłeś użytkownikowi wyniki wyszukiwania w kolejności zaufania modelu do każdego wyniku. Jednym ze sposobów sprawdzenia dokładności modelu jest sprawdzenie, jak często użytkownicy otwierali pierwszy wynik wyszukiwania.

Aby sprawdzić, który model najlepiej osiągnął cel, jakim jest maksymalizacja liczby kliknięć z najwyższym wynikiem, należy rejestrować zdarzenie niestandardowe za każdym razem, gdy użytkownik dotknie pierwszego elementu na liście wyników.

Szybki

Analytics.logEvent("first_result_opened", parameters: nil)

Cel C

[FIRAnalytics logEventWithName:@"first_result_opened" parameters:nil];

Metryka, którą testujesz, ostatecznie zależy od tego, w jaki sposób aplikacja korzysta z modelu.

Na tym etapie możesz wdrożyć aplikację w sklepie App Store. Twoja aplikacja będzie nadal korzystać z oryginalnego modelu, ale dodany przez Ciebie kod Remote Config i Analytics umożliwi eksperymentowanie z różnymi modelami przy użyciu wyłącznie konsoli Firebase.

3. Przeprowadź eksperyment z testem A/B

Teraz, gdy Twoja aplikacja jest w rękach użytkowników i zbiera dane analityczne, utwórz eksperyment testowy A/B, który sprawdzi efekt użycia nowego modelu zamiast bieżącego.

Aby utworzyć eksperyment:

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

    Twoja aplikacja musi rejestrować każde zdarzenie co najmniej raz, zanim pojawi się ono w konsoli Firebase.

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

  3. Utwórz nowy eksperyment:

    1. Kliknij opcję Utwórz eksperyment > Zdalna konfiguracja .

    2. W sekcji Kierowanie :

      • Wybierz swoją aplikację z listy
      • Określ ilu użytkowników chcesz uwzględnić w eksperymencie
      • Wybierz zdarzenie aktywacyjne, które zacząłeś rejestrować (w tym przykładzie nondefault_model_downloaded )
    3. W sekcji Cele wybierz metrykę celu określoną w poprzedniej sekcji (w tym przykładzie First_result_opened ) z listy metryk celu i wybierz dodatkowe metryki, które chcesz śledzić, takie jak przychody z zakupów lub użytkownicy bez awarii.

    4. W sekcji Warianty zdefiniuj dwa warianty:

      • Grupa kontrolna (tworzona automatycznie)
      • Eksperymentalna etykieta roślin

      Dla grupy Control 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 eksperymentalnego wariantu etykietowania 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.

    Ekran konfiguracji testu A/B

Rozpocznij eksperyment i pozwól mu działać przez kilka dni lub dłużej, aż testy A/B wyłonią lidera. Jeśli w eksperymencie nie uda się wyłonić lidera, konieczne może być rozszerzenie eksperymentu na większą liczbę użytkowników .

4. Udostępnij zwycięski wariant wszystkim użytkownikom

Karta wyników testu A/B

Po tym, jak w ramach testów A/B zbierzesz wystarczającą ilość informacji, aby wyłonić lidera – w tym przypadku wariant, który zmaksymalizował kliknięcia w najwyższych wynikach wyszukiwania – możesz zdecydować, czy wdrożyć zwycięski wariant (lub inny wariant) wszystkim użytkownikom.

W sekcji Testy A/B konsoli Firebase otwórz widok szczegółów zakończonego eksperymentu. W tym widoku możesz sprawdzić skuteczność każdego wariantu zgodnie z Twoimi celami i wybranymi dodatkowymi danymi. Dzięki tym informacjom możesz zdecydować, czy wdrożyć wariant wiodący, czy inny.

Aby wdrożyć wariant dla wszystkich użytkowników, kliknij > Wdróż wariant na stronie szczegółów eksperymentu. Gdy to zrobisz, wartość parametru plant_labeler_model będzie plant_labeler_v2 dla wszystkich użytkowników.

W przyszłej aktualizacji aplikacji powinieneś zmienić domyślną wartość parametru plant_labeler_model na plant_labeler_v2 i zaktualizować dołączony model, jeśli go używasz. Jednak Twoi użytkownicy korzystają już z najnowszego modelu, więc możesz opublikować tę aktualizację jako część opublikowanej aplikacji, kiedy tylko jest to wygodne, na przykład podczas następnej aktualizacji funkcji.