Wyzwanie
Wszystkie startupy z branży wertykalnego AI uderzają w tę samą ścianę około drugiego miesiąca. Wypuszczają copilota do obsługi klienta, asystenta badań prawnych lub bota ds. zgodności z przepisami. Pierwsze demo zdobywa klientów. Potem dane się starzeją, a odpowiedzi zaczynają rozmijać się z rzeczywistością.
Obserwowaliśmy zespoły, które dopracowały stronę AI, ale warstwę danych potraktowały po macoszemu. Pipeline do ingestii to pojedynczy skrypt w Pythonie uruchamiany na czyimś laptopie. Scrapuje 200 źródłowych adresów URL jeden raz, wrzuca czysty Markdown do bazy wektorowej i wszyscy świętują. Sześć tygodni później połowa odpowiedzi cytuje usunięte strony, przestarzałe API lub funkcje produktu wydane w marcu i zmienione w maju.
Rozwiązanie wydaje się proste: cotygodniowy recrawl każdego źródła. Rzeczywistość jest bardziej skomplikowana. Do 2026 roku około 60% renomowanych witryn blokuje crawlery AI (wzrost z 23% pod koniec 2023 roku), a zabezpieczenia nie ograniczają się już do prostego sprawdzania User-Agent. Analizują zachowanie sesji, rytm zapytań i sygnały na poziomie handshake'a. Prosty skrypt, który działał w styczniu, w marcu po cichu zwraca puste strony.
Co gorsza, niektóre witryny serwują teraz treści typu tarpit (bełkot generowany łańcuchami Markowa, który wygląda jak prawdziwy tekst), dopóki nie zatruje to twoich embeddingów. W rezultacie inżynierowie spędzają pół tygodnia na łataniu scrapera zamiast na rozwijaniu produktu. Jakość retrievalu spada, klienci to zauważają, a zespół zatrudniony do budowy AI staje się serwisem do utrzymywania scraperów.
Podejście
Problem ponownego crawlingu sprowadza się do trzech konkretnych decyzji, które muszą zapadać przy każdym żądaniu:
- Renderować czy nie? Większość portali z dokumentacją serwuje czysty HTML. Coraz większa część (wszystko oparte na Next.js lub z renderowaniem po stronie klienta) wymaga pełnego renderowania w przeglądarce, aby zwrócić użyteczną treść.
- Które proxy? Residential, datacenter, mobile, z geolokalizacją, przypisane do konkretnego ISP. Właściwy wybór zależy od celu.
- Czy to naprawdę zadziałało? Kod 200 z pustym body lub stroną weryfikacyjną to udane żądanie HTTP, ale nieudany crawl.
Platforma taka jak FourA traktuje każdy z tych problemów priorytetowo.
W kwestii renderowania wywołujesz Single dla tanich, szybkich przypadków oraz Browser dla celów mocno opartych na JS. Struktura wywołania jest identyczna, więc kod ingestii rozgałęzia się raz na podstawie flagi źródła, zamiast obsługiwać setki specyficznych dla danej witryny wyjątków.
W przypadku wyboru proxy funkcja Proxy Finder działa w ramach każdego wywołania Single, Browser i Auto. Platforma wybiera działający punkt wyjścia dla każdego żądania, zwraca jego identyfikator w odpowiedzi (na poziomie głównym w r.proxy w Single/Browser lub r.session.proxy w Auto), a ty używasz go ponownie w kolejnych wywołaniach, gdy musisz zachować ten sam punkt wyjścia. Twój crawler nie musi posiadać własnego algorytmu rankingu proxy. (Napisaliśmy o tym, dlaczego wielkość puli przestała mieć znaczenie, w Dlaczego rozmiar puli proxy przestał mieć znaczenie w 2026 roku.)
A odpowiadając na pytanie, „czy to rzeczywiście zadziałało”: każde request obsługuje blok validate. Definiujesz, co oznacza sukces: akceptowane kody statusu, wymagane wartości header, ciągi znaków w body, które muszą lub nie mogą się pojawić. FourA zwraca jeden z siedmiu wyników, a rozliczeniu podlega wyłącznie success. Kod 200, który nie spełnia Twoich reguł dotyczących treści, otrzymuje status application_fail i nigdy nie trafia do Twojego zbioru danych.
Oto jak wygląda wywołanie ponownego pobierania dla portalu z dokumentacją, który wymaga renderowania JS. Pozwalamy, aby tryb Auto zajął się orkiestracją: dobiera odpowiedni produkt (Single, Proxy lub Browser), radzi sobie z zabezpieczeniami przed botami i zwraca trójkę sesyjną, dzięki czemu kolejne pobranie może korzystać z tego samego punktu wyjścia:
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 zwróci stronę pośrednią Cloudflare, reguła validate.data.fail ją wychwyci. Wynik przypisany do Twojego zużycia to application_fail. Nie płacisz za to, a Twój kod pobierający wie, że należy ponowić próbę z innym proxy, zamiast przekazywać stronę "Just a moment..." do embeddingów.
W przypadku szerszego korpusu danych ten sam wzorzec można opakować w istniejącą kolejkę zadań. Zespoły, z którymi rozmawialiśmy, uruchamiają nocne diffy względem poprzedniego crawlowania, generują embeddingi tylko dla dokumentów, które faktycznie uległy zmianie, i odświeżają korpusy z 500 źródeł w ciągu zaledwie kilku godzin czasu rzeczywistego. Kolejka zadań pozostaje po Twojej stronie. Rotacja proxy, decyzja o renderowaniu i ocena sukcesu należą do nas.
Wyniki
Jak wygląda pętla świeżości danych, gdy infrastruktura przestaje być wąskim gardłem (przykładowy scenariusz oparty na wzorcach, które obserwujemy w zespołach vertical AI):
- 500 źródłowych adresów URL crawlowanych co tydzień, zamiast jednorazowego pobrania 200 adresów URL przy wdrożeniu
- Czas pracy inżynierów nad scraperem: poniżej 2 godzin tygodniowo, spadek z 1-2 dni
- Okno nieaktualności danych (staleness window): 5-7 dni, zamiast nieograniczonego
- Odsetek niepoprawnych danych w bazie wektorowej bliski zeru, ponieważ strony pośrednie Cloudflare i tarpity są odrzucane na warstwie
validate, zanim dotrą do Twojego modelu embeddingów - Przewidywalny koszt na źródło, ponieważ nieudane próby crawlowania nie pojawiają się na rachunku
Nie chodzi o to, że którekolwiek z tych rozwiązań to magia. Chodzi o to, że są powtarzalne i stabilne. A właśnie takiej przewidywalności wymaga produkcyjne AI. (Więcej informacji o tym, kiedy kalkulacja kosztów hostowanej ekstrakcji LLM przestaje się spinać, znajdziesz w artykule When LLM Extraction Stops Paying for Itself.)
Podsumowanie
Większość zespołów budujących rozwiązania vertical AI uważa, że przewagę konkurencyjną stanowi prompt, wybór modelu lub algorytm wyszukiwania. Tak nie jest. Przewagę stanowi pętla świeżości danych: niewdzięczna infrastruktura, która dba o aktualność bazy wiedzy tydzień po tygodniu.
Zespoły, które wygrają w segmencie vertical AI do 2026 roku, nie będą tymi z najbardziej pomysłowymi promptami. Będą to te, których użytkownicy nigdy nie zauważą, że dane są aktualne, bo po prostu zawsze takie będą.