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 bezpieczniej jest potraktować model jako ranker w przestrzeni rozwiązań, które są z definicji poprawne technicznie. Oznacza to architekturę, w której:

1. reguły filtrują niepoprawne lub nierealne konfiguracje,
2. model wybiera i sortuje warianty spośród poprawnych.

Rodzaje twardych constraints w meblach modułowych

W praktycznych implementacjach spotyka się kilka grup ograniczeń, które dobrze dają się opisać regułowo:

• Geometryczne – suma szerokości modułów nie może przekroczyć wymiaru ściany; wysokość zabudowy nie może zejść poniżej linii okna; minimalne odległości od sprzętów (np. odległość płyty od lodówki).
• Konstrukcyjne – dopuszczalne obciążenie blatu, wymagana liczba podpór, konieczność zastosowania modułów technicznych przy długich przęsłach.
• Kompatybilności systemowej – seria okuć, typ systemu szuflad, rodzaj cokołu; mieszanie różnych systemów w jednym ciągu często jest zabronione lub ekonomicznie bez sensu.
• Topologiczne – kolejność elementów: zlew nie powinien znaleźć się za daleko od zmywarki, płyta nie powinna być w samym rogu, słupek lodówki nie powinien blokować okna.

Część tych reguł da się wyrazić prostymi nierównościami, część wymaga bardziej złożonej reprezentacji, np. w postaci grafu połączeń z typami krawędzi (sąsiedztwo, nad/pod, przeciwległa ściana).

Jak reprezentować reguły, żeby dało się je utrzymać

Reguły projektowe mają tendencję do rozrastania się w niekontrolowany sposób. Nowy system zawiasów, nowa głębokość korpusów, kolejna seria frontów – i po kilku latach nikt nie wie, co z czym się jeszcze zgadza. Proste spisy w Excelu przestają wystarczać. Praktyczne podejścia:

• Graf kompatybilności – węzły to typy modułów, krawędzie opisują dopuszczalne połączenia (z typem relacji: lewa/prawa/góra/dół). Na tym grafie można później robić proste algorytmy wyszukiwania ścieżek.
• Silnik regułowy – proste DSL (domain‑specific language) czy nawet tabele warunków typu „IF seria=A AND typ=zawiasu=X THEN not_compatible_with=Y”.
• Walidatory konfiguracji – funkcje, które przyjmują całą konfigurację i zwracają listę naruszeń; używane zarówno przy projektowaniu, jak i przy trenowaniu modeli (odrzucanie złych przykładów).

Łączenie reguł z modelem – architektura „candidate generation + ranking”

Użyteczny schemat to rozdzielenie etapu tworzenia kandydatów od etapu oceny kandydatów. W meblach modułowych ma to szczególnie duże znaczenie, bo liczba teoretycznych kombinacji jest gigantyczna, a większość z nich jest nielegalna technicznie lub kompletnie bez sensu użytkowego.

Praktyczny przepływ wygląda zazwyczaj tak:

1. Silnik regułowy generuje kandydatów – np. wszystkie układy dolnych szafek, które mieszczą się w ścianie 320 cm, spełniają minimalne szerokości przy sprzętach i mają prawidłowe podparcie blatu.
2. Walidator odrzuca „skrajnie złe” opcje – np. układy, gdzie zlewozmywak znalazł się 30 cm od krawędzi ściany albo zmywarka stoi w rogu i nie ma jak jej otworzyć.
3. Model ML rankuje poprawne warianty – wykorzystując dane sprzedażowe, statystyki użycia konfiguratora, a czasem preferencje estetyczne użytkownika.

Reguły odpowiadają więc za przestrzeń dopuszczalnych rozwiązań, a model za priorytetyzację. Próba odwrócenia tej odpowiedzialności kończy się zwykle tym, że trzeba „uciąć ogon” rekomendacji dodatkowymi filtrami i ręcznymi poprawkami.

Dobrze jest też zdefiniować osobne progi dla różnych kanałów:

• dla klienta końcowego – pokazywać tylko kilka najlepszych, „bezpiecznych” propozycji,
• dla handlowca/projektanta – szerszy zestaw kandydatów, w tym „ambitniejsze” układy, ale z wyraźnym oznaczeniem ich statusu (np. „wymaga weryfikacji montażowej”).

Priorytety w regułach: kiedy twarde, kiedy miękkie

Nie wszystkie ograniczenia mają ten sam status. Jeśli wszystko wrzuci się do jednego worka „zakazane”, to:

• część realnych, choć nietypowych rozwiązań stanie się niemożliwa,
• projektanci zaczną omijać system, bo „nie da się zrobić normalnej kuchni”.

Przydatne jest rozróżnienie:

• hard constraints – naruszenie grozi reklamacją, uszkodzeniem produktu albo jest sprzeczne z instrukcją producenta; system nie powinien nigdy ich łamać,
• soft constraints – dobre praktyki, ergonomia, zasady „tak zazwyczaj robimy”; mogą zostać naruszone, ale świadomie i z wyraźnym sygnałem.

Takie podejście pozwala np. na:

• oznaczenie konfiguracji jako „nietypowa – wymagana zgoda działu technicznego”,
• pozostawienie marginesu twórczości projektanta przy jednoczesnym zabezpieczeniu końcowego klienta przed błędami konstrukcyjnymi.

Wybór i projektowanie modeli – od prostych algorytmów po hybrydy

Osobno: rekomendacje modułów, osobno: rekomendacje konfiguracji

Pierwsze nieporozumienie pojawia się już na etapie definicji problemu. Co właściwie ma rekomendować system:

• pojedyncze moduły (kolejna szafka obok istniejącego układu),
• całe układy (gotowe konfiguracje ścian, wysp, garderób),
• czy może warianty modyfikacji istniejącego projektu (zamiana frontów, podmiana systemu szuflad)?

To trzy różne zadania, często wymagające trzech różnych modeli. Próba zrobienia jednego „modelu do wszystkiego” zwykle kończy się tym, że jest on średni we wszystkich zastosowaniach. Rozsądniejsze jest potraktowanie:

• rekomendacji modułów jako problemu uzupełniania sekwencji w silnym kontekście regułowym,
• rekomendacji konfiguracji jako problemu wyszukiwania podobnych projektów z bazy istniejących realizacji,
• rekomendacji modyfikacji jako problemu substitution recommendation (co można bezpiecznie podmienić przy zachowaniu funkcji i wyglądu).

Proste hybrydy: współwystępowanie + reguły + content

Nie trzeba od razu sięgać po skomplikowane sieci neuronowe. Często wystarczy rozsądnie sklejony model hybrydowy, który:

1. używa macierzy współwystępowania na poziomie typów modułów (nie SKU),
2. ogranicza kandydatów regułami kompatybilności,
3. dogrywa kolejność na podstawie podobieństwa estetycznego i ceny.

Przykładowo: użytkownik ustawił już ciąg dolnych szafek i szuka zabudowy górnej. System:

• wybiera typy szafek górnych, które statystycznie najczęściej współwystępują z danym typem zabudowy dolnej,
• filtruje je po wymiarach i systemie okuć, tak aby realnie dało się je powiesić nad istniejącym układem,
• w obrębie poprawnych kandydatów sortuje po dopasowaniu wizualnym do frontów dolnych i budżetu użytkownika.

Takie podejście jest z natury „nudne”, ale za to przewidywalne i w dużej mierze odporne na absurdalne podpowiedzi.

Modele grafowe: GNN i message passing na konfiguracjach

Jeśli dane są dobrze przygotowane – mamy topologię konfiguracji, relacje sąsiedztwa, typy połączeń – warto rozważyć modele grafowe (Graph Neural Networks). Działają one nie na płaskiej liście produktów, lecz na grafie:

• węzły – moduły, ściany, sprzęty,
• krawędzie – relacje „obok”, „nad/pod”, „połączone blatem”, „po przeciwnej stronie”.

Taki model jest w stanie propagować informacje: np. węzeł „płyta grzewcza” informuje o wymaganych odległościach i typie sąsiadów, a węzeł „słupek lodówki” – o ograniczeniach otwierania drzwi. W prostszym wariancie:

• GNN służy do embeddowania całej konfiguracji w wektor,
• a rekomendacje polegają na wyszukiwaniu „podobnych projektów” w tej przestrzeni wektorowej.

To nadal nie rozwiązuje wszystkich problemów (np. rzadkie, nietypowe układy nadal będą słabo reprezentowane), ale pozwala lepiej wyłapać strukturalne zależności niż zwykły collaborative filtering.

Modele sekwencyjne z geometrią jako dodatkowymi cechami

Jeśli jednak z jakiegoś powodu trzeba pracować na sekwencjach (np. obecny konfigurator rejestruje liniowy ciąg modułów na ścianie), minimalne wymaganie to wzbogacenie identyfikatorów produktów o:

• wymiary (szerokość, wysokość, głębokość),
• położenie (np. odległość od lewej krawędzi ściany),
• kontekst ściany (długość, pozycje okien, gniazdek),
• role (szafka zlewozmywakowa, narożna, przelotowa itd.).

Transformery czy inne modele sekwencyjne mogą wtedy uczyć się wzorców typu:

• „po wstawieniu szafki zlewozmywakowej często pojawia się zmywarka po tej samej stronie, ale niekoniecznie bezpośrednio obok”,
• „nad określoną długością blatu rzadko pozostawia się ścianę pustą – zwykle pojawiają się szafki wiszące lub półki”.

Nadal nie zastępuje to twardych reguł. Może jednak sensownie uzupełniać rekomendacje o układy, które są poprawne, ale statystycznie mniej typowe (np. inne rozłożenie słupków czy szafek cargo).

Learning-to-rank zamiast klasycznej predykcji „kto co kupi”

Modele rekomendacyjne w e‑commerce często przewidują prawdopodobieństwo zakupu produktu. W meblach modułowych bardziej adekwatne jest uczenie modeli typu learning-to-rank:

• na wejściu: konfiguracja + zbiór dopuszczalnych kandydatów,
• na wyjściu: ranking kandydatów, uporządkowany według „użyteczności” w danym projekcie.

Dane treningowe nie muszą być ograniczone do realnych zakupów. Można użyć:

• zatwierdzonych projektów z salonów (projekty zakończone sprzedażą),
• informacji, które warianty projektant wybierał, a które odrzucał przy pracy z klientem,
• ocen techników/serwisu (np. które projekty wymagały korekt).

Tak zbudowany model uczy się nie tyle „co jest popularne ogólnie”, ile „co zostało wybrane w konkretnym kontekście i nie doprowadziło do problemu montażowego”. To subtelna, ale istotna różnica.

Personalizacja estetyczna: gdzie AI ma pole do popisu

Tam, gdzie kończy się twarda geometria i konstrukcja, zaczyna się pole dla bardziej „miękkiej” AI. Typowe obszary:

• dobór frontów i kolorów do istniejącej bazy – model może wykrywać style (nowoczesny, klasyczny, loftowy) i proponować spójne zestawy,
• dobór uchwytów i detali – przy tej samej konstrukcji szafek można proponować kilka wariantów „charakteru” zabudowy,
• dopasowanie do reszty mieszkania – jeśli użytkownik udostępnia zdjęcia salonu czy podłogi, modele wizualne mogą ograniczyć gamę kolorystyczną, zamiast serwować pełen katalog.

Nawet tu jednak dobrze jest wprowadzić ograniczenia: np. nie proponować frontów spoza wybranej kolekcji cenowej albo nie mieszać zbyt wielu dekori w jednym ciągu bez wyraźnej zgody użytkownika. Algorytmy potrafią generować zaskakująco „odważne” zestawienia, które handlowiec nazwałby po prostu „nie do sprzedania”.

Modele do wykrywania błędnych i „szalonych” propozycji

Ironią jest to, że samo AI może pomóc w kontrolowaniu innych modeli AI. W praktyce da się zbudować:

• model klasyfikujący „podejrzane konfiguracje” – uczony na przykładach projektów, które wróciły jako reklamacje lub wymagały korekt technicznych,
• model anomalii – wykrywający układy znacząco odbiegające od tego, co było historycznie realizowane w danym segmencie (np. mieszkanie w bloku vs. dom jednorodzinny).

Takie modele mogą działać jako dodatkowa warstwa kontroli nad rekomendacjami:

• oznaczając konfiguracje do ręcznej weryfikacji,
• obniżając ranking rozwiązań z wysokim „ryzykiem technicznym”,
• a czasem w ogóle blokując ich prezentację w kanale self‑service.

Nie zastępuje to walidatorów regułowych, ale tworzy „poduszkę bezpieczeństwa” tam, gdzie reguły nie nadążają za kreatywnością użytkowników i modeli.

Iteracyjne doskonalenie: pętle feedbacku zamiast jednorazowego wdrożenia

Modele rekomendacyjne w meblach modułowych rzadko działają poprawnie „od strzału”. Typowy cykl obejmuje:

1. start z konserwatywnym zakresem – rekomendacje ograniczone do dobrze przetestowanych przypadków,
2. monitoring absurdów – logowanie i tagowanie sytuacji, w których handlowiec lub użytkownik odrzuca propozycje jako „bez sensu”,
3. analizę przyczyn – czy zawiodły reguły, czy model, czy dane wejściowe,
4. aktualizację reguł i cech – dopisywanie brakujących constraints, poprawianie atrybutów, czasem usuwanie „zatrutych” danych treningowych,
5. ponowne trenowanie i walidację na podstawie nowych logów.

Z perspektywy praktyka kluczowe jest, aby ten proces był lekki organizacyjnie. Jeśli każda zmiana wymaga trzech komitetów i pół roku, system szybko stanie się reliktem – projektanci wrócą do Excela, a klienci do kartki i ołówka.

Najczęściej zadawane pytania (FAQ)

Dlaczego klasyczne systemy rekomendacyjne źle działają dla mebli modułowych?

Klasyczne algorytmy „kupiono razem” zakładają, że produkty są w miarę niezależne i da się je dowolnie łączyć. W meblach modułowych jest odwrotnie: elementy mają silne ograniczenia techniczne (wymiary, sposób łączenia, kierunek otwierania), więc wiele kombinacji jest po prostu fizycznie niemożliwych lub absurdalnych z punktu widzenia montażu.

Zwykłe filtrowanie kolaboratywne uczy się jedynie współwystępowania w zamówieniach. Jeśli front do wysokiej szafy często występuje razem z szafką narożną, model zaczyna traktować to jako „dobre połączenie”, mimo że te elementy nie są względem siebie w żaden sposób kompatybilne. Efekt: rekomendacje, które wyglądają „statystycznie sensownie”, ale kompletnie nie pasują do konkretnej konfiguracji użytkownika.

Jakie są najczęstsze „absurdalne” rekomendacje przy meblach modułowych?

Najbardziej typowe błędy to rekomendowanie elementów, które nie pasują wymiarami, systemem, kierunkiem otwierania lub stylistyką. Algorytm koncentruje się na tym, co często kupowano razem, zamiast na tym, co można ze sobą poprawnie zmontować.

W praktyce często widać m.in.:

• szafki 60 cm proponowane do wolnej przestrzeni 45 cm,
• fronty w innym dekorze lub serii niż reszta zabudowy, bo „kiedyś były w bundlu promocji”,
• fronty pod inny system zawiasów niż wybrany korpus,
• drzwi lewe sugerowane tam, gdzie fizycznie da się zamontować tylko prawe,
• mieszanie korpusów o różnych głębokościach w jednej linii, tworzące wizualne „schody”.

Te błędy nie wynikają z „głupoty” modelu, tylko z braku jawnie zakodowanej logiki kompatybilności.

Jak modelować dane o meblach modułowych, żeby rekomendacje miały sens?

Podstawą jest porzucenie podejścia „nazwa + opis + cena” na rzecz bogatego, ustrukturyzowanego opisu modułu. Każdy element powinien mieć jawne pola dla wymiarów, typu połączeń, kierunku otwierania, materiału, serii, a przede wszystkim twardych ograniczeń kompatybilności (np. „działa tylko z prowadnicami typu X”).

Dobrą praktyką jest rozdzielenie trzech poziomów reprezentacji:

• moduł – pojedyncza szafka, front, blat z kompletem atrybutów technicznych,
• konfiguracja – konkretna zabudowa jako lista modułów z pozycją, wysokością, itp.,
• kontekst – parametry pomieszczenia i preferencje klienta (wymiary, styl, budżet).

Modele rekomendacyjne mogą wtedy korzystać z filtrów „twardych” (co jest w ogóle możliwe montażowo), a dopiero w drugim kroku z uczenia maszynowego do wyboru najlepszego z dopuszczalnych wariantów.

Jak decyzje biznesowe (promocje, zestawy) psują dane do rekomendacji?

Promocje, sztuczne zestawy i wyprzedaże wprowadzają w danych silne, ale mylące korelacje. System widzi, że pewne elementy często kupowano razem, choć prawdziwą przyczyną był rabat lub konieczność „dobicia” zamówienia magazynowymi resztkami, a nie realne dopasowanie modułów.

Typowe pułapki to:

• pakiety „startowe” z losowo dobranymi szafkami projektowanymi pod rabat, nie pod ergonomię,
• chwilowe promocje na konkretny kolor lub szerokość, które przesterowują model w stronę tych opcji,
• mieszanie starych i nowych systemów w jednym zamówieniu przy wyprzedaży końcówek serii.

Jeśli takie przypadki nie zostaną oznaczone lub przefiltrowane, model będzie powielał decyzje marketingu jako „wiedzę o kompatybilności”, co prowadzi do kuriozalnych sugestii.

Czym różni się rekomendacja „kolejnego modułu” od zwykłego „kupiono razem”?

W klasycznym e‑commerce system proponuje najczęściej niezależne produkty, które po prostu „lubią się” ze sobą w koszykach. W meblach modułowych model ma inne zadanie: zasugerować kolejny krok w budowie konfiguracji, biorąc pod uwagę to, co już użytkownik ułożył i jakie ma jeszcze ograniczenia przestrzenne.

Technicznie to problem sekwencyjny z silnymi constraintami. Każdy nowy moduł zmienia dostępne opcje (pozostałą szerokość ściany, możliwe wysokości, miejsce na AGD). Jeśli model nie pracuje na poziomie „konfiguracja + kontekst”, a tylko „moduł + historia zakupów innych klientów”, skończy się na podpowiadaniu elementów, które co prawda „często pojawiały się obok”, ale w aktualnym układzie są nie do użycia.

Czy wystarczy użyć dużego modelu językowego, żeby uniknąć absurdalnych rekomendacji?

LLM może pomóc interpretować opisy produktów czy wspierać interfejs rozmowy z klientem, ale sam nie rozwiąże problemu twardej kompatybilności. Opisy tekstowe rzadko zawierają wszystkie niezbędne szczegóły techniczne w sposób jednoznaczny, a nawet jeśli – model językowy nie ma gwarancji, że będzie je stosował konsekwentnie.

Bez dobrego modelu danych (atrybuty techniczne jako struktura, nie tylko tekst) i warstwy reguł logicznych LLM będzie generował elegancko brzmiące, lecz potencjalnie błędne zestawienia. Sensowne podejście to połączenie: twarde reguły i filtry wykluczające niemożliwe konfiguracje, a dopiero wewnątrz tej „bezpiecznej przestrzeni” zastosowanie ML/LLM do rankingowania i dopasowania stylistycznego.

Jak ocenić, czy rekomendacje dla mebli modułowych są faktycznie „dobre”?

Same metryki typu CTR czy konwersja potrafią być mylące, bo promocje i bundle mogą sztucznie zawyżać wyniki. Potrzebne są dodatkowe miary jakości konstrukcyjnej: odsetek konfiguracji odrzuconych przez projektantów lub montażystów, liczba ręcznych korekt w koszyku, zgłoszenia klientów o „niepasujących elementach”.

W praktyce dobrze działa połączenie:

• automatycznych walidatorów konfiguracji (sprawdzenie wymiarów, kolizji, systemów okuć),
• przeglądu próbek rekomendacji przez ekspertów produktowych,
• monitoringu zwrotów i reklamacji powiązanych z błędnymi zestawami.

Dopiero takie spojrzenie pokazuje, czy model wspiera sensowne projekty, czy tylko wzmacnia przypadkowe korelacje z danych sprzedażowych.

Kluczowe Wnioski

• Meble modułowe to nie pojedyncze produkty, lecz złożone konfiguracje wielu elementów, więc model rekomendacyjny musi brać pod uwagę sekwencję budowy, kontekst przestrzenny i techniczne ograniczenia, a nie tylko listę kupionych SKU.
• Klasyczne podejście „kupiono razem” w modułach prowadzi do logicznych błędów konstrukcyjnych (np. front słupkowy do małej szafki stojącej), bo algorytm myli współwystępowanie w jednym zamówieniu z realną kompatybilnością elementów.
• Bez twardych reguł technicznych systemy rekomendacyjne systematycznie produkują absurdalne propozycje: niepasujące wymiary, kolizje kierunków otwierania, mieszanie głębokości korpusów czy niespójne wykończenia, co z punktu widzenia klienta wygląda jak „inteligentny chaos”.
• Dane sprzedażowe są zanieczyszczone decyzjami biznesowymi (promocje, sztuczne zestawy, wyprzedaże końcówek serii), więc bez ich świadomego odfiltrowania model będzie utrwalał przypadkowe kombinacje zamiast uczyć się poprawnych konfiguracji.
• Sklep zwykle nie widzi pełnej ścieżki konfiguracji, tylko finalne zestawy lub kilka zapisów po drodze; brak tej historii utrudnia uczenie modeli sekwencyjnych, które miałyby rozumieć, co „po czym” jest sensownie dokładane.
• Podstawą sensownych rekomendacji jest bogata, ustrukturyzowana reprezentacja modułów (wymiary, typ połączeń, system mocowań, kierunek otwierania itd.), bo uproszczone opisy typu „nazwa + cena” uniemożliwiają odróżnienie elementów formalnie podobnych, lecz technicznie niekompatybilnych.