Drift av maskinlæring i Mail.ru Mail

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

For mange i dag er post en integrert del av livet på nett. Med dens hjelp driver vi forretningskorrespondanse, lagrer all slags viktig informasjon knyttet til økonomi, hotellbestillinger, bestilling og mye mer. I midten av 2018 formulerte vi en produktstrategi for postutvikling. Hvordan skal moderne post være?

Mail må være smart, det vil si å hjelpe brukere med å navigere i det økende volumet av informasjon: filtrere, strukturere og gi det på den mest praktiske måten. Det må hun være nyttig, slik at du kan løse ulike oppgaver rett i postkassen din, for eksempel betale bøter (en funksjon som jeg dessverre bruker). Og samtidig skal selvfølgelig post gi informasjonsbeskyttelse, kutte av spam og beskytte mot hacking, det vil si være sikker.

Disse områdene definerer en rekke nøkkelproblemer, hvorav mange kan løses effektivt ved hjelp av maskinlæring. Her er eksempler på allerede eksisterende funksjoner utviklet som en del av strategien – en for hver retning.

• Smart svar. Mail har en smart svarfunksjon. Det nevrale nettverket analyserer teksten i brevet, forstår dens betydning og formål, og tilbyr som et resultat de tre mest passende svaralternativene: positiv, negativ og nøytral. Dette bidrar til å spare tid betydelig når du svarer på brev, og svarer ofte på en ikke-standardisert og morsom måte.
• Gruppering av e-posterknyttet til bestillinger i nettbutikker. Vi handler ofte på nett, og som regel kan butikker sende flere e-poster for hver bestilling. For eksempel, fra AliExpress, den største tjenesten, kommer det inn mange brev for én bestilling, og vi beregnet at i terminaltilfellet kan antallet komme opp til 29. Derfor trekker vi ut ordrenummeret ved å bruke modellen for navngitt enhetsgjenkjenning. og annen informasjon fra teksten og grupper alle bokstaver i én tråd. Vi viser også grunnleggende informasjon om bestillingen i en egen boks, noe som gjør det enklere å jobbe med denne typen e-post.

  

• Anti-phishing. Phishing er en spesielt farlig svindeltype, ved hjelp av hvilken angripere prøver å få tak i økonomisk informasjon (inkludert brukerens bankkort) og pålogginger. Slike brev etterligner ekte brev sendt av tjenesten, inkludert visuelt. Derfor, ved hjelp av Computer Vision, gjenkjenner vi logoer og designstilen til brev fra store selskaper (for eksempel Mail.ru, Sber, Alfa) og tar hensyn til dette sammen med tekst og andre funksjoner i våre spam- og phishing-klassifiseringer .

Maskinlæring

Litt om maskinlæring i e-post generelt. Mail er et svært belastet system: et gjennomsnitt på 1,5 milliarder brev per dag passerer gjennom serverne våre for 30 millioner DAU-brukere. Omtrent 30 maskinlæringssystemer støtter alle nødvendige funksjoner og funksjoner.

Hver bokstav går gjennom en hel klassifiseringspipeline. Først kutter vi spam og legger igjen gode e-poster. Brukere legger ofte ikke merke til arbeidet med antispam, fordi 95-99% av spam ikke engang havner i den aktuelle mappen. Spamgjenkjenning er en svært viktig del av systemet vårt, og det vanskeligste, siden det innen anti-spam er en konstant tilpasning mellom forsvars- og angrepssystemer, noe som gir en kontinuerlig teknisk utfordring for teamet vårt.

Deretter skiller vi brev fra mennesker og roboter. E-poster fra folk er det viktigste, så vi tilbyr funksjoner som Smart Reply for dem. Brev fra roboter er delt inn i to deler: transaksjonelle - dette er viktige brev fra tjenester, for eksempel bekreftelser på kjøp eller hotellreservasjoner, økonomi og informasjon - dette er bedriftsreklame, rabatter.

Vi mener at transaksjonelle e-poster er like viktige som personlig korrespondanse. De bør være for hånden, fordi vi ofte trenger raskt å finne informasjon om en bestilling eller flybillettreservasjon, og vi bruker tid på å søke etter disse bokstavene. Derfor deler vi dem automatisk inn i seks hovedkategorier for enkelhets skyld: reiser, bestillinger, økonomi, billetter, registreringer og til slutt bøter.

Informasjonsbrev er den største og sannsynligvis mindre viktige gruppen, som ikke krever umiddelbar respons, siden ingenting vesentlig vil endre seg i brukerens liv hvis han ikke leser et slikt brev. I vårt nye grensesnitt kollapser vi dem i to tråder: sosiale nettverk og nyhetsbrev, slik at vi visuelt tømmer innboksen og lar bare viktige meldinger være synlige.

Utnyttelse

Et stort antall systemer forårsaker mange vanskeligheter i drift. Tross alt forringes modeller over tid, som all programvare: funksjoner går i stykker, maskiner svikter, koden blir skjev. I tillegg er data i stadig endring: nye legges til, brukeradferdsmønstre transformeres osv., så en modell uten skikkelig støtte vil fungere dårligere og dårligere over tid.

Vi må ikke glemme at jo dypere maskinlæring trenger inn i brukernes liv, jo større innvirkning har de på økosystemet, og som et resultat, jo mer økonomiske tap eller fortjeneste kan markedsaktører motta. Derfor, på et økende antall områder, tilpasser spillere seg til arbeidet med ML-algoritmer (klassiske eksempler er reklame, søk og den allerede nevnte antispam).

Maskinlæringsoppgaver har også en særegenhet: Enhver, selv mindre, endring i systemet kan generere mye arbeid med modellen: arbeid med data, omskolering, distribusjon, som kan ta uker eller måneder. Derfor, jo raskere miljøet som modellene dine fungerer i, endres, jo mer innsats krever det å vedlikeholde dem. Et team kan lage mange systemer og være glade for det, men så bruke nesten alle ressursene sine på å vedlikeholde dem, uten mulighet til å gjøre noe nytt. Vi har en gang møtt en slik situasjon i antispam-teamet. Og de kom med den åpenbare konklusjonen at støtte må automatiseres.

Automatisering

Hva kan automatiseres? Nesten alt, faktisk. Jeg har identifisert fire områder som definerer maskinlæringsinfrastrukturen:

• datainnsamling;
• tilleggstrening;
• utplassere;
• testing og overvåking.

Hvis miljøet er ustabilt og i stadig endring, så viser hele infrastrukturen rundt modellen seg å være mye viktigere enn selve modellen. Det kan være en god gammel lineær klassifiserer, men hvis du mater den med de riktige funksjonene og får gode tilbakemeldinger fra brukerne, vil den fungere mye bedre enn State-Of-The-Art-modeller med alle klokkene og fløyter.

Feedback loop

Denne syklusen kombinerer datainnsamling, tilleggstrening og distribusjon – faktisk hele modelloppdateringssyklusen. Hvorfor er det viktig? Se påmeldingsplanen i posten:

En maskinlæringsutvikler har implementert en anti-bot-modell som hindrer roboter i å registrere seg i e-post. Grafen synker til en verdi der bare reelle brukere er igjen. Alt er flott! Men det går fire timer, robotene justerer skriptene sine, og alt går tilbake til det normale. I denne implementeringen brukte utvikleren en måned på å legge til funksjoner og omskole modellen, men spammeren var i stand til å tilpasse seg på fire timer.

For ikke å være så uhyggelig vondt og slippe å gjøre om alt senere, må vi i utgangspunktet tenke på hvordan tilbakemeldingssløyfen vil se ut og hva vi skal gjøre hvis omgivelsene endres. La oss begynne med å samle inn data - dette er drivstoffet for algoritmene våre.

Datainnsamling

Det er klart at for moderne nevrale nettverk, jo mer data, jo bedre, og de genereres faktisk av brukere av produktet. Brukere kan hjelpe oss ved å merke data, men vi kan ikke misbruke dette, fordi brukere på et tidspunkt blir lei av å fullføre modellene dine og vil bytte til et annet produkt.

En av de vanligste feilene (her viser jeg til Andrew Ng) er for mye fokus på metrikk på testdatasettet, og ikke på tilbakemeldinger fra brukeren, som faktisk er hovedmålet på kvaliteten på arbeidet, siden vi lager et produkt for brukeren. Hvis brukeren ikke forstår eller ikke liker arbeidet med modellen, er alt ødelagt.

Derfor skal brukeren alltid kunne stemme og skal få et verktøy for tilbakemelding. Hvis vi tror at det har kommet et brev relatert til økonomi i postkassen, må vi merke det som «finans» og tegne en knapp som brukeren kan klikke på og si at dette ikke er økonomi.

Tilbakemeldingskvalitet

La oss snakke om kvaliteten på tilbakemeldinger fra brukere. For det første kan du og brukeren sette ulike betydninger i ett konsept. For eksempel tror du og dine produktsjefer at «økonomi» betyr brev fra banken, og brukeren tror at et brev fra bestemor om hennes pensjon også refererer til økonomi. For det andre er det brukere som tankeløst elsker å trykke på knapper uten logikk. For det tredje kan brukeren ta dypt feil i sine konklusjoner. Et slående eksempel fra vår praksis er implementeringen av en klassifiserer nigeriansk spam, en veldig morsom type spam der brukeren blir bedt om å ta flere millioner dollar fra en plutselig funnet fjern slektning i Afrika. Etter å ha implementert denne klassifiseringen, sjekket vi «Ikke spam»-klikkene på disse e-postene, og det viste seg at 80 % av dem var saftig nigeriansk spam, noe som tyder på at brukere kan være ekstremt godtroende.

Og la oss ikke glemme at knappene ikke bare kan klikkes av folk, men også av alle slags roboter som utgir seg for å være en nettleser. Så rå tilbakemelding er ikke bra for læring. Hva kan du gjøre med denne informasjonen?

Vi bruker to tilnærminger:

• Tilbakemelding fra koblet ML. For eksempel har vi et online anti-bot-system, som, som jeg nevnte, tar en rask avgjørelse basert på et begrenset antall tegn. Og det er et annet, tregt system som fungerer etterpå. Den har mer data om brukeren, hans oppførsel osv. Som et resultat blir den mest informerte beslutningen tatt; følgelig har den høyere nøyaktighet og fullstendighet. Du kan rette forskjellen i driften av disse systemene til det første som treningsdata. Dermed vil et enklere system alltid prøve å nærme seg ytelsen til et mer komplekst.
• Klikk klassifisering. Du kan ganske enkelt klassifisere hvert brukerklikk, evaluere gyldigheten og brukervennligheten. Vi gjør dette i antispam-e-post, ved å bruke brukerattributter, hans historie, avsenderattributter, selve teksten og resultatet av klassifisere. Som et resultat får vi et automatisk system som validerer brukertilbakemeldinger. Og siden det må omskoleres mye sjeldnere, kan dets arbeid bli grunnlaget for alle andre systemer. Hovedprioriteten i denne modellen er presisjon, fordi trening av modellen på unøyaktige data er full av konsekvenser.

Mens vi renser dataene og videreutdanner ML-systemene våre, må vi ikke glemme brukerne, for for oss er tusenvis, millioner av feil på grafen statistikk, og for brukeren er hver feil en tragedie. I tillegg til at brukeren på en eller annen måte må leve med feilen din i produktet, forventer han etter å ha mottatt tilbakemelding at en lignende situasjon vil bli eliminert i fremtiden. Derfor er det alltid verdt å gi brukerne ikke bare muligheten til å stemme, men også å korrigere oppførselen til ML-systemer, for eksempel lage personlige heuristikk for hvert tilbakemeldingsklikk; i tilfelle e-post kan dette være muligheten til å filtrere slike brev etter avsender og tittel for denne brukeren.

Du må også bygge en modell basert på noen rapporter eller forespørsler om å støtte i en halvautomatisk eller manuell modus, slik at andre brukere ikke lider av lignende problemer.

Heuristikk for læring

Det er to problemer med disse heuristikkene og krykkene. Den første er at det stadig økende antallet krykker er vanskelig å vedlikeholde, enn si kvaliteten og ytelsen på lang sikt. Det andre problemet er at feilen kanskje ikke er hyppig, og noen få klikk for å trene modellen videre vil ikke være nok. Det ser ut til at disse to ikke-relaterte effektene kan bli betydelig nøytralisert hvis følgende tilnærming brukes.

1. Vi lager en midlertidig krykke.
2. Vi sender data fra den til modellen, den oppdaterer seg regelmessig, inkludert de mottatte dataene. Her er det selvsagt viktig at heuristikkene har høy nøyaktighet for ikke å redusere kvaliteten på dataene i treningssettet.
3. Deretter setter vi overvåkingen til å utløse krykken, og hvis krykken etter en tid ikke lenger fungerer og er fullstendig dekket av modellen, kan du trygt fjerne den. Nå vil dette problemet neppe skje igjen.

Så en hær av krykker er veldig nyttig. Hovedsaken er at tjenesten deres haster og ikke permanent.

Tilleggstrening

Omskolering er prosessen med å legge til nye data innhentet som et resultat av tilbakemeldinger fra brukere eller andre systemer, og trene en eksisterende modell på det. Det kan være flere problemer med tilleggsopplæring:

1. Modellen støtter kanskje rett og slett ikke tilleggstrening, men lærer bare fra bunnen av.
2. Ingen steder i naturens bok står det skrevet at tilleggsopplæring helt sikkert vil forbedre kvaliteten på arbeidet i produksjonen. Ofte skjer det motsatte, det vil si at bare forverring er mulig.
3. Endringer kan være uforutsigbare. Dette er et ganske subtilt poeng som vi har identifisert for oss selv. Selv om en ny modell i en A/B-test viser lignende resultater sammenlignet med den nåværende, betyr ikke dette at den vil fungere identisk. Arbeidet deres kan variere på bare én prosent, noe som kan føre til nye feil eller returnere gamle som allerede er rettet. Både vi og brukerne vet allerede hvordan de skal leve med aktuelle feil, og når det oppstår et stort antall nye feil kan det hende at brukeren heller ikke forstår hva som skjer, fordi han forventer forutsigbar atferd.

Derfor er det viktigste ved tilleggstrening å sørge for at modellen blir forbedret, eller i hvert fall ikke forverret.

Det første du tenker på når vi snakker om tilleggstrening er tilnærmingen til aktiv læring. Hva betyr dette? Klassifisereren bestemmer for eksempel om en e-post er relatert til økonomi, og rundt beslutningsgrensen legger vi til et utvalg merkede eksempler. Dette fungerer bra for eksempel i reklame, hvor det er mange tilbakemeldinger og man kan trene modellen på nett. Og hvis det er lite tilbakemelding, får vi et sterkt partisk utvalg i forhold til produksjonsdatafordelingen, på grunnlag av hvilket det er umulig å evaluere oppførselen til modellen under drift.

Faktisk er målet vårt å bevare gamle mønstre, allerede kjente modeller, og skaffe nye. Kontinuitet er viktig her. Modellen, som vi ofte gjorde store anstrengelser for å rulle ut, fungerer allerede, så vi kan fokusere på ytelsen.

Ulike modeller brukes i post: trær, lineære, nevrale nettverk. For hver lager vi vår egen ekstra treningsalgoritme. I prosessen med ytterligere opplæring mottar vi ikke bare nye data, men også ofte nye funksjoner, som vi vil ta hensyn til i alle algoritmene nedenfor.

Lineære modeller

La oss si at vi har logistisk regresjon. Vi lager en tapsmodell fra følgende komponenter:

• Loggtap på nye data;
• vi regulerer vekten av nye funksjoner (vi berører ikke de gamle);
• vi lærer også av gamle data for å bevare gamle mønstre;
• og kanskje det viktigste: vi legger til Harmonic Regularization, som garanterer at vektene ikke vil endre seg mye i forhold til den gamle modellen i henhold til normen.

Siden hver tapskomponent har koeffisienter, kan vi velge de optimale verdiene for oppgaven vår gjennom kryssvalidering eller basert på produktkrav.

Деревья

La oss gå videre til beslutningstrær. Vi har satt sammen følgende algoritme for tilleggstrening av trær:

1. Produksjonen driver en skog på 100-300 trær, som er trent på et gammelt datasett.
2. På slutten fjerner vi M = 5 stykker og legger til 2M = 10 nye, trent på hele datasettet, men med høy vekt for de nye dataene, noe som naturligvis garanterer en inkrementell endring i modellen.

Det er klart at antallet trær over tid øker kraftig, og de må med jevne mellomrom reduseres for å overholde tidspunktene. For å gjøre dette bruker vi den nå allestedsnærværende Knowledge Destillation (KD). Kort om prinsippet for driften.

1. Vi har den nåværende "komplekse" modellen. Vi kjører det på treningsdatasettet og får klassesannsynlighetsfordelingen ved utgangen.
2. Deretter trener vi elevmodellen (modellen med færre trær i dette tilfellet) til å gjenta modellens resultater ved å bruke klassefordelingen som målvariabel.
3. Det er viktig å merke seg her at vi ikke bruker datasettmarkeringen på noen måte, og derfor kan vi bruke vilkårlige data. Vi bruker selvfølgelig en dataprøve fra kampstrømmen som treningsprøve for elevmodellen. Dermed lar treningssettet oss sikre nøyaktigheten til modellen, og strømprøven garanterer en lignende ytelse på produksjonsdistribusjonen, og kompenserer for skjevheten til treningssettet.

Kombinasjonen av disse to teknikkene (å legge til trær og med jevne mellomrom redusere antallet ved hjelp av Knowledge Destillation) sikrer introduksjon av nye mønstre og fullstendig kontinuitet.

Ved hjelp av KD utfører vi også ulike operasjoner på modellfunksjoner, som å fjerne funksjoner og arbeide med hull. I vårt tilfelle har vi en rekke viktige statistiske funksjoner (av avsendere, teksthasher, URL-er osv.) som er lagret i databasen, som har en tendens til å mislykkes. Modellen er selvfølgelig ikke klar for en slik utvikling av hendelser, siden feilsituasjoner ikke oppstår i treningssettet. I slike tilfeller kombinerer vi KD- og utvidelsesteknikker: når vi trener for en del av dataene, fjerner eller tilbakestiller vi de nødvendige funksjonene, og vi tar de originale etikettene (utdata fra gjeldende modell), og studentmodellen lærer å gjenta denne distribusjonen .

Vi la merke til at jo mer alvorlig modellmanipulasjon som skjer, desto større er prosentandelen av trådprøven som kreves.

Funksjonsfjerning, den enkleste operasjonen, krever bare en liten del av flyten, siden bare et par funksjoner endres, og den nåværende modellen ble trent på samme sett - forskjellen er minimal. For å forenkle modellen (redusere antall trær flere ganger), kreves det allerede 50 til 50. Og for utelatelser av viktige statistiske funksjoner som vil påvirke ytelsen til modellen alvorlig, kreves det enda mer flyt for å jevne ut arbeidet til ny unnlatelsessikker modell på alle typer brev.

Hurtigtekst

La oss gå videre til FastText. La meg minne deg på at representasjonen (Innebygging) av et ord består av summen av innebyggingen av selve ordet og alle dets bokstav N-gram, vanligvis trigram. Siden det kan være ganske mange trigrammer, brukes Bucket Hashing, det vil si å konvertere hele plassen til et bestemt fast hashmap. Som et resultat oppnås vektmatrisen med dimensjonen til det indre laget per antall ord + bøtter.

Med tilleggstrening dukker det opp nye tegn: ord og trigrammer. Det skjer ikke noe vesentlig i standard oppfølgingstrening fra Facebook. Kun gamle vekter med kryssentropi blir omskolert på nye data. Dermed brukes ikke nye funksjoner; selvfølgelig har denne tilnærmingen alle de ovenfor beskrevne ulempene forbundet med uforutsigbarheten til modellen i produksjon. Derfor modifiserte vi FastText litt. Vi legger til alle nye vekter (ord og trigrammer), utvider hele matrisen med kryssentropi og legger til harmonisk regulering i analogi med den lineære modellen, som garanterer en ubetydelig endring i de gamle vektene.

CNN

Konvolusjonelle nettverk er litt mer kompliserte. Hvis de siste lagene er fullført i CNN, så kan du selvfølgelig bruke harmonisk regularisering og garantere kontinuitet. Men hvis ytterligere opplæring av hele nettverket er nødvendig, kan slik regularisering ikke lenger brukes på alle lag. Det er imidlertid et alternativ å trene komplementære innebygginger gjennom Triplet Loss (original artikkel).

Trillingtap

Ved å bruke en anti-phishing-oppgave som eksempel, la oss se på Triplet Loss i generelle termer. Vi tar vår logo, samt positive og negative eksempler på logoer til andre selskaper. Vi minimerer avstanden mellom den første og maksimerer avstanden mellom den andre, vi gjør dette med et lite gap for å sikre større kompakthet i klassene.

Hvis vi trener nettverket videre, endres vårt metriske rom fullstendig, og det blir helt uforenlig med det forrige. Dette er et alvorlig problem i problemer som bruker vektorer. For å komme rundt dette problemet vil vi blande inn gamle innstøpinger under trening.

Vi har lagt til nye data til treningssettet og trener opp den andre versjonen av modellen fra bunnen av. På andre trinn videreutdanner vi nettverket vårt (Finetuning): først er det siste laget ferdig, og deretter fryses hele nettverket opp. I prosessen med å komponere trillinger, beregner vi bare en del av innbyggingene ved å bruke den trente modellen, resten - ved å bruke den gamle. I prosessen med tilleggsopplæring sikrer vi derfor kompatibiliteten til metriske rom v1 og v2. En unik versjon av harmonisk regularisering.

Hele arkitekturen

Hvis vi ser på hele systemet som bruker antispam som et eksempel, er modellene ikke isolert, men nestet i hverandre. Vi tar bilder, tekst og andre funksjoner, ved å bruke CNN og Fast Text får vi innbygginger. Deretter brukes klassifiserere på toppen av innebyggingene, som gir poengsum for ulike klasser (typer av brev, spam, tilstedeværelse av en logo). Signalene og skiltene går allerede inn i skogen av trær for den endelige avgjørelsen skal tas. Individuelle klassifikatorer i denne ordningen gjør det mulig å bedre tolke resultatene av systemet og mer spesifikt omskolere komponenter i tilfelle problemer, i stedet for å mate alle data inn i beslutningstrær i en rå form.

Som et resultat garanterer vi kontinuitet på alle nivåer. På bunnnivået i CNN og Fast Text bruker vi harmonisk regularisering, for klassifikatorene i midten bruker vi også harmonisk regularisering og ratekalibrering for konsistens av sannsynlighetsfordelingen. Vel, treforsterkning trenes trinnvis eller ved hjelp av kunnskapsdestillasjon.

Generelt er det vanligvis vanskelig å opprettholde et slikt nestet maskinlæringssystem, siden enhver komponent på lavere nivå fører til en oppdatering av hele systemet ovenfor. Men siden i oppsettet vårt endres hver komponent litt og er kompatibel med den forrige, kan hele systemet oppdateres stykke for stykke uten behov for å trene opp hele strukturen, noe som gjør at det kan støttes uten alvorlige overhead.

Utplassere

Vi har diskutert datainnsamling og tilleggstrening av ulike typer modeller, så vi går videre til distribusjon av dem i produksjonsmiljøet.

A/B-testing

Som jeg sa tidligere, i prosessen med å samle inn data, får vi vanligvis et partisk utvalg, hvorfra det er umulig å evaluere produksjonsytelsen til modellen. Derfor må modellen ved utplassering sammenlignes med forrige versjon for å forstå hvordan ting faktisk går, det vil si gjennomføre A/B-tester. Faktisk er prosessen med å rulle ut og analysere diagrammer ganske rutinemessig og kan enkelt automatiseres. Vi ruller ut modellene våre gradvis til 5 %, 30 %, 50 % og 100 % av brukerne, mens vi samler inn alle tilgjengelige beregninger for modellsvar og brukertilbakemeldinger. Ved noen alvorlige uteliggere ruller vi automatisk tilbake modellen, og for andre tilfeller, etter å ha samlet et tilstrekkelig antall brukerklikk, bestemmer vi oss for å øke prosentandelen. Som et resultat bringer vi den nye modellen til 50 % av brukerne helt automatisk, og utrullingen til hele publikum vil bli godkjent av en person, selv om dette trinnet kan automatiseres.

A/B-testprosessen gir imidlertid rom for optimalisering. Faktum er at enhver A/B-test er ganske lang (i vårt tilfelle tar den fra 6 til 24 timer avhengig av mengden tilbakemelding), noe som gjør den ganske dyr og med begrensede ressurser. I tillegg kreves det en tilstrekkelig høy prosentandel av flyt for testen for å i det vesentlige øke hastigheten på den totale tiden for A/B-testen (å rekruttere en statistisk signifikant prøve for å evaluere beregninger med en liten prosentandel kan ta svært lang tid), noe som gjør antall A/B-spor ekstremt begrenset. Det er klart at vi bare trenger å teste de mest lovende modellene, som vi får ganske mye av under den ekstra opplæringsprosessen.

For å løse dette problemet trente vi opp en egen klassifiserer som forutsier suksessen til en A/B-test. For å gjøre dette tar vi beslutningsstatistikk, presisjon, tilbakekalling og andre beregninger på treningssettet, på det utsatte og på prøven fra strømmen som funksjoner. Vi sammenligner også modellen med den nåværende i produksjon, med heuristikk, og tar hensyn til modellens kompleksitet. Ved å bruke alle disse funksjonene, evaluerer en klassifikator som er trent på testhistorie kandidatmodeller, i vårt tilfelle er disse skoger av trær, og bestemmer hvilken som skal brukes i A/B-testen.

På tidspunktet for implementering tillot denne tilnærmingen oss å øke antallet vellykkede A/B-tester flere ganger.

Testing og overvåking

Testing og overvåking skader merkelig nok ikke helsen vår, men tvert imot forbedrer de den og avlaster oss for unødvendig stress. Testing lar deg forhindre en feil, og overvåking lar deg oppdage det i tide for å redusere innvirkningen på brukerne.

Det er viktig å forstå her at før eller siden vil systemet ditt alltid gjøre feil - dette er på grunn av utviklingssyklusen til enhver programvare. I begynnelsen av systemutvikling er det alltid mange feil inntil alt ordner seg og hovedstadiet av innovasjon er fullført. Men over tid tar entropi sitt toll, og feil dukker opp igjen - på grunn av nedbrytning av komponenter rundt og endringer i data, som jeg snakket om i begynnelsen.

Her vil jeg bemerke at ethvert maskinlæringssystem bør vurderes ut fra dets fortjeneste gjennom hele livssyklusen. Grafen nedenfor viser et eksempel på hvordan systemet fungerer for å fange en sjelden type spam (linjen i grafen er nær null). En dag, på grunn av en feil bufret attributt, ble hun gal. Heldigvis var det ingen overvåking for unormal utløsning; som et resultat begynte systemet å lagre brev i store mengder til "spam"-mappen ved beslutningsgrensen. Til tross for å korrigere konsekvensene, har systemet allerede gjort feil så mange ganger at det ikke vil betale seg selv om fem år. Og dette er en fullstendig fiasko med tanke på modellens livssyklus.

Derfor kan en så enkel ting som overvåking bli nøkkelen i livet til en modell. I tillegg til standard og åpenbare beregninger, vurderer vi fordelingen av modellresponser og -skårer, samt fordelingen av nøkkelfunksjonsverdier. Ved å bruke KL-divergens kan vi sammenligne den nåværende distribusjonen med den historiske eller verdiene i A/B-testen med resten av strømmen, noe som lar oss legge merke til anomalier i modellen og rulle tilbake endringer i tide.

I de fleste tilfeller lanserer vi våre første versjoner av systemer ved hjelp av enkle heuristikk eller modeller som vi bruker som overvåking i fremtiden. For eksempel overvåker vi NER-modellen sammenlignet med de vanlige for spesifikke nettbutikker, og hvis klassifiseringsdekningen faller i forhold til dem, forstår vi årsakene. Nok en nyttig bruk av heuristikk!

Resultater av

La oss gå gjennom hovedideene i artikkelen igjen.

• Fibdeck. Vi tenker alltid på brukeren: hvordan han vil leve med våre feil, hvordan han vil kunne rapportere dem. Ikke glem at brukere ikke er en kilde til ren tilbakemelding for treningsmodeller, og den må fjernes ved hjelp av ML-tilleggssystemer. Hvis det ikke er mulig å samle inn et signal fra brukeren, ser vi etter alternative kilder for tilbakemelding, for eksempel tilkoblede systemer.
• Tilleggstrening. Hovedsaken her er kontinuitet, så vi stoler på dagens produksjonsmodell. Vi trener nye modeller slik at de ikke skiller seg mye fra den forrige på grunn av harmonisk regularisering og lignende triks.
• Utplassere. Automatisk distribusjon basert på beregninger reduserer tiden for implementering av modeller betraktelig. Overvåking av statistikk og distribusjon av beslutningstaking, antall fall fra brukere er obligatorisk for din avslappende søvn og produktive helg.

Vel, jeg håper dette hjelper deg med å forbedre ML-systemene dine raskere, få dem ut på markedet raskere og gjøre dem mer pålitelige og mindre stressende.

Kilde: www.habr.com