Grote op aandacht gebaseerde transformatormodellen hebben enorme winsten behaald op het gebied van natuurlijke taalverwerking (NLP). Om deze gigantische netwerken helemaal opnieuw te trainen, is echter een enorme hoeveelheid gegevens en rekenkracht nodig. Voor kleinere NLP-datasets is een eenvoudige maar effectieve strategie om een ​​vooraf getrainde transformator te gebruiken, die meestal zonder toezicht wordt getraind op zeer grote datasets, en deze af te stemmen op de betreffende dataset. Gezicht knuffelen onderhoudt een grote dierentuin van deze voorgetrainde transformatoren en maakt ze gemakkelijk toegankelijk, zelfs voor beginnende gebruikers.

Het verfijnen van deze modellen vereist echter nog steeds specialistische kennis, omdat ze behoorlijk gevoelig zijn voor hun hyperparameters, zoals leersnelheid of batchgrootte. In dit bericht laten we zien hoe we deze hyperparameters kunnen optimaliseren met het open-source framework Syne Tune voor gedistribueerde hyperparameteroptimalisatie (HPO). Met Syne Tune kunnen we een betere hyperparameterconfiguratie vinden die een relatieve verbetering tussen 1-4% behaalt in vergelijking met standaard hyperparameters op populaire LIJM benchmarkgegevenssets. De keuze van het vooraf getrainde model zelf kan ook als een hyperparameter worden beschouwd en daarom automatisch worden geselecteerd door Syne Tune. Bij een tekstclassificatieprobleem leidt dit tot een extra verhoging van de nauwkeurigheid van ongeveer 5% in vergelijking met het standaardmodel. We kunnen echter meer beslissingen automatiseren die een gebruiker moet nemen; we demonstreren dit door ook het type instantie bloot te leggen als een hyperparameter die we later gebruiken om het model te implementeren. Door het juiste instantietype te selecteren, kunnen we configuraties vinden die kosten en latentie optimaal inruilen.

Voor een inleiding tot Syne Tune verwijzen wij u naar: Voer gedistribueerde hyperparameter- en neurale architectuurafstemmingstaken uit met Syne Tune.

Hyperparameter-optimalisatie met Syne Tune

We zullen gebruik maken van de LIJM benchmarksuite, die bestaat uit negen datasets voor taken voor het begrijpen van natuurlijke taal, zoals tekstherkenning of sentimentanalyse. Daarvoor passen we Hugging Face's aan run_glue.py trainingsscript. GLUE-datasets worden geleverd met een vooraf gedefinieerde trainings- en evaluatieset met labels en een hold-out-testset zonder labels. Daarom splitsen we de trainingsset op in een trainings- en validatieset (70%/30% verdeling) en gebruiken we de evaluatieset als onze holdout-testgegevensset. Verder voegen we nog een callback-functie toe aan Hugging Face's Trainer API die de validatieprestaties na elk tijdperk terugrapporteert aan Syne Tune. Zie de volgende code:

import transformers

from syne_tune.report import Reporter

class SyneTuneReporter(transformers.trainer_callback.TrainerCallback):

    def __init__(self):
        self.report = Reporter()

    def on_evaluate(self, args, state, control, **kwargs):
        results = kwargs['metrics'].copy()
        results['step'] = state.global_step
        results['epoch'] = int(state.epoch)
        self.report(**results)

We beginnen met het optimaliseren van typische trainingshyperparameters: de leersnelheid, de opwarmverhouding om de leersnelheid te verhogen en de batchgrootte voor het verfijnen van een vooraf getrainde BERT (bert-base-cased) model, wat het standaardmodel is in het voorbeeld van Hugging Face. Zie de volgende code:

config_space = dict()
config_space['learning_rate'] = loguniform(1e-6, 1e-4)
config_space['per_device_train_batch_size'] =  randint(16, 48)
config_space['warmup_ratio'] = uniform(0, 0.5)

Als onze HPO-methode gebruiken we: ASHA, die hyperparameterconfiguraties uniform willekeurig bemonstert en iteratief de evaluatie van slecht presterende configuraties stopt. Hoewel meer geavanceerde methoden gebruikmaken van een probabilistisch model van de objectieve functie, zoals BO of MoBster bestaat, gebruiken we ASHA voor dit bericht omdat het zonder aannames over de zoekruimte komt.

In de volgende afbeelding vergelijken we de relatieve verbetering van de testfout ten opzichte van de standaard hyperparameterconfiguratie van Hugging Faces.

Voor de eenvoud beperken we de vergelijking tot MRPC, COLA en STSB, maar we zien ook vergelijkbare verbeteringen voor andere GLUE-datasets. Voor elke dataset voeren we ASHA uit op een enkele ml.g4dn.xlarge Amazon Sage Maker instantie met een runtime-budget van 1,800 seconden, wat overeenkomt met respectievelijk ongeveer 13, 7 en 9 volwaardige evaluaties van deze datasets. Om rekening te houden met de intrinsieke willekeur van het trainingsproces, bijvoorbeeld veroorzaakt door de mini-batch-bemonstering, draaien we zowel ASHA als de standaardconfiguratie voor vijf herhalingen met een onafhankelijke seed voor de generator van willekeurige getallen en rapporteren we de gemiddelde en standaarddeviatie van de relatieve verbetering over de herhalingen heen. We kunnen zien dat we voor alle datasets in feite de voorspellende prestaties met 1-3% kunnen verbeteren ten opzichte van de prestaties van de zorgvuldig geselecteerde standaardconfiguratie.

Automatiseer het selecteren van het vooraf getrainde model

Met HPO kunnen we niet alleen hyperparameters vinden, maar ook automatisch het juiste voorgetrainde model selecteren. Waarom willen we dit doen? Omdat geen enkel model beter presteert dan alle datasets, moeten we het juiste model voor een specifieke dataset selecteren. Om dit aan te tonen, evalueren we een reeks populaire transformatormodellen van Hugging Face. Voor elke dataset rangschikken we elk model op basis van zijn testprestaties. De rangschikking over datasets (zie de volgende afbeelding) verandert en niet één model dat het hoogst scoort op elke dataset. Als referentie tonen we ook de absolute testprestaties van elk model en dataset in de volgende afbeelding.

Om automatisch het juiste model te selecteren, kunnen we de keuze van het model casten als categorische parameters en dit toevoegen aan onze hyperparameter-zoekruimte:

config_space['model_name_or_path'] = choice(['bert-base-cased', 'bert-base-uncased', 'distilbert-base-uncased', 'distilbert-base-cased', 'roberta-base', 'albert-base-v2', 'distilroberta-base', 'xlnet-base-cased', 'albert-base-v1'])

Hoewel de zoekruimte nu groter is, betekent dat niet per se dat het moeilijker is om te optimaliseren. De volgende afbeelding toont de testfout van de best waargenomen configuratie (gebaseerd op de validatiefout) op de MRPC-dataset van ASHA in de loop van de tijd wanneer we zoeken in de oorspronkelijke ruimte (blauwe lijn) (met een op BERT gebaseerd voorgetraind model ) of in de nieuwe uitgebreide zoekruimte (oranje lijn). Met hetzelfde budget kan ASHA een veel beter presterende hyperparameterconfiguratie vinden in de uitgebreide zoekruimte dan in de kleinere ruimte.

Automatiseer het selecteren van het instantietype

In de praktijk gaat het ons misschien niet alleen om het optimaliseren van voorspellende prestaties. We kunnen ons ook bekommeren om andere doelstellingen, zoals trainingstijd, (dollar)kosten, latentie of rechtvaardigheidsstatistieken. We moeten ook andere keuzes maken dan de hyperparameters van het model, bijvoorbeeld het selecteren van het instantietype.

Hoewel het instantietype geen invloed heeft op de voorspellende prestaties, heeft het wel een grote invloed op de (dollar)kosten, de looptijd van de training en de latentie. Dit laatste wordt vooral belangrijk wanneer het model wordt ingezet. We kunnen HPO formuleren als een optimalisatieprobleem met meerdere doelstellingen, waarbij we ernaar streven meerdere doelstellingen tegelijk te optimaliseren. Geen enkele oplossing optimaliseert echter alle statistieken tegelijkertijd. In plaats daarvan proberen we een reeks configuraties te vinden die het ene doel optimaal inruilen tegen het andere. Dit heet de Pareto-set.

Om deze instelling verder te analyseren, voegen we de keuze van het instantietype toe als een extra categorische hyperparameter aan onze zoekruimte:

config_space['st_instance_type'] = choice(['ml.g4dn.xlarge', 'ml.g4dn.2xlarge', 'ml.p2.xlarge', 'ml.g4dn.4xlarge', 'ml.g4dn.8xlarge', 'ml.p3.2xlarge'])

Wij gebruiken MO-ASHA, die ASHA aanpast aan het scenario met meerdere doelstellingen door gebruik te maken van niet-gedomineerde sortering. In elke iteratie selecteert MO-ASHA ook voor elke configuratie het type instantie waarop we het willen evalueren. Om HPO op een heterogene set instanties uit te voeren, biedt Syne Tune de SageMaker-backend. Met deze backend wordt elke proef geëvalueerd als een onafhankelijke SageMaker-trainingstaak op zijn eigen exemplaar. Het aantal werkers bepaalt hoeveel SageMaker-taken we tegelijkertijd uitvoeren. De optimizer zelf, MO-ASHA in ons geval, draait ofwel op de lokale machine, een Sagemaker-notebook of op een aparte SageMaker-trainingstaak. Zie de volgende code:

backend = SageMakerBackend(
    sm_estimator=HuggingFace(
        entry_point=str('run_glue.py'),
        source_dir=os.getcwd(),
        base_job_name='glue-moasha',
        # instance-type given here are override by Syne Tune with values sampled from `st_instance_type`.
        instance_type='ml.m5.large',
        instance_count=1,
        py_version="py38",
        pytorch_version='1.9',
        transformers_version='4.12',
        max_run=3600,
        role=get_execution_role(),
    ),
)

De volgende afbeeldingen tonen de latentie versus testfout aan de linkerkant en latentie versus kosten aan de rechterkant voor willekeurige configuraties die zijn gesampled door MO-ASHA (we beperken de as voor zichtbaarheid) op de MRPC-dataset nadat deze 10,800 seconden op vier werknemers is uitgevoerd. Kleur geeft het instantietype aan. De gestippelde zwarte lijn vertegenwoordigt de Pareto-verzameling, dat wil zeggen de verzameling punten die alle andere punten in ten minste één doelstelling domineren.

We kunnen een afweging zien tussen latentie en testfout, wat betekent dat de beste configuratie met de laagste testfout niet de laagste latentie bereikt. Op basis van uw voorkeur kunt u een hyperparameterconfiguratie selecteren die inlevert op testprestaties, maar wordt geleverd met een kleinere latentie. We zien ook de afweging tussen latentie en kosten. Door bijvoorbeeld een kleinere ml.g4dn.xlarge-instantie te gebruiken, verhogen we de latentie slechts marginaal, maar betalen we een vierde van de kosten van een ml.g4dn.8xlarge-instantie.

Conclusie

In dit bericht hebben we hyperparameteroptimalisatie besproken voor het verfijnen van vooraf getrainde transformatormodellen van Hugging Face op basis van Syne Tune. We hebben gezien dat we door het optimaliseren van hyperparameters zoals leersnelheid, batchgrootte en opwarmverhouding, de zorgvuldig gekozen standaardconfiguratie kunnen verbeteren. We kunnen dit ook uitbreiden door automatisch het vooraf getrainde model te selecteren via hyperparameteroptimalisatie.

Met behulp van de SageMaker-backend van Syne Tune kunnen we het instantietype behandelen als een hyperparameter. Hoewel het instantietype geen invloed heeft op de prestaties, heeft het een aanzienlijke invloed op de latentie en kosten. Daarom kunnen we, door HPO te beschouwen als een optimalisatieprobleem met meerdere doelstellingen, een reeks configuraties vinden die het ene doel optimaal afwegen tegen het andere. Wil je dit zelf eens proberen, kijk dan op onze voorbeeld notebook.

Over de auteurs

Aaron Klein is een Applied Scientist bij AWS.

Matthias Seegers is Principal Applied Scientist bij AWS.

David Salinas is Sr Applied Scientist bij AWS.

Emily Webber kwam bij AWS net na de lancering van SageMaker en probeert sindsdien de wereld erover te vertellen! Naast het bouwen van nieuwe ML-ervaringen voor klanten, mediteert Emily graag en bestudeert ze het Tibetaans boeddhisme.

Cédric Archambeau is Principal Applied Scientist bij AWS en Fellow van het European Lab for Learning and Intelligent Systems.