Test A/B dwóch wersji modelu

Po wytrenowaniu nowego modelu niestandardowego lub modelu AutoML Vision Edge możesz użyć: testy A/B, które pozwolą 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 Parametr Zdalnej konfiguracji pozwalający 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:

Swift

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

Objective-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 wczytać model określony przez metodę Parametr plant_labeler_model:

Swift

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

Objective-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

Twoja aplikacja używa teraz parametru Zdalnej konfiguracji, aby określić, który model obciążenia, możesz go zmienić, publikując nowy model i przypisując mu jako parametr Zdalnej konfiguracji. Ta funkcja pozwala Testom A/B 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:

Swift

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

Objective-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ó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.

Testy A/B mają kilka wbudowanych wskaźników, 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.

Swift

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

Objective-C

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

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

Na tym etapie możesz już wdrożyć swoją aplikację w App Store. Aplikacja będzie nadal używać pierwotnego modelu, ale dodany przez Ciebie kod Zdalna konfiguracja i Analytics pozwoli Ci eksperymentować z różnymi modelami tylko za pomocą konsoli Firebase.

3. Przeprowadź eksperyment A/B

Gdy aplikacja jest już w katalogu i zbiera dane analityczne, utworzyć eksperyment A/B, który sprawdzi efekty zastosowania zamiast bieżącego.

Aby utworzyć eksperyment:

na stronie Wydarzenia, w 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 konsoli Firebase.
W konsoli Firebase otwórz sekcję Testy A/B.
Utwórz nowy eksperyment:
1. Kliknij Utwórz eksperyment > Zdalna konfiguracja.
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 jest to 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.

Rozpocznij eksperyment i prowadź przez co najmniej kilka dni, W przypadku testów A/B zwycięzca jest deklarowany. 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

Po zebraniu przez Testy A/B wystarczającej ilości informacji do zadeklarowania 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 Testy A/B w 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.