Les atouts de l'approche black-box de Vizier

Le terme Vizier désigne le conseiller d'un roi, dérivé de l'arabe وزير wazīr via le persan et le turc. Le Vizier conseille le souverain sur sa politique, sans la décider. C'est exactement ainsi que fonctionne l'optimisation black-box de Vizier : il n'exécute pas les essais d'optimisation à votre place. Les services de tuning d'hyperparamètres de GCP et d'AWS, eux, font tout pour vous. Vous fournissez une plage d'hyperparamètres : par exemple un taux d'apprentissage variant continûment de 0 à 1, ou un minimum child weight sous forme d'entier compris entre 1 et 3. Vous instanciez le client de tuning d'hyperparamètres, puis vous lancez l'opération sans plus vous en soucier via une fonction comme fit(). Celle-ci s'exécute pendant un certain temps, parfois plusieurs heures, et déclenche en interne plusieurs itérations d'entraînement en faisant varier les hyperparamètres. Le tuner renvoie ensuite le meilleur modèle qu'il a pu trouver.

Le processus d'optimisation Black Box échappe à votre contrôle et reste invisible pour vous (du moins du côté de l'API : il existe généralement des systèmes de monitoring en place).

Remarque : Black Box signifie que vos essais sont invisibles pour Vizier. Il ne sait rien de l'entraînement ML ni du test A/B. Il ignore tout des gradients, des hauts et des bas de la fonction optimisée à l'intérieur de chaque essai.

Pour vous, en revanche, ces essais sont entièrement white-box : vous gardez la main.

Un service de tuning d'hyperparamètres paraît plus simple que Vizier, et de fait, Google a bâti Vertex AI AutoML ainsi que les tuners d'hyperparamètres de l'AI Platform (l'ancienne marque) sur un moteur s'appuyant sur Vizier. L'approche Black Box, dans laquelle vous interagissez directement avec Vizier, présente pourtant de réels atouts.

La Black Box Optimization vous donne davantage de contrôle.

Les essais relèvent généralement de votre domaine d'expertise. Vos développeurs web connaissent les moindres détails de votre site ; vos data scientists maîtrisent les subtilités algorithmiques du ML. Vous avez longuement réfléchi à la meilleure façon de tirer parti de vos systèmes au moindre coût. Avec Vizier, vous gardez la pleine maîtrise de l'entraînement ML lui-même : quelle infrastructure ou quelles API utiliser, combien de GPU ou de TPU et lesquels, etc.

Vous pouvez même faire abstraction des suggestions de Vizier et utiliser vos propres paramètres. En règle générale, vous suivrez bien sûr ses suggestions : c'est précisément la raison pour laquelle vous faites appel à lui. Mais imaginez que vous découvriez un nouvel algorithme pour votre ML, ou que les product managers veuillent tester une variante absente du test A/B initial : rien ne vous empêche de vous lancer. Même lorsque vous menez un essai avec vos propres paramètres, vous pouvez transmettre ces paramètres et les métriques à Vizier, qui en tirera des enseignements, exactement comme lorsque vous utilisez ses suggestions.

Vizier ne s'occupe que de la partie " facile " de l'optimisation menée sur de multiples essais. Il ne prend pas en charge le gros œuvre du ML, qui peut exiger beaucoup de matériel spécialisé. Il ne se charge pas non plus du gros œuvre des tests A/B d'un site web ou du pilotage d'une usine. C'est ce qui le rend scalable : vous gérez vous-même l'entraînement réel ou tout autre processus à optimiser — la phase la plus intensive de l'ensemble — et vous pouvez ainsi appliquer les bonnes pratiques les mieux adaptées à votre configuration. (Dans la Figure 1 ci-dessous, vos machines d'entraînement correspondent aux Evaluation workers sous l'API REST de Vizier.)

De son côté, Vizier instancie à la demande des workers pour générer des suggestions ou recommander un arrêt. Comme son état est stocké en base de données plutôt que dans le contexte d'une exécution unique, il peut se remettre d'une panne. Et puisque les workers de suggestion ne font que de l'hyperoptimisation, sans assurer votre gros œuvre, Vizier peut les faire monter en charge efficacement.

Figure 1. Diagramme d'architecture (d'après le schéma de l' article de recherche. )

La plupart des processus d'optimisation, et la plupart des tuners d'hyperparamètres, cherchent à maximiser une seule métrique. C'est aussi l'usage le plus courant de Vertex AI Vizier. Il arrive cependant que l'on veuille optimiser plusieurs métriques simultanément. Dans un test A/B sur un site web, vous voudrez peut-être maximiser à la fois le chiffre d'affaires et le temps passé sur le site. Ou bien vous opérez une marketplace bilatérale, et vous souhaitez à la fois que les acheteurs réalisent de bonnes affaires et que les vendeurs maximisent leurs profits.

Pour illustrer simplement le concept, vous pouvez consulter ce Notebook d'exemple de Google, qui maximise deux fonctions trigonométriques portant sur les deux mêmes paramètres d'entrée.

Figure 2. Aucun point n'est optimal pour les deux fonctions à la fois.

Puisqu'aucun point ne maximise simultanément les deux métriques, Vertex AI Vizier identifie la frontière de Pareto : une ligne au-delà de laquelle il devient impossible d'améliorer une métrique sans en dégrader une autre. L'optimum n'est plus un point, mais une frontière.

Vizier est un système simple, et vous pouvez (et devriez généralement) l'utiliser avec ses paramètres par défaut. Vous pouvez néanmoins en affiner les capacités. Dans le prochain article, nous verrons comment procéder, exemples de code à l'appui.