A/B-Test zweier Versionen eines Modells

Nachdem Sie ein neues benutzerdefiniertes Modell oder AutoML Vision Edge-Modell trainiert haben, können Sie A/B-Tests verwenden, um zu sehen, wie gut das neue Modell unter realen Bedingungen im Vergleich zu dem bereits verwendeten Modell abschneidet. Nachdem Sie bestätigt haben, dass Ihr neues Modell eine Verbesserung darstellt, können Sie das neue Modell problemlos für alle Ihre Benutzer bereitstellen, ohne dass ein App-Update erforderlich ist.

Diese Seite zeigt, wie Sie einen A/B-Test durchführen können, der zwei Versionen eines Modells bewertet, das eine hypothetische visuelle Pflanzensuchfunktion unterstützt. Diese Funktion verwendet ein benutzerdefiniertes Bildkennzeichnungsmodell, um Benutzern zu helfen, Pflanzenarten anhand von Bildern von ihnen zu identifizieren.

Angenommen, Sie haben gerade ein neues Pflanzenkennzeichnungsmodell plant_labeler_v2 und möchten ein Experiment ausführen, das es mit Ihrem aktuellen Modell namens plant_labeler_v1 . Die folgenden Schritte zeigen, wie Sie das Experiment einrichten, ausführen und Maßnahmen zu den Ergebnissen ergreifen.

1. Machen Sie Ihr Modell fernkonfigurierbar

Der erste Schritt zum A/B-Testen Ihrer Modelle besteht darin, Ihre App so zu ändern, dass sie einen Remote Config-Parameter verwendet, um zu bestimmen, welches Modell sie verwendet. Anfänglich legen Sie den Standardwert dieses Parameters auf das Modell fest, das Ihre App bereits verwendet, aber da der Modellname von einem remote konfigurierbaren Parameter gesteuert wird, können Sie verschiedene Modelle ändern und mit ihnen experimentieren, ohne App-Updates auf Ihre App übertragen zu müssen Benutzer jedes Mal.

Wenn Sie also Ihr aktuelles Modell unter dem Namen plant_labeler_v1 veröffentlicht haben, würden Sie in Ihrem App-Initialisierungscode plant_labeler_v1 als Standardwert des Parameters plant_labeler_model , wie im folgenden Beispiel:

Schnell

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

Ziel c

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

Ändern Sie dann Ihren Modelleinrichtungscode, um das durch den Parameter plant_labeler_model angegebene Modell zu laden:

Schnell

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

Ziel 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

Da Ihre App nun einen Remote Config-Parameter verwendet, um zu bestimmen, welches Modell geladen werden soll, können Sie das Modell ändern, indem Sie einfach ein neues Modell veröffentlichen und seinen Namen dem Remote Config-Parameter zuweisen. Mit dieser Funktion können A/B-Tests verschiedenen Benutzern unterschiedliche Modelle zuweisen, um sie zu vergleichen.

Bevor Sie fortfahren, fügen Sie Ihrem Modell-Download-Code außerdem Folgendes hinzu:

Schnell

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

Ziel 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];
              }
            }];

Der obige Code protokolliert ein benutzerdefiniertes Analytics-Ereignis, das Sie später als Experiment verwenden werden Aktivierungsereignis . Ein Aktivierungsereignis ist ein Ereignis, das der Benutzer auslösen muss, bevor er als Teil des Experiments betrachtet wird. Dadurch wird sichergestellt, dass Benutzer nicht in Ihren A/B-Test aufgenommen werden, bis ihr Gerät das Herunterladen ihres benutzerdefinierten ML-Modells abgeschlossen hat.

2. Bestimmen Sie eine Zielmetrik

Im nächsten Schritt müssen Sie entscheiden, wie Sie den Erfolg Ihres Modells messen und sicherstellen, dass Ihre App die Daten erfasst, die erforderlich sind, um zu testen, wie gut verschiedene Versionen des Modells gemäß dieser Metrik abschneiden.

A/B-Tests verfügen über mehrere integrierte Metriken, darunter Umsatz, tägliches Engagement und Benutzerbindung. Diese Metriken sind oft nützlich, um verschiedene UX-Flows oder Feinabstimmungsparameter zu testen, sind aber möglicherweise nicht sinnvoll, um Ihr Modell und Ihren Anwendungsfall zu bewerten. In dieser Situation können Sie stattdessen versuchen, für ein benutzerdefiniertes Analytics-Ereignis zu optimieren.

Nehmen Sie am Beispiel der Funktion für die hypothetische visuelle Pflanzensuche an, dass Sie Ihrem Benutzer Suchergebnisse in der Reihenfolge des Vertrauens des Modells in jedes Ergebnis präsentiert haben. Sie können sich beispielsweise ein Bild von der Genauigkeit Ihres Modells machen, indem Sie sich ansehen, wie oft Benutzer das erste Suchergebnis geöffnet haben.

Um zu testen, welches Modell das Ziel der Maximierung der Klicks auf die besten Ergebnisse am besten erreicht, würden Sie jedes Mal ein benutzerdefiniertes Ereignis protokollieren, wenn ein Benutzer auf das erste Element in der Ergebnisliste tippt.

Schnell

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

Ziel c

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

Welche Metrik Sie testen, hängt letztendlich davon ab, wie Ihre App Ihr ​​Modell verwendet.

An diesem Punkt können Sie Ihre App im App Store bereitstellen. Ihre App verwendet weiterhin Ihr ursprüngliches Modell, aber der von Ihnen hinzugefügte Remotekonfigurations- und Analysecode ermöglicht es Ihnen, mit verschiedenen Modellen zu experimentieren, indem Sie nur die Firebase-Konsole verwenden.

3. Führen Sie ein A/B-Test-Experiment durch

Nachdem sich Ihre App nun in den Händen Ihrer Benutzer befindet und Analysedaten sammelt, erstellen Sie ein A/B-Testexperiment, das die Auswirkungen der Verwendung Ihres neuen Modells anstelle des aktuellen Modells testet.

So erstellen Sie das Experiment:

  1. Vergewissern Sie sich auf der Seite „ Ereignisse “ der Firebase-Konsole, dass Sie die relevanten Analytics-Ereignisse protokollieren: das Aktivierungsereignis und die Zielmetrik.

    Ihre App muss jedes Ereignis mindestens einmal protokollieren, bevor es in der Firebase-Konsole angezeigt wird.

  2. Öffnen Sie in der Firebase-Konsole den Abschnitt A/B-Tests .

  3. Erstellen Sie einen neuen Test:

    1. Klicken Sie auf Experiment erstellen > Remote-Konfiguration .

    2. Im Abschnitt „ Targeting “:

      • Wählen Sie Ihre App aus der Liste aus
      • Geben Sie an, wie viele Ihrer Benutzer Sie in den Test einbeziehen möchten
      • Wählen Sie das Aktivierungsereignis aus, das Sie mit der Protokollierung begonnen haben (in diesem Beispiel nondefault_model_downloaded ).

    3. Wählen Sie im Abschnitt „ Ziele “ die Zielmetrik, die Sie im vorherigen Abschnitt festgelegt haben (in diesem Beispiel first_result_opened ), aus der Liste der Zielmetriken aus, und wählen Sie alle zusätzlichen Metriken aus, die Sie nachverfolgen möchten, z. B. Kaufumsatz oder absturzfreie Benutzer.

    4. Definieren Sie im Abschnitt Varianten zwei Varianten:

      • Kontrollgruppe (automatisch erstellt)
      • Experimenteller Pflanzenetikettierer

      Erstellen Sie für die Control-Gruppe einen plant_labeler_model Parameter und setzen Sie ihn auf plant_labeler_v1 . Benutzer, die der Kontrollgruppe zugewiesen sind, verwenden das alte Modell. (Setzen Sie den Parameter nicht auf (no change) , da Sie in Ihrer App testen, ob Sie einen Remote-Wert verwenden.)

      Setzen Sie für die Variante Experimental plant labeler den Parameter plant_labeler_model auf plant_labeler_v2 (vorausgesetzt, Sie haben Ihr neues Modell unter diesem Namen veröffentlicht). Benutzer, die dieser Variante zugewiesen sind, verwenden das neue Modell.

    A/B-Testkonfigurationsbildschirm

Starten Sie das Experiment und lassen Sie es mehrere Tage oder länger laufen, bis A/B-Tests einen Leader ausmachen. Wenn der Test keinen Leader ermitteln kann, müssen Sie den Test möglicherweise auf mehr Nutzer ausdehnen .

4. Führen Sie die erfolgreiche Variante allen Benutzern zu

A/B-Testergebniskarte

Nachdem A/B-Tests genügend Informationen gesammelt haben, um einen Leader zu erklären – in diesem Fall die Variante, die die Klicks auf die obersten Suchergebnisse maximiert hat – können Sie entscheiden, ob Sie die Gewinnervariante (oder eine andere Variante) für alle Ihre Benutzer einführen möchten.

Öffnen Sie im Abschnitt A/B-Tests der Firebase-Konsole die Detailansicht des abgeschlossenen Tests. In dieser Ansicht können Sie sehen, wie jede Variante gemäß Ihrer Zielmetrik und allen von Ihnen ausgewählten sekundären Metriken abgeschnitten hat. Anhand dieser Informationen können Sie entscheiden, ob Sie die führende Variante oder eine andere Variante ausrollen möchten.

Um eine Variante für alle Benutzer bereitzustellen, klicken Sie auf der Detailseite des Experiments auf > Variante bereitstellen . Danach lautet der Wert des Parameters plant_labeler_model für alle Benutzer plant_labeler_v2 .

In einem zukünftigen App-Update sollten Sie den Standardwert des Parameters plant_labeler_model in plant_labeler_v2 und das gebündelte Modell aktualisieren, falls Sie eines verwenden. Ihre Benutzer verwenden jedoch bereits das neueste Modell, sodass Sie dieses Update jederzeit als Teil der veröffentlichten App pushen können, z. B. wenn Sie das nächste Feature-Update vornehmen.