CyberScraper 2077: LLM-Extraktion mit Streamlit-Oberfläche
A Powerful web scraper powered by LLM | OpenAI, Gemini & Ollama
Auf einen Blick
- Was ist das?
- CyberScraper 2077 kombiniert Playwright, eine Streamlit-GUI und wahlweise OpenAI, Gemini, LiteLLM oder Ollama, um Webseiten in strukturierte Daten zu verwandeln. Der Ansatz senkt den Aufwand für wechselnde Seitengerüste, erkauft sich das aber mit Modellabhängigkeit und einer Captcha-Ausnahme, die im Docker-Betrieb nicht greift.
- Für wen ist es gedacht?
- Sinnvoll ist CyberScraper 2077 für Teams, die unregelmäßig wechselnde Seiten auswerten und dafür keine eigenen Extraktionsregeln pflegen wollen, sowie für Anwender, die ein lokales Modell über Ollama betreiben.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 5 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem die LLM-Extraktion hier löst
Klassische Scraper brechen, sobald ein Betreiber die DOM-Struktur ändert. Selektoren wie div.product-price müssen nach jedem Redesign nachgezogen werden, und bei Seiten mit uneinheitlichem Aufbau sammelt sich schnell eine Regelbasis an, die niemand mehr überblickt. CyberScraper 2077 setzt an dieser Stelle an: Statt CSS-Pfade zu pflegen, liest ein Sprachmodell den Seiteninhalt und entscheidet, welche Felder relevant sind. Die README beschreibt das als intelligentes Verstehen und Parsen von Webinhalten.
Die Zielgruppe ist entsprechend gemischt. Genannt werden Datenanalysten und Anwender, die Informationen aus dem Web ziehen wollen, ohne für jede Quelle einen eigenen Parser zu schreiben. Dass die Oberfläche auf Streamlit basiert, passt zu diesem Publikum: Wer eine Weboberfläche bedienen kann, kommt hier ohne Python-Kenntnisse aus. Für Ingenieure, die eine Pipeline mit festen Schemata und reproduzierbaren Ergebnissen bauen, ist das dagegen ein anderes Werkzeug als ein Framework wie Scrapy.
Playwright, Caching und die Modellschicht
Der Ablauf lässt sich aus der README und der Installationsanleitung rekonstruieren. Playwright wird separat installiert und übernimmt das Laden der Seiten, also auch JavaScript-lastige Inhalte. Der gerenderte Inhalt geht an ein Sprachmodell, das die gewünschten Felder herauszieht. Erst danach greifen die Exportformate JSON, CSV, HTML, SQL und Excel.
Zwischen Abruf und Modellaufruf sitzt ein Cache. Die README nennt zwei Varianten: inhaltsbasiertes und abfragebasiertes Caching, umgesetzt mit LRU-Cache und einem eigenen Dictionary. Das ist der wirtschaftlich wichtigste Teil des Entwurfs, denn jeder Modellaufruf kostet Geld und Zeit. Wer dieselbe URL mit derselben Frage erneut auswertet, soll den Treffer aus dem Cache bekommen statt einen zweiten API-Aufruf zu bezahlen. Wie lange Einträge gültig bleiben und ob der Cache persistent ist oder nur im Prozess lebt, geht aus der README nicht hervor. Das ist eine offene Frage, die man vor dem Produktiveinsatz klären sollte.
Für die Modellwahl gibt es drei Wege. OpenAI und Gemini laufen über Umgebungsvariablen. LiteLLM wird über LITELLM_API_KEY, LITELLM_BASE_URL und LITELLM_MODELS angebunden, wobei die konfigurierten Modelle in der Seitenleiste als litellm:<model> erscheinen und die Basis-URL standardmäßig auf http://localhost:4000/v1 zeigt. Ollama deckt lokale Modelle ab.
Installation: venv, Playwright, Docker
Der Einstieg folgt dem üblichen Muster. Nach git clone und cd CyberScraper-2077 wird eine virtuelle Umgebung angelegt, danach pip install -r requirements.txt ausgeführt. Anschließend muss Playwright mit playwright install seine Browser beziehen, sonst fehlt die Rendering-Schicht. Vorausgesetzt wird Python 3.10 oder höher.
Die Schlüssel setzt man über die Umgebung. Für Linux und Mac nennt die README export OPENAI_API_KEY="your-api-key-here" und export GOOGLE_API_KEY="your-api-key-here". Wer einen LiteLLM-Proxy dazwischenschaltet, setzt zusätzlich LITELLM_BASE_URL auf die eigene Adresse statt auf den lokalen Standardwert.
Für Docker gibt es einen eigenen Weg: docker build -t cyberscraper-2077 . und danach docker run -p 8501:8501 mit den API-Schlüsseln als -e Parameter. Der Port 8501 verrät die Streamlit-Oberfläche. Windows-Nutzern empfiehlt die README ausdrücklich den Docker-Weg, weil keine separate Windows-Version gepflegt wird. Das ist eine ehrliche Ansage, schränkt aber die nutzbaren Funktionen ein, wie der nächste Abschnitt zeigt.
Captcha, Tor und die Grenzen des Entwurfs
Die README wirbt mit Captcha-Umgehung, und die Details sind wichtig: Sie funktioniert, wenn man -captcha an das Ende der URL hängt, und laut README nur nativ, nicht im Docker-Betrieb. Wer also unter Windows auf den Docker-Weg verwiesen wird, verliert genau diese Funktion. Das ist kein Randdetail, sondern betrifft die Frage, ob das Werkzeug für eine Zielseite überhaupt taugt.
Ein zweiter Punkt ist der Browser. Die Funktion Current Browser nutzt die lokale Browserinstanz, um Bot-Erkennung zu umgehen. Die README empfiehlt den Einsatz nur, wenn es nötig ist. Das ist ein sinnvoller Hinweis, denn eine ferngesteuerte lokale Sitzung ist schwerer zu reproduzieren und für Serverumgebungen ungeeignet.
Der dritte Vorbehalt steht bei Ollama und kommt vom Autor selbst: Er empfiehlt OpenAI und Gemini, weil diese Modelle Anweisungen besser befolgen. Bei quelloffenen Modellen hängt die Geschwindigkeit von der eigenen Hardware ab, und laut README kann es nötig sein, den Prompt anzupassen und zusätzliche Filter zu schreiben. Man kauft sich mit lokaler Ausführung also nicht nur Unabhängigkeit, sondern auch eigene Nacharbeit an der Extraktionsqualität.
Wann ein regelbasierter Scraper die bessere Wahl bleibt
Der naheliegende Vergleich ist Scrapy. Dessen Modell besteht aus Spiders, die Selektoren und Extraktionsregeln im Code festhalten, mit Pipelines für Bereinigung und Speicherung. Das Ergebnis ist deterministisch: Dieselbe Seite liefert dieselben Felder, und ein Fehler lässt sich auf eine Regel zurückführen. Bei CyberScraper 2077 entscheidet stattdessen das Modell, was ein Feld ist. Das macht den Einstieg schneller, aber die Ausgabe weniger vorhersagbar, und Fehler äußern sich nicht als fehlgeschlagener Selektor, sondern als plausibel aussehender, aber falscher Wert.
Wer Tausende Seiten täglich mit identischem Aufbau verarbeitet, fährt mit Scrapy günstiger und stabiler. Der LLM-Ansatz spielt seine Stärke dort aus, wo sich Strukturen häufig ändern oder wo man einmalig eine Handvoll Seiten auswerten will und dafür keinen Parser schreiben möchte. Die beiden Ansätze schließen sich nicht aus: Man kann Scrapy für die Massenverarbeitung nutzen und CyberScraper 2077 für die unregelmäßigen Quellen daneben.
Lizenz, Wartung und Betriebskosten
Der Code steht unter MIT. Das erlaubt kommerzielle Nutzung und Änderungen, verlangt aber, dass der Lizenztext und der Urheberrechtshinweis in Kopien oder wesentlichen Teilen erhalten bleiben. Das Repository enthält Sponsoring-Platzhalter für Proxy-Anbieter, die mit Rabattcodes verlinkt sind. Das ist ein Hinweis auf die Finanzierung des Projekts, sagt aber nichts über die Qualität des Codes aus. Eine rechtliche Bewertung der Lizenz für den eigenen Fall ersetzt das nicht.
Zu den Betriebskosten trägt die README wenig Konkretes bei. Es gibt keine Release-Einträge, also auch keine Versionshistorie, an der man Breaking Changes ablesen könnte. Wer das Projekt produktiv einsetzt, sollte den Stand des main-Branches selbst verfolgen. Die Modellkosten hängen vollständig vom gewählten Anbieter und der Seitenlänge ab, und der Cache ist die einzige im Material genannte Gegenmaßnahme. Ob er über Neustarts hinweg erhalten bleibt, klärt die README nicht.
Bevor man es auf eine echte Zielseite lässt
Der praktikable erste Schritt ist eine einzelne, unkritische Seite mit dem eigenen Modell und einer kleinen Feldliste. Danach vergleicht man die Ausgabe mit dem, was tatsächlich auf der Seite steht, und wiederholt den Lauf mit derselben URL, um zu sehen, ob der Cache greift. Bei Ollama lohnt sich der Test mit dem Modell, das später laufen soll, denn die README weist ausdrücklich darauf hin, dass Prompt-Anpassungen nötig werden können.
Für den Containerbetrieb gilt eine harte Grenze: Wer die Captcha-Funktion braucht, muss nativ installieren, was unter Windows laut README nicht vorgesehen ist. Und wer Tor für .onion-Adressen nutzen will, sollte prüfen, ob das im eigenen Setup mit der Modellanbindung zusammenspielt. Die README nennt automatisches Routing, geht aber nicht darauf ein, wie sich das mit einem externen LiteLLM-Proxy verhält.
Redaktionelles Fazit
Sinnvoll ist CyberScraper 2077 für Teams, die unregelmäßig wechselnde Seiten auswerten und dafür keine eigenen Extraktionsregeln pflegen wollen, sowie für Anwender, die ein lokales Modell über Ollama betreiben. Wer stabile Massenextraktion mit vorhersagbaren Kosten braucht oder Captcha-Umgehung im Container benötigt, sollte zuerst prüfen, ob der native Betrieb ohne Docker für den eigenen Fall überhaupt in Frage kommt, denn die README schließt diese Funktion im Docker-Betrieb ausdrücklich aus.
Community-Notizen