Evaluering av anbefalingssystemer: Velge det beste for bedriften din

Sammen med den uendelige utvidelsen av e-handel og online medier de siste årene, er det flere og flere Software-as-a-Service (SaaS) anbefalingssystemer (RS) som blir tilgjengelige i dag. I motsetning til for 5 år siden, når bruk av RS-er var et privilegium for store selskaper som bygger sitt eget RS-selskap og brukte et enormt budsjett på et team av dataforskere, gjør dagens popularitet av SaaS-løsninger det rimelig å bruke anbefaling selv for små og mellomstore store selskaper. Et spørsmål som CTOs for slike selskaper står overfor når de leter etter den rette SaaS RS er: Hvilken løsning er best? Hvis du antar at du fremdeles ikke har en RS, eller at du ikke er fornøyd med din nåværende RS, hvilken løsning bør du velge?

I denne artikkelen vil jeg dekke to tilnærminger:

  • Frakoblet evaluering i akademisk verden (pluss Netflix-prisen), søker etter lav prediksjonsfeil (RMSE / MAE) og høy dekning for tilbakekalling / katalog. TLDR; bare vet at disse tiltakene finnes, og at du sannsynligvis ikke vil bruke dem. Men jeg gir fortsatt en kort oppsummering av dem i tilfelle du er interessert.
  • Online evaluering i næringslivet, søker etter høye Customer Lifetime Values ​​(CLV), går gjennom A / B-testing, CTR, CR, ROI og QA. Du bør lese dette avsnittet hvis du seriøst vurderer anbefalinger som øker virksomheten din.

Offline World = Hvordan akademikere gjør det?

RS har blitt undersøkt i flere tiår i akademisk forskning. Det er mange forskningsartikler som introduserer forskjellige algoritmer, og for å gjøre algoritmene sammenlignbare bruker de faglige tiltak. Vi kaller disse tiltakene for frakoblede tiltak. Du legger ikke noe i produksjon, du spiller bare med algoritmene i sandkassen og finjusterer dem i henhold til disse tiltakene. Jeg har personlig forsket på disse tiltakene, men fra dagens synspunkt er de ganske forhistoriske. Men selv i middelalderen av 2006 i den berømte Netflix-prisen, er et rent akademisk tiltak kalt RMSE (root mean squared error) blitt brukt.

Bare for å kort forklare hvordan det fungerer, antar det at brukerne dine eksplisitt vurderer produktene dine med antallet stjerner (1 = sterk motvilje, 5 = sterk som), og du har en rekke slike rangeringer (poster som sier at brukeren har en rangert vare X med Y-stjerner) fra fortiden. Det brukes en teknikk som kalles delt validering: du tar bare en delmengde av disse vurderingene, sier 80% (kalt togsettet), bygger RS ​​på dem, og ber deretter RS ​​om å forutsi karakterene på de 20% du har skjult (testsettet). Og slik kan det hende at en testbruker vurderte en vare med 4 stjerner, men modellen din spår 3,5, derav har den en feil på 0,5 på den vurderingen, og det er akkurat der RMSE kommer fra. Da beregner du bare gjennomsnittet av feilene fra hele testsettet ved å bruke en formel og får et sluttresultat på 0.71623. BINGO! Det er hvor god (eller mer presist, dårlig) din RS er. Eller du kan også bruke en annen formel og få MAE (gjennomsnittlig absolutt feil), som ikke straffer enorme feil (ekte 4 stjerner, spådd 1 stjerne) så mye, slik at du kanskje bare får 0,6134.

En liten ulempe her er at slike data nesten ikke eksisterer i den virkelige verden, eller i det minste er det for få av dem.

Brukere er for late og de vil ikke rangere noe. De åpner bare en webside, og hvis de liker det de ser, kan de kjøpe den / konsumere den. hvis det suger, går de så fort som de kom. Og slik at du bare har såkalte implisitte rangeringer i din web-serverlogg eller en database med kjøp, og du kan ikke måle antall stjerner-feilen på dem, ganske enkelt fordi det ikke er noen stjerner. Du har bare +1 = bruker sett en detalj eller kjøpt et produkt, og, vanligvis, ingenting annet. Noen ganger kalles disse unary ratings, som du vet fra Facebooks "Like" -knapp: rangeringen er enten positiv eller ukjent (brukeren vet kanskje ikke at innholdet eksisterer).

Du kan fremdeles bruke delt validering på slike data, selv for din egen offline sammenligning av SaaS-anbefalere. Si at du tar for eksempel innkjøpsdatabasen din, sender inn historien til 80% brukere til RS, og sender deretter bare noen få kjøp for hver testbruker og ber RS ​​om å forutsi resten. Du har kanskje gjemt 4 kjøpte varer og be RS om 10 varer. Du kan få 0%, 25%, 50%, 75% eller 100% nøyaktighet for den brukeren, avhengig av hvor mange av de skjulte 4 som dukket opp i anbefalt 10. Og denne nøyaktigheten kalles Recall. Du kan gjennomsnittlig beregne det over hele testsettet og TADAAA! Resultatet ditt er 31.4159%, det er hvor god din RS er.

Nå, ærlig talt, selv om Recall er mye mer tilregnelig enn RMSE, gir det fortsatt mye smerte. Si at en testbruker så 20 episoder av den samme TV-serien, og du måler tilbakekall på henne. Så du skjuler episoder nr. 18–20 og ber RS ​​om å forutsi dem fra nr. 1–17. Det er ganske enkel oppgave ettersom episodene er sterkt koblet sammen, så du får 100% tilbakekall. Nå, oppdaget brukeren din noe nytt? Vil du anbefale henne et slikt innhold i det hele tatt? Og hva gir deg den høyeste forretningsverdien til deg? Si i nettbutikk, vil du anbefale alternativer eller tilbehør? Du skal føle at du kommer på en veldig tynn is med tilbakekalling.

Og en hemmelighet til kommer jeg til å fortelle deg: I noen tilfeller (ikke alltid, avhenger av virksomheten din!), Er det en rettferdig strategi å bare anbefale de globalt mest populære varene (f.eks. Bestselgere) for å oppnå rimelig tilbakekall. Så her kommer katalogdekningen. Ønsker du at brukere fortsetter å oppdage nytt og nytt innhold for å forbli lojale? Da kan det være lurt å anbefale så mange forskjellige elementer som mulig. I enkleste tilfelle, for å beregne katalogdekningen, tar du bare testbrukere, ber om anbefaling for hver enkelt av dem og setter alle de anbefalte varene sammen. Du skaffer deg et stort sett med forskjellige varer. Del størrelsen på dette settet med det totale antallet varer i hele katalogen, så får du ... 42,125%! Det er den delen av varene RS-en din kan anbefale.

Vurder nå en bestselgermodell. Det kan ha ganske god tilbakekalling, men nesten null dekning (5 konstanter elementer?). Og ta en tilfeldig anbefaling. Den har nesten null tilbakekalling og 100% dekning. Du kan føle at du vil ha noe kompromiss.

Bildet ovenfor kommer fra min (nå veldig utdaterte) originale forskning. Du kan se rundt 1000 forskjellige RS-modeller tegnet i Recall-Cover-flyet. Nerdete, er det ikke? :) Du kan føle deg svimmel når du velger den beste, men jeg håper du føler at det å velge noen øverst til høyre (“Pareto-optimal front”) kan være et godt valg.

For å gjøre ditt offline estimat enda mer robust, kan du bruke kryssvalidering (Xval) i stedet for delt validering. Del bare brukerne dine i 10 brett og gå i sløyfe: ta alltid 9 brett for å bygge modellen, og bruk den gjenværende 1 folden for å gjøre valideringen. Gjennomsnittlig resultatene over disse 10 løpene.

Nå kan du kanskje si: Hva med virksomheten min? Det kan være greit å måle tilbakekalling og dekning, men hvordan er de relatert til KPI-ene mine?

Og du har rett. For å sette SaaS RS på X-aksen og $$$ på Y-aksen, må vi forlate frakoblet verden og gå inn i produksjonen!

Online World: Følg eksemplene på smarte CTO-er

Ovennevnte seksjon handlet om å måle kvaliteten på RS før den går i produksjon, nå er det på tide å snakke om forretnings-KPI-er.

Mens vi i den offline evalueringen vanligvis bruker split-valideringen, er A / B-testing (eller multivariat testing) i den elektroniske evalueringen dagens mest framtredende tilnærming. Du kan integrere få forskjellige RS-er, dele brukerne dine i grupper og sette RS-ene i kamp. Litt kostbart, fordi det forbruker utviklingsressursene dine, slik at du kan bruke den estimerte vanskeligheten med integrering og fremtidige tilpasninger / justeringskostnader som et av tiltakene dine, noe som kan forhindre redusert antall kandidater.

Nå kan vi si at du har integrasjonen klar og er i stand til å dele online brukere i A / B-testgrupper. Du kan enten bruke din egen hashing av UID-informasjonskapslene dine, eller bruke et verktøy for det (for eksempel VWO, Optimizely, eller til og med GAs, selv om det siste alternativet er litt vondt). For å gjøre eksperimentet, bør du bestemme ett bra sted på nettstedet / applikasjonen din hvor du skal teste anbefalingene, fordi du helt sikkert ikke vil gjøre full integrering av alle kandidat-RS-er tidlig i pilotfasen, ikke sant? Hvis du har liten trafikk, må du huske at det valgte stedet må være synlig nok til å samle betydelige resultater. I motsatt tilfelle, hvis du har stor trafikk, kan du velge en konservativ strategi for å for eksempel slippe bare 20% av trafikken til testen, holde deg selv og resten 80% brukere i tilfelle noen av kandidatene vil vær helt ødelagt og anbefaler rare ting.

Anta at hele saken er i gang. Hva må jeg måle? De enkleste målene er klikkfrekvensen (CTR) og konverteringsfrekvensen (CR) for anbefalingene.

Viste sett med N-anbefalinger 20 ganger, hvorfra 3 ganger en bruker klikket på minst en av de anbefalte varene? Da er CTR-en din 15%. Faktisk er det fint å klikke, men det førte sannsynligvis brukeren til en detaljside, og det kan være lurt å vite hva som skjedde videre. Fant brukeren virkelig innholdet interessant? Så hun hele videoen, hørte på hele sangen, leste hele artikkelen, svarte på jobbtilbudet, la produktet i handlekurven og faktisk bestilte det? Dette er konverteringsfrekvensen = antall anbefalinger som gjorde både deg og brukeren din fornøyd.

Eksempel: Recombee KPI-konsoll

CTR og CR kan gi deg et godt estimat av anbefalingens ytelse, men du bør være forsiktig og fortsette å tenke på produktet ditt. Det kan hende du kjører en nyhetsportal og legger de nyhetene på hjemmesiden. Dette gir deg kanskje ikke den høyeste mulige CTR, men den opprettholder kvaliteten og følelsen du og du brukere har om tjenesten din. Nå kan du sette en RS der, og det kan begynne å vise annet innhold, for eksempel gule journalistikkartikler eller morsomme artikler om “veldig raske hunder som kjører i utrolige høye hastigheter”. Dette kan øke din umiddelbare CTR med 5 ganger, men det vil skade bildet ditt og du kan miste brukerne dine på lang sikt.

Her kommer den empiriske evalueringen av RS-ene. Bare start en ny økt med tomme informasjonskapsler, simulere atferden til en bruker og sjekk om anbefalingene er tilregnelige. Hvis du har et QA-team, få dem til jobben! Empirisk evaluering er både komplisert og lett på en gang. Det er komplisert, fordi det ikke gir noen tall du kan presentere på produkttavlen. Men det er også enkelt, fordi du, takket være din menneskelige intuisjon, ganske enkelt vil gjenkjenne hvilke anbefalinger som er gode og hvilke som er dårlige. Hvis du velger en underlig fungerende anbefaling, setter du deg selv i mye fremtidig trøbbel, selv om CTR / CR er høyt for øyeblikket.

Men selvfølgelig, foruten kvalitet, bør du bry deg om Return of Investment (ROI).

Enkelt sagt kan det hende du har bestemt at A / B-testen brett nr. 1 fører til en økning på X% i konverteringsfrekvens over grunnlinje fold # 0 (din nåværende løsning), at marginen din var $ Y for gjennomsnittlig vellykket anbefalt vare, og at den krevde Z-anbefalingsforespørsler for å oppnå det. Gjør matematikken, projiser utgiftene / inntektene i tilfelle du legger den gitte RS på 100% av trafikken din, og integrer deg også i andre deler av nettstedet / appen din.

Én advarsel om ROI-beregning: Den er veldig uklar og avhenger av et stort antall ukjente: Vil CR være den samme på andre steder på min hjemmeside / app? (Enkelt svar = nei, det vil ikke, forskjellige steder har forskjellig CTR / CR). Hvordan vil CR endre seg hvis du legger anbefalingene til mer eller mindre attraktiv stilling? (Enkelt svar = mye). Hvordan vil CR utvikle seg i tide? Vil brukerne lære å bruke og stole på anbefalingen, eller vil CR avvise?

Dette fører til det ultimate, men allikevel vanskeligste tiltaket: Customer Lifetime Value (CLV). Du leter etter vinn-vinn-situasjonen. Du vil at brukerne dine skal like tjenesten din, skal føle seg komfortable, glade og villige til å komme tilbake. Hånd i hånd med det, vil du at RS skal forbedre UX, hjelpe brukerne med å finne interessant innhold / produkter det de liker. Hvordan nå høy CLV ved hjelp av en RS?

Vel, ingen enkle råd her. Du bør søke etter fine anbefalinger med høy empirisk kvalitet og en rimelig positiv avkastning. Etter min erfaring tilsvarer det fine med anbefalinger vanligvis forretningsverdi, vil forhindre at du blir lagt ut av klager fra ditt QA-team / administrerende direktør. Og hvis du observerer at saken er positiv, har du funnet det du lette etter :)

Konklusjon

Jeg har prøvd å dekke de viktigste aspektene ved evaluering av RS. Du har kanskje sett at det ikke er en lett oppgave, og det er mye å vurdere, men jeg håper i det minste ga deg noen ledetråder for å finne veien rundt i området. Du kan teste RS-er frakoblet selv før du går i produksjon, eller gjøre A / B-produksjon med CTR / CR og ROI estimat. Inkluder alltid noe QA, fordi CTR / CR / ROI alene kan være misvisende og ikke garanterer kompatibilitet med visjonen til produktet ditt.

Mye er utelatt bare for å holde teksten finst lang. I tillegg til CTR / CR / ROI / kvalitet på anbefalingene, bør du se raskt på de overordnede mulighetene til RS som vurderes. Det kan være lurt å ta med anbefalinger i e-postkampanjene dine i fremtiden. Vil det fungere? Har den muligheter til å rotere anbefalinger, slik at en gitt bruker ikke får samme sett med anbefalinger i hver e-post? Kan du tjene alle virksomhetens krav, kan du påvirke anbefalingene, øke en slags innhold, filtrere det basert på forskjellige kriterier? Dette er emner som ikke er dekket, men du kan føle at du også vil vurdere dem.

Forfatteren er medgründer i Recombee, en sofistikert SaaS-anbefalingsmotor.