Wann sich LLM-Extraction nicht mehr rechnet

Wann sich LLM-Extraction nicht mehr rechnet

Firecrawl berechnet 1 Credit für das Scraping einer Seite und 5 Credits, um strukturierte Felder aus derselben Seite zu extrahieren (Firecrawl-Preise, 2026). Das ist ein 5-facher Aufschlag für dasselbe HTML, das durch ein Modell geschickt wird.

Das Versprechen klingt gut: Beschreibe, was du willst, erhalte JSON zurück, keine Selektoren, die du warten musst. Bei instabilen Layouts und einmaligen Targets rechtfertigt das den Aufschlag. Aber für eine Produktions-Pipeline, die täglich 500k Produktseiten von denselben fünf Händlern abruft, lohnt es sich nicht.

Wir haben erlebt, wie Teams standardmäßig auf LLM-Extraction gesetzt haben, im Rechnungsmonat aufgewacht sind und nach einem Ausweg gesucht haben. Die Lösung ist meistens nicht, LLMs komplett aufzugeben. Es geht darum, sie an der richtigen Stelle in der Pipeline einzusetzen.

Die Rechnung wird schnell ungemütlich

Nehmen wir Firecrawl am günstigen Ende. Scrape plus AI-Extract kostet 6 Credits pro Seite ohne Crawling, 7 Credits mit Crawling (ScrapeGraphAI-Analyse, 2026). 100k Seiten am Tag im Growth-Tarif kosten rund 21.000 $ im Monat, noch vor Retries und bevor du auch nur einen einzigen Proxy bezahlt hast.

Betreibst du deine eigene LLM-Pipeline, verschiebt sich die Rechnung, wird aber nicht kleiner. GPT-4o kostet 2,50 $ pro Million Input-Token und 10 $ pro Million Output-Token (PricePerToken, 2026). Eine Produktseite nach der Markdown-Konvertierung benötigt 4k bis 8k Input-Token. Sagen wir 6k Input, 200 Output für ein JSON-Blob. Bei 100k Seiten am Tag sind das 360 $ täglich, 11.000 $ monatlich für eine Aufgabe, die CSS-Selektoren nach einmaliger Einrichtung kostenlos erledigen.

Das ist das günstige Modell. Wechselst du zu Claude Sonnet 4.6 (3 $ Input, 15 $ Output), verdoppelt sich die Rechnung (PE Collective, 2026). Nutzt du ein Reasoning-Modell, kommt ein 3- bis 10-facher Aufschlag hinzu, je nachdem, wie viel es vor der Antwort nachdenkt.

Nichts davon berücksichtigt Fehler. Eine Halluzinationsrate von 3 bis 5 % klingt harmlos, bis du nachrechnest. Bei 100k Seiten am Tag fließen täglich 3.000 bis 5.000 fehlerhafte Datensätze in dein Warehouse, die exakt wie die korrekten aussehen, weil das Modell sie selbstbewusst ausgegeben hat. Wie DataHen es ausdrückt: "Es ist nicht so, dass sich die KI manchmal irrt. Es ist so, dass sie sich selbstbewusst irrt." (DataHen, 2026).

Was erfahrene Teams tatsächlich tun

Liest du die Dokumentation von Anbietern, die Scraper tatsächlich in der Produktion betreiben, zeigt sich ein konsistentes Muster: Hybrid-Ansätze. Nutze das LLM, um die Seite einmalig zu verstehen, und verwende danach günstigen, deterministischen Code für alles Weitere.

Zyte bringt es in der eigenen Dokumentation auf den Punkt: "Anstatt ein LLM pro Seite zu verwenden, nutze dein LLM, um CSS-Selektoren für die gewünschten Felder aus dem rohen HTML einer ersten Seite zu generieren, und verwende diese Selektoren, um alle anderen Seiten zu parsen." (Zyte-LLM-Guide, 2026). Apify empfiehlt denselben Ablauf in ihrem Guide für 2026: Versuche es zuerst mit CSS-Selektoren und weiche auf das LLM aus, wenn diese fehlschlagen (Apify-Guide 2026). Ein Bericht der DEV Community über ein Produktions-Rollout beschreibt die Architektur exakt: Der gecachte Selektor-Pfad kostet nichts, das LLM springt nur an, wenn die Validierung fehlschlägt (DEV.to, 2026).

Die Aufteilung in der Produktion sieht also so aus:

• Das LLM bootstrappt den Selektor (ein Aufruf pro Target, Bruchteile eines Cents)
• Der Selektor läuft auf jeder Seite (kostenlos)
• Ein Validator (meist ein Regex oder ein Presence-Check) erkennt Abweichungen
• Abweichungen triggern ein erneutes Bootstrapping, Wochen oder Monate später

Die Kosten pro Seite sinken von ca. 0,005 $ auf weit unter 0,0001 $. Die Qualität steigt, weil deterministisches Parsen nicht halluziniert. Und du verbrauchst Token für Aufgaben, in denen LLMs wirklich gut sind: das Erkennen neuer Strukturen, statt bereits kartierte Strukturen nachzuplappern.

Wo sich LLMs trotzdem bezahlt machen

Dies ist kein Anti-LLM-Artikel. Es gibt viele Extraktionsaufgaben, bei denen das Modell genau das richtige Werkzeug ist und die Credit-Rechnung aufgeht:

• Instabile Layouts, die sich wöchentlich ändern. Selektoren, die jeden Dienstag brechen, kosten mehr Entwicklungszeit, als die LLM-Extraction an Token kostet. Lass das Modell laufen.
• Long-Tail-Targets, die du nie wieder besuchst. Es lohnt sich nicht, einen Selektor zu schreiben. Lass das Modell laufen.
• Unstrukturierte Inhalte, bei denen der Output selbst eine Zusammenfassung ist. Stellenbeschreibungen zu Skills, Artikel zu Behauptungen, Reviews zu Sentiment. Selektoren helfen hier nicht weiter. Lass das Modell laufen.
• Seiten mit optionalen Feldern, die über verschiedene Layout-Varianten verstreut sind. Ein einziges Template mit zwanzig bedingten Renderings ist genau der Fall, in dem LLMs Regex-Ketten schlagen.

Schau dir deine Pipeline an. Sortiere die Targets nach Volumen. Die Top 20 % nach Request-Anzahl haben fast immer eine stabile Struktur (deshalb sind sie die Top 20 % (du hast sie gezielt integriert)). Sie sind Kandidaten für Selektoren. Der Long-Tail ist der Ort, an den das Modell gehört.

Was das für deinen Stack bedeutet

Das Versprechen der Anbieter im Jahr 2026 will dich dazu bringen, standardmäßig auf LLM-Extraction zu setzen. Die Credit-Preise lassen das bei kleinen Projekten sinnvoll erscheinen. Sobald du skalierst, ist es damit vorbei, genauso wie die Größe des Proxy-Pools keinen echten Erfolg mehr vorhersagte, als das zugrunde liegende Signal wegbrach.

Drei Erkenntnisse für Teams, die echte Pipelines bauen:

1. Trenne das Abrufen vom Parsen. Wenn dein Scraping-Anbieter nur LLM-extrahiertes JSON zurückgibt, kannst du nicht auf Selektoren ausweichen, wenn die Rechnung kommt. Wähle eine Infrastruktur, die dir HTML liefert und dich den Extraktionsweg selbst bestimmen lässt.
2. Cache aggressiv auf Selektor-Ebene. Generierte Selektoren sind über Tausende von Seiten hinweg wiederverwendbar. Der teure Aufruf ist die Generierung, nicht die Nutzung.
3. Messe die Kosten pro Datensatz, nicht pro Seite. Eine Pipeline, die 0,001 $/Seite kostet, aber 5 % fehlerhafte Datensätze liefert, ist teurer als eine, die 0,005 $/Seite kostet und saubere Daten liefert. Speicherung, nachgelagerte Abfragen und die spätere Bereinigung fallen alle ins Gewicht.

Wähle die langweilige Hälfte

Der Standardweg über LLM-Extraction ist perfekt für eine Demo, aber falsch für die Produktion. Die Teams, die es richtig machen, betrachten LLMs als Werkzeug, um eine Seite zu verstehen, nicht als Werkzeug, um eine Seite zu lesen. Langweiliger, deterministischer Code gewinnt auch 2026 das Volumenspiel; das Modell gewinnt das Neuheitsspiel. Beide gehören in den Stack.

Bei FourA geben Single und Browser die rohe Response (HTML, gerendertes DOM, Header, Body) zurückgibt und hören dort auf. Ob du mit Selektoren parst, es an ein Modell sendest oder beides tust, ist deine Entscheidung. Wir erheben keinen Credit-Multiplikator für eine Extraktion, die wir nicht durchgeführt haben.