Drift af maskinlæring i Mail.ru Mail

Baseret på mine taler på Highload++ og DataFest Minsk 2019.

For mange i dag er mail en integreret del af livet på nettet. Med dens hjælp fører vi forretningskorrespondance, opbevarer alle mulige vigtige informationer relateret til økonomi, hotelreservationer, afgivelse af ordrer og meget mere. I midten af ​​2018 formulerede vi en produktstrategi for postudvikling. Hvordan skal moderne post være?

Mail skal være smart, det vil sige at hjælpe brugere med at navigere i den stigende mængde information: filtrere, strukturere og levere dem på den mest bekvemme måde. Det må hun være nyttig, så du kan løse forskellige opgaver lige i din postkasse, for eksempel betale bøder (en funktion, som jeg desværre bruger). Og samtidig skal mail selvfølgelig give informationsbeskyttelse, afskære spam og beskytte mod hacking, dvs. sikker.

Disse områder definerer en række nøgleproblemer, hvoraf mange kan løses effektivt ved hjælp af maskinlæring. Her er eksempler på allerede eksisterende funktioner udviklet som en del af strategien – en til hver retning.

• Smart svar. Mail har en smart svarfunktion. Det neurale netværk analyserer brevets tekst, forstår dets betydning og formål og tilbyder som et resultat de tre mest passende svarmuligheder: positiv, negativ og neutral. Dette er med til at spare tid betydeligt, når du besvarer breve, og svarer også ofte på en ikke-standardiseret og sjov måde.
• Gruppering af e-mailsrelateret til ordrer i netbutikker. Vi handler ofte online, og butikker kan som udgangspunkt sende flere mails for hver ordre. Fra AliExpress, den største tjeneste, kommer der for eksempel mange breve ind til én ordre, og vi beregnede, at i terminaltilfældet kunne deres antal nå op til 29. Derfor udtrækker vi ordrenummeret ved at bruge modellen for navngivet enhedsgenkendelse. og andre oplysninger fra teksten og grupper alle bogstaver i én tråd. Vi viser også grundlæggende information om ordren i en separat boks, hvilket gør det nemmere at arbejde med denne type e-mail.

  

• Antiphishing. Phishing er en særlig farlig svigagtig type e-mail, ved hjælp af hvilken angribere forsøger at få økonomiske oplysninger (inklusive brugerens bankkort) og logins. Sådanne breve efterligner rigtige breve sendt af tjenesten, herunder visuelt. Derfor genkender vi ved hjælp af Computer Vision logoer og designstilen for breve fra store virksomheder (f.eks. Mail.ru, Sber, Alfa) og tager højde for dette sammen med tekst og andre funktioner i vores spam- og phishing-klassificeringer .

Maskinelæring

Lidt om maskinlæring i e-mail generelt. Mail er et meget belastet system: Der passerer i gennemsnit 1,5 milliarder breve om dagen gennem vores servere for 30 millioner DAU-brugere. Omkring 30 maskinlæringssystemer understøtter alle de nødvendige funktioner og funktioner.

Hvert bogstav går gennem en hel klassifikationspipeline. Først afskærer vi spam og efterlader gode e-mails. Brugere bemærker ofte ikke arbejdet med antispam, fordi 95-99% af spam ikke engang ender i den relevante mappe. Spam-genkendelse er en meget vigtig del af vores system, og den sværeste, da der inden for anti-spam er en konstant tilpasning mellem forsvars- og angrebssystemer, hvilket giver en kontinuerlig teknisk udfordring for vores team.

Dernæst adskiller vi breve fra mennesker og robotter. E-mails fra folk er de vigtigste, så vi leverer funktioner som Smart Reply til dem. Breve fra robotter er opdelt i to dele: transaktionelle - disse er vigtige breve fra tjenester, for eksempel bekræftelser på køb eller hotelreservationer, økonomi og information - disse er virksomhedsreklamer, rabatter.

Vi mener, at transaktionelle e-mails er lige vigtige for personlig korrespondance. De skal være lige ved hånden, for ofte skal vi hurtigt finde information om en bestilling eller flybilletreservation, og vi bruger tid på at søge efter disse breve. Derfor opdeler vi dem for nemheds skyld automatisk i seks hovedkategorier: rejser, bestillinger, økonomi, billetter, tilmeldinger og endelig bøder.

Informationsbreve er den største og sandsynligvis mindre vigtige gruppe, som ikke kræver et øjeblikkeligt svar, da intet væsentligt vil ændre sig i brugerens liv, hvis han ikke læser et sådant brev. I vores nye grænseflade samler vi dem sammen i to tråde: sociale netværk og nyhedsbreve, så vi visuelt rydder indbakken og efterlader kun vigtige beskeder synlige.

Udnyttelse

Et stort antal systemer forårsager mange vanskeligheder i drift. Trods alt forringes modeller over tid, som enhver software: funktioner går i stykker, maskiner fejler, koden bliver skæv. Derudover ændres data konstant: nye tilføjes, brugeradfærdsmønstre transformeres osv., så en model uden ordentlig support vil fungere dårligere og dårligere over tid.

Vi må ikke glemme, at jo dybere maskinlæring trænger ind i brugernes liv, jo større indvirkning har de på økosystemet, og som et resultat, jo flere økonomiske tab eller profitter kan markedsaktører modtage. Derfor tilpasser spillerne sig på et stigende antal områder til arbejdet med ML-algoritmer (klassiske eksempler er reklame, søgning og den allerede nævnte antispam).

Maskinlæringsopgaver har også en særegenhed: Enhver, selv mindre, ændring i systemet kan generere en masse arbejde med modellen: arbejde med data, genoptræning, implementering, som kan tage uger eller måneder. Derfor, jo hurtigere miljøet, som dine modeller opererer i, ændrer sig, jo større indsats kræver det at vedligeholde dem. Et team kan skabe en masse systemer og være glade for det, men så bruge næsten alle sine ressourcer på at vedligeholde dem, uden mulighed for at lave noget nyt. Vi stødte engang på en sådan situation i antispam-teamet. Og de kom med den indlysende konklusion, at support skal automatiseres.

Automation

Hvad kan automatiseres? Næsten alt, faktisk. Jeg har identificeret fire områder, der definerer maskinlæringsinfrastrukturen:

• dataindsamling;
• yderligere uddannelse;
• indsætte;
• test og overvågning.

Hvis miljøet er ustabilt og konstant i forandring, så viser hele infrastrukturen omkring modellen sig at være meget vigtigere end selve modellen. Det kan være en god gammel lineær klassificering, men hvis du fodrer den med de rigtige funktioner og får god feedback fra brugerne, vil den fungere meget bedre end state-of-the-art modeller med alle de klokker og fløjter.

Feedback loop

Denne cyklus kombinerer dataindsamling, yderligere træning og implementering - faktisk hele modelopdateringscyklussen. Hvorfor er det vigtigt? Se tilmeldingsplanen i mailen:

En maskinlæringsudvikler har implementeret en anti-bot-model, der forhindrer bots i at registrere sig i e-mail. Grafen falder til en værdi, hvor der kun er rigtige brugere tilbage. Alt er fantastisk! Men der går fire timer, bots justerer deres scripts, og alt vender tilbage til det normale. I denne implementering brugte udvikleren en måned på at tilføje funktioner og genoptræne modellen, men spammeren var i stand til at tilpasse sig på fire timer.

For ikke at gøre så voldsomt ondt og ikke skulle lave alt om senere, må vi i første omgang tænke over, hvordan feedback-sløjfen kommer til at se ud, og hvad vi vil gøre, hvis omgivelserne ændrer sig. Lad os starte med at indsamle data - dette er brændstoffet til vores algoritmer.

Dataindsamling

Det er klart, at for moderne neurale netværk, jo flere data, jo bedre, og de genereres faktisk af brugere af produktet. Brugere kan hjælpe os ved at markere data, men vi kan ikke misbruge dette, fordi brugerne på et tidspunkt bliver trætte af at færdiggøre dine modeller og skifter til et andet produkt.

En af de mest almindelige fejl (her refererer jeg til Andrew Ng) er for meget fokus på målinger på testdatasættet, og ikke på feedback fra brugeren, hvilket faktisk er hovedmålet for kvaliteten af ​​arbejdet, da vi skaber et produkt til brugeren. Hvis brugeren ikke forstår eller ikke kan lide modellens arbejde, så er alt ødelagt.

Derfor skal brugeren altid kunne stemme og skal have et værktøj til feedback. Hvis vi tror, ​​at der er kommet et brev relateret til økonomi i postkassen, skal vi markere det "finans" og tegne en knap, som brugeren kan klikke på og sige, at det ikke er økonomi.

Feedback kvalitet

Lad os tale om kvaliteten af ​​brugerfeedback. For det første kan du og brugeren lægge forskellige betydninger ind i ét koncept. For eksempel tror du og dine produktchefer, at "økonomi" betyder breve fra banken, og brugeren mener, at et brev fra bedstemor om hendes pension også refererer til økonomi. For det andet er der brugere, der åndssvagt elsker at trykke på knapper uden nogen logik. For det tredje kan brugeren tage dybt fejl i sine konklusioner. Et slående eksempel fra vores praksis er implementeringen af ​​en klassifikator nigeriansk spam, en meget sjov form for spam, hvor brugeren bliver bedt om at tage flere millioner dollars fra en pludselig fundet fjern slægtning i Afrika. Efter at have implementeret denne klassificering, tjekkede vi "Ikke Spam"-klikkene på disse e-mails, og det viste sig, at 80 % af dem var saftig nigeriansk spam, hvilket tyder på, at brugere kan være ekstremt godtroende.

Og lad os ikke glemme, at knapperne ikke kun kan klikkes af mennesker, men også af alle mulige bots, der foregiver at være en browser. Så rå feedback er ikke godt for læring. Hvad kan du gøre med disse oplysninger?

Vi bruger to tilgange:

• Feedback fra linket ML. For eksempel har vi et online anti-bot system, der, som jeg nævnte, tager en hurtig beslutning ud fra et begrænset antal tegn. Og der er et andet, langsomt system, der virker bagefter. Den har flere data om brugeren, hans adfærd osv. Som et resultat bliver den mest informerede beslutning truffet; følgelig har den højere nøjagtighed og fuldstændighed. Du kan rette forskellen i driften af ​​disse systemer til det første som træningsdata. Således vil et enklere system altid forsøge at nærme sig ydeevnen af ​​et mere komplekst.
• Klik klassificering. Du kan ganske enkelt klassificere hvert brugerklik, evaluere dets gyldighed og anvendelighed. Det gør vi i antispam-mail, ved hjælp af brugerattributter, hans historie, afsenderattributter, selve teksten og resultatet af klassificeringerne. Som et resultat får vi et automatisk system, der validerer brugerfeedback. Og da det skal omskoles meget sjældnere, kan dets arbejde blive grundlaget for alle andre systemer. Hovedprioriteten i denne model er præcision, fordi træning af modellen på unøjagtige data er fyldt med konsekvenser.

Mens vi renser data og videreuddanner vores ML-systemer, må vi ikke glemme brugerne, for for os er tusinder, millioner af fejl på grafen statistik, og for brugeren er hver fejl en tragedie. Ud over at brugeren på en eller anden måde må leve med din fejl i produktet, forventer han efter at have modtaget feedback, at en lignende situation vil blive elimineret i fremtiden. Derfor er det altid værd at give brugerne ikke kun muligheden for at stemme, men også at rette opførselen af ​​ML-systemer ved at skabe for eksempel personlige heuristika for hvert feedback-klik; i tilfælde af mail kan dette være muligheden for at filtrere sådanne breve efter afsender og titel for denne bruger.

Du skal også bygge en model baseret på nogle rapporter eller anmodninger om at understøtte i en semi-automatisk eller manuel tilstand, så andre brugere ikke lider af lignende problemer.

Heuristik til læring

Der er to problemer med disse heuristika og krykker. Den første er, at det stadigt stigende antal krykker er vanskeligt at vedligeholde, endsige deres kvalitet og ydeevne i det lange løb. Det andet problem er, at fejlen muligvis ikke er hyppig, og et par klik for at træne modellen yderligere vil ikke være nok. Det ser ud til, at disse to ikke-relaterede virkninger kan neutraliseres væsentligt, hvis følgende fremgangsmåde anvendes.

1. Vi skaber en midlertidig krykke.
2. Vi sender data fra den til modellen, den opdaterer sig selv løbende, herunder på de modtagne data. Her er det selvfølgelig vigtigt, at heuristikkerne har høj nøjagtighed for ikke at forringe kvaliteten af ​​dataene i træningssættet.
3. Så sætter vi overvågningen til at udløse krykken, og hvis krykken efter noget tid ikke længere virker og er helt dækket af modellen, så kan du roligt fjerne den. Nu er det usandsynligt, at dette problem opstår igen.

Så en hær af krykker er meget nyttig. Det vigtigste er, at deres service er presserende og ikke permanent.

Yderligere træning

Genoplæring er processen med at tilføje nye data opnået som et resultat af feedback fra brugere eller andre systemer og træne en eksisterende model på det. Der kan være flere problemer med yderligere træning:

1. Modellen understøtter måske simpelthen ikke yderligere træning, men lærer kun fra bunden.
2. Intet sted i naturens bog står der, at yderligere træning helt sikkert vil forbedre kvaliteten af ​​arbejdet i produktionen. Ofte sker det modsatte, det vil sige, at kun forringelse er mulig.
3. Ændringer kan være uforudsigelige. Dette er et ret subtilt punkt, som vi selv har identificeret. Selvom en ny model i en A/B-test viser lignende resultater sammenlignet med den nuværende, betyder det ikke, at den vil fungere identisk. Deres arbejde kan afvige på kun én procent, hvilket kan medføre nye fejl eller returnere gamle, der allerede er blevet rettet. Både vi og brugerne ved allerede, hvordan de skal leve med aktuelle fejl, og når der opstår en lang række nye fejl, forstår brugeren måske heller ikke, hvad der sker, fordi han forventer forudsigelig adfærd.

Derfor er det vigtigste ved efteruddannelse at sikre, at modellen bliver forbedret, eller i hvert fald ikke forringet.

Det første, der kommer til at tænke på, når vi taler om yderligere træning, er den aktive læringstilgang. Hvad betyder det? For eksempel bestemmer klassifikatoren, om en e-mail er relateret til økonomi, og omkring dens beslutningsgrænse tilføjer vi et eksempel på mærkede eksempler. Dette fungerer godt, for eksempel i annoncering, hvor der er meget feedback, og man kan træne modellen online. Og hvis der er lidt feedback, så får vi en stærkt partisk prøve i forhold til produktionsdatafordelingen, på grundlag af hvilken det er umuligt at evaluere modellens adfærd under drift.

Faktisk er vores mål at bevare gamle mønstre, allerede kendte modeller og erhverve nye. Kontinuitet er vigtig her. Modellen, som vi ofte gjorde os umage med at rulle ud, fungerer allerede, så vi kan fokusere på dens ydeevne.

Forskellige modeller bruges i post: træer, lineære, neurale netværk. For hver laver vi vores egen ekstra træningsalgoritme. I processen med yderligere træning modtager vi ikke kun nye data, men også ofte nye funktioner, som vi vil tage højde for i alle algoritmerne nedenfor.

Lineære modeller

Lad os sige, at vi har logistisk regression. Vi opretter en tabsmodel ud fra følgende komponenter:

• LogTab på nye data;
• vi regulerer vægten af ​​nye funktioner (vi rører ikke de gamle);
• vi lærer også af gamle data for at bevare gamle mønstre;
• og måske det vigtigste: Vi tilføjer Harmonic Regularization, som garanterer, at vægtene ikke ændrer sig meget i forhold til den gamle model ifølge normen.

Da hver tabskomponent har koefficienter, kan vi vælge de optimale værdier for vores opgave gennem krydsvalidering eller baseret på produktkrav.

Деревья

Lad os gå videre til beslutningstræerne. Vi har samlet følgende algoritme til yderligere træning af træer:

1. Produktionen driver en skov på 100-300 træer, som er trænet på et gammelt datasæt.
2. Til sidst fjerner vi M = 5 stykker og tilføjer 2M = 10 nye, trænet på hele datasættet, men med en høj vægt for de nye data, hvilket naturligvis garanterer en trinvis ændring i modellen.

Det er klart, at antallet af træer over tid stiger meget, og de skal med jævne mellemrum reduceres for at overholde tidsplanen. For at gøre dette bruger vi den nu allestedsnærværende Knowledge Destillation (KD). Kort om princippet om dens funktion.

1. Vi har den nuværende "komplekse" model. Vi kører det på træningsdatasættet og får klassesandsynlighedsfordelingen ved output.
2. Dernæst træner vi elevmodellen (modellen med færre træer i dette tilfælde) til at gentage modellens resultater ved at bruge klassefordelingen som målvariabel.
3. Det er vigtigt at bemærke her, at vi ikke bruger datasætmarkeringen på nogen måde, og derfor kan vi bruge vilkårlige data. Vi bruger selvfølgelig en dataprøve fra kampstrømmen som træningsprøve til elevmodellen. Således giver træningssættet os mulighed for at sikre nøjagtigheden af ​​modellen, og strømprøven garanterer en lignende ydeevne på produktionsfordelingen, hvilket kompenserer for skævheden i træningssættet.

Kombinationen af ​​disse to teknikker (tilføjelse af træer og periodisk reduktion af deres antal ved hjælp af Knowledge Destillation) sikrer introduktionen af ​​nye mønstre og fuldstændig kontinuitet.

Ved hjælp af KD udfører vi også forskellige operationer på modelfunktioner, såsom at fjerne funktioner og arbejde på huller. I vores tilfælde har vi en række vigtige statistiske funktioner (af afsendere, teksthash, URL'er osv.), som er gemt i databasen, som har en tendens til at fejle. Modellen er naturligvis ikke klar til en sådan udvikling af hændelser, da fejlsituationer ikke opstår i træningssættet. I sådanne tilfælde kombinerer vi KD- og augmentationsteknikker: Når vi træner for en del af dataene, fjerner eller nulstiller vi de nødvendige funktioner, og vi tager de originale etiketter (output fra den nuværende model), og elevmodellen lærer at gentage denne distribution .

Vi har bemærket, at jo mere seriøs modelmanipulation forekommer, jo større er procentdelen af ​​trådprøven, der kræves.

Funktionsfjernelse, den enkleste operation, kræver kun en lille del af flowet, da kun et par funktioner ændres, og den nuværende model blev trænet på det samme sæt - forskellen er minimal. For at forenkle modellen (reducere antallet af træer flere gange), kræves der allerede 50 til 50. Og for udeladelser af vigtige statistiske træk, som i alvorlig grad vil påvirke modellens ydeevne, kræves der endnu mere flow for at udjævne arbejdet i ny fejlfri model på alle typer breve.

Hurtigtekst

Lad os gå videre til FastText. Lad mig minde dig om, at repræsentationen (Indlejring) af et ord består af summen af ​​indlejringen af ​​selve ordet og alle dets bogstav N-gram, normalt trigrammer. Da der kan være ret mange trigrammer, bruges Bucket Hashing, det vil sige at konvertere hele rummet til et bestemt fast hashmap. Som et resultat opnås vægtmatricen med dimensionen af ​​det indre lag pr. antal ord + spande.

Med yderligere træning dukker nye tegn op: ord og trigrammer. Der sker ikke noget væsentligt i standard opfølgningstræning fra Facebook. Kun gamle vægte med krydsentropi genoptrænes på nye data. Nye funktioner bruges således ikke, denne tilgang har naturligvis alle de ovenfor beskrevne ulemper forbundet med modellens uforudsigelighed i produktionen. Derfor har vi ændret en lille smule på FastText. Vi tilføjer alle nye vægte (ord og trigrammer), udvider hele matrixen med krydsentropi og tilføjer harmonisk regularisering i analogi med den lineære model, som garanterer en ubetydelig ændring i de gamle vægte.

CNN

Konvolutionelle netværk er lidt mere komplicerede. Hvis de sidste lag trænes i CNN, så kan du selvfølgelig anvende harmonisk regularisering og garantere kontinuitet. Men hvis der kræves yderligere træning af hele netværket, kan en sådan regularisering ikke længere anvendes på alle lag. Der er dog en mulighed for at træne komplementære indlejringer gennem Triplet Loss (original artikel).

Tredobbelt tab

Brug en anti-phishing-opgave som eksempel, lad os se på Triplet Loss i generelle vendinger. Vi tager vores logo, samt positive og negative eksempler på logoer fra andre virksomheder. Vi minimerer afstanden mellem den første og maksimerer afstanden mellem den anden, vi gør dette med et lille mellemrum for at sikre større kompakthed af klasserne.

Hvis vi træner netværket videre, ændres vores metriske rum fuldstændig, og det bliver fuldstændig uforeneligt med det forrige. Dette er et alvorligt problem i problemer, der bruger vektorer. For at komme uden om dette problem vil vi blande gamle indlejringer i under træningen.

Vi har tilføjet nye data til træningssættet og træner den anden version af modellen fra bunden. På anden fase træner vi vores netværk videre (Finetuning): først afsluttes det sidste lag, og derefter fryses hele netværket op. I processen med at komponere tripletter beregner vi kun en del af indlejringerne ved hjælp af den trænede model, resten - ved hjælp af den gamle. I processen med yderligere træning sikrer vi således kompatibiliteten af ​​metriske rum v1 og v2. En unik version af harmonisk regularisering.

Hele arkitekturen

Hvis vi betragter hele systemet ved hjælp af antispam som et eksempel, så er modellerne ikke isolerede, men indlejrede i hinanden. Vi tager billeder, tekst og andre funktioner, ved hjælp af CNN og Fast Text får vi indlejringer. Dernæst anvendes klassifikatorer oven på indlejringerne, som giver score for forskellige klasser (typer af breve, spam, tilstedeværelse af et logo). Signalerne og skiltene går allerede ind i skoven af ​​træer, for at den endelige beslutning skal træffes. Individuelle klassifikatorer i denne ordning gør det muligt bedre at fortolke systemets resultater og mere specifikt genoptræne komponenter i tilfælde af problemer, frem for at føre alle data ind i beslutningstræer i en rå form.

Som et resultat garanterer vi kontinuitet på alle niveauer. På det nederste niveau i CNN og Fast Text bruger vi harmonisk regularisering, til klassifikatorerne i midten bruger vi også harmonisk regularisering og hastighedskalibrering for konsistens af sandsynlighedsfordelingen. Nå, træboosting trænes trinvist eller ved hjælp af videndestillation.

Generelt er det normalt en smerte at vedligeholde et sådant indlejret maskinlæringssystem, da enhver komponent på det lavere niveau fører til en opdatering af hele systemet ovenfor. Men da hver komponent i vores opsætning ændres en smule og er kompatibel med den forrige, kan hele systemet opdateres stykke for stykke uden behov for at genoptræne hele strukturen, hvilket gør det muligt at understøtte det uden alvorlige omkostninger.

Indsætte

Vi har diskuteret dataindsamling og yderligere træning af forskellige typer modeller, så vi går videre til deres udrulning i produktionsmiljøet.

A/B test

Som jeg sagde tidligere, i processen med at indsamle data, får vi normalt en forudindtaget prøve, hvorfra det er umuligt at evaluere modellens produktionsydelse. Derfor skal modellen ved udrulning sammenlignes med den tidligere version for at forstå, hvordan det rent faktisk går, det vil sige udføre A/B-tests. Faktisk er processen med at rulle ud og analysere diagrammer ret rutinemæssig og kan nemt automatiseres. Vi udruller vores modeller gradvist til 5 %, 30 %, 50 % og 100 % af brugerne, mens vi indsamler alle tilgængelige metrics om modelsvar og brugerfeedback. I tilfælde af nogle alvorlige outliers ruller vi automatisk modellen tilbage, og i andre tilfælde beslutter vi, efter at have indsamlet et tilstrækkeligt antal brugerklik, at øge procentdelen. Som et resultat bringer vi den nye model til 50 % af brugerne helt automatisk, og udrulningen til hele publikum vil blive godkendt af en person, selvom dette trin kan automatiseres.

A/B-testprocessen giver dog plads til optimering. Faktum er, at enhver A/B-test er ret lang (i vores tilfælde tager det fra 6 til 24 timer afhængigt af mængden af ​​feedback), hvilket gør det ret dyrt og med begrænsede ressourcer. Derudover kræves der en tilstrækkelig høj procentdel af flow til testen for i det væsentlige at fremskynde den samlede tid af A/B-testen (at rekruttere en statistisk signifikant prøve til at evaluere metrikker ved en lille procentdel kan tage meget lang tid), hvilket gør antallet af A/B slots ekstremt begrænset. Det er klart, at vi kun skal teste de mest lovende modeller, som vi modtager en hel del af under den ekstra træningsproces.

For at løse dette problem trænede vi en separat klassifikator, der forudsiger succesen af ​​en A/B-test. For at gøre dette tager vi beslutningsstatistik, præcision, tilbagekaldelse og andre målinger på træningssættet, på det udskudte og på stikprøven fra strømmen som funktioner. Vi sammenligner også modellen med den nuværende i produktion, med heuristik, og tager højde for modellens kompleksitet. Ved at bruge alle disse funktioner evaluerer en klassifikator, der er trænet i testhistorie, kandidatmodeller, i vores tilfælde er disse skove af træer, og beslutter, hvilken der skal bruges i A/B-testen.

På tidspunktet for implementeringen tillod denne tilgang os at øge antallet af vellykkede A/B-tests flere gange.

Test og overvågning

Test og overvågning skader mærkeligt nok ikke vores helbred, men tværtimod forbedrer de det og aflaster os for unødvendig stress. Test giver dig mulighed for at forhindre en fejl, og overvågning giver dig mulighed for at opdage det i tide for at reducere indvirkningen på brugerne.

Det er vigtigt at forstå her, at før eller siden vil dit system altid lave fejl - dette skyldes udviklingscyklussen for enhver software. I begyndelsen af ​​systemudvikling er der altid en masse fejl, indtil alt falder på plads, og hovedstadiet af innovation er afsluttet. Men med tiden tager entropien sit præg, og der opstår fejl igen – på grund af nedbrydningen af ​​komponenter omkring og ændringer i data, som jeg talte om i starten.

Her vil jeg gerne bemærke, at ethvert maskinindlæringssystem skal betragtes ud fra dets profit gennem hele dets livscyklus. Grafen nedenfor viser et eksempel på, hvordan systemet fungerer for at fange en sjælden type spam (linjen i grafen er tæt på nul). En dag, på grund af en forkert cachelagret attribut, gik hun amok. Som heldet ville det, var der ingen overvågning for unormal udløsning; som et resultat begyndte systemet at gemme breve i store mængder til "spam"-mappen ved beslutningsgrænsen. Trods de korrigerede konsekvenser har systemet allerede begået fejl så mange gange, at det ikke vil betale sig selv om fem år. Og dette er en fuldstændig fiasko set ud fra modellens livscyklus.

Derfor kan en så simpel ting som overvågning blive nøglen i en models liv. Ud over standard og indlysende metrics overvejer vi fordelingen af ​​modelsvar og -scoringer samt fordelingen af ​​nøglefunktionsværdier. Ved hjælp af KL-divergens kan vi sammenligne den aktuelle fordeling med den historiske eller værdierne i A/B-testen med resten af ​​strømmen, hvilket giver os mulighed for at bemærke anomalier i modellen og rulle ændringer tilbage i tide.

I de fleste tilfælde lancerer vi vores første versioner af systemer ved hjælp af simple heuristik eller modeller, som vi bruger som overvågning i fremtiden. For eksempel overvåger vi NER-modellen i sammenligning med de almindelige for specifikke netbutikker, og hvis klassifikationsdækningen falder i forhold til dem, så forstår vi årsagerne. Endnu en nyttig brug af heuristik!

Resultaterne af

Lad os gennemgå hovedideerne i artiklen igen.

• Fibdeck. Vi tænker altid på brugeren: hvordan han vil leve med vores fejl, hvordan han vil være i stand til at rapportere dem. Glem ikke, at brugere ikke er en kilde til ren feedback til træningsmodeller, og det skal ryddes ved hjælp af hjælpe-ML-systemer. Hvis det ikke er muligt at indsamle et signal fra brugeren, så leder vi efter alternative kilder til feedback, for eksempel tilsluttede systemer.
• Yderligere træning. Det vigtigste her er kontinuitet, så vi stoler på den nuværende produktionsmodel. Vi træner nye modeller, så de ikke adskiller sig meget fra den tidligere på grund af harmonisk regularisering og lignende tricks.
• Indsætte. Automatisk implementering baseret på metrics reducerer i høj grad tiden til implementering af modeller. Overvågning af statistik og fordeling af beslutningstagning, antallet af fald fra brugere er obligatorisk for din afslappende søvn og produktive weekend.

Nå, jeg håber, at dette hjælper dig med at forbedre dine ML-systemer hurtigere, få dem til at markedsføre hurtigere og gøre dem mere pålidelige og mindre stressende.

Kilde: www.habr.com