Artificiell intelligens och machine learning är på allas läppar. Jobb som automatiseras bort, världar som går under och räddas och branscher som vänds upp och ner. Även om en del hype kan tas med en nypa salt är tekniken här för att stanna och något att förhålla sig till.
Detta gäller såklart även produktutveckling. Många bolag har redan integrerat machine learning i sina produkter och arbetssätt.
Att börja tänka hur våra produkter fungerar med machine learning (ML) är också rätt annorlunda än hur vi gjort tidigare. Varför testa fram en lösning som funkar hyfsat för alla när vi kan personalisera och skapa helt datadrivna användarupplevelser?
Vi som har haft lyxen att jobba med machine learning i produktion ser tydligt hur tight ML och A/B-tester hänger ihop. Något som kan kännas kontraintuitivt, men i praktiken är det solklart.
Här tänkte vi gå igenom hur ML hänger ihop med A/B-tester:
- Hur används ML i produkter idag och framöver?
- Offline evaluation 101
- Kvalitativa tester för machine learning?
- Hur A/B-testas machine learning?
- Lyckas med experiment: Data, verktyg och kultur
Hur används ML i produkter idag och framöver?
Även om Large Language Models (LLM) som GPT och Llama är otroliga och överraskat många av oss, är ML sedan flera år en central del i produkter vi dagligen använder. Och det är inte bara LLM:s heller.
Här är några exempel, och fler lär det bli:
Rekommendationssystem
Vad: Utifrån användarbeteenden och preferenser ge personaliserade rekommendationer.
Exempel: Streamingtjänster som rekommenderar nytt innehåll, e-handlare som tipsar om produkter m.fl.
Prediktiv analys
Vad: Förutspå scenarios och behov som presenteras för användare.
Exempel: Väderappar som gissar väder, taxitjänster som förutspår var fordonen ska befinna sig m.fl.
Bildigenkänning
Vad: Utifrån bilder skapa säkrare och snabbare användarupplevelser.
Exempel: Säkra hur e-scootrar körs och parkeras, scanna ID-kort och ansikten i onboarding av nya användare.
Natural Language Processing (NLP) / Chat interfaces
Vad: Direkt identifiera och kategorisera vad kunder söker, pratar om eller har problem med för tillfället.
Exempel: Resesajter som tipsar om nya resor, språkappar som ger personaliserat lärande m.fl.
Prissättning
Vad: Dynamisk prissättning utifrån utbud och efterfrågan.
Exempel: Energilösningar som optimerar priset på din el, taxitjänster som prissätter utifrån utbud och efterfrågan.
Innehållsproduktion
Vad: Använda LLM:s för att generera text till produkter och marknadsföring.
Exempel: Pressmeddelandetjänster som automatiserar nyhetsskrivande, marknadsföringsassistenter som skapar kampanjer m.fl.
Fraud Detection och säkerhet
Vad: Upptäck skurkar och bedragare i realtid utifrån beteendemönster och parametrar som tidigare lett till negativa konsekvenser.
Exempel: Betaltjänster som bedömer riskprofil, uthyrningstjänster som identifierar skumma värdar och gäster.
Machine learning är och kommer alltså att vara en central del i hur vi bygger produkter och användarupplevelser.
Därtill också påverka interna processer, forskning, hur vi jobbar och det mesta annat. Men låt oss hålla oss till produktutveckling här.
Tekniken utvecklas lavinartat och görs allt mer tillgänglig och det är ingen vild gissning att product roadmaps och backlogs kommer innehålla allt fler ML-relaterade initiativ framöver.
Tid och resurser kommer att läggas här och frågan blir då: Hur kan vi veta att ML-initiativ skapar värde?
Testa innan ni går live – Offline evaluation 101
Det finns en rad olika sätt att utvärdera om hur en ML-modell funkar utan att släppa ut den i det vilda. Genom att utvärdera hur väl ML-modellen presterar utifrån etablerade mått och vinklar kan vi med historisk data få en bra bild av hur bra modellen är. Det kan gå att testas på minuter och timmar.
Låt oss titta på några exempel på hur ML kan utvärderas “offline” (varning för svengelska och jargon):
Modellens prestanda:
- Precision: Hur ofta gör modellen korrekta förutsägelser?
- Känslighet (Recall): Hur bra är modellen på att identifiera de faktiska positiva fallen?
- F1-score: En kombinerad bedömning av precision och känslighet.
- Generaliseringsförmåga: Hur funkar modellen med ny, tidigare osedd data?
Operationella aspekter
- Skalbarhet: Kan modellen hantera tillräckligt stora datamängder effektivt?
- Responsivitet: Hur snabbt kan modellen ge svar eller förutsägelser? Tillräckligt snabbt för att ge en vettig användarupplevelse?
- Robusthet: Hur väl klarar modellen av osäker eller ovanlig data?
- Cold start: Kan modellen ge tillräckligt bra rekommendationer även om den har begränsad historik om användaren, som i fallet för nya användare?
- Feedbackloop: Anpassar och förbättrar sig modellen baserat på användarfeedback?
Allmänt
- Förklarbarhet: Är det möjligt att förstå varför modellen fattar vissa beslut? Går det att förklara för andra delar av verksamheten som påverkas av vad modellen spottar ur sig?
- Diversitet och etik: Hur påverkas modellen av bias och agerar den på ett etiskt hållbart sätt?
- Kompatibilitet: Hur väl kan modellen integreras i befintliga system och tekniska lösningar?
- Kostnadseffektivitet: Vilka resurser krävs för att träna, driftsätta och underhålla modellen?
- Stöd och dokumentation: Finns det tillgängliga resurser och handledning för att fler på bolaget ska kunna arbeta med modellen?
Redan här kan vi bedöma om modellen överhuvudtaget går att ta live – vilket är kanon. Åtminstone med historisk data, men mer om det senare. Många ML-projekt kommer faktiskt inte ens förbi den här fasen.
Notering: Det finns bolag (Doordash t.ex.) som använder väldigt sofistikerade lösningar för simulering av data av testdata (men även de A/B-testar sina ML-modeller).
Allt detta till trots finns det fortfarande viktig information vi saknar: Vad händer när vi sätter detta framför riktiga användare?
Kvalitativa tester av machine learning?
En aspekt där ML-baserade initiativ skiljer sig från “vanliga” produktfeatures är att det är svårare att användningstesta på förhand, innan vi släpper till riktiga användare. När produkten anpassas och ser olika ut baserat på data blir traditionella kvalitativa testmetoder klurigare. Tänk att användningstesta en personaliseringsalgoritm som ser olika ut för alla.
Många gånger löser också ML problem som inte direkt syns i produkten vilket gör användartester på prototyper ytterligare mer komplext.
Kvalitativa metoder har dock en viktig roll att spela även i tider av ML för att förstå användarbehov, utforska viktiga features och bygga empati runt användarproblem. För att validera effekten av ML på er produkt och användare blir det dock svårt när produkten ser olika ut för varje användare.
Vi vill kunna veta hur vi skapar affärs- och användarvärde och där kan A/B-test hjälpa till.
Hur A/B-testas machine learning-modeller?
Alla offline-mått till trots använder många bolag A/B-tester som en viktig del för sin ML-utveckling. Mer om anledningarna varför nedan, men först går vi igenom hur A/B-tester används för utvärdera ML:
Testa modell vs ingen modell
A: En regelbaserad metod som rekommenderar produkter baserat på samma kategori-taggar.
B: En ML-modell som har tränats på användardata för att automatiskt avgöra vilka produkter som bör rekommenderas för varje enskild användare.
Mätpunkter: Klickfrekvens på rekommenderade produkter, konverteringsfrekvens, genomsnittlig varukorgsstorlek etc.
Testa två modeller mot varandra
T.ex. Vilken LLM ska vi använda för vår chatbot?
- Byggt med GPTs davinci-modell
- Byggt med Curie-modellen
Mätpunkter: Flest andel lösta supportärenden, nöjda och återkommande kunder, life time value
Testa byggstenarna till en modell
- Nuvarande modell
- Finetunead modell
- Högre temperatur
- Mer träningsdata
Mätpunkter: Faktiska affärsmått som t.ex. intäkter, vinst och life time value
Varför A/B-testa ML-modeller?
Egentligen är det samma anledningar som att A/B-testa “vanliga” features och förändringar i produkter. Men låt oss gå igenom det ur ett ML-perspektiv.
Beteenden förändras
Modeller tränas på historisk data och kan som sagt utvärderas utan att gå live. Men historisk data är inte en garanti för framtiden. Användares beteenden och preferenser ändras och det är först när vi sätter modellen framför deras ögon eller i deras händer som vi vet hur den faktiskt fungerar.
Verklig outcome och impact är viktigare än output – brukar det heta och det gäller även för ML-modeller.
Skapar modellen affärsvärde?
Vi vill förstå om vår nya modell skapar affärsvärde. Det vet vi först när vi släpper det till riktiga användare.
Vi tjänar inte pengar på finfin accuracy eller recall med vår testdata. Vi kan simulera och gissa så gott vi kan, men den riktiga utvärderingen sker i verkligheten. Riktiga affärsmått som faktiska ökade intäkter, minskade kostnader och lojala och nöjda användare, alltså.
Korrelation och kausalitet
Vi släpper vår nya modell och våra KPI:er skjuter i taket – Succé!
Samtidigt lanserar ni nya marknadsföringskampanjer, har en ny design och dessutom regnar det ute. Är det modellens förtjänst att alla mätetal pekar uppåt?
För att veta om det är just er nya modell som skapar affärsvärde vill vi kunna isolera ut den förändringen. Klassiskt case där A/B-tester briljerar, då vi kan testa en sak i taget och förstå effekten – allt annat lika.
Riskminimera
Vi nämnde att kvalitativa användartester blir svårare med ML-baserade features ovan, och det gäller även generell testning/QA. Det kan vara svårt att veta och testa alla möjliga sätt en ML-modell påverkar användarupplevelsen. Det ökar risken för att vi släpper något som får oönskade effekter.
Här skiner A/B-tester (eller gradual rollouts och feature flagging). Genom att testa smått på en delmängd av era användare minskar risken för hur många användare som påverkas av er virriga personaliseringssnurra eller osköna chatbot.
Rättfärdiga underhåll
Att lägga till ny funktionalitet kommer oftast med en kostnad av underhåll. Mer kod, mer komplexitet.
Detta kan vara än mer aktuellt för just ML-features. För att monitorera att ML fungerar i produktion krävs både infrastruktur och tid. Även om ML Ops är ett fält på frammarsch bör man räkna med en hel del underhållskostnader när ni produktionssätter.
Då vill ni veta att uppsidan är värd kostnaden och det kan A/B-tester hjälpa er bevisa.
För att förbättra modellen
Testa olika byggstenar i en modell och förstå hur det slår i praktiken. Ny träningsdata, andra features, snabbare modell. Genom att isolera ut förändringar ni gör på själva modellen kan ni få förståelse för hur det påverkar användarupplevelse och affär.
Tack vare smart feature engineering är er nya sökalgoritm är 20% bättre i teorin men kanske bara ger 0.01% bättre hittbarhet jämfört med den tidigare. Detta är ju inget att fira, men samtidigt lär vi oss att lägga tid på feature engineering kanske inte är den byggstenen vi ska prioritera för kommande utveckling.
Det är också lätt att vi bygger in vår egen bias i utvecklingen av våra ML-modeller. Genom en utvärdering baserad på experiment kan vi upptäcka och mäta detta. Vi kan sedan justera våra modeller eller träningsdata för att minska påverkan av våra egna antaganden. Genom att göra detta säkerställer vi att våra ML-produkter inte bara replikerar våra fördomar, utan lär sig och utvecklas på ett mer balanserat och rättvist sätt.
Lyckas med experiment och ML: Data, verktyg och kultur
Så för att lyckas med ML-initativ bör experiment vara en del i er verktygslåda.
Att lyckas med experiment är något vi på Signific jobbat massvis med och pratat om både här, där och med vår Per.
Det är lika delar en utmaning av data, verktyg/infrastruktur och kultur som krävs för att få till en effektiv process för experiment och A/B-tester.
Molnplattformar gör det möjligt för allt fler bolag att samla in stora mängder data och analysera A/B-test på ett korrekt sätt. Men för att lyckas med både ML och experiment kräver det också att ert data håller kvalité och finns tillgänglig
På teknik- och infrastruktursidan händer det massor av spännande saker på A/B-testområdet med nya plattformar som Eppo och Spotifys smyglansering av Confidence m.fl.
Men precis som för ML löser inte tekniken allt utan det är också en fråga om kultur och process för att bli en lärande, experimenterande organisation.
Vi har varit med och hjälpt både små och stora bolag med just detta.
Vi hörs gärna och snackar hur ni kan få ihop ML och A/B-tester. Skicka ett mail till martina@signific.se eller hugg tag i Max på Linkedin så tar vi gärna ett möte.
Vill du jobba med detta? Vi söker vassa, nyfikna datanördar.