2019 februárjában-márciusában versenyt rendeztek a közösségi hálózat hírfolyamának rangsorolására , melyen csapatunk első helyezést ért el. A cikkben a verseny lebonyolításáról, az általunk kipróbált módszerekről, valamint a big data-on történő edzés catboost beállításairól lesz szó.
SNA Hackathon
Ez a harmadik alkalom, hogy ezen a néven hackathont rendeznek. Az ok.ru közösségi hálózat szervezi, a feladat és az adatok közvetlenül ehhez a közösségi hálózathoz kapcsolódnak.
Az SNA (social network analysis) ebben az esetben helyesebben nem egy társadalmi gráf elemzéseként értendő, hanem inkább egy közösségi hálózat elemzéseként.
- 2014-ben a feladat az volt, hogy megjósolják, hány lájkot kap egy bejegyzés.
- 2016-ban - a VVZ feladat (talán ismerős), közelebb a társadalmi grafikon elemzéséhez.
- 2019-ben a felhasználó hírcsatornájának rangsorolása annak a valószínűsége alapján, hogy a felhasználónak tetszeni fog a bejegyzés.
2014-ről nem tudok nyilatkozni, de 2016-ban és 2019-ben az adatelemzési képességek mellett a nagy adatokkal való munkavégzés készségeire is szükség volt. Azt hiszem, a gépi tanulás és a nagy adatfeldolgozási problémák kombinációja vonzott ezekre a versenyekre, és az ezeken a területeken szerzett tapasztalataim segítettek nyerni.
mlbootcamp
2019-ben a versenyt a platformon rendezték meg .
A verseny február 7-én kezdődött online, és 3 feladatból állt. Bárki regisztrálhatott az oldalon, letöltheti és rakod be az autódat néhány órára. A március 15-i online szakasz végén minden díjugrató esemény legjobb 15 helyezettje meghívást kapott a Mail.ru irodájába az offline szakaszra, amely március 30. és április 1. között zajlott.
Feladat
A forrásadatok felhasználói azonosítókat (userId) és bejegyzésazonosítókat (objectId) tartalmaznak. Ha a felhasználónak megjelent egy bejegyzés, akkor az adatok tartalmaznak egy sort, amely tartalmazza a userId-t, az objectId-t, a felhasználói reakciókat a bejegyzésre (visszajelzés), valamint egy sor különféle funkciót vagy linkeket képekre és szövegekre.
| Felhasználói azonosító | objectId | tulajdonosazonosító | Visszacsatolás | képek |
|---|---|---|---|---|
| 3555 | 22 | 5677 | [tetszik, kattintott] | [hash1] |
| 12842 | 55 | 32144 | [nem tetszett] | [hash2, hash3] |
| 13145 | 35 | 5677 | [kattintott, megosztott] | [hash2] |
A tesztadatkészlet hasonló szerkezetet tartalmaz, de a visszacsatolási mező hiányzik. A feladat a „tetszik” reakció jelenlétének előrejelzése a visszacsatolási mezőben.
A benyújtott fájl szerkezete a következő:
| Felhasználói azonosító | RendezettLista[objektumazonosító] |
|---|---|
| 123 | 78,13,54,22 |
| 128 | 35,61,55 |
| 131 | 35,68,129,11 |
A mérőszám a felhasználók átlagos ROC AUC értéke.
Az adatok részletesebb leírása a címen található. Ott is letölthet adatokat, köztük teszteket és képeket.
Online színpad
Az online szakaszban a feladatot 3 részre osztották
- — a képek és szövegek kivételével minden funkciót tartalmaz;
- — csak a képekkel kapcsolatos információkat tartalmaz;
- — csak szövegekkel kapcsolatos információkat tartalmaz.
Offline színpadon
Az offline szakaszban az adatok minden funkciót tartalmaztak, míg a szövegek és képek ritkák. 1,5-szer több sor volt az adathalmazban, amiből már sok volt.
A probléma megoldása
Mivel a munkahelyemen önéletrajzot készítek, a „Képek” feladattal indultam el ezen a versenyen. A megadott adatok a következők voltak: userId, objectId, ownerId (az a csoport, amelyben a bejegyzés megjelent), időbélyegek a bejegyzés létrehozásához és megjelenítéséhez, és természetesen a bejegyzés képe.
Az időbélyegek alapján több funkció létrehozása után a következő ötlet az volt, hogy a neuron utolsó előtti rétegét az imagenet-en előre betanították, és ezeket a beágyazásokat elküldjük boostolásra.
Az eredmények nem voltak lenyűgözőek. Az imagenet neuronból származó beágyazások lényegtelenek, gondoltam, saját autoencodert kell készítenem.
Sok időbe telt, és az eredmény nem javult.
Funkciógenerálás
A képekkel való munka sok időt vesz igénybe, ezért úgy döntöttem, valami egyszerűbbet csinálok.
Amint az azonnal látható, több kategorikus jellemző is van az adathalmazban, és hogy ne zavarjon túl sokat, csak a catboost vettem át. A megoldás kiváló volt, minden beállítás nélkül azonnal a ranglista első sorába kerültem.
Elég sok adat van, és parketta formátumban vannak kirakva, úgyhogy kétszeri gondolkodás nélkül vettem a scala-t és elkezdtem mindent szikrában írni.
A legegyszerűbb funkciók, amelyek nagyobb növekedést eredményeztek, mint a képbeágyazások:
- hányszor jelent meg az adatokban az objectId, a userId és a ownerId (korrelálnia kell a népszerűséggel);
- hány bejegyzést látott userId a ownerIdtől (korrelálnia kell a felhasználó csoport iránti érdeklődésével);
- hány egyedi userId tekintette meg a ownerId bejegyzéseit (a csoport közönségének méretét tükrözi).
Az időbélyegekből meg lehetett kapni a napszakot, amikor a felhasználó nézte a hírfolyamot (reggel/délután/este/éjszaka). A kategóriák kombinálásával folytathatja a funkciók létrehozását:
- hányszor jelentkezett be userId este;
- mikor jelenik meg ez a bejegyzés leggyakrabban (objectId) és így tovább.
Mindez fokozatosan javította a mutatókat. De a képzési adatkészlet mérete körülbelül 20 millió rekord, így a funkciók hozzáadása nagymértékben lelassította az edzést.
Újragondoltam az adatok felhasználásával kapcsolatos megközelítésemet. Bár az adatok időfüggőek, nyilvánvaló információszivárgást nem láttam „a jövőben”, ennek ellenére minden esetre így bontottam:
A rendelkezésünkre bocsátott tréningkészletet (február és március 2 hete) 2 részre osztottuk.
A modellt az elmúlt N nap adatai alapján képezték ki. A fent leírt aggregációk minden adatra épültek, beleértve a tesztet is. Ugyanakkor megjelentek olyan adatok, amelyekre a célváltozó különféle kódolásait lehet építeni. A legegyszerűbb megoldás az, ha újra felhasználjuk a már új funkciókat létrehozó kódot, és egyszerűen betápláljuk azokat az adatokat, amelyekre nem lesz betanítva, és cél = 1.
Így hasonló funkciókat kaptunk:
- Hányszor látott userId bejegyzést a csoport tulajdonosazonosítójában;
- Hányszor tetszett userIdnek a bejegyzés a következő csoportban: ownerId;
- Azon bejegyzések százalékos aránya, amelyeket userId kedvelt a tulajdonosIdtől.
Vagyis kiderült átlagos célkódolás az adatkészlet egy részén a kategorikus jellemzők különféle kombinációihoz. A catboost elvileg célkódolást is épít, és ebből a szempontból semmi haszna nincs, de például lehetővé vált, hogy megszámolják az egyedi felhasználók számát, akik kedvelték a bejegyzéseket ebben a csoportban. Ezzel párhuzamosan a fő cél megvalósult - az adatkészletemet többször csökkentették, és lehetőség nyílt a szolgáltatások generálására.
Míg a catboost csak a kedvelt reakció alapján tud kódolást létrehozni, a visszajelzésnek más reakciói is vannak: újra megosztott, nem tetszett, nem tetszett, kattintott, figyelmen kívül hagyva, a kódolások pedig manuálisan elvégezhetők. Mindenféle aggregátumot újraszámítottam, és kiszűrtem az alacsony jelentőségű jellemzőket, hogy ne növeljem fel az adatkészletet.
Ekkor már nagy különbséggel az első helyen álltam. Az egyetlen zavaró dolog az volt, hogy a képbeágyazások szinte semmilyen növekedést nem mutattak. Jött az ötlet, hogy mindent megadjunk a catboostnak. Csoportosítjuk a Kmeans képeket, és kapunk egy új, kategorikus imageCat funkciót.
Íme néhány osztály a KMeans-ből származó fürtök kézi szűrése és egyesítése után.
Az imageCat alapján generáljuk:
- Új kategorikus jellemzők:
- Melyik imageCat-et tekintette meg leggyakrabban userId;
- Melyik imageCat mutatja leggyakrabban a tulajdonosazonosítót;
- Melyik imageCat kedvelte leggyakrabban userId;
- Különféle számlálók:
- Hány egyedi imageCat nézett a userId-re;
- Körülbelül 15 hasonló szolgáltatás, valamint a fent leírt célkódolás.
szövegek
A képpályázaton elért eredmények megfeleltek nekem, és úgy döntöttem, hogy kipróbálom magam a szövegekben. Korábban keveset dolgoztam szövegekkel, és bolond módon megöltem a napot tf-idf-en és svd-n. Aztán megláttam az alapvonalat a doc2vec-el, ami pontosan azt csinálja, amire szükségem van. A doc2vec paramétereit kissé módosítva szövegbeágyazásokat kaptam.
Aztán egyszerűen újra felhasználtam a kódot a képekhez, amiben a képbeágyazásokat szövegbeágyazással helyettesítettem. Ennek eredményeként a szöveges versenyen 2. helyezést értem el.
Együttműködési rendszer
Egy verseny maradt, amit még nem „böktem meg” bottal, és a ranglistán szereplő AUC alapján ítélve ennek a versenynek kellett volna a legnagyobb hatással lennie az offline szakaszra.
A forrásadatokban szereplő összes jellemzőt kiválasztottam, kategorikusakat választottam, és ugyanazokat az aggregátumokat számoltam ki, mint a képeknél, kivéve a képeken alapuló jellemzőket. Ha ezt a catboostba tettem, a 2. helyre kerültem.
A catboost optimalizálás első lépései
Egy első és két második hely örömet okozott, de az volt a tudat, hogy nem csináltam semmi különöset, ami azt jelenti, hogy pozícióvesztésre számíthatok.
A verseny feladata a posztok rangsorolása a felhasználón belül, és mindvégig az osztályozási feladatot oldottam meg, vagyis a rossz mérőszámot optimalizáltam.
Mondok egy egyszerű példát:
| Felhasználói azonosító | objectId | előrejelzés | földi igazság |
|---|---|---|---|
| 1 | 10 | 0.9 | 1 |
| 1 | 11 | 0.8 | 1 |
| 1 | 12 | 0.7 | 1 |
| 1 | 13 | 0.6 | 1 |
| 1 | 14 | 0.5 | 0 |
| 2 | 15 | 0.4 | 0 |
| 2 | 16 | 0.3 | 1 |
Csináljunk egy kis átrendezést
| Felhasználói azonosító | objectId | előrejelzés | földi igazság |
|---|---|---|---|
| 1 | 10 | 0.9 | 1 |
| 1 | 11 | 0.8 | 1 |
| 1 | 12 | 0.7 | 1 |
| 1 | 13 | 0.6 | 0 |
| 2 | 16 | 0.5 | 1 |
| 2 | 15 | 0.4 | 0 |
| 1 | 14 | 0.3 | 1 |
A következő eredményeket kapjuk:
| Modell | AUC | User1 AUC | User2 AUC | átlagos AUC |
|---|---|---|---|---|
| Az 1 opció | 0,8 | 1,0 | 0,0 | 0,5 |
| Az 2 opció | 0,7 | 0,75 | 1,0 | 0,875 |
Amint látható, az általános AUC-mutató javítása nem jelenti a felhasználó átlagos AUC-mutatójának javítását.
Catboost a dobozból. Olvastam a rangsorolási mérőszámokról, a catboost használatakor, és állítsa be a YetiRankPairwise-t, hogy éjszaka edzen. Az eredmény nem volt lenyűgöző. Mivel úgy döntöttem, hogy alulképzett vagyok, a hibafüggvényt QueryRMSE-re cseréltem, ami a catboost dokumentációból ítélve gyorsabban konvergál. Végül ugyanazokat az eredményeket értem el, mint a besorolási edzésen, de ennek a két modellnek az együttesei jó növekedést hoztak, amivel mindhárom versenyszámban az első helyezést értem el.
5 perccel az „Együttműködő rendszerek” verseny online szakaszának zárása előtt Sergey Shalnov a második helyre vitt. Együtt jártuk a további utat.
Felkészülés az offline szakaszra
Az online szakaszban egy RTX 2080 TI videokártyával garantált győzelmet arattunk, de a 300 000 rubel főnyeremény és nagy valószínűséggel még a végső első hely is arra kényszerített minket, hogy ezt a 2 hetet megdolgozzuk.
Mint kiderült, Sergey catboost is használt. Ötleteket és funkciókat cseréltünk, és megtanultam amely sok kérdésemre tartalmazta a választ, és még azokra is, amelyeket addig még nem tudtam meg.
A jelentés megtekintése során arra az ötletre jutottam, hogy minden paramétert vissza kell állítani az alapértelmezett értékre, és nagyon körültekintően kell elvégezni a beállításokat, csak a funkciók javítása után. Most egy edzés körülbelül 15 órát vett igénybe, de egy modellnek sikerült jobb sebességet elérnie, mint a rangsorolásos együttesben.
Funkciógenerálás
A Collaborative Systems versenyben számos funkciót értékelnek a modell szempontjából fontosnak. Például, auditweights_spark_svd - a legfontosabb jel, de nincs információ arról, hogy mit jelent. Úgy gondoltam, hogy a különböző aggregátumokat fontos jellemzők alapján érdemes megszámolni. Például átlagos auditweights_spark_svd felhasználó, csoport vagy objektum szerint. Ugyanez kiszámítható olyan adatok felhasználásával, amelyeken nem történik edzés, és cél = 1, azaz átlag auditweights_spark_svd felhasználó által a neki tetsző objektumok szerint. Ezen kívül fontos jelek auditweights_spark_svd, több volt. Itt van néhány közülük:
- auditweightsCtrGender
- auditweightsCtrHigh
- userOwnerCounterCreateLikes
Például az átlag auditweightsCtrGender a userId szerint fontos tulajdonságnak bizonyult, akárcsak az átlagérték userOwnerCounterCreateLikes userId+ownerId alapján. Ez már el kell, hogy gondolja, hogy meg kell értenie a mezők jelentését.
Fontos tulajdonságok is voltak auditweightsLikesCount и auditweightsShowsCount. Az egyiket a másikkal elosztva egy még fontosabb tulajdonságot kaptunk.
Adatszivárgás
A verseny és a termelés modellezése nagyon különböző feladatok. Az adatok előkészítésekor nagyon nehéz minden részletet figyelembe venni, és nem közölni néhány nem triviális információt a tesztben szereplő célváltozóról. Ha éles megoldást hozunk létre, igyekszünk elkerülni az adatszivárgást a modell betanítása során. De ha meg akarjuk nyerni a versenyt, akkor az adatszivárgás a legjobb tulajdonság.
Az adatok tanulmányozása után láthatja, hogy az objectId értékek szerint auditweightsLikesCount и auditweightsShowsCount változás, ami azt jelenti, hogy ezen jellemzők maximális értékeinek aránya sokkal jobban tükrözi az utólagos konverziót, mint a megjelenítéskori arány.
Az első szivárgás, amit találtunk auditweightsLikesCountMax/auditweightsShowsCountMax.
De mi van, ha alaposabban megvizsgáljuk az adatokat? Válogassunk a bemutató dátuma szerint, és kapjuk:
| objectId | Felhasználói azonosító | auditweightsShowsCount | auditweightsLikesCount | cél (tetszik) |
|---|---|---|---|---|
| 1 | 1 | 12 | 3 | valószínűleg nem |
| 1 | 2 | 15 | 3 | Talán igen |
| 1 | 3 | 16 | 4 |
Meglepő volt, amikor rátaláltam az első ilyen példára, és kiderült, hogy a jóslatom nem vált be. De figyelembe véve azt a tényt, hogy ezeknek a jellemzőknek az objektumon belüli maximális értéke nőtt, nem voltunk lusták, és úgy döntöttünk, hogy megtaláljuk auditweightsShowsCountNext и auditweightsLikesCountNext, vagyis a következő pillanatban érvényes értékeket. Funkció hozzáadásával
(auditweightsShowsCountNext-auditweightsShowsCount)/(auditweightsLikesCount-auditweightsLikesCountNext) gyorsan éles ugrást hajtottunk végre.
Hasonló szivárgások használhatók a következő értékek meghatározásával userOwnerCounterCreateLikes a userId+ownerId és pl. auditweightsCtrGender az objectId+userGender belül. 6 hasonló szivárgó mezőt találtunk, és a lehető legtöbb információt kinyertük belőlük.
Addigra a lehető legtöbb információt kisajtoltuk az együttműködési funkciókból, de nem tértünk vissza a képi és szöveges versenyekhez. Remek ötletem támadt, hogy ellenőrizzem: mennyit adnak a közvetlenül képeken vagy szövegeken alapuló funkciók a releváns versenyeken?
A kép- és szövegversenyben nem volt kiszivárgás, de addigra visszaadtam az alapértelmezett catboost paramétereket, kitisztítottam a kódot és hozzáadtam néhány funkciót. Összesen ez volt:
| döntés | hamar |
|---|---|
| Maximum képekkel | 0.6411 |
| Maximum nincs kép | 0.6297 |
| Második helyezés eredménye | 0.6295 |
| döntés | hamar |
|---|---|
| Maximum szövegekkel | 0.666 |
| Maximum szövegek nélkül | 0.660 |
| Második helyezés eredménye | 0.656 |
| döntés | hamar |
|---|---|
| Maximum az együttműködésben | 0.745 |
| Második helyezés eredménye | 0.723 |
Nyilvánvalóvá vált, hogy szövegekből és képekből aligha tudunk sokat kicsikarni, és miután kipróbáltunk néhány legérdekesebb ötletet, abbahagytuk a velük való munkát.
A kollaboratív rendszerek szolgáltatásainak további generációja nem hozott növekedést, és elkezdtük a rangsorolást. Az online szakaszon a besorolás és a helyezési együttes adott egy kis növekedést, mint kiderült, mert alulképzettem a besorolást. A hibafüggvények egyike sem, beleértve a YetiRanlPairwise-t sem, közel sem hozott olyan eredményt, mint a LogLoss (0,745 vs. 0,725). Még volt remény a QueryCrossEntropyra, amelyet nem sikerült elindítani.
Offline színpadon
Az offline szakaszban az adatstruktúra változatlan maradt, de voltak kisebb változások:
- a userId, objectId, ownerId azonosítók újra véletlenszerűvé lettek osztva;
- több táblát eltávolítottak, és néhányat átneveztek;
- az adatok körülbelül 1,5-szeresére nőttek.
A felsorolt nehézségek mellett volt egy nagy plusz: a csapat egy nagy szervert kapott egy RTX 2080TI-vel. Régóta élvezem a htopot.
Csak egy ötlet volt: egyszerűen reprodukálni azt, ami már létezik. Miután néhány órát töltöttünk a környezet beállításával a szerveren, fokozatosan elkezdtük ellenőrizni, hogy az eredmények reprodukálhatók-e. A fő probléma, amellyel szembesülünk, az adatmennyiség növekedése. Úgy döntöttünk, hogy egy kicsit csökkentjük a terhelést, és beállítjuk a ctr_complexity=1 catboost paramétert. Ez kicsit csökkenti a sebességet, de a modellem elkezdett működni, az eredmény jó volt - 0,733. Szergej velem ellentétben nem osztotta 2 részre az adatokat, és az összes adatra oktatott, bár ez adta a legjobb eredményeket az online szakaszban, az offline szakaszban sok nehézség volt. Ha az összes általunk generált szolgáltatást felhasználnánk, és megpróbálnánk bevinni őket a catboostba, akkor az online szakaszban semmi sem működne. Szergej típusoptimalizálást végzett, például a float64 típusokat float32-re konvertálta. A pandák memóriaoptimalizálásáról tájékozódhat. Ennek eredményeként Szergej az összes adat felhasználásával edzett a CPU-n, és körülbelül 0,735-öt kapott.
Ezek az eredmények elegendőek voltak a győzelemhez, de elrejtettük valódi sebességünket, és nem lehettünk biztosak abban, hogy más csapatok nem csinálják ugyanezt.
Küzdj a végsőkig
Catboost tuning
Megoldásunkat teljesen reprodukáltuk, hozzáadtuk a szöveges adatok és képek jellemzőit, így már csak a catboost paraméterek hangolása maradt hátra. Sergey a CPU-n edzett kis számú iterációval, én pedig a ctr_complexity=1-el. Egy nap volt hátra, és ha csak iterációkat adsz hozzá, vagy növeled a ctr_complexity-t, akkor reggelre még jobb sebességet érhetsz el, és egész nap sétálhatsz.
Offline állapotban a sebességek nagyon könnyen elrejthetők, ha egyszerűen nem a legjobb megoldást választják a webhelyen. Drasztikus változásokra számítottunk a ranglistán az utolsó percekben a leadások lezárása előtt, és úgy döntöttünk, nem állunk meg.
Anna videójából megtudtam, hogy a modell minőségének javítása érdekében a legjobb a következő paraméterek kiválasztása:
- tanulási_ráta — Az alapértelmezett érték kiszámítása az adatkészlet mérete alapján történik. A learning_rate növelése az iterációk számának növelését igényli.
- l2_leaf_reg — Szabályozási együttható, alapértelmezett érték 3, lehetőleg 2 és 30 között válasszon. Az érték csökkentése a túlillesztés növekedéséhez vezet.
- zsákolási_hőmérséklet — véletlenszerűsítést ad a mintában szereplő objektumok súlyához. Az alapértelmezett érték 1, ahol a súlyok exponenciális eloszlásból származnak. Az érték csökkentése a túlzott illeszkedés növekedéséhez vezet.
- random_strength — Befolyásolja a felosztások kiválasztását egy adott iterációnál. Minél nagyobb a random_strength, annál nagyobb az esélye annak, hogy alacsony fontosságú felosztás kerül kiválasztásra. Minden következő iterációnál a véletlenszerűség csökken. Az érték csökkentése a túlzott illeszkedés növekedéséhez vezet.
Más paraméterek sokkal kisebb hatással vannak a végeredményre, ezért nem próbáltam kiválogatni őket. A ctr_complexity=1 beállítású GPU-adatkészletemen a betanítás egy iterációja 20 percig tartott, és a csökkentett adatkészlet kiválasztott paraméterei kissé eltértek a teljes adatkészlet optimális paramétereitől. Végül körülbelül 30 iterációt végeztem az adatok 10%-án, majd további 10 iterációt az összes adaton. Valami ilyesmi lett belőle:
- tanulási_ráta 40%-kal növeltem az alapértelmezetthez képest;
- l2_leaf_reg ugyanazt hagyta;
- zsákolási_hőmérséklet и random_strength 0,8-ra csökkentve.
Megállapíthatjuk, hogy a modell alulképzett volt az alapértelmezett paraméterekkel.
Nagyon meglepődtem, amikor megláttam az eredményt a ranglistán:
| Modell | modell 1 | modell 2 | modell 3 | együttes |
|---|---|---|---|---|
| Tuning nélkül | 0.7403 | 0.7404 | 0.7404 | 0.7407 |
| Tuningolással | 0.7406 | 0.7405 | 0.7406 | 0.7408 |
Arra a következtetésre jutottam, hogy ha nincs szükség a modell gyors alkalmazására, akkor jobb, ha a paraméterek kiválasztását több modellből álló együttessel helyettesítjük, nem optimalizált paramétereket használva.
Szergej optimalizálta az adatkészlet méretét, hogy a GPU-n futtassa. A legegyszerűbb lehetőség az adatok egy részének levágása, de ez többféleképpen is megtehető:
- fokozatosan távolítsa el a legrégebbi adatokat (február eleje), amíg az adatkészlet el nem kezd illeszkedni a memóriába;
- távolítsa el a legalacsonyabb jelentőségű funkciókat;
- távolítsa el a felhasználói azonosítókat, amelyekhez csak egy bejegyzés tartozik;
- csak a tesztben szereplő userId-eket hagyja meg.
Végül pedig alkoss egy együttest az összes lehetőségből.
Az utolsó együttes
Az utolsó nap késő estéjére elkészítettük modelljeink együttesét, amely 0,742-t hozott. Egyik napról a másikra elindítottam a modellemet ctr_complexity=2-vel, és 30 perc helyett 5 órát edzett. Csak hajnali 4-kor számolták be, és megcsináltam az utolsó együttest, ami 0,7433-at adott a nyilvános ranglistán.
A probléma megoldásának eltérő megközelítései miatt előrejelzéseink nem korreláltak erősen, ami jó növekedést adott az együttesben. Ahhoz, hogy egy jó együttest kapjunk, jobb, ha a nyers modell előrejelzéseit használja a prediction(prediction_type='RawFormulaVal') és állítsa be a scale_pos_weight=neg_count/pos_count értéket.
A weboldalon láthatod .
Egyéb megoldások
Sok csapat követte az ajánlórendszer-algoritmusok kánonját. Én, mivel nem vagyok szakértő ezen a területen, nem tudom értékelni őket, de emlékszem 2 érdekes megoldásra.
- . Nikolay a Mail.ru munkatársaként nem pályázott nyereményekre, így nem a maximális sebesség elérése volt a célja, hanem egy könnyen méretezhető megoldás megszerzése.
- A zsűri díjnyertes csapatának döntése alapján , nagyon jó képcsoportosítást tesz lehetővé manuális munka nélkül.
Következtetés
Ami a legjobban megmaradt az emlékezetemben:
- Ha vannak kategorikus jellemzők az adatokban, és tudja, hogyan kell helyesen végrehajtani a célkódolást, még mindig jobb, ha kipróbálja a catboost.
- Ha versenyen vesz részt, ne veszítsen időt a tanulási sebességen és az iterációkon kívüli paraméterek kiválasztására. Gyorsabb megoldás több modellből álló együttes készítése.
- Az erősítések tanulhatnak a GPU-n. A Catboost nagyon gyorsan tud tanulni a GPU-n, de sok memóriát felemészt.
- Az ötletek fejlesztése és tesztelése során célszerű egy kis rsm~=0.2 (csak CPU) és ctr_complexity=1 értéket beállítani.
- Más csapatokkal ellentétben a mi modelleink együttese nagy növekedést hozott. Csak eszmét cseréltünk és különböző nyelveken írtunk. Más megközelítést alkalmaztunk az adatok felosztására, és azt hiszem, mindegyiknek megvoltak a saját hibái.
- Nem világos, hogy a rangsorolás optimalizálás miért teljesített rosszabbul, mint az osztályozás optimalizálás.
- Tapasztalatot szereztem a szövegekkel való munkavégzés során, és megértettem, hogyan készülnek az ajánlórendszerek.
Köszönet a szervezőknek az érzelmekért, a tudásért és a kapott díjakért.
Forrás: will.com