← Wszystkie wpisy
Zastosowanie 5 min czytania

Problem recrawlu: Jak dbać o świeżość pipeline'ów RAG

Baza wiedzy Twojego RAG starzeje się już w tydzień po wdrożeniu. Oto jak zespoły ponownie pobierają dane z setek branżowych źródeł bez rozbijania budżetu inżynieryjnego.

ragai-trainingdata-collectionvertical-aiuse-case

Wyzwanie

Startupy tworzące pionowe AI (vertical AI) zderzają się z tą samą ścianą około drugiego miesiąca. Wdrażają copilota do wsparcia, asystenta do analizy prawnej lub bota ds. zgodności (compliance). Pierwsze demo zdobywa klientów. Potem dane się starzeją, a odpowiedzi zaczynają rozjeżdżać się z rzeczywistością.

Widzieliśmy zespoły, które dopracowały część AI do perfekcji, traktując kwestię danych po macoszemu. Pipeline do ingestion to pojedynczy skrypt w Pythonie uruchamiany na czyimś laptopie. Pobiera dane z 200 adresów URL 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, które wdrożono w marcu i zmieniono w maju.

Rozwiązanie wydaje się proste: robić recrawl każdego źródła co tydzień. Rzeczywistość wygląda gorzej. Do 2026 roku około 60% renomowanych witryn blokuje boty AI (wzrost z 23% pod koniec 2023 roku), a zabezpieczenia to już nie są proste weryfikacje User-Agent. Analizują zachowanie sesji, rytm requestów i sygnały na poziomie handshake'u. Naiwny skrypt, który działał w styczniu, w marcu po cichu zwraca puste strony.

Co gorsza, niektóre witryny serwują teraz zawartość typu tarpit (bełkot generowany łańcuchami Markowa, który wygląda jak prawdziwy tekst), dopóki nie zatruje on Twoich osadzeń. W efekcie inżynierowie spędzają pół tygodnia na łataniu scrapera zamiast rozwijać produkt. Jakość wyszukiwania (retrieval) spada, klienci to zauważają, a zespół zatrudniony do budowy AI zamienia się w serwis utrzymania scraperów.

Podejście

Problem recrawlu sprowadza się do trzech konkretnych decyzji, które muszą zapadać przy każdym requeście:

  1. Renderować czy nie? Większość portali z dokumentacją serwuje czysty HTML. Coraz większa część (wszystko zbudowane na Next.js, wszystko z renderowaniem po stronie klienta) wymaga pełnego renderowania w przeglądarce, aby zwrócić przydatną treść.
  2. Które proxy? Residential, datacenter, mobile, z określoną geolokalizacją, specyficzne dla ISP. Właściwy wybór zależy od celu.
  3. Czy to naprawdę zadziałało? Kod 200 z pustym body lub strona HTML z CAPTCHA to udany request HTTP, ale nieudany crawl.

Platforma taka jak FourA traktuje każdą z tych kwestii priorytetowo.

W przypadku decyzji o renderowaniu wywołujesz Single dla tanich i szybkich przypadków, a Browser dla celów mocno opartych na JS. Body wywołania ma taki sam kształt, więc Twój kod ingestion rozgałęzia się tylko raz na podstawie flagi źródła, zamiast obsługiwać setki specyficznych dla danej witryny wyjątków.

Przy wyborze proxy, Proxy Finder działa jako część każdego wywołania Single, Browser i Auto. Platforma wybiera działający exit dla każdego requestu, zwraca jego identyfikator w response w polu meta.proxy, a Ty używasz go ponownie przy kolejnych wywołaniach, gdy musisz trzymać się tego samego exitu. Twój crawler nie musi mieć własnego algorytmu rankingu proxy. (Pisaliśmy o tym, dlaczego wielkość puli przestała mieć znaczenie w artykule Dlaczego wielkość puli proxy przestała mieć znaczenie w 2026 roku).

A jeśli chodzi o pytanie „czy to naprawdę zadziałało”, każdy request obsługuje blok validate. Deklarujesz, co uznajesz za sukces: akceptowane kody statusu, wymagane wartości headerów, ciągi znaków w body, które muszą lub nie mogą się pojawić. FourA zwraca jeden z siedmiu wyników, a rozliczana jest tylko wartość success. Kod 200, który nie spełnia Twoich reguł zawartości, otrzymuje status application_fail i nigdy nie trafia do Twojego zbioru danych.

Oto jak wygląda wywołanie recrawlu dla portalu z dokumentacją wymagającego renderowania JS. Pozwalamy, aby Auto zajęło się orkiestracją. Wybiera ono odpowiedni produkt (Single, Proxy lub Browser), radzi sobie z zabezpieczeniami przed botami i zwraca trójkę sesyjną, dzięki czemu kolejny recrawl może korzystać z tego samego exitu:

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"]    — rendered body
# r["meta"]    — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["meta"]["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 stronę przejściową Cloudflare, reguła validate.data.fail to wychwyci. Wynik przypisany do Twojego zużycia to application_fail. Nie płacisz za to, a Twój kod ingestion wie, że należy spróbować ponownie z innym proxy, zamiast karmić model osadzeń stroną „Just a moment...”.

Dla szerszego zestawu danych opakowujesz ten sam schemat w istniejącą kolejke zadań. Zespoły, z którymi rozmawialiśmy, uruchamiają co noc porównania (diffy) z poprzednim crawlem, generują nowe osadzenia tylko dla dokumentów, które faktycznie się zmieniły, i odświeżają zbiory 500 źródeł w zaledwie kilka 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, gdy infrastruktura przestaje być wąskim gardłem (przykładowy scenariusz oparty na wzorcach, które widzimy w zespołach tworzących pionowe AI):

  • 500 adresów URL źródeł poddawanych recrawlowi co tydzień, zamiast jednorazowego pobrania 200 adresów URL przy wdrożeniu
  • Czas inżynieryjny poświęcony na scraper: poniżej 2 godzin tygodniowo, spadek z 1-2 dni
  • Okno nieaktualności danych (retrieval staleness): 5-7 dni, zamiast nieograniczonego
  • Ilość śmieci w bazie wektorowej bliska zeru, ponieważ strony przejściowe Cloudflare i strony typu tarpit są odrzucane na warstwie validate, zanim trafią do Twojego modelu osadzeń
  • Przewidywalny koszt na źródło, ponieważ nieudane crawle nie pojawiają się na rachunku

Nie chodzi o to, że któreś z tych rozwiązań to magia. Chodzi o to, że są nudne. A nudy właśnie potrzebuje produkcyjne AI. (Więcej o tym, kiedy kalkulacja przestaje się opłacać przy ekstrakcji za pomocą hostowanych LLM, przeczytasz w artykule Kiedy ekstrakcja LLM przestaje się opłacać).

Kluczowe wnioski

Większość zespołów budujących pionowe AI uważa, że ich przewagą konkurencyjną (moat) jest prompt, wybór modelu lub algorytm wyszukiwania. Tak nie jest. Tą przewagą jest pętla świeżości: mało efektowna infrastruktura, która tydzień po tygodniu dba o rzetelność bazy wiedzy.

Zespoły, które wygrają w obszarze pionowego AI do 2026 roku, to nie te z najsprytniejszymi promptami. Będą to te, których użytkownicy nigdy nie zauważą, że dane są aktualne, ponieważ będą one takie zawsze.