Test A/B dwóch wersji modelu

Po wytrenowaniu nowego modelu niestandardowego lub modelu AutoML Vision Edge możesz użyć testów A/B, aby sprawdzić, jak dobrze nowy model działa w warunkach rzeczywistych w porównaniu z modelem, którego już używasz. Po potwierdzeniu, że nowy model jest ulepszeniem, możesz go łatwo wdrożyć u wszystkich użytkowników bez konieczności aktualizacji aplikacji.

Na tej stronie pokazano, jak można przeprowadzić test A/B, który ocenia 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 zidentyfikować gatunki roślin na podstawie ich obrazów.

Załóżmy, że właśnie opublikowałeś nowy model etykietowania roślin, plant_labeler_v2 i chcesz przeprowadzić eksperyment, który porównuje go z bieżącym modelem o nazwie plant_labeler_v1 . Poniższe kroki pokazują, jak skonfigurować eksperyment, przeprowadzić go i podjąć działania na wynikach.

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

Pierwszym krokiem do testowania A/B modeli jest zmodyfikowanie aplikacji tak, aby używała parametru Zdalna konfiguracja w celu określenia używanego modelu. Początkowo ustawisz domyślną wartość tego parametru na model, którego już używa Twoja aplikacja, ale ponieważ nazwa modelu jest kontrolowana przez zdalnie konfigurowany parametr, możesz zmieniać i eksperymentować z różnymi modelami bez konieczności przesyłania aktualizacji aplikacji do użytkowników za każdym razem.

Jeśli więc 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:

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

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 :

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

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 Zdalnej konfiguracji, aby określić, który model ma zostać załadowany, możesz zmienić model, publikując nowy model i przypisując jego nazwę do parametru Zdalna konfiguracja. Ta funkcja umożliwia testom A/B przypisywanie różnych modeli różnym użytkownikom w celu ich porównania.

Zanim przejdziesz dalej, dodaj także następujący dodatek do kodu pobierania modelu:

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

__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órego użyjesz później jako zdarzenia w eksperymencie wydarzenie aktywacyjne . Zdarzenie aktywacji to zdarzenie, które użytkownik musi wywołać, zanim zostanie uznany za część eksperymentu. Dzięki temu użytkownicy nie będą rejestrowani w teście A/B, dopóki ich urządzenie nie zakończy pobierania niestandardowego modelu ML.

2. Określ wskaźnik celu

Następnym krokiem jest podjęcie decyzji, w jaki sposób będziesz mierzyć sukces swojego modelu, i upewnienie się, że Twoja aplikacja zbiera dane niezbędne do przetestowania skuteczności różnych wersji modelu w zależności od tego wskaźnika.

Testy A/B mają kilka wbudowanych wskaźników, w tym przychody, dzienne zaangażowanie i utrzymanie użytkowników. Te metryki 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 takiej sytuacji możesz zamiast tego spróbować zoptymalizować niestandardowe zdarzenie Analytics.

Na przykładzie hipotetycznej wizualnej funkcji wyszukiwania roślin, załóżmy, że zaprezentowano użytkownikowi wyniki wyszukiwania w kolejności zaufania modelu do każdego wyniku. Jednym ze sposobów na zorientowanie się w dokładności modelu jest sprawdzenie, jak często użytkownicy otwierali pierwszy wynik wyszukiwania.

Aby przetestować, który model najlepiej osiągnął cel, jakim jest zmaksymalizowanie kliknięć z najlepszymi wynikami, należy rejestrować zdarzenie niestandardowe za każdym razem, gdy użytkownik kliknie pierwszy element na liście wyników.

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

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

Metryka, którą testujesz, zależy ostatecznie od tego, jak Twoja aplikacja korzysta z Twojego modelu.

W tym momencie możesz wdrożyć swoją aplikację w App Store. Twoja aplikacja będzie nadal korzystać z oryginalnego modelu, ale dodany kod Remote Config i Analytics umożliwi eksperymentowanie z różnymi modelami tylko przy użyciu konsoli Firebase.

3. Przeprowadź eksperyment testowania A/B

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

Aby stworzyć eksperyment:

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

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

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

3. Utwórz nowy eksperyment:

   1. Kliknij 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 aktywacji, które rozpoczęło się rejestrowanie (w tym przykładzie nondefault_model_downloaded )

   3. W sekcji Cele wybierz z listy dane celu określone w poprzedniej sekcji (w tym przykładzie first_result_opened ) i wybierz dodatkowe dane, które chcesz śledzić, takie jak przychody z zakupów lub użytkownicy bez awarii.

   4. W sekcji Warianty zdefiniuj dwa warianty:

      • Grupa kontrolna (utworzona automatycznie)
      • Eksperymentalna maszyna do znakowania 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ą używać starego modelu. (Nie ustawiaj parametru na (no change) , ponieważ w Twojej aplikacji testujesz, że używasz wartości zdalnej).

      W przypadku wariantu etykiety eksperymentalnej rośliny ustaw parametr plant_labeler_model na plant_labeler_v2 (zakładając, że opublikowałeś nowy model pod tą nazwą). Użytkownicy przypisani do tego wariantu będą korzystać z nowego modelu.

   

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

4. Rozwiń zwycięski wariant dla wszystkich użytkowników

Po zebraniu przez testy A/B informacji wystarczających do wyznaczenia lidera — w tym przypadku wariantu, który zmaksymalizował liczbę kliknięć w najlepszych wynikach wyszukiwania — możesz zdecydować, czy udostępnić 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 zobaczyć skuteczność poszczególnych wariantów zgodnie z danymi celu i wybranymi danymi dodatkowymi. Dzięki tym informacjom możesz zdecydować, czy wprowadzić wariant wiodący, czy inny.

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

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