🥇Shfrytëzimi i mësimit të makinerive në Mail.ru Mail

Bazuar në fjalimet e mia në Highload++ dhe DataFest Minsk 2019.

Për shumë njerëz sot, posta është një pjesë integrale e jetës në internet. Me ndihmën e tij, ne kryejmë korrespondencë biznesi, ruajmë të gjitha llojet e informacioneve të rëndësishme në lidhje me financat, prenotimet e hoteleve, vendosjen e porosive dhe shumë më tepër. Në mesin e vitit 2018, ne formuluam një strategji produkti për zhvillimin e postës. Si duhet të jetë posta moderne?

Posta duhet të jetë i zgjuar, domethënë, duke ndihmuar përdoruesit të lundrojnë në vëllimin në rritje të informacionit: filtroni, strukturoni dhe siguroni atë në mënyrën më të përshtatshme. Ajo duhet të jetë e dobishme, duke ju lejuar të zgjidhni detyra të ndryshme direkt në kutinë tuaj postare, për shembull, të paguani gjoba (një funksion që, për fat të keq, unë e përdor). Dhe në të njëjtën kohë, natyrisht, posta duhet të sigurojë mbrojtje të informacionit, duke ndërprerë postën e padëshiruar dhe duke mbrojtur kundër hakimit, d.m.th. i sigurt.

Këto fusha përcaktojnë një numër problemesh kryesore, shumë prej të cilave mund të zgjidhen në mënyrë efektive duke përdorur mësimin e makinerive. Këtu janë shembuj të veçorive tashmë ekzistuese të zhvilluara si pjesë e strategjisë - një për çdo drejtim.

Përgjigje e mençur. Mail ka një veçori të përgjigjes inteligjente. Rrjeti nervor analizon tekstin e letrës, kupton kuptimin dhe qëllimin e saj dhe si rezultat ofron tre opsionet më të përshtatshme të përgjigjes: pozitive, negative dhe neutrale. Kjo ndihmon për të kursyer ndjeshëm kohë kur u përgjigjeni letrave, dhe gjithashtu shpesh përgjigjeni në një mënyrë jo standarde dhe qesharake.
Grupimi i emailevelidhur me porositë në dyqanet online. Ne shpesh bëjmë blerje në internet dhe, si rregull, dyqanet mund të dërgojnë disa email për çdo porosi. Për shembull, nga AliExpress, shërbimi më i madh, vijnë shumë shkronja për një porosi dhe ne kemi llogaritur që në rastin e terminalit numri i tyre mund të arrijë deri në 29. Prandaj, duke përdorur modelin "Njohja e njësive me emër", nxjerrim numrin e porosisë. dhe informacione të tjera nga teksti dhe gruponi të gjitha shkronjat në një fije. Ne gjithashtu shfaqim informacionin bazë rreth porosisë në një kuti të veçantë, gjë që e bën më të lehtë punën me këtë lloj emaili.
Antiphishing. Phishing është një lloj emaili mashtrues veçanërisht i rrezikshëm, me ndihmën e të cilit sulmuesit përpiqen të marrin informacione financiare (përfshirë kartat bankare të përdoruesit) dhe hyrje. Letrat e tilla imitojnë ato reale të dërguara nga shërbimi, përfshirë vizualisht. Prandaj, me ndihmën e Computer Vision, ne njohim logot dhe stilin e projektimit të letrave nga kompanitë e mëdha (për shembull, Mail.ru, Sber, Alfa) dhe e marrim parasysh këtë së bashku me tekstin dhe veçoritë e tjera në klasifikuesit tanë të spam dhe phishing .

Të mësuarit makinerik

Pak për mësimin e makinerive në email në përgjithësi. Posta është një sistem shumë i ngarkuar: mesatarisht 1,5 miliardë letra në ditë kalojnë nëpër serverët tanë për 30 milionë përdorues të DAU. Rreth 30 sisteme të mësimit të makinerive mbështesin të gjitha funksionet dhe veçoritë e nevojshme.

Çdo shkronjë kalon nëpër një tubacion të tërë klasifikimi. Së pari ne ndërpresim mesazhet e padëshiruara dhe lëmë emaile të mira. Përdoruesit shpesh nuk e vënë re punën e antispam-it, sepse 95-99% e spamit nuk përfundojnë as në dosjen përkatëse. Njohja e spamit është një pjesë shumë e rëndësishme e sistemit tonë, dhe më e vështira, pasi në fushën e anti-spam ka një përshtatje të vazhdueshme midis sistemeve të mbrojtjes dhe sulmit, gjë që ofron një sfidë të vazhdueshme inxhinierike për ekipin tonë.

Më pas, ne ndajmë letrat nga njerëzit dhe robotët. Email-et nga njerëzit janë më të rëndësishmit, ndaj ne ofrojmë veçori si Përgjigja inteligjente për ta. Letrat nga robotët ndahen në dy pjesë: transaksionale - këto janë letra të rëndësishme nga shërbimet, për shembull, konfirmimet e blerjeve ose rezervimet e hoteleve, financat dhe informacioni - këto janë reklama biznesi, zbritje.

Ne besojmë se emailet transaksionale kanë rëndësi të barabartë me korrespondencën personale. Ata duhet të jenë pranë, sepse shpesh na duhet të gjejmë shpejt informacione për një porosi ose rezervim të biletës ajrore dhe kalojmë kohë duke kërkuar për këto letra. Prandaj, për lehtësi, ne i ndajmë automatikisht në gjashtë kategori kryesore: udhëtime, porosi, financa, bileta, regjistrime dhe, së fundi, gjoba.

Letrat e informacionit janë grupi më i madh dhe ndoshta më pak i rëndësishëm, të cilat nuk kërkojnë një përgjigje të menjëhershme, pasi asgjë e rëndësishme nuk do të ndryshojë në jetën e përdoruesit nëse ai nuk lexon një letër të tillë. Në ndërfaqen tonë të re, ne i fshijmë ato në dy tema: rrjetet sociale dhe gazetat, duke pastruar vizualisht kutinë hyrëse dhe duke lënë të dukshme vetëm mesazhe të rëndësishme.

Shfrytëzimi

Një numër i madh sistemesh shkakton shumë vështirësi në funksionim. Në fund të fundit, modelet degradohen me kalimin e kohës, si çdo softuer: funksionet prishen, makinat dështojnë, kodi bëhet i shtrembër. Përveç kësaj, të dhënat po ndryshojnë vazhdimisht: shtohen të reja, transformohen modelet e sjelljes së përdoruesit, etj., kështu që një model pa mbështetjen e duhur do të funksionojë gjithnjë e më keq me kalimin e kohës.

Nuk duhet të harrojmë se sa më i thellë të depërtojë mësimi i makinerive në jetën e përdoruesve, aq më i madh është ndikimi që ata kanë në ekosistem dhe, si rezultat, aq më shumë humbje financiare ose fitime mund të marrin lojtarët e tregut. Prandaj, në një numër në rritje fushash, lojtarët po përshtaten me punën e algoritmeve ML (shembuj klasikë janë reklamimi, kërkimi dhe antispam i përmendur tashmë).

Gjithashtu, detyrat e mësimit të makinerive kanë një veçori: çdo ndryshim, madje edhe i vogël, në sistem mund të gjenerojë shumë punë me modelin: punë me të dhëna, rikualifikim, vendosje, të cilat mund të zgjasin javë ose muaj. Prandaj, sa më shpejt të ndryshojë mjedisi në të cilin funksionojnë modelet tuaja, aq më shumë përpjekje kërkon për t'i ruajtur ato. Një ekip mund të krijojë shumë sisteme dhe të jetë i lumtur për këtë, por më pas shpenzon pothuajse të gjitha burimet e tij për t'i mirëmbajtur ato, pa pasur mundësinë për të bërë ndonjë gjë të re. Dikur kemi hasur në një situatë të tillë në ekipin antispam. Dhe ata bënë përfundimin e qartë se mbështetja duhet të automatizohet.

automatizim

Çfarë mund të automatizohet? Pothuajse gjithçka, në fakt. Unë kam identifikuar katër fusha që përcaktojnë infrastrukturën e mësimit të makinerisë:

Mbledhja e të dhënave;
trajnime shtesë;
vendosja;
testimi dhe monitorimi.

Nëse mjedisi është i paqëndrueshëm dhe vazhdimisht ndryshon, atëherë e gjithë infrastruktura rreth modelit rezulton të jetë shumë më e rëndësishme se vetë modeli. Mund të jetë një klasifikues i mirë i vjetër linear, por nëse e ushqeni me veçoritë e duhura dhe merrni reagime të mira nga përdoruesit, do të funksionojë shumë më mirë se modelet më të fundit me të gjitha këmbanat dhe bilbilat.

Cikli i reagimit

Ky cikël kombinon mbledhjen e të dhënave, trajnimin shtesë dhe vendosjen - në fakt, të gjithë ciklin e përditësimit të modelit. Pse është e rëndësishme? Shikoni orarin e regjistrimit në postë:

Një zhvillues i mësimit të makinerive ka zbatuar një model anti-bot që parandalon që robotët të regjistrohen në email. Grafiku bie në një vlerë ku mbeten vetëm përdoruesit e vërtetë. Gjithçka është e mrekullueshme! Por kalojnë katër orë, bot-et modifikojnë skriptet e tyre dhe gjithçka kthehet në normalitet. Në këtë zbatim, zhvilluesi kaloi një muaj duke shtuar veçori dhe duke ritrajnuar modelin, por spammer-i ishte në gjendje të përshtatej në katër orë.

Në mënyrë që të mos jemi kaq të dhimbshëm dhe të mos na duhet të ribëjmë gjithçka më vonë, fillimisht duhet të mendojmë se si do të duket cikli i reagimit dhe çfarë do të bëjmë nëse mjedisi ndryshon. Le të fillojmë me mbledhjen e të dhënave - ky është karburanti për algoritmet tona.

Mbledhja e të dhënave

Është e qartë se për rrjetet nervore moderne, sa më shumë të dhëna, aq më mirë, dhe ato, në fakt, gjenerohen nga përdoruesit e produktit. Përdoruesit mund të na ndihmojnë duke shënuar të dhëna, por ne nuk mund të abuzojmë me këtë, sepse në një moment përdoruesit do të lodhen duke plotësuar modelet tuaja dhe do të kalojnë në një produkt tjetër.

Një nga gabimet më të zakonshme (këtu i referohem Andrew Ng) është përqendrimi i tepërt në metrikat në grupin e të dhënave të testit, dhe jo në reagimet nga përdoruesi, i cili në fakt është matësi kryesor i cilësisë së punës, pasi ne krijojmë një produkt për përdoruesit. Nëse përdoruesi nuk e kupton ose nuk i pëlqen puna e modelit, atëherë gjithçka është e shkatërruar.

Prandaj, përdoruesi duhet të jetë gjithmonë në gjendje të votojë dhe duhet t'i jepet një mjet për reagime. Nëse mendojmë se në kutinë postare ka mbërritur një letër në lidhje me financat, duhet ta shënojmë "financim" dhe të vizatojmë një buton që përdoruesi mund të klikojë dhe të thotë se kjo nuk është financë.

Cilësia e komenteve

Le të flasim për cilësinë e reagimeve të përdoruesve. Së pari, ju dhe përdoruesi mund të vendosni kuptime të ndryshme në një koncept. Për shembull, ju dhe menaxherët e produktit tuaj mendoni se "financa" do të thotë letra nga banka dhe përdoruesi mendon se një letër nga gjyshja për pensionin e saj i referohet edhe financave. Së dyti, ka përdorues që pa mend u pëlqen të shtypin butonat pa asnjë logjikë. Së treti, përdoruesi mund të jetë thellësisht i gabuar në përfundimet e tij. Një shembull i mrekullueshëm nga praktika jonë është zbatimi i një klasifikuesi Spam nigerian, një lloj spam shumë qesharak ku përdoruesit i kërkohet të marrë disa milionë dollarë nga një i afërm i largët i gjetur papritur në Afrikë. Pas zbatimit të këtij klasifikuesi, ne kontrolluam klikimet "Jo e padëshiruar" në këto email dhe rezultoi se 80% e tyre ishin mesazhe të padëshiruara nigeriane, gjë që sugjeron se përdoruesit mund të jenë jashtëzakonisht sylesh.

Dhe të mos harrojmë se butonat mund të klikohen jo vetëm nga njerëzit, por edhe nga të gjitha llojet e robotëve që pretendojnë të jenë një shfletues. Pra, reagimet e papërpunuara nuk janë të mira për të mësuar. Çfarë mund të bëni me këtë informacion?

Ne përdorim dy qasje:

Reagime nga ML e lidhur. Për shembull, ne kemi një sistem anti-bot online, i cili, siç e përmenda, merr një vendim të shpejtë bazuar në një numër të kufizuar shenjash. Dhe ka një sistem të dytë, të ngadaltë që funksionon pas faktit. Ka më shumë të dhëna për përdoruesin, sjelljen e tij, etj. Si rezultat, merret vendimi më i informuar; në përputhje me rrethanat, ai ka saktësi dhe plotësi më të lartë. Ju mund ta drejtoni ndryshimin në funksionimin e këtyre sistemeve tek i pari si të dhëna trajnimi. Kështu, një sistem më i thjeshtë do të përpiqet gjithmonë t'i afrohet performancës së një sistemi më kompleks.
Klasifikimi klikoni. Ju thjesht mund të klasifikoni çdo klikim të përdoruesit, të vlerësoni vlefshmërinë dhe përdorshmërinë e tij. Ne e bëjmë këtë në postën antispam, duke përdorur atributet e përdoruesit, historinë e tij, atributet e dërguesit, vetë tekstin dhe rezultatin e klasifikuesve. Si rezultat, ne marrim një sistem automatik që vërteton reagimet e përdoruesve. Dhe meqenëse duhet të rikualifikohet shumë më rrallë, puna e tij mund të bëhet bazë për të gjitha sistemet e tjera. Prioriteti kryesor në këtë model është saktësia, sepse trajnimi i modelit për të dhëna të pasakta është i mbushur me pasoja.

Ndërsa pastrojmë të dhënat dhe trajnojmë më tej sistemet tona ML, nuk duhet të harrojmë përdoruesit, sepse për ne, mijëra, miliona gabime në grafik janë statistika, dhe për përdoruesit, çdo gabim është një tragjedi. Përveç faktit që përdoruesi duhet të jetojë disi me gabimin tuaj në produkt, pasi të marrë reagime, ai pret që një situatë e ngjashme të eliminohet në të ardhmen. Prandaj, gjithmonë ia vlen t'u jepet përdoruesve jo vetëm mundësia për të votuar, por edhe për të korrigjuar sjelljen e sistemeve ML, duke krijuar, për shembull, heuristika personale për çdo klikim reagimi; në rastin e postës, kjo mund të jetë aftësia për të filtruar letra të tilla nga dërguesi dhe titulli për këtë përdorues.

Ju gjithashtu duhet të ndërtoni një model bazuar në disa raporte ose kërkesa për mbështetje në një mënyrë gjysmë automatike ose manuale, në mënyrë që përdoruesit e tjerë të mos vuajnë nga probleme të ngjashme.

Heuristika për të mësuar

Ka dy probleme me këto heuristika dhe paterica. E para është se numri gjithnjë në rritje i patericave është i vështirë për t'u mirëmbajtur, e lëre më cilësinë dhe performancën e tyre për një kohë të gjatë. Problemi i dytë është se gabimi mund të mos jetë i shpeshtë dhe disa klikime për të trajnuar më tej modelin nuk do të mjaftojnë. Duket se këto dy efekte të palidhura mund të neutralizohen ndjeshëm nëse zbatohet qasja e mëposhtme.

Ne krijojmë një paterica të përkohshme.
Ne dërgojmë të dhëna prej tij në model, ai përditësohet rregullisht vetë, duke përfshirë të dhënat e marra. Këtu, natyrisht, është e rëndësishme që heuristikat të kenë saktësi të lartë në mënyrë që të mos ulin cilësinë e të dhënave në grupin e trajnimit.
Pastaj vendosim monitorimin për të ndezur patericën, dhe nëse pas njëfarë kohe paterica nuk funksionon më dhe mbulohet plotësisht nga modeli, atëherë mund ta hiqni me siguri. Tani ky problem nuk ka gjasa të përsëritet.

Pra, një ushtri me paterica është shumë e dobishme. Gjëja kryesore është që shërbimi i tyre të jetë urgjent dhe jo i përhershëm.

Trajnim shtesë

Rikualifikimi është procesi i shtimit të të dhënave të reja të marra si rezultat i reagimeve nga përdoruesit ose sistemet e tjera, dhe trajnimi i një modeli ekzistues mbi të. Mund të ketë disa probleme me trajnimin shtesë:

Modeli thjesht mund të mos mbështesë trajnime shtesë, por të mësojë vetëm nga e para.
Askund në librin e natyrës nuk është shkruar se trajnimi shtesë sigurisht që do të përmirësojë cilësinë e punës në prodhim. Shpesh ndodh e kundërta, pra vetëm përkeqësimi është i mundur.
Ndryshimet mund të jenë të paparashikueshme. Kjo është një pikë mjaft delikate që ne e kemi identifikuar për veten tonë. Edhe nëse një model i ri në një test A/B tregon rezultate të ngjashme në krahasim me atë aktual, kjo nuk do të thotë se do të funksionojë në mënyrë identike. Puna e tyre mund të ndryshojë në vetëm një përqind, gjë që mund të sjellë gabime të reja ose të kthejë të vjetrat që tashmë janë korrigjuar. Si ne ashtu edhe përdoruesit tashmë dimë se si të jetojmë me gabimet aktuale, dhe kur shfaqen një numër i madh gabimesh të reja, përdoruesi gjithashtu mund të mos kuptojë se çfarë po ndodh, sepse ai pret sjellje të parashikueshme.

Prandaj, gjëja më e rëndësishme në trajnimin shtesë është të sigurohet që modeli të përmirësohet, ose të paktën të mos përkeqësohet.

Gjëja e parë që na vjen në mendje kur flasim për trajnime shtesë është qasja e të mësuarit aktiv. Çfarë do të thotë kjo? Për shembull, klasifikuesi përcakton nëse një email është i lidhur me financat, dhe rreth kufirit të vendimit të tij ne shtojmë një mostër shembujsh të etiketuar. Kjo funksionon mirë, për shembull, në reklamat, ku ka shumë reagime dhe ju mund ta trajnoni modelin në internet. Dhe nëse ka pak reagime, atëherë marrim një mostër shumë të njëanshme në lidhje me shpërndarjen e të dhënave të prodhimit, në bazë të së cilës është e pamundur të vlerësohet sjellja e modelit gjatë funksionimit.

Në fakt, qëllimi ynë është të ruajmë modelet e vjetra, modelet tashmë të njohura dhe të marrim të reja. Vazhdimësia është e rëndësishme këtu. Modeli, për të cilin shpesh kemi munduar shumë për ta nxjerrë në treg, tashmë po funksionon, ndaj mund të fokusohemi në performancën e tij.

Në postë përdoren modele të ndryshme: pemë, lineare, rrjete nervore. Për secilin ne bëjmë algoritmin tonë shtesë të trajnimit. Në procesin e trajnimit shtesë, ne marrim jo vetëm të dhëna të reja, por shpesh edhe veçori të reja, të cilat do t'i marrim parasysh në të gjitha algoritmet e mëposhtme.

Modele lineare

Le të themi se kemi regresion logjistik. Ne krijojmë një model humbjeje nga komponentët e mëposhtëm:

LogLoss në të dhënat e reja;
rregullojmë peshat e veçorive të reja (nuk i prekim të vjetrat);
ne gjithashtu mësojmë nga të dhënat e vjetra për të ruajtur modelet e vjetra;
dhe, ndoshta, gjëja më e rëndësishme: shtojmë Rregullimin Harmonik, i cili garanton që peshat nuk do të ndryshojnë shumë në krahasim me modelin e vjetër sipas normës.

Meqenëse çdo komponent Humbje ka koeficientë, ne mund të zgjedhim vlerat optimale për detyrën tonë përmes verifikimit të kryqëzuar ose bazuar në kërkesat e produktit.

pemë

Le të kalojmë te pemët e vendimit. Ne kemi përpiluar algoritmin e mëposhtëm për trajnimin shtesë të pemëve:

Prodhimi drejton një pyll me 100-300 pemë, i cili është trajnuar mbi një grup të vjetër të dhënash.
Në fund heqim M = 5 copë dhe shtojmë 2M = 10 të reja, të trajnuara në të gjithë grupin e të dhënave, por me një peshë të madhe për të dhënat e reja, gjë që garanton natyrshëm një ndryshim në rritje në model.

Natyrisht, me kalimin e kohës, numri i pemëve rritet shumë dhe ato duhet të zvogëlohen periodikisht për të përmbushur kohën. Për ta bërë këtë, ne përdorim Distilimin e Njohurive tani të kudogjendur (KD). Shkurtimisht për parimin e funksionimit të tij.

Kemi modelin aktual “kompleks”. Ne e ekzekutojmë atë në grupin e të dhënave të trajnimit dhe marrim shpërndarjen e probabilitetit të klasës në dalje.
Më pas, ne trajnojmë modelin e studentit (modelin me më pak pemë në këtë rast) për të përsëritur rezultatet e modelit duke përdorur shpërndarjen e klasës si variablin e synuar.
Është e rëndësishme të theksohet këtu se ne nuk përdorim në asnjë mënyrë shënimin e grupit të të dhënave dhe për këtë arsye mund të përdorim të dhëna arbitrare. Natyrisht, ne përdorim një mostër të dhënash nga rryma luftarake si një mostër trajnimi për modelin e studentit. Kështu, grupi i trajnimit na lejon të sigurojmë saktësinë e modelit, dhe kampioni i rrjedhës garanton një performancë të ngjashme në shpërndarjen e prodhimit, duke kompensuar paragjykimin e grupit të trajnimit.

Kombinimi i këtyre dy teknikave (shtimi i pemëve dhe zvogëlimi periodik i numrit të tyre duke përdorur Distilimin e Njohurive) siguron futjen e modeleve të reja dhe vazhdimësinë e plotë.

Me ndihmën e KD, ne kryejmë gjithashtu operacione të ndryshme në veçoritë e modelit, si heqja e veçorive dhe puna me boshllëqet. Në rastin tonë, ne kemi një sërë veçorish të rëndësishme statistikore (nga dërguesit, hash teksti, URL, etj.) që ruhen në bazën e të dhënave, të cilat priren të dështojnë. Modeli, natyrisht, nuk është gati për një zhvillim të tillë të ngjarjeve, pasi situatat e dështimit nuk ndodhin në grupin e trajnimit. Në raste të tilla, ne kombinojmë KD dhe teknikat e shtimit: kur stërvitemi për një pjesë të të dhënave, ne heqim ose rivendosim veçoritë e nevojshme dhe marrim etiketat origjinale (daljet e modelit aktual) dhe modeli i studentit mëson të përsërisë këtë shpërndarje .

Ne vumë re se sa më serioz të ndodhë manipulimi i modelit, aq më e madhe është përqindja e kampionit të filetos që kërkohet.

Heqja e veçorive, operacioni më i thjeshtë, kërkon vetëm një pjesë të vogël të rrjedhës, pasi vetëm disa veçori ndryshojnë, dhe modeli aktual u trajnua në të njëjtin grup - ndryshimi është minimal. Për të thjeshtuar modelin (reduktimi i numrit të pemëve disa herë), tashmë kërkohet 50 deri në 50. Dhe për lëshimet e veçorive të rëndësishme statistikore që do të ndikojnë seriozisht në performancën e modelit, kërkohet edhe më shumë rrjedhje për të niveluar punën e model i ri rezistent ndaj lëshimeve në të gjitha llojet e shkronjave.

FastText

Le të kalojmë te FastText. Më lejoni t'ju kujtoj se paraqitja (Embedding) e një fjale përbëhet nga shuma e ngulitjes së vetë fjalës dhe të gjithë shkronjës së saj N-gram, zakonisht trigram. Meqenëse mund të ketë shumë trigrame, përdoret Bucket Hashing, domethënë konvertimi i të gjithë hapësirës në një hashmap të caktuar fiks. Si rezultat, matrica e peshës merret me dimensionin e shtresës së brendshme për numrin e fjalëve + kova.

Me trajnime shtesë, shfaqen shenja të reja: fjalë dhe trigrame. Asgjë e rëndësishme nuk ndodh në trajnimin standard vijues nga Facebook. Vetëm peshat e vjetra me ndër-entropi rikualifikohen në të dhëna të reja. Kështu, veçoritë e reja nuk përdoren; natyrisht, kjo qasje ka të gjitha disavantazhet e përshkruara më sipër që lidhen me paparashikueshmërinë e modelit në prodhim. Kjo është arsyeja pse ne modifikuam pak FastText. Shtojmë të gjitha peshat e reja (fjalët dhe trigramet), zgjerojmë të gjithë matricën me entropi tërthore dhe shtojmë rregullimin harmonik me analogji me modelin linear, i cili garanton një ndryshim të parëndësishëm në peshat e vjetra.

CNN

Rrjetet konvolucionale janë pak më të komplikuara. Nëse shtresat e fundit plotësohen në CNN, atëherë, sigurisht, mund të aplikoni rregullim harmonik dhe të garantoni vazhdimësi. Por nëse kërkohet trajnim shtesë i të gjithë rrjetit, atëherë një rregullim i tillë nuk mund të zbatohet më për të gjitha shtresat. Megjithatë, ekziston një mundësi për të trajnuar ngulitje plotësuese përmes Humbjes Triplet (artikull origjinal).

Humbje e trefishtë

Duke përdorur një detyrë anti-phishing si shembull, le të shohim Humbjen Triplet në terma të përgjithshëm. Ne marrim logon tonë, si dhe shembuj pozitivë dhe negativë të logove të kompanive të tjera. Ne minimizojmë distancën midis të parit dhe maksimizojmë distancën midis të dytit, këtë e bëjmë me një hendek të vogël për të siguruar kompaktësi më të madhe të klasave.

Nëse e trajnojmë më tej rrjetin, atëherë hapësira jonë metrike ndryshon plotësisht dhe bëhet plotësisht e papajtueshme me atë të mëparshme. Ky është një problem serioz në problemet që përdorin vektorë. Për të kapërcyer këtë problem, ne do të përziejmë ngulitje të vjetra gjatë stërvitjes.

Ne kemi shtuar të dhëna të reja në grupin e trajnimit dhe po trajnojmë versionin e dytë të modelit nga e para. Në fazën e dytë, ne trajnojmë më tej rrjetin tonë (Finetuning): fillimisht përfundon shtresa e fundit dhe më pas i gjithë rrjeti shkrihet. Në procesin e kompozimit të trinjakëve, ne llogarisim vetëm një pjesë të ngulitjeve duke përdorur modelin e trajnuar, pjesën tjetër - duke përdorur atë të vjetër. Kështu, në procesin e trajnimit shtesë, ne sigurojmë përputhshmërinë e hapësirave metrike v1 dhe v2. Një version unik i rregullimit harmonik.

E gjithë arkitektura

Nëse marrim si shembull të gjithë sistemin duke përdorur antispam, atëherë modelet nuk janë të izoluara, por të vendosura brenda njëri-tjetrit. Ne bëjmë fotografi, tekst dhe veçori të tjera, duke përdorur CNN dhe Fast Text marrim ngulitje. Më pas, klasifikuesit aplikohen në majë të nguliturave, të cilët ofrojnë pikë për klasa të ndryshme (llojet e shkronjave, spam, prania e një logoje). Sinjalet dhe tabelat tashmë po hyjnë në pyllin e pemëve për të marrë vendimin përfundimtar. Klasifikuesit individualë në këtë skemë bëjnë të mundur interpretimin më të mirë të rezultateve të sistemit dhe më konkretisht rikualifikimin e komponentëve në rast problemesh, në vend që të ushqehen të gjitha të dhënat në pemët e vendimit në formë të papërpunuar.

Si rezultat, ne garantojmë vazhdimësi në çdo nivel. Në nivelin e poshtëm në CNN dhe Fast Text ne përdorim rregullimin harmonik, për klasifikuesit në mes ne përdorim gjithashtu rregullimin harmonik dhe kalibrimin e normës për konsistencën e shpërndarjes së probabilitetit. Epo, rritja e pemëve trajnohet gradualisht ose duke përdorur distilimin e njohurive.

Në përgjithësi, mbajtja e një sistemi të tillë të mbivendosur të mësimit të makinerive është zakonisht një dhimbje, pasi çdo komponent në nivelin më të ulët çon në një përditësim të të gjithë sistemit të mësipërm. Por meqenëse në konfigurimin tonë çdo komponent ndryshon pak dhe është i pajtueshëm me atë të mëparshëm, i gjithë sistemi mund të përditësohet pjesë-pjesë pa pasur nevojë të rikualifikohet e gjithë struktura, gjë që e lejon atë të mbështetet pa shpenzime serioze.

Vendosni

Ne kemi diskutuar mbledhjen e të dhënave dhe trajnimin shtesë të llojeve të ndryshme të modeleve, kështu që po kalojmë në vendosjen e tyre në mjedisin e prodhimit.

Testimi A/B

Siç thashë më herët, në procesin e mbledhjes së të dhënave, zakonisht marrim një mostër të njëanshme, nga e cila është e pamundur të vlerësohet performanca e prodhimit të modelit. Prandaj, kur vendoset, modeli duhet të krahasohet me versionin e mëparshëm për të kuptuar se si po shkojnë gjërat në të vërtetë, domethënë të kryeni teste A/B. Në fakt, procesi i nxjerrjes dhe analizimit të grafikëve është mjaft rutinë dhe mund të automatizohet lehtësisht. Ne i shpërndajmë modelet tona gradualisht në 5%, 30%, 50% dhe 100% të përdoruesve, ndërsa mbledhim të gjitha metrikat e disponueshme për përgjigjet e modelit dhe komentet e përdoruesve. Në rastin e disa të dhënave serioze, ne e kthejmë automatikisht modelin, dhe për raste të tjera, pasi kemi mbledhur një numër të mjaftueshëm klikimesh të përdoruesit, vendosim të rrisim përqindjen. Si rezultat, ne e sjellim modelin e ri te 50% e përdoruesve plotësisht automatikisht dhe shpërndarja për të gjithë audiencën do të miratohet nga një person, megjithëse ky hap mund të automatizohet.

Megjithatë, procesi i testimit A/B ofron hapësirë për optimizim. Fakti është se çdo test A/B është mjaft i gjatë (në rastin tonë zgjat nga 6 deri në 24 orë në varësi të sasisë së reagimeve), gjë që e bën atë mjaft të shtrenjtë dhe me burime të kufizuara. Përveç kësaj, kërkohet një përqindje mjaft e lartë e rrjedhës për testin për të shpejtuar në thelb kohën e përgjithshme të testit A/B (rekrutimi i një kampioni statistikisht të rëndësishëm për të vlerësuar metrikat në një përqindje të vogël mund të marrë një kohë shumë të gjatë), gjë që bën numri i lojërave elektronike A/B është jashtëzakonisht i kufizuar. Natyrisht, ne duhet të testojmë vetëm modelet më premtuese, nga të cilat marrim mjaft gjatë procesit të trajnimit shtesë.

Për të zgjidhur këtë problem, ne trajnuam një klasifikues të veçantë që parashikon suksesin e një testi A/B. Për ta bërë këtë, ne marrim statistikat e vendimmarrjes, saktësinë, rikujtimin dhe metrika të tjera në grupin e trajnimit, në atë të shtyrë dhe në kampionin nga transmetimi si veçori. Gjithashtu krahasojmë modelin me atë aktual në prodhim, me heuristikë dhe marrim parasysh Kompleksitetin e modelit. Duke përdorur të gjitha këto veçori, një klasifikues i trajnuar për historikun e testeve vlerëson modelet e kandidatëve, në rastin tonë këto janë pyje me pemë dhe vendos se cilin të përdorë në testin A/B.

Në kohën e zbatimit, kjo qasje na lejoi të rrisim disa herë numrin e testeve të suksesshme A/B.

Testimi & Monitorimi

Testimi dhe monitorimi, çuditërisht, nuk e dëmtojnë shëndetin tonë, përkundrazi, e përmirësojnë atë dhe na çlirojnë nga stresi i panevojshëm. Testimi ju lejon të parandaloni një dështim, dhe monitorimi ju lejon ta zbuloni atë në kohë për të zvogëluar ndikimin tek përdoruesit.

Është e rëndësishme të kuptohet këtu se herët a vonë sistemi juaj gjithmonë do të bëjë gabime - kjo është për shkak të ciklit të zhvillimit të çdo softueri. Në fillim të zhvillimit të sistemit ka gjithmonë shumë gabime derisa gjithçka të qetësohet dhe të përfundojë faza kryesore e inovacionit. Por me kalimin e kohës, entropia bën të ardhurat e saj, dhe gabimet shfaqen përsëri - për shkak të degradimit të komponentëve përreth dhe ndryshimeve në të dhëna, për të cilat fola në fillim.

Këtu dua të vërej se çdo sistem i mësimit të makinerive duhet të konsiderohet nga pikëpamja e fitimit të tij gjatë gjithë ciklit të tij jetësor. Grafiku më poshtë tregon një shembull se si funksionon sistemi për të kapur një lloj të rrallë të spam-it (vija në grafik është afër zeros). Një ditë, për shkak të një atributi të ruajtur gabimisht, ajo u çmend. Me fat, nuk kishte monitorim për shkaktimin jonormal; si rezultat, sistemi filloi të ruante letra në sasi të mëdha në dosjen "spam" në kufirin e vendimmarrjes. Pavarësisht korrigjimit të pasojave, sistemi tashmë ka bërë gabime aq shumë sa nuk do ta paguajë veten as në pesë vjet. Dhe ky është një dështim i plotë nga pikëpamja e ciklit jetësor të modelit.

Prandaj, një gjë kaq e thjeshtë si monitorimi mund të bëhet kyç në jetën e një modeli. Përveç matjeve standarde dhe të dukshme, ne konsiderojmë shpërndarjen e përgjigjeve dhe rezultateve të modelit, si dhe shpërndarjen e vlerave kryesore të veçorive. Duke përdorur divergjencën KL, ne mund të krahasojmë shpërndarjen aktuale me atë historike ose vlerat në testin A/B me pjesën tjetër të rrymës, gjë që na lejon të vërejmë anomali në model dhe të kthejmë ndryshimet në kohën e duhur.

Në shumicën e rasteve, ne lëshojmë versionet tona të para të sistemeve duke përdorur heuristika të thjeshta ose modele që i përdorim si monitorim në të ardhmen. Për shembull, ne monitorojmë modelin NER në krahasim me ato të rregullta për dyqane specifike në internet, dhe nëse mbulimi i klasifikuesit bie në krahasim me ta, atëherë kuptojmë arsyet. Një tjetër përdorim i dobishëm i heuristikës!

Rezultatet e

Le të shqyrtojmë përsëri idetë kryesore të artikullit.

Fibdeck. Ne gjithmonë mendojmë për përdoruesin: si do të jetojë me gabimet tona, si do të jetë në gjendje t'i raportojë ato. Mos harroni se përdoruesit nuk janë një burim i pastër reagimi për modelet e trajnimit dhe duhet të pastrohet me ndihmën e sistemeve ndihmëse ML. Nëse nuk është e mundur të mbledhim një sinjal nga përdoruesi, atëherë ne kërkojmë burime alternative të reagimit, për shembull, sistemet e lidhura.
Trajnim shtesë. Gjëja kryesore këtu është vazhdimësia, kështu që ne mbështetemi në modelin aktual të prodhimit. Ne trajnojmë modele të reja që të mos ndryshojnë shumë nga ai i mëparshmi për shkak të rregullimit harmonik dhe trukeve të ngjashme.
Vendosni. Vendosja automatike e bazuar në metrikë redukton shumë kohën për zbatimin e modeleve. Monitorimi i statistikave dhe shpërndarjes së vendimmarrjes, numri i rënieve nga përdoruesit është i detyrueshëm për gjumin tuaj të qetë dhe fundjavën produktive.

Epo, shpresoj që kjo t'ju ndihmojë të përmirësoni më shpejt sistemet tuaja ML, t'i nxirrni ato në treg më shpejt dhe t'i bëni ato më të besueshme dhe më pak stresuese.

Burimi: www.habr.com

Funksionimi i mësimit të makinerive në Mail.ru Mail