70 000 opisów produktów w dwa tygodnie

Kiedy opowiadam o tym projekcie, ludzie zwykle chcą wiedzieć, jakiego modelu użyłem i jak wyglądał prompt. To są dwa najmniej interesujące pytania, jakie można tu zadać.

Wygenerowanie 70 000 opisów przez API było najprostszą częścią całej roboty i zajęło ułamek czasu. Cała trudność siedziała przed tym momentem i po nim: w danych wejściowych, w spójności między rynkami i w tym, jak sprawdzić jakość czegoś, czego fizycznie nie da się przeczytać.

To nie był projekt AI. To był projekt operacyjny, w którym AI było jednym z narzędzi.

Skąd się w ogóle bierze 70 000 opisów

Rzadko z jednego katalogu. Zwykle z mnożenia.

Kilka tysięcy indeksów razy kilka rynków językowych i jesteś w dziesiątkach tysięcy, zanim ktokolwiek pomyślał o wariantach. Dołóż do tego, że opis na własny sklep i opis na marketplace to nie ten sam tekst — mają inne wymogi formalne, inne limity znaków i inne zasady dotyczące tego, czego nie wolno napisać — i liczba mnoży się jeszcze raz.

W praktyce większość firm dochodzi do tego problemu nie przez wzrost asortymentu, tylko przez wejście na kolejne rynki. Katalog, który po polsku był do ogarnięcia, po piątym języku przestaje być.

Arytmetyka ręcznej roboty

Warto ją zrobić raz, bo rozstrzyga dyskusję szybciej niż jakikolwiek argument o technologii.

Copywriter piszący opisy produktowe z sensem — czyli patrzący na specyfikację, na konkurencję i na to, co faktycznie odróżnia produkt — robi ich realnie kilkanaście do trzydziestu dziennie. Przyjmijmy dwadzieścia pięć.

70 000 ÷ 25 = 2 800 osobodni. Przy standardowym roku pracy to ponad jedenaście lat pracy jednej osoby. Zespół dziesięciu copywriterów, gdyby nie robił nic innego, potrzebowałby ponad roku — i skończyłby w momencie, w którym pierwsza partia opisów byłaby już nieaktualna, bo asortyment się zmienił.

To nie jest sytuacja, w której AI jest tańsze. To sytuacja, w której alternatywa nie istnieje. I to jest jedyny sensowny powód, żeby brać się za taki projekt: nie „bo AI”, tylko „bo tej pracy nie da się wykonać inaczej”.

Co było naprawdę trudne

Dane wejściowe, których nikt nie pilnował

Model generuje opis na podstawie tego, co mu dasz. Jeśli w karcie produktu jeden dostawca wpisał materiał jako „bawełna 100%”, drugi jako „100% cotton”, a trzeci zostawił puste pole — dostaniesz trzy opisy o różnym poziomie szczegółowości i jeden, który zmyśli.

Największa część pracy w takim projekcie to nie generowanie, tylko doprowadzenie atrybutów do stanu, w którym da się na nich cokolwiek oprzeć. Normalizacja jednostek, uspójnienie słowników, wyłapanie pól, które w teorii istnieją, a w praktyce są puste w połowie katalogu.

To jest robota, którą trzeba zrobić tak czy inaczej — z AI czy bez. Projekt generowania opisów zwykle jest po prostu pierwszym momentem, w którym ten dług staje się widoczny.

Halucynacje przy brakujących danych

Model, który nie ma informacji o materiale, nie zostawi pustego miejsca. Napisze coś prawdopodobnego. Przy 70 000 opisów „coś prawdopodobnego” pojawi się kilkaset razy i część z tego trafi na kartę produktu jako fakt.

Rozwiązanie nie leży w lepszym prompcie, tylko w regule: jeżeli atrybut krytyczny jest pusty, produkt nie idzie do generowania. Wypada z partii i trafia na listę do uzupełnienia. Lepiej mieć 62 000 dobrych opisów i 8 000 zadań, niż 70 000 opisów, z których nie wiadomo, którym ufać.

Kontrola jakości, kiedy nie da się przeczytać

Nikt nie przeczyta 70 000 tekstów. Trzeba więc zbudować kontrolę, która działa bez czytania: automatyczne sprawdzenie długości, obecności wymaganych atrybutów, zakazanych sformułowań i podobieństwa między opisami. Do tego ręczna próbka — losowa, nie wybrana — czytana przez człowieka, na tyle duża, żeby wyłapać systematyczny błąd.

Systematyczny błąd jest tu groźniejszy niż pojedynczy. Jeśli model źle interpretuje jedno pole, zrobi to konsekwentnie w całej kategorii.

Duplikaty i cienka treść

Siedemdziesiąt tysięcy tekstów zbudowanych z tego samego szablonu na podobnych danych będzie do siebie podobnych. Dla wyszukiwarki to jest sygnał niskiej wartości, a przy dużym katalogu potrafi zaszkodzić bardziej, niż pomogły nowe opisy.

Kontrola podobieństwa między wygenerowanymi tekstami jest więc częścią procesu, nie dodatkiem po fakcie. W praktyce oznacza to wymuszenie zmienności struktury i pilnowanie, żeby to, co w opisie unikalne, faktycznie pochodziło z danych produktu, a nie z losowej wariacji językowej.

Różne rynki to nie to samo z tłumaczem

Opis przetłumaczony i opis napisany dla danego rynku to dwie różne rzeczy. Różnią się nie tylko językiem, ale też tym, co kupujący uznaje za istotne, jakie jednostki są naturalne i czego nie wolno obiecać ze względu na lokalne regulacje.

Marketplace dokłada do tego własny zestaw zasad — o innym poziomie rygoru niż własny sklep. Ten wątek rozwijam przy ekspansji zagranicznej.

Jak to wyglądało procesowo

Kolejność, która się sprawdziła:

1. Audyt atrybutów — które pola są kompletne, które są puste, które są niespójne między dostawcami.
2. Reguła odcięcia — definicja atrybutów krytycznych, bez których produkt nie idzie do generowania.
3. Partia pilotażowa na jednej kategorii, czytana ręcznie w całości. To jest moment na wyłapanie systematycznych błędów, zanim pomnożysz je przez siedemdziesiąt tysięcy.
4. Generowanie właściwe przez API, partiami, z zapisem wersji i parametrów.
5. Kontrola automatyczna na całości plus losowa próbka do czytania.
6. Publikacja etapami, nie wszystko naraz — żeby dało się cofnąć.

Krok trzeci jest tym, który ludzie pomijają najczęściej i najdrożej.

Czego bym nie powtórzył

Nie zaczynałbym od pisania promptu. Zacząłbym od arkusza z kompletnością atrybutów. Gdybym zrobił to od razu, wiedziałbym wcześniej, że część kategorii w ogóle nie nadaje się do automatyzacji w tym stanie danych.

Nie generowałbym wszystkiego naraz. Partie po kategoriach dają możliwość korekty. Jedna wielka partia daje jeden wielki problem.

Nie traktowałbym opisu jako produktu końcowego. Wygenerowany tekst to półprodukt, który dopiero po walidacji i publikacji staje się czymś wartościowym. Projekt kończy się w momencie, w którym opisy działają na stronie — nie w momencie, w którym wychodzą z API.

Kiedy to się nie opłaca

Uczciwie, bo to jest dziś rzadko mówione:

• Przy małym katalogu. Poniżej kilkuset produktów napisanie opisów ręcznie jest tańsze niż zbudowanie procesu, który je wygeneruje. Próg opłacalności leży wysoko.
• Kiedy dane wejściowe są w rozsypce i nikt nie zamierza tego naprawić. Bez uporządkowanych atrybutów dostaniesz szybko wygenerowany chaos.
• Kiedy opis nie jest wąskim gardłem. Jeśli produkty się nie sprzedają z powodu ceny, dostępności albo zdjęć, lepsze opisy tego nie odwrócą. To jest najczęstszy przypadek.
• Kiedy chodzi o kilkaset kluczowych produktów. Bestsellery zasługują na tekst napisany przez człowieka, który zna kategorię. Automatyzacja jest dla długiego ogona.

Wniosek

Najbardziej wartościową rzeczą, jaką ten projekt dał firmie, nie były opisy. Było nią uporządkowanie danych produktowych, które przy okazji trzeba było zrobić — i które przydało się potem wszędzie: w feedach, w filtrach, w kampaniach produktowych, na marketplace’ach.

Tak zwykle wygląda dobrze zrobione wdrożenie AI w e-commerce. Nie jako nowa zdolność, której wcześniej nie było, tylko jako pretekst do posprzątania czegoś, co i tak trzeba było posprzątać — plus zdjęcie z ludzi pracy, której w tej skali po prostu nie da się wykonać ręcznie.

O tym, jak układam takie projekty razem z zespołem klienta, piszę tutaj.