A gépi tanulás működése a Mail.ru Mailben

A Highload++ és DataFest Minsk 2019 rendezvényen elhangzott beszédeim alapján.

Manapság sokak számára a levelezés az online élet szerves része. Segítségével üzleti levelezést folytatunk, mindenféle pénzügyekkel, szállásfoglalással, rendelés leadásával és sok mással kapcsolatos fontos információt tárolunk. 2018 közepén termékstratégiát dolgoztunk ki a levelezés fejlesztésére. Milyen legyen a modern posta?

A levélnek lennie kell Okos, vagyis segít a felhasználóknak eligazodni a növekvő mennyiségű információ között: szűrni, strukturálni és a legkényelmesebb módon biztosítani. Biztosan az hasznos, amely lehetővé teszi, hogy különféle feladatokat oldjon meg közvetlenül a postafiókjában, például bírságot fizessen ki (ezt a funkciót sajnos használom). És ugyanakkor természetesen a levélnek információvédelmet kell nyújtania, le kell vágnia a spameket és meg kell védenie a hackeléstől, azaz biztonságos.

Ezek a területek számos kulcsproblémát határoznak meg, amelyek közül sok hatékonyan megoldható gépi tanulással. Íme példák a stratégia részeként kifejlesztett, már meglévő funkciókra – minden irányhoz egyet.

• Intelligens válasz. A Mail intelligens válasz funkcióval rendelkezik. A neurális hálózat elemzi a levél szövegét, megérti annak jelentését és célját, és ennek eredményeként a három legmegfelelőbb válaszlehetőséget kínálja: pozitív, negatív és semleges. Ez jelentősen megtakarítja az időt a levelek megválaszolásakor, és gyakran nem szabványos és vicces módon válaszol.
• E-mailek csoportosításaonline áruházak rendeléseivel kapcsolatos. Gyakran online vásárolunk, és az üzletek általában több e-mailt is küldhetnek minden egyes rendelésről. Például az AliExpresstől, a legnagyobb szolgáltatástól sok levél érkezik egy rendelésre, és úgy számoltuk, hogy terminál esetben ezek száma elérheti a 29-et is. Ezért a Named Entity Recognition modell segítségével kivonjuk a rendelés számát és egyéb információkat a szövegből, és csoportosítsa az összes betűt egy szálba. A megrendeléssel kapcsolatos alapvető információkat is külön dobozban jelenítjük meg, ami megkönnyíti az ilyen típusú e-mailekkel való munkát.

  

• Antiphishing. Az adathalászat egy különösen veszélyes csalárd típusú e-mail, amelynek segítségével a támadók pénzügyi információkat (beleértve a felhasználó bankkártyáit is) és bejelentkezési adatokat próbálnak megszerezni. Az ilyen levelek a szolgáltatás által küldött valódi leveleket utánozzák, beleértve a vizuálisan is. Ezért a Computer Vision segítségével felismerjük a nagyvállalatok (például Mail.ru, Sber, Alfa) logóit és a levelek tervezési stílusát, és ezt a szöveggel és egyéb jellemzőkkel együtt figyelembe vesszük spam- és adathalász-osztályozóinkban. .

Gépi tanulás

Egy kicsit a gépi tanulásról az e-mailben általában. A Mail nagyon terhelt rendszer: átlagosan napi 1,5 milliárd levél halad át szervereinken 30 millió DAU felhasználó számára. Körülbelül 30 gépi tanulási rendszer támogatja az összes szükséges funkciót és szolgáltatást.

Minden betű egy teljes osztályozási folyamaton megy keresztül. Először levágjuk a spamet, és jó e-maileket hagyunk. A felhasználók gyakran nem veszik észre a levélszemét-szűrő munkáját, mert a spamek 95-99%-a nem is a megfelelő mappába kerül. A spamfelismerés nagyon fontos része rendszerünknek, és a legnehezebb is, hiszen a levélszemét-elhárítás területén folyamatos az alkalmazkodás a védelmi és támadórendszerek között, ami folyamatos mérnöki kihívást jelent csapatunk számára.

Ezután elválasztjuk a leveleket az emberektől és a robotoktól. Az emberektől érkező e-mailek a legfontosabbak, ezért olyan funkciókat biztosítunk számukra, mint az Intelligens válasz. A robotoktól származó levelek két részre oszlanak: tranzakciós - ezek fontos levelek a szolgáltatásoktól, például a vásárlások vagy szállodafoglalások visszaigazolásai, a pénzügyek és az információs - ezek üzleti hirdetések, kedvezmények.

Meggyőződésünk, hogy a tranzakciós e-mailek ugyanolyan fontosak, mint a személyes levelezés. Kéznél kell lenniük, mert gyakran gyorsan kell információt találnunk egy megrendeléssel vagy repülőjegy-foglalással kapcsolatban, és időt töltünk ezeknek a leveleknek a keresésével. Ezért a kényelem kedvéért automatikusan hat fő kategóriába soroljuk őket: utazások, rendelések, pénzügyek, jegyek, regisztrációk és végül bírságok.

A tájékoztató levelek a legnagyobb és valószínűleg kevésbé fontos csoport, amely nem igényel azonnali választ, hiszen a felhasználó életében semmi lényeges nem változik, ha nem olvassa el az ilyen levelet. Az új felületünkön ezeket két szálra bontjuk: közösségi hálózatokra és hírlevelekre, így vizuálisan kiürítjük a beérkező leveleket, és csak a fontos üzeneteket hagyjuk láthatóvá.

kizsákmányolás

A rendszerek nagy száma sok nehézséget okoz a működésben. Végül is a modellek idővel leépülnek, mint minden szoftver: a funkciók megszakadnak, a gépek meghibásodnak, a kód elferdül. Ráadásul az adatok folyamatosan változnak: újak kerülnek be, a felhasználói viselkedésminták átalakulnak stb., így a megfelelő támogatás nélküli modell idővel egyre rosszabbul fog működni.

Nem szabad megfeledkeznünk arról, hogy minél mélyebben hatol be a gépi tanulás a felhasználók életébe, annál nagyobb hatást gyakorolnak az ökoszisztémára, és ennek eredményeként a piaci szereplők annál több pénzügyi veszteséget vagy profitot érhetnek el. Ezért egyre több területen alkalmazkodnak a játékosok az ML-algoritmusok munkájához (klasszikus példa a reklám, a keresés és a már említett antispam).

A gépi tanulási feladatoknak is van egy sajátossága: bármilyen, akár kisebb rendszerváltozás is rengeteg munkát generálhat a modellel: adatokkal való munka, átképzés, telepítés, ami hetekig, hónapokig is eltarthat. Ezért minél gyorsabban változik a környezet, amelyben a modellek működnek, annál több erőfeszítést igényel a karbantartásuk. Egy csapat sok rendszert létrehozhat és örülhet ennek, de aztán szinte minden erőforrását ezek karbantartására fordítja, anélkül, hogy bármi újat csinálna. Egyszer találkoztunk ilyen helyzettel a levélszemét-elhárító csapatban. És arra a nyilvánvaló következtetésre jutottak, hogy a támogatást automatizálni kell.

automatizálás

Mit lehet automatizálni? Tulajdonképpen szinte mindent. Négy területet azonosítottam, amelyek meghatározzák a gépi tanulási infrastruktúrát:

• adatgyűjtés;
• kiegészítő képzés;
• telepíteni;
• tesztelés és ellenőrzés.

Ha a környezet instabil és folyamatosan változik, akkor a modell körüli teljes infrastruktúra sokkal fontosabbnak bizonyul, mint maga a modell. Lehet, hogy ez egy jó öreg lineáris osztályozó, de ha a megfelelő tulajdonságokkal táplálja, és jó visszajelzéseket kap a felhasználóktól, sokkal jobban fog működni, mint a legkorszerűbb modellek minden csengővel és síppal.

Visszacsatolás

Ez a ciklus egyesíti az adatgyűjtést, a további képzést és a telepítést – valójában a teljes modellfrissítési ciklust. Miért fontos? Nézze meg a jelentkezési ütemtervet e-mailben:

Egy gépi tanulást fejlesztő fejlesztő bevezetett egy anti-bot modellt, amely megakadályozza, hogy a robotok regisztráljanak e-mailben. A grafikon egy olyan értékre csökken, ahol csak a valódi felhasználók maradnak. Minden nagyszerű! De eltelik négy óra, a botok megcsipkednek a forgatókönyveiken, és minden visszatér a normális kerékvágásba. Ebben a megvalósításban a fejlesztő egy hónapot töltött a funkciók hozzáadásával és a modell átképzésével, de a spammer négy óra alatt tudott alkalmazkodni.

Annak érdekében, hogy ne legyünk olyan elviselhetetlenül fájdalmasak, és ne kelljen később mindent újracsinálnunk, kezdetben el kell gondolkodnunk azon, hogy milyen lesz a visszacsatolási kör, és mit fogunk tenni, ha megváltozik a környezet. Kezdjük az adatgyűjtéssel – ez az üzemanyag az algoritmusainkhoz.

Adatgyűjtés

Nyilvánvaló, hogy a modern neurális hálózatok esetében minél több adat, annál jobb, és azokat valójában a termék felhasználói generálják. A felhasználók segíthetnek nekünk az adatok megjelölésével, de ezzel nem élhetünk vissza, mert a felhasználók egy bizonyos ponton belefáradnak a modellek kiegészítésébe, és átváltanak egy másik termékre.

Az egyik leggyakoribb hiba (itt Andrew Ng-re hivatkozom) az, hogy túlságosan a tesztadatkészlet mérőszámaira koncentrálunk, és nem a felhasználó visszajelzésére, ami tulajdonképpen a munka minőségének fő mérőszáma, mivel mi hozunk létre termék a felhasználó számára. Ha a felhasználó nem érti vagy nem szereti a modell munkáját, akkor minden tönkremegy.

Ezért a felhasználónak mindig szavazni kell, és visszajelzési eszközt kell kapnia. Ha úgy gondoljuk, hogy pénzügyekkel kapcsolatos levél érkezett a postaládába, akkor azt „pénzügy” jelöléssel kell ellátni, és rá kell húzni egy gombot, amelyre kattintva a felhasználó azt mondhatja, hogy ez nem pénzügy.

Visszajelzés minősége

Beszéljünk a felhasználói visszajelzések minőségéről. Először is, Ön és a felhasználó különböző jelentéseket helyezhet el egy fogalomban. Például Ön és termékmenedzserei azt gondolják, hogy a „pénzügy” a bank leveleit jelenti, a felhasználó pedig úgy gondolja, hogy a nagymama nyugdíjáról szóló levele is pénzügyekre vonatkozik. Másodszor, vannak olyan felhasználók, akik esztelenül szeretnek minden logika nélkül nyomkodni a gombokat. Harmadszor, a felhasználó mélyen tévedhet következtetéseiben. Gyakorlatunkból szembetűnő példa egy osztályozó megvalósítása Nigériai spam, egy nagyon vicces típusú spam, ahol a felhasználót arra kérik, hogy vegyen el több millió dollárt egy hirtelen talált távoli rokonától Afrikában. Az osztályozó bevezetése után ellenőriztük a „Nem Spam” kattintásokat ezeken az e-maileken, és kiderült, hogy ezek 80%-a szaftos nigériai spam volt, ami arra utal, hogy a felhasználók rendkívül hiszékenyek lehetnek.

És ne felejtsük el, hogy a gombokra nem csak emberek kattinthatnak, hanem mindenféle, böngészőnek kiállító bot is. Tehát a nyers visszajelzés nem tesz jót a tanulásnak. Mit lehet kezdeni ezzel az információval?

Két megközelítést alkalmazunk:

• Visszajelzés a linkelt ML-től. Például van egy online anti-bot rendszerünk, ami, mint említettem, korlátozott számú jel alapján gyorsan dönt. És van egy második, lassú rendszer, amely utólag működik. Több adattal rendelkezik a felhasználóról, viselkedéséről stb. Ennek eredményeként a leginkább megalapozott döntés születik, ennek megfelelően nagyobb a pontossága és teljessége. Ezeknek a rendszereknek a működési különbségét az elsőre irányíthatja tanítási adatként. Így egy egyszerűbb rendszer mindig megpróbálja megközelíteni egy bonyolultabb rendszer teljesítményét.
• Kattintson az osztályozásra. Egyszerűen osztályozhatja az egyes felhasználói kattintásokat, értékelheti azok érvényességét és használhatóságát. Ezt a kéretlen levelekben tesszük, felhasználói attribútumok, előzmények, feladó attribútumok, maga a szöveg és az osztályozók eredményének felhasználásával. Ennek eredményeként egy automatikus rendszert kapunk, amely érvényesíti a felhasználói visszajelzéseket. És mivel sokkal ritkábban kell átképezni, munkája minden más rendszer alapjává válhat. Ebben a modellben a fő prioritás a precizitás, mivel a modell pontatlan adatokon való betanítása tele van következményekkel.

Az adatok tisztítása, ML rendszereink továbbképzése közben nem szabad megfeledkeznünk a felhasználókról sem, mert számunkra a grafikonon több ezer, millió hiba statisztika, a felhasználó számára pedig minden hiba tragédia. Amellett, hogy a felhasználónak valahogy együtt kell élnie a termék hibájával, a visszajelzések megérkezése után arra számít, hogy a hasonló helyzet a jövőben megszűnik. Ezért mindig érdemes nemcsak szavazási lehetőséget adni a felhasználóknak, hanem az ML rendszerek viselkedésének korrekcióját is, például minden visszajelzési kattintáshoz személyes heurisztikát készíteni, levél esetén ez lehet a szűrési lehetőség. az ilyen leveleket feladó és cím szerint ehhez a felhasználóhoz.

Ezenkívül létre kell hoznia egy modellt egyes jelentések vagy kérések alapján félautomata vagy kézi módban, hogy más felhasználók ne szenvedjenek hasonló problémáktól.

Heurisztika a tanuláshoz

Két probléma van ezekkel a heurisztikákkal és mankókkal. Az első az, hogy az egyre növekvő számú mankókat nehéz fenntartani, nem beszélve a minőségükről és a hosszú távú teljesítményükről. A második probléma az, hogy a hiba nem gyakori, és néhány kattintás a modell továbbképzéséhez nem lesz elég. Úgy tűnik, hogy ez a két független hatás jelentősen semlegesíthető, ha a következő megközelítést alkalmazzuk.

1. Ideiglenes mankót hozunk létre.
2. Adatokat küldünk róla a modellnek, rendszeresen frissíti magát, beleértve a kapott adatokat is. Itt természetesen fontos, hogy a heurisztikák nagy pontossággal rendelkezzenek, hogy ne rontsák a tanítókészletben található adatok minőségét.
3. Ezután beállítjuk a felügyeletet a mankó kioldására, és ha egy idő után a mankó már nem működik, és teljesen lefedi a modell, akkor nyugodtan eltávolíthatja. Most nem valószínű, hogy ez a probléma megismétlődik.

Tehát a mankók hada nagyon hasznos. A lényeg az, hogy szolgáltatásuk sürgős és nem állandó.

Kiegészítő képzés

Az átképzés a felhasználóktól vagy más rendszerektől kapott visszajelzések eredményeként kapott új adatok hozzáadásának folyamata, és egy meglévő modell betanítása. Számos probléma adódhat a kiegészítő képzéssel:

1. Lehet, hogy a modell egyszerűen nem támogatja a további képzést, de csak a semmiből tanul.
2. A természet könyvében sehol nem írják, hogy a kiegészítő képzés minden bizonnyal javítja a termelésben végzett munka minőségét. Gyakran ennek az ellenkezője történik, vagyis csak romlás lehetséges.
3. A változások kiszámíthatatlanok lehetnek. Ez egy meglehetősen finom pont, amelyet magunk azonosítottunk. Még ha egy új modell egy A/B tesztben hasonló eredményeket mutat a jelenlegihez képest, ez nem jelenti azt, hogy ugyanúgy fog működni. Munkájuk csak egy százalékban térhet el egymástól, ami új hibákat hozhat, vagy régi, már javított hibákat adhat vissza. Mind mi, mind a felhasználók már tudjuk, hogyan kell élni az aktuális hibákkal, és ha nagyszámú új hiba jelentkezik, akkor a felhasználó sem érti, mi történik, mert kiszámítható viselkedést vár el.

Ezért a kiegészítő képzésben a legfontosabb annak biztosítása, hogy a modellt javítsák, vagy legalábbis ne rontsák.

Az első dolog, ami eszünkbe jut, ha kiegészítő képzésről beszélünk, az az aktív tanulási megközelítés. Mit is jelent ez? Például az osztályozó meghatározza, hogy egy e-mail kapcsolódik-e a pénzügyekhez, és a döntési határa körül hozzáadunk egy mintát címkézett példákból. Ez jól működik például a reklámozásban, ahol sok a visszajelzés, és online lehet betanítani a modellt. Ha pedig kevés a visszacsatolás, akkor a termelési adatok eloszlásához képest erősen torzított mintát kapunk, amely alapján nem lehet értékelni a modell működése közbeni viselkedését.

Valójában a régi minták, a már ismert modellek megőrzése, újak beszerzése a célunk. Itt fontos a folytonosság. A modell, amelyet sokszor nagy fáradsággal hajtottunk végre, már működik, így a teljesítményére tudunk koncentrálni.

A levelezésben különböző modelleket használnak: fák, lineáris, neurális hálózatok. Mindegyikhez elkészítjük a saját kiegészítő edzési algoritmusunkat. A továbbképzés során nemcsak új adatokhoz jutunk, hanem gyakran új funkciókhoz is, amelyeket az alábbi algoritmusok mindegyikénél figyelembe veszünk.

Lineáris modellek

Tegyük fel, hogy logisztikus regressziónk van. A következő komponensekből veszteségmodellt készítünk:

• LogLoss új adatokon;
• rendszeresítjük az új jellemzők súlyát (a régiekhez nem nyúlunk);
• régi adatokból is tanulunk a régi minták megőrzése érdekében;
• és talán a legfontosabb: hozzáadjuk a Harmonic Regularization-t, ami garantálja, hogy a súlyok nem sokat változnak a norma szerinti régi modellhez képest.

Mivel minden veszteségkomponensnek együtthatója van, keresztellenőrzéssel vagy termékkövetelmények alapján tudjuk kiválasztani a feladatunkhoz az optimális értékeket.

fák

Térjünk át a döntési fákra. A következő algoritmust állítottuk össze a fák további betanítására:

1. A termelés egy 100-300 fás erdőt üzemeltet, amelyet egy régi adathalmazra képeznek ki.
2. A végén eltávolítjuk az M = 5 darabot és hozzáadunk 2M = 10 újat, a teljes adathalmazra betanítva, de nagy súllyal az új adatok számára, ami természetesen garantálja a modell inkrementális változását.

Nyilvánvaló, hogy az idő múlásával a fák száma nagymértékben növekszik, és időnként csökkenteni kell őket, hogy megfeleljenek az időzítéseknek. Ehhez a ma már mindenütt elterjedt tudáslepárlást (KD) használjuk. Röviden a működési elvéről.

1. Megvan a jelenlegi "komplex" modell. Futtatjuk a betanítási adathalmazon, és a kimeneten megkapjuk az osztályvalószínűségi eloszlást.
2. Ezután megtanítjuk a tanulómodellt (ebben az esetben a kevesebb fát tartalmazó modellt), hogy megismételje a modell eredményeit, célváltozóként az osztályeloszlást használva.
3. Itt fontos megjegyezni, hogy semmilyen módon nem használjuk az adatkészlet-jelölést, ezért tetszőleges adatokat használhatunk. Természetesen a harci folyamból vett adatmintát használunk kiképzési mintaként a tanulói modellhez. Így a betanító készlet lehetővé teszi a modell pontosságának biztosítását, a stream minta pedig hasonló teljesítményt garantál a termelési eloszláson, kompenzálva a betanítási halmaz torzítását.

E két technika kombinációja (fák hozzáadása és számuk időszakos csökkentése Knowledge Destillation segítségével) biztosítja az új minták bevezetését és a teljes folytonosságot.

A KD segítségével különböző műveleteket is végzünk a modell jellemzőivel, mint például a jellemzők eltávolítása és a hézagok megmunkálása. Esetünkben számos fontos statisztikai jellemzőnk van (feladók, szövegkivonatok, URL-ek stb. szerint), amelyek az adatbázisban tárolódnak, és általában meghibásodnak. A modell természetesen nem áll készen az események ilyen fejlõdésére, mivel a tréningkészletben nem fordulnak elõ meghibásodási helyzetek. Ilyen esetekben kombináljuk a KD és az augmentációs technikákat: az adatok egy részének betanításakor eltávolítjuk vagy visszaállítjuk a szükséges jellemzőket, és vesszük az eredeti címkéket (az aktuális modell kimeneteit), és a tanuló modell megtanulja megismételni ezt az eloszlást. .

Észrevettük, hogy minél komolyabb modellmanipuláció történik, annál nagyobb a szükséges szálminta százalékos aránya.

A funkció eltávolítása, a legegyszerűbb művelet, az áramlásnak csak egy kis részét igényli, mivel csak néhány funkció változik, és a jelenlegi modellt ugyanazon a készleten tanították - a különbség minimális. A modell egyszerűsítéséhez (a fák számának többszöri csökkentése) már 50-50-re van szükség. A modell teljesítményét súlyosan befolyásoló fontos statisztikai jellemzők kihagyásához pedig még nagyobb áramlásra van szükség ahhoz, hogy kiegyenlítse a fák munkáját. új kihagyásálló modell minden betűtípuson.

FastText

Térjünk át a FastTextre. Hadd emlékeztesselek arra, hogy egy szó reprezentációja (Beágyazás) magának a szónak és az összes betű N-grammjának, általában trigramjának az összegéből áll. Mivel elég sok trigram lehet, ezért Bucket Hashing-et használnak, vagyis a teljes teret egy bizonyos fix hashmapé alakítják. Ennek eredményeként a súlymátrixot a belső réteg szószámra + vödrökre vetített méretével kapjuk meg.

További képzéssel új jelek jelennek meg: szavak és trigramok. Semmi jelentős nem történik a Facebook szokásos utóképzésén. Csak a régi keresztentrópiával rendelkező súlyokat képezik át az új adatokon. Így az új funkciókat nem alkalmazzák, ennek a megközelítésnek természetesen megvannak a fentebb leírt hátrányai, amelyek a modell gyártásban való kiszámíthatatlanságával járnak. Ezért módosítottunk egy kicsit a FastTexten. Minden új súlyt (szavakat és trigramokat) adunk hozzá, a teljes mátrixot keresztentrópiával bővítjük, és a lineáris modell analógiájával harmonikus regularizációt adunk hozzá, ami garantálja a régi súlyok jelentéktelen változását.

CNN

A konvolúciós hálózatok egy kicsit bonyolultabbak. Ha az utolsó rétegek elkészülnek a CNN-ben, akkor természetesen alkalmazhat harmonikus szabályzást és garantálja a folytonosságot. De ha a teljes hálózat további képzésére van szükség, akkor az ilyen rendszeresítés már nem alkalmazható minden rétegre. Lehetőség van azonban kiegészítő beágyazások betanítására a Triplet Loss (eredeti cikk).

Háromszoros veszteség

Példaként használva egy adathalászat elleni feladatot, nézzük meg általánosságban a Triplet Loss-t. Vegyünk logónkat, valamint más cégek logóinak pozitív és negatív példáit. Minimálisra csökkentjük az első és maximalizáljuk a második közötti távolságot, ezt kis hézaggal tesszük, hogy biztosítsuk az osztályok nagyobb tömörségét.

Ha tovább képezzük a hálózatot, akkor a metrikus terünk teljesen megváltozik, és teljesen összeférhetetlenné válik az előzővel. Ez komoly probléma a vektorokat használó problémáknál. A probléma megkerülése érdekében az edzés során a régi beágyazásokat keverjük be.

Új adatokkal egészítettük ki a képzési készletet, és a modell második verzióját a semmiből oktatjuk. A második szakaszban tovább képezzük hálózatunkat (Finetuning): először az utolsó réteg készül el, majd a teljes hálózat feloldása. A tripletek összeállítása során a beágyazások csak egy részét számítjuk ki a betanított modell segítségével, a többit - a régi segítségével. Így a kiegészítő képzés során biztosítjuk a v1 és v2 metrikus terek kompatibilitását. A harmonikus szabályosítás egyedülálló változata.

A teljes építészet

Ha a teljes rendszert szemléljük a levélszemét-szűrő használatával, akkor a modellek nem elszigeteltek, hanem egymásba vannak ágyazva. Képeket, szöveget és egyéb funkciókat készítünk, a CNN és ​​a Fast Text segítségével beágyazásokat kapunk. Ezután a beágyazások tetejére osztályozókat alkalmaznak, amelyek különböző osztályokra (levéltípusok, spam, logó jelenléte) adnak pontszámot. A jelzések és táblák már befutnak a fák erdőjébe, hogy meghozzák a végső döntést. Az egyes osztályozók ebben a sémában lehetővé teszik a rendszer eredményeinek jobb értelmezését, pontosabban a komponensek újraképzését problémák esetén, ahelyett, hogy az összes adatot nyers formában betáplálnák a döntési fákba.

Ennek eredményeként garantáljuk a folytonosságot minden szinten. Az alsó szinten a CNN-ben és a Fast Text-ben harmonikus regularizációt alkalmazunk, a középső osztályozóknál harmonikus regularizációt és sebességkalibrációt is alkalmazunk a valószínűségi eloszlás konzisztenciája érdekében. Nos, a fák növelését fokozatosan vagy a Knowledge Destillation segítségével tanítják.

Általánosságban elmondható, hogy egy ilyen beágyazott gépi tanulási rendszer fenntartása általában fájdalmas, mivel az alacsonyabb szinten lévő bármely összetevő a fenti teljes rendszer frissítéséhez vezet. Ám mivel a mi beállításunkban minden komponens némileg változik, és kompatibilis az előzővel, így a teljes rendszer darabonként frissíthető anélkül, hogy a teljes szerkezetet át kellene képezni, így komoly ráfordítás nélkül is támogatható.

Telepítés

Megbeszéltük az adatgyűjtést és a különböző típusú modellek kiegészítő betanítását, így továbblépünk azok éles környezetben való bevezetésére.

A/B tesztelés

Mint korábban említettem, az adatgyűjtés során általában egy torz mintát kapunk, amelyből nem lehet értékelni a modell gyártási teljesítményét. Ezért telepítéskor össze kell hasonlítani a modellt az előző verzióval, hogy megértsük, hogyan is mennek a dolgok, vagyis A/B teszteket kell végezni. Valójában a diagramok kihelyezése és elemzése meglehetősen rutin, és könnyen automatizálható. Modelleinket fokozatosan vezetjük be a felhasználók 5%, 30%, 50% és 100%-a számára, miközben összegyűjtjük az összes elérhető mérőszámot a modellre adott válaszokról és a felhasználói visszajelzésekről. Egyes komoly kiugró értékek esetén automatikusan visszaállítjuk a modellt, más esetekben pedig megfelelő számú felhasználói kattintás gyűjtése után a százalékos emelés mellett döntünk. Ennek eredményeként az új modellt teljesen automatikusan a felhasználók 50%-ának hozzuk el, és a teljes közönség számára történő bevezetést egy személy jóváhagyja, bár ez a lépés automatizálható.

Az A/B tesztelési folyamat azonban lehetőséget kínál az optimalizálásra. Az tény, hogy minden A/B teszt elég hosszú (esetünkben a visszajelzések mennyiségétől függően 6-24 órát vesz igénybe), ami meglehetősen költségessé és korlátozott erőforrásokkal rendelkezik. Ezenkívül a teszthez kellően magas áramlási százalékra van szükség ahhoz, hogy lényegesen felgyorsítsa az A/B teszt teljes időtartamát (a statisztikailag szignifikáns minta toborzása a mutatók kis százalékos kiértékeléséhez nagyon hosszú ideig tarthat), ami az A/B helyek száma rendkívül korlátozott. Nyilvánvalóan csak a legígéretesebb modelleket kell tesztelnünk, amelyekből elég sokat kapunk a kiegészítő képzés során.

Ennek a problémának a megoldására egy külön osztályozót képeztünk ki, amely előrejelzi az A/B teszt sikerét. Ehhez a döntéshozatali statisztikákat, a Precision, Recall és egyéb mérőszámokat a betanítási halmazon, a késleltetetten és a streamből vett mintán jellemzőként vesszük fel. Összehasonlítjuk a modellt a jelenlegi gyártásban lévővel, heurisztikával, és figyelembe vesszük a modell összetettségét. Mindezen tulajdonságokat felhasználva egy teszttörténetre képzett osztályozó értékeli a jelölt modelleket, esetünkben ezek fák erdei, és eldönti, hogy melyiket használja az A/B tesztben.

A megvalósítás idején ez a megközelítés lehetővé tette, hogy többszörösére növeljük a sikeres A/B tesztek számát.

Tesztelés és felügyelet

A tesztelés és monitorozás furcsa módon nem károsítja az egészségünket, ellenkezőleg, javítja, és megszabadít a felesleges stressztől. A tesztelés lehetővé teszi a hibák megelőzését, a monitorozás pedig lehetővé teszi annak időben történő észlelését, hogy csökkentse a felhasználókra gyakorolt ​​hatást.

Itt fontos megérteni, hogy előbb-utóbb a rendszer mindig hibázik - ez bármely szoftver fejlesztési ciklusának köszönhető. A rendszerfejlesztés kezdetén mindig sok a hiba, amíg minden rendeződik és az innováció fő szakasza be nem fejeződik. De idővel az entrópia megteszi a hatását, és újra megjelennek a hibák - a körülötte lévő komponensek romlása és az adatok változása miatt, amiről az elején beszéltem.

Itt szeretném megjegyezni, hogy minden gépi tanulási rendszert a profitja szempontjából kell szemlélni a teljes életciklusa során. Az alábbi grafikon egy példát mutat be arra, hogyan működik a rendszer egy ritka típusú spam elkapására (a grafikonon a vonal közel nulla). Egy nap egy helytelenül gyorsítótárazott attribútum miatt megőrült. Szerencsére nem volt megfigyelhető a rendellenes kioldás, ennek eredményeként a rendszer a leveleket nagy mennyiségben menteni kezdte a „spam” mappába a döntési határon. Hiába korrigálta a következményeket, a rendszer már annyiszor hibázott, hogy öt év múlva sem térül meg. Ez pedig teljes kudarc a modell életciklusa szempontjából.

Ezért egy olyan egyszerű dolog, mint a monitorozás, kulcsfontosságúvá válhat egy modell életében. A standard és nyilvánvaló mérőszámok mellett figyelembe vesszük a modellválaszok és pontszámok eloszlását, valamint a kulcsfontosságú jellemzők értékeinek eloszlását. A KL divergencia segítségével összehasonlíthatjuk az aktuális eloszlást a múltbelivel, vagy az A/B tesztben szereplő értékeket a stream többi részével, ami lehetővé teszi, hogy észrevegyük a modell anomáliáit, és időben visszagörgessük a változásokat.

A legtöbb esetben a rendszer első verzióit egyszerű heurisztikák vagy modellek segítségével indítjuk el, amelyeket a jövőben monitorozásként használunk. Például a NER-modellt a szokásos webáruházakhoz képest figyeljük, és ha azokhoz képest csökken az osztályozói lefedettség, akkor megértjük az okokat. A heurisztika újabb hasznos felhasználása!

Eredményei

Nézzük újra a cikk legfontosabb gondolatait.

• Fibdeck. Mindig a felhasználóra gondolunk: hogyan fog élni a hibáinkkal, hogyan tudja majd bejelenteni azokat. Ne felejtsük el, hogy a felhasználók nem csupán visszajelzések forrásai a képzési modellekhez, és ezt a segéd ML-rendszerek segítségével kell törölni. Ha nem lehetséges jelet gyűjteni a felhasználótól, akkor alternatív visszacsatolási forrásokat keresünk, például csatlakoztatott rendszereket.
• Kiegészítő képzés. Itt a fő a folytonosság, ezért a jelenlegi gyártási modellre hagyatkozunk. Az új modelleket úgy képezzük ki, hogy a harmonikus szabályosítás és hasonló trükkök miatt ne sokban térjenek el az előzőtől.
• Telepítés. A metrikákon alapuló automatikus üzembe helyezés nagymértékben csökkenti a modellek megvalósításának idejét. A statisztikák és a döntéshozatal eloszlásának monitorozása, a felhasználók elesésének száma kötelező a pihentető alváshoz és a produktív hétvégéhez.

Nos, remélem, ez segít Önnek gyorsabban fejleszteni ML rendszereit, gyorsabban piacra vinni őket, és megbízhatóbbá és kevésbé stresszessé teszi őket.

Forrás: will.com