Opisy produktów z AI dla 5000 SKU: proces bez duplikatów

Sklep z pięcioma tysiącami produktów nie ma wyboru: ręczne pisanie opisów zajęłoby zespołowi rok, a połowa tekstów zestarzałaby się przed końcem projektu. Generowanie opisów produktów masowo przez AI rozwiązuje problem czasu, ale tworzy nowy. Bez procesu dostajesz tysiące kart, które brzmią tak samo, różnią się tylko nazwą i kolorem, a Google traktuje je jako treść o niskiej wartości. Poniżej opisujemy układ, który sprawdza się przy katalogu tej wielkości: od danych wejściowych, przez kontrolę podobieństwa, po koszt i harmonogram.

Ogólne zasady automatyzacji opisaliśmy w tekście o workflow automatyzacji opisów ofert. Tutaj skupiamy się na tym, co zmienia się przy skali kilku tysięcy SKU, bo przy dwustu produktach większość problemów po prostu nie występuje.

Dane wejściowe, bez których nie ma sensu zaczynać

Model językowy nie wymyśli różnic, których nie ma w danych. Jeśli dwa produkty mają w feedzie te same cztery atrybuty, dostaniesz dwa prawie identyczne opisy, niezależnie od jakości promptu. Dlatego pierwszy tydzień projektu to zwykle porządki w danych, a nie generacja.

Minimalny zestaw na jedną kartę to:

• nazwa, marka, kategoria i podkategoria,
• co najmniej 6–8 atrybutów technicznych z jednostkami (wymiary, materiał, waga, moc, pojemność),
• przeznaczenie: dla kogo i do czego produkt służy,
• wyróżnik na tle sąsiadów w tej samej kategorii,
• zawartość zestawu i informacje o kompatybilności, jeśli dotyczą.

W praktyce warto zrobić audyt kompletności: policz, ile SKU ma pełny komplet pól. Przy typowym katalogu hurtowym wychodzi 30–50%. Produktów z trzema atrybutami nie generuj od razu; najpierw uzupełnij dane od dostawcy albo z kart producenta. Ten sam porządek przyda się zresztą w feedzie, o czym piszemy w przewodniku sklepy pod AI: feed, opisy, kategorie i schema produktu.

Szablon kontra swobodna generacja

Są dwie skrajności. Sztywny szablon („Produkt X marki Y wykonano z Z. Idealnie sprawdzi się…”) daje przewidywalność, ale też 5000 tekstów o identycznej składni. Swobodna generacja z krótkim promptem daje różnorodność, za to model zaczyna dopisywać cechy, których produkt nie ma, i trudno to kontrolować.

Najlepiej działa układ pośredni: stała struktura sekcji i zmienna treść w sekcjach. Prompt wymusza kolejność (akapit otwierający z zastosowaniem, tabela parametrów, „dla kogo i dla kogo nie”, zawartość zestawu), ale nie narzuca gotowych zdań. Do tego twarde ograniczenia: używaj wyłącznie atrybutów z danych, nie podawaj liczb spoza feedu, nie stosuj słów z listy zakazanej („idealny”, „najwyższej jakości”, „niezawodny”). Jak taki szkielet wygląda w szczegółach, opisaliśmy w tekście o strukturze opisów produktów pod AI.

Osobne szablony przygotuj dla każdej grupy kategorii. Opis wiertarki i opis sukienki potrzebują innych sekcji, a wspólny prompt dla całego sklepu to najczęstsza przyczyna płaskich tekstów.

Jak wymusić różnorodność między wariantami

Największe ryzyko duplikacji nie dotyczy całego katalogu, tylko rodzin produktów: ten sam model w ośmiu kolorach, ta sama kurtka w pięciu rozmiarach, kabel w czterech długościach. Tu masz trzy rozsądne opcje.

1. Jedna karta z wariantami. Jeśli warianty różnią się tylko kolorem lub rozmiarem, najczęściej nie potrzebują osobnych opisów ani osobnych adresów indeksowanych. To decyzja architektoniczna, nie kontentowa, i oszczędza setki generacji.
2. Opis bazowy plus akapit wariantu. Wspólny trzon dla rodziny i jeden unikalny akapit o tym, czym wariant się wyróżnia (dłuższy kabel do biura, ciemny kolor do warsztatu).
3. Rotacja kątów. Dla produktów naprawdę różnych, ale z tej samej podkategorii, przypisz każdemu SKU inny kąt otwarcia: zastosowanie, problem klienta, porównanie z poprzednią wersją, scenariusz użycia. Kąt losujesz w skrypcie i przekazujesz w prompcie.

Pomaga też podawanie modelowi w kontekście dwóch, trzech wcześniej wygenerowanych opisów z tej samej kategorii z instrukcją, żeby nie powtarzał ich otwarć ani konstrukcji zdań. To prosta technika, a wyraźnie obniża podobieństwo w obrębie partii.

Kontrola duplikatów przed publikacją

Kontroli nie da się zrobić „na oko” przy 5000 tekstach. Potrzebny jest automatyczny pomiar podobieństwa każdego opisu z każdym innym w tej samej kategorii. Dwie metody wystarczą:

Progi są orientacyjne i warto je skalibrować na pierwszej partii: weź 50 par oznaczonych ręcznie jako „za podobne” i „w porządku”, sprawdź, gdzie leży granica. Opisy, które przekroczą próg, wracają do generacji z innym kątem, a nie do ręcznej poprawki, bo ręczne poprawki przy tej skali zjadają cały zaoszczędzony czas.

Trzecia linia tabeli jest najważniejsza. Wymyślona pojemność baterii albo materiał, którego produkt nie ma, to reklamacja i zwrot, nie tylko problem SEO. Prosty skrypt wyciąga z opisu wszystkie liczby z jednostkami i porównuje je z atrybutami w feedzie.

Osobno sprawdź duplikację zewnętrzną. Jeśli w danych wejściowych przekazujesz modelowi opis producenta, część zdań potrafi przejść do wyniku niemal dosłownie, a ten sam tekst producenta ma już na stronach kilkudziesięciu innych sklepów. Najprostsza zasada: opis producenta służy wyłącznie jako źródło faktów, nigdy jako wzór stylu, a w kontroli porównujesz wynik także z tym opisem. Fragment dłuższy niż kilkanaście słów pokrywający się z oryginałem oznacza regenerację. W ten sposób unikasz sytuacji, w której po miesiącu pracy twoje karty wyglądają dla wyszukiwarki jak kolejna kopia tego samego katalogu dystrybutora.

Wsad ekspercki tam, gdzie się opłaca

Nie każde SKU zasługuje na tę samą pracę. W typowym sklepie 10–15% produktów generuje większość przychodu i ruchu organicznego. Dla tej grupy warto dodać do danych wejściowych wiedzę, której nie ma w feedzie: notatkę od działu obsługi klienta o częstych pytaniach, typowe błędy przy montażu, porównanie z produktem konkurencji z własnego asortymentu.

Takie opisy częściej trafiają też do odpowiedzi w wyszukiwarkach AI, bo zawierają konkretne fakty, których model nie znajdzie gdzie indziej. To samo dotyczy widoczności w zakupowych modułach Google, o czym więcej w tekście o Google Shopping i AI Overviews. Pozostałe 85% katalogu dostaje solidny, poprawny opis z danych, bez dodatkowej redakcji.

Publikacja partiami i pomiar

Wrzucenie 5000 nowych opisów jednego dnia to proszenie się o kłopoty. Google w zasadach dotyczących spamu wprost wymienia nadużycia związane ze skalowaną treścią, czyli masowe generowanie stron bez wartości dla użytkownika. Sam fakt użycia AI nie jest problemem (Google potwierdził to w swoich wytycznych), ale skok o kilka tysięcy zmienionych stron w jeden dzień utrudnia ocenę, co zadziałało.

Rozsądny rytm to partie po 200–500 SKU tygodniowo, zaczynając od jednej kategorii. Przed startem zapisz stan wyjściowy: wyświetlenia i kliknięcia z Search Console dla tej kategorii, konwersję kart, odsetek zwrotów z powodu „produkt niezgodny z opisem”. Po 3–4 tygodniach porównaj z kategorią kontrolną, której jeszcze nie ruszałeś. Dopiero wtedy skaluj na kolejne kategorie.

Koszty i czas dla 5000 SKU

Sama generacja jest dziś tania. Opis o długości 250–400 słów to kilkaset tokenów wyjścia i około tysiąca tokenów wejścia (dane plus instrukcje). Dla 5000 SKU, z jedną regeneracją dla co piątego opisu, koszt API przy modelach średniej klasy zamyka się zwykle w kwocie od kilkudziesięciu do kilkuset złotych. To nie pieniądze decydują o budżecie projektu.

Decyduje czas ludzi:

• porządki w danych: 40–80 godzin, zależnie od jakości feedu,
• przygotowanie szablonów dla grup kategorii i kalibracja progów: 20–30 godzin,
• wsad ekspercki dla 500–700 kluczowych SKU: 60–100 godzin,
• wyrywkowa kontrola jakości (około 5% opisów czytanych w całości): 15–25 godzin.

Razem to 135–235 godzin, czyli realnie 2–3 miesiące pracy przy publikacji partiami. Dla porównania ręczne napisanie 5000 opisów po 20 minut to ponad 1600 godzin. Oszczędność jest więc ogromna, pod warunkiem że czas zaoszczędzony na pisaniu zainwestujesz w dane i kontrolę, a nie w szybszą publikację.

Na koniec jedna uwaga praktyczna: zapisuj wersję szablonu i promptu przy każdym opisie (w polu meta albo w osobnej tabeli). Gdy za pół roku zmienisz podejście, będziesz wiedzieć, które karty wymagają regeneracji, zamiast zgadywać.

FAQ