Modele rekomendacyjne dla mebli modułowych: jak unikać absurdalnych podpowiedzi AI

Dlaczego meble modułowe są trudnym przypadkiem dla modeli rekomendacyjnych

Złożoność kombinatoryczna zamiast prostego „jeden produkt = jeden wybór”

Meble modułowe nie są pojedynczym, skończonym produktem. To przestrzeń konfiguracji, w której klient składa zestaw z wielu elementów: szafek, korpusów, frontów, blatów, boków maskujących, cokołów, łączników. Dla modelu rekomendacyjnego oznacza to nieporównywalnie większą złożoność niż przy książkach czy ubraniach.

System nie rekomenduje „jednej szafki”, lecz sugeruje kolejne elementy do już istniejącej konfiguracji, która może mieć dziesiątki stanów pośrednich. Każdy nowy moduł zmienia kontekst: wolną przestrzeń, dostępne połączenia, dopuszczalne wysokości i kierunki otwierania frontów. Bez uwzględnienia tej złożoności, model rekomendacyjny będzie produkował podpowiedzi, które są logiczne z punktu widzenia statystyki współwystępowania, ale kompletnie bez sensu konstrukcyjnego.

Do tego dochodzi ograniczona kompletność danych: sklep rzadko widzi wszystkie etapy konfiguracji klienta. Często ma jedynie finalny zestaw na zamówieniu lub kilka zapisanych konfiguracji. To jeszcze bardziej utrudnia uczenie modeli, które miałyby rozumieć „sekwencję budowy” zabudowy modułowej.

Dlaczego klasyczne „kupiono razem” prowadzi do absurdów

Standardowe modele typu „customers who bought this also bought” (kolaboratywne filtrowanie item–item) działają dobrze, gdy produkty są w dużej mierze niezależne. Klient kupił książkę A i książkę B? Jest sens polecić książkę A+1, jeśli inni kupowali taki zestaw. W meblach modułowych zależności są dużo bardziej restrykcyjne.

Jeśli wielu klientów kupiło razem szafkę narożną i front do szafki wysokiej, klasyczny algorytm może to odczytać jako silny sygnał współwystępowania. Natomiast technicznie te dwa elementy nie są ze sobą bezpośrednio powiązane – występują w tej samej kuchni, ale nie są zamiennikami ani kompatybilnymi końcówkami sekwencji. Model bez zrozumienia struktury zabudowy będzie proponował:

• front słupkowy jako uzupełnienie dla samodzielnej szafki stojącej 40 cm,
• elementy zabudowy lodówki w konfiguracji bez miejsca na sprzęt AGD,
• szafkę wiszącą 80 cm nad słupkiem wysokim, gdzie fizycznie nie ma miejsca.

Z punktu widzenia surowych danych zakupowych takie powiązania są „prawdziwe”, ale z punktu widzenia montażu – bezwartościowe, a czasem wręcz wprowadzające klienta w błąd.

Typowe absurdalne rekomendacje w meblach modułowych

Bez twardych ograniczeń produktowych typowe systemy rekomendacyjne popełniają przewidywalne błędy. Najczęściej spotykane przypadki:

• Niepasujące wymiary – proponowanie szafki 60 cm do przestrzeni, w której zostało 45 cm, bo „klienci często kupowali razem 60 i 80 cm”.
• Niespójne kolory i wykończenia – sugerowanie frontów w innym dekorze niż dotychczasowe moduły, bo nazwa serii jest podobna albo z powodu wspólnych zakupów w ramach promocji.
• Niekompatybilne systemy mocowań – rekomendowanie frontu pod inny system zawiasów lub inne wiercenia, bo w danych historycznych fronty różnych systemów pojawiały się w tym samym zamówieniu.
• Przekręcone kierunki otwierania – sugerowanie drzwi lewych tam, gdzie konstrukcyjnie możliwe są tylko prawe, albo dokładanie szafki z otwieraniem na środek kolidującym z sąsiednią.
• Niespójne poziomy i głębokości – mieszanie korpusów o różnych głębokościach w jednej linii, z punktu widzenia algorytmu podobnych, ale wizualnie tworzących „schody”.

Do tego dochodzą nietrafione bundle: system może proponować gotowe zestawy akcesoriów, które pasują do innej generacji okuć, innego typu prowadnic lub innej wysokości korpusu. Z perspektywy klienta sklepu online wygląda to jak „inteligentny chaos”, który podważa zaufanie do całej platformy.

Jak decyzje biznesowe dodatkowo niszczą jakość sygnałów

Dane dla modeli rekomendacyjnych zwykle nie pochodzą z „czystego świata idealnej racjonalności klienta”, ale są przefiltrowane przez politykę sprzedażową, promocje i działania marketingowe. W meblach modułowych widać to szczególnie mocno:

• Sztuczne bundlowanie – pakiety typu „zestaw startowy kuchni” z losowo dobranymi szafkami, zaprojektowane pod rabat, a nie pod optymalną konfigurację. Model uczy się, że te konkretnie moduły „pasują do siebie”, mimo że klient tak naprawdę potrzebował innego układu.
• Promocje wymuszone – rabaty na konkretną szerokość czy kolor, które chwilowo zaburzają rozkład sprzedaży. Algorytm zaczyna faworyzować te elementy jako „często wybierane”, chociaż motywacją był tylko niższy koszt.
• Wyprzedaże końcówek serii – mieszanie starych i nowych systemów w jednym zamówieniu, gdy klient (czy sprzedawca) „dobija” zamówienie tym, co jest na magazynie. Dla modelu rekomendacyjnego to sygnał współwystępowania, który w normalnych warunkach byłby nielogiczny.

Bez świadomego traktowania tych zjawisk jako zanieczyszczeń danych, każdy nawet bardzo zaawansowany model będzie wzmacniał chaotyczne decyzje biznesowe zamiast projektować sensowne konfiguracje.

Modelowanie danych o modułach i konfiguracjach – fundament bez którego nic nie zadziała

Jak opisać pojedynczy moduł w sposób przyjazny dla ML

Pojedynczy moduł meblowy musi być zdefiniowany znacznie precyzyjniej niż „nazwa + cena + opis”. Z perspektywy modeli rekomendacyjnych przyda się ustrukturyzowany opis, zawierający co najmniej:

• Wymiary – szerokość, wysokość, głębokość, a przy bardziej zaawansowanych systemach także pozycje otworów montażowych, wysokość cokołu, wysokość wieńca.
• Typ połączenia – rodzaj złączy bocznych, górnych, dolnych, czy moduł może łączyć się „na styk”, czy wymaga elementu pośredniego.
• Kierunek i typ otwierania – lewe/prawe, uchylne, przesuwne, podnoszone, bezuchwytowe (tip-on), wymagania co do luzów montażowych.
• Materiał i konstrukcja – płyta, MDF, metal, szkło, rodzaj krawędzi, grubość płyty – istotne zarówno dla kompatybilności okuć, jak i długoterminowo dla modeli predykcyjnych (np. wytrzymałość, zwroty).
• Seria i stylistyka – kolekcja, dekor, kolor frontu, typ ramki, styl (nowoczesny, klasyczny, loftowy).
• Ograniczenia kompatybilności – jawne reguły typu: „pasuje tylko do korpusów serii X”, „nie współpracuje z prowadnicami typu Y”, „wymaga cokołu min. 10 cm”.

Im więcej z tych atrybutów jest zapisanych w postaci pól strukturalnych, a nie zamkniętych w jednym opisie tekstowym, tym łatwiej zbudować sensowne embeddingi i logikę filtrującą. Tekst może być użyty pomocniczo, ale sam w sobie nie rozwiąże problemu kompatybilności technicznej.

Trzy poziomy reprezentacji: moduł, konfiguracja, kontekst

Przy meblach modułowych z reguły potrzebne są co najmniej trzy powiązane poziomy danych:

1. Poziom modułu – pojedyncza szafka, front, blat, panel boczny. To podstawowa jednostka katalogu produktowego.
2. Poziom konfiguracji – konkretny układ modułów tworzących komplet: kuchnię, szafę, zabudowę salonu. Może być reprezentowany jako lista modułów z metadanymi (np. pozycja na ścianie, wysokość montażu).
3. Poziom kontekstu – informacje o pomieszczeniu i preferencjach: wymiary pokoju, wysokość sufitu, układ okien, obecne AGD, budżet, preferowany styl, ewentualne ograniczenia (np. rury, grzejniki).

Dane na poziomie modułu są kluczowe do filtracji kompatybilności. Dane na poziomie konfiguracji pozwalają uczyć modele sekwencyjne: jaki moduł typowo pojawia się po jakim w danej serii i typie zabudowy. Dane kontekstowe umożliwiają lepsze dopasowanie stylistyczne i budżetowe – oraz wykluczenie propozycji, które są formalnie poprawne, ale nie mieszczą się w przestrzeni fizycznej lub finansowej klienta.

Jawne relacje kompatybilności i zakazów

Same atrybuty nie wystarczą. W praktyce trzeba wprowadzić jawne relacje pomiędzy modułami, często ręcznie zdefiniowane przez technologów lub konstruktorów:

• „Może się łączyć z…” – lista typów modułów, które mogą sąsiadować z danym elementem z lewej/prawej/góry/dołu.
• „Nie może być skrajny” – flaga, że dany moduł (np. szafka bez bocznej ścianki, element narożny wewnętrzny) nie może znajdować się na krańcu zabudowy.
• „Tylko w środku układu” – moduły, które wymagają sąsiadów po obu stronach (np. segment otwarty bez boków, które pełnią funkcję dekoracyjną).
• „Wymaga elementu towarzyszącego” – np. front pod AGD, który bez korpusu do zabudowy nie ma sensu.
• „Wyklucza się z…” – np. konkretne typy zawiasów i prowadnic, fronty z pochwytem krawędziowym kolidujące z sąsiednimi modułami.

Takie relacje da się przechowywać jako macierze kompatybilności, graf połączeń lub prosty system reguł. Ważne, aby były maszynowo czytelne i możliwe do zastosowania jako filtr przed rankingiem ML.

Skutki złego modelowania schematu danych

Przy ubogim lub niekonsekwentnym schemacie danych pojawiają się powtarzalne problemy, które trudno potem „naprawić” samym modelem:

• Brak walidacji konfiguracji – system nie ma informacji, że szafka 70 cm powinna sąsiadować z określonymi modułami, więc dopuszcza dowolne zestawienia.
• Trudność w nauce embeddingów – embedding modułów oparty tylko na nazwie produktu i kilku ogólnych cechach nie odróżni szafki wiszącej od stojącej, ani korpusu od frontu.
• Wzmacnianie absurdów – jeśli dane źródłowe są nieprecyzyjne, model będzie sobie dorabiał korelacje z przypadkowych współwystąpień, uznając je za reguły.
• Brak możliwości wprowadzania twardych constraints – brak jawnych atrybutów kompatybilności uniemożliwia zbudowanie prostego filtra regułowego, przez co cała logika spada na barki modelu ML.

Przy słabym modelowaniu danych im „mądrzejszy” algorytm, tym więcej statystycznie poprawnych, ale praktycznie bezsensownych rekomendacji. To klasyczna sytuacja, w której AI elegancko formalizuje błędy ukryte w danych.

Przykład: liniowa zabudowa kuchenna z narożnikiem i słupkiem wysokim

Prosty przykład pokazuje, jak szczegółowo powinny być opisane elementy. Załóżmy ścianę o długości 3,6 m, z planowanej strony lewej znajduje się narożnik wewnętrzny, a z prawej słupek do zabudowy piekarnika.

Potrzebne moduły mogą wyglądać tak:

• Szafka narożna dolna 90×90 – wymiar po blacie, rzeczywisty rozstaw ścian inny, typ narożnika „L”, wymaga z lewej lub prawej kontynuacji zabudowy, nie może być elementem końcowym.
• Szafka stojąca 60 z szufladami – moduł liniowy, może być na skraju z jednej strony, ma określoną wysokość cokołu i głębokość dopasowaną do blatu.
• Słupek wysoki 60 pod piekarnik – wysokość do sufitu lub standardowa, inny system zawiasów, inna głębokość, inne okucia niż w dolnych szafkach.
• Blat 240 cm – wymaga podporu co określony odcinek, nie może „lewitować”, musi być powiązany z układem dolnych szafek.

Jeśli schemat danych nie rozróżnia tych ról (narożny vs liniowy vs wysoki), model rekomendacyjny potraktuje je jako „szafki kuchenne” i może podpowiedzieć słupek jako bezpośrednią kontynuację szafki narożnej w miejscu, gdzie powinna znaleźć się liniowa szafka stojąca. Dla algorytmu to po prostu element popularny w tej samej serii, dla montażysty – błąd uniemożliwiający realizację projektu.

Źródła danych do rekomendacji i typowe zanieczyszczenia

Jakie dane faktycznie istnieją w e‑commerce z meblami modułowymi

W praktyce rzadko ma się „idealne” dane. W typowym systemie do dyspozycji są:

• Logi kliknięć – co użytkownik oglądał, jakie moduły otwierał z listy, jak długo był na stronie produktu.

Trudności z logami kliknięć i ich interpretacją

Surowe logi kliknięć są kuszące, bo często są jedynym dużym zbiorem danych behawioralnych. Problem w tym, że w meblach modułowych są one szczególnie mylące. Kliknięcie w moduł nie oznacza jeszcze, że ten moduł jest częścią finalnej konfiguracji albo że klient go w ogóle rozważał poważnie.

Typowe zniekształcenia w logach kliknięć:

• Przypadkowe eksplorowanie – klient przegląda całą serię, bo chce zrozumieć logikę producenta, a nie dlatego, że realnie rozważa każdy element.
• Przewijanie „po listingach” – automatyczne ładowanie kolejnych stron, scroll bez faktycznego zainteresowania produktami.
• Ruch wygenerowany przez kampanie – baner kieruje na konkretny moduł, który musi dostać dużo wejść, bo tak ustawiono reklamę, nie dlatego, że dobrze pasuje do innych.
• Testy wewnętrzne i ruch robotów – zespoły projektowe, QA, integracje zewnętrzne, skrypty monitorujące – często mieszają się z ruchem użytkowników końcowych.

Bez filtrów jakości ruchu i oznaczania sesji „niefaktycznych” (wewnętrznych, testowych, z botów) logi kliknięć wprowadzą do modelu mnóstwo korelacji, które nie mają nic wspólnego z realnymi konfiguracjami.

Dane z konfiguratorów i projektantów – złoto z domieszką błota

Jeżeli istnieje jakikolwiek konfigurator kuchni, szaf czy zestawów salonowych, to z perspektywy modeli rekomendacyjnych jest to najcenniejsze źródło danych. W takich sesjach użytkownik (lub projektant) tworzy pełną konfigurację, a nie tylko ogląda pojedyncze moduły. Niestety i tu nie brakuje pułapek.

• Projekty „na próbę” – mnogość konfiguracji porzuconych po kilku minutach, w których użytkownik wrzuca „cokolwiek”, żeby zrozumieć działanie konfiguratora.
• Projekty wewnętrzne salonów – pracownicy testują nowe kolekcje, robią niestandardowe konfiguracje „pod wystawę”, które nigdy nie trafią do masowego klienta.
• Błędy w danych przestrzennych – źle wpisane wymiary pomieszczeń, brak oznaczenia baterii, okna, drzwi – model uczy się wzorców, które w prawdziwych mieszkaniach są nierealne.
• Auto‑uzupełnianie przez konfigurator – „inteligentny” konfigurator, który sam dodaje brakujące cokoły, maskownice, panele. Jeśli te elementy nie są odpowiednio oznaczone, model uzna je za aktywne wybory użytkownika.

Zanim dane z konfiguratorów trafią do trenowania modeli rekomendacyjnych, potrzebne jest ich oznaczenie: które moduły zostały wybrane ręcznie, które dodał system, a które służą tylko do obejścia ograniczeń narzędzia (np. „moduł techniczny” użyty tymczasowo).

Historie zamówień i zwroty – gdzie kończy się intencja klienta

Historia zamówień wydaje się twardym dowodem „co z czym się sprzedaje”. W meblach modułowych trzeba jednak rozdzielić trzy warstwy:

1. Poziom zamówienia – pełen koszyk, często wiele pomieszczeń naraz.
2. Poziom projektu – konkretna kuchnia, konkretna szafa; zamówienie może zawierać kilka niezależnych projektów.
3. Poziom korekt – zamienniki modułów, usunięte elementy, korekty po pomiarze.

Modele oparte wyłącznie na współwystępowaniu w koszykach szybko „nauczą się”, że front łazienkowy często współwystępuje z szafką kuchenną, bo w jednym zamówieniu klient robi kilka pomieszczeń. Dla finalnego systemu rekomendacyjnego to bezużyteczna korelacja.

Dodatkowo dochodzą zwroty i reklamacje. Jeśli moduł często jest zamieniany (np. z powodu kolizji z oknem lub błędu projektanta), to surowe dane sprzedażowe będą promować pierwotny moduł, który w praktyce nie działa. Bez połączenia danych sprzedażowych z informacjami posprzedażowymi model będzie wzmacniał błędne wybory.

Dane katalogowe i dokumentacja techniczna – dlaczego są tak chaotyczne

Opis katalogowy, karty produktów, pliki CAD, PDF‑y montażowe – to zwykle jedyne miejsce, gdzie istnieje „prawda techniczna” o module. Niestety w wielu firmach taka dokumentacja:

• powstaje w różnych działach i systemach,
• ma niespójne nazewnictwo (inne kody w systemie ERP, inne w katalogu, inne w plikach CAD),
• jest niepełna dla starszych kolekcji,
• nie nadąża za zmianami komponentów (np. wymianą prowadnic na nowy typ).

Z punktu widzenia modeli rekomendacyjnych problem zaczyna się, gdy część atrybutów jest wiarygodna (np. wymiary), a część kompletnie nie (np. pola kompatybilności). Model, który traktuje wszystkie kolumny jednakowo, będzie łączył twarde fakty z przypadkowymi opisami marketingowymi.

Jak wstępnie czyścić i ważyć źródła danych

Zanim powstanie choćby najprostszy model, źródła danych warto podzielić nie tylko według typu, ale też wiarygodności. Praktyczne podejście:

• Kategoryzacja sesji – osobno ruch klientów indywidualnych, salonów, kont B2B, ruch wewnętrzny; to różne światy, często z odmienną logiką konfiguracji.
• Filtry zdrowego rozsądku – odrzucanie konfiguracji, które naruszają podstawowe zasady: blat bez żadnej szafki pod spodem, szafka 80 cm wciśnięta w lukę 70 cm itd.
• Wagi źródeł – konfiguracje powstałe z udziałem doświadczonego projektanta mogą mieć inną wagę niż szybkie projekty zrobione samodzielnie online.
• Oznaczanie auto‑uzupełnień – pola binarne „dodane automatycznie przez konfigurator”, „dodane przez handlowca”, „wybrane przez klienta” – to później przydaje się w modelach.

W praktyce oznacza to, że zanim powstanie pierwsza macierz współwystępowania, trzeba zdecydować, które dane są „szumem”, a które reprezentują docelowe zachowania, które chcemy wzmacniać.

Modele rekomendacyjne, które prawie na pewno zawiodą w meblach modułowych

Proste „często kupowane razem” bez rozumienia projektu

Klasyczny widget „często kupowane razem” działa w modelu koszykowym: bierze produkty z jednego zamówienia i liczy współwystąpienia. W meblach modułowych prowadzi to do kilku typowych absurdów:

• Mieszanie pomieszczeń – w jednym zamówieniu kuchnia, szafa i łazienka, a model sugeruje fronty łazienkowe jako uzupełnienie zabudowy kuchennej.
• Brak rozróżnienia roli modułów – blat i cokół traktowane na równi z szafkami; model proponuje dodatkowy blat tam, gdzie potrzeba szafki liniowej.
• Wzmacnianie błędnych konfiguracji – jeśli przez rok sprzedało się wiele „quasi‑poprawnych” konfiguracji, prosty algorytm uzna je za „standard”.

Bez rozbijania zamówień na spójne konfiguracje i bez kontroli kontekstu pomieszczenia, taki widget jest bardziej systemem powielania dawnych błędów niż narzędziem projektowym.

Rekomendacje oparte wyłącznie na podobieństwie treści

Modele content‑based oparte na embeddingach opisów produktów i zdjęć potrafią znaleźć „podobne wizualnie” moduły. Dla mebli modułowych to za mało. Przykładowo:

• dwa fronty mogą wyglądać podobnie, ale mieć inne okucia i wymiary techniczne,
• szafka wisząca i stojąca mają tę samą estetykę, ale nie mogą zastąpić się wzajemnie w projekcie.

Jeśli model opiera się wyłącznie na tekście i obrazie, będzie proponował „ładnie pasujące” elementy, które montażowo kompletnie się nie bronią. Treść jest przydatna, ale wyłącznie jako warstwa pomocnicza nad twardymi atrybutami technicznymi.

„Klienci podobni do ciebie kupili…” przy skomplikowanych projektach

Modele typu user‑based collaborative filtering działają, gdy:

1. użytkownicy mają stabilne preferencje,
2. produkty mają prostą strukturę (np. książki, ubrania).

Przy meblach modułowych użytkownik w krótkim czasie tworzy jeden, góra dwa duże projekty, czasem zupełnie różne (np. pierwsze mieszkanie vs. kolejny dom). „Podobni użytkownicy” to zwykle osoby na podobnym etapie życiowym, ale z zupełnie inną architekturą mieszkań, inną lokalną ofertą i ograniczeniami (instalacje, wnęki itd.).

Dane o użytkowniku rzadko są bogate i stabilne. Zwykle jest to kilka sesji w krótkim okresie, potem długo nic. Algorytmy budujące podobieństwo użytkowników na takim fundamencie produkują bardziej szum niż użyteczny sygnał.

Modele sekwencyjne ignorujące geometrię

Recurrent neural networks, modele sekwencyjne czy architektury typu Transformer kuszą wizją, że „nauczą się kolejności modułów” w układzie. Problem w tym, że same identyfikatory produktów nie niosą informacji o geometrii ani położeniu. Bez:

• wymiarów pomieszczenia,
• pozycji modułu na ścianie,
• informacji o stronach (lewa/prawa),
• relacji sąsiedztwa,

taka sekwencja jest jedynie lista kliknięć, a nie opis realnego układu na ścianie. Model może „nauczyć się”, że po szafce narożnej często pojawia się słupek, bo wiele osób najpierw obejrzy narożnik, a potem „wysoką zabudowę” – to jednak nie oznacza, że te elementy powinny być obok siebie.

Projektowanie twardych ograniczeń – filtr regułowy przed AI

Dlaczego reguły muszą wyprzedzać model ML

W meblach modułowych istnieje duża grupa ograniczeń, które są zero‑jedynkowe:

• moduł fizycznie nie mieści się w danej wnęce,
• nie można zestawić dwóch typów zawiasów,
• określony element nie może być skrajny,
• moduł wymaga obecności innego modułu.

Uczenie modelu ML, że „zwykle tak się nie robi”, jest nieefektywne, jeśli realnie chodzi o twarde zakazy, nie o preferencje. Dużo bezpieczni