← Alle Beiträge
Use Case 5 Min. Lesezeit

Das Recrawl-Problem: RAG-Pipelines aktuell halten

Deine RAG-Wissensdatenbank veraltet in der Woche, in der du sie veröffentlichst. So recrawlen Teams Hunderte von vertikalen Quellen, ohne ihr Entwicklungsbudget zu sprengen.

ragai-trainingdata-collectionvertical-aiuse-case

Die Herausforderung

Vertikale KI-Startups stoßen alle um den zweiten Monat herum an dieselbe Grenze. Sie veröffentlichen einen Support-Copilot, einen Assistenten für Rechtsrecherchen oder einen Compliance-Bot. Die erste Demo gewinnt Kunden. Dann veralten die Daten und die Antworten weichen langsam von der Realität ab.

Wir haben beobachtet, wie Teams die KI-Seite sauber aufbauen und die Datenseite stiefmütterlich behandeln. Die Ingestion-Pipeline ist ein einziges Python-Script, das auf dem Laptop von irgendwem läuft. Es scrapt einmalig 200 Quell-URLs, lädt sauberes Markdown in einen Vector-Store und alle feiern. Sechs Wochen später zitiert die Hälfte der Antworten gelöschte Seiten, veraltete APIs oder Produktfeatures, die im März und dann im Mai noch mal veröffentlicht wurden.

Die Lösung klingt einfach: Jede Quelle wöchentlich neu crawlen. Die Realität ist ungemütlicher. Bis 2026 blockieren rund 60 % der seriösen Websites KI-Crawler (gegenüber 23 % Ende 2023), und die Schutzmaßnahmen sind keine simplen User-Agent-Prüfungen mehr. Sie analysieren das Sitzungsverhalten, den Request-Rhythmus und Signale auf Handshake-Ebene. Ein naives Script, das im Januar noch funktionierte, liefert im März stillschweigend leere Seiten zurück.

Schlimmer noch: Einige Websites liefern mittlerweile Tarpit-Inhalte aus (durch Markov-Ketten generiertes Kauderwelsch, das sich wie echte Prosa liest), bis diese deine Embeddings vergiften. Deine Engineers verbringen also die Hälfte der Woche damit, den Scraper zu flicken, anstatt das Produkt weiterzuentwickeln. Die Retrieval-Qualität sinkt, Kunden bemerken es und das Team, das du für den Aufbau der KI eingestellt hast, wird zu einer Scraper-Wartungstruppe.

Der Ansatz

Das Recrawl-Problem teilt sich in drei konkrete Entscheidungen auf, die bei jedem Request getroffen werden müssen:

  1. Rendern oder nicht? Die meisten Dokumentationsportale liefern sauberes HTML. Ein wachsender Anteil (alles, was auf Next.js basiert, alles mit clientseitigem Rendering) benötigt vollständiges Browser-Rendering, um brauchbare Inhalte zu liefern.
  2. Welcher Proxy? Residential, Datacenter, Mobile, Geo-pinned, ISP-spezifisch. Die richtige Wahl ändert sich je nach Ziel.
  3. Hat es tatsächlich funktioniert? Ein 200-Statuscode mit leerem Body oder eine CAPTCHA-HTML-Seite ist ein erfolgreicher HTTP-Request, aber ein fehlgeschlagener Crawl.

Eine Plattform wie FourA behandelt jeden dieser Punkte als First-Class-Concern.

Für die Render-Entscheidung rufst du Single für den günstigen, schnellen Fall auf und Browser für JS-lastige Ziele. Der Body des Aufrufs hat dieselbe Struktur, sodass sich dein Ingestion-Code nur einmal über ein Flag pro Quelle verzweigt, anstatt hunderte von sitespezifischen Eigenheiten mitzuschleppen.

Für die Proxy-Auswahl läuft Proxy Finder als Teil jedes Single-, Browser- und Auto-Aufrufs. Die Plattform wählt pro Request einen funktionierenden Exit, gibt dessen opake ID in der Response unter meta.proxy zurück und du verwendest diese ID bei Folgeaufrufen wieder, wenn du denselben Exit beibehalten willst. Dein Crawler benötigt keinen eigenen Proxy-Ranking-Algorithmus. (Wir haben in Warum die Proxy-Pool-Größe im Jahr 2026 keine Rolle mehr spielt darüber geschrieben, warum die Pool-Größe kein Unterscheidungsmerkmal mehr ist.)

Und für die Frage „Hat es tatsächlich funktioniert?“ unterstützt jeder Request einen validate-Block. Du definierst, was als Erfolg gilt: akzeptierte Statuscodes, erforderliche Header-Werte, Body-Strings, die vorkommen müssen oder nicht vorkommen dürfen. FourA gibt eines von sieben Ergebnissen zurück, und nur success ist kostenpflichtig. Ein 200-Statuscode, der deine Content-Regeln verfehlt, wird als application_fail markiert und gelangt nie in deinen Datensatz.

So sieht ein Recrawl-Aufruf für ein Dokumentationsportal aus, das ein JS-Rendering benötigt. Wir lassen Auto die Orchestrierung übernehmen. Es wählt das richtige Produkt (Single, Proxy oder Browser), kümmert sich um die Bot-Abwehr und gibt das Session-Triple zurück, damit der nächste Recrawl denselben Exit nutzen kann:

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.

Wenn das Ziel eine Cloudflare-Interstitiale vorschaltet, greift die Regel validate.data.fail. Das für deine Nutzung erfasste Ergebnis lautet application_fail. Du bezahlst nicht dafür und dein Ingestion-Code weiß, dass er es mit einem anderen Proxy erneut versuchen muss, anstatt eine „Just a moment...“-Seite in die Embeddings einzuspeisen.

Für den größeren Datenbestand bettest du dasselbe Pattern in deine bestehende Job-Queue ein. Teams, mit denen wir gesprochen haben, führen nächtliche Diffs gegen den vorherigen Crawl aus, erstellen nur für die tatsächlich geänderten Dokumente neue Embeddings und aktualisieren Datenbestände von 500 Quellen in wenigen Stunden realer Laufzeit. Die Job-Queue bleibt in deiner Hand. Der Proxy-Wechsel, die Render-Entscheidung und die Erfolgsbewertung sind unsere Aufgabe.

Ergebnisse

Wie der Aktualitäts-Loop aussieht, sobald die Infrastruktur kein Flaschenhals mehr ist (beispielhaftes Szenario basierend auf Mustern, die wir bei vertikalen KI-Teams beobachten):

  • 500 Quell-URLs wöchentlich neu gecrawlt statt eines einmaligen Crawls von 200 URLs beim Launch
  • Engineering-Zeit für den Scraper: unter 2 Stunden pro Woche statt zuvor 1 bis 2 Tage
  • Retrieval-Veraltungsfenster: 5 bis 7 Tage statt unbegrenzt
  • Müllquote im Vector-Store nahe Null, weil Cloudflare-Interstitials und Tarpit-Seiten auf der validate-Ebene abgewiesen werden, bevor sie dein Embedding-Modell erreichen
  • Kosten pro Quelle kalkulierbar, weil fehlgeschlagene Crawls nicht in der Abrechnung auftauchen

Es geht nicht darum, dass das alles Magie ist. Es geht darum, dass es langweilig ist. Und langweilig ist genau das, was produktive KI braucht. (Mehr dazu, ab wann sich die Rechnung bei gehosteter LLM-Extraktion nicht mehr trägt, findest du in Wenn sich LLM-Extraktion im großen Stil nicht mehr auszahlt.)

Wichtigste Erkenntnis

Die meisten Teams, die vertikale KI aufbauen, denken, der Wettbewerbsvorteil sei der Prompt, die Modellwahl oder der Retrieval-Algorithmus. Das ist er nicht. Der Wettbewerbsvorteil ist der Aktualitäts-Loop: die unglamouröse Infrastruktur, die die Wissensdatenbank Woche für Woche auf dem neuesten Stand hält.

Die Teams, die sich bis 2026 im Bereich der vertikalen KI durchsetzen, werden nicht diejenigen mit den cleversten Prompts sein. Es werden diejenigen sein, deren Nutzer gar nicht erst bemerken, dass die Daten aktuell sind, weil sie es einfach immer sind.