Blog
AI zrobi Ci 5000 rumuńskich ofert w weekend. W poniedziałek zaczynają się problemy
Jeszcze kilka lat temu lokalizacja kilku tysięcy produktów na nowy rynek oznaczała tygodnie pracy, duży zespół i całkiem konkretny budżet.
Dziś?
Wrzuć dane do AI, przygotuj prompt i teoretycznie możesz mieć cały rumuński katalog gotowy przed poniedziałkiem.
Brzmi świetnie. I właściwie jest świetnie.
Pod warunkiem, że nie pomylimy dwóch zupełnie różnych rzeczy: szybko wygenerowanego katalogu i dobrze zlokalizowanego katalogu.
AI bardzo mocno zmieniło możliwości ekspansji e-commerce. Pozwala pracować szybciej, taniej i przede wszystkim na skali, która jeszcze niedawno wymagała całych zespołów.
Ale wraz z tą skalą pojawił się nowy problem.
Dzisiaj nie musimy już martwić się tylko o to, czy AI zrobi błąd. Musimy martwić się o to, że ten sam błąd potrafimy automatycznie powielić 5000 razy.
Jeden błąd razy 5000
Przy 20 produktach błędy można jeszcze wyłapać ręcznie. Oczywiście pod jednym, dość istotnym warunkiem: masz kogoś, kto zna dany język na tyle dobrze, żeby w ogóle zauważyć, że coś jest nie tak.
Bo jeżeli osoba weryfikująca sama nie zna rumuńskiego, może patrzeć na poprawne gramatycznie zdanie i nie mieć najmniejszego powodu, żeby je zakwestionować.
A AI brzmi bardzo przekonująco. Nawet wtedy, kiedy nie ma racji.
Przy katalogu liczącym kilka tysięcy SKU problem robi się jeszcze większy.
Model może dopisać parametr, którego produkt nigdy nie miał. Pomylić materiał. Źle zinterpretować wariant. Zmienić zawartość zestawu. Użyć określenia poprawnego językowo, ale zupełnie nienaturalnego dla lokalnego rynku.
Może również stworzyć zbyt odważny claim, którego nie było w danych źródłowych, albo „optymalizować SEO” tak długo, aż tekst zacznie bardziej przypominać worek słów kluczowych niż ofertę przygotowaną dla klienta.
I do tego dochodzi jeden z moich ulubionych problemów przy dużych katalogach: różne nazwy tego samego typu produktu.
Bo AI lubi synonimy.
E-commerce trochę mniej.
Jedna główka, dwie nazwy i bardzo dużo ofert
Weźmy przykład całkowicie niezwiązany z branżami, z którymi pracuję na co dzień.
Sprzedajemy główki do szczoteczek elektrycznych.
Polskie określenie „główka do szczoteczki elektrycznej” model może przetłumaczyć jako:
„vârf pentru periuță electrică”
zamiast określenia, które wcześniej zweryfikowaliśmy i przyjęliśmy:
„capăt pentru periuță electrică”.
Przy jednym produkcie mamy po prostu jedno złe tłumaczenie. Można poprawić. Koniec historii.
Ale wyobraźmy sobie, że firma ma kilkadziesiąt modeli, kilka marek, zestawy po 2, 4 i 8 sztuk, różne rodzaje włosia, kompatybilności i warianty.
AI przy jednym produkcie użyje „vârf”. Przy drugim „capăt”. Przy trzecim może znaleźć jeszcze inne określenie.
W kategorii pojawia się jedna nazwa, w filtrze druga, w tytule produktu trzecia, a do Google Merchant Center lub marketplace’u wysyłamy jeszcze czwartą wersję.
Każde z tych określeń może nawet wyglądać na językowo poprawne.
Problem w tym, że sklep przestaje być spójny.
A jeżeli błędna decyzja zostanie zapisana w automatyzacji, ten sam termin może trafić do setek tytułów produktów, opisów, filtrów, feedów produktowych, ofert marketplace, reklam, meta danych, a czasem również grafik produktowych.
I nagle nie poprawiamy już jednej karty produktu.
Poprawiamy cały ekosystem sprzedaży.
Tłumaczenie nie powinno zaczynać się od tłumaczenia
To brzmi trochę absurdalnie, ale przy dużych projektach lokalizacyjnych jedną z pierwszych rzeczy, które warto zrobić, jest właśnie… nie tłumaczyć całego katalogu.
Najpierw trzeba podjąć decyzje.
Jak naprawdę nazywa się ten produkt na rynku rumuńskim? Jakiej nazwy używa klient? Jakiej nazwy używa konkurencja?
Co pojawia się na eMAG? Co pojawia się w Google? Jakiego terminu używają specjalistyczne sklepy i dystrybutorzy?
I jeszcze ważniejsze: czy termin popularny w wynikach wyszukiwania jest rzeczywiście poprawny?
Czy mamy różnicę między językiem konsumenckim a technicznym? Czy w tytule chcemy stosować tę samą formę co w kategorii? Czy określenie używane przez marketplace jest tym samym, którego powinniśmy użyć na własnym sklepie?
Dopiero po takim researchu podejmujemy decyzję.
Ale nie zostawiamy jej w głowie osoby, która robiła research. Nie zostawiamy jej też w jednym czacie z ChatGPT i nie liczymy na to, że za trzy tygodnie model „będzie pamiętał, jak ustaliliśmy to ostatnio”.
Bo nie o pamięć tutaj chodzi.
Potrzebujemy systemu.
Glosariusz, czyli miejsce, w którym kończy się językowa demokracja
Tworzymy glosariusz.
W nim zapisujemy kluczowe decyzje językowe dla konkretnego rynku.
Jeżeli ustalamy, że używamy „capăt pentru periuță electrică”, ta decyzja trafia do glosariusza.
Jeżeli inne określenie jest niepożądane, również to zapisujemy.
W glosariuszu możemy określić preferowaną nazwę produktu, dopuszczalne synonimy, formę używaną w tytule, formę stosowaną w kategorii, terminy do filtrów, nazwy parametrów, słowa, których nie używamy, uwagi kontekstowe oraz wyjątki dla konkretnych kategorii.
I dopiero kiedy glosariusz zostanie zweryfikowany, zatwierdzamy go jako źródło prawdy dla danego rynku.
To ważny moment.
Od tej chwili AI nie powinno już za każdym razem podejmować na nowo decyzji, jak przetłumaczyć ten sam produkt.
Decyzja została podjęta wcześniej. AI ma się do niej zastosować.
Najpierw research. Potem decyzja językowa. Następnie zapisanie i zatwierdzenie. Dopiero później skalowanie.
I dopiero wtedy tym glosariuszem karmimy AI przy dalszym tłumaczeniu i lokalizacji.
To naprawdę niewielka zmiana w procesie, która przy kilku tysiącach produktów robi ogromną różnicę.
Nie każdy poprawny rumuński jest dobrym rumuńskim e-commerce
To również rzecz, którą warto mocno podkreślić.
Lokalizacja nie oznacza sprawdzenia, czy zdanie jest gramatycznie poprawne.
Można napisać tekst bez żadnego błędu gramatycznego i nadal stworzyć ofertę, która dla rumuńskiego klienta brzmi dziwnie. Albo sztucznie. Albo zbyt technicznie. Albo po prostu jak tłumaczenie.
Dlatego przy ekspansji interesuje mnie nie tylko pytanie:
„Czy to jest poprawne po rumuńsku?”
Interesuje mnie także:
„Czy Rumun rzeczywiście tak nazywa ten produkt?”
„Czy tak go szuka?”
„Czy takiego określenia spodziewa się na karcie produktu?”
„Czy ten tekst brzmi jak lokalny e-commerce, czy jak polski sklep przepuszczony przez tłumacz?”
To są dwie zupełnie inne rzeczy.
I właśnie tutaj sama znajomość narzędzia AI nie wystarcza. Potrzebna jest jeszcze wiedza o języku, rynku i zachowaniach lokalnego klienta.
Mój preferowany workflow lokalizacji z AI
Przy większych projektach coraz częściej pracuję według bardzo prostego schematu:
ChatGPT → glosariusz → QA → Codex → native check
Każdy z tych etapów ma inną rolę.
I właśnie rozdzielenie tych ról robi największą różnicę.
ChatGPT - research, kontekst i pierwsza wersja
ChatGPT bardzo dobrze sprawdza się na etapie przygotowawczym.
Może pomóc przeanalizować produkt, uporządkować dane, przygotować pierwszą wersję treści, porównać terminologię czy wskazać miejsca wymagające dodatkowego researchu.
Może stworzyć strukturę opisów, FAQ, krótkich opisów, tytułów czy danych potrzebnych do marketplace.
Może też pomóc zestawić kilka potencjalnych nazw produktu i przeanalizować ich użycie.
Ale nie powinien dostać pełnej swobody podejmowania wszystkich decyzji terminologicznych w katalogu.
Zwłaszcza jeżeli później te decyzje będziemy automatycznie powielać na tysiącach produktów.
Glosariusz - raz podejmujemy decyzję, później jej używamy
Kolejny etap to glosariusz.
Tutaj zapisujemy wszystkie decyzje, które chcemy później stosować w całym projekcie.
Dla mnie to jeden z kluczowych elementów jakości.
Nie chcę, żeby AI tłumaczyło ten sam typ produktu za każdym razem od nowa.
Chcę, żeby wiedziało:
to jest preferowany termin,
tego terminu używamy w tytule,
tego określenia nie stosujemy,
ten wariant można wykorzystać tylko w konkretnym kontekście.
Po zatwierdzeniu glosariusza karmimy nim AI przy kolejnych etapach pracy.
Wtedy model nie „zgaduje”.
Pracuje na wcześniej ustalonym standardzie.
A jeżeli pojawia się nowy termin, którego nie ma jeszcze w glosariuszu? Nie pozwalamy AI po cichu podjąć decyzji za nas. Termin trafia do analizy, zostaje zweryfikowany, zatwierdzony i dopiero potem staje się częścią źródła prawdy.
W ten sposób glosariusz rośnie razem z katalogiem.
QA - tutaj sprawdzamy, czy AI nie było zbyt kreatywne
Potem przychodzi QA.
I ten etap bardzo łatwo pominąć, bo przecież „tekst już jest”.
Tylko że nie sprawdzamy wyłącznie języka.
Weryfikujemy parametry, materiały, liczby, wymiary, warianty, zawartość zestawu, kompatybilność, spójność z materiałem źródłowym, terminologię, claimy oraz informacje techniczne i bezpieczeństwa.
Sprawdzamy również, czy jeden typ produktu nie zaczął nagle funkcjonować pod kilkoma różnymi nazwami.
Czy nazwy stosowane w tytułach odpowiadają temu, co ustaliliśmy w glosariuszu.
Czy AI nie postanowiło „urozmaicić” tekstu dodatkowym synonimem.
Czy nie pojawiły się informacje, których nie było w źródle.
Innymi słowy: sprawdzamy, czy AI czegoś nie dopisało, nie zgubiło albo nie ulepszyło na własną rękę.
Bo w marketingu kreatywność jest zaletą.
Przy parametrze technicznym produktu już trochę mniej.
Codex – automatyzujemy dopiero uporządkowany proces
Dopiero później przechodzę do pracy na większej skali.
I tutaj zaczyna się miejsce dla Codexa.
Można wykorzystać go do kontroli dużych zestawów danych, wykrywania niespójności, pracy na setkach czy tysiącach produktów oraz automatyzacji powtarzalnych zmian.
Możemy szukać produktów, w których pojawił się zakazany termin.
Sprawdzać, czy wszystkie produkty z danej kategorii korzystają z zatwierdzonego glosariusza.
Wykrywać brakujące parametry.
Porównywać dane źródłowe z finalną wersją.
Wyszukiwać polskie fragmenty pozostawione przez przypadek w rumuńskich opisach.
Kontrolować długość tytułów.
Sprawdzać strukturę treści.
Wykrywać produkty, w których ten sam parametr został nazwany na kilka różnych sposobów.
Ale najważniejsza zasada brzmi:
automatyzujemy proces, który wcześniej uporządkowaliśmy. Nie chaos.
Bo automatyzacja chaosu nie sprawia, że przestaje być chaosem.
Sprawia tylko, że mamy go więcej i szybciej.
Native check - ale w odpowiednim miejscu
Na końcu zostaje native check.
I tu pojawia się ważne „ale”.
AI nie eliminuje potrzeby znajomości języka.
Zmienia natomiast miejsce, w którym tej wiedzy najbardziej potrzebujemy.
Nie zawsze potrzebujemy native speakera, który ręcznie przeczyta 5000 prawie identycznych kart produktów.
Znacznie większą wartość może dać native, który sprawdzi nową kategorię, nową terminologię, bestsellery, kluczowe landing pages, ważne decyzje zapisane w glosariuszu, trudne przypadki, treści o większym ryzyku i teksty, które później staną się wzorem dla setek innych produktów.
To zasadnicza różnica.
Człowiek przestaje być ręcznym tłumaczem każdego pojedynczego SKU.
Staje się częścią systemu kontroli jakości.
AI nie eliminuje specjalistów. Pozwala inaczej wykorzystać ich wiedzę
I chyba tutaj najlepiej widać zmianę, którą AI wprowadza do ekspansji.
Kilka lat temu przy dużym katalogu mogliśmy potrzebować całego zespołu ludzi do ręcznego przygotowania opisów.
Dzisiaj dużą część tej pracy możemy zautomatyzować.
Ale nadal potrzebujemy osób, które potrafią podejmować właściwe decyzje.
Kogoś, kto zna język.
Kogoś, kto rozumie lokalny e-commerce.
Kogoś, kto wie, kiedy tłumaczenie jest technicznie poprawne, ale lokalnie brzmi źle.
Kogoś, kto potrafi zauważyć, że określenie użyte przez AI może nie odpowiadać temu, czego rzeczywiście szukają użytkownicy.
AI nie usuwa więc człowieka z procesu.
Po prostu przesuwa go z produkcji do kontroli, researchu i podejmowania decyzji.
I moim zdaniem właśnie tutaj leży jedna z największych korzyści z wykorzystania AI w ekspansji.
Nie chodzi o zastąpienie wiedzy.
Chodzi o to, żeby nie marnować tej wiedzy na zadania, które można bezpiecznie zautomatyzować.
A gdzie w tym wszystkim SEO, GEO i zero-click?
Dopiero tutaj.
I celowo dopiero tutaj.
Bo zanim zaczniemy optymalizować treść pod Google, marketplace, wyszukiwarki AI czy odpowiedzi generatywne, najpierw musimy mieć poprawne dane i poprawną terminologię.
Nie ma większego sensu perfekcyjnie zoptymalizować pod SEO nazwę produktu, która jest lokalnie błędna.
Nie ma sensu budować FAQ dla produktu, któremu AI dopisało nieistniejącą funkcję.
Nie ma też większego sensu tworzyć treści „pod AI”, jeżeli sami nie mamy ustalonego źródła prawdy.
Najpierw jakość danych.
Potem terminologia.
Później spójność.
Dopiero następnie SEO, GEO, zero-click i skalowanie widoczności.
Kolejność ma znaczenie.
Dobry prompt nie naprawi złych danych
I jeszcze jedna rzecz, o której często zapominamy.
Możemy stworzyć najlepszy prompt świata.
Możemy rozpisać rolę modelu, ton komunikacji, SEO, grupę docelową, strukturę nagłówków, CTA i wszystkie możliwe zasady.
Ale jeżeli w danych wejściowych firma sama nie wie, z jakiego materiału wykonano produkt, AI tego problemu nie rozwiąże.
Jeżeli źródło mówi w jednym miejscu, że zestaw zawiera cztery elementy, a w drugim, że pięć, model nie powinien wybierać sobie wersji, która wydaje mu się bardziej prawdopodobna.
Dobre AI powinno wtedy powiedzieć:
„Mam konflikt w danych. Sprawdźmy go.”
To jest znacznie cenniejsze niż bardzo ładnie napisany opis z błędną informacją.
I znowu wracamy do tego samego punktu: jakość lokalizacji zaczyna się dużo wcześniej niż w momencie generowania tekstu.
Najdroższy błąd? Ten, który potrafimy skalować
AI może bardzo mocno przyspieszyć ekspansję.
Daje mniejszym firmom dostęp do możliwości, które jeszcze niedawno były zarezerwowane dla dużych zespołów.
Możemy szybciej analizować rynki, przygotowywać treści, lokalizować katalogi, aktualizować oferty i wchodzić na kolejne marketplace’y.
I właśnie dlatego coraz mniej interesuje mnie pytanie:
„Jak szybko AI przetłumaczy cały katalog?”
Znacznie bardziej interesuje mnie:
„Jak zbudować proces, który pozwoli bezpiecznie zlokalizować 5000 albo 10 000 produktów?”
Bo największym zagrożeniem AI w ekspansji nie jest to, że zrobi jeden błąd.
Błędy zawsze się zdarzają.
Problem zaczyna się wtedy, kiedy ten sam błąd potrafimy dziś opublikować automatycznie 5000 razy.
By Edyta Astalus