Машин сургалт бизнест: Сбербанк + 50 сая хэрэглэгчтэй мобайл аппликейшнд ML нэвтрүүлсэн туршлага
Монголд өгөгдлийн шинжлэх ухаан, машин сургалтын талаар хамгийн их судалж хэрэгжүүлж байгаа салбар бол санхүүгийн салбар тэр дундаа финтек, банкууд гэж бодож байна. Тэр ч утгаараа Оросын хамгийн том банк болох Сбербанк гар утасны аппликейшндээ машин сургалтын алгоритм нэвтрүүлсэн тухай сонирхолтой байх болвуу. Ингээд Сбербанк-ын хөгжүүлэгчийн бичсэн нийтлэлийг та бүхэндээ орчуулан хүргэж байна. Эх хувилбар унших хүсэлтэй бол энэ линкээр орно уу.
Энэхүү нийтлэл нь Сбербанк Онлайн гар утасны аппликейшны төлбөр тооцоо шилжүүлгийн санал болгох систем буюу recommendation system хэрхэн нэвтрүүлсэн талаар өгүүлнэ.
Асуудал тодорхойлох нь
Сбербанк Онлайн аппликейшн хөгжиж өргөжихийн хэрээр түүний хэрэгцээт боломжууд болон нэмэлт цэсүүдийн тоо өссөөр ирсэн. Мөнгө шилжүүлэх, төлбөр төлөх гэх мэт.
“Аппликейшн дах харилцагчийн замналыг бид маш сайтар судалсан бөгөөд богиносгох олон боломж байгааг анзаарсан юм. Үүний тулд бид эхлээд эхлэл хуудсаа хэд хэдэн шатлалтайгаар шинжилсэн. Нэгдүгээрт, харилцагчийн ашигладаггүй зүйлсийг дэлгэцээс авч хаях. Дараа нь харилцагчийн өмнө нь хийж байсан бөгөөд одоо хийх магадлалтай үйлдлүүдийг эхэнд гаргах. Одоогоор боломжит үйлдлүүдийн жагсаалт нь байгууллагын төлбөр төлөх болон хоорондын шилжүүлэг зэргээс бүрдэж байгаа боловч цаашид энэхүү жагсаалт нэмэгдсээр байх болно” хэмээн Сбербанк Онлайн аппликейшны функционалын хөгжүүлэлт хариуцсан мэргэжилтэн Сергей Комаров ярьсан байдаг.
Иймд, бидний даалгавар бол дээрх зурагт харуулсан “Үйлдэл” гэсэн хэсэгт харилцагч бүрд өөрсдийнх нь хэрэгцээ шаардлагаас хамаарч ямар зүйлс байршуулах хэрэгтэйг тодорхойлох явдал юм.
Шийдэл
Манай баг асуудлыг дараах 2 дэд хэсэгт хуваасан:
- Хэрэглээний төлбөр болон шилжүүлгийн давтагдсан үйлдлүүдийг дахин санал болгох (“Санал болгож буй үйлдлүүд”)
- Тухайн харилцагчийн өмнө нь огт хийж байгаагүй үйлдлүүдийг шинээр санал болгох (“Хайлтын жишээ”)
Эхлээд үүнийгээ хайлтын хэсэгт туршиж үзэв.
Санал болгож буй үйлдлүүд
Скоринг-ийн оновчлол
Эхний дэд хэсэг буюу өмнө нь хийж байсан үйлдлүүдийг санал болгох нь харилцагч бүрийн үйлдлүүдийн хэдэн тэрбум боломжит комбинацийг авч үзэлгүйгээр түүнээс хамаагүй бага хэмжээний боломжит хувилбаруудад анхаарах боломжийг олгосон юм.
Харилцагчийн хийх боломжтой асар олон үйлдлүүдээс харилцагч “YYY” нь зөвхөн шатахууны болон зогсоолын төлбөр л төлсөн гэж үзвэл бид зөвхөн тэр 2 үйлдлийн давтагдах магадлалыг тооцох болно.
Өгөгдөл бэлтгэх
Бидний гол өгөгдөл нь гүйлгээний ажиглалтууд байсан бөгөөд үүн дээр нэмээд харилцагчийн демографик болон санхүүгийн үзүүлэлтүүд, тухайн үйлдлийн давтамж зэрэг мэдээллүүдийг ашигласан.
Зорилтот хувьсагч нь бидний тооцоолол хийсэн өдрөөс хойших өдрүүдэд тухайн гүйлгээ эсвэл үйлдэл хийгдсэн эсэх талаар мэдээлэл бүхий бинар хувьсагч юм. Тооцоолол хийх өдрөө дахин дахин өөрчилсөөр нэг үйдлийн хувьд тооцоолол хийж буй өдрөөс хамааран зорилтот хувьсагчийн тэмдэглэгээ өөр өөр болох бөгөөд энэ нь маш олон удаа давтагдах юм.
Жишээ нь, бид тооцоолол 17.03.2019-нд хийсэн гэж үзвэл дараах хоёр ажиглалт үр дүнд нь авах юм.
Энд Feature 1 гэдэг нь харилцагчийн бүх карт дээрх гүйлгээ эсвэл сүүлийн долоо хоногт тодорхой нэг гүйлгээ хийгдсэн эсэх зэрэг янз бүрийн хувьсагч байж болно. Энэ тохиолдолд зорилтот хувьсагч маань 1 байгаа нь тооцоолол хийгдсэн өдрөөс хойш тухайн гүйлгээ эсвэл үйлдэл хийгдсэн гэдгийг илтгэж байна.
Харин тооцоолол хийх өдрөө 20.03.2019 гэж өөрчилбөл feature-үүд болон зорилтот хувьсагч маань өөрчлөгдөж байгааг харж болно.
Дээрх жишээнд, ойлгомжтой байх үүднээс хүчин зүйлүүдийн шууд буюу боловсруулаагүй утгад тулгуурлан тайлбарласан боловч яг бодит байдал дээр бид WOE хувиргалт ашиглан хүчин зүйлсээ урьдчилан боловсруулсан юм. Энэхүү хувиргалт нь нөлөөлөгч хүчин зүйлс болон зорилтот хувьсагч хоорондын хамаарлыг шугаман болгох давуу талтай төдийгүй гаж утгуудаас /outlier/ ангид байх боломжийг олгодог. Жишээ нь, бидэнд “Эзэмшиж буй картын тоо” гэх фактор байлаа гэж үзвэл хувиргалт маань дараах байдалтай байна.
Уг хувиргалт нь хувьсагч хоорондын шугаман бус хамаарлыг шугаман болгодгоороо давуу талтай. Фактор болгоны хувьд WOE хувиргалттай утгаа тооцоололдоо оруулаад бодит утгаа хасна.
Мөн хувиргалт хийсэн dictionary-гаа хадгалан дараа дараагийн скоринг-д ашиглана.
Сургалт
Арга аргачлалын сонголтод ойлгомжтой байх шаардлага тавигдсан. Иймээс, хугацаандаа амжих үүднээс SHAP ашиглан тайлбарлах хэсгийг даалгаврын хоёрдугаар хэсэгт хийхээр хойшлуулан харьцангуй амар аргуудыг /регресс, гүн биш нейрон сүлжээ/ туршихаар шийдэв. Ингэхдээ SAS Miner /интерактив байдлаар цаг хугацаа хэмнэн төрөл бүрийн өгөгдөлд шинжилгээ хийх, модель боловсруулах боломж бүхий програм хангамж/ ашигласан.
Чанарын үнэлгээ
GINI метрик ашиглан тооцон үнэлгээний дагуу нейрон сүлжээ арай илүү сайн ажиллаж байгааг харж болно.
Гар утасны аппликейшн дээр энэхүү загварынхаа үр дүнг харуулах 2 блок байгаа. Эхнийх нь хамгийн эхний зурагт харуулсан нүүр хуудаст карт хэлбэрээр, дараагийнх нь “санал болгож буй үйлдлүүд” хэсэгт эдгээрээс топ-4 үйлдлүүдийг харуулсан байна.
Хайлтын жишээ
Асуудлын хоёрдох хэсэгт шилжвэл бидний маш олон үйлдлүүдийг хэдэн сая үйлчлүүлэгч бүрийн хувьд үнэлэн эрэмбэлэх асар олон боломжит хувилбаруудын асуудалтай тулгарна.
Дээрээс нь бидэнд байгаа өгөгдөл нь implicit буюу төлбөр, үйлдлийн үнэлгээний мэдээлэл байхгүй, тухайн харилцагч яагаад аль нэг үйлдэл болон гүйлгээг хийгээгүй талаар мэдээлэл байхгүй байсан юм. Иймээс эхний ээлжид үйлчилгээ болон харилцагчийн матриц бодох аргачлалуудыг туршиж үзэв: ALS болон FM.
ALS
ALS (Alternating Least Squares) буюу Ээлжилсэн хамгийн бага квадратын арга нь харилцан үйлчлэлийн матрицыг задлах аргуудын нэг юм. Гүйлгээний өгөгдлийг матриц хэлбэрээр дүрслье: багануудад үйлчилгээнүүдийг байршуулсан бөгөөд мөрүүдэд харилцагч бүрийг харуулсан байна. Нүднүүдэд тодорхой хугацааны туршид тухайн харилцагчийн тухайн үйлчилгээг авсан тоог байршуулсан.
Аргын гол санаа нь хоёр жижиг хэмжээтэй матриц үүсгэн эдгээр 2-ийн үржвэр нь бидний бодит том матрицтай боломжит хамгийн ижил үр дүнг гарахуйц байх юм. Бидний загвар харилцагчдын болон үйлчилгээнүүдийн нуугдмал фактор дүрслэл бий болгож сурах юм. Ингэхдээ implicit санг ашиглан тус аргыг хэрэгжүүлсэн. Сургалт дараах алгоритмаар явагдсан:
- Харилцагчид болон үйлчилгээнүүдийн матрицыг нуугдмал факторуудтайгаар эхний байдлаар бий болгох /initialize/ бөгөөд тэдгээрийн тоо нь бидний загварын hyperparameter юм.
- Үйлчилгээний нуугдмал фактор бүхий матрицыг тогтмол гэж авч үзэн харилцагчдын матрицыг засварлах зорилгоор алдааны функцийн /loss function/ уламжлал тооцно. Энэхүү алхмыг хурдасгах зорилгоор Нэгтгэсэн градиентын аргыг /Conjugate Gradient Method/ ашигласан байна.
- Дээрх алхмыг харилцагчдын матрицын хувьд мөн хийж гүйцэтгэнэ.
- Ингээд алгоритм дуусах хүртэл эдгээр алхмуудыг давтан хийнэ.
Бэлтгэл
Гүйлгээний мэдээллүүдийг боловсруулан матриц хэлбэрт шилжүүлсэн. Train болон validation өгөгдлийн бүрдэл хэсгүүдэд хуваахын тулд бид санамсаргүй аргаар зарим бөглөгдсөн нүхнүүдийн утгуудыг арилгасан.
Test өгөгдлийн хувьд сургалтын хугацаанаас хойш хугацаанд хийгдсэн гүйлгээнүүдийг авч матриц хэлбэрт шилжүүлсэн.
Сургалт
Загвар маань хэд хэдэн hyperparameter-тэй бөгөөд чанарыг сайжруулах зорилгоор тэдгээрийг өөрчилж болох юм.
- Alpha — тухайн үйлчилгээ харилцагчид үнэхээр “таалагдах” итгэлийг жинлэж буй коэффицент юм.
- Харилцагчид болон үйлчилгээнүүдийн матрицын нуугдмал факторуудын тоо — багана, мөрүүдийн тоо
- L2 regularization-ийн коэффицент λ.
- Аргын давталтын тоо /iteration/
Бид hyperparameter-уудын чанарын метрик-д нөлөөлөх нөлөөллийг TPE аргаар тооцон тэдгээрийн оновчтой утгыг сонгох боломжийг олгодог hyperopt санг ашигласан. Энэхүү алгоритм нь шинжлэгдэж буй hyperparameter-уудаас хамаарсан хэд хэдэн чанарын метрикийн хэмжилт хийх бөгөөд ямар hyperparameter-уудын нийлбэр тухайн чанарын метрикийн үр дүнг өндөр магадлалтайгаар хамгийн сайн байлгахыг олдог. Энэхүү процессын үр дүнгүүд хадгалагдах бөгөөд дараа нь график зуран харах боломжтой /цэнхэр нь сайн байгааг илтгэнэ/:
Графикаас hyperparameter-уудын загварын чанарын үзүүлэлтүүд асар их нөлөөлж байгаа нь харагдаж байна. Үүнээс гадна энэхүү алгоритмын орцод hyperparameter бүрийн тохиромжтой утгуудын интервалыг өгөх ёстой тул энэхүү графикаас интервалын хэмжээг нэмэгдүүлэх шаардлагатай эсэхийг тодорхойлж болно. Жишээ нь, бидний тохиолдолд энэхүү интервалын хэмжээг нэмэгдүүлэн дахин тооцох нь тохиромжтой байсан бөгөөд энэ нь бидний загварыг сайжруулах давуу талтай байсан юм.
Чанарын үнэлгээний метрик
Загварынхаа чанарыг хэрхэн үнэлэх вэ? Дарааллыг чухалчилдаг санал болгох систем /recommender system/-ийг үнэлэх хамгийн өргөн хэрэглэгддэг аргуудын нэг бол MAP@k буюу Mean average precision at K юм. Энэхүү метрик нь нийт харилцагч нарын хувьд бидний загвараар эрэмбэлэгдсэн топ K саналын дараалал үнэн зөв дараалалтай хэр ойролцоо байгааг хэмждэг.
Харамсалтай нь энэхүү чанарын үнэлгээ нь жижиг түүвэр өгөгдөл дээр хүртэл хэдэн цаг тооцоолол хийж байв. Ингээд бид mean_average_pecision_at_k() функцийг line_profiler ашиглан profile /зарцуулж буй хугацаа, санах ой зэргийг хэмжих/ хийж эхлэв. Энэхүү функц cython код ашиглан бичигдсэн байсан нь даалгаврыг маань илүү хүнд болгож байв. Метрикийн үнэлгээг хийхэд нөгөө л өгөгдлийн хэмжээний асуудал тулгарч эхлэв: тооцоолол хийхэд харилцагч бүрийн хувьд үйлчилгээ болгоныг үнэлэн тэдгээрээс харилцагч бүрийн хувьд топ-К саналын боловсруулан эрэмбэлэх хэрэгтэй. Хэсэгчилсэн эрэмбэлэлт numpy.argpartition() ашиглаж байсан хэдий ч үнэлгээнүүдээ эрэмбэлэх нь хамгийн удаан процесс байсан юм. numpy.argpartition() функц бидний серверийн бүрэн хүчин чадлыг ашиглаж чадахгүй байсан тул шинэ алгоритм C++ болон OpenMP дээр cython ашиглан бичих болов. Шинэ алгоритм нь дараах байдалтай байна.
- Өгөгдлийг харилцагч бүрээр жижиг хэсгүүдэд хуваана.
- Тооцоллын үр дүнг хадгалах хоосон матрицыг санах ойд үүсгэв.
- Өгөгдлийн жижиг хэсгүүдийн мөрүүд эхлээд partial_sort функцээр дараа нь C++ хэлийн sort санг ашиглан эрэмбэлэгдсэн юм.
- Үр дүнгүүд хоосон матриц дээр параллел байдлаар бичигдэнэ.
- Өгөгдлөө Python руу буцаана.
Энэ нь тооцооллын хурдыг хэд дахин нэмэгдүүлж чадсан юм. Үүнийг эндээс харах боломжтой байгаа.
OOT дээрх үр дүнгийн шинжилгээ
За ингээд загварын чанарыг үнэлэх цаг ирлээ.Яагаад бидэнд Out-Of-Time өгөгдөл хэрэгтэй вэ? Үйлчилгээний тархалтыг харвал дараах байдалтай байна:
Тэнцвэрт бус байдал тод харагдаж байна. Энэ нь загвар түгээмэл ашиглагддаг үйлчилгээг санал болгох гэж хичээдэг болохыг илтгэнэ. Доорх зурагт анхааръя:
Нэг ижил матрицыг масклан загварын оновчтой байдлыг хэмжвэл дийлэнх харилцагчдын хувьд загварын чанар хамгийн түгээмэл үйлчилгээг санал болгож байгаа үед өндөр байдаг хэмээн ойлгож болохоор байна. Ийм учраас бид дараах арга хэмжээг авсан юм:
- Загвараар үйлчилгээнүүдийн үнэлгээг боловсруулав.
- Үнэлгээ болон OOT-матрицуудаас харилцагчийн одоо хэрэглэдэг үйлчилгээнүүдийг хассан.
- Үлдэж буй үнэлгээнүүдээс топ-К саналуудыг боловсруулж үлдсэн OOT дээр MAP@k үнэлэв.
Үйлчилгээнүүдийн жагсаалтыг эрэлтээр нь эрэмбэлсэн бөгөөд үүнийгээ харилцагч бүрт үржүүлсэн байгаа. Тэдгээрээс харилцагчийн одоо ашигладаг үйлчилгээнүүдийг хассан. Гарсан үр дүнгээ чанарын үнэлгээний baseline болгон ашигласан. Ингээд харамсалтай нь, загварын маань эцсийн үр дүн нь бидний хүлээж байсан үр дүн огтхон ч биш байсан юм.
Зогс! Бидэнд харилцагчдын факторууд болон үйлчилгээнүүдийн параметрүүд байгаа шүү дээ.
FM
Factorization machines — матриц хэлбэрээр өгөгдсөн факторуудын хамаарлыг олох зорилго бүхий хяналттай сургалтын алгоритм юм. Бид LightFM санг ашигласан юм.
Өгөгдлийн формат
Нормальчлагдсан матрицаас гадна энэхүү арга нь нэмэлтээр хоёр өгөгдөл шаардана: one-hot-encoded матриц хэлбэрээр өгөгдсөн харилцагчдын болон үйлчилгээнүүдийн факторуудтай матрицууд.
Чанарын үнэлгээ
FM загварын чанар ALS загвараас ч бага байгаа харж болно:
Загварын архитектурын өөрчлөлт — Boosting
Асуудалд өөр талаас хандахаар шийдэв. Үйлчилгээний эрэлттэй байдлын тархалтаас үндэслэн бид нийт үйлдлийн 80%-ийг эзэлж буй 300 үйлчилгээг сонгон эдгээр үйлчилгээнүүд дээр классификатор ажиллуулсан. Энд өгөгдөл нь харилцагчдын хүчин зүйлсийг агуулсан гүйлгээнүүдийн агрегатууд байгааг харж болно.
Яагаад зөвхөн харилцагчийн гэж? Яагаад гэвэл ийм тохиолдолд харилцагчид үйлчилгээ санал болгоход 1 мөр л хангалттай байх болно. Түүндээ модель ажиллуулах үед гарц нь класс болгоны магадлал бүхий вектор гарах бөгөөд энэхүү вектор-с топ-К үйлчилгээг сонгох нь амар байх юм. Хэрвээ train өгөгдөлдөө үйлчилгээнүүдийн хүчин зүйлсийг нэмж өгвөл харилцагч болгон дээр 300 мөр нэмэх шаардлагатай эсвэл нэмэлтээр эрэмбэлэх хоёрдогч модель бичих хэрэг гарах юм.
Энэ тохиолдолд бид сайн үр дүнд хүрч чадсан юм.
Дүгнэлт
Ийм байдлаар харилцагч бүрийн ялгаатай хэрэгцээ шаардлагад нийцсэн үйлчилгээнүүдийг санал болгох 2 модель боловсруулсан юм. Цаашид санал болгож буй үйлчилгээнүүд дээр харилцагчдаас хариу үйлдэл авах бөгөөд таалагдаж байгаа эсэх талаар мэдээлэлтэй болох үед энэхүү загваруудаа сайжруулах төлөвлөгөөтэй байгаа. Энэхүү ажлыг хийх явцад маш их алдаа гарч, хүндрэлтэй тулгарсан ч асар их туршлага олж аван open source-д хувь нэмэрээ оруулсандаа баяртай байна.
