Evaluering af anbefalingssystemer: Valg af det bedste til din virksomhed

Sammen med den uendelige udvidelse af e-handel og online medier i de sidste år er der flere og flere Software-as-a-Service (SaaS) anbefalingssystemer (RS) tilgængelige i dag. I modsætning til for 5 år siden, når brugen af ​​RS var et privilegium for store virksomheder, der bygger deres eget RS internt og brugte et enormt budget på et team af datavidenskabsmænd, gør dagens popularitet af SaaS-løsninger det overkommeligt at bruge anbefaling, selv for små og mellemstore -store virksomheder. Et spørgsmål, som CTO'er for sådanne virksomheder står overfor, når de leder efter den rigtige SaaS RS er: Hvilken løsning er bedst? Hvis du antager, at du stadig ikke har en RS, eller at du ikke er tilfreds med din nuværende RS, hvilken løsning skal du vælge?

I denne artikel vil jeg dække to tilgange:

  • Offlineevaluering i den akademiske verden (plus Netflix-prisen), der søger efter lav forudsigelsesfejl (RMSE / MAE) og høj dækning af Recall / Catalog. TLDR; bare ved, at disse foranstaltninger findes, og at du sandsynligvis ikke vil bruge dem. Men jeg giver stadig et kort resumé af dem, hvis du er interesseret.
  • Online evaluering i erhvervslivet, søgning efter høje kundelivstidsværdier (CLV), gennemgå A / B-test, CTR, CR, ROI og QA. Du bør læse dette afsnit, hvis du seriøst overvejer anbefalinger, der øger din virksomhed.

The Offline World = Hvordan akademikere gør det?

RS er blevet undersøgt i årtier inden for akademisk forskning. Der er mange forskningsartikler, der introducerer forskellige algoritmer, og for at gøre algoritmerne sammenlignelige bruger de akademiske mål. Vi kalder disse mål for de offline mål. Du lægger ikke noget i produktion, du spiller bare med algoritmerne i din sandkasse og finjusterer dem i henhold til disse mål. Jeg har personligt undersøgt disse mål meget, men ud fra min dags synspunkt er de temmelig forhistoriske. Men selv i middelalderen af ​​2006 i den berømte Netflix-pris er der anvendt en rent akademisk foranstaltning kaldet RMSE (root mean squared error).

Bare for kort at forklare, hvordan det fungerer, antager det, at dine brugere eksplicit vurderer dine produkter med sig antallet af stjerner (1 = stærk modvilje, 5 = stærk ligesom), og du har en masse sådanne ratings (poster, der siger, at brugeren er en klassificeret vare X med Y-stjerner) fra fortiden. Der bruges en teknik kaldet split validation: du tager kun en undergruppe af disse ratings, siger 80% (kaldes togsættet), bygger RS ​​på dem og beder derefter RS ​​om at forudsige ratings på de 20%, du har skjult (testsættet). Og så kan det ske, at en testbruger bedømte en vare med 4 stjerner, men din model forudsiger 3,5, og derfor har den en fejl på 0,5 på denne bedømmelse, og det er præcis, hvor RMSE kommer fra. Derefter beregner du bare gennemsnittet af fejlene fra hele testsættet ved hjælp af en formel og får et slutresultat på 0.71623. BINGO! Det er, hvor god (eller mere præcist, dårlig) din RS er. Eller du kan også bruge anden formel og få MAE (gennemsnitlig absolut fejl), som ikke straffer store fejl (ægte 4 stjerner, forudsagt 1 stjerne) så meget, så du får muligvis kun 0,6134.

En lille ulempe her er, at sådanne data næsten ikke findes i den virkelige verden, eller i det mindste er der for få af dem.

Brugere er for doven, og de vurderer ikke noget. De åbner bare en webside, og hvis de kan lide det, de ser, kan de måske købe den / forbruge den; hvis det suger, forlader de så hurtigt, som de kom. Og så har du kun såkaldte implicit ratings i din web-server-log eller en database med køb, og du kan ikke måle antallet af stjerner-fejl på dem, simpelthen fordi der ikke er nogen stjerner. Du har kun +1 = bruger vist en detalje eller købt et produkt, og typisk intet andet. Nogle gange kaldes disse unary ratings, som du kender fra Facebooks “Like” -knap: klassificeringen er enten positiv eller ukendt (brugeren ved muligvis ikke, at indholdet findes).

Du kan stadig bruge split-valideringen på sådanne data, selv til din egen offline sammenligning af SaaS-anbefalere. Lad os sige, at du f.eks. Tager din købedatabase, indsender historie på 80% brugere til RS, og indsender derefter kun et par køb for hver testbruger og beder RS ​​om at forudsige resten. Du har muligvis skjult 4 købte varer og bede RS om 10 varer. Du kan få 0%, 25%, 50%, 75% eller 100% nøjagtighed for denne bruger, afhængigt af hvor mange af de skjulte 4, der optrådte i den anbefalede 10. Og denne nøjagtighed kaldes Recall. Du kan gennemsnit det i hele dit testsæt og TADAAA! Dit resultat er 31.4159%, det er hvor god din RS er.

Nu ærligt, selvom Recall er meget mere fornuftig end RMSE, bringer det stadig meget smerter. Lad os sige, at en testbruger så 20 episoder af den samme tv-serie, og du måler tilbagekaldelse af hende. Så du skjuler episoder nr. 18–20 og beder RS ​​om at forudsige dem fra nr. 1–17. Det er en ganske let opgave, da episoderne er stærkt forbundet, så du får 100% tilbagekald. Opdagede din bruger noget nyt? Vil du overhovedet anbefale hende et sådant indhold? Og hvad bringer den højeste forretningsværdi til dig alligevel? Sig i online butik, vil du anbefale alternativer eller tilbehør? Du skulle føle, at du kommer på en meget tynd is med tilbagekaldelse.

Og en hemmelighed mere vil jeg fortælle dig: I nogle tilfælde (ikke altid, afhænger af din virksomhed!), Er det en retfærdig strategi at kun anbefale de globalt mest populære varer (f.eks. Bestsellere) for at opnå en rimelig tilbagekaldelse. Så her kommer katalogdækningen. Ønsker du, at dine brugere fortsat opdager nyt og nyt indhold for at forblive loyale? Så vil du måske anbefale så mange forskellige genstande som muligt. I det enkleste tilfælde for at beregne katalogdækningen skal du bare tage dine testbrugere, bede om anbefaling for hver enkelt af dem og sætte alle de anbefalede emner sammen. Du får et stort sæt forskellige genstande. Del størrelsen på dette sæt med det samlede antal varer i hele kataloget, og du får ... 42,125%! Det er den del af varer, som din RS nogensinde kan anbefale.

Overvej nu en bestseller-model. Det har måske en ganske god tilbagekaldelse, men næsten nul dækning (5 konstante poster?). Og tag en tilfældig anbefaling. Det har næsten nul tilbagekaldelse og 100% dækning. Du kan måske føle, at du kunne lide noget kompromis.

Ovenstående billede kommer fra min (nu meget forældede) originale forskning. Du kan se omkring 1000 forskellige RS-modeller tegnet i Genkaldækningsplanet. Nørdede, er det ikke? :) Du føler dig måske svimmel, når du vælger den bedste, men jeg håber, du føler, at det at vælge nogle fra øverste højre hjørne (“Pareto-optimal front”) kan være et godt valg.

For at gøre dit offline estimat endnu mere robust kan du bruge krydsvalidering (Xval) i stedet for splitvalidering. Opdel bare dine brugere i 10 folder og gå i loop: Tag altid 9 folder for at opbygge modellen, og brug den resterende 1 fold til at udføre valideringen. Gennemsnittet af resultaterne i løbet af disse 10 kørsler.

Nu kan du sige: Hvad med min virksomhed? Måling af tilbagekaldelse og dækning kan være fint, men hvordan er de relateret til mine KPI'er?

Og du har ret. For at sætte SaaS RS på X-aksen og $$$ på Y-aksen, er vi nødt til at forlade offlineverdenen og gå i produktion!

Onlineverdenen: Følg eksemplerne på smarte CTO'er

Ovenstående afsnit handlede om at måle kvaliteten af ​​RS, inden den går i produktion, nu er det tid til at tale om forretningsmæssige KPI'er.

Mens vi i den offline evaluering typisk bruger split-valideringen, er A / B-testen (eller multivariat test) i onlineevalueringen dagens mest fremtrædende tilgang. Du kan integrere få forskellige RS'er, dele dine brugere i grupper og sætte RS'erne i kamp. Lidt dyrt, fordi det forbruger dine udviklingsressourcer, så du kan bruge de anslåede vanskeligheder ved integration og fremtidige tilpasninger / justeringsomkostninger som et af dine mål, hvilket muligvis forinden reducerer puljen af ​​kandidater.

Lad os nu sige, at du har integrationen klar og er i stand til at opdele dine online brugere i A / B-testgrupper. Du kan enten bruge din egen hashing af deres UID-cookies, eller bruge et eller andet værktøj til det (f.eks. VWO, Optimizely eller endda GA'er, selvom den sidste mulighed er lidt smertefuld). For at udføre eksperimentet, skal du bestemme et godt sted på dit websted / din applikation, hvor du skal teste anbefalingerne, fordi du bestemt ikke ønsker at gøre den fulde integration af alle kandidat-RS'erne tidligt i pilotfasen, ikke? Hvis du har lille trafik, skal du huske, at det valgte sted skal være synligt nok til at indsamle betydelige resultater. I det modsatte tilfælde, hvis du har enorm trafik, kan du vælge en konservativ strategi for f.eks. Kun at frigive 20% af din trafik til testen, holde dig selv og resten 80% brugere i sikkerhed, hvis nogle af kandidatens RS'er ville være helt ødelagt og anbefale underlige ting.

Antag, at det hele er i gang. Hvad skal man måle? De nemmeste målinger er klikfrekvensen (CTR) og konverteringsfrekvensen (CR) i anbefalingerne.

Viset sæt N-anbefalinger 20 gange, hvorfra 3 gange en bruger klikkede på mindst et af de anbefalede emner? Derefter er din CTR 15%. Faktisk er det rart at klikke, men det førte sandsynligvis brugeren til en detaljside, og du vil måske vide, hvad der skete dernæst. Fandt brugeren virkelig indholdet interessant? Så hun hele videoen, lytter til hele sangen, læste hele artiklen, besvarede jobtilbudet, lagde produktet i indkøbskurven og faktisk bestilte det? Dette er konverteringsfrekvensen = antallet af anbefalinger, der gjorde både dig og din bruger glad.

Eksempel: Recombee KPI-konsol

CTR og CR kan give dig et godt skøn over anbefalernes ydeevne, men du skal være forsigtig og fortsat tænke på dit produkt. Du kører muligvis en nyhedsportal og lægger de nyeste nyheder på hjemmesiden. Dette giver dig muligvis ikke den højest mulige CTR, men det opretholder kvaliteten og den følelse, du og dine brugere har om din service. Nu kan du sætte en RS der, og det kan begynde at vise andet indhold, såsom gule journalistikartikler eller sjove artikler om “meget hurtige hunde, der kører i utrolige hastigheder”. Dette kan øge din øjeblikkelige CTR med 5 gange, men det vil skade dit image, og du kan miste dine brugere på lang sigt.

Her kommer den empiriske evaluering af RS'erne. Start bare en ny session med tomme cookies, simulere en brugers opførsel og kontroller, om anbefalingerne er sane. Hvis du har et QA-team, skal du få dem til jobbet! Empirisk evaluering er både kompliceret og let på én gang. Det er kompliceret, fordi det ikke producerer de numre, du kunne præsentere på produkttavlen. Men det er også let, for takket være din menneskelige intuition vil du simpelthen genkende, hvilke anbefalinger der er gode, og hvilke der er dårlige. Hvis du vælger en underligt fungerende anbefaling, sætter du dig selv i en masse fremtidige problemer, selvom CTR / CR er høj i øjeblikket.

Men selvfølgelig skal du bortset fra kvalitet bry sig om investeringsafkastet (ROI).

Kort sagt, har du måske bestemt at A / B-test fold # 1 førte til en stigning på X% i konverteringsfrekvens over baseline fold # 0 (din nuværende løsning), at din margen var $ Y for gennemsnitligt anbefalet produkt med succes og at det krævede Z-henstillingsanmodninger for at opnå det. Gør matematik, projicér udgifter / indkomster, hvis du lægger det givne RS på 100% af din trafik, og integrer også i andre sektioner på din webside / app.

Én advarsel om beregning af ROI: Den er meget uklar og afhænger af et stort antal ukendte: Vil CR være den samme på andre steder på min hjemmeside / app? (Enkelt svar = nej, det vil det ikke, forskellige steder har forskellige CTR / CR). Hvordan ændres CR, hvis placering af henstillingerne er mere eller mindre attraktiv? (Enkelt svar = meget). Hvordan vil CR udvikle sig i tide? Vil brugerne lære at bruge og stole på anbefalingen, eller vil CR afvise?

Dette fører til det ultimative, men alligevel mest vanskelige mål: Customer Lifetime Value (CLV). Du leder efter win-win-situationen. Du vil have, at dine brugere kan lide din service, skal føle sig komfortable, glade og villige til at vende tilbage. Hånd i hånd med det, du ønsker, at RS skal forbedre UX, hjælpe brugerne med at finde interessant indhold / produkter, hvad de kan lide. Hvordan nå man høj CLV ved hjælp af en RS?

Nå, ingen enkle råd her. Du skal søge efter pæne henstillinger med høj empirisk kvalitet og en rimelig positiv ROI. Efter min oplevelse svarer pænheden i anbefalinger typisk til forretningsværdien, og forhindrer dig i at blive bogført af klager fra dit QA-team / CEO. Og hvis du observerer, at forretningssagen er positiv, har du fundet det, du ledte efter :)

Konklusion

Jeg har forsøgt at dække de vigtigste aspekter ved evaluering af RS'er. Du har måske set, at det ikke er en nem opgave, og at der er meget at overveje, men jeg håber i det mindste gav dig nogle ledetråde for at finde din vej rundt i området. Du kan teste RS'er offline, selv før du går i produktion, eller foretage produktion A / B-test med CTR / CR og ROI estimat. Inkluder altid noget QA, fordi CTR / CR / ROI alene kan være vildledende og ikke garanterer kompatibilitet med visionen for dit produkt.

Meget er udeladt bare for at holde teksten færdig længe. Udover CTR / CR / ROI / kvaliteten af ​​anbefalingerne, skal du se hurtigt på de overordnede kapaciteter i RS, der overvejes. Du ønsker muligvis at medtage anbefalinger i dine e-mail-kampagner i fremtiden. Vil det arbejde? Har det evner til at rotere anbefalinger, så en given bruger ikke modtager det samme sæt anbefalinger i hver e-mail? Kan du tjene alle dine forretningskrav, kan du påvirke anbefalingerne, øge en eller anden form for indhold, filtrere det baseret på forskellige kriterier? Dette er emner, der ikke er dækket, men du føler måske, at du også vil overveje dem.

Forfatteren er medstifter af Recombee, en sofistikeret SaaS-anbefalingsmotor.