{"id":53143,"date":"2019-11-24T00:00:00","date_gmt":"2019-11-23T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/ekspluatatsiya-mashinnogo-obucheniya-v-pochte-mail-ru"},"modified":"2020-02-18T14:01:00","modified_gmt":"2020-02-18T11:01:00","slug":"ekspluatatsiya-mashinnogo-obucheniya-v-pochte-mail-ru","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ekspluatatsiya-mashinnogo-obucheniya-v-pochte-mail-ru","title":{"rendered":"Udnyttelse af maskinl\u00e6ring i Mail.ru","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Udnyttelse af maskinl\u00e6ring i Mail.ru\" src=\"\/wp-content\/uploads\/2019\/11\/ee5728dccb94b849ad3bfd9cf84ad74d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>Baseret p\u00e5 mine pr\u00e6sentationer ved Highload++ og DataFest Minsk 2019.<\/i><\/p>\n<p>For mange er e-mail i dag en uundg\u00e5elig del af livet online. Vi bruger den til gesch\u00e4ftskommunikation, opbevarer forskellige vigtige informationer relateret til \u00f8konomi, hotelreservationer, ordrebehandling og meget mere. I midten af 2018 formulerede vi en produktstrategi for udviklingen af e-mail. Hvordan skal moderne e-mail v\u00e6re?<\/p>\n<p>E-mail skal v\u00e6re <b>smart<\/b>, det vil sige hj\u00e6lpe brugerne med at navigere i den stigende m\u00e6ngde information: filtrere, strukturere og pr\u00e6sentere den p\u00e5 den mest bekvemme m\u00e5de. Den skal v\u00e6re <b>nyttig<\/b>, hvilket g\u00f8r det muligt direkte fra indbakken at l\u00f8se forskellige opgaver, for eksempel betale b\u00f8der (en funktion, som jeg desv\u00e6rre m\u00e5tte bruge). Og selvf\u00f8lgelig skal e-mail sikre informationsbeskyttelse ved at blokere spam og beskytte mod hacking, det vil sige v\u00e6re <b>sikre<\/b>.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nDisse retninger definerer en r\u00e6kke centrale opgaver, hvoraf mange effektivt kan l\u00f8ses ved hj\u00e6lp af maskinl\u00e6ring. Her er eksempler p\u00e5 allerede fungerende funktioner, udviklet inden for strategien \u2014 \u00e9n for hver retning.<\/p>\n<ul>\n<li><b>Smart Reply<\/b>. E-mailen har en smart svar-funktion. Neuralnetv\u00e6rket analyserer teksten i e-mailen, forst\u00e5r dens mening og form\u00e5l, og tilbyder derefter tre mest passende svarmuligheder: positiv, negativ og neutral. Dette hj\u00e6lper betydeligt med at spare tid, n\u00e5r man svarer p\u00e5 e-mails, og ofte besvarer man ogs\u00e5 p\u00e5 en uventet og sjov m\u00e5de.\n<\/li>\n<li><b>Gruppering af e-mails<\/b>, der vedr\u00f8rer ordrer i webshops. Vi handler ofte online, og typisk kan butikker sende flere e-mails pr. ordre. For eksempel fra AliExpress, hvor den st\u00f8rste tjeneste sender mange e-mails vedr\u00f8rende \u00e9n ordre, og vi har beregnet, at i krisesituationer kan antallet n\u00e5 op til 29. Derfor bruger vi modellen Named Entity Recognition til at udtr\u00e6kke ordrenummer og anden information fra teksten og gruppere alle e-mails i en tr\u00e5d. Vi viser ogs\u00e5 hovedoplysningerne om ordren i et separat felt, hvilket letter arbejdet med denne type e-mails.\n<p><img decoding=\"async\" alt=\"Udnyttelse af maskinl\u00e6ring i Mail.ru\" src=\"\/wp-content\/uploads\/2019\/11\/8b37b0bf0c0d152498027bc25d476128.jpg\" style=\"display:block;margin: 0 auto;\" \/>\n<\/li>\n<li><b>Antiphishing<\/b>Phishing er en farlig type bedragerisk e-mail, hvor kriminelle fors\u00f8ger at f\u00e5 fat i finansielle oplysninger (herunder brugernes kreditkortoplysninger) og loginoplysninger. Disse e-mails efterligner \u00e6gte e-mails sendt af tjenester, ogs\u00e5 visuelt. Derfor bruger vi Computer Vision til at genkende logoer og designstile fra store virksomheder (f.eks. Mail.ru, Sber, Alfa) og tager dette i betragtning sammen med tekst og andre indikatorer i vores spam- og phishingklassifikatorer.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>Maskinl\u00e6ring<\/h2>\n<p>\nLidt om maskinl\u00e6ring i e-mail generelt. E-mail er et h\u00f8jbelastet system: Gennem vores servere passerer der i gennemsnit 1,5 milliarder e-mails dagligt for 30 millioner daglige brugere. Ca. 30 maskinl\u00e6ringssystemer h\u00e5ndterer alle n\u00f8dvendige funktioner og features. <\/p>\n<p>Hver e-mail g\u00e5r gennem en hel klassifikationsk\u00e6de. F\u00f8rst filtrerer vi spam fra og lader gode e-mails komme igennem. Brugerne bem\u00e6rker ofte ikke arbejdet med at bek\u00e6mpe spam, da 95-99 % af spam ikke selv n\u00e5r ind i den relevante mappe. Spamgenkendelse er en meget vigtig del af vores system og den mest komplekse, da der inden for spambeskyttelse konstant er en tilpasning mellem beskyttelsessystemer og angreb, hvilket giver en kontinuerlig ingeni\u00f8rudfordring for vores team.<\/p>\n<p>Dern\u00e6st adskiller vi e-mails fra mennesker og robotter. E-mails fra mennesker er de mest vigtige, s\u00e5 for dem tilbyder vi funktioner som Smart Reply. E-mails fra robotter opdeles i to kategorier: transaktionelle \u2013 dette er vigtige e-mails fra tjenester, s\u00e5som bekr\u00e6ftelser af k\u00f8b eller hotelreservationer, finansielle oplysninger, og informationsm\u00e6ssige \u2013 dette er forretningsreklamer og rabatter. <\/p>\n<p>Vi mener, at transaktionelle e-mails er lige s\u00e5 vigtige som personlig korrespondance. De skal v\u00e6re lige ved h\u00e5nden, da man ofte hurtigt har brug for at finde information om en ordre eller en flyreservation, og vi bruger tid p\u00e5 at lede efter disse e-mails. Derfor deler vi dem for nemheds skyld automatisk op i seks hovedkategorier: rejser, ordrer, finanser, billetter, registreringer og endelig b\u00f8der.<\/p>\n<p>Informationsbreve er den mest talrige og nok ogs\u00e5 den mindst vigtige gruppe, som ikke kr\u00e6ver \u00f8jeblikkelig reaktion, da ingenting v\u00e6sentligt \u00e6ndrer sig i brugerens liv, hvis han ikke l\u00e6ser en s\u00e5dan e-mail. I vores nye interface samler vi dem i to tr\u00e5de: sociale medier og nyhedsbreve, og derved ryder vi visuelt op i indbakken og lader kun vigtige e-mails v\u00e6re synlige.<\/p>\n<p><img decoding=\"async\" alt=\"Udnyttelse af maskinl\u00e6ring i Mail.ru\" src=\"\/wp-content\/uploads\/2019\/11\/175773879daaa29d1542a98070cb7972.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Drift<\/h3>\n<p>\nEt stort antal systemer medf\u00f8rer mange udfordringer i driften. For modeller degraderes over tid, ligesom enhver software: tydelige tegn mislykkes, maskiner svigter, og der bygger sig en d\u00e5rlig kode op. Desuden \u00e6ndres data konstant: nye tilf\u00f8jes, brugeradf\u00e6rdens m\u00f8nstre transforms, osv., hvorfor en model uden tilstr\u00e6kkelig support vil fungere d\u00e5rligere og d\u00e5rligere over tid. <\/p>\n<p>Man skal ogs\u00e5 huske, at jo dybere maskinl\u00e6ring tr\u00e6nger ind i brugernes liv, jo st\u00f8rre indflydelse har de p\u00e5 \u00f8kosystemet, og som f\u00f8lge heraf, jo st\u00f8rre \u00f8konomiske tab eller gevinster kan akt\u00f8rerne p\u00e5 markedet opn\u00e5. Derfor tilpasser flere og flere akt\u00f8rer sig til at arbejde med ML-algoritmer (klassiske eksempler er reklame, s\u00f8gning og det allerede n\u00e6vnte spamfilter).<\/p>\n<p>Desuden har opgaver inden for maskinl\u00e6ring den egenskab, at enhver, selv en lille, \u00e6ndring i systemet kan f\u00f8re til meget arbejde med modellen: databehandling, genuddannelse, deployment, hvilket kan tage uger eller m\u00e5neder. S\u00e5 jo hurtigere milj\u00f8et, hvor dine modeller opererer, \u00e6ndrer sig, jo mere kr\u00e6ver det afs\u00e6tningsarbejde at supportere dem. Et team kan bygge mange systemer og gl\u00e6de sig over dette, men s\u00e5 bruge n\u00e6sten alle ressourcer p\u00e5 deres vedligeholdelse, uden mulighed for at lave noget nyt. I et s\u00e5dant scenario st\u00f8ttede vi tidligere en gang i anti-spam teamet. Og vi n\u00e5ede den \u00e5benlyse konklusion, at vedligeholdelse skal automatiseres.<\/p>\n<h3>Automatisering<\/h3>\n<p>\nHvad kan automatiseres? Faktisk n\u00e6sten alt. Jeg har identificeret fire omr\u00e5der, der definerer infrastrukturen for maskinl\u00e6ring:<\/p>\n<ul>\n<li>dataindsamling;\n<\/li>\n<li>forfining;\n<\/li>\n<li>deployment;\n<\/li>\n<li>test &amp; overv\u00e5gning.\n<\/li>\n<\/ul>\n<p>\nHvis milj\u00f8et er ustabilt og konstant \u00e6ndrer sig, s\u00e5 er hele infrastrukturen omkring modellen langt vigtigere end selve modellen. Det kan v\u00e6re en god gammeldags line\u00e6r klassifikator, men hvis man korrekt pr\u00e6senterer funktionerne for den og etablerer en god feedback fra brugerne, vil den fungere meget bedre end de nyeste state-of-the-art-modeller med alle mulige funktioner.<\/p>\n<h4>Feedbackcyklus<\/h4>\n<p>\nDenne cyklus omfatter indsamling af data, finjustering og implementering \u2014 i bund og grund hele opdateringscyklussen for modellen. Hvorfor er det vigtigt? Se p\u00e5 grafen for registreringen i e-mailen:<\/p>\n<p><img decoding=\"async\" alt=\"Udnyttelse af maskinl\u00e6ring i Mail.ru\" src=\"\/wp-content\/uploads\/2019\/11\/f3c98bd49a101754cf299821a40e2b8e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUdvikleren af maskinl\u00e6ring implementerede en anti-bot model, der forhindrer bots i at registrere sig i e-mailen. Grafen falder til et niveau, hvor der kun er rigtige brugere tilbage. Alt ser fantastisk ud! Men efter fire timer tilpasser bot-skribenterne deres scripts, og alt vender tilbage til status quo. I denne implementering brugte udvikleren en m\u00e5ned p\u00e5 at tilf\u00f8je funktioner og finjustere modellen, men spammerne kunne tilpasse sig p\u00e5 bare fire timer.<\/p>\n<p>For at det ikke skal blive s\u00e5 pinefuldt og man ikke ender med at skulle g\u00f8re alt om, skal man i starten t\u00e6nke p\u00e5, hvordan feedbackcyklussen vil se ud, og hvad vi vil g\u00f8re, hvis milj\u00f8et \u00e6ndrer sig. Lad os starte med at indsamle data \u2014 det er br\u00e6ndstoffet til vores algoritmer.<\/p>\n<h2>Dataindsamling<\/h2>\n<p>\nDet er klart, at moderne neurale netv\u00e6rk fungerer bedre jo flere data de har, og disse data genereres reelt af produktets brugere. Brugere kan hj\u00e6lpe os ved at annotere data, men vi m\u00e5 ikke misbruge dette, fordi brugerne p\u00e5 et tidspunkt vil blive tr\u00e6tte af at finjustere jeres modeller og vil skifte til et andet produkt. <\/p>\n<p>En af de mest almindelige fejl (her henviser jeg til Andrew Ng) er at have en for st\u00e6rk fokus p\u00e5 metrikker p\u00e5 testdatas\u00e6ttet, snarere end feedback fra brugeren, hvilket faktisk er det vigtigste m\u00e5l for kvalitet, da vi skaber produkter til brugerne. Hvis brugeren ikke kan forst\u00e5 eller ikke bryder sig om, hvordan modellen fungerer, s\u00e5 er alt forg\u00e6ves. <\/p>\n<p>Derfor skal brugeren altid have mulighed for at stemme, og vi skal give dem et v\u00e6rkt\u00f8j til feedback. Hvis vi mener, at der er kommet en e-mail, der vedr\u00f8rer \u00f8konomi, skal vi m\u00e6rke den som '\u00f8konomi' og tegne en knap, som brugeren kan trykke p\u00e5 og sige, at det ikke er \u00f8konomi.<\/p>\n<h3>Kvaliteten af feedback<\/h3>\n<p>\nLad os tale om kvaliteten af brugerfeedback. For det f\u00f8rste kan du og brugeren l\u00e6gge forskellig betydning i det samme begreb. For eksempel mener du og produktcheferne, at \"finanser\" er bankbreve, mens brugeren mener, at et brev fra sin bedstefor\u00e6lder om pension ogs\u00e5 h\u00f8rer til under finans. For det andet er der brugere, der tankel\u00f8st elsker at trykke p\u00e5 knapper uden nogen logik. For det tredje kan brugeren v\u00e6re dybt fejlinformeret i sine konklusioner. Et klart eksempel fra vores praksis er implementeringen af klassifikatoren <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/%D0%9D%D0%B8%D0%B3%D0%B5%D1%80%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B5_%D0%BF%D0%B8%D1%81%D1%8C%D0%BC%D0%B0\">nigeriansk spam<\/a><\/noindex>, en temmelig underholdende type spam, hvor brugeren bliver tilbudt at hente flere millioner dollars fra en pludselig funden fjern sl\u00e6gtning i Afrika. Efter implementeringen af denne klassifikator kontrollerede vi klik p\u00e5 \"Ikke spam\" p\u00e5 disse breve, og det viste sig, at 80 % af dem var saftig nigeriansk spam, hvilket tyder p\u00e5, at brugerne kan v\u00e6re ekstremt naiv.<\/p>\n<p>Og lad os ikke glemme, at der ikke kun kan trykkes p\u00e5 knapper af mennesker, men ogs\u00e5 af forskellige bots, der udgiver sig for at v\u00e6re browsere. S\u00e5 r\u00e5 feedback er ikke egnet til tr\u00e6ning. Hvad kan der g\u00f8res med denne information?<\/p>\n<p>Vi anvender to tilgange: <\/p>\n<ul>\n<li><b>Feedback fra relateret ML<\/b>. For eksempel har vi et online anti-bot-system, som, som jeg allerede har n\u00e6vnt, tr\u00e6ffer hurtige beslutninger baseret p\u00e5 et begr\u00e6nset antal funktioner. Og der er et andet, langsommere system, der arbejder post factum. Det har flere data om brugeren, om hans adf\u00e6rd osv. Som f\u00f8lge deraf tr\u00e6ffes den mest afbalancerede beslutning, hvilket giver det h\u00f8jere n\u00f8jagtighed og fuldst\u00e6ndighed. Forskellen i arbejdet mellem disse systemer kan sendes til det f\u00f8rste som tr\u00e6ningsdata. P\u00e5 denne m\u00e5de vil det enklere system altid fors\u00f8ge at n\u00e6rme sig ydelsen af det mere komplekse.\n<\/li>\n<li><b>Klikklassifikation<\/b>. Man kan blot klassificere hvert klik fra brugeren, vurdere dets gyldighed og brugsmuligheder. Det g\u00f8r vi i antispam for e-mails ved at bruge brugerens tegn, hans historik, afsenderens karakteristika, selve teksten og resultatet fra klassificatorerne. I sidste ende f\u00e5r vi et automatisk system, der validerer brugerens feedback. Og da det skal tr\u00e6nes betydeligt sj\u00e6ldnere, kan dets arbejde blive grundlaget for alle andre systemer. Hovedprioriteten i denne model er pr\u00e6cision, fordi det at tr\u00e6ne modellen p\u00e5 un\u00f8jagtige data kan f\u00e5 alvorlige konsekvenser. \n<\/li>\n<\/ul>\n<p>\nMens vi renser dataene og tr\u00e6ner vores ML-systemer, m\u00e5 vi ikke glemme brugerne, for for os er tusindvis, millioner af fejl p\u00e5 grafen statistik, mens hver fejl for brugeren er en tragedie. Udover at brugeren skal leve med din fejl i produktet, forventer de, efter at have givet feedback, at lignende situationer ikke vil gentage sig i fremtiden. Derfor er det vigtigt altid at give brugerne mulighed for ikke kun at stemme, men ogs\u00e5 at korrigere ML-systemernes adf\u00e6rd ved at skabe for eksempel personlige heuristikker for hvert klik p\u00e5 feedbacken; i tilf\u00e6lde af e-mail kan det v\u00e6re muligheden for at filtrere s\u00e5danne e-mails efter afsender og emne for den p\u00e5g\u00e6ldende bruger.<\/p>\n<p>Der skal ogs\u00e5 p\u00e5 basis af nogen rapporter eller henvendelser til supporten i et semi-automatisk eller manuelt regime knokles med modellen, s\u00e5 andre brugere ikke lider under lignende problemer.<\/p>\n<h3>Heuristikker til tr\u00e6ning<\/h3>\n<p>\nDer er to problemer med disse heuristikker og kn\u00e6k. For det f\u00f8rste er det sv\u00e6rt at vedligeholde det konstant voksende antal kn\u00e6k, for ikke at tale om deres kvalitet og effektivitet p\u00e5 lang sigt. Det andet problem er, at fejlen ikke n\u00f8dvendigvis er hyppig, og at f\u00e5 klik til at tr\u00e6ne modellen ikke vil v\u00e6re tilstr\u00e6kkeligt. Det virker som om, at disse to uafh\u00e6ngige effekter kan reduceres betydeligt, hvis vi anvender den f\u00f8lgende tilgang.<\/p>\n<ol>\n<li>Oprettelse af et midlertidigt kn\u00e6k. \n<\/li>\n<li>Vi sender data fra det til modellen, som regelm\u00e6ssigt bliver tr\u00e6net, ogs\u00e5 p\u00e5 de indsamlede data. Her er det selvf\u00f8lgelig vigtigt, at heuristikken har h\u00f8j n\u00f8jagtighed, for ikke at reducere datakvaliteten i tr\u00e6ningss\u00e6ttet. \n<\/li>\n<li>Derefter s\u00e6tter vi overv\u00e5gning op for aktivering af workaround'en, og hvis workaround'en ikke l\u00e6ngere aktiveres over tid og helt erstattes af modellen, kan den trygt fjernes. Nu er det usandsynligt, at dette problem vil gentage sig.\n<\/li>\n<\/ol>\n<p>\nS\u00e5 derfor er en h\u00e6r af workarounds meget nyttig. Det vigtigste er, at deres tjeneste er midlertidig og ikke vedvarende. <\/p>\n<h2>Finjustering<\/h2>\n<p>\nFinjustering er processen med at tilf\u00f8je nye data, der er indsamlet som f\u00f8lge af feedback fra brugere eller andre systemer, og tr\u00e6ne den eksisterende model p\u00e5 disse. Der kan v\u00e6re flere problemer med finjustering:<\/p>\n<ol>\n<li>Modellen kan simpelthen ikke underst\u00f8tte finjustering og kun l\u00e6re fra bunden. \n<\/li>\n<li>Der st\u00e5r intet i naturens bog, der siger, at finjustering n\u00f8dvendigvis vil forbedre kvaliteten i produktionen. Det sker ofte det modsatte, dvs. at der kun er risiko for forringelse.\n<\/li>\n<li>\u00c6ndringer kan v\u00e6re uforudsigelige. Dette er en ganske delikat sag, som vi har identificeret. Selv hvis den nye model i A\/B-testen viser lignende resultater i forhold til den nuv\u00e6rende, betyder det slet ikke, at den vil fungere identisk. Deres pr\u00e6station kan variere med et enkelt procentpoint, hvilket kan medf\u00f8re nye fejl eller genindf\u00f8re allerede rettede gamle fejl. Med de nuv\u00e6rende fejl har b\u00e5de vi og brugerne allerede l\u00e6rt at leve, og n\u00e5r der opst\u00e5r mange nye fejl, kan brugeren heller ikke forst\u00e5, hvad der sker, for han forventer en forudsigelig adf\u00e6rd.\n<\/li>\n<\/ol>\n<p>\nDerfor er det vigtigste ved finjustering at sikre, at man forbedrer modellen eller i det mindste ikke forringer den. <\/p>\n<p>Det f\u00f8rste, der falder mig ind, n\u00e5r vi taler om finjustering, er Active Learning-tilgangen. Hvad betyder det? For eksempel bestemmer en klassificerer, om en e-mail tilh\u00f8rer \u00f8konomi, og omkring dens beslutningsgr\u00e6nse tilf\u00f8jer vi et udvalg af m\u00e6rkede eksempler. Dette fungerer godt, for eksempel i reklame, hvor der er meget feedback, og man kan tr\u00e6ne modellen i realtid. Men hvis der er lidt feedback, f\u00e5r vi et st\u00e6rkt sk\u00e6vvredet udvalg i forhold til produktionsdatafordelingen, som ikke kan bruges til at evaluere modellens adf\u00e6rd i driftsprocessen.<\/p>\n<p><img decoding=\"async\" alt=\"Udnyttelse af maskinl\u00e6ring i Mail.ru\" src=\"\/wp-content\/uploads\/2019\/11\/fd1b3e07bfaf896dde3248e43537f61a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVores m\u00e5l er faktisk at bevare de gamle m\u00f8nstre, de allerede kendte modeller, og at erhverve nye. Her er kontinuitet vigtig. Den model, vi ofte har pr\u00e6senteret med stort besv\u00e6r, er allerede i brug, s\u00e5 vi kan basere os p\u00e5 dens ydeevne. <\/p>\n<p>I brevmail anvendes forskellige modeller: tr\u00e6er, line\u00e6re, neurale netv\u00e6rk. For hver af dem laver vi vores egen finjusteringsalgoritme. I finjusteringsprocessen f\u00e5r vi ikke kun nye data, men ogs\u00e5 ofte nye karakteristika, som vi vil tage hensyn til i alle algoritmerne nedenfor.<\/p>\n<h3>Line\u00e6re modeller<\/h3>\n<p>\nLad os sige, vi har logistisk regression. Vi sammens\u00e6tter tabet for modellen af f\u00f8lgende komponenter:<\/p>\n<ul>\n<li>LogLoss p\u00e5 nye data;\n<\/li>\n<li>regulerer v\u00e6gtene for de nye karakteristika (de gamle ber\u00f8res ikke);\n<\/li>\n<li>l\u00e6rer ogs\u00e5 med de gamle data for at bevare de gamle m\u00f8nstre;\n<\/li>\n<li>og m\u00e5ske det vigtigste: vi p\u00e5f\u00f8rer Harmonic Regularization, som sikrer, at v\u00e6gtene ikke \u00e6ndres meget i forhold til den gamle model med hensyn til normen.\n<\/li>\n<\/ul>\n<p>\nDa hver komponent af tab har koefficienter, kan vi finde de optimale v\u00e6rdier for vores opgave gennem krydsvalidering eller baseret p\u00e5 produktkrav.<\/p>\n<p><img decoding=\"async\" alt=\"Udnyttelse af maskinl\u00e6ring i Mail.ru\" src=\"\/wp-content\/uploads\/2019\/11\/00ae86d23afb780f5e260e61f833d4bd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Tr\u00e6er<\/h3>\n<p>\nLad os g\u00e5 videre til beslutningstr\u00e6er. Vi har udviklet f\u00f8lgende algoritme til finjustering af tr\u00e6erne:<\/p>\n<ol>\n<li>Vi har en skov med 100-300 tr\u00e6er, som er tr\u00e6net p\u00e5 det gamle datas\u00e6t.\n<\/li>\n<li>Vi fjerner 5 i slutningen og tilf\u00f8jer 10 nye, tr\u00e6net p\u00e5 hele datas\u00e6ttet, men med h\u00f8j v\u00e6gt p\u00e5 nye data, hvilket naturligt sikrer en inkrementel \u00e6ndring af modellen.\n<\/li>\n<\/ol>\n<p>\nDet er tydeligt, at antallet af tr\u00e6er over tid stiger kraftigt, og de skal regelm\u00e6ssigt reduceres for at overholde tidsrammerne. Til dette bruger vi den i dag almindelige Knowledge Distillation (KD). Kort om princippet bag.<\/p>\n<ol>\n<li>Vi har den nuv\u00e6rende \u2019kompleks\u2019 model. Vi k\u00f8rer den p\u00e5 tr\u00e6ningsdatas\u00e6ttet og f\u00e5r sandsynlighedsfordelingen for klasserne som output.\n<\/li>\n<li>Herefter l\u00e6rer vi eleven modellen (modellen med f\u00e6rre tr\u00e6er i dette tilf\u00e6lde) at gentage resultaterne fra modellen ved at bruge klassesandsynlighedsfordelingen som den m\u00e5lrettede variabel.\n<\/li>\n<li>Det er vigtigt at bem\u00e6rke, at vi ikke bruger nogen form for datas\u00e6tmarkup, og derfor kan vi anvende vilk\u00e5rlige data. Selvf\u00f8lgelig bruger vi en sample data fra produktionsstr\u00f8mmen som tr\u00e6ningss\u00e6t til elevmodellen. P\u00e5 den m\u00e5de giver tr\u00e6ningss\u00e6ttet os mulighed for at sikre modellens n\u00f8jagtighed, mens samplestr\u00f8mmen garanterer lignende ydeevne ved produktionsfordelingen, hvilket kompenserer for sk\u00e6vheden i tr\u00e6ningss\u00e6ttet.\n<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Udnyttelse af maskinl\u00e6ring i Mail.ru\" src=\"\/wp-content\/uploads\/2019\/11\/3fdfcb9b1e5a6fa824226a429afc475a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKombinationen af disse to metoder (tilf\u00f8jelse af tr\u00e6er og periodisk reduktion af deres antal ved hj\u00e6lp af Knowledge Distillation) sikrer introduktionen af nye m\u00f8nstre og fuld kontinuitet.<\/p>\n<p>Med KD udf\u00f8rer vi ogs\u00e5 operationer med modellens tr\u00e6k, som f.eks. fjernelse af tr\u00e6k og arbejde med mangler. I vores tilf\u00e6lde har vi en r\u00e6kke vigtige statistiske tr\u00e6k (vedr\u00f8rende afsendere, teksthashes, URL'er osv.), som er gemt i en database med tilb\u00f8jelighed til at fejle. Modellen er selvf\u00f8lgelig ikke klar til en s\u00e5dan udvikling, da der ikke findes situationer med fejl i tr\u00e6ningss\u00e6ttet. I s\u00e5danne tilf\u00e6lde kombinerer vi KD-teknikker med augmentation: ved tr\u00e6ning af en del af dataene fjerner eller nulstiller vi n\u00f8dvendige tr\u00e6k, mens etiketterne (udgangen fra den nuv\u00e6rende model) tages som originale, og elevmodellen l\u00e6rer at gentage denne fordeling.<\/p>\n<p><img decoding=\"async\" alt=\"Udnyttelse af maskinl\u00e6ring i Mail.ru\" src=\"\/wp-content\/uploads\/2019\/11\/5e1f5af9a359646a49f4fe88ffed1025.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVi har bem\u00e6rket, at jo mere alvorlig manipulation med modellerne der udf\u00f8res, jo mere samplestr\u00f8m kr\u00e6ves i procent.<\/p>\n<p>For at fjerne tr\u00e6k, som er den letteste operation, kr\u00e6ves kun en lille del af str\u00f8mmen, da der kun \u00e6ndres et par tr\u00e6k, og den nuv\u00e6rende model er blevet tr\u00e6net p\u00e5 det samme s\u00e6t \u2014 forskellen er minimal. For at forenkle modellen (reducere antallet af tr\u00e6er flere gange) kr\u00e6ves der allerede 50 til 50. Og for at h\u00e5ndtere mangler af vigtige statistiske tr\u00e6k, som alvorligt p\u00e5virker modellens ydeevne, kr\u00e6ves der endnu mere str\u00f8m for at nivellere den nye model, der er robust over for mangler, p\u00e5 alle typer af mails. <\/p>\n<p><img decoding=\"async\" alt=\"Udnyttelse af maskinl\u00e6ring i Mail.ru\" src=\"\/wp-content\/uploads\/2019\/11\/8f3729cfff43be9ecdc47d532daa8d6f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>FastText<\/h3>\n<p>\nLad os g\u00e5 videre til FastText. Jeg minder om, at repr\u00e6sentationen (Embedding) af et ord best\u00e5r af summen af embedding'en af selve ordet og alle dets bogstav N-grammer, typisk trigrammer. Da der kan v\u00e6re mange trigrammer, anvendes Bucket Hashing, hvilket vil sige, at hele rummet omdannes til en bestemt fast hash-map. Resultatet er, at v\u00e6gtmatricen f\u00e5r dimensioner svarende til det interne lag gange antallet af ord + buckets. <\/p>\n<p>Under finjustering opst\u00e5r der nye funktioner: ord og trigrammer. I den standard finjustering, der anvendes af Facebook, sker der ikke noget v\u00e6sentligt. Kun de gamle v\u00e6gte bliver finjusteret med kryds-entropi p\u00e5 de nye data. Hermed bruges nye funktioner ikke, og naturligvis har denne tilgang alle de ovenn\u00e6vnte ulemper, der er forbundet med modellens uforudsigelighed i produktionen. Derfor har vi lidt videreudviklet FastText. Vi tilf\u00f8jer alle nye v\u00e6gte (ord og trigrammer), finjusterer hele matricen med kryds-entropi og tilf\u00f8jer harmonisk regularisering som i den line\u00e6re model, som sikrer en ubetydelig \u00e6ndring af de gamle v\u00e6gte.<\/p>\n<p><img decoding=\"async\" alt=\"Udnyttelse af maskinl\u00e6ring i Mail.ru\" src=\"\/wp-content\/uploads\/2019\/11\/4491639587d1c91ac91d77b587ee0111.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>CNN<\/h3>\n<p>\nDet er lidt mere kompliceret med konvolutionsnetv\u00e6rk. Hvis de sidste lag i CNN finjusteres, kan man naturligvis anvende harmonisk regularisering og sikre kontinuitet. Men i det tilf\u00e6lde, hvor hele netv\u00e6rket skal finjusteres, kan s\u00e5dan en regularisering ikke anvendes p\u00e5 alle lag. Der er dog en mulighed for at tr\u00e6ne komplement\u00e6re embeddings gennem Triplet Loss (<noindex><a rel=\"nofollow\" href=\"https:\/\/arxiv.org\/abs\/1503.03832\">original artikel<\/a><\/noindex>).<\/p>\n<h4>Triplet Loss<\/h4>\n<p>\nVi vil i grove tr\u00e6k gennemg\u00e5 Triplet Loss ved at tage udgangspunkt i opgaven med at opdage phishing. Vi tager vores logo samt positive og negative eksempler p\u00e5 logoer fra andre virksomheder. Vi minimerer afstanden mellem de f\u00f8rste og maksimerer afstanden mellem de sidste, og vi g\u00f8r dette med en lille margin for at sikre st\u00f8rre kompakthed af klasserne. <\/p>\n<p><img decoding=\"async\" alt=\"Udnyttelse af maskinl\u00e6ring i Mail.ru\" src=\"\/wp-content\/uploads\/2019\/11\/dc8547fa042286798eb5c2f0887c4da6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHvis vi finjusterer netv\u00e6rket, \u00e6ndres det metrisk rum fuldst\u00e6ndigt, og det bliver absolut inkompatibelt med det forrige. Dette er et alvorligt problem i opgaver, der bruger vektorer. For at overvinde dette problem vil vi blande gamle embeddings ind under tr\u00e6ningen.<\/p>\n<p>Vi har tilf\u00f8jet nye data til tr\u00e6ningss\u00e6ttet og tr\u00e6ner fra bunden den anden version af modellen. I den anden fase finjusterer vi vores netv\u00e6rk: f\u00f8rst finjusteres det sidste lag, og derefter fryses hele netv\u00e6rket. Under sammens\u00e6tningen af tripletter beregner vi kun en del af indlejringerne ved hj\u00e6lp af den tr\u00e6nede model, mens resten beregnes med den gamle. P\u00e5 den m\u00e5de sikrer vi kompatibiliteten mellem de metrisk rum v1 og v2 under finjusteringen. En slags harmonisk regularisering.<\/p>\n<p><img decoding=\"async\" alt=\"Udnyttelse af maskinl\u00e6ring i Mail.ru\" src=\"\/wp-content\/uploads\/2019\/11\/854d4fcc97775b24e6863cc38743cd27.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Helhedsarkitektur<\/h3>\n<p>\nHvis vi ser p\u00e5 hele systemet i eksemplet med spamfiltering, s\u00e5 er modellerne ikke isolerede, men indlejret i hinanden. Vi tager billeder, tekst og andre tr\u00e6k, og ved hj\u00e6lp af CNN og Fast Text f\u00e5r vi indlejringer. Derefter anvendes klassifikatorer over indlejringerne, som giver scores for forskellige klasser (typer af e-mails, spam, tilstedev\u00e6relse af logoer). Scores og tr\u00e6k g\u00e5r ind i et skov af tr\u00e6er for at tr\u00e6ffe den endelige beslutning. Separate klassifikatorer i denne ordning g\u00f8r det muligt at bedre fortolke resultaterne fra systemets arbejde og mere m\u00e5lrettet at finjustere komponenterne i tilf\u00e6lde af problemer, end at give alle data r\u00e5t ind i beslutningstr\u00e6erne.<\/p>\n<p><img decoding=\"async\" alt=\"Udnyttelse af maskinl\u00e6ring i Mail.ru\" src=\"\/wp-content\/uploads\/2019\/11\/30effc5ef7398db5f085b6dd415647d3.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSom et resultat sikrer vi kontinuitet p\u00e5 hvert niveau. P\u00e5 det lavere niveau i CNN og Fast Text anvender vi harmonisk regularisering, og til klassifikatorerne i midten \u2014 ogs\u00e5 harmonisk regularisering og kalibrering af scorerne for at sikre kompatibilitet med sandsynlighedsfordelingen. Boosting af tr\u00e6erne tr\u00e6nes inkrementelt eller ved hj\u00e6lp af Knowledge Distillation.<\/p>\n<p>Generelt set kan underst\u00f8ttelsen af et s\u00e5dant indlejret system af maskinl\u00e6ring v\u00e6re smertefuld, da enhver komponent p\u00e5 det lavere niveau f\u00f8rer til en opdatering af hele systemet ovenfor. Men da hver komponent i vores setup \u00e6ndres minimalt og er kompatibel med den forrige, kan hele systemet opdateres i bidder uden behov for at gentr\u00e6ne hele strukturen, hvilket g\u00f8r det muligt at vedligeholde det uden alvorligt overhead. <\/p>\n<h2>Deploy<\/h2>\n<p>\nVi har gennemg\u00e5et indsamlingen af data og finjusteringen af forskellige typer modeller, s\u00e5 nu g\u00e5r vi videre til deres deployment i produktionsmilj\u00f8et.<\/p>\n<h3>A\/B-testning<\/h3>\n<p>\nSom jeg n\u00e6vnte tidligere, f\u00e5r vi typisk en sk\u00e6v stikpr\u00f8ve under dataindsamlingen, hvilket g\u00f8r det umuligt at vurdere produktionsydeevnen af modellen. Derfor er det vigtigt at sammenligne modellen med den tidligere version ved implementeringen for at forst\u00e5, hvordan det faktisk st\u00e5r til, alts\u00e5 at udf\u00f8re A\/B-tests. Faktisk er processen med lancering og analyse af grafer ret rutinem\u00e6ssig og er let at automatisere. Vi ruller vores modeller ud gradvist til 5 %, 30 %, 50 % og 100 % af brugerne, samtidig med at vi indsamler alle tilg\u00e6ngelige metrics fra modelens svar og brugernes feedback. I tilf\u00e6lde af alvorlige udsving ruller vi automatisk modellen tilbage, og for de resterende tilf\u00e6lde, efter at have indsamlet et tilstr\u00e6kkeligt antal brugerklik, tr\u00e6ffer vi en beslutning om at \u00f8ge procentdelen. I sidste ende bringer vi den nye model op til 50 % af brugerne helt automatisk, mens en person godkender lanceringen til hele publikum, selvom dette trin ogs\u00e5 kan automatiseres.<\/p>\n<p>Men A\/B-testprocessen rummer muligheder for optimering. Problemet er, at enhver A\/B-test er relativt lang (i vores tilf\u00e6lde tager den mellem 6 og 24 timer afh\u00e6ngigt af m\u00e6ngden af feedback), hvilket g\u00f8r den ret kostbar og med begr\u00e6nsede ressourcer. Derudover kr\u00e6ves der en h\u00f8j procentdel af flowet til testen for i realiteten at fremskynde den samlede tid for A\/B-testen (at opsamle statistisk signifikante stikpr\u00f8ver for at vurdere metrics p\u00e5 et lille procentdel kan tage lang tid), hvilket g\u00f8r antallet af A\/B-slots ekstremt begr\u00e6nset. Det er \u00e5benlyst, at vi skal bringe de mest lovende modeller ind i testen, og i l\u00f8bet af den yderligere tr\u00e6ning f\u00e5r vi mange af dem.<\/p>\n<p>For at l\u00f8se denne opgave har vi tr\u00e6net en separat klassificer, der forudsiger succesraten for A\/B-testen. Til dette bruger vi som funktioner beslutningsstatistik, Precision, Recall og andre metrics p\u00e5 det tr\u00e6ningss\u00e6t, det afholdte s\u00e6t og et sample fra flowet. Vi sammenligner ogs\u00e5 modellen med den nuv\u00e6rende version i produktionen, med heuristikker og tager modellens kompleksitet (Complexity) i betragtning. Ved at bruge alle disse funktioner scorer klassificeren, der er tr\u00e6net p\u00e5 testhistorikken, modellerne-kandidater, i vores tilf\u00e6lde tr\u00e6er i skovene, og tr\u00e6ffer beslutning om, hvilken af dem der skal sendes til A\/B-test. <\/p>\n<p><img decoding=\"async\" alt=\"Udnyttelse af maskinl\u00e6ring i Mail.ru\" src=\"\/wp-content\/uploads\/2019\/11\/41b121987209a663075be399e83f5a50.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVed implementeringen gjorde denne tilgang det muligt at \u00f8ge antallet af vellykkede A\/B-tests flere gange.<\/p>\n<h3>Testning &amp; overv\u00e5gning<\/h3>\n<p>\nTestning og overv\u00e5gning skader, m\u00e6rkeligt nok, ikke vores helbred; tv\u00e6rtimod forbedrer de det og befrier os for un\u00f8dvendig stress. Testning forhindrer fejl, mens overv\u00e5gning opdager dem i tide for at minimere indflydelsen p\u00e5 brugerne.<\/p>\n<p>Her er det vigtigt at forst\u00e5, at din system altid vil fejle f\u00f8r eller senere \u2014 dette er en del af udviklingscyklussen for enhver software. I starten af systemudviklingen er der altid mange fejl, indtil alt falder p\u00e5 plads og den prim\u00e6re innovationsfase er afsluttet. Men over tid kommer entropien tilbage, og fejl opst\u00e5r igen p\u00e5 grund af komponentdegradering og \u00e6ndringer i data, som jeg n\u00e6vnte indledningsvis.<\/p>\n<p>Her vil jeg gerne bem\u00e6rke, at ethvert maskinl\u00e6ringssystem skal betragtes udfra dens afkast gennem hele livscyklussen. Nedenfor vises et eksempel p\u00e5, hvordan et system til at fange sj\u00e6ldne former for spam fungerede (grafen viser en linje t\u00e6t p\u00e5 nul). En gang for\u00e5rsagede en forkert cachelagret funktion, at det blev ustabilt. Som held var der ingen overv\u00e5gning for unormale aktiveringer, hvilket resulterede i, at systemet begyndte at gemme e-mails i mappen \"spam\" i store m\u00e6ngder ved beslutningsgr\u00e6nsen. P\u00e5 trods af at der blev rettet op p\u00e5 konsekvenserne, havde systemet allerede fejlet s\u00e5 mange gange, at det ikke ville kunne betale sig inden for fem \u00e5r. Dette er en fuldst\u00e6ndig fiasko i forhold til modellens livscyklus. <\/p>\n<p><img decoding=\"async\" alt=\"Udnyttelse af maskinl\u00e6ring i Mail.ru\" src=\"\/wp-content\/uploads\/2019\/11\/65efd799537ceea3761cabc3a764ba90.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDerfor kan s\u00e5 en simpel ting som overv\u00e5gning blive afg\u00f8rende i modellens liv. Udover standard- og \u00e5benlyse m\u00e5linger vurderer vi fordelingen af \u200b\u200bmodellens svar og scores samt fordelingen af v\u00e6rdierne for de n\u00f8glefunktioner. Ved hj\u00e6lp af KL-divergens kan vi sammenligne den nuv\u00e6rende fordeling med den historiske eller v\u00e6rdierne fra A\/B-testen med den \u00f8vrige str\u00f8m, hvilket g\u00f8r os i stand til at opdage anomalier i modellen og hurtigt rulle \u00e6ndringer tilbage.<\/p>\n<p>I de fleste tilf\u00e6lde starter vi vores f\u00f8rste versioner af systemerne ved hj\u00e6lp af enkle heuristikker eller modeller, som vi senere bruger til overv\u00e5gning. For eksempel overv\u00e5ger vi NER-modellen i forhold til regul\u00e6re udtryk for specifikke onlinebutikker, og hvis d\u00e6kningen af klassifikatoren falder i forhold til dem, unders\u00f8ger vi \u00e5rsagerne. Endnu en nyttig anvendelse af heuristikker!<\/p>\n<h2>Resum\u00e9<\/h2>\n<p>\nLad os gennemg\u00e5 n\u00f8glepunkterne i artiklen igen.<\/p>\n<ul>\n<li><b>Fibd\u00e6k<\/b>. Vi t\u00e6nker altid p\u00e5 brugeren: hvordan vil de leve med vores fejl, og hvordan kan de rapportere dem. Vi glemmer ikke, at brugerne ikke er en kilde til rent feedback til modeltr\u00e6ning, og det er n\u00f8dvendigt at rense det ved hj\u00e6lp af supplerende ML-systemer. Hvis det ikke er muligt at indsamle signaler fra brugeren, s\u00f8ger vi alternative kilder til feedback, s\u00e5som relaterede systemer. \n<\/li>\n<li><b>Finjustering<\/b>. Her er det vigtigste kontinuitet, s\u00e5 vi bygger videre p\u00e5 den nuv\u00e6rende produktionsmodel. Vi tr\u00e6ner nye modeller, s\u00e5 de ikke adskiller sig v\u00e6sentligt fra den foreg\u00e5ende ved hj\u00e6lp af harmonisk regularisering og lignende tricks.<\/li>\n<li><b>Deploy<\/b>. Autodeploy baseret p\u00e5 metrikker forkorter betydeligt tiden til implementering af modeller. Overv\u00e5gning af statistikker og beslutningstagningens fordeling, samt antallet af falske svar fra brugerne, er obligatorisk for din sindsro og produktive weekender.\n<\/li>\n<\/ul>\n<p>\nJeg h\u00e5ber, at det l\u00e6ste hj\u00e6lper dig med hurtigere at forbedre dine ML-systemer, accelerere deres lancering og g\u00f8re dem mere p\u00e5lidelige, hvilket reducerer stresset ved arbejdet.<br \/>\n<br \/>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/476714\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u043e \u043c\u043e\u0442\u0438\u0432\u0430\u043c \u043c\u043e\u0438\u0445 \u0432\u044b\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u0439 \u043d\u0430 Highload++ \u0438 DataFest Minsk 2019 \u0433. \u0414\u043b\u044f \u043c\u043d\u043e\u0433\u0438\u0445 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u043f\u043e\u0447\u0442\u0430 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043d\u0435\u043e\u0442\u044a\u0435\u043c\u043b\u0435\u043c\u043e\u0439 \u0447\u0430\u0441\u0442\u044c\u044e \u0436\u0438\u0437\u043d\u0438 \u0432 \u0441\u0435\u0442\u0438. \u0421 \u0435\u0435 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u043c\u044b \u0432\u0435\u0434\u0435\u043c \u0431\u0438\u0437\u043d\u0435\u0441-\u043f\u0435\u0440\u0435\u043f\u0438\u0441\u043a\u0443, \u0445\u0440\u0430\u043d\u0438\u043c \u0432\u0441\u0435\u0432\u043e\u0437\u043c\u043e\u0436\u043d\u0443\u044e \u0432\u0430\u0436\u043d\u0443\u044e \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044e, \u0441\u0432\u044f\u0437\u0430\u043d\u043d\u0443\u044e \u0441 \u0444\u0438\u043d\u0430\u043d\u0441\u0430\u043c\u0438, \u0431\u0440\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435\u043c \u043e\u0442\u0435\u043b\u0435\u0439, \u043e\u0444\u043e\u0440\u043c\u043b\u0435\u043d\u0438\u0435\u043c \u0437\u0430\u043a\u0430\u0437\u043e\u0432 \u0438 \u043c\u043d\u043e\u0433\u0438\u043c \u0434\u0440\u0443\u0433\u0438\u043c. \u0412 \u0441\u0435\u0440\u0435\u0434\u0438\u043d\u0435 2018 \u0433\u043e\u0434\u0430 \u043c\u044b \u0441\u0444\u043e\u0440\u043c\u0443\u043b\u0438\u0440\u043e\u0432\u0430\u043b\u0438 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u043e\u0432\u0443\u044e \u0441\u0442\u0440\u0430\u0442\u0435\u0433\u0438\u044e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f \u043f\u043e\u0447\u0442\u044b. \u041a\u0430\u043a\u043e\u0439 \u0436\u0435 \u0434\u043e\u043b\u0436\u043d\u0430 \u0431\u044b\u0442\u044c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-53143","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u043e \u043c\u043e\u0442\u0438\u0432\u0430\u043c \u043c\u043e\u0438\u0445 \u0432\u044b\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u0439 \u043d\u0430.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ekspluatatsiya-mashinnogo-obucheniya-v-pochte-mail-ru\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u042d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u044f \u043c\u0430\u0448\u0438\u043d\u043d\u043e\u0433\u043e \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u044f \u0432 \u041f\u043e\u0447\u0442\u0435 Mail.ru | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u043e \u043c\u043e\u0442\u0438\u0432\u0430\u043c \u043c\u043e\u0438\u0445 \u0432\u044b\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u0439 \u043d\u0430.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ekspluatatsiya-mashinnogo-obucheniya-v-pochte-mail-ru\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-11-23T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:01:00+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Udnyttelse af maskinl\u00e6ring i Mail.ru | ProHoster","description":"Inspireret af mine pr\u00e6sentationer p\u00e5.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ekspluatatsiya-mashinnogo-obucheniya-v-pochte-mail-ru","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u042d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u044f \u043c\u0430\u0448\u0438\u043d\u043d\u043e\u0433\u043e \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u044f \u0432 \u041f\u043e\u0447\u0442\u0435 Mail.ru | ProHoster","og:description":"\u041f\u043e \u043c\u043e\u0442\u0438\u0432\u0430\u043c \u043c\u043e\u0438\u0445 \u0432\u044b\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u0439 \u043d\u0430.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ekspluatatsiya-mashinnogo-obucheniya-v-pochte-mail-ru","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-11-23T21:00:00+00:00","article:modified_time":"2020-02-18T11:01:00+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53143","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 06:14:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:30:25","updated":"2026-01-24 06:14:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/53143","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=53143"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/53143\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=53143"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=53143"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=53143"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}