Budujemy system rekomendacji krok po kroku: od surowych danych po działający silnik

Zespół ma logi kliknięć, katalog produktów albo treści i jedno krótkie oczekiwanie z góry: „zróbmy rekomendacje oparte o AI”. Po dwóch tygodniach okazuje się, że nie wiadomo, czy system ma zwiększać kliknięcia, sprzedaż, czas spędzony w serwisie czy odkrywanie nowych pozycji. To moment, w którym większość projektów psuje się nie przez słaby model, tylko przez zły start.

Realne pytania, które pojawiają się na początku, są zwykle bardzo przyziemne: jaki problem biznesowy ma rozwiązać system rekomendacji, jakie dane o interakcjach naprawdę wystarczą do MVP, jak przygotować logi zdarzeń bez przecieków danych, kiedy wystarczy baseline rekomendacyjny, kiedy wybrać collaborative filtering, kiedy content-based, jak obsłużyć cold start i po czym poznać, że winne są dane, a nie algorytm. Dopiero odpowiedzi na te pytania składają się na działający silnik, a nie odwrotnie.

system rekomendacji, dane o interakcjach, collaborative filtering, content-based, cold start, candidate generation, ranking rekomendacji, ewaluacja offline, logi zdarzeń, metryki rekomendacji, baseline rekomendacyjny, AI w praktyce

Gdy zespół ma logi kliknięć i presję na „AI”, ale nie ma jeszcze właściwego problemu

Krótka scenka wdrożeniowa jako punkt wyjścia

Typowy scenariusz wygląda podobnie niezależnie od branży. Są dane o użytkownikach, jest lista obiektów, czasem nawet ślady zakupów lub odtworzeń, ale nie ma jednej odpowiedzi na pytanie: co ma poprawić rekomendacja. Bez tej decyzji bardzo łatwo zbudować model, który optymalizuje coś wygodnego do policzenia, a nie coś ważnego dla produktu.

Jeżeli celem jest zwiększenie liczby kliknięć, to etykieta treningowa będzie inna niż wtedy, gdy chodzi o zakup, zapisanie elementu na później, dokończenie procesu czy retencję po kilku dniach. Ten wybór wpływa na wszystko: jakie zdarzenia zbieramy, jak budujemy zbiór uczący, co uznajemy za pozytywny sygnał i jak oceniamy wynik. Model zoptymalizowany pod kliknięcie może dobrze „łapać uwagę”, a jednocześnie słabo wspierać finalizację zakupu.

Różnica między branżami też ma znaczenie. W sklepie użytkownik może wchodzić rzadziej, ale podejmować decyzję z większą intencją. W serwisie contentowym interakcji jest więcej, za to sygnały bywają płytsze i bardziej podatne na przypadek. W katalogu wiedzy albo środowisku B2B celem może być nie maksymalizacja liczby odsłon, tylko znalezienie trafnego dokumentu czy następnego sensownego kroku w procesie.

Najwięcej błędów bierze się z budowania modelu przed ustaleniem definicji sukcesu. Jeśli system rekomendacji ma być narzędziem produktu, to punkt wyjścia nie brzmi „jaki algorytm wybrać”, tylko „jakie zachowanie chcemy poprawić i w jakim miejscu interfejsu”. To mini-wniosek, który oszczędza tygodnie pracy.

Pierwsze decyzje, które ustawiają cały projekt

Na początku trzeba rozdzielić kilka pozornie prostych spraw. Dla kogo generujemy rekomendacje: dla nowego użytkownika bez historii, dla powracającego z bogatym profilem, czy dla anonimowej sesji, w której liczy się wyłącznie bieżący kontekst? Odpowiedź wpływa na to, czy w ogóle mamy szansę użyć historii zachowań, czy musimy opierać się na cechach obiektów i sygnałach sesyjnych.

Druga decyzja dotyczy tego, co właściwie rekomendujemy. Nie zawsze musi to być pojedynczy produkt czy artykuł. W niektórych przypadkach sensowniejsza jest rekomendacja kategorii, dokumentu powiązanego, kolejnego kroku w procesie albo zestawu elementów. Im bardziej złożony obiekt rekomendacji, tym ważniejsze stają się reguły biznesowe i kontrola jakości katalogu.

Trzecia sprawa to miejsce użycia. Rekomendacje na stronie głównej działają inaczej niż na karcie produktu, w koszyku, w panelu użytkownika czy w feedzie. Na stronie głównej zwykle walczy się z brakiem kontekstu i większym znaczeniem świeżości. Na karcie produktu sensowniejsze bywają elementy podobne lub często wybierane razem. W koszyku dochodzi logika uzupełniania, a nie tylko podobieństwa. Jeden model dla wszystkich miejsc bywa kuszący, ale często daje przeciętny wynik wszędzie.

Na tym samym etapie trzeba ustalić ograniczenia, których model sam nie „odgadnie”. Przykłady są bardzo praktyczne: nie rekomendować niedostępnych elementów, dbać o świeżość w katalogu treści, ograniczać powtarzalność, nie pokazywać użytkownikowi rzeczy już kupionych lub przeczytanych, jeśli kontekst tego nie wymaga. To nie są dodatki na później. Bez nich nawet dobry ranking rekomendacji może wyglądać źle w produkcji.

Krótka lista sytuacji, w których cel rekomendacji zmienia wszystko

• Sklep: celem może być zakup, dodanie do koszyka albo zwiększenie wartości koszyka, nie samo kliknięcie.
• Media i content: ważniejsze bywa dokończenie materiału, powrót użytkownika lub odkrywanie nowych treści niż liczba odsłon.
• Katalog wiedzy lub platforma B2B: sukcesem może być znalezienie właściwego dokumentu, rozwiązanie problemu albo przejście do kolejnego etapu procesu.

Jeżeli te trzy scenariusze wrzuci się do jednego worka pod hasłem „system rekomendacji”, decyzje będą przypadkowe. Jeśli rozdzieli się je na cele i kontekst użycia, architektura zaczyna układać się naturalnie.

Jakie dane naprawdę są potrzebne, a co jest tylko dodatkiem

Minimalny zestaw danych do pierwszej wersji

Do pierwszego sensownego systemu rekomendacji nie potrzeba od razu rozbudowanego jeziora danych, setek cech użytkownika i skomplikowanych embeddingów. W MVP liczą się trzy podstawowe grupy danych: użytkownicy lub sesje, obiekty oraz interakcje. Bez interakcji model nie ma z czego uczyć preferencji. Bez identyfikacji obiektu nie da się budować podobieństw ani historii. Bez czasu zdarzenia trudno odtworzyć realną sekwencję decyzji.

W praktyce minimalny zestaw pól w logach zdarzeń jest skromny, ale krytyczny: identyfikator użytkownika albo sesji, identyfikator elementu, typ zdarzenia i znacznik czasu. Jeśli któryś z tych elementów jest niestabilny, późniejsze modelowanie staje się dużo bardziej ryzykowne. Przykładowo świetne logi kliknięć niewiele pomogą, jeśli identyfikator użytkownika zmienia się między kanałami albo sesjami i nie da się odtworzyć historii zachowań.

Drugim filarem są metadane obiektów. Kategorie, tagi, tytuł, opis, a w zależności od domeny także cechy techniczne, temat, poziom trudności czy status dostępności. To właśnie one często ratują projekt na starcie, zwłaszcza gdy danych o użytkowniku jest mało. Jeśli katalog jest dobrze opisany, można szybko zbudować rekomendacje podobnych elementów bez czekania na gęstą macierz interakcji.

Dane „miłe do posiadania” istnieją, ale nie trzeba od nich zaczynać. Rozbudowane profile demograficzne, sygnały z urządzenia, dane zewnętrzne, embeddingi z innych systemów czy skomplikowany kontekst behawioralny potrafią pomóc, lecz w MVP często bardziej komplikują pipeline niż realnie poprawiają wynik. Gdy fundament jest słaby, dokładanie kolejnych cech tylko maskuje problem.

Sygnały nie są równe — kliknięcie to nie zakup

Jednym z najczęstszych błędów jest wrzucenie wszystkich zdarzeń do jednego worka pod etykietą „aktywność użytkownika”. Tymczasem kliknięcie, obejrzenie, dodanie do koszyka i zakup mają inną wagę. Klik może oznaczać ciekawość, przypadek albo źle sformułowany tytuł. Zakup lub zapisanie na później zwykle niesie mocniejszy sygnał intencji. Jeżeli model traktuje te zdarzenia identycznie, uczy się spłaszczonej wersji rzeczywistości.

W praktyce dobrze działa prosta hierarchia sygnałów. Obejrzenie fragmentu materiału można potraktować jako słaby ślad zainteresowania. Dłuższa konsumpcja, dodanie do listy lub koszyka to sygnały mocniejsze. Zakup, finalizacja lub wyraźna pozytywna akcja mają najwyższy priorytet. Nie chodzi o skomplikowaną matematykę, tylko o sensowną reprezentację tego, co naprawdę oznacza zachowanie użytkownika.

Trzeba też uważać na szum. Długie oglądanie nie zawsze znaczy satysfakcję; czasem oznacza niezdecydowanie albo problem ze znalezieniem informacji. Kliknięcie nie zawsze oznacza trafność; bywa skutkiem chwytliwego nagłówka. Brak kliknięcia też nie jest czystym sygnałem negatywnym, bo użytkownik mógł po prostu nie zobaczyć elementu. System rekomendacji budowany na logach zdarzeń prawie nigdy nie pracuje na idealnych etykietach.

Wniosek praktyczny jest prosty: lepszy bywa prosty model na dobrze opisanych sygnałach niż złożony model uczony na przypadkowo zebranych eventach. Jeśli wyniki są dziwne, najpierw trzeba sprawdzić semantykę zdarzeń, a dopiero później zastanawiać się nad bardziej zaawansowanym algorytmem.

Mała tabela, duża różnica w jakości danych

Od surowych logów do zbioru, na którym da się bezpiecznie trenować

Czyszczenie, agregacja i okna czasowe

Surowe logi zdarzeń prawie nigdy nie nadają się od razu do trenowania. Trzeba usunąć duplikaty, ruch botów, konta testowe, zdarzenia techniczne oraz obiekty, których nie da się realnie rekomendować. Jeśli w danych zostają elementy niedostępne, usunięte albo sztucznie podbijane testami, model uczy się złych wzorców. Potem wygląda to tak, jakby algorytm był słaby, choć problem leży w higienie danych.

Kolejna decyzja dotyczy agregacji. Czasem wystarczy para użytkownik–element z policzoną liczbą interakcji, ale w innych przypadkach ważna jest sesja, kolejność działań albo okno czasowe. Dla rekomendacji „podobne do tego, co oglądasz teraz” liczy się bieżąca sekwencja. Dla rekomendacji „co może cię zainteresować ogólnie” bardziej sensowna bywa zagregowana historia z kilku tygodni lub miesięcy.

Czas jest jednym z najbardziej niedocenianych wymiarów. Stare zachowania mogą pomagać albo szkodzić. W katalogu treści, gdzie świeżość ma ogromne znaczenie, zbyt długa historia wprowadza szum i promuje materiały, które kiedyś działały, ale dziś są nieaktualne. W domenach z dłuższym cyklem decyzji część starszych interakcji nadal może być wartościowa. Nie ma jednej poprawnej długości historii; trzeba ją dobrać do rytmu produktu.

Dobrym testem zdrowego rozsądku jest pytanie: czy użytkownik sprzed miesięcy zachowuje się dziś podobnie i czy katalog zmienia się wolno, czy szybko? Jeśli odpowiedź brzmi „nie”, przycinanie historii powinno być bardziej agresywne. To mały ruch techniczny, który potrafi poprawić trafność bardziej niż zmiana modelu.

Najczęstszy błąd: przeciek danych przez zły podział

Jeśli system rekomendacji ma działać w realnym czasie produktu, to test offline też powinien możliwie wiernie symulować przyszłość. Dlatego podział treningowy i testowy powinien uwzględniać czas, a nie być losowym przemieszaniem wszystkich zdarzeń. W przeciwnym razie model może uczyć się z informacji, które w momencie rekomendacji nie były jeszcze dostępne.

Przeciek danych ma wiele form. Najprostsza: cechy obiektu albo użytkownika zostały policzone z całej historii, również tej po dacie testowej. Inna pułapka: model przewiduje zakup na podstawie sygnałów, które pojawiły się już po dodaniu elementu do koszyka, więc formalnie wynik wygląda świetnie, ale praktycznie nie ma wartości predykcyjnej. Jeszcze inny problem to losowy split, który sprawia, że ten sam użytkownik i ten sam obiekt pojawiają się jednocześnie w treningu i teście w nienaturalny sposób.

Trzeba pilnować spójności czasu na każdym poziomie: cechy użytkownika, cechy elementu, agregaty popularności, etykieta i kontekst sesji powinny pochodzić z właściwego momentu. To bywa żmudne, ale bez tego ewaluacja offline staje się podejrzana. Bardzo dobre wyniki na papierze przy słabym zachowaniu po wdrożeniu często wskazują właśnie na przeciek albo źle postawione zadanie.

Jeżeli model wygląda zaskakująco dobrze już w pierwszej próbie, to nie zawsze jest dobra wiadomość. W praktyce to sygnał, że trzeba dwa razy sprawdzić pipeline danych, logikę targetu i moment powstawania cech. W systemach rekomendacyjnych podejrzanie łatwy sukces bywa bardziej niebezpieczny niż jawna porażka.

Jak z surowych zdarzeń zrobić zbiór uczący bez nadmiaru komplikacji

1. Zostaw tylko zdarzenia, które mają sens dla celu biznesowego i są wiarygodnie logowane.
2. Usuń ruch techniczny, testowy i obiekty, których nie wolno rekomendować.
3. Ustal okno czasowe zgodne z rytmem produktu i zbuduj cechy tylko z danych dostępnych do danego momentu.
4. Rozdziel zbiory po czasie, a nie losowo, i sprawdź, czy etykieta nie „widzi przyszłości”.
5. Zacznij od prostego targetu oraz prostych cech, które da się wyjaśnić i zweryfikować ręcznie.

Często problem wychodzi dopiero przy ręcznym sprawdzeniu kilku rekordów. W tabeli wszystko wygląda poprawnie, a potem okazuje się, że użytkownik „kupił” produkt po tym, jak produkt zniknął z oferty, albo że sekwencja zdarzeń została odwrócona przez błąd w stemplach czasu. Taki przegląd kilku przypadków jest nudny, ale zwykle oszczędza dni szukania winnego po stronie modelu.

Druga praktyczna rzecz to pilnowanie, by zbiór uczący odpowiadał temu, co system naprawdę będzie robił po wdrożeniu. Jeśli silnik ma wybierać kilka propozycji z aktualnie dostępnego katalogu, to trening nie powinien opierać się na obiektach, których później i tak nie da się pokazać. Jeśli rekomendacja ma działać dla nowych użytkowników, trzeba zostawić w ewaluacji także takie przypadki, zamiast przypadkiem testować wyłącznie tych najbardziej aktywnych.

Najlepszy pierwszy pipeline jest zwykle prostszy, niż zakłada zespół na starcie. Kilka dobrze zdefiniowanych eventów, sensowne okno czasu, porządny podział czasowy i baseline, który da się obronić. Dopiero na takim fundamencie widać, czy kolejne cechy naprawdę pomagają, czy tylko produkują bardziej skomplikowaną wersję tego samego błędu.

Jaki punkt startowy wybrać, żeby dowieźć działającą wersję zamiast ładnego prototypu

To zwykle wygląda podobnie: po tygodniu ktoś pokazuje notebook z efektownym modelem, a po miesiącu nadal nie ma czego podłączyć do produktu. Kłopot nie polega na tym, że model był za prosty albo za słaby. Kłopot polega na tym, że punkt startowy został wybrany pod prezentację, nie pod wdrożenie.

Najbezpieczniejszy start to baseline, który spełnia trzy warunki: da się go policzyć regularnie, da się go wyjaśnić biznesowi i da się go porównać z czymś jeszcze prostszym, na przykład popularnością globalną lub popularnością w kategorii. W wielu produktach taki pierwszy krok to rekomendacje oparte na współwystępowaniu interakcji, podobieństwie elementów albo prostym rankingu z wagami zdarzeń i świeżością. To nie brzmi spektakularnie, ale bardzo często wystarcza, by poprawić obecny stan i zbudować sensowny punkt odniesienia.

Trzeba też od razu zdecydować, gdzie system ma być mocny, a gdzie może być przeciętny. Inaczej projektuje się rekomendacje na stronę główną, inaczej „podobne produkty”, a jeszcze inaczej kolejny materiał w sesji. Każdy z tych przypadków ma inny kontekst, inne ograniczenia i inne ryzyka. Jeśli zespół próbuje jednym ruchem obsłużyć wszystko, kończy z rozwiązaniem, które nigdzie nie działa naprawdę dobrze.

Dobrze działa podejście etapowe. Najpierw jeden przypadek użycia, jeden sposób ewaluacji i jeden prosty mechanizm serwowania. Potem dopiero dochodzą reranking, personalizacja głębsza niż historia kilku akcji, obsługa cold startu czy bardziej zaawansowane modele. Dzięki temu łatwo zauważyć, co realnie poprawiło wynik, a co tylko zwiększyło koszt utrzymania.

Jeśli trzeba wybrać jedną zasadę na start, to taka: buduj system, który da się sprawdzić w produkcie szybciej niż da się o nim zrobić slajdy. Rekomendacje wygrywają nie wtedy, gdy wyglądają mądrze w eksperymencie offline, tylko wtedy, gdy na czystych danych i prostych regułach zaczynają regularnie pomagać użytkownikowi coś znaleźć, obejrzeć albo kupić.

Kiedy wystarczy popularność, a kiedy trzeba wejść w collaborative filtering lub hybrydę

Zwykle ten moment przychodzi szybko. Baseline działa, ale zespół widzi jego granice: wszyscy dostają podobne propozycje, nowe zainteresowania użytkownika są słabo wychwytywane, a katalog jest zbyt szeroki, by sama popularność dawała sensowną personalizację.

Najprostsza reguła wyboru jest praktyczna, nie modna. Jeśli masz mało wiarygodnych danych o użytkownikach, ale sporo informacji o samych elementach, rozsądnie zacząć od podejścia content-based. Jeśli cechy obiektów są ubogie, za to interakcji użytkownik–element jest dużo i układają się w powtarzalne wzorce, naturalnym kandydatem staje się collaborative filtering. Gdy obie strony są w miarę sensowne, zwykle najlepiej kończy się to hybrydą, choć niekoniecznie od razu skomplikowaną.

W praktyce decyzję można uprościć do kilku pytań:

• czy użytkownicy wracają i zostawiają historię, z której da się coś wyczytać,
• czy elementy mają opisy, kategorie, tagi albo inne stabilne cechy,
• czy katalog zmienia się szybko,
• czy ważniejsza jest personalizacja ogólna, czy rekomendacje „podobne do tego, co właśnie oglądasz”.

Dla sekcji „podobne produkty” albo „zobacz też” bardzo często wystarcza dobrze policzone podobieństwo elementów: współwystępowanie w sesjach, wspólne zakupy, zbliżone cechy treści. Dla strony głównej lub feedu częściej potrzebna jest warstwa użytkownika, nawet jeśli na początku jest dość prosta. Mini-wniosek jest taki: nie wybiera się jednej „najlepszej” klasy modelu dla całego produktu, tylko dobiera mechanizm do konkretnego miejsca użycia.

Prosty przewodnik po wyborze pierwszego mechanizmu

Jeśli celem jest pierwsza działająca wersja, sensowniej myśleć o kompromisach niż o pełnej mapie metod.

Jeżeli zespół waha się między dwiema ścieżkami, dobrym ruchem jest zbudowanie dwóch lekkich wariantów i porównanie ich na tym samym podziale czasowym. Nie po to, by wygrał model bardziej efektowny, tylko po to, by zobaczyć, który daje stabilniejsze wyniki dla realnych scenariuszy: aktywni użytkownicy, nowi użytkownicy, długi ogon katalogu, szybkie zmiany zainteresowań.

Minimalna architektura, która ma sens już przy MVP

W wielu zespołach kłopot zaczyna się wtedy, gdy „system rekomendacji” jest mylony z „jednym modelem”. Tymczasem nawet skromne wdrożenie składa się zwykle z kilku osobnych etapów. Jeśli się je rozdzieli od początku, łatwiej naprawić błędy i łatwiej rozwijać całość bez przebudowy wszystkiego naraz.

Candidate generation i ranking to nie to samo

Najpierw trzeba odpowiedzieć na proste pytanie: z czego w ogóle wybieramy? Candidate generation zawęża ogromny katalog do mniejszej puli sensownych kandydatów. Potem ranking ustala kolejność tych kandydatów dla konkretnego użytkownika i konkretnego kontekstu.

To rozdzielenie bywa ważniejsze niż wybór samego algorytmu. Jeżeli katalog jest większy, próba dokładnego rankingu wszystkich elementów na każde wywołanie szybko robi się kosztowna albo po prostu niepotrzebna. Dużo bezpieczniej wygenerować ograniczoną listę kandydatów z kilku źródeł, a dopiero potem zastosować prostszy lub bogatszy ranking.

Przykład praktyczny: kandydaci mogą pochodzić równolegle z kilku mechanizmów — popularne w kategorii, podobne do ostatnio oglądanego, elementy zgodne z profilem użytkownika, nowości z filtrem jakości. Sam ranking może wtedy uwzględnić świeżość, przewidywaną intencję, różnorodność i dostępność. Mini-wniosek: nawet jeśli pierwszy model jest prosty, architektura dwustopniowa daje lepszą kontrolę nad tym, co trafia do użytkownika.

Najmniejszy sensowny pipeline

Nie trzeba od razu budować pełnej platformy ML. Dla pierwszego sensownego wdrożenia zwykle wystarcza taki układ:

1. regularny import i czyszczenie logów zdarzeń,
2. budowa cech i agregatów w podziale czasowym,
3. okresowe trenowanie albo przeliczanie modelu/baseline’u,
4. generowanie list kandydatów dla użytkowników lub elementów,
5. warstwa serwowania, która potrafi zwrócić rekomendacje szybko i z filtrem dostępności.

Do tego dochodzą dwa elementy, o których łatwo zapomnieć, bo nie wyglądają „modelowo”: monitoring jakości danych i prosty mechanizm fallbacku. Jeśli codzienny proces nie policzy modelu, system nie powinien zwracać pustej odpowiedzi. Lepiej wtedy podać bezpieczny zestaw oparty na popularności, kategorii albo ostatniej poprawnej wersji.

Właśnie takie detale odróżniają prototyp od rozwiązania, które da się podłączyć do produktu bez ciągłego gaszenia pożarów.

Cold start bez magii: co robić, gdy użytkownik albo element są nowi

To jeden z tych problemów, które wracają niemal zawsze. Produkt startuje, katalog się zmienia, część użytkowników odwiedza serwis pierwszy raz, a model oparty na historii mówi wtedy niewiele albo nic.

Nowy użytkownik

Dla nowego użytkownika najgorszą decyzją jest udawanie pełnej personalizacji. Lepiej jawnie oprzeć się na kontekście sesji i mocnych sygnałach dostępnych od razu. Mogą to być:

• popularne elementy w danym miejscu produktu,
• popularność zawężona do kategorii, języka, typu treści albo źródła wejścia,
• krótka historia z bieżącej sesji, nawet jeśli to tylko kilka kliknięć,
• lekkie reguły eksploracji, żeby nie zamykać nowego użytkownika w jednym schemacie.

Jeśli użytkownik obejrzał dwa podobne obiekty w jednej sesji, to już jest materiał do prostych rekomendacji sekwencyjnych. W wielu sytuacjach taki sygnał bywa cenniejszy niż stara historia użytkownika, który dawno nie wracał.

Nowy element

Nowe elementy cierpią odwrotnie: użytkownicy jeszcze z nimi nie weszli w interakcję, więc collaborative filtering ich nie „widzi”. Tu pomagają cechy obiektu i reguły ekspozycji. Jeśli element ma sensowne metadane, można podpiąć go do rekomendacji content-based albo do podobnych grup katalogowych. Jeśli jakość nowości jest niepewna, rozsądnie dodać warstwę kontroli — na przykład ograniczyć widoczność do miejsc, gdzie koszt nietrafionej rekomendacji jest mniejszy.

Typowy błąd polega na tym, że nowe elementy nigdy nie trafiają do kandydatów, więc nigdy nie zbierają interakcji, więc dalej nie trafiają do kandydatów. To zamknięte koło. Trzeba świadomie zostawić trochę miejsca na ekspozycję nowości, inaczej system będzie tylko wzmacniał to, co już popularne.

Jak mierzyć jakość offline, żeby nie oszukać samego siebie

Zespół często widzi jedną liczbę i odruchowo traktuje ją jak prawdę o całym systemie. Problem w tym, że system rekomendacji rzadko daje się opisać jedną metryką. Co więcej, część rzeczy naprawdę ważnych wychodzi dopiero po wdrożeniu.

Metryki offline są potrzebne, ale tylko w odpowiednim użyciu

Offline można dobrze oceniać to, czy model potrafi odzyskać elementy, z którymi użytkownik faktycznie wszedł później w interakcję. Przydatne są metryki typu precision@k, recall@k, hit rate, MAP albo NDCG. Nie chodzi jednak o to, by ścigać się na komplet metryk naraz, tylko dobrać je do sposobu użycia rekomendacji.

Jeżeli użytkownik widzi krótki moduł z kilkoma propozycjami, bardziej interesuje jakość topowych pozycji niż zachowanie długiej listy. Jeśli rekomendacje mają wspierać odkrywanie katalogu, sama trafność może nie wystarczyć i trzeba patrzeć też na pokrycie katalogu albo różnorodność. System, który stale pokazuje te same mocne pozycje, często świetnie wygląda w części metryk, a jednocześnie ogranicza realną wartość produktu.

Czego offline nie pokaże

Nie da się uczciwie ocenić offline wszystkiego, co zależy od interfejsu, pozycji modułu, konkurencji innych elementów na stronie czy wpływu rekomendacji na dłuższą ścieżkę użytkownika. Model może dobrze przewidywać klik, ale prowadzić do gorszej finalizacji. Może też promować treści łatwe do kliknięcia, ale mało wartościowe biznesowo.

Dlatego wyniki offline lepiej traktować jak filtr bezpieczeństwa niż jak ostateczny werdykt. Jeśli model przegrywa z prostą popularnością już offline, trudno liczyć na cud po wdrożeniu. Ale jeśli wygrywa offline, to jeszcze nie znaczy, że wygra w produkcie.

Jak porównywać modele sensownie

Porównanie ma sens dopiero wtedy, gdy wszystkie warianty działają na tym samym podziale czasowym, tej samej definicji targetu i tej samej puli kandydatów albo przy jasno opisanej różnicy. Inaczej łatwo pomylić poprawę modelu z poprawą danych wejściowych.

Dobrą praktyką jest też rozbicie wyników na segmenty, bo średnia często ukrywa prawdziwy obraz. Model może poprawiać aktywnych użytkowników, ale pogarszać doświadczenie nowych. Może dobrze działać w głównych kategoriach, a fatalnie w długim ogonie. Taki rozkład mówi o systemie więcej niż jedna ogólna liczba.

Typowe miejsca, w których projekt wykłada się mimo „dobrego modelu”

Czasem wszystko wygląda poprawnie: model działa, metryki są przyzwoite, pipeline się wykonuje. A mimo to rekomendacje są przeciętne albo irytujące. Wtedy zwykle problem leży nie w algorytmie, tylko w jednej z decyzji wokół niego.

• Zła definicja sukcesu — system optymalizuje klik, choć produkt potrzebuje jakości dalszego kroku.
• Źle dobrane negatywy — brak interakcji został uznany za jednoznaczny brak zainteresowania, choć użytkownik nawet nie miał szansy zobaczyć elementu.
• Zbyt aktywna populacja w treningu i teście — model wygląda dobrze, bo oceniany jest głównie na użytkownikach z bogatą historią.
• Brak filtrowania dostępności — rekomendowane są obiekty niedostępne, wygasłe albo niepasujące do kontekstu.
• Brak różnorodności — system pokazuje pięć niemal identycznych propozycji, więc formalnie trafia w temat, ale praktycznie marnuje miejsce.
• Nadmiar złożoności za wcześnie — zespół inwestuje w model, zanim ustali, czy sygnały wejściowe są stabilne i sensownie opisane.

Jedna z bardziej zdradliwych sytuacji wygląda tak: model konsekwentnie promuje elementy, które już i tak byłyby klikane z powodu ekspozycji w produkcie. Na papierze wygląda to dobrze, ale system nie wnosi dodatkowej wartości. Bez testu produkcyjnego trudno to odróżnić od realnej poprawy.

Jeśli trzeba szybko ustalić, czy kłopot leży w danych, czy w modelu, dobrze zrobić prosty test kontrolny: uruchomić kilka ręcznie zrozumiałych reguł, porównać je z obecnym modelem i obejrzeć rekomendacje rekord po rekordzie. Gdy prosty mechanizm daje podobny wynik, a model jest wielokrotnie bardziej skomplikowany, zwykle nie brakuje „mocniejszego algorytmu”, tylko lepszego sygnału i lepiej postawionego zadania.

Najbezpieczniejsza ścieżka prowadzi przez małe, sprawdzalne decyzje. Najpierw czyste dane i prosty cel. Potem baseline, który da się obronić. Dopiero później bardziej ambitna personalizacja. W systemach rekomendacyjnych to podejście zwykle dowozi szybciej niż próba przeskoczenia od surowych logów prosto do skomplikowanego silnika.

Najczęściej zadawane pytania (FAQ)

Od czego zacząć budowę systemu rekomendacji?

Zwykle problem zaczyna się nie od danych, tylko od celu. Zespół ma logi kliknięć, katalog produktów i oczekiwanie, że „AI coś wymyśli”, ale bez odpowiedzi na pytanie, co dokładnie ma się poprawić, model będzie optymalizował przypadkową metrykę. Inaczej projektuje się rekomendacje pod zakup, inaczej pod kliknięcie, a jeszcze inaczej pod odkrywanie nowych treści.

Dobry start to ustalenie trzech rzeczy: jakie zachowanie użytkownika chcemy poprawić, w jakim miejscu interfejsu pokażemy rekomendacje i dla kogo one są — nowego użytkownika, powracającego czy anonimowej sesji. Ten etap brzmi mało „AI”, ale właśnie on najczęściej decyduje, czy system będzie użyteczny.

Jakie dane są potrzebne do MVP systemu rekomendacji?

Do pierwszej działającej wersji nie trzeba rozbudowanego stacku danych. W praktyce wystarczą trzy grupy informacji: użytkownicy lub sesje, obiekty oraz interakcje między nimi. Kluczowe są przede wszystkim logi zdarzeń z czasem, bo bez kolejności zdarzeń łatwo zbudować model, który „wie za dużo” o przyszłości.

Minimalny zestaw danych zwykle obejmuje:

• identyfikator użytkownika albo sesji,
• identyfikator produktu, treści lub innego obiektu,
• typ zdarzenia, np. kliknięcie, dodanie do koszyka, zakup,
• znacznik czasu,
• podstawowe metadane obiektu, np. kategoria, tagi, tytuł, dostępność.

Jeśli identyfikatory są niestabilne albo katalog ma słabe opisy, nawet dobry algorytm będzie miał ograniczone pole manewru. Najpierw porządek w danych, potem rozbudowa modelu.

Czy kliknięcia wystarczą do trenowania rekomendacji?

Czasem tak, ale tylko jako punkt startowy. Kliknięcie jest sygnałem słabszym niż zakup, zapisanie na później czy dłuższe zaangażowanie w treść. Gdy model traktuje wszystkie interakcje tak samo, zaczyna uczyć się nie intencji użytkownika, tylko mieszaniny ciekawości, przypadku i jakości nagłówka.

W praktyce lepiej ustawić prostą hierarchię sygnałów i nadać im różną wagę. W sklepie zakup zwykle mówi więcej niż samo wejście na kartę produktu. W serwisie contentowym lepszym sygnałem niż klik może być dokończenie materiału albo powrót do podobnego tematu. Jeśli celem biznesowym jest sprzedaż, model oparty wyłącznie na klikach często zawyża wyniki offline, a rozczarowuje po wdrożeniu.

Kiedy wybrać collaborative filtering, a kiedy content-based?

Jeżeli masz sporo wiarygodnych interakcji użytkownik–obiekt, collaborative filtering bywa bardzo skuteczny, bo uczy się wzorców współwystępowania: co oglądają, kupują albo czytają podobni użytkownicy. Problem pojawia się wtedy, gdy danych jest mało, katalog szybko się zmienia albo duża część ruchu pochodzi od nowych użytkowników.

Content-based sprawdza się lepiej, gdy obiekty są dobrze opisane i da się sensownie porównać ich cechy. To częsty wybór na start, zwłaszcza przy cold starcie nowych produktów lub treści. W praktyce wiele systemów kończy jako hybryda: candidate generation z jednego źródła, a ranking z uwzględnieniem drugiego. Jeśli trzeba wystartować szybko, prosty model podobieństwa obiektów bywa rozsądniejszy niż ambitne collaborative filtering na słabych logach.

Jak poradzić sobie z problemem cold start?

Cold start pojawia się wtedy, gdy nie ma historii dla użytkownika, obiektu albo obu naraz. To klasyczna sytuacja: nowy produkt trafia do katalogu i przez kilka dni nie ma szans być polecany, bo model nie widzi interakcji. Podobnie z nowym użytkownikiem, który wszedł pierwszy raz i nie zostawił jeszcze żadnych śladów.

Najczęstsze sposoby obejścia problemu to:

• wykorzystanie metadanych obiektów, np. kategorii, tagów i opisów,
• rekomendacje popularne lub świeże w danym kontekście,
• sygnały sesyjne, np. to, co użytkownik właśnie ogląda,
• reguły biznesowe dla nowych elementów, by nie znikały z obiegu.

Jeżeli cold start dotyczy dużej części ruchu, system oparty wyłącznie na historii zachowań będzie miał naturalny sufit. Wtedy cechy obiektów i logika miejsca użycia stają się równie ważne jak sam model.

Jak przygotować logi zdarzeń do rekomendacji bez przecieków danych?

To miejsce, w którym łatwo zepsuć cały eksperyment. Najczęstszy błąd polega na trenowaniu modelu na danych, które w realnym momencie rekomendacji nie były jeszcze dostępne. Przykład z praktyki: model ocenia produkt na podstawie interakcji z przyszłych dni, więc offline wygląda świetnie, ale po wdrożeniu wynik nagle spada.

Bezpieczne przygotowanie danych oznacza kilka prostych zasad: dzielenie zbiorów po czasie, odtwarzanie sekwencji zdarzeń tak, jak widział je system, filtrowanie elementów niedostępnych oraz pilnowanie, by cechy użytkownika i obiektu pochodziły z właściwego momentu. Jeśli ewaluacja nie szanuje czasu, porównujesz model z wersją rzeczywistości, która nigdy nie istniała.

Jak sprawdzić, czy problem leży w danych, a nie w algorytmie?

To pytanie pojawia się zwykle wtedy, gdy drugi lub trzeci model daje prawie taki sam wynik jak pierwszy. W takiej sytuacji podejrzanym numer jeden są dane: za mało interakcji, niestabilne identyfikatory, słabe metadane, źle zdefiniowany cel albo zbyt płytkie sygnały. Zmiana architektury niewiele da, jeśli wejście jest chaotyczne.

Dobrym testem jest porównanie z prostym baseline’em, na przykład rekomendacją popularnych elementów, podobnych obiektów albo najczęściej współoglądanych produktów. Jeśli rozbudowany model ledwo przebija baseline, trzeba najpierw sprawdzić jakość logów, definicję etykiety i sposób ewaluacji offline. Gdy baseline jest zaskakująco mocny, często oznacza to nie porażkę, tylko sygnał, że fundament projektu jest jeszcze ważniejszy niż „mądrzejszy” algorytm.

Najważniejsze punkty

• Projekt rekomendacji najczęściej wykłada się nie na modelu, tylko na starcie: najpierw trzeba ustalić, czy system ma poprawiać kliknięcia, zakupy, retencję, czas w serwisie czy odkrywanie treści, bo od tego zależą dane, etykiety i sposób oceny.
• To samo „trafne polecenie” znaczy co innego w różnych branżach i miejscach interfejsu — sklep, feed contentowy, karta produktu czy koszyk wymagają innych sygnałów i często innej logiki rekomendacji.
• Na początku trzeba jasno określić odbiorcę rekomendacji: nowy użytkownik, powracający użytkownik albo anonimowa sesja. To rozstrzyga, czy można oprzeć się na historii zachowań, czy lepiej bazować na cechach obiektów i bieżącym kontekście.
• Nie zawsze rekomenduje się pojedynczy produkt lub artykuł; czasem lepiej podpowiadać kategorię, dokument powiązany, kolejny krok procesu albo zestaw elementów. Im bardziej złożony obiekt, tym większe znaczenie mają reguły biznesowe i jakość katalogu.
• Nawet MVP nie wymaga rozbudowanej infrastruktury, ale bez trzech rzeczy system nie ruszy sensownie: identyfikacji użytkownika lub sesji, identyfikacji obiektu oraz logów interakcji z czasem zdarzenia, które pozwalają odtworzyć realną sekwencję decyzji.
• Baseline rekomendacyjny to nie strata czasu, tylko punkt odniesienia: zanim zespół sięgnie po collaborative filtering czy content-based, powinien sprawdzić, czy prostsze podejście już nie rozwiązuje problemu wystarczająco dobrze.