AI opisuje zdjęcia produktów, a katalog ładuje się 27 sekund

Problem

Punkt wyjścia jest znany każdemu, kto prowadzi sklep albo magazyn: ktoś musi napisać tytuł i opis do każdego produktu. Przy siedemdziesięciu pozycjach to nudne popołudnie, przy siedmiuset to etat. Zadanie brzmiało więc prosto: wrzucasz zdjęcie, a system sam pisze tytuł i opis.

Ta część zadziałała od razu i, szczerze mówiąc, jest w całej historii najmniej ciekawa. Model rozpoznaje przedmiot na zdjęciu i pisze o nim po polsku sensowne zdania. Problem pojawił się gdzie indziej.

Lista produktów ładowała się ponad 27 sekund. Nie „wolno” — dwadzieścia siedem sekund białego ekranu, po którym część ludzi zdąży zamknąć kartę. Aplikacja z działającą sztuczną inteligencją była nie do użycia z powodu, który ze sztuczną inteligencją nie miał nic wspólnego.

Diagnoza

Zdjęcia produktów leżały w bazie danych, zakodowane jako tekst. To rozwiązanie, które kusi na początku każdego projektu, bo jest wygodne: nie trzeba nigdzie osobno przechowywać plików, wszystko siedzi w jednym miejscu i da się skopiować jednym poleceniem.

Kosztuje jednak dokładnie tyle, ile w tym projekcie. Zdjęcie zapisane w ten sposób zajmuje o kilkadziesiąt procent więcej miejsca niż plik, a co gorsza — przy każdym otwarciu listy szła przez sieć cała treść wszystkich zdjęć naraz. Nie miniaturki, nie adresy plików: całe zdjęcia, w każdej odpowiedzi. Przeglądarka dostawała wielomegabajtową odpowiedź i cierpliwie ją rozpakowywała, zanim pokazała cokolwiek.

Co zrobiłem

Przeniosłem zdjęcia do magazynu plików, a w bazie zostawiłem sam adres. Od tej pory lista produktów to lekki spis tekstu z adresami obrazków, a same obrazki przeglądarka pobiera osobno i tylko wtedy, gdy naprawdę są potrzebne — z pamięci podręcznej sieci, a nie z bazy danych.

Przy okazji migracji naprawiłem 44 brakujące zdjęcia, o których w ogóle nie było wiadomo, że brakują. Katalog liczy 75 produktów, więc mówimy o ponad połowie stanu — takie rzeczy wychodzą dopiero wtedy, gdy ktoś przenosi dane po jednym i sprawdza, czy każde ma swoją parę.

Drugi wniosek: model dobrany po pomiarze, nie po przeczuciu

Modele AI rozliczają się za zużycie, a różnice między nimi bywają kilkukrotne. W tym projekcie nie zgadywałem, który wypada lepiej — zmierzyłem koszt pojedynczego żądania i porównałem jakość opisów na tych samych zdjęciach. Wybrany model okazał się tańszy przy porównywalnym wyniku.

To brzmi jak drobiazg przy siedemdziesięciu pięciu produktach i faktycznie nim jest. Przestaje nim być, gdy proces wykonuje się kilka tysięcy razy w miesiącu — a to jest normalna skala dla automatyzacji, która ma sens. Dlatego przy każdym wdrożeniu z modelem AI liczę koszt na jedno wykonanie i podaję go, zanim cokolwiek ruszy na produkcję.

Co z tego wynika dla Twojego projektu

Jeżeli masz katalog, magazyn, bazę zdjęć albo cokolwiek, co „działa, tylko strasznie muli” — zanim ktoś zaproponuje Ci przepisanie całości na nową technologię, warto sprawdzić, co dokładnie idzie przez sieć przy każdym otwarciu ekranu. W mojej praktyce niewygodna prawda brzmi tak: większość dramatycznie wolnych aplikacji jest wolna z jednego, prozaicznego powodu, a nie z dziesięciu naraz.

I druga rzecz, o wiele ważniejsza przy kupowaniu automatyzacji z AI: efektowna część (model, który pisze opisy) prawie nigdy nie jest tą, która decyduje o powodzeniu projektu. Decyduje nudna warstwa pod spodem — gdzie leżą pliki, co się dzieje, gdy usługa nie odpowie, ile kosztuje jedno wykonanie. O to warto pytać wykonawcę, a nie o to, którego modelu użyje.

Efekt w liczbach

• 27 s → 0,3 s czasu ładowania listy produktów, około 90 razy szybciej,
• zero zmian we frontendzie — problem rozwiązany po stronie danych,
• 75 produktów w katalogu, 44 brakujące zdjęcia wykryte i uzupełnione przy migracji,
• model AI wybrany po pomiarze kosztu jednego żądania, nie „na czuja”.

Stack: n8n jako warstwa wykonawcza całego zaplecza (analiza zdjęcia, lista, dodanie i usunięcie produktu), PostgreSQL jako baza, Cloudflare R2 jako magazyn plików, frontend na Cloudflare Pages, model wizyjny wywoływany przez OpenRouter. Wdrożenie na własnej infrastrukturze.

Inne case studies