Después de entrenar un nuevo modelo personalizado o un modelo de AutoML Vision Edge, puedes usar las pruebas A/B para ver qué tan bien se desempeña el nuevo modelo en condiciones del mundo real, en comparación con el modelo que ya usas. Después de confirmar que su nuevo modelo es una mejora, puede implementar fácilmente el nuevo modelo para todos sus usuarios, sin necesidad de actualizar la aplicación.
Esta página muestra cómo podría realizar una prueba A/B que evalúe dos versiones de un modelo que impulsa una función de búsqueda visual de plantas hipotética. Esta función utiliza un modelo de etiquetado de imágenes personalizado para ayudar a los usuarios a identificar especies de plantas a partir de imágenes de ellas.
Suponga que acaba de publicar un nuevo modelo de etiquetado de plantas, plant_labeler_v2 y desea ejecutar un experimento que lo compare con su modelo actual, denominado plant_labeler_v1 . Los pasos siguientes muestran cómo configurar el experimento, ejecutarlo y tomar medidas sobre los resultados.
1. Haga que su modelo sea configurable de forma remota
El primer paso para realizar pruebas A/B de sus modelos es modificar su aplicación para usar un parámetro de Remote Config para determinar qué modelo usa. Inicialmente, establecerá el valor predeterminado de este parámetro para que sea el modelo que su aplicación ya usa, pero debido a que el nombre del modelo está controlado por un parámetro configurable de forma remota, puede cambiar y experimentar con diferentes modelos sin tener que enviar actualizaciones de la aplicación a su usuarios cada vez.
Por lo tanto, si publicó su modelo actual con el nombre plant_labeler_v1 , en el código de inicialización de su aplicación, establecería plant_labeler_v1 como el valor predeterminado del parámetro plant_labeler_model , como en el siguiente ejemplo:
Rápido
let remoteConfig = RemoteConfig.remoteConfig()
let defaults = [
"plant_labeler_model": "plant_labeler_v1" as NSObject,
// ...
]
remoteConfig.setDefaults(defaults)
remoteConfig.fetchAndActivate()
C objetivo
FIRRemoteConfig *remoteConfig = [FIRRemoteConfig remoteConfig];
NSDictionary<NSString *, NSObject *> *defaults = @{
@"plant_labeler_model" : (NSObject *)@"plant_labeler_v1",
// ...
};
[remoteConfig setDefaults:defaults];
[remoteConfig fetchAndActivateWithCompletionHandler:nil];
Luego, cambie el código de configuración de su modelo para cargar el modelo especificado por el parámetro plant_labeler_model :
Rápido
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
C objetivo
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
Ahora que su aplicación usa un parámetro de Remote Config para determinar qué modelo cargar, puede cambiar el modelo simplemente publicando un nuevo modelo y asignando su nombre al parámetro de Remote Config. Esta capacidad permite que las pruebas A/B asigne diferentes modelos a diferentes usuarios con el fin de compararlos.
Antes de continuar, agregue también lo siguiente al código de descarga de su modelo:
Rápido
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)
}
}
C objetivo
__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];
}
}];
El código anterior registra un evento de Analytics personalizado que usará más adelante como evento de su experimento.
2. Determinar una métrica de objetivo
El siguiente paso es decidir cómo medirá el éxito de su modelo y asegurarse de que su aplicación recopile los datos necesarios para probar qué tan bien se desempeñan las diferentes versiones del modelo de acuerdo con esa métrica.
Las pruebas A/B tienen varias métricas integradas, incluidos ingresos, participación diaria y retención de usuarios. Estas métricas suelen ser útiles para probar diferentes flujos de UX o ajustar parámetros, pero pueden no tener sentido para evaluar su modelo y caso de uso. En esta situación, puede intentar optimizar para un evento de Analytics personalizado.
Utilizando la función de búsqueda visual de plantas hipotética como ejemplo, suponga que presenta los resultados de la búsqueda a su usuario en el orden de confianza del modelo en cada resultado. Una forma de tener una idea de la precisión de su modelo sería observar la frecuencia con la que los usuarios abrieron el primer resultado de búsqueda.
Para probar qué modelo logró mejor el objetivo de maximizar los clics en los resultados principales, registraría un evento personalizado cada vez que un usuario tocara el primer elemento de la lista de resultados.
Rápido
Analytics.logEvent("first_result_opened", parameters: nil)
C objetivo
[FIRAnalytics logEventWithName:@"first_result_opened" parameters:nil];
La métrica que pruebes depende en última instancia de cómo tu aplicación utiliza tu modelo.
En este punto, puede implementar su aplicación en la App Store. Tu aplicación seguirá usando tu modelo original, pero el código de Remote Config y Analytics que agregaste te permitirá experimentar con diferentes modelos usando solo Firebase console.
3. Ejecute un experimento de prueba A/B
Ahora que su aplicación está en manos de sus usuarios y está recopilando datos analíticos, cree un experimento de prueba A/B que pruebe el efecto de usar su nuevo modelo en lugar del modelo actual.
Para crear el experimento:
En la página Eventos de Firebase console, verifique que esté registrando los eventos de Analytics relevantes: el evento de activación y la métrica de objetivo.
Tu aplicación debe registrar cada evento al menos una vez antes de que aparezca en Firebase console.
En Firebase console, abre la sección Pruebas A/B .
Crea un nuevo experimento:
Haga clic en Crear experimento > Configuración remota .
En la sección Orientación :
- Elige tu aplicación de la lista
- Especifique cuántos de sus usuarios desea incluir en el experimento.
- Seleccione el evento de activación que comenzó a registrar (en este ejemplo, nondefault_model_downloaded ).
En la sección Objetivos , elija la métrica de objetivo que determinó en la sección anterior (en este ejemplo, first_result_opened ) de la lista de métricas de objetivos y seleccione cualquier métrica adicional que desee rastrear, como ingresos por compras o usuarios sin fallas.
En la sección Variantes , defina dos variantes:
- Grupo de control (creado automáticamente)
- Etiquetadora de plantas experimentales
Para el grupo Control , cree un parámetro
plant_labeler_modely configúrelo enplant_labeler_v1. Los usuarios asignados al grupo de control utilizarán el modelo antiguo. (No establezca el parámetro en(no change), ya que en su aplicación está probando que está usando un valor remoto).Para la variante de etiquetador de plantas experimental , establezca el parámetro
plant_labeler_modelenplant_labeler_v2(suponiendo que haya publicado su nuevo modelo con ese nombre). Los usuarios asignados a esta variante utilizarán el nuevo modelo.
Inicie el experimento y déjelo funcionar durante varios días o más, hasta que las pruebas A/B lo declaren líder. Si el experimento no puede determinar un líder, es posible que deba ampliar el experimento a más usuarios .
4. Implemente la variante ganadora para todos los usuarios.
Después de que las pruebas A/B hayan recopilado suficiente información para declarar un líder (en este caso, la variante que maximizó los clics en los principales resultados de búsqueda), puede decidir si implementar la variante ganadora (u otra variante) para todos sus usuarios.
En la sección Pruebas A/B de Firebase console , abre la vista de detalles del experimento completado. Desde esta vista, puede ver el rendimiento de cada variante según su métrica objetivo y cualquier métrica secundaria que haya seleccionado. Con esta información, puedes decidir si implementar la variante principal u otra variante.
Para implementar una variante para todos los usuarios, haga clic en more_vert > Implementar variante en la página de detalles del experimento. Una vez que lo haga, el valor del parámetro plant_labeler_model será plant_labeler_v2 para todos los usuarios.
En una futura actualización de la aplicación, debe cambiar el valor predeterminado del parámetro plant_labeler_model a plant_labeler_v2 y actualizar el modelo incluido si usa uno. Sin embargo, sus usuarios ya están usando el último modelo, por lo que puede enviar esta actualización como parte de la aplicación publicada cuando sea conveniente, como la próxima vez que realice una actualización de funciones.