Cleora: rekomendacje bez modelu językowego

Zachowanie Twoich klientów układa się w graf samo z siebie. Klient łączy się z produktem, który kupił, produkt z kategorią, koszyk z innym koszykiem. Nikt tego nie projektuje, to po prostu zapis tego, co wydarzyło się w sklepie. Embedding to zamiana takiego obiektu na wiersz liczb, zwykle kilkuset, ułożony tak, żeby obiekty o podobnej historii miały podobne wiersze. Kiedy masz już te wiersze, pytanie „co jest podobne do tego produktu” przestaje być problemem badawczym i staje się zwykłym wyszukiwaniem najbliższych sąsiadów w bazie danych.

Czym jest Cleora i kto ją zbudował

Cleorę opisali w lutym 2021 roku Barbara Rychalska, Piotr Bąbel, Konrad Gołuchowski, Andrzej Michałowski i Jacek Dąbrowski, pracujący w polskiej firmie Synerise, częściowo także na Politechnice Warszawskiej. Kod od początku jest otwarty, na licencji MIT, która pozwala na użycie komercyjne. Dziś repozytorium prowadzi BaseModelAI, a bibliotekę instaluje się jednym poleceniem jako pycleora. Najnowsze wydanie w serwisie PyPI ma datę 2 kwietnia 2026 roku, więc projekt nie jest porzucony.

Sam pomysł jest zaskakująco prosty. Każdy węzeł grafu dostaje na starcie wiersz liczb, a potem w kółko zastępuje go uśrednionym wierszem swoich sąsiadów i normalizuje wynik. Nie ma funkcji celu, nie ma losowania przykładów pozytywnych i negatywnych, nie ma karty graficznej. Autorzy piszą, że algorytm ma tylko dwa parametry do ustawienia, liczbę powtórzeń i długość wiersza, podczas gdy konkurencyjny PyTorch BigGraph ma ich co najmniej osiemnaście. Ta prostota jest powodem, dla którego liczby poniżej wyglądają tak, jak wyglądają.

Liczby, które opublikowali autorzy

W pracy z 2021 roku autorzy zmierzyli czas na pięciu publicznych grafach. Weźmy graf YouTube: 1 134 890 węzłów i 2 987 624 krawędzi. Policzenie embeddingów zajęło Cleorze 12 minut i 7 sekund. PyTorch BigGraph, skalowalny silnik z laboratorium Facebooka, potrzebował 54 minut i 35 sekund. DeepWalk, klasyczna metoda grafowa, liczył 28 godzin i 33 minuty. Wszystko na jednej maszynie w chmurze Azure, typ Standard E32s v3, 32 wirtualne rdzenie i 256 GB pamięci.

Na większych grafach różnica rośnie. LiveJournal, 4 847 571 węzłów i niecałe 69 milionów krawędzi: Cleora 1 godzina 36 minut, PyTorch BigGraph 10 godzin 38 minut, DeepWalk nie skończył wcale. Na grafie Twittera, 41,65 miliona węzłów i 1,47 miliarda krawędzi, jedyną metodą, która dobiegła do końca, była Cleora, w 25 godzin i 34 minuty. Pozostałe przerwały pracę na zużyciu pamięci. Autorzy dodają, że w ich własnym środowisku produkcyjnym największe zbiory e-commerce liczyły się poniżej dwóch godzin na tej samej maszynie.

Jakość to inna historia i warto ją przeczytać dokładnie. W zadaniu przypisywania węzłów do kategorii na grafie Facebooka, 22 470 węzłów, Cleora dostała micro‑F1, czyli miarę trafności, na poziomie 0,9165. To czwarty wynik z pięciu. Lepsze były LINE (0,9442), DeepWalk (0,9349) i PyTorch BigGraph (0,9258). Tyle że dwie pierwsze metody autorzy sami zaliczyli do nieskalowalnych: na większych grafach po prostu nie kończą pracy. Gorzej od niej wypadł tylko GOSH, metoda liczona na karcie graficznej. Cleora nie wygrywa jakością. Wygrywa tym, że dowozi wynik wtedy, gdy inni się poddają.

Gdzie to bije model językowy

Model językowy nie ma tu przewagi, bo nie ma czego czytać. Informacja, że dwa produkty pasują do siebie, nie siedzi w ich opisach, tylko w tym, że tysiąc osób kupiło je razem. Do tego dochodzi rachunek. Załóżmy, że pokazujesz sekcję „podobne produkty” przy 100 tysiącach odsłon dziennie i że jedno zapytanie do modelu to 2000 tokenów wejściowych, czyli kawałków tekstu. To założenie, nie pomiar. Wychodzi 200 milionów tokenów dziennie. W publicznym cenniku Anthropic najtańszy model, Claude Haiku 4.5, kosztuje 1 dolara za milion tokenów wejściowych, więc same wejścia to 200 dolarów dziennie, około 6 tysięcy dolarów miesięcznie, zanim policzymy odpowiedzi.

Po stronie embeddingów opłata za pojedyncze zapytanie nie istnieje. Wiersze liczb są policzone wcześniej, a odpowiedź to wyszukanie w bazie danych, więc opóźnienie jest takie samo jak przy każdym innym zapytaniu do niej. Dla skali: w benchmarku na stronie projektu graf sieci drogowej Kalifornii, 1 965 206 węzłów, policzył się w 31,5 sekundy na jednym współdzielonym rdzeniu.

Gdzie ta metoda zawodzi

Największa dziura jest tam, gdzie nie ma historii. Cleora czyta wyłącznie strukturę grafu, więc produkt wstawiony dziś do katalogu nie ma z czego dostać wiersza liczb. Zespół Zomato, platformy do zamawiania jedzenia, opisał to wprost w kwietniu 2022 roku: w odróżnieniu od GraphSAGE, czyli sieci neuronowej na grafach, do Cleory nie dało się wtedy podać cech produktu, a wagi krawędzi nie były zaimplementowane. Ta sama publikacja jest zresztą najczęściej powtarzanym argumentem za Cleorą: embeddingi dla jednego regionu w Indiach liczyły się poniżej 5 minut zamiast około 20 godzin, których potrzebował GraphSAGE.

• Zimny start. Nowy produkt bez ani jednego zakupu nie istnieje w grafie, więc nie ma dla niego wektora.
• Encje dominujące. Dokumentacja projektu ostrzega, że obiekt obecny w prawie każdym koszyku, na przykład reklamówka, psuje wyniki i lepiej go usunąć z danych wejściowych.
• Dokładanie węzłów po fakcie. Autorzy sprawdzili to w osobnym eksperymencie, w którym uczą wprost tylko 30 procent węzłów, a punktem odniesienia jest 0,9190: gdy pozostałe 70 procent dolicza się po policzeniu reszty, trafność na grafie Facebooka spada do 0,8718, a przy drugim poziomie odtwarzania do 0,7856. Na grafie YouTube spadki wynoszą 18 i 40 procent.
• Mieszanie typów. Dokumentacja mówi wprost, że porównywanie wektora klienta z wektorem produktu jest metodologicznie błędne. Najpierw liczy się produkty, potem składa z nich klientów.

Jak to łączyć z modelem językowym

Te dwa światy się nie wykluczają. Dokumentacja Cleory opisuje wprost, że startowe wiersze liczb można wziąć z modelu czytającego tekst albo obrazek i dopiero potem puścić uśrednianie po grafie. To jest gotowa odpowiedź na zimny start: nowy produkt wchodzi do systemu z wektorem ze swojego opisu i zdjęcia, a historia zakupów poprawia ten wektor później. Sami autorzy poszli dalej i w 2020 roku opublikowali EMDE, nadbudowę, która z wektorów produktów i listy zakupów klienta robi jedną zwięzłą reprezentację klienta. Zomato zbudowało na parze Cleora plus EMDE swoje rekomendacje i podaje Recall@Top10, czyli trafienia w pierwszej dziesiątce, na poziomie 35 procent, zaznaczając od razu, że sama ta liczba niewiele mówi bez miar różnorodności. W takim układzie graf odpowiada na pytanie „co pokazać”, a model językowy co najwyżej na „jak o tym napisać”.

Czego te liczby nie obiecują

Pomiary z pracy pochodzą z lutego 2021 roku i porównują Cleorę z tym, co wtedy uchodziło za skalowalne: PyTorch BigGraph, GOSH, DeepWalk i LINE. Od tamtej pory zmienił się i sprzęt, i konkurencja. Nowszy benchmark na stronie projektu pokazuje Cleorę na pierwszym miejscu we wszystkich pięciu zbiorach, ale warto doczytać metodologię. Wszystko puszczono na jednym współdzielonym rdzeniu z około 3 GB pamięci i limitem 90 sekund na wynik, konkurenci dostali ustawienia domyślne bez strojenia, a autorzy strony sami przyznają, że na większej maszynie część z nich by dokończyła obliczenia. To benchmark dostawcy, nie niezależny test.

Jest jeszcze jedna rzecz, którą łatwo przeoczyć, a która w sklepie zmienia wszystko: liczba powtórzeń zmienia znaczenie wyniku. Przy jednym powtórzeniu najbliżsi sąsiedzi produktu to rzeczy kupowane razem z nim, przy czterech to rzeczy, którymi można go zastąpić. Autorzy pokazali to na danych Dunnhumby z 2500 gospodarstw domowych zbieranych przez dwa lata. To jeden parametr, a odpowiada na dwa zupełnie różne pytania biznesowe i łatwo ustawić go odwrotnie, niż się chciało.

Jeśli masz katalog i historię transakcji, ten test jest tani: jeden plik z parami klient i produkt, jedno przeliczenie, porównanie wyników z tym, co pokazujesz dziś. Jeśli chcesz to sprawdzić na swoich danych, napisz do nas.