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
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:
Kliknij Utwórz eksperyment > Zdalna konfiguracja.
-
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).
-
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.
-
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 naplant_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 doplant_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
more_vert 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.