Predstavljamo pakirani BERT za 2x pospešitev usposabljanja pri obdelavi naravnega jezika

Izvorno vozlišče: 1062065

Predstavljamo pakirani BERT za 2x pospešitev usposabljanja pri obdelavi naravnega jezika

Oglejte si ta novi algoritem pakiranja BERT za učinkovitejše usposabljanje.


By Dr. Mario Michael Krell, glavni vodja strojnega učenja pri Graphcore & Matej Kosec, specialist za aplikacije AI pri Graphcore


glava slike
Slika avtorja.

 

Z uporabo novega algoritma pakiranja smo med usposabljanjem BERT-Large obdelavo naravnega jezika pospešili za več kot dvakrat. Naša nova tehnika pakiranja odstrani oblazinjenje, kar omogoča bistveno bolj učinkovito računanje.

Sumimo, da bi to lahko uporabili tudi za modele genomike in zvijanja beljakovin ter druge modele s poševno porazdeljeno dolžino, da bi dosegli veliko širši vpliv v različnih panogah in aplikacijah.

Predstavili smo Graphcorejev visoko učinkovit algoritem pakiranja histogramov nenegativnih najmanjših kvadratov (ali NNLSHP) kot tudi naš algoritem BERT, ki se uporablja za pakirana zaporedja v novem dokumentu [1].

Računalniška izguba v NLP zaradi oblazinjenja zaporedja

 
 
Začeli smo raziskovati nove načine optimizacije usposabljanja BERT, medtem ko smo delali na našem nedavnem primerjalne predložitve v MLPerf™. Cilj je bil razviti uporabne optimizacije, ki jih je mogoče preprosto uporabiti v aplikacijah v resničnem svetu. BERT je bil naravna izbira kot eden od modelov, na katerega se je treba osredotočiti za te optimizacije, saj ga pogosto uporabljajo v industriji in številne naše stranke.

Resnično nas je presenetilo, ko smo izvedeli, da je bilo v naši aplikaciji za usposabljanje BERT-Large, ki uporablja nabor podatkov Wikipedije, 50 % žetonov v naboru podatkov oblazinjenih, kar je povzročilo veliko izgubljenega računanja.

Zaporedja oblazinjenja, da se vse poravnajo na enako dolžino, so pogost pristop, ki se uporablja pri grafičnih procesorjih, vendar smo mislili, da bi bilo vredno poskusiti drugačen pristop.

Zaporedja imajo velike razlike v dolžini iz dveh razlogov:

  1. Osnovni podatki Wikipedije kažejo velike razlike v dolžini dokumenta
  2. Sama predhodna obdelava BERT naključno zmanjša velikost ekstrahiranih dokumentov, ki so združeni za ustvarjanje zaporedja usposabljanja

Če izpolnite dolžino do največje dolžine 512, bo 50 % vseh žetonov žetonov za polnjenje. Zamenjava 50 % oblazinjenja z resničnimi podatki bi lahko povzročila 50 % več obdelanih podatkov z enakim računskim naporom in s tem dvakratno pospešitev pod optimalnimi pogoji.



Slika 1: Distribucije nabora podatkov Wikipedije. Slika avtorja.

 

Je to specifično za Wikipedijo? št.

No, potem je to specifično za jezik? št.

Pravzaprav se poševne porazdelitve dolžin pojavljajo povsod: v jeziku, genomiki in zvijanju beljakovin. Sliki 2 in 3 prikazujeta porazdelitve za nabor podatkov SQuAD 1.1 in nabore podatkov GLUE.



Slika 2: Histogram dolžine zaporedja nabora podatkov SQuAD 1.1 BERT pred usposabljanjem za največjo dolžino zaporedja 384. Slika avtorja.

 


Slika 3: Histogrami dolžine zaporedja nabora podatkov GLUE za največjo dolžino zaporedja 128. Slika avtorja.

 

Kako lahko ravnamo z različnimi dolžinami in se izognemo računskim zapravljanju?

Trenutni pristopi zahtevajo različna računalniška jedra za različne dolžine ali da inženir programsko odstrani oblazinjenje in ga nato večkrat doda nazaj za vsak blok pozornosti in izračun izgube. Prihranek pri računanju z razstrelitvijo kode in njeno bolj zapleteno ni bilo privlačno, zato smo poiskali nekaj boljšega. Ali ne moremo preprosto združiti več zaporedij v paket z največjo dolžino in vse skupaj obdelati? Izkazalo se je, da lahko!

Ta pristop zahteva tri ključne sestavine:

  1. Učinkovit algoritem za odločanje, katere vzorce sestaviti, da bo ostalo čim manj polnila
  2. Prilagoditev modela BERT za obdelavo paketov namesto zaporedij
  3. In prilagajanje hiperparametrov

Pakiranje

 
 
Sprva se je zdelo malo verjetno, da bi lahko zelo učinkovito zapakirali velik nabor podatkov, kot je Wikipedia. Ta težava je splošno znana kot pakiranje v smeti. Tudi če je pakiranje omejeno na tri zaporedja ali manj, bi bila nastala težava še vedno močno NP-popolna, brez učinkovite algoritemske rešitve. Obstoječi hevristični algoritmi pakiranja niso bili obetavni, ker so imeli kompleksnost vsaj O(n dnevnik(n)), kje n je število zaporedij (~16M za Wikipedijo). Zanimali so nas pristopi, ki bi se dobro prilagodili milijonom zaporedij.

Dva trika sta nam pomagala drastično zmanjšati kompleksnost:

  1. Omejitev števila zaporedij v paketu na tri (za naš prvi pristop rešitve)
  2. Deluje samo na histogramu dolžine zaporedja z enim zalogovnikom za vsako pojavno dolžino

Naša največja dolžina zaporedja je bila 512. Premik na histogram je torej zmanjšal razsežnost in kompleksnost s 16 milijonov zaporedij na 512 dolžin. Dovolitev največ treh zaporedij v paketu je zmanjšala število dovoljenih kombinacij dolžine na 22K. To je že vključevalo trik, ki zahteva, da so zaporedja razvrščena po dolžini v paketu. Zakaj torej ne poskusite s 4 zaporedji? To je povečalo število kombinacij z 22K na 940K, kar je bilo preveč za naš prvi pristop modeliranja. Poleg tega je globina 3 že dosegla izjemno visoko učinkovitost pakiranja.

Prvotno smo mislili, da bi uporaba več kot treh zaporedij v paketu povečala računske stroške in vplivala na konvergenčno vedenje med usposabljanjem. Da bi podprli aplikacije, kot je sklepanje, ki zahtevajo še hitrejše pakiranje v realnem času, smo razvili zelo učinkovit algoritem za pakiranje histogramov nenegativnih najmanjših kvadratov (NNLSHP).

Pakiranje histogramov nenegativnih najmanjših kvadratov (NNLSHP)

 
 
Pakiranje v smeti je pogosto formulirano kot matematični optimizacijski problem. Vendar pri 16 milijonih zaporedij (ali več) to ni praktično. Samo spremenljivke problema bi presegle pomnilnik večine strojev. Matematični program za pristop, ki temelji na histogramu, je precej čeden. Zaradi enostavnosti smo se odločili za pristop najmanjših kvadratov (Ax=b) z vektorjem histograma b. Razširili smo ga z zahtevo po vektorju strategije x biti nenegativen in dodajati uteži, da omogoči manjše oblazinjenje.

Težaven del je bila matrika strategije. Vsak stolpec ima največjo vsoto tri in kodira, katera zaporedja so pakirana skupaj, da se natančno ujemajo z želeno skupno dolžino; 512 v našem primeru. Vrstice kodirajo vsako od možnih kombinacij za doseganje skupne dolžine. Vektor strategije x je tisto, kar smo iskali, kar opisuje, kako pogosto izberemo katero od 20k kombinacij. Zanimivo je, da je bilo na koncu izbranih le okoli 600 kombinacij. Da bi dobili natančno rešitev, šteje strategija x bi morala biti pozitivna cela števila, vendar smo ugotovili, da je približna zaokrožena rešitev s samo nenegativnimi x zadostovala. Za približno rešitev bi lahko uporabili preprost reševalec, ki je že pripravljen, da bi dobili rezultat v 30 sekundah.



Slika 4: Primer matrike strategije za dolžino zaporedja 8 in globino pakiranja 3. Vrstice pomenijo zaporedja dolžine 1–8, ki se pakirajo skupaj, stolpci pa vse možne kombinacije dolžin v paketu brez posebnega vrstnega reda. Slika avtorja.

 

Na koncu smo morali popraviti nekaj vzorcev, ki jim ni bila dodeljena strategija, vendar jih je bilo minimalno. Razvili smo tudi variantni reševalec, ki uveljavlja, da se vsako zaporedje zapakira, potencialno z oblazinjenjem, in ima utež, odvisno od oblazinjenja. Trajalo je veliko dlje, rešitev pa ni bila veliko boljša.

Najkrajši paket - prvo pakiranje histograma

 
 
NNLSHP je za nas zagotovil zadosten pristop pakiranja. Vendar smo se spraševali, ali bi lahko teoretično pridobili hitrejši spletni pristop in odpravili omejitev sestavljanja samo treh zaporedij.

Zato smo se zgledovali po obstoječih algoritmih pakiranja, vendar smo se še vedno osredotočili na histograme.

Obstajajo štiri sestavine za naš prvi algoritem, SPFHP (Shortest-pack-first histogram-packing):

  1. Delujte na podlagi števila histograma od najdaljših zaporedij do najkrajših
  2. Če trenutna dolžina zaporedja ne ustreza nobenemu paketu, zaženite nov niz paketov
  3. Če obstaja več primerkov, vzemite paket, kjer je vsota dolžin zaporedja najkrajša, in ustrezno spremenite število
  4. Znova preverite, ali se ujemajo preostale številke

Ta pristop je bil najpreprostejši za izvedbo in je trajal le 0.02 sekunde.

Različica je bila, da vzamemo največjo vsoto dolžine zaporedja namesto najkrajše in razdelimo štetje, da dobimo popolnejše prileganje. Na splošno to ni bistveno spremenilo učinkovitosti, vendar je zelo povečalo kompleksnost kode.



Kako deluje pakiranje histogramov po najkrajšem paketu. Animacija avtorja.

 

Wikipedia, SQuAD 1.1, rezultati pakiranja GLUE

 
 
Tabele 1, 2 in 3 prikazujejo rezultate pakiranja naših dveh predlaganih algoritmov. Globina pakiranja opisuje največje število pakiranih zaporedij. Globina pakiranja 1 je osnovna izvedba BERT. Največja možna globina pakiranja, če ni nastavljena nobena omejitev, je označena z dodatnim "max". The število paketov opisuje dolžino novega pakiranega nabora podatkov. Učinkovitost je odstotek dejanskih žetonov v zapakiranem naboru podatkov. The faktor pakiranja opisuje posledično potencialno pospešitev v primerjavi z globino pakiranja 1.

Imeli smo štiri glavne ugotovitve:

  1. Bolj ko je porazdelitev izkrivljena, večje so koristi pakiranja.
  2. Vsi nabori podatkov imajo koristi od pakiranja. Nekateri celo za več kot faktor 2.
  3. SPFHP postane učinkovitejši, če globina pakiranja ni omejena.
  4. Za največje število 3 zapakiranih zaporedij je bolj zapleten NNLSHP, bolj učinkovit je (99.75 proti 89.44).



Tabela 1: Ključni rezultati učinkovitosti predlaganih algoritmov pakiranja (SPFHP in NNLSHP) na Wikipediji. Slika avtorja.

 


Tabela 2: Rezultati delovanja predlaganih algoritmov pakiranja za predhodno usposabljanje SQUaD 1.1 BERT. Slika avtorja.

 


Tabela 3: Rezultati delovanja predlaganih algoritmov pakiranja za nabor podatkov GLUE. Prikazana sta samo osnovna linija in rezultati pakiranja SPFHP brez omejitve globine pakiranja. Slika avtorja.

 

Prilagoditev obdelave BERT

 
 
Nekaj ​​zanimivega pri arhitekturi BERT je, da se večina obdelave zgodi na ravni žetona, kar pomeni, da ne moti našega pakiranja. Samo štiri komponente potrebujejo prilagoditev: maska ​​pozornosti, izguba MLM, izguba NSP in natančnost.

Ključ za vse štiri pristope za obravnavanje različnega števila zaporedij je bila vektorizacija in uporaba največjega števila zaporedij, ki jih je mogoče povezati. Za pozornost smo že imeli masko za oblazinjenje. Razširitev tega na več sekvenc je bila preprosta, kot je razvidno iz naslednje psevdo kode TensorFlow. Koncept je, da smo poskrbeli, da je pozornost omejena na ločena zaporedja in ne more segati čez to.

Vzorec kode maske pozornosti.


 


Slika 5: Primer maske nič-ena

 

Za izračun izgube načeloma razpakiramo zaporedja in izračunamo ločene izgube, na koncu pa dobimo povprečje izgub v zaporedjih (namesto paketov).

Za izgubo MLM je koda videti takole:

Vzorec kode za izračun izgube.


 

Za izgubo in natančnost NSP je načelo enako. V naših javnih primerih lahko najdete ustrezno kodo pri našem podjetju Okvir PopART.

Wikipedia režijski stroški in ocena pospešitve

 
 
Pri naši modifikaciji BERT-a smo imeli dve vprašanji:

  1. Koliko režijskih stroškov prinaša s seboj?
  2. Koliko so režijski stroški odvisni od največjega števila zaporedij, ki so sestavljena v paket?

Ker je priprava podatkov v BERT-u lahko okorna, smo uporabili bližnjico in sestavili kodo za več različnih globin pakiranja ter primerjali posamezne (izmerjene) cikle. Rezultati so prikazani v tabeli 4. Z režijske, označujemo odstotek zmanjšanja pretoka zaradi sprememb modela za omogočanje pakiranja (kot je maskirna shema za pozornost in spremenjen izračun izgube). The realizirana pospešitev je kombinacija pospeška zaradi pakiranja ( faktor pakiranja) in zmanjšanje pretoka zaradi režijske.



Tabela 4: Primerjava ocenjene pospešitve predlaganih algoritmov pakiranja (SPFHP in NNLSHP) na Wikipediji. Slika avtorja.

 

Zahvaljujoč tehniki vektorizacije je režijski strošek presenetljivo majhen in ni nobene slabosti pri pakiranju številnih zaporedij skupaj.

Prilagoditve hiperparametrov

 
 
S pakiranjem podvojimo dejansko velikost serije (povprečno). To pomeni, da moramo prilagoditi hiperparametre treninga. Preprost trik je, da prepolovite število kopičenja gradientov, da ohranite enako efektivno povprečno velikost serije kot pred treningom. Z uporabo primerjalne nastavitve z vnaprej pripravljenimi kontrolnimi točkami lahko vidimo, da se krivulje natančnosti popolnoma ujemajo.



Slika 6: Primerjava krivulj učenja za pakirano in nepakirano obdelavo z zmanjšana velikost serije za pakiran pristop. Slike po avtorju.

 

Natančnost se ujema: izguba treninga MLM je lahko na začetku nekoliko drugačna, vendar se hitro ujame. Ta začetna razlika bi lahko izhajala iz rahlih prilagoditev ravni pozornosti, ki so bile morda nagnjene k kratkim sekvencam v prejšnjem usposabljanju.

Da bi se izognili upočasnitvi, včasih pomaga ohraniti prvotno velikost serije enako in prilagoditi hiperparametre na povečano dejansko velikost serije (podvojeno). Glavni hiperparametri, ki jih je treba upoštevati, so parametri beta in stopnje učenja. Eden pogostih pristopov je podvojitev velikosti serije, kar je v našem primeru zmanjšalo zmogljivost. Če pogledamo statistiko optimizatorja LAMB, lahko dokažemo, da zvišanje parametra beta na potenco faktorja pakiranja ustreza zaporednemu usposabljanju več serij, da ohranimo primerljivost zagona in hitrosti.



Slika 7: Primerjava krivulj učenja za pakirano in nepakirano obdelavo z Hevristika uporabljeno. Slike po avtorju.

 

Naši poskusi so pokazali, da je beta na potenco dva dobra hevristika. V tem scenariju se ne pričakuje, da se krivulji ujemata, ker povečanje velikosti serije običajno zmanjša hitrost konvergence v smislu vzorcev/epoh, dokler ni dosežena ciljna natančnost.

Zdaj se postavlja vprašanje, ali v praktičnem scenariju res dosežemo pričakovano pospešitev?



Slika 8: Primerjava krivulj učenja za pakirano in nepakirano obdelavo v optimizirana nastavitev. Slike po avtorju.

 

Da, imamo! Dodatno pohitritev smo pridobili, ker smo stisnili prenos podatkov.

zaključek

 
 
Pakiranje stavkov skupaj lahko prihrani računalniški napor in okolje. To tehniko je mogoče implementirati v kateri koli okvir, vključno s PyTorch in TensorFlow. Dosegli smo jasno 2-kratno pospešitev in ob tem razširili stanje tehnike v algoritmih pakiranja.

Druge aplikacije, ki nas zanimajo, so genomika in zvijanje beljakovin, kjer je mogoče opaziti podobne porazdelitve podatkov. Vision transformatorji bi lahko bili tudi zanimivo področje za uporabo pakiranih slik različnih velikosti. Katere aplikacije bi po vašem mnenju dobro delovale? Radi bi slišali od vas!

Preberi časopis

Dostop do kode na GitHub

Hvala

 
 
Hvala našim kolegom v Graphcorejevi skupini za inženiring aplikacij, Sheng Fu in Mrinal Iyer, za njun prispevek k temu delu in hvala Douglasu Orru iz Graphcoreove raziskovalne ekipe za njegove dragocene povratne informacije.

Reference

 
 
[1] M. Kosec, S. Fu, MM Krell, Pakiranje: Proti 2x NLP BERT Acceleration (2021), arXiv

 
Dr. Mario Michael Krell je glavni vodja strojnega učenja pri Graphcore. Mario že več kot 12 let raziskuje in razvija algoritme strojnega učenja ter ustvarja programsko opremo za tako raznolike industrije, kot so robotika, avtomobilizem, telekomunikacije in zdravstvo. Pri Graphcoreju je prispeval k našemu impresivnemu Predložitve MLPerf in ima strast do pospeševanja novih nestandardnih modelov, kot je približen Bayesov izračun za statistično analizo podatkov COVID-19.

Matej Kosec je specialist za aplikacije AI pri Graphcore v Palo Altu. Pred tem je delal kot znanstvenik za umetno inteligenco na področju avtonomne vožnje pri NIO v San Joseju in ima magisterij iz aeronavtike in astronavtike na univerzi Stanford.

prvotni. Poročeno z dovoljenjem.

Povezano:

Vir: https://www.kdnuggets.com/2021/08/packed-bert-training-speed-up-natural-language-processing.html

Časovni žig:

Več od KDnuggets