Nie zastępuje danych produktowych
Jeżeli katalog nie ma atrybutów, AI nie wytworzy ich z powietrza. Przy ubogich danych sensowniejszym pierwszym krokiem jest audyt i uzupełnienie kartoteki.
Case study · Shoper · AI/API · dane produktowe
21 000 produktów opisanych i przetworzonych w 96 godzin
Ten case nie jest o tym, że AI umie pisać teksty. Jest o tym, jak przeprowadzić duży katalog Shopera przez pipeline, który czyta dane i zdjęcia, generuje opisy i metadane w zadanym formacie, sprawdza je regułami, odkłada rekordy niepewne do raportu i publikuje przez API tylko to, co przeszło kontrolę.
Shoper API
Python
OpenAI
Vision AI
walidacja
logi
Stan początkowy
Katalog był kompletny handlowo, ale nie treściowo
Produkty miały SKU, ceny, stany i zdjęcia. Brakowało opisów oraz spójnych metadanych. Przy tej skali ręczne uzupełnianie oznacza miesiące pracy i nierówną jakość — a przy okazji ryzyko, że osoba pisząca „domyśli się" parametru, którego nie ma w danych.
Ograniczenie projektowe
AI nie miała prawa niczego zgadywać
Model dostawał wyłącznie dane z karty produktu i ze zdjęcia. Jeżeli materiał, skład, rozmiarówka albo przeznaczenie nie wynikały z danych wejściowych, opis nie mógł ich zawierać. Rekord z brakiem wymaganego pola nie trafiał do publikacji, tylko do raportu.
Dane wejściowe
Z czego powstawał opis jednego produktu
Poniżej anonimowa próbka struktury wejścia. Konkretne dane klienta nie są publikowane — pokazujemy sam model rekordu, bo to on decyduje o jakości wyniku.
| Pole wejściowe | Przykład (anonimowy) | Rola w generowaniu | Gdy brakuje |
|---|---|---|---|
| SKU | XX-1042-BLK-M | klucz rekordu i publikacji | rekord odrzucony |
| Nazwa | Kurtka softshell męska | baza tematu opisu | rekord odrzucony |
| Kategoria | Odzież → Kurtki → Softshell | wybór promptu i słownictwa | rekord do przeglądu |
| Atrybuty | membrana, kaptur, kieszenie | treść części merytorycznej | opis skrócony, bez zmyślania |
| Zdjęcie główne | URL do pliku produktu | weryfikacja cech widocznych | generowanie tylko z atrybutów |
| Marka | marka z kartoteki | ton i nazewnictwo | pominięta w treści |
| Warianty | rozmiary S–XXL | informacja o rozmiarówce | brak wzmianki o rozmiarach |
Pipeline
Siedem etapów, każdy z własnym warunkiem przejścia
Rekord przechodzi dalej tylko wtedy, gdy spełni warunek etapu. Inaczej ląduje w raporcie z powodem odrzucenia — i można go poprawić oraz uruchomić ponownie bez ruszania reszty katalogu.
01
Eksport z Shopera
Pobranie produktów, kategorii, atrybutów i adresów zdjęć przez API. Wynik zapisany jako zbiór wejściowy — praca nigdy nie idzie bezpośrednio na produkcji.
02
Walidacja wejścia
Kontrola kompletności: SKU, nazwa, kategoria, dostępność zdjęcia. Rekordy niekompletne odpadają tutaj, zanim ktokolwiek wyda złotówkę na przetwarzanie.
03
Analiza zdjęcia
Vision AI potwierdza cechy widoczne na zdjęciu. Służy do weryfikacji, nie do wymyślania parametrów — rozbieżność z atrybutami oznacza rekord do przeglądu.
04
Generowanie
Prompt dobrany do kategorii produktu, z twardym zakazem twierdzeń nieobecnych w danych i z narzuconą strukturą: opis, SEO title, meta description.
05
Kontrola jakości
Długości pól SEO, brak zakazanych sformułowań, brak powtórzeń między produktami, poprawność językowa, zgodność z atrybutami wejściowymi.
06
Publikacja przez API
Zapis wyłącznie wybranych pól, partiami, z ponowieniem po błędzie sieci i kontrolą limitów. Pola nieobjęte zakresem pozostają nietknięte.
07
Raport końcowy
Zestawienie: opublikowane, do przeglądu, odrzucone — z powodem dla każdego rekordu i możliwością ponownego uruchomienia samej reszty.
Rekordy odrzucone
Najciekawsze jest to, czego nie opublikowaliśmy
Odrzucenie nie jest porażką procesu — jest jego funkcją. Poniżej realne kategorie powodów, dla których rekord nie trafiał do sklepu.
- brak zdjęcia albo zdjęcie niedostępne pod podanym adresem,
- kategoria pusta lub niejednoznaczna, więc prompt nie miał kontekstu,
- atrybuty sprzeczne ze zdjęciem — do decyzji człowieka,
- zbyt mało danych, żeby napisać cokolwiek ponad ogólniki,
- wynik nie przeszedł kontroli długości albo powtarzalności,
- produkt archiwalny lub wycofany, oznaczony w eksporcie.
EtapWarunek przejściaLog
exportrekord pobrany z APIINFO
validatekomplet pól wymaganychWARN przy braku
visionzdjęcie odczytaneWARN przy 404
generateodpowiedź w formacieERROR przy timeout
qadługości i brak duplikatuWARN → review
publishAPI zwróciło 200ERROR → retry
reportzestawienie partiiINFO
Ograniczenia AI
Czego ten pipeline nie robi
Nie publikuje bez kontroli
Każdy rekord przechodzi walidację, a rekordy niepewne wymagają decyzji człowieka. Tryb „wygeneruj i wypchnij" jest w tym procesie niedostępny z założenia.
Nie gwarantuje pozycji w Google
Opisy i metadane usuwają barierę wejścia, ale widoczność zależy też od struktury kategorii, indeksacji, linkowania i konkurencji w danej niszy.
Nie działa raz na zawsze
Nowe produkty wymagają kolejnych przebiegów. Dlatego proces jest powtarzalny i parametryzowany, a nie jednorazowym skryptem.
FAQ
Pytania o ten pipeline
Tak, ale tylko wtedy, gdy nie działa jako luźny generator tekstu. Potrzebne są dane wejściowe, reguły jakości, walidacja, logi i możliwość pomijania produktów, których AI nie powinno opisywać bez dodatkowej informacji.
API pozwoliło aktualizować dane w sklepie w sposób kontrolowany, bez ręcznego kopiowania treści do panelu. Pozwalało to pracować partiami, logować błędy i publikować tylko te pola, które były częścią procesu.
Tak, ale najpierw trzeba sprawdzić jakość danych, platformę, dostęp do API, strukturę kategorii, zdjęcia, atrybuty i wymagania SEO. Bez tego automatyzacja może tylko szybciej powielić chaos.
Nie zawsze. Najlepiej traktować ją jako system do masowego przygotowania bazowych treści, które mają strukturę, SEO i spójność. Przy najważniejszych produktach nadal można dodać ręczną redakcję premium.
Masz katalog, którego nikt nie zdąży opisać ręcznie?
Podaj liczbę produktów, platformę i to, jakie dane masz w kartotece. Odpowiemy, czy pipeline ma sens, czy najpierw trzeba uporządkować dane wejściowe.