ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 125
Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 120
Abonament PDF

Machine Learning – la raftul cu iaurt vă rog

Dragoș Cojocari
Co-Founder @ DataGrid Software
PROGRAMARE


Când vine vorba despre AI si ML, probabil, primul gând se îndreaptă spre rețele neuronale, recunoaștere de imagini, roboți autonomi și multe alte lucruri minunate. Putem însă, și e nevoie să aplicăm această tehnologie pentru a rezolva probleme mai puțin spectaculoase, dar cu un impact la fel de mare. Cum ar fi de exemplu, să prezicem ce iaurturi sunt pe cale să expire și să evităm astfel risipa alimentară ?

Nu e la fel de "cool" precum roboții de la Boston Dynamics dar degrevează angajații de sarcini plicticoase, permițându-le să își folosească timpul pentru activități creative.

Cum stăm în practică?

Un studiu realizat de Capgemini arată că doar 13% din companiile ce au adoptat ML o fac consistent și consecvent. Vorbim aici despre companii cu cifre de afaceri de peste 1 miliard de dolari anual, despre care putem presupune că au atât dorința, cât și resursele necesare pentru a susține astfel de proiecte. Și totuși rezultatele sunt sub așteptări. E chiar atât de dificil de aplicat ML în afaceri?

Despre ce e vorba în acest articol?

Un munte de date generate de procesele industriale și de afaceri zac nefolosite, deși se spune că datele sunt petrolul secolului 21. Împreună cu unul din partenerii noștri, unul din marile lanțuri de vânzare en-gros, am dezvoltat o aplicație bazată pe Machine Learning ce folosește o parte din aceste date pentru a reduce risipa alimentare în paralel cu creșterea veniturilor.

Am construit un model ce estimează cantitatea vândută pentru produsele pe cale să expire. Efectuând predicția asupra unui set de valori ale reducerii, putem alege valoarea ce maximizează profitul fără a genera risipă (produsul nu se vinde și trebuie distrus).

Proiectul pilot a avut succes iar aplicația a ajuns să fie folosită de sute de angajați în peste 100 de magazine.

În următoarele rânduri, voi descrie ce presupune aplicarea ML-ului într-o problemă de business.

Ce nu veți găsi aici și de ce?

Nu voi încerca o descriere detaliată a unui algoritm sau a vreunei metode de ML întrucât sunt nenumărate articole detaliate pe această temă. Recomand https://towardsdatascience.com și https://kaggle.com pentru astfel de articole.

Ce presupune utilizarea ML-ului într-o problemă concretă de business?

Să începem cu începutul : necesarul de materiale. Nu pretind că lista de mai jos e exhaustivă, deoarece fiecare proiect are particularitățile sale.

  1. Date;

  2. Cunoașterea domeniului și capacitatea de a analiza datele;

  3. Selecția modelului;

  4. Operaționalizarea modelului;

  5. Planul de test și monitorizarea soluției;

  6. Acceptarea soluției și suportul echipei de business.

Acceptarea soluției și suportul echipei de business

Încep cu ultimul punct din lista mea pentru că este cel fără de care proiectul rămâne la stadiul de "shelfware" sau în cel mai bun caz ca Proof of Concept. Acceptul dat de beneficiarii soluției e condiționat de capacitatea echipei de dezvoltare de a explica/demonstra corectitudinea soluției.

Pentru pasionații de ML, metricile unui model și înțelegerea matematicii din spatele acestuia sunt suficiente pentru a "avea încredere" în model. Însă pentru persoana responsabilă de rezultatele financiare, metricile modelului sunt cel mai adesea insuficiente. E important să poți explica de ce modelul oferă predicțiile pe care le oferă și să simulezi comportamentul modelului.

De aceea, un algoritm mai "slab", dar mai explicabil (Regresie Liniară, Arbore de decizie etc.) poate fi preferat în locul unuia mai puternic, dar dificil de explicat. Mă refer aici la modele " black-box" precum sunt rețelele neuronale.

Prin urmare, am documentat metricile modelului (R2, RMSE etc.) și am simulat impactul asupra vânzărilor la fiecare iterație a modelului. Astfel, beneficiarii non-tehnici au putut înțelege și urmări ce se întâmplă.

Datele

Categoric, reprezintă cel mai important ingredient al soluției. Niciun algoritm, indiferent cât de puternic este, nu poate compensa lipsa datelor sau calitatea proastă a acestora.

Algoritmii de ML dau rezultate mai bune cu cât avem mai multe date, atât ca număr de înregistrări, dar și ca număr de proprietăți. Un set mai bogat de date permite echipei de Data Science să emită și să testeze mai multe ipoteze și soluții.

Calitatea datelor e la fel de importantă ca și cantitatea, dar e o problemă mai dificil de rezolvat. În cazul unei cantități mici de date se poate crește viteza de colectare, se pot identifica noi surse de date sau se poate crește perioada de colectare. E dificil să corectezi datele generate de-a lungul a mai multor ani de procese de business relativ rigide.

În situația noastră, ne-am lovit de problema variabilității scăzute a datelor, trei reduceri reprezentând 90%+ din datele disponibile. Ori asta înseamnă că modelul va învăța doar aceste trei valori, invalidând întregul efort. Garbage in, garbage out se aplică și aici. Fără a intra în detalii, am rezolvat parțial problema rotunjind și grupând predicțiile modelului, ceea ce a generat o plajă mai largă de recomandări.

Avem datele, ce facem cu ele?

O bună înțelegere a domeniului dublată de aptitudinile necesare pentru a analiza datele sunt, de asemenea, necesare. Trendurile anuale, sezonale, "product cannibalization", schimbarea furnizorilor sau strategia companiei sunt aspecte de luat în calcul.

Metrici bune ale modelului pot ascunde predicții ce nu au sens sau nu sunt aplicabile din motive legale, comerciale etc. De aceea, e important ca pe lângă echipa de dezvoltare să existe experți în domeniu care să analizeze rezultatele.

Notă : prin echipa de dezvoltare într-un proiect de ML mă refer la data scientists, data analysts, ingineri soft, designeri, QA etc.

Selecția modelului

Selectarea modelului presupune un proces ciclic ce nu se încheie nici când modelul ajunge în producție. Am folosit Jupyter Nothebooks și ScikitLearn pentru a explora datele, experimenta diverse modele și pentru alege modelul cel mai potrivit.

Pilot

Modelul folosit în faza pilot a fost o Regresie Liniară (OLS - Ordinary Least Squares). Cu toate că OLS e unul din cei mai vechi și relativ simpli algoritmi, rezultatele au fost excelente. Numărul produselor distruse a scăzut, iar valoarea ușor micșorată a reducerilor a avut ca rezultat creșterea veniturilor.

Producție

Pentru următoarea etapă, pilotul a fost extins la peste 100 de magazine.

Am înlocuit modelul OLS cu un model compus (stacking model) dintr-o regresie liniară (OLS) aplicată peste rezultatele unui arbore de decizie (GradientBoostingRegressor). Arborele de decizie estimează cererea pentru acel produs, iar modelul de regresie liniară combină această valoare cu valoarea reducerii pentru rezultatul final.

Acest model este cu aproximativ 15% mai bun decât modelul liniar, dar rămânând simplu de explicat.

Notă: pentru o explicație detaliată de cum se construiesc "stacked models" recomand acest articol.

Operaționalizarea modelului

În deschiderea articolului am prezentat procentul de modele ce ajung în producție. Iar utilizarea unui model în producție înseamnă mai mult decât crearea sa în Jupyter Notebooks. Pentru a putea utiliza predicțiile modelului, am construit un "inference service" pe care l-am integrat în flowul și UI-ul deja existente.

Am avut de ales între Go (Java, Rust, Node.JS) și Python pentru implementarea serviciului.

Pros Cons
Go Optimizat pentru a construi aplicații de rețea Amprenta mica Necesită un container separat care rulează Python pentru a încărca modelul
Python Scrierea de servicii de rețea rapide nu e punctul forte al Pythonului Modelul se poate încărca în spațiul de memorie al serviciului și servi direct

Am ales Python pentru că am putut compensa performanța mai scăzută prin folosirea unui server WSGI (Waitress/Gunicorn). Păstrând abilitatea de a încărca modelele direct în serviciu am obținut o soluție mai simplă și mai ușor de întreținut fără ca performanța să aibă de suferit per ansamblu.

Logurile și metricile de performanță sunt colectate automat și centralizat în DataDog pentru a avea imaginea de ansamblu a performanței serviciului și a putea investiga eventualele probleme.

Serviciul efectuează aproximativ 300000 de predicții săptămânal, latența fiind sub 50ms (P95). Numărul în sine nu este uriaș, însă combinat cu metricile de performanță validează alegerea făcută. Mai mult, traficul poate crește, dat fiind că utilizarea actuală reprezintă 10% din capacitatea configurată în Google Cloud Platform, 2 pod-uri cu 1 CPU si 2 GB de RAM.

Planul de test și monitorizarea soluției

Modelul a fost creat, serviciul de inferență implementat, ce rămâne de făcut? Revenind la discuția despre acceptarea soluției, e necesar să monitorizăm și să validăm rezultatele din punctul de vedere al obiectivelor de business. Cu alte cuvinte, am obținut ce ne-am propus?

Pentru a evalua calitatea modelului dacă rezultatele sunt datorate modelului sau întâmplării, am implementat două teste în cele două faze ale proiectului.

Pilot - A/B Testing

Am împărțit magazinele în două grupuri comparabile ca număr de clienți, volum și valoare a vânzărilor etc. Primul grup, grupul de test, a folosit predicțiile modelului pentru a alege valoarea reducerilor. Cel de-al 2-lea grup, cel de control, a continuat să aplice reducerile în modul obișnuit (manual).

Test Grup Control Grup
Magazin 1,3 Produsul A Magazin 2,4 Produsul A
Magazin 1,3 Produsul B Magazin 2,4 Produsul B
Magazin 1,3 Produsul C Magazin 2,4 Produsul C

La jumătatea perioadei de test cele două grupuri s-au schimbat între ele, grupul de test devenind control și viceversa. La finalul testului prima concluzie e că e dificil să asiguri condițiile ideale pentru un A/B test:

Cea de-a doua concluzie a fost că soluția e viabilă dar e nevoie de o metodologie de test mai bună.

Producție - Block Design Testing

Folosind ce am învățat în faza pilot am schimbat metodologia de test de la "A/B Testing" la "Block Design Testing". În această metodă de test, în cazul fiecărui magazin, o serie de produse fac parte din grupul de test, iar altele in grupul de control. Astfel, locația magazinului și perioada testului nu mai influențează negativ capacitatea de a analiza rezultatele.

Test Grup Control Grup
Magazin 1, Produsul A Magazin 1, Produsul B
Magazin 2, Produsul B Magazin 2, Produsul C
Magazin 3, Produsul C Magazin 3, Produsul A

Concluzie

Tehnologia poate fi aplicată în probleme zilnice cu rezultate bune. Automatizarea proceselor e un câștig în sine întrucât elimină eroarea umană și permite implicarea în activități mai creative.

Factorul decisiv în succesul unui astfel de proiect e "explicabilitatea" soluției. Poate părea ciudat, dar tehnologia ML folosită reprezintă, probabil, cel mai puțin important factor pentru succesul proiectului. Da, rețelele neuronale sunt extrem de puternice, însă în multe cazuri umila regresie liniară e suficientă (și mai ieftină).

Închei prin a vă recomanda să inventariați datele pe care le aveți, încercați să le analizați și să vedeți ce puteți învăța din ele. E primul și cel mai important pas spre a folosi Machine Learning și AI.

VIDEO: NUMĂRULUI 125

Sponsori

  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • AboutYou
  • Colors in projects

VIDEO: EXTRA

Dragoș Cojocari a mai scris