Flexibilité de l'optimisation Black Box de Vizier

Votre dialogue avec Vizier se présente ainsi : en entrée, les paramètres et la métrique d'un essai que vous avez exécuté ; en sortie, des suggestions de paramètres pour l'essai suivant. Mais Vizier offre davantage de flexibilité lorsque c'est nécessaire. Je recommande toutefois la prudence avant de toucher à ces options de configuration avancées. Vizier réalise une optimisation imbriquée : les essais eux-mêmes sont des optimisations, et Vizier vise à converger vers la meilleure réponse à travers ces répétitions, dont chacune est coûteuse. Si vous ajoutez une autre couche d'imbrication en lançant plusieurs études Vizier sur le même problème, en ajustant à chaque fois sa configuration optionnelle, le coût de ces optimisations risque fort de dépasser les bénéfices.

Vous pouvez choisir l'algorithme que Vizier utilise pour parcourir l'espace des paramètres et trouver le meilleur jeu de paramètres. Le premier est la recherche par grille (grid search), qui balaie régulièrement l'espace des paramètres en testant autant d'options que possible compte tenu du nombre limité d'itérations. Vient ensuite la recherche aléatoire : on saute simplement d'un point à un autre dans l'espace des paramètres, ce qui peut donner d'excellents résultats. Ces deux algorithmes paraissent assez basiques et vous pourriez les exécuter sans Vizier ; que vous parcouriez méthodiquement la plage des hyperparamètres ou que vous testiez des combinaisons au hasard, les résultats seraient identiques. Mais avec Vizier, le processus est suivi et géré pour vous. La recherche par grille et la recherche aléatoire sont gratuites dans Vizier.

Plus sophistiquée, la recherche bayésienne s'appuie sur un modèle interne créé par Vizier pour optimiser les suggestions. (Voir la publication de recherche pour plus de détails.) Contrairement aux sauts aléatoires ou aux pas prédéterminés, cette approche converge bien plus rapidement.

La recherche bayésienne est l'option par défaut, et la seule facturée : un dollar par essai au-delà des 100 premiers essais mensuels, qui sont gratuits. Vizier ayant été conçu pour minimiser la répétition de processus d'optimisation onéreux, ce tarif est dérisoire face, par exemple, à une seule itération d'entraînement ML qui peut coûter 20 $, ou à un test A/B susceptible de représenter des milliers de dollars de revenus potentiellement perdus. Et en proposant un service d'hyperoptimisation plutôt qu'une bibliothèque à déployer soi-même, Vizier vous épargne le temps et le coût de la mise en place de l'architecture.

Comme indiqué, Vizier peut vous conseiller sur le moment où s'arrêter. Sur le graphique ci-dessous, la courbe verte en pointillés progresse d'abord, puis finit par se dégrader : il est donc judicieux d'arrêter, et Vizier sait le détecter. La courbe orange en pointillés, en revanche, s'améliore rapidement et il vaut la peine de poursuivre ; les courbes pleines se situent quant à elles entre les deux. Vous pouvez configurer l'algorithme utilisé par Vizier à cet effet : lui demander de recommander l'arrêt de l'étude lorsque la dernière itération n'est pas meilleure que la médiane de toutes les précédentes, ou pas meilleure que les quelques dernières.

Figure 1. Suggestions d'arrêt (d'après la publication de recherche. )

Une fois l'étude terminée, Vizier vous indique quel jeu de paramètres a été le meilleur, et vous pouvez lui préciser la méthode de sélection. Il peut sembler évident de retenir l'essai ayant produit les meilleures métriques, et c'est l'option par défaut. Mais si votre processus comporte beaucoup de bruit (voir l'image ci-dessous), le pic peut n'être que le fruit du hasard, un sursaut momentané, parfois appelé la malédiction du vainqueur. Si vous savez que ce type de bruit est présent, mais que la tendance est globalement à la hausse, vous pouvez demander à Vizier de simplement retenir le dernier essai.

Figure 2. La malédiction du vainqueur : pourquoi il vaut parfois mieux ne pas retenir le meilleur essai

Vizier peut réutiliser de manière incrémentale ce qu'il a appris, en créant une nouvelle étude qui s'appuie sur une étude antérieure similaire. Imaginons que vous ayez optimisé votre site web par tests A/B avec l'aide de Vizier, mais qu'une nouvelle version dotée d'importantes fonctionnalités sorte quelques semaines plus tard et que vous souhaitiez les ajuster également. Avec resumePreviousJobId, vous transférez les apprentissages d'une autre étude. À la clé, des économies importantes de temps et d'argent : vous réutilisez des efforts de modélisation déjà réalisés et exécutez bien moins de ces essais lents et coûteux que Vizier vous aide à orienter.

Aujourd'hui, cette fonctionnalité n'est prise en charge que dans la version interne de Vizier qui alimente le tuner d'hyperparamètres d'AI Platform, et non dans les API portant la marque Vizier.

Vizier propose plusieurs API.

L'API Vertex AI Vizier (parfois appelée GAPIC, d'après le générateur de client Protocol Buffer utilisé) s'articule autour d'une classe Python, VizierServiceClient. Il s'agit d'un produit en disponibilité générale et de l'orientation que Google privilégie pour l'avenir. C'est donc l'API principale sur laquelle se concentrer.

Vizier est également exposé via une autre API, rétroportée vers l'ancienne GCP AI Platform et désormais en bêta. Cette API est de type discovery : aucune fonction n'est implémentée explicitement dans la bibliothèque ; vous appelez à la place des fonctions définies via une couche d'enrobage dynamique. Ce n'est pas aussi compliqué qu'il y paraît : la documentation, l'expérimentation et les exemples de code (dont le mien, ci-dessous) la rendent tout à fait utilisable.

L'autre implémentation de Vizier, comme indiqué, est le projet open-source, si vous souhaitez le gérer vous-même ou simplement en parcourir le code.

Les exemples de code disponibles sont rares. La documentation officielle de Vizier ne propose en effet qu'un seul notebook ML pour l'API Vizier rétroportée vers AI Platform, et aucun pour l'API Vertex AI Vizier, pourtant privilégiée. J'ai donc préparé ce notebook. Il s'articule autour d'un processus classique d'entraînement ML exécuté en interne dans le conteneur (sachant que Vizier est indépendant de la manière dont cet entraînement est lancé). Vous pouvez le parcourir grâce aux commentaires de code numérotés #[0], #[1], etc.

Par ailleurs, Ryan Holbrook a créé ce notebook open-source. Vous préférerez peut-être utiliser cette variante que j'ai préparée : elle affiche le résultat d'une exécution réussie et a été légèrement ajustée pour faciliter une exécution de bout en bout sans configuration supplémentaire.