Kiedy ekstrakcja za pomocą LLM przestaje się opłacać

Kiedy ekstrakcja za pomocą LLM przestaje się opłacać

Firecrawl pobiera 1 kredyt za scrape strony i 5 kredytów za ekstrakcję ustrukturyzowanych pól z tej samej strony (cennik Firecrawl, 2026). To pięciokrotny narzut za ten sam HTML przepuszczony przez model.

Obietnica brzmi świetnie: opisujesz, czego chcesz, dostajesz z powrotem JSON i nie musisz utrzymywać selektorów. Przy niestabilnych układach stron i jednorazowych zadaniach ten narzut ma sens. Ale w produkcyjnym pipeline, który codziennie pobiera 500 tys. stron produktowych z tych samych pięciu sklepów, to się nie opłaca.

Widzieliśmy zespoły, które wdrożyły ekstrakcję opartą domyślnie na LLM, dostały pierwszy miesięczny rachunek i natychmiast zaczęły szukać wyjścia. Rozwiązaniem zazwyczaj nie jest całkowita rezygnacja z LLM. Chodzi o to, by umieścić je we właściwym miejscu w pipeline.

Kalkulacja szybko staje się bezlitosna

Weźmy Firecrawl jako tę tańszą opcję. Scrape plus ekstrakcja AI to 6 kredytów za stronę bez crawlera, a 7 kredytów z crawlerem (analiza ScrapeGraphAI, 2026). Przy 100 tys. stron dziennie na ich planie "growth" daje to około 21 tys. dolarów miesięcznie, jeszcze przed uwzględnieniem ponownych prób i zanim zapłacisz za choćby jedno proxy.

Jeśli postawisz własny pipeline oparty na LLM, liczby się zmienią, ale wcale nie będą małe. GPT-4o kosztuje 2,50 USD za milion tokenów wejściowych (input tokens) i 10 USD za milion wyjściowych (output tokens) (PricePerToken, 2026). Strona produktowa po konwersji na markdown to jakieś 4-8 tys. tokenów wejściowych. Przyjmijmy średnio 6 tys. na wejściu i 200 na wyjściu dla obiektu JSON. Przy 100 tys. stron dziennie daje to 360 USD dziennie, czyli 11 tys. USD miesięcznie za zadanie, które selektory CSS robią za darmo po jednorazowej konfiguracji.

A to i tak tani model. Przejście na Claude Sonnet 4.6 (3 USD za input, 15 USD za output) podwaja ten rachunek (PE Collective, 2026). Wybierz model rozumujący (reasoning model), a dojdzie do tego 3-10-krotny narzut w zależności od tego, jak długo model "myśli" przed udzieleniem odpowiedzi.

Żadne z tych wyliczeń nie uwzględnia błędów. Poziom halucynacji rzędu 3-5% brzmi niegroźnie, dopóki nie policzysz konkretów. Przy 100 tys. stron dziennie oznacza to od 3 000 do 5 000 błędnych rekordów trafiających do Twojej hurtowni danych, które wyglądają dokładnie tak samo jak poprawne, ponieważ model wygenerował je z pełną pewnością siebie. Jak ujął to DataHen: "Problem nie w tym, że AI czasem się myli. Problem w tym, że myli się z absolutną pewnością siebie." (DataHen, 2026).

Co naprawdę robią doświadczone zespoły

Wystarczy poczytać dokumentację dostawców, którzy naprawdę uruchamiają scrapery produkcyjnie, by dostrzec spójny wzorzec: podejście hybrydowe. Użyj LLM raz, aby rozpracować strukturę strony, a potem uruchamiaj tani, deterministyczny kod dla całej reszty.

Zyte pisze o tym wprost w swojej dokumentacji: "Zamiast używać LLM dla każdej strony, użyj go do wygenerowania selektorów CSS dla wybranych pól na podstawie surowego HTML pierwszej strony, a następnie użyj tych selektorów do sparsowania wszystkich pozostałych stron." (poradnik Zyte o LLM, 2026). Apify zaleca dokładnie ten sam schemat w swoim przewodniku z 2026 roku: najpierw spróbuj użyć selektorów CSS, a w razie niepowodzenia przełącz się na LLM (poradnik Apify z 2026 roku). Artykuł na DEV Community opisujący wdrożenie produkcyjne idealnie oddaje tę architekturę: zcache'owana ścieżka selektora nic nie kosztuje, a LLM uruchamia się tylko wtedy, gdy walidacja zakończy się błędem (DEV.to, 2026).

Podział w środowisku produkcyjnym wygląda więc następująco:

• LLM inicjuje selektor (jedno wywołanie na cel, ułamki centa)
• Selektor działa na każdej stronie (za darmo)
• Walidator (zazwyczaj regex lub sprawdzenie obecności elementu) wykrywa zmiany w strukturze (drift)
• Wykrycie zmian uruchamia ponowną inicjalizację, tygodnie lub miesiące później

Koszt za stronę spada z około 0,005 USD do poziomu znacznie poniżej 0,0001 USD. Jakość rośnie, ponieważ deterministyczny parsing nie halucynuje. A tokeny wydajesz na to, w czym LLM są naprawdę dobre: na analizowanie nowych struktur, a nie na powtarzanie schematów, które już masz rozpracowane.

Gdzie LLM mimo wszystko na siebie zarabiają

To nie jest tekst wymierzony w LLM. Istnieje mnóstwo zadań ekstrakcji, w których model jest idealnym narzędziem, a kalkulacja kredytów się spina:

• Niestabilne układy stron, które zmieniają się co tydzień. Selektory, które sypią się w każdy wtorek, kosztują więcej czasu programistów niż ekstrakcja LLM w tokenach. Uruchom model.
• Cele z długiego ogona (long-tail), których nigdy nie odwiedzisz ponownie. Pisanie selektora się nie opłaca. Uruchom model.
• Nieustrukturyzowana treść, gdzie wynikiem jest podsumowanie. Mapowanie opisów stanowisk na umiejętności, artykułów na tezy, opinii na sentyment. Selektory tu nie pomogą. Uruchom model.
• Strony z opcjonalnymi polami rozrzuconymi po różnych wariantach układu. Jeden szablon z dwudziestoma warunkowymi renderowaniami to idealne miejsce, w którym LLM wygrywają z łańcuchami regexów.

Spójrz na swój pipeline. Posortuj cele według wolumenu. Najpopularniejsze 20% pod kątem liczby requestów prawie zawsze ma stabilną strukturę (dlatego stanowią te 20% — zostały wdrożone celowo). To idealni kandydaci na selektory. Długi ogon to miejsce, gdzie powinien działać model.

Co to oznacza dla Twojego stacku

Przekaz marketingowy dostawców w 2026 roku nakłania do domyślnego korzystania z ekstrakcji LLM. Cenniki oparte na kredytach sprawiają, że wygląda to sensownie przy małych projektach. Przestaje to mieć sens, gdy zaczynasz się skalować, dokładnie tak samo jak wielkość puli proxy przestała gwarantować sukces, gdy tylko podstawowy sygnał uległ zakłóceniu.

Trzy wnioski dla zespołów budujących prawdziwe pipeline'y:

1. Oddziel pobieranie (fetch) od parsowania. Jeśli Twój dostawca scrapingu zwraca tylko JSON wyekstrahowany przez LLM, nie będziesz mieć możliwości powrotu do selektorów, gdy przyjdzie wysoki rachunek. Wybierz infrastrukturę, która dostarcza HTML i pozwala Ci samodzielnie zdecydować o ścieżce ekstrakcji.
2. Agresywnie cache'uj na poziomie selektorów. Wygenerowane selektory można wielokrotnie wykorzystywać na tysiącach stron. Kosztowne jest ich generowanie, a nie używanie.
3. Mierz koszt na rekord, a nie na stronę. Pipeline, który kosztuje 0,001 USD za stronę, ale dostarcza 5% błędnych rekordów, jest droższy niż ten kosztujący 0,005 USD za stronę, ale dostarczający czyste dane. Przechowywanie danych, zapytania w dół strumienia (downstream) i ostateczne czyszczenie bazy też generują koszty.

Wybierz tę nudniejszą część

Domyślna ekstrakcja przez LLM świetnie sprawdza się w wersjach demonstracyjnych, ale nie na produkcji. Zespoły, które robią to dobrze, traktują LLM jako narzędzie do zrozumienia strony, a nie do jej czytania. Nudny, deterministyczny kod wciąż wygrywa w 2026 roku w starciu z dużym wolumenem danych; model wygrywa tam, gdzie pojawiają się nowości. W nowoczesnym stacku jest miejsce na jedno i drugie.

W FourA, Single i Browser zwracają surową odpowiedź (HTML, wyrenderowany DOM, nagłówki, body) i na tym kończą swoje zadanie. To od Ciebie zależy, czy sparsujesz ją za pomocą selektorów, wyślesz do modelu, czy zrobisz jedno i drugie. Nie doliczamy mnożnika kredytów za ekstrakcję, której nie przeprowadziliśmy.