Wyzwanie
Wszystkie startupy wertykalnej AI napotykają tę samą ścianę w okolicach drugiego miesiąca. Udostępniają copilota do wsparcia, asystenta do badań prawnych albo bota compliance. Pierwsze demo zdobywa klientów. Następnie dane się starzeją, a odpowiedzi zaczynają mijać się z rzeczywistością.
Obserwowaliśmy zespoły, które budują czysto część AI, a część danych jako refleksję po czasie. Pipeline do pobierania to jeden skrypt w Pythonie działający na czyimś laptopie. Pobiera on dane z 200 adresów URL ze źródłami, zrzuca czysty Markdown do vector store, po czym wszyscy świętują. Sześć tygodni później połowa odpowiedzi powołuje się na usunięte strony, wycofane API albo funkcje produktu wdrożone w marcu, a następnie ponownie zmienione w maju.
Rozwiązanie brzmi prosto: recrawlować każde źródło co tydzień. Rzeczywistość jest gorsza. Do 2026 roku około 60% renomowanych stron zablokuje crawlery AI (wzrost z 23% pod koniec 2023 r.), a zabezpieczenia to już nie są głupie testy na User-Agent. Analizują zachowanie w sesji, rytm requestów i sygnały na poziomie handshake. Naiwny skrypt, który działał w styczniu, w marcu bez ostrzeżenia zwraca puste strony.
Co gorsza, niektóre witryny serwują teraz zawartość typu tarpit (wygenerowany markovowo bełkot przypominający prawdziwą prozę), aż do momentu, w którym zatruje on Twoje embeddingi. Twoi inżynierowie spędzają więc połowę tygodnia na patchowaniu scrapera zamiast dostarczać produkt. Jakość retrievealu spada, klienci to zauważają, a zespół zatrudniony do zbudowania AI staje się warsztatem konserwacji scraperów.
Podejście
Problem recrawlu dzieli się na trzy konkretne decyzje, które muszą zapaść przy każdym requeście:
- Renderować czy nie? Większość portali z dokumentacją serwuje czysty HTML. Rosnąca część (wszystko zbudowane na Next.js, wszystko z client-side renderingiem) wymaga pełnego renderowania w przeglądarce, żeby zwrócić użyteczny content.
- Jakie proxy? Residential, datacenter, mobile, geo-pinned, specyficzne dla ISP. Odpowiedni wybór zależy od targetu.
- Czy to faktycznie zadziałało? 200 z pustym body albo strona HTML z CAPTCHA to udany request HTTP i nieudany crawl.
Platforma taka jak FourA traktuje każde z tych zagadnień pierwszoplanowo.
W kwestii renderowania wywołujesz Single w przypadku tanich, szybkich wywołań i Browser dla targetów opartych w dużej mierze na JS. Zarys tego wywołania jest taki sam, a kod ingestu decyduje w zależności od ustawień na poziomie poszczególnych źródeł, zamiast ciągnąć za sobą setki quirków dla poszczególnych stron.
W kwestii wyboru proxy Proxy Finder działa jako część każdego wywołania Single, Browser i Auto. Platforma wybiera działający węzeł wyjściowy dla każdego requestu, zwraca w response'ie jego nieprzejrzyste id (na poziomie r.proxy top-level w przypadku Single/Browser lub r.session.proxy na poziomie Auto), a w kolejnych requestach używasz tego id w sytuacji, gdy chcesz pozostać przy tym samym węźle wyjściowym. Twój crawler nie ma swojego własnego algorytmu pozycjonowania proxy. (Napisaliśmy o tym, dlaczego wielkość puli przestała być różnikiem w tekście pt. Why Proxy Pool Size Stopped Mattering in 2026).
Jeśli chodzi o to, "czy faktycznie zadziałało", w każdym requeście dostępny jest blok validate. Deklarujesz co stanowi sukces: akceptowane kody statusu, wymagane wartości w headerach, ciągi znaków w body, które muszą lub nie mogą się pojawić. FourA zwraca jeden z siedmiu wyników, a tylko wynik success podlega rozliczeniu. Jeśli wywołanie zakończy się kodem 200, lecz nie spełni ono Twoich reguł dla contentu, zostanie mu nadany status application_fail, a wynik nigdy nie trafi do datasetu.
Oto jak wygląda call do recrawlowania doc portalu wymagającego renderu JS. Pozwalamy Auto decydować, dobiera właściwy produkt (Single, Proxy albo Browser), radzi sobie z ochroną przed botami i wraca do potrójnego trybu sesji, aby kolejny recrawl pozostał na tym samym węźle wyjściowym:
import requests
r = requests.post(
"https://api.foura.ai/api/auto",
headers={"Authorization": "Bearer pk_live_..."},
json={
"url": "https://docs.example.com/changelog",
"validate": {
"status": {"accept": [200]},
"data": {"accept": ["<article"], "fail": ["captcha", "Just a moment"]},
},
},
).json()
# r["data"] or r["body"] — rendered content (Auto runs the right sub-product per host;
# Single populates "data", Browser populates "body")
# r["session"] — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["session"]["proxy"] back as `ignoreProxies: [<id>]` to avoid
# the same exit, or via /api/single with `proxy: <id>` to stick to it.
Jeśli cel wyświetli blokadę Cloudflare interstitial, reguła validate.data.fail to wyłapie. Zużycie po Twojej stronie jest w takiej sytuacji opisywane jako application_fail. Nie płacisz za to, a kod do ingestu wie, że należy spróbować z użyciem innego proxy, zamiast dodawać do embeddingu strony pt. "Just a moment...".
W przypadku szerszego korpusu cały ten proces wpinasz do istniejącej job queue. Zespoły, z którymi rozmawialiśmy uruchamiają dzienne różnice względem wcześniejszego crawlu, dołączają za pomocą embeddingu jedynie dokumenty poddane modyfikacji, na koniec zaś odświeżają 500-źródłowe korpusy w zaledwie kilka godzin wall-clock time. Zostajesz ze swoim job queue. Proxy churn, podejmowanie decyzji co do renderingu, wyrok o tym, czy operacja była udana to nasza broszka.
Rezultaty
Oto jak wygląda obieg świeżości, gdy infrastruktura nie będzie już wąskim gardłem (przykładowy scenariusz oparty na trendach obserwowanych przez nas u zespołów związanych z pionową sztuczną inteligencją):
- Co tydzień udaje się przetworzyć powtórnie 500 źródłowych adresów URL w przeciwieństwie do jednorazowego przetwarzania 200 przy uruchomieniu.
- Czas pracy inżynierów nad spraperem to niecałe 2 godziny tygodniowo, a więc zauważalnie mniejszy niż 1, 2 dni.
- Czas utraty świeżości danych Retrieval: 5-7 dni, co nie stanowiło do tej pory wymogu bezwzględnego
- Odsetek "śmieci" w systemach Vector Store wynosi prawie zero, chociażby ze względu na odrzucenie komunikatów zapór typu Cloudflare i stron-pułapek (tzw. tarpit), co następuje przy użyciu mechanizmów warstwy
validate, na długo przed przekazaniem odpowiednich wyników do modelu wprowadzania (embedowania) danych. - Koszt na źródło w przewidywalnej dla nas wysokości, jako że dane wyciągnięte ze strony przy błędach sieciowych typu crawl, po prostu nie występują na fakturze.
Tu wcale nie chodzi o odnalezienie cudu, lecz w tym wypadku chodzi bardziej o nudę. To ta cecha jest wymagana wobec produkcyjnej AI. (Bliższe dane o miejscu, gdzie matma dla hostowanej opcji ekstrakcji na silniku LLM kończy swoją karierę, znajdziesz zresztą m.in. tutaj When LLM Extraction Stops Paying for Itself).
Kluczowy wniosek
Większość zespołów budujących wertykalną sztuczną inteligencję uważa, że ich jedynym atutem pozostaje prompt, właściwy dobór modelu lub ewentualnie sprawny algorytm retrievalu. Tak nie jest. Zaletą okazuje się przede wszystkim obieg informacji celem poprawy ogólnego wskaźnika świeżości, a w tym wypadku to m.in. na co dzień niezauważalna dla przeciętnego użytkownika infrastruktura informatyczna utrzymuje Twoją bazę wiedzy w odpowiedniej "uczciwości" z upływem każdego nowego tygodnia.
Sukces rynkowy oparty o wykorzystanie sztucznej inteligencji pionowej do 2026 r. w przypadku poszczególnych zespołów zależał będzie nie od tego jak przebiegł proces zastosowania sprytnych promptów. O ich losach rynkowych ostatecznie zdecyduje wyeliminowanie zjawiska zauważalności momentu uaktualniania ze strony z poziomu końcowych odbiorców usług.