Aanbevelingssysteem

Wat is een aanbevelingssysteem?

Een aanbevelingssysteem kiest een handvol artikels uit een grote catalogus en zet die in een bepaalde volgorde voor één persoon. Dat is de hele opdracht. Het blok onder een product in een webshop, het volgende artikel op een nieuwssite, het wisselstuk dat past op de machine die iemand net bestelde, de drie extra's die een vertegenwoordiger ziet terwijl hij een offerte opmaakt: de catalogus verschilt, het probleem niet.

Bij zoeken vertelt de klant zelf wat hij wil. Een aanbevelingssysteem moet gokken, op basis van wat deze persoon eerder deed en wat gelijkaardige klanten deden.

De vier aanpakken die je tegenkomt

Populariteit. Toon iedereen dezelfde toppers, eventueel per categorie. De documentatie van Amazon Personalize zegt om een Popularity-Count model te trainen, dat de K populairste artikels aanbeveelt, puur als vergelijkingsbasis. Sla je die stap over, dan kan je achteraf niet zeggen of jouw model beter scoorde dan de eigen toptien van de winkel.

Content-based filtering. Beschrijf elk artikel met kenmerken (categorie, merk, prijsklasse, materiaal, compatibiliteit) en beveel artikels aan die lijken op wat deze klant al kocht. De machine learning cursus van Google geeft er twee voordelen aan: het model heeft geen data over andere gebruikers nodig, en het kan nicheartikels aanbevelen waar bijna niemand anders naar kijkt. De kenmerken worden met de hand bedacht, dus het model is nooit beter dan de velden die je invulde, en het gaat nauwelijks verder dan de interesses die de klant al toonde.

Collaborative filtering. Vergeet wat de producten zijn en kijk enkel naar wie met wat interageerde. "Klanten die dit kochten, kochten ook dat" is de vorm die iedereen herkent. Google noemt als voordelen dat je geen domeinkennis nodig hebt en dat het toeval een kans krijgt: zo kan iemand een nieuwe interesse ontdekken.

Ranking op embeddings. De moderne versie zet klanten en producten in dezelfde vectorruimte, waardoor een aanbeveling een nearest-neighbour opzoeking wordt: welke productvectoren liggen het dichtst bij de vector van deze klant?

Content-based of collaborative: wat elk nodig heeft voor het werkt

Content-based filtering heeft een productcatalogus met echte kenmerken nodig en bijna niets over gedrag. De retaildocumentatie van Google is duidelijk over het uiterste geval: hun Similar Items model heeft enkel informatie uit de productcatalogus nodig, user events zijn niet vereist. Met titels van drie woorden en lege kenmerkvelden werkt de aanpak niet, hoeveel bezoekers je ook hebt.

Collaborative filtering is het spiegelbeeld. Het heeft een geschiedenis nodig van wie wat deed, en het maakt niet uit wat de producten zijn. Vijf jaar bestellingen en een producttabel met enkel een code en een prijs volstaat, terwijl een winkel die vorige maand opende niets te leren geeft. De meeste systemen in productie draaien allebei.

Welke data je nodig hebt

Een verkoopgeschiedenis met een klantnummer op elke lijn komt eerst. Veel webshops boeken gastbestellingen zonder ze aan iets te koppelen, en zonder nummer kan je twee aankopen niet aan dezelfde persoon hangen. Daarna productkenmerken waar je op kan matchen, ingevuld voor de hele catalogus en niet enkel voor de 200 artikels die iemand vorig jaar opkuiste. En dan bekeken pagina's, niet alleen aankopen: een aankoop is een sterk maar zeldzaam signaal, terwijl paginaweergaves en toevoegingen aan het winkelmandje veel vaker binnenkomen.

Amazon legt een ondergrens vast: minstens 1000 interacties en 25 unieke gebruikers-ID's met elk minstens twee interacties voor het iets traint, en minstens 50.000 interacties van minstens 1.000 gebruikers voor wat ze kwalitatieve aanbevelingen noemen. Een winkel met 400 bestellingen per jaar krijgt geen model dat het uitrollen waard is.

Cold start: nieuwe klanten en nieuwe artikels

Cold start is de toestand waarin aanbevelingen zwak zijn omdat de geschiedenis er nog niet is. Amazon beschrijft het als de fase waarin aanbevelingen minder relevant zijn door een gebrek aan historische gebruikersdata. Het loopt in twee richtingen.

Een nieuwe klant. Val terug op populariteit binnen het segment dat je kan afleiden, en begin te personaliseren binnen de sessie zodra iemand ergens op klikt. Toestel, regio, de campagne waar het bezoek vandaan komt en het tijdstip ken je al bij de eerste paginaweergave, en Amazon noemt net die contextuele metadata een manier om de cold-startfase korter te maken.

Een nieuw artikel. Niemand kocht het, dus collaborative filtering heeft het nooit gezien. Google zegt het mechanisme zonder omweg: als een item niet in de training voorkwam, kan het systeem er geen embedding voor maken en er het model niet mee bevragen. De antwoorden zijn content-based gelijkenis op de kenmerken, en exploratie, waarbij je een deel van de plaatsen reserveert voor artikels met weinig interacties zodat die er kunnen verzamelen. Amazon zet dat op een exploration weight met 0,3 als standaardwaarde.

Meten of het werkt

Hier lopen aanbevelingsprojecten stilletjes fout, en de mislukking heeft een herkenbare vorm: de offline cijfers gaan vooruit, het model gaat live, en de omzet beweegt niet.

Offline cijfers komen uit het herspelen van de geschiedenis. Je verbergt een stuk van het verleden van elke klant, vraagt het model om het te voorspellen, en telt hoe vaak het verborgen artikel in de top vijf staat. Online cijfers zijn wat er gebeurt als echte klanten het blok zien: kliks, toevoegingen aan het mandje, orderwaarde, retours. De documentatie van Amazon stelt dat jij zelf verantwoordelijk bent om die online cijfers te genereren en bij te houden.

Een offline score vergelijkt twee modellen op dezelfde data. Het is geen belofte over gedrag: een model kan de volgende aankoop van een klant hoger zetten en toch niets extra verkopen, omdat die klant dat artikel sowieso ging kopen en het blok de plaats innam van iets anders dat hij anders misschien had meegenomen. Splits dus je bezoekers en meet het resultaat waar het je om gaat, tegen twee referenties: gewone populariteit, en het lijstje dat je eigen productverantwoordelijke met de hand zou schrijven.

Een uitgewerkt voorbeeld

Een webshop met 6.500 klanten, 3.000 artikels en ongeveer 12.000 bestellingen per jaar wil een blok "klanten kochten ook" op de winkelmandpagina. De offline test houdt de laatste bestelling van elke klant achter en vraagt beide modellen om vier artikels. De gewone toppers raken het achtergehouden artikel bij 210 klanten, een trefkans van 3,2 procent. Een eenvoudig artikel-tot-artikel collaborative model raakt er 495, of 7,6 procent. Ruim dubbel zo goed op papier, en dat is het cijfer dat op de slide belandt.

De A/B-test over vier weken vertelt een kleiner verhaal. Elke helft ziet 10.000 winkelmandpagina's. Het populariteitsblok haalt 240 kliks en 96 toegevoegde artikels, aan gemiddeld 34 euro. Het model haalt 305 kliks en 118 toegevoegde artikels, aan gemiddeld 31 euro, omdat het beter een passend accessoire vindt dan een duur artikel. Dat komt op 3.658 euro extra mandwaarde tegen 3.264: een verschil van 394 euro op vier weken, of ruwweg 5.000 euro per jaar.

Alleen dat tweede cijfer zegt of het project zijn onderhoud waard is, en met een paar honderd kliks per helft loont het om eerst te checken of het geen toeval is.

De meeste KMO-cases zijn geen Netflix

De tooling is gebouwd rond consumentenplatformen met miljoenen gebruikers en een catalogus waar smaak de keuze bepaalt. Neem in plaats daarvan een technische groothandel: 4.000 klanten, 20.000 artikels, kopers die dezelfde dingen op een ritme bestellen. Die hebben geen neuraal model nodig om verborgen smaak te ontdekken. Die hebben de query nodig die zegt dat deze klant filter X vier keer in achttien maanden bestelde, telkens met zo'n zestig dagen ertussen, en dat het nu vijfennegentig dagen geleden is. Een vertegenwoordiger kan daar vanmiddag mee bellen, het staat in SQL, en op die catalogus brengt het lang meer op dan een collaborative model.

Aanbevelingsmodellen beginnen op te brengen als de catalogus te groot is om in je hoofd te houden, als er voortdurend nieuwe klanten binnenkomen, en als er niemand tussen de ranking en de klant staat. Een LLM past daarnaast, om de uitleg naast een aanbeveling te schrijven of om "iets dat past bij een zwarte winterjas" om te zetten in een gefilterde zoekopdracht, maar de ranking blijft bij het model dat de bestelgeschiedenis gezien heeft.

Waar moet je op letten bij een aanbevelingssysteem

Aanbevelen wat ze al kochten. Een model dat op aankopen getraind is, stelt vrolijk de vaatwasser voor die iemand vorige week kocht. Verbruiksartikels mogen terugkomen, duurzame goederen niet, en dat onderscheid zit in je productdata en niet in het model. Het voorbeeld dat Amazon zelf geeft bij filters is precies dit.

Aanbevelen wat je niet kan leveren. Artikels zonder voorraad in het blok kosten je de klik en een stuk vertrouwen, dus voorraad check je op het moment van tonen en niet op het moment van trainen. De retaildocumentatie van Google zet net daarvoor hun catalogusmodel voor gelijkaardige artikels in als terugvaloptie.

De terugkoppeling die je catalogus versmalt. Het systeem bepaalt wat getoond wordt, wat getoond wordt raakt verkocht, en wat verkocht raakt traint de volgende versie. Laat je dat lopen, dan concentreert de verkoop zich in een steeds kleinere groep artikels. Coverage zegt welk aandeel van je unieke artikels het systeem ooit zou aanbevelen, dus volg dat naast je klikratio en behandel een dalend cijfer als een probleem, ook al zien de kliks er goed uit.

Profilering heeft een juridische definitie. Onder de GDPR is profilering elke vorm van geautomatiseerde verwerking van persoonsgegevens om persoonlijke aspecten van iemand te evalueren, en de definitie noemt persoonlijke voorkeuren, interesses en gedrag expliciet. Een systeem gebouwd op de aankoopgeschiedenis van een geïdentificeerde klant is dus profilering. Je hebt er een rechtsgrond voor nodig en het hoort in je privacyverklaring. Artikel 27 van de Digital Services Act legt daar bovenop een plicht voor platformen die inhoud van derden dragen: zet de belangrijkste parameters van je aanbevelingssysteem in je algemene voorwaarden, in duidelijke en begrijpelijke taal. Micro- en kleine ondernemingen vallen buiten die afdeling.