Aanbevelingssystemen evalueren: de beste kiezen voor uw bedrijf

Samen met de eindeloze uitbreiding van e-commerce en online media in de afgelopen jaren, zijn er steeds meer Software-as-a-Service (SaaS) Recommender Systems (RS's) beschikbaar vandaag. In tegenstelling tot 5 jaar geleden, toen het gebruik van RS's een voorrecht was van grote bedrijven om hun eigen RS in eigen huis te bouwen, een enorm budget uitgeven aan een team van datawetenschappers, maakt de populariteit van SaaS-oplossingen tegenwoordig het betaalbaar om aanbevelingen te gebruiken, zelfs voor kleine en middelgrote grote bedrijven. Een vraag waarmee CTO's van dergelijke bedrijven worden geconfronteerd bij het zoeken naar de juiste SaaS RS is: welke oplossing is de beste? Ervan uitgaande dat u nog steeds geen RS hebt of niet tevreden bent met uw huidige RS, welke oplossing moet u dan kiezen?

In dit artikel zal ik twee benaderingen behandelen:

  • Offline evaluatie in academische wereld (plus de Netflix-prijs), op zoek naar lage voorspellingsfouten (RMSE / MAE) en een hoge Recall / Catalog-dekking. TLDR; weet alleen dat deze maatregelen bestaan ​​en dat je ze waarschijnlijk niet wilt gebruiken. Maar ik geef nog steeds een korte samenvatting van hen voor het geval u geïnteresseerd bent.
  • Online evaluatie in de zakenwereld, op zoek naar hoge klantlevensduurwaarden (CLV), A / B-testen, CTR, CR, ROI en QA doorlopen. Lees dit gedeelte als u serieus aanbevelingen overweegt om uw bedrijf te stimuleren.

The Offline World = How Academics Do It?

RS's worden al tientallen jaren onderzocht in academisch onderzoek. Er zijn veel onderzoeken die verschillende algoritmen introduceren, en om de algoritmen vergelijkbaar te maken, gebruiken ze academische maatregelen. We noemen deze maatregelen de offline maatregelen. Je zet niets in productie, je speelt gewoon met de algoritmen in je sandbox en stemt ze af volgens deze maatregelen. Ik heb persoonlijk veel naar deze maatregelen onderzocht, maar vanuit het perspectief van vandaag zijn ze nogal prehistorisch. Maar zelfs in de middeleeuwen van 2006 in de beroemde Netflix-prijs, is een puur academische maatregel genaamd de RMSE (root mean squared error) gebruikt.

Om kort uit te leggen hoe het werkt, veronderstelt het dat uw gebruikers uw producten expliciet beoordelen met bijvoorbeeld het aantal sterren (1 = sterke afkeer, 5 = sterke zoals), en u hebt een aantal van dergelijke beoordelingen (records waarin staat dat gebruiker een beoordeeld item X heeft met Y-sterren) uit het verleden. Er wordt een techniek gebruikt die de gesplitste validatie wordt genoemd: je neemt slechts een subset van deze beoordelingen, zeg 80% (de treinset genoemd), bouw de RS erop en vraag de RS vervolgens om de beoordelingen te voorspellen voor de 20% die je hebt verborgen (de testset). En dus kan het gebeuren dat een testgebruiker een item met 4 sterren beoordeelde, maar uw model voorspelt 3,5, vandaar dat het een fout van 0,5 op die rating heeft en dat is precies waar RMSE vandaan komt. Vervolgens bereken je gewoon het gemiddelde van de fouten uit de hele testset met behulp van een formule en krijg je een eindresultaat van 0,71623. BINGO! Dat is hoe goed (of, beter gezegd, slecht) je RS is. Of u kunt ook een andere formule gebruiken en de MAE (gemiddelde absolute fout) krijgen, die enorme fouten (echte 4 sterren, voorspelde 1 ster) niet zoveel bestraft, dus u zou slechts 0,6134 kunnen krijgen.

Een klein nadeel hier is dat dergelijke gegevens in de echte wereld bijna niet bestaan, of er in ieder geval te weinig van zijn.

Gebruikers zijn te lui en beoordelen niets. Ze openen gewoon een webpagina en als ze het leuk vinden wat ze zien, kunnen ze het kopen / consumeren; als het zuigt, vertrekken ze net zo snel als ze kwamen. En dus hebt u alleen zogenaamde impliciete beoordelingen in uw webserverlogboek of een database met aankopen en kunt u de fout aantal sterren niet meten, simpelweg omdat er geen sterren zijn. U hebt alleen +1 = gebruiker een detail bekeken of een product gekocht, en meestal niets anders. Soms worden dit de unaire beoordelingen genoemd, die je kent van de "Vind ik leuk" -knop van Facebook: de beoordeling is positief of onbekend (de gebruiker weet misschien niet dat de inhoud bestaat).

U kunt de split-validatie van dergelijke gegevens nog steeds gebruiken, zelfs voor uw eigen offline vergelijking van SaaS-adviseurs. Stel dat u bijvoorbeeld uw aankoopdatabase neemt, geschiedenis van 80% gebruikers bij de RS indient en vervolgens voor elke testgebruiker slechts enkele aankopen indient en de RS vraagt ​​om de rest te voorspellen. Mogelijk hebt u 4 gekochte items verborgen en vraagt ​​u de RS om 10 items. U kunt een nauwkeurigheid van 0%, 25%, 50%, 75% of 100% krijgen voor die gebruiker, afhankelijk van hoeveel van de verborgen 4 in de aanbevolen 10 verscheen. En deze nauwkeurigheid wordt de terugroepactie genoemd. Je mag het gemiddeld over je hele testset en TADAAA! Je resultaat is 31.4159%, dat is hoe goed je RS is.

Nu, eerlijk gezegd, hoewel de Recall veel meer gezond is dan RMSE, brengt het nog steeds veel pijn met zich mee. Stel dat een testgebruiker 20 afleveringen van dezelfde tv-serie heeft bekeken en dat u de herinnering aan haar meet. Dus verberg je afleveringen # 18–20 en vraag je de RS om ze te voorspellen van # 1–17. Het is een vrij gemakkelijke taak omdat de afleveringen sterk verbonden zijn, dus je krijgt 100% recall. Heeft uw gebruiker nu iets nieuws ontdekt? Wil je haar zo'n inhoud helemaal aanbevelen? En wat levert u eigenlijk de hoogste zakelijke waarde op? Zeg in een online winkel, wilt u alternatieven of accessoires aanbevelen? Je zou het gevoel moeten krijgen dat je op een heel dun ijs komt met recall.

En nog een geheim zal ik u vertellen: in sommige gevallen (niet altijd, hangt af van uw bedrijf!), Is het een eerlijke strategie om alleen de wereldwijd meest populaire items (oftewel bestsellers) aan te bevelen om een ​​redelijke terugroepactie te bereiken. Dus hier komt de dekking van de catalogus. Wenst u dat uw gebruikers nieuwe en nieuwe inhoud blijven ontdekken om loyaal te blijven? Dan wilt u misschien zoveel mogelijk verschillende artikelen aanbevelen. In het eenvoudigste geval, om de catalogusdekking te berekenen, neemt u gewoon uw testgebruikers, vraagt ​​u om aanbeveling voor elk van hen en zet u alle aanbevolen items samen. U krijgt een grote reeks verschillende items. Deel de grootte van deze set door het totale aantal items in je hele catalogus, en je krijgt ... 42.125%! Dat is het deel van de items dat je RS ooit kan aanbevelen.

Overweeg nu een bestseller-model. Het heeft misschien een heel goede terugroepactie, maar bijna nul dekking (5 constanten items?). En neem een ​​willekeurige aanbeveling. Het heeft bijna nul terugroepactie en 100% dekking. Misschien heb je het gevoel dat je een compromis wilt.

De bovenstaande afbeelding komt uit mijn (nu erg verouderde) oorspronkelijke onderzoek. U ziet ongeveer 1000 verschillende RS-modellen getekend in het Recall-Coverage-vlak. Geeky, is het niet? :) Je voelt je misschien duizelig bij het kiezen van de beste, maar ik hoop dat je het gevoel hebt dat het kiezen van iets uit de rechterbovenhoek ("Pareto-optimale voorkant") een goede keuze kan zijn.

Om uw offline schatting nog robuuster te maken, kunt u kruisvalidatie (Xval) gebruiken in plaats van split-validatie. Verdeel uw gebruikers in 10 vouwen en ga in lus: neem altijd 9 vouwen om het model te bouwen en gebruik de resterende 1 vouw om de validatie uit te voeren. Gemiddeld de resultaten over deze 10 runs.

Nu zou je kunnen zeggen: hoe zit het met mijn bedrijf? Het meten van terugroepactie en dekking is misschien prima, maar hoe verhouden deze zich tot mijn KPI's?

En je hebt gelijk. Om SaaS RS op de X-as en $$$ op de Y-as te plaatsen, moeten we de offline wereld verlaten en de productie ingaan!

De online wereld: volg de voorbeelden van slimme CTO's

Het bovenstaande gedeelte ging over het meten van de kwaliteit van de RS voordat deze in productie gaat, nu is het tijd om te praten over zakelijke KPI's.

Terwijl we in de offline evaluatie meestal de split-validatie gebruiken, is in de online evaluatie de A / B-test (of multivariate test) de meest prominente benadering van vandaag. Je kunt enkele verschillende RS's integreren, je gebruikers in groepen verdelen en de RS's in gevecht brengen. Een beetje duur, omdat het je ontwikkelingsbronnen verbruikt, dus je kunt de geschatte moeilijkheid van integratie en toekomstige aanpassingen / aanpassingen kosten gebruiken als een van je maatregelen, die a-priori de pool van kandidaten kunnen verminderen.

Laten we nu zeggen dat u de integratie bij de hand hebt en uw online gebruikers kunt verdelen in A / B-testgroepen. Je kunt ofwel je eigen hashing van hun UID-cookies gebruiken, of daarvoor een tool gebruiken (bijvoorbeeld VWO, Optimizely of zelfs GA's, hoewel de laatste optie een beetje pijnlijk is). Om het experiment uit te voeren, moet u een goede plek op uw website / applicatie bepalen waar u de aanbevelingen kunt testen, omdat u zeker niet de volledige integratie van alle kandidaat-RS's vroeg in de pilot wilt doen, toch? Als u weinig verkeer heeft, moet u er rekening mee houden dat de geselecteerde plaats zichtbaar genoeg moet zijn om significante resultaten te verzamelen. In het tegenovergestelde geval, als u veel verkeer heeft, kunt u een conservatieve strategie kiezen om bijvoorbeeld slechts 20% van uw verkeer vrij te geven voor het testen, zodat u uzelf en de rest 80% gebruikers veilig houdt in het geval dat sommige kandidaat-RS's volledig gebroken zijn en vreemde dingen aanbevelen.

Stel dat de hele zaak draait. Wat te meten? De eenvoudigste maatregelen zijn de Click-Through Rate (CTR) en de Conversion Rate (CR) van de aanbevelingen.

Set van N aanbevelingen 20 keer weergegeven, waarvan 3 keer dat een gebruiker op ten minste een van de aanbevolen items heeft geklikt? Dan is uw CTR 15%. Inderdaad, klikken is leuk, maar het heeft de gebruiker waarschijnlijk naar een detailpagina geleid en je wilt misschien weten wat er daarna gebeurde. Vond de gebruiker de inhoud echt interessant? Heeft ze de hele video bekeken, naar het hele nummer geluisterd, het hele artikel gelezen, de vacature beantwoord, het product in de winkelwagen geplaatst en het daadwerkelijk besteld? Dit is de conversieratio = het aantal aanbevelingen dat zowel u als uw gebruiker blij heeft gemaakt.

Voorbeeld: Recombee KPI-console

CTR en CR kunnen u een goede schatting geven van de prestaties van de aanbevelaar, maar u moet voorzichtig blijven en aan uw product blijven denken. Mogelijk voert u een nieuwsportaal uit en plaatst u het laatste nieuws op de startpagina. Dit levert u misschien niet de hoogst mogelijke CTR op, maar het behoudt de kwaliteit en het gevoel dat u en uw gebruikers over uw service hebben. Nu kunt u daar een RS plaatsen en deze kan verschillende inhoud tonen, zoals gele journalistieke artikelen of grappige artikelen over "zeer snelle honden die met ongelooflijke hoge snelheden lopen". Dit kan uw onmiddellijke CTR met 5 keer verhogen, maar het zal uw afbeelding beschadigen en u kunt uw gebruikers op de lange termijn verliezen.

Hier komt de empirische evaluatie van de RS's. Start gewoon een nieuwe sessie met lege cookies, simuleer het gedrag van een gebruiker en controleer of de aanbevelingen gezond zijn. Als je een QA-team hebt, ga ze dan aan de slag! Empirische evaluatie is tegelijkertijd ingewikkeld en gemakkelijk. Het is ingewikkeld, omdat het geen cijfers oplevert die je op het productbord zou kunnen presenteren. Maar het is ook gemakkelijk, want dankzij je menselijke intuïtie zul je eenvoudig herkennen welke aanbevelingen goed en welke slecht zijn. Als u kiest voor een vreemd werkende aanbeveling, brengt u uzelf in de toekomst veel problemen, zelfs als de CTR / CR momenteel hoog zijn.

Maar naast kwaliteit moet u natuurlijk ook rekening houden met de Return of Investment (ROI).

Simpel gezegd, u hebt misschien vastgesteld dat de A / B-testvouw # 1 leidde tot een toename van de conversieratio van X% ten opzichte van basislijnvouw # 0 (uw huidige oplossing), dat uw marge $ Y was voor een gemiddeld succesvol aanbevolen item, en dat het Z-aanbevelingsverzoeken vereiste om dat te bereiken. Doe de wiskunde, projecteer de uitgaven / inkomsten voor het geval u de gegeven RS op 100% van uw verkeer plaatst, ook te integreren in andere delen van uw website / app.

Eén waarschuwing over ROI-berekening: het is erg wazig en hangt af van een groot aantal onbekenden: zal de CR hetzelfde zijn op andere plaatsen op mijn website / app? (Eenvoudig antwoord = nee, dat doet het niet, verschillende plaatsen hebben verschillende CTR / CR). Hoe zal CR veranderen als de aanbevelingen op een min of meer aantrekkelijke positie worden gezet? (Eenvoudig antwoord = veel). Hoe zal de CR evolueren in de tijd? Zullen de gebruikers de aanbeveling leren gebruiken en vertrouwen, of zal de CR weigeren?

Dit leidt tot de ultieme maar moeilijkste maatregel: de Customer Lifetime Value (CLV). U bent op zoek naar de win-win situatie. U wilt dat uw gebruikers uw service leuk vinden, zich comfortabel, gelukkig en bereid voelen om terug te keren. Hand in hand daarmee wil je dat de RS de UX verbetert, de gebruikers helpt interessante inhoud / producten te vinden wat ze willen. Hoe een hoge CLV bereiken met behulp van een RS?

Wel, geen eenvoudig advies hier. Je moet zoeken naar leuke aanbevelingen met een hoge empirische kwaliteit en een redelijk positieve ROI. Naar mijn ervaring komt de aardigheid van aanbevelingen meestal overeen met de bedrijfswaarde, zodat u niet wordt geplaatst door klachten van uw QA-team / CEO. En als je merkt dat de business case positief is, heb je gevonden wat je zocht :)

Gevolgtrekking

Ik heb geprobeerd de belangrijkste aspecten van het evalueren van RS's te behandelen. Je hebt misschien gezien dat het geen gemakkelijke taak is en dat er veel te overwegen is, maar ik hoop dat je in ieder geval enkele aanwijzingen hebt gekregen om je weg in het gebied te vinden. U kunt RS's offline testen, zelfs voordat u in productie gaat, of doe productie A / B-testen met CTR / CR en ROI-schatting. Neem altijd wat QA op, omdat alleen CTR / CR / ROI misleidend kan zijn en geen compatibiliteit met de visie van uw product kan garanderen.

Veel is weggelaten alleen om de tekst eindig lang te houden. Naast CTR / CR / ROI / kwaliteit van de aanbevelingen, moet u de algemene mogelijkheden van de overwogen RS snel bekijken. Misschien wilt u in de toekomst aanbevelingen opnemen in uw e-mailcampagnes. Zal het werken? Heeft het mogelijkheden om aanbevelingen te rouleren zodat een bepaalde gebruiker niet dezelfde set aanbevelingen in elke e-mail ontvangt? Kun je aan al je zakelijke vereisten voldoen, kun je de aanbevelingen beïnvloeden, een bepaald type inhoud stimuleren, filteren op basis van verschillende criteria? Dit zijn onderwerpen die niet worden behandeld, maar je kunt het gevoel hebben dat je ze ook wilt overwegen.

De auteur is mede-oprichter in Recombee, een geavanceerde SaaS Recommendation Engine.