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.
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?
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.
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.
Date;
Cunoașterea domeniului și capacitatea de a analiza datele;
Selecția modelului;
Operaționalizarea modelului;
Planul de test și monitorizarea soluției;
Î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ă.
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.
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.
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.
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.
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.
Î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.
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.
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:
Cele două perioade alte testului pot conține evenimente deosebite (ex: sărbători, pandemie etc.) sau anotimpuri diferite ce favorizează un alt fel de consum;
Factorul uman - personalul din magazin aplică reducerile inconsecvent;
Cea de-a doua concluzie a fost că soluția e viabilă dar e nevoie de o metodologie de test mai bună.
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 |
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.
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
