Po co w ogóle budować system rekomendacji? Kontekst biznesowy i techniczny
Realne cele: konwersja, retencja, zaangażowanie
Model rekomendacji nie jest ozdobą interfejsu, tylko narzędziem do przesuwania konkretnych wskaźników. Najczęściej chodzi o:
Zwiększenie konwersji – w e‑commerce to dodatkowe produkty dodane do koszyka; w VOD więcej obejrzanych materiałów; w SaaS więcej użytych funkcji.
Większą retencję – użytkownik wraca, bo zawsze znajdzie coś sensownego „dla siebie”, więc nie szuka alternatywy w konkurencyjnej aplikacji.
Większy czas spędzany w aplikacji – szczególnie ważny w serwisach z treściami: muzyka, filmy, artykuły, kursy online.
Rekomendacje działają najlepiej tam, gdzie liczba dostępnych elementów (produktów, filmów, artykułów) jest na tyle duża, że użytkownik bez pomocy zwyczajnie się gubi. System rekomendacji krok po kroku ma doprowadzić użytkownika do jednego, dwóch najtrafniejszych wyborów w danym momencie.
Typowe domeny zastosowań systemów rekomendacji
Najbardziej klasyczne zastosowania to:
E‑commerce – sekcje „Produkty podobne”, „Klienci kupili również”, „Dla Ciebie”. Collaborative filtering użytkownik–użytkownik potrafi tu świetnie zadziałać, gdy masz historię zakupów i przeglądania.
VOD / streaming – „Co obejrzeć dalej?”, „Podobne seriale”. Collaborative filtering element–element oparty o historię oglądania jest tu standardem.
Muzyka – playlisty spersonalizowane, sugestie artystów. Tu często łączy się collaborative filtering z embeddings i modelami głębokimi.
News / content – artykuły polecane po przeczytaniu konkretnego tekstu, personalizowane strony główne.
SaaS / aplikacje B2B – rekomendacje funkcji, raportów, integracji, które użytkownik powinien wypróbować.
Edukacja online – kolejne lekcje, kursy, zadania dopasowane do historii nauki.
Wspólny mianownik: duża liczba opcji i konieczność pomocy w wyborze. Tam, gdzie elementów jest kilkanaście, bardziej opłaca się ręczne ułożenie prostego lejka, niż inwestycja w złożony model rekomendacji.
Widget z ładnym UI a kluczowy komponent produktu
Łatwo wpaść w pułapkę myślenia: „dodajmy karuzelę z rekomendacjami, bo tak ma Amazon”. Różnica między ładnym widgetem a strategicznym komponentem produktu polega na tym, gdzie faktycznie jest wartość:
Jeśli rekomendacje odpowiadają za dużą część ruchu lub przychodu (np. „strona główna = feed rekomendowany”), stają się kluczową warstwą logiki biznesowej.
Jeśli „podobne produkty” na dole strony generują ślad konwersji, system ma sens, ale nie musi być hiper‑zaawansowany od pierwszej wersji.
Jeśli rekomendacje prawie nigdzie nie są widoczne, a większość użytkowników i tak kupuje z wyszukiwarki lub menu kategorii, priorytet budowy skomplikowanego modelu CF jest niższy.
W praktyce warto od początku założyć, że nawet prosty model collaborative filtering może z czasem stać się fundamentem personalizacji – ale na starcie dobrze jest zachować rozsądek i prostotę wdrożenia.
„Czy to nie jest za trudne na start?” – prosty scenariusz wdrożenia
Obawa jest naturalna: machine learning, macierz użytkownik–przedmiot, ewaluacja jakości rekomendacji, skalowanie rekomenderów – wszystko brzmi ciężko. Można to rozbroić etapami:
Etap 1: Top‑N globalne – bez personalizacji, po prostu najczęściej kupowane / oglądane elementy w danej kategorii.
Etap 2: Prosty element–element – „użytkownicy, którzy obejrzeli X, obejrzeli także Y”, liczone np. po współ‑występowaniu w sesji.
Etap 3: Pełny collaborative filtering – macierz użytkownik–przedmiot i model, np. ALS lub Funk‑SVD.
Etap 4: Modele hybrydowe – dołączenie opisu treści, kategorii, metadanych, a później embeddings i modele głębokie.
Każdy etap daje już mierzalną wartość. Nawet jeśli na początku korzystasz z prymitywnego podejścia, zyskujesz dane, które później wykorzystasz do bardziej zaawansowanych modeli.
Kiedy system rekomendacji ma sens, a kiedy nie
Rekomendacje mają sens, gdy:
Masz co najmniej kilkaset–kilka tysięcy elementów w katalogu.
Użytkownicy często wracają lub wykonują wiele akcji (kliknięć, obejrzeń, zakupów).
Elementy są dość zróżnicowane, a użytkownicy mogą mieć wyraźnie różne preferencje.
W globalnym rankingu wystarczy: mały katalog, niski wolumen ruchu, jednorodny produkt (np. jeden typ usługi). Wtedy bardziej opłaca się ręcznie dopracować ścieżkę użytkownika niż budować collaborative filtering i podejście hybrydowe od zera.
Podstawy systemów rekomendacji: typy podejść i ich ograniczenia
Trzy główne nurty: collaborative, content-based i hybrydowe
Fundamentem projektowania modelu rekomendacji jest wybór podejścia:
Collaborative filtering (CF) – wykorzystuje wzorce zachowań użytkowników: kto co kupił, obejrzał, kliknął. Nie potrzebuje zrozumienia treści, polega na strukturze interakcji.
Filtrowanie oparte na treści (content-based) – patrzy na cechy elementów: kategorie, tagi, opis tekstowy, autorów, aktorów, ceny, technologie itd. Rekomenduje „podobne” do tego, co użytkownik już polubił.
Modele hybrydowe w rekomendacjach – łączą oba podejścia, np. collaborative filtering + wektor cech treści, albo dwa osobne modele zblendowane w jeden wynik.
Prawie każdy dojrzały system rekomendacji kończy jako model hybrydowy. W praktyce dobrze jest zacząć od jednego nurtu (najczęściej collaborative filtering oparty na danych niejawnych), a następnie sukcesywnie dorzucać informacje o treści.
Jawne vs niejawne dane preferencji
Systemy rekomendacji mogą korzystać z dwóch głównych typów sygnałów:
Jawne – oceny (ratingi), gwiazdki, lajki, recenzje. Użytkownik wprost mówi, co mu się podoba, a co nie.
Niejawne (implicit) – kliknięcia, odsłuchy, czas oglądania, dodanie do koszyka, zakup, skip utworu po kilku sekundach.
Jawne dane są czyste, ale rzadkie – większość użytkowników nie wystawia ocen. W praktyce większość systemów działa na danych niejawnych, odpowiednio je ważąc. W collaborative filtering niejawne sygnały można kodować np. jako licznik interakcji lub miarę zaangażowania.
Przykład: w serwisie VOD można przyjąć, że:
Oglądanie < 10% długości filmu = słaby sygnał zainteresowania,
Oglądanie > 80% = mocny sygnał „polubił”.
Wybór kodowania ma ogromny wpływ na wyniki modelu, dlatego lepiej zacząć prosto (np. binarne 0/1: było – nie było), a potem dodawać niuanse.
Zalety i wady collaborative filtering
Zalety CF:
Nie wymaga zrozumienia treści – wystarczą logi zachowań.
Potrafi znaleźć nieoczywiste powiązania, np. użytkownicy lubiący niszowy gatunek filmów i pewien typ książek.
Dobrze się skaluje przy użyciu modeli współczynnikowych (matrix factorization).
Wady CF:
Cold start w systemach rekomendacji – nowi użytkownicy i nowe przedmioty nie mają historii, więc system nie ma czego porównać.
Wymaga wystarczająco gęstej macierzy użytkownik–przedmiot. Gdy większość użytkowników obejrzała tylko 1–2 elementy, CF będzie mieć problemy.
Może wzmacniać pętle popularności: popularne rzeczy stają się jeszcze bardziej popularne, nisze dostają mniej ekspozycji.
Zalety i wady filtrowania opartego na treści
Zalety podejścia content-based:
Brak problemu cold start dla nowych użytkowników – wystarczy kilka kliknięć lub jawnych preferencji, by zrozumieć, jakie cechy lubią.
Łatwiejsza interpretowalność – można powiedzieć: „Polubisz to, bo też jest z gatunku X i gra w nim ten sam aktor”.
Działa nawet przy małej liczbie użytkowników – wystarczy jeden użytkownik z preferencjami.
Wady:
Ograniczona personalizacja przy ubogich cechach – jeśli opis produktów jest prosty (np. tylko kategoria i cena), model będzie „płaski”.
Wymaga dobrej jakości metadanych – źle otagowane treści = złe rekomendacje.
Może zamykać użytkownika w „bańce” (filter bubble) – poleca bardzo podobne rzeczy, nie odkrywając nowych tematów.
Jak dobrać podejście do skali, domeny i danych
Dobór strategii warto oprzeć na kilku prostych pytaniach:
Czy masz już dużo interakcji (kliknięć, zakupów, odsłuchów)? Jeśli tak – collaborative filtering będzie dobrym pierwszym wyborem.
Czy posiadasz bogate metadane opisujące elementy (tags, opis tekstowy, cechy techniczne)? Jeśli tak – filtracja oparta na treści może zadziałać od ręki i pomóc przy cold start.
Czy masz wysoki odsetek nowych produktów? W takim przypadku model hybrydowy jest praktycznie obowiązkowy.
W praktyce często stosuje się sekwencję: uruchom collaborative filtering na danych niejawnych, a następnie dodaj warstwę content-based jako fallback i uzupełnienie.
Źródło: Pexels | Autor: Artem Podrez
Dane do modeli rekomendacji: co zbierać i jak je przygotować
Jakie interakcje logować w systemie rekomendacji
Bez dobrych danych żadna magia collaborative filtering nie zadziała. Minimum, które warto logować:
Wyświetlenia (impressions) – kiedy dany element został pokazany użytkownikowi: w liście, na karuzeli, w wyszukiwarce.
Kliknięcia – przejście na stronę elementu, rozpoczęcie odtwarzania, otwarcie artykułu.
Interakcje głębsze – dodanie do koszyka, dodanie do playlisty, zapisanie na później, polubienie.
Konwersje – zakup, obejrzenie do końca, ukończenie kursu, wygenerowanie raportu.
Przy projektowaniu logowania dobrze mieć z tyłu głowy przyszłą macierz użytkownik–przedmiot. Każda linia w logu powinna dać się jednoznacznie przypisać do użytkownika (lub cookies/ID urządzenia) i do konkretnego elementu.
Budowa macierzy użytkownik–przedmiot
Macierz użytkownik–przedmiot to centrum większości algorytmów CF. Definiuje się ją następująco:
Wiersze – użytkownicy (ID użytkownika, czasem też anonimowe ID sesji).
Kolumny – przedmioty (ID produktu, filmu, artykułu itd.).
Wartości – miara preferencji lub zaangażowania: rating, liczba kliknięć, 0/1 (brak / jest interakcja), czas oglądania, liczba zakupów.
Przykładowe schematy kodowania wartości:
Binarne 0/1 – bardzo proste, odporne na szum: 1, jeśli była jakakolwiek interakcja (np. kliknięcie, zakup), 0 w przeciwnym wypadku.
Licznik interakcji – ile razy użytkownik wchodził w interakcję z elementem (np. ile razy słuchał utworu).
Ważona miara zaangażowania – suma zdarzeń, ale każde z inną wagą: kliknięcie = 1, dodanie do koszyka = 3, zakup = 5.
Na początek sprawdza się proste kodowanie binarne, szczególnie przy dużych wolumenach danych. Z czasem można przejść do bardziej złożonych, różnicując siłę poszczególnych sygnałów.
Rzadkość macierzy i konsekwencje
W realnych aplikacjach macierz użytkownik–przedmiot jest ekstremalnie rzadka: większość użytkowników wchodzi w interakcję z promilem katalogu. Ta rzadkość oznacza:
Metody oparte na podobieństwie (k‑NN z cosine similarity) mogą mieć problem ze znalezieniem sensownych sąsiadów, jeśli użytkownik ma zbyt mało interakcji.
Jak agregować i filtrować surowe logi interakcji
Surowe logi są często hałaśliwe: zdarzają się boty, przypadkowe kliknięcia, testy wewnętrzne. Zanim powstanie macierz użytkownik–przedmiot, przydaje się prosty etap „oczyszczania”. Typowe kroki:
Filtracja ruchu technicznego – usunięcie interakcji z kont testowych, wewnętrznych IP, crawlerów.
Scalanie powtarzających się zdarzeń – jeśli użytkownik 20 razy odświeża stronę produktu w ciągu minuty, można to policzyć jako jedno wyświetlenie.
Okienka czasowe – kodowanie preferencji np. w 30‑dniowych oknach, tak by model lepiej reagował na zmiany gustu.
Minimalny próg aktywności – odfiltrowanie użytkowników z jedną losową interakcją, którzy wprowadzają dużo szumu, a niewiele wnoszą.
Wielu osobom wydaje się, że bez pełnej automatyzacji i perfekcyjnych ETL‑i nie da się ruszyć. Lepiej zacząć od prostego batchowego joba (np. raz dziennie) i kilku rozsądnych reguł, niż przez miesiące dopieszczać pipeline, którego nikt jeszcze nie używa.
Normalizacja, ważenie i czas w danych rekomendacyjnych
Te same zdarzenia mogą mieć inną wagę w różnych biznesach. Obejrzany do końca film ma zupełnie inną wartość niż krótkie skanowanie listy produktów. Kilka prostych trików pomaga to odzwierciedlić:
Wagi biznesowe – przypisanie różnej wagi zdarzeniom (klik < dodanie do koszyka < zakup). To nie musi być idealne – wystarczy, że mniej więcej odzwierciedla hierarchię.
Ucinanie ekstremów – użytkownik, który odsłuchał ten sam utwór 300 razy, nie musi mieć 300x większej „miłości” niż ktoś, kto odsłuchał go 10 razy. Można zastosować logarytm lub ograniczenie do maksymalnej wartości.
Starzenie interakcji – nowszym zdarzeniom można dać większą wagę, np. mnożąc je współczynnikiem zależnym od wieku interakcji.
Dobrym kompromisem na start jest: proste 0/1 dla „jakiejkolwiek sensownej interakcji” plus ewentualne odcięcie bardzo starych danych (np. sprzed roku), jeśli domena szybko się zmienia.
Minimalne informacje o użytkownikach i elementach
Nawet jeśli rdzeń stanowi collaborative filtering na danych niejawnych, przydaje się minimalny zestaw metadanych, który później ułatwi przejście w stronę podejścia hybrydowego. Typowy zestaw:
Użytkownicy – typ konta (B2B/B2C), kraj, język interfejsu, platforma (mobile/desktop), źródło pozyskania.
Przedmioty – kategoria, podkategoria, marka/autor, kilka kluczowych tagów, podstawowe atrybuty biznesowe (cena, poziom zaawansowania kursu, długość filmu).
Nie trzeba od razu budować złożonej ontologii produktów. Wiele firm latami korzysta z kilku najprostszych pól, a dopiero później inwestuje w porządne tagowanie i analizę treści.
Collaborative filtering oparty na podobieństwie: użytkownik–użytkownik i element–element
Model użytkownik–użytkownik: kto jest do mnie podobny
CF użytkownik–użytkownik (user‑based) zakłada, że najlepszą wskazówką dla danego użytkownika są osoby o podobnych zachowaniach. W praktyce działa to tak:
Budujesz wektor zachowań użytkownika – np. lista produktów, które kupił lub polubił.
Dla każdego innego użytkownika tworzysz analogiczny wektor.
Licząc miarę podobieństwa (np. cosine similarity), znajdujesz k najbliższych sąsiadów.
Patrzysz, jakie przedmioty polubili sąsiedzi, a których Twój użytkownik jeszcze nie zna – to kandydaci do rekomendacji.
Urokiem tego podejścia jest intuicyjność. Można wytłumaczyć biznesowi: „pokazujemy temu użytkownikowi to, co podobało się innym o podobnej historii zakupów”. Problem pojawia się, gdy macierz jest bardzo rzadka – wtedy znalezienie sensownych sąsiadów staje się trudne.
Model element–element: podobne do tego, co kliknąłeś
CF item‑item (element–element) opiera się na tym samym pomyśle, ale przerzuca uwagę z użytkowników na przedmioty. Zamiast pytać: „kto jest podobny do tego użytkownika?”, pytasz: „jakie elementy są podobne do tego filmu/kursu/produktu?”. Proces jest zbliżony:
Tworzysz wektory elementów – np. które użytkownicy wchodzili z nimi w interakcję.
Dla każdego elementu trzymasz listę kilku–kilkunastu najbardziej podobnych.
Podczas rekomendacji: bierzesz ostatnio obejrzane/przeczytane/kupione rzeczy i do nich szukasz podobnych.
To podejście dobrze skaluje się operacyjnie: podobieństwa między elementami można pre‑obliczać offline, a online tylko szybko odczytywać „podobne do X, Y, Z”. Dlatego tak często widać moduł typu „Użytkownicy oglądający ten film oglądali też…”.
Jak mierzyć podobieństwo w collaborative filtering
Kluczowe pytanie w metodach sąsiedztwa brzmi: jak zmierzyć podobieństwo? Kilka najczęściej używanych miar:
Cosine similarity – patrzy na kąt między dwoma wektorami, ignorując ich długość. Dobrze się sprawdza przy binarnych i licznikowych macierzach.
Jaccard similarity – stosunek części wspólnej do sumy. Użyteczny przy bardzo rzadkich, binarnych danych (np. użytkownik kupił / nie kupił).
Pearson correlation – przydatna przy jawnych ocenach, gdzie istotne jest, czy użytkownicy podobnie oceniają te same elementy.
Na początku nie ma sensu komplikować. Cosine similarity na binarnej macierzy (interakcja była/nie była) często daje zaskakująco dobre wyniki, zwłaszcza gdy macierz nie jest skrajnie pusta.
Wyzwania i obejścia w podejściu sąsiedztwa
Metody oparte na podobieństwie mają kilka typowych pułapek. W praktyce najczęściej pojawia się kilka pytań:
Co z użytkownikami o bardzo małej liczbie interakcji? Można wymagać minimalnej liczby zdarzeń, by w ogóle włączać user‑based CF, a dla reszty korzystać z fallbacków (np. najpopularniejsze w kategorii, prosty content‑based).
Jak poradzić sobie z „super fanami” lub botami? Odfiltrować nietypowo intensywnych użytkowników (np. powyżej określonego percentyla) lub ograniczyć maksymalną liczbę interakcji, które wchodzą do modelu.
Jak uniknąć rekomendowania tylko hitów? Można dodać karę za zbyt dużą popularność elementu lub mieszać listę rekomendacji z modułem eksploracji (np. „podobne, ale nie ultra popularne”).
Jeśli pojawia się obawa, że implementacja w pełnej skali będzie zbyt złożona, dobrą drogą jest prototyp na małym wycinku danych: np. jedna kategoria, tylko użytkownicy z min. 5 interakcjami. To pozwala zobaczyć, jak model „myśli”, zanim włoży się wysiłek w optymalizację.
Przykładowy pipeline dla CF item–item
Dla uporządkowania, prosta ścieżka wdrożenia CF element–element dla sklepu internetowego może wyglądać tak:
Logujesz zdarzenia: „użytkownik X obejrzał / kupił produkt Y”.
Budujesz binarną macierz użytkownik–produkt na podstawie ostatnich kilku miesięcy.
Obliczasz podobieństwo między wszystkimi parami produktów, które współwystąpiły w interakcjach ≥ N razy (np. 5).
Dla każdego produktu zapisujesz listę np. 20 najbardziej podobnych.
W produkcie wdrażasz boksy „Podobne produkty” oraz „Użytkownicy kupujący ten produkt wybierali też…”, korzystając z tej listy.
To już jest realny system rekomendacji, choć bardzo prosty. W wielu sklepach taki moduł spokojnie generuje dodatkową sprzedaż, zanim pojawią się bardziej wyszukane modele.
Źródło: Pexels | Autor: Mikhail Nilov
Modele współczynnikowe (matrix factorization) jako rdzeń collaborative filtering
Od macierzy użytkownik–przedmiot do przestrzeni czynników
Matrix factorization rozwiązuje problem rzadkiej macierzy w inny sposób niż metody sąsiedztwa. Zamiast liczyć podobieństwa między parą użytkowników lub elementów, uczy ukryte reprezentacje (embeddingi) zarówno dla użytkowników, jak i przedmiotów. Intuicja:
Każdemu użytkownikowi przypisujesz wektor liczb (np. 50 wymiarów), który ma podsumować jego preferencje.
Każdemu elementowi przypisujesz inny wektor (także 50 wymiarów), który opisuje jego „charakter”.
Iloczyn skalarny tych wektorów daje przewidywaną siłę preferencji (rating, prawdopodobieństwo interakcji).
Model uczy te wektory tak, by przewidywana wartość była jak najbliżej rzeczywistego zachowania (np. oceny lub „była/nie była interakcja”). Dzięki temu może „domyślać się” relacji nawet tam, gdzie w macierzy nie ma żadnych danych.
Jawne a niejawne matrix factorization
W wersji z jawnymi ocenami często używa się wariantów takich jak ALS (Alternating Least Squares) czy SVD, minimalizując błąd między przewidywaną a rzeczywistą oceną. W świecie danych niejawnych częściej stosuje się adaptacje, które:
traktują obserwowane interakcje jako pozytywne sygnały,
dokładają do loss function mnóstwo „pseudo-negatywnych” przykładów (przedmioty, z którymi użytkownik nie wchodził w interakcję),
wprowadzają wagi pewności – np. zakup ma większą wagę niż jedno kliknięcie.
Popularną techniką jest implicit ALS, zaimplementowany np. w bibliotekach takich jak implicit w Pythonie lub Spark MLlib. Dla wielu zespołów to najprostszy sposób na start z matrix factorization, bo biblioteki biorą na siebie sporą część złożoności matematycznej.
Regularizacja i kontrola nad dopasowaniem
Modele współczynnikowe są bardzo elastyczne – i to ich siła, ale też ryzyko przeuczenia. Żeby uniknąć sytuacji, w której model „uczy się na pamięć” historii aktywnych użytkowników, stosuje się:
Regularizację L2 – kara za zbyt duże wartości współczynników; w praktyce jeden z najważniejszych hyperparametrów.
Ograniczenie wymiaru embeddingów – zamiast 200 wymiarów, na początek 20–50 zwykle wystarczy.
Odpowiednio zbalansowany sampling negatywny w wersjach na dane niejawne – zbyt mało „negatywów” prowadzi do przeoptymistycznych przewidywań.
Częsta obawa brzmi: „Nie mamy wystarczająco dużo danych na tak złożony model”. W praktyce matrix factorization zaczyna sensownie działać już przy setkach tysięcy interakcji, o ile są one rozsądnie rozłożone na użytkowników i przedmioty.
Jak z matrix factorization zrobić realne rekomendacje
Sam fakt, że masz wektory użytkowników i elementów, jeszcze nie daje gotowej listy rekomendacji. Trzeba przejść kilka kroków operacyjnych:
Uczysz model na historycznej macierzy użytkownik–przedmiot.
Zapisujesz embeddingi użytkowników i elementów (np. do bazy lub plików binarnych).
W trybie offline generujesz kandydatów dla każdego użytkownika – najczęściej przez obliczanie iloczynu skalarnego wektora użytkownika z wektorami wszystkich elementów i sortowanie według wyniku.
Odfiltrowujesz elementy, z którymi użytkownik już wchodził w interakcję, oraz te, których nie można pokazać (brak na stanie, nieodpowiedni kraj, ograniczenia licencyjne).
W praktyce wąskim gardłem nie jest sama matematyka, tylko skalowanie: jak policzyć „top‑N elementów dla każdego użytkownika” przy milionach pozycji. Tu przydają się przybliżone wyszukiwarki sąsiadów (ANN, np. Faiss, ScaNN, Annoy) lub pre‑generowanie rekomendacji batchowo i cachowanie ich w bazie.
Rozszerzanie matrix factorization o cechy (factorization machines, embeddings)
Krok dalej to modele, które łączą collaborative filtering z cechami użytkownika i elementu. Dwie popularne rodziny:
Factorization Machines (FM) – rozszerzają ideę matrix factorization na dowolne cechy wejściowe (one‑hoty użytkowników, elementów, kategorii, kanału, pory dnia). Pozwalają modelować interakcje między cechami bez eksplozji wymiarów.
Embeddingi w architekturach sieciowych – użytkownik i element mają swoje embeddingi, które wraz z dodatkowymi cechami przechodzą przez warstwy gęste (MLP). Przykłady to modele typu Wide & Deep, DeepFM.
Jak oceniać jakość modeli collaborative filtering
Po zbudowaniu pierwszego modelu pokusa jest jedna: jak najszybciej wdrożyć go do produkcji. Zanim to nastąpi, dobrze jest mieć twarde liczby, które pokazują, czy nowy system faktycznie jest lepszy od baseline’u typu „najpopularniejsze”. Ocena zwykle dzieje się na dwóch poziomach: offline i online.
Metryki offline dla rekomendacji
W świecie klasyfikacji wszystko kręci się wokół accuracy, precision i recall. W rekomendacjach dochodzi jeszcze ranking, więc pojawiają się nieco inne miary. Najczęściej wykorzystywane to:
Precision@K – jaki odsetek z pierwszych K rekomendacji faktycznie „trafił” w jakieś przyszłe zachowanie użytkownika (np. kliknięcie, zakup).
Recall@K – jaki odsetek wszystkich przyszłych interakcji udało się wychwycić w pierwszych K rekomendacjach.
MAP@K (Mean Average Precision) – uwzględnia zarówno to, czy trafiasz, jak i na jakich pozycjach rankingu pojawiają się trafienia.
nDCG@K – nagradza trafienia blisko góry listy, karze za „dobre, ale bardzo nisko” rekomendacje.
W prostszych projektach wystarczy precyzja i recall. Jeśli rekomendacje będą używane głównie w małym boksie typu „dla ciebie” z kilkoma pozycjami, skupienie się na Precision@5 lub @10 ma więcej sensu niż patrzenie na metryki dla długich list.
Jak przygotować walidację offline
Większy kłopot niż sama metryka to podział danych. Klasyczny train/test na losowych rekordach psuje chronologię, a system rekomendacji jest mocno zależny od czasu. Lepsze warianty:
Podział czasowy – trenujesz na danych do pewnej daty, testujesz na zdarzeniach z późniejszego okresu. Dobrze imituje rzeczywiste użycie.
Leave-one-out per user – dla każdego użytkownika odkładasz ostatnią interakcję jako testową, reszta idzie do treningu. Model ma więc za zadanie „odgadnąć” ten ostatni krok.
Do walidacji leave-one-out typowy scenariusz wygląda tak: dla użytkownika generujesz listę rekomendacji na podstawie treningu, potem sprawdzasz, czy wśród top‑K znajduje się przedmiot z ostatniej interakcji. Prosty, a bardzo przydatny test sanity-check na wczesnym etapie.
Ograniczenia oceny offline
Model, który ma świetne metryki offline, wcale nie musi przynieść najwyższego wzrostu w biznesowych KPI (kliknięcia, przychód, retencja). Przyczyny są zwykle trzy:
Metryki offline patrzą w przeszłość, a użytkownicy i oferta potrafią szybko się zmieniać.
Nie mierzą efektu eksploracji nowości – system wyłącznie „odtwarzający historię” może mieć świetny wynik offline, a jednocześnie wypychać użytkownika z serwisu, bo ciągle pokazuje to samo.
Przy klasycznym trenowaniu na danych zapisanych w logach występuje efekt biasu ekspozycji: widzimy tylko to, co realnie zostało wyświetlone, a nie to, co mogłoby zadziałać.
Dlatego ocena offline powinna służyć do odbicia oczywistych błędów (model gorszy niż baseline, błędny sampling, problemy z featurami), a ostateczne decyzje produktowe trzeba opierać na testach online.
Eksperymenty online: A/B testy rekomendacji
Nawet bardzo techniczny zespół prędzej czy później dochodzi do momentu, w którym nie da się dalej „kręcić metrykami offline”. Różnice między kolejnymi wersjami modeli są niewielkie, a biznes pyta: „Który da najwięcej sprzedaży?”. Odpowiedź przychodzi z A/B testu.
Co mierzyć w testach A/B
Zakres metryk zależy od produktu. Kilka najczęściej stosowanych:
CTR rekomendacji – czy użytkownicy częściej klikają w moduły z rekomendacjami po zmianie modelu.
Konwersja / przychód z sesji – ważne zwłaszcza w e‑commerce; liczy się nie tylko liczba kliknięć, ale to, czy przekładają się na koszyk.
Czas spędzony w serwisie, liczba odtworzeń, liczba przeczytanych artykułów – w serwisach treściowych i streamingowych.
Długoterminowe wskaźniki retencji – bardziej wymagające, ale dają obraz, czy rekomendacje budują przywiązanie, czy tylko chwilowo „podbija się” klikalność.
W praktyce dobrze mieć jedną główną metrykę decyzyjną (np. przychód na użytkownika) i kilka pomocniczych, które pokazują szerszy obraz. Dzięki temu łatwiej uniknąć sytuacji, w której model zwiększa CTR kosztem np. konwersji.
Jak bezboleśnie wystartować z A/B testem
Częsta obawa: „Nie mamy platformy eksperymentacyjnej, to za duży projekt”. Start wcale nie musi być skomplikowany. Minimalna wersja eksperymentu wygląda tak:
Przy wejściu użytkownika do serwisu losujesz go do grupy A (stary model) lub B (nowy model) i zapisujesz tę informację w cookie lub w sesji.
Przy każdym zapytaniu o rekomendacje odczytujesz grupę i generujesz odpowiednią listę.
Logujesz, który wariant rekomendacji dostał użytkownik oraz jego dalsze zachowania (klik, zakup).
Po uzbieraniu odpowiedniej liczby zdarzeń analizujesz różnice między grupami.
Na początek sprawdza się prosty split 50/50 i czas trwania rzędu kilku tygodni, żeby złapać różne dni tygodnia, kampanie marketingowe itd. Później można podejść do bardziej zaawansowanych metod (bandyty wieloramienne, sekwencyjne testy statystyczne), ale nie jest to potrzebne na pierwszym etapie.
Collaborative filtering krok po kroku: od problemu do działającego prototypu
Definiowanie celu biznesowego i zakresu pilota
Zanim stanie się w połowie drogi z macierzami, embeddingami i metrykami, pomaga proste pytanie: co dokładnie ma się poprawić dzięki rekomendacjom? Inny model zrobisz, jeśli celem jest zwiększenie wartości koszyka, a inny, gdy zależy ci na odkrywaniu nowych treści.
Dobrą praktyką jest zawężenie pierwszego wdrożenia do konkretnego modułu, np.:
w e‑commerce: „Produkty podobne” na stronie produktu i „Często kupowane razem”,
w VOD: „Obejrzyj dalej / podobne filmy” po zakończeniu seansu,
w serwisie z artykułami: „Powiązane teksty” pod treścią.
Taki wycinek łatwiej obsłużyć, przetestować i zmierzyć niż całkowitą przebudowę całego serwisu „pod personalizację”. Dzięki temu unikasz paraliżu decyzyjnego, gdy wszystko naraz chce się zrobić idealnie.
Wybór minimalnego zestawu danych i prostego baseline’u
Przy pierwszym podejściu do CF pojawia się naturalne pytanie: „Czy musimy od razu budować matrix factorization?”. Niekoniecznie. Rozsądnym startem jest:
Zdefiniować jeden wyraźny sygnał pozytywny (np. zakup, dłuższe odtworzenie) i opcjonalnie jego wagę.
Zbudować bardzo prosty baseline, np. „najpopularniejsze w kategorii” w określonym horyzoncie czasu.
Ten baseline jest ważny z dwóch powodów. Po pierwsze, często działa zaskakująco dobrze i podnosi KPI nawet bez ML. Po drugie, daje punkt odniesienia, z którym później porównujesz collaborative filtering – jeśli nowy model nie przebija baseline’u, wiadomo, że gdzieś jest błąd.
Prototyp user–item z wykorzystaniem podejścia implicit
Gdy masz już eventy, można przejść do pierwszej prawdziwej wersji CF opartej o matrix factorization dla danych niejawnych. Typowy pipeline dla biblioteki pokroju implicit w Pythonie może wyglądać następująco:
Przygotowanie macierzy – tworzysz sparse matrix w formacie CSR: wiersze to użytkownicy, kolumny to produkty, wartościami mogą być np. zliczone interakcje lub wagi (1 dla kliknięcia, 3 dla zakupu).
Trenowanie modelu implicit ALS – ustawiasz podstawowe hyperparametry: liczbę czynników (np. 50), siłę regularizacji, liczbę iteracji.
Ustalenie wagi „pewności” – dla ALS na danych niejawnych ważny jest hyperparametr alpha, który skaluje, jak mocno model ufa interakcjom.
Generowanie rekomendacji – dla każdego użytkownika pytasz model o top‑N elementów, filtrujesz już widziane i zapisujesz wynik.
Jeśli wolumen danych jest na początku mały, taki prototyp da się uruchomić na jednym serwerze lub wręcz na mocniejszym laptopie. Dopiero przy dziesiątkach milionów interakcji trzeba myśleć o rozproszeniu (Spark, duże maszyny, ANN).
Obsługa cold startu użytkowników i przedmiotów
Jedno z bardziej frustrujących zagadnień brzmi: „A co z nowymi użytkownikami albo nowymi produktami, których model jeszcze nie widział?”. Na szczęście nie trzeba od razu budować rozbudowanego systemu hybrydowego, żeby mieć sensowne obejścia.
Nowi użytkownicy (cold user)
Dla użytkowników bez historii można zastosować kilka prostych strategii:
Fallback do popularności – pokazujesz najpopularniejsze elementy (globalnie lub w danej kategorii / kraju).
Mini-ankieta lub onboarding – na starcie prosisz użytkownika o wybór kilku kategorii lub przykładów, które go interesują; to pozwala szybko zbudować namiastkę wektora preferencji.
Wykorzystanie kontekstu – jeśli użytkownik trafia na stronę produktu z reklamy, pierwsze rekomendacje możesz wygenerować na podstawie tego konkretnego produktu (item–item).
Później, gdy tylko pojawi się kilka interakcji, można stopniowo „przełączać się” w stronę pełnego CF, np. przez mieszanie wyników: 50% popularność, 50% CF, a wraz z rosnącą historią zwiększać udział CF.
Nowe przedmioty (cold item)
Nowa książka, film czy produkt w magazynie nie ma jeszcze historii interakcji, więc czysty collaborative filtering nie ma do czego się „przyczepić”. Przydają się wtedy:
Reguły biznesowe – jeśli produkt jest częścią nowej kampanii, można mu na początku dać lekkie „dopalenie” w modułach rekomendacji.
Strategia „explore” – nowy przedmiot częściej losowo podsuwać wśród rekomendacji, by szybciej zebrać pierwsze interakcje.
Czasem pomaga też prosty próg: dopóki element nie uzbiera określonej liczby interakcji, traktujesz go w rekomendacjach bardziej „ręcznie” (np. na bazie kategorii), a dopiero potem wpuszczasz go w pełny obieg CF.
Łączenie collaborative filtering z regułami biznesowymi
Niewiele systemów w realnych firmach działa w pełni „czysto” według modelu. Zwykle dochodzą do tego zasady typu „nie pokazuj produktów niedostępnych”, „promuj kampanię X” albo „unikaj powtarzania tego samego serialu na wszystkich boksach strony”. CF trzeba więc osadzić w szerszym silniku rankingowym.
Filtry twarde (hard constraints)
To wszystko, czego nie wolno pokazać, niezależnie od preferencji użytkownika. Kilka typowych przykładów:
produkty wyprzedane lub zablokowane prawnie w danym kraju,
treści z nieodpowiednią klasyfikacją wiekową dla zalogowanego użytkownika,
elementy, które użytkownik już kupił i nie ma sensu ich ponownie polecać (np. bilety jednorazowe).
Najprościej zastosować filtr twardy na końcu pipeline’u – po wygenerowaniu kandydatów przez CF odrzuca się wszystkie pozycje niespełniające warunków biznesowych i ewentualnie dobiera kolejne z listy.
Miękkie priorytety i mieszanie list
Inna kategoria to sygnały „miękkie”: premie za nowość, kampanie promocyjne, wagi kategorii. Zamiast nadpisywać nimi wynik CF, sensowniej jest zbudować końcowy ranking, w którym:
do tego dochodzi kilka funkcji, np. „bonus za nowość”, „bonus za marżę”, „kara za zbyt dużą popularność”,
na końcu model (lub prosta formuła liniowa) łączy to w jeden wynik rankingowy.
Na początek wystarczy nawet heurystyka typu: final_score = 0.7 * cf_score + 0.3 * novelty_score. Z czasem można to zastąpić bardziej zaawansowanym modelem rankingowym (learning‑to‑rank), który uczy się, jak ważyć poszczególne sygnały na podstawie realnych kliknięć i konwersji.
Prosta architektura hybrydowa w praktyce
Najczęściej zadawane pytania (FAQ)
Kiedy w ogóle opłaca się budować system rekomendacji?
System rekomendacji ma sens, gdy katalog elementów jest duży (co najmniej kilkaset–kilka tysięcy produktów, filmów, artykułów), a użytkownicy wykonują wiele akcji: klikają, oglądają, kupują, wracają do serwisu. Wtedy bez automatycznych podpowiedzi trudno im się odnaleźć, a ręczne układanie oferty szybko przestaje działać.
Jeśli oferta jest mała, ruch niski, a produkt jednorodny (np. jedna usługa w kilku wariantach), lepiej dopracować prosty lejek sprzedażowy i nawigację niż inwestować czas w collaborative filtering i hybrydę. Rekomendacje zaczynają „zarabiać”, gdy ich wpływ na konwersję, retencję lub czas w aplikacji jest realny, a nie tylko kosmetyczny.
Od czego zacząć budowę modelu rekomendacji, żeby się nie „przestrzelić” z poziomem skomplikowania?
Najbezpieczniej zacząć od bardzo prostych etapów i dopiero na danych decydować, czy iść dalej. Dobry, pragmatyczny plan wygląda tak:
Etap 1: ranking Top‑N globalny (najpopularniejsze elementy w danej kategorii, bez personalizacji),
Etap 2: prosty model element–element oparty na współ‑występowaniu, typu „użytkownicy, którzy obejrzeli X, obejrzeli też Y”,
Etap 3: pełny collaborative filtering z macierzą użytkownik–przedmiot (np. ALS, Funk‑SVD),
Etap 4: modele hybrydowe, które dorzucają cechy treści, metadane, embeddings.
Każdy krok można zatrzymać, jeśli wzrost metryk jest niewielki względem kosztu wdrożenia. To pozwala uniknąć sytuacji, w której zespół przez miesiące buduje skomplikowany model, a biznes nie widzi różnicy.
Czym różni się collaborative filtering od filtrowania opartego na treści?
Collaborative filtering (CF) bazuje na wzorcach zachowań: kto co obejrzał, kupił, kliknął. Nie musi „rozumieć” treści – wystarczą logi interakcji. Dzięki temu potrafi wyłapywać nieoczywiste powiązania, np. że osoby oglądające określony niszowy serial często kupują także pewien typ książek.
Filtrowanie oparte na treści (content‑based) korzysta z cech elementów: kategorii, tagów, opisów, aktorów, cen, technologii itd. Szuka podobnych elementów do tego, co użytkownik już polubił. Sprawdza się, gdy katalog jest dobrze opisany, a liczba użytkowników jest niewielka albo dane o ich zachowaniach są skąpe.
W praktyce dojrzałe systemy łączą oba podejścia w modelach hybrydowych: CF daje „mądrość tłumu”, a treść pomaga radzić sobie z cold startem i wyjaśniać, dlaczego coś jest polecane.
Na czym polega podejście hybrydowe w systemach rekomendacji?
Model hybrydowy łączy collaborative filtering z informacją o treści. Można to zrobić na kilka sposobów, np. ucząc wspólną reprezentację (wektor) dla użytkownika, która uwzględnia zarówno historię zachowań, jak i cechy konsumowanych elementów, albo blendując wynik dwóch osobnych modeli (CF + content‑based) z odpowiednimi wagami.
Takie podejście zmniejsza problem cold startu (nowe przedmioty można rekomendować na podstawie opisu, a nowych użytkowników – na podstawie kilku pierwszych kliknięć) i jest odporniejsze na szum w logach. W praktyce często zaczyna się od „gołego” CF, a dopiero potem dokłada warstwę treści, gdy są już sensowne dane i widać ograniczenia czystego collaborative filtering.
Jakie dane są potrzebne do collaborative filtering i co z danymi jawnymi vs niejawnymi?
Do collaborative filtering potrzebna jest przede wszystkim macierz użytkownik–przedmiot, czyli informacja, że dany użytkownik wykonał jakąś akcję na danym elemencie. Może to być obejrzenie filmu, kliknięcie artykułu, dodanie produktu do koszyka, zakup, odsłuch utworu itd. Te sygnały można potraktować binarnie (było/nie było) albo nadać im różną wagę.
Dane jawne (ratingi, gwiazdki, recenzje) są bardzo wartościowe, ale zwykle rzadkie. Dlatego większość systemów opiera się na danych niejawnych: czasie oglądania, liczbie odsłuchów, głębokości scrollowania. Przykładowo, w VOD obejrzenie ponad 80% filmu można zakodować jako „mocne lubienie”, a porzucenie po kilku minutach – jako słaby sygnał. Na start wystarczy jednak prosty model: 0/1 „była interakcja – nie było”, dopiero później można wprowadzać bardziej złożone wagi.
Jak rozwiązać problem cold start w systemie rekomendacji?
Cold start dotyczy nowych użytkowników (brak historii) i nowych elementów (brak interakcji). W CF to naturalne ograniczenie, bo model nie ma czego porównać. Są jednak sprawdzone sposoby, by to złagodzić:
dla nowych użytkowników – krótkie onboardingowe pytania o preferencje, promowanie popularnych elementów z danej kategorii, szybkie uczenie preferencji po kilku pierwszych kliknięciach,
dla nowych elementów – dobre metadane (tagi, kategorie, opis), które pozwalają wpiąć je do modelu content‑based jeszcze zanim pojawią się logi.
Podejście hybrydowe szczególnie tu pomaga: gdy nie ma jeszcze sygnałów collaborative, model opiera się mocniej na treści, a wraz z pojawieniem się interakcji stopniowo zwiększa wagę komponentu CF.
Jak mierzyć skuteczność systemu rekomendacji w kontekście biznesowym?
Najważniejsze jest powiązanie rekomendacji z konkretnym celem: konwersją, retencją lub zaangażowaniem. W praktyce oznacza to np. mierzenie, ile zamówień, obejrzeń czy kliknięć pochodzi z sekcji rekomendacji, jak zmienia się średnia wartość koszyka, ile dodatkowych treści użytkownik konsumuje po wejściu z rekomendacji.
Równolegle stosuje się metryki typowo „rekomendacyjne” (precision@K, recall@K, MAP, NDCG), ale one same w sobie nie gwarantują efektu biznesowego. Dobrym podejściem jest: najpierw szybka iteracja offline (te metryki), a później testy A/B na produkcji, które bezpośrednio pokazują wpływ nowego modelu na zachowanie użytkowników i przychody.
