MAMS vs własny skrypt na API modelu językowego
Prototyp własnego skryptu powstaje w jedno popołudnie i generuje przyzwoity opis — i to jest źródło nieporozumienia, bo generowanie tekstu to najmniejsza część problemu. Reszta to mapowanie kategorii i parametrów osobno pod każdą platformę, limity i formaty pól, walidacja z auto-korektą, obsługa błędów i ponowień na tysiącach wywołań, tłumaczenia z terminologią branżową, generowanie grafik, publikacja zwrotna do systemu magazynowego oraz nadążanie za zmianami wymogów platform. Własny skrypt ma sens, gdy masz w firmie developera, katalog jest mały i stabilny, a wystawiasz na jedną–dwie platformy w jednym języku. Przy kilku tysiącach SKU i kilku rynkach koszt zbudowania i utrzymania tego wszystkiego przewyższa koszt gotowego systemu — a projekt zwykle nie umiera na etapie budowy, tylko utrzymania.
Dlaczego prototyp działa, a wdrożenie nie
Pierwsza wersja skryptu wygląda obiecująco, bo rozwiązuje najłatwiejszy fragment zadania. Bierzesz nazwę produktu i kilka parametrów, wysyłasz do modelu, dostajesz zgrabny opis. Na dziesięciu produktach wynik jest dobry, na stu wciąż akceptowalny — i tu zapada decyzja o budowie własnego rozwiązania. Ściana pojawia się dopiero przy realnym katalogu i wynika z rzeczy, które w prototypie nie występują. Dane wejściowe są nierówne: część SKU ma komplet parametrów od producenta, część ma trzy pola i nazwę z myślnikami, część ma opis, który jest listą kodów. Model, karmiony ubogim wejściem, nie odmawia — dopisuje prawdopodobnie brzmiące szczegóły, których nikt nie zweryfikował, i przy tysiącu ofert nie masz jak sprawdzić każdej ręcznie. Format wyjścia bywa niestabilny: raz JSON, raz JSON w bloku kodu, raz z dodatkowym komentarzem — więc parser wymaga obudowy w retry i walidację schematu. Do tego dochodzą limity i formaty pól, inne na każdej platformie: długość tytułu, dozwolone znaki, dopuszczalne tagi HTML w opisie, wymagane parametry w danej kategorii. Skrypt, który tego nie pilnuje, produkuje oferty odrzucane przy publikacji — a odrzucenie wraca do Ciebie jako kod błędu przy pozycji numer 4 200 z 11 000, w środku nocnego przebiegu. Wreszcie skala operacyjna: kilkanaście tysięcy wywołań API to limity szybkości, timeouty, częściowe niepowodzenia, konieczność wznowienia od miejsca przerwania i kontrola kosztów tokenów. Każda z tych rzeczy z osobna jest do rozwiązania. Razem tworzą projekt informatyczny, a nie skrypt.
Czego nie widać w wycenie własnego rozwiązania
Wycena budowy własnego narzędzia niemal zawsze obejmuje wyłącznie generowanie treści, bo to jedyna część, którą widać w prototypie. Poniżej lista pozycji, które pojawiają się później i decydują o kosztach. Mapowanie kategorii i parametrów: każda platforma ma własne drzewo kategorii i własny zestaw wymaganych pól, więc jedno SKU musi zostać opisane inaczej dla każdej z nich — i to mapowanie trzeba utrzymywać, bo platformy zmieniają kategorie. Walidacja z auto-korektą: potrzebujesz warstwy, która przed publikacją sprawdza kompletność i zgodność z regułami, a przy błędzie potrafi poprawić ofertę zamiast tylko ją odrzucić. Tłumaczenia: tłumaczenie maszynowe opisu technicznego rozjeżdża terminologię branżową, więc potrzebujesz kontroli słownictwa i weryfikacji jakości per język. Grafiki: paneli produktowych model tekstowy nie zrobi — to osobny pipeline. Integracja w obie strony: pobranie danych z systemu magazynowego i zapisanie wyniku z powrotem do właściwych pól, per platforma, bez nadpisania tego, co już działa. Idempotencja i wznawialność: przebieg musi dać się powtórzyć bez tworzenia duplikatów. Obserwowalność: bez logów i raportu z przebiegu nie wiesz, które oferty poszły, które padły i dlaczego. Do tego kontrola kosztów, obsługa sekretów, wersjonowanie promptów i testy regresyjne — bo zmiana jednego promptu potrafi popsuć wynik w kategorii, której nie sprawdzałeś. I pozycja najdroższa, bo bezterminowa: utrzymanie. Platformy zmieniają wymogi, API modeli się zmieniają, modele są wycofywane i zastępowane nowszymi o innym zachowaniu, dochodzą nowe obowiązki regulacyjne w danych oferty. Skrypt, który nie jest aktywnie utrzymywany, po kilku miesiącach przestaje publikować — zwykle w najmniej wygodnym momencie.
Kiedy własny skrypt ma sens, a kiedy gotowy system
Własne rozwiązanie jest rozsądne w kilku sytuacjach. Masz w zespole developera, który realnie ma czas nie tylko zbudować, ale i utrzymywać narzędzie przez lata. Katalog jest mały i stabilny — kilkaset SKU, rzadkie zmiany. Wystawiasz na jedną, najwyżej dwie platformy, w jednym języku. Twoje wymagania są nietypowe na tyle, że żaden gotowy produkt ich nie pokrywa. Albo traktujesz to jako inwestycję w kompetencję, którą chcesz mieć u siebie niezależnie od rachunku. Gotowy system wygrywa w odwrotnym układzie: katalog liczony w tysiącach SKU, kilka platform, kilka języków, brak wolnych rąk developerskich i potrzeba efektu w tygodniach, a nie kwartałach. Uczciwa metoda porównania jest prosta: policz nie koszt zbudowania, tylko koszt posiadania przez dwa lata — czas budowy, czas utrzymania, koszt tokenów, koszt przestojów, kiedy publikacja padnie, i koszt alternatywny tego, czego developer w tym czasie nie zrobi. MAMS jest zbudowany dokładnie wokół tych elementów, których w prototypie nie widać: wieloagentowy pipeline z walidatorami i auto-korektą, mapowanie kategorii i parametrów per platforma, tłumaczenia na język rynku o jakości 97–99,8%, generowanie grafik oraz publikacja zwrotna do pól produktowych w Base (BaseLinker). W praktyce oznacza to 10 000+ ofert w mniej niż 24 godziny przy ~0% błędów walidacyjnych. U Dystrybutora 11 000+ SKU pozwoliło to wystawić 20 000+ ofert, w tym 1500+ na Allegro ze wzrostem sprzedaży o 114%; Kaufland urósł o 286%, Amazon jako nowy kanał, a cała firma przeszła ze 139 723 do 321 652 zł miesięcznie — +130% rok do roku, czyli +181 929 zł miesięcznie. To nie jest argument przeciwko budowaniu własnych narzędzi w ogóle — to argument za policzeniem pełnego zakresu, zanim decyzja zapadnie na podstawie działającego prototypu.
| Element | Własny skrypt na API modelu | MAMS | |
|---|---|---|---|
| Generowanie opisu | Tak — najłatwiejsza część | Tak, osobno pod każdą platformę | |
| Mapowanie kategorii i parametrów | Do zbudowania i utrzymania samodzielnie | Wbudowane, per marketplace | |
| Walidacja i auto-korekta | Trzeba napisać od zera | Walidatory z auto-korektą, ~0% błędów | |
| Tłumaczenia branżowe | Zwykle surowe tłumaczenie maszynowe | Kontrola terminologii, jakość 97–99,8% | |
| Grafiki | Osobny projekt | Generowane w ramach pipeline’u | |
| Publikacja zwrotna do Base | Własna integracja i obsługa błędów | Write-back do pól produktowych | |
| Skala i wznawianie przebiegu | Limity, timeouty, duplikaty do ogarnięcia | 10 000+ ofert w mniej niż 24 h | |
| Utrzymanie po zmianach platform i modeli | Po Twojej stronie, bezterminowo | Po stronie dostawcy |
Najczęstsze pytania
Czy da się samemu napisać skrypt generujący oferty na marketplace’y?
Da się i sam generator opisów powstaje szybko. Problemem nie jest generowanie tekstu, tylko warstwa wokół niego: mapowanie kategorii i parametrów per platforma, limity i formaty pól, walidacja z auto-korektą, tłumaczenia z terminologią branżową, grafiki, publikacja zwrotna i obsługa kilkunastu tysięcy wywołań z ponowieniami. To już projekt informatyczny z utrzymaniem, a nie skrypt.
Ile realnie kosztuje własne rozwiązanie?
Licz koszt posiadania przez dwa lata, nie koszt zbudowania: czas developera na budowę, czas na utrzymanie po zmianach wymogów platform i API modeli, koszt tokenów, koszt przestojów, kiedy publikacja przestanie działać, oraz to, czego ten developer w tym czasie nie zrobi. Ta suma wygląda inaczej niż wycena samego prototypu.
Dlaczego skrypt zaczyna zawodzić dopiero przy dużym katalogu?
Bo na dziesięciu produktach nie widać nierównych danych wejściowych ani zachowań brzegowych. Przy tysiącach SKU pojawiają się produkty z trzema polami opisu, niestabilny format odpowiedzi modelu, odrzucenia na walidacji platformy, limity szybkości API i częściowe niepowodzenia przebiegu. Każdą z tych rzeczy trzeba obsłużyć osobno, a ich sprawdzenie ręcznie przy takiej skali nie jest wykonalne.
Kiedy własny skrypt jest lepszym wyborem niż gotowy system?
Gdy masz developera z realnym czasem na utrzymanie, katalog jest mały i stabilny, wystawiasz na jedną–dwie platformy w jednym języku, a wymagania są na tyle nietypowe, że nie pokrywa ich żaden gotowy produkt. Przy kilku tysiącach SKU, kilku platformach i kilku językach rachunek zwykle wychodzi odwrotnie.