Infrastrukturdesign zur Reduzierung von Proxy-Kosten und Token-Verbrauch bei der Produktion von Agent-Reach
makedream2026年6月19日
0
Computing/Software
Comments (0)
Log in to leave a comment
No posts yet
makedreammakedreamLog in to leave a comment
No posts yet
Selbst Agent-Reach-basierte Agenten, die in der lokalen CLI einwandfrei funktionieren, stoßen in Produktionsumgebungen sofort auf Hindernisse. Sobald zehntausende Scraping-Anfragen eingehen, greifen Sicherheitsmechanismen von CDNs wie Cloudflare und blockieren die IP-Adressen reihenweise. Wenn man sich jedoch ausschließlich auf kostenpflichtige Residential Proxies verlässt, explodieren die Bandbreitenkosten. Zudem führt das direkte Einspeisen von rohem HTML in das LLM oft zu Kontext-Überlastungen und einer massiven Kostenexplosion bei den Token-Gebühren. Um diese Probleme zu lösen, sind eine dynamische Routing-Architektur und eine Preprocessing-Pipeline erforderlich.
Der ungeschützte Betrieb von Agent-Reach kann allein durch die Kosten für kostenpflichtige Residential Proxies tausende Dollar verschlingen. Bei einem System, das 100.000 Anfragen pro Tag verarbeitet, einer durchschnittlichen Seitengröße von 150 KB und einer Ausfallrate von 50 %, erreicht das monatliche Datenvolumen 675 GB. Premium-Residential-Proxies von Anbietern wie Bright Data oder Oxylabs kosten zwischen 4 und 8 US-Dollar pro GB. Wenn der gesamte Traffic darüber läuft, steigen die monatlichen Kosten auf bis zu 5.400 US-Dollar.
Durch den Einsatz des Open-Source-Proxy-Aggregators Scrapoxy als Docker-basierter Super-Proxy können Sie ein einzelnes Endpunkt-Setup beibehalten und gleichzeitig die Infrastrukturkosten kontrollieren. Erstellen Sie zunächst eine docker-compose.yml im Projektstammverzeichnis und definieren Sie die Images valkey/valkey:7.2-alpine und fabienvauchelles/scrapoxy:latest. Verwenden Sie den Befehl --appendonly yes --requirepass [Passwort] für den Valkey-Container, um die Persistenz des Credential-Cachings sicherzustellen. Nachdem Sie Benutzername und Passwort in den Umgebungsvariablen für Scrapoxy konfiguriert haben, starten Sie die Container mit docker compose up -d. Mit dieser Konfiguration können Sie monatlich über 200 US-Dollar an Abonnementgebühren einsparen.
Abhängig von der Sicherheitsrichtlinie der Zielplattform sollte die IP-Wechselfrequenz dual gesteuert werden, um Sitzungsabbrüche zu vermeiden. Für öffentliche Read-Only-Anfragen ohne Authentifizierung empfiehlt sich ein aggressives TTL-Intervall zwischen 30 Sekunden und 3 Minuten, um in einem Round-Robin-Verfahren bei jeder Anfrage eine neue IP zuzuweisen. Dies dient der Umgehung von schwellenwertbasierten Sperren. Bei authentifizierungsbasierten Plattformen wie X oder Reddit, bei denen das Aufrechterhalten von Session-Cookies zwingend erforderlich ist, sollte die Cookie-Injection-Funktion von Scrapoxy aktiviert werden, um denselben Residential-IP-Knoten für 5 bis 10 Minuten festzuhalten. Dies verhindert, dass die Authentifizierungssitzung aufgrund eines abrupten Wechsels der geografischen IP-Adresse abläuft.
Um die Kosten weiter zu senken, sollte das Traffic-Routing auf der NGINX-API-Gateway-Ebene optimiert werden. Definieren Sie in der NGINX-Konfigurationsdatei (/etc/nginx/nginx.conf) im upstream-Block sowohl kostengünstige Datacenter-Proxy-Pools (z. B. DataImpulse mit ca. 1 USD/GB) als auch den Scrapoxy-Residential-Proxy-Pool. Erstellen Sie im server-Block einen /fetch/generic/-Location-Block, um sicherheitsunkritischen öffentlichen HTML-Traffic (wie RSS-Feeds oder GitHub-Suchen) an Datacenter-Proxies weiterzuleiten. Erstellen Sie anschließend einen /fetch/social/-Location-Block, um nur Anfragen an hochsensible soziale Endpunkte an das Scrapoxy-Backend zu routen und die erforderlichen Header zu injizieren. Durch dieses 2-Track-Routing vermeiden Sie die Verschwendung teurer Bandbreite bei Residential Proxies und senken die Proxy-Gesamtkosten um bis zu 90 %.
Rohe HTML-Daten sind voll von redundanten DOM-Elementen, Stylesheets und Inline-Skripten. Wenn diese direkt in das LLM eingegeben werden, verbrauchen sie unnötige Token und verwässern die Inferenz-Ergebnisse. Die Umwandlung von Webseiten in Markdown vor der Einspeisung in das Kontextfenster reduziert die Datengröße um 75 % bis 90 %. Durch Bereinigung mittels regulärer Ausdrücke und Markdown-Serialisierung in der Preprocessing-Stufe lässt sich der Token-Verbrauch der LLM-API um über 40 % senken, während gleichzeitig "Window Exceeded"-Fehler vermieden werden.
Implementieren Sie eine Python-Funktion, die zur Vorverarbeitung der Eingabedaten die Parser-Komponenten Trafilatura und html2text kombiniert. Rufen Sie die Funktion trafilatura.extract() mit der Option favor_recall=False auf, um Seitenleisten und Werbung auszuschließen und nur den Haupttext zu extrahieren. Für den Fall, dass die Extraktion des Hauptinhalts fehlschlägt, fügen Sie einen Fallback-Code ein, der ein html2text.HTML2Text()-Objekt erstellt, wobei ignore_images=True und body_width=0 gesetzt sind. Durch die Ausführung von regulären Ausdrücken (re.sub) zur Entfernung verbleibender Tags wie <script> und <style> sowie Bereinigungsroutinen zur Reduzierung aufeinanderfolgender Leerzeilen im extrahierten Markdown-Text wird die Antwortlatenz des Agenten verringert.
Beim Aufteilen langer Dokumente sollte statt einer simplen zeichenbasierten Chunking-Methode ein Segmentierungsalgorithmus verwendet werden, der semantische Ähnlichkeiten berücksichtigt, um den Kontext zu bewahren. Berechnen Sie die Kosinus-Ähnlichkeit zwischen den Embedding-Vektoren von satzweise segmentierten Texten, um Punkte semantischer Brüche zu identifizieren:
Similarity(u, v) = rac{u cdot v}{\|u\| \|v\|}Nach Berechnung der Distanzen zwischen benachbarten Sätzen werden die Grenzen, an denen der Distanzunterschied das 95. Perzentil des gesamten Dokuments überschreitet, als semantische Segmentierungspunkte festgelegt, um die Liste der Chunks zu erstellen. Die Anwendung von semantischem Chunking anstelle von Chunking mit fester Länge verhindert Informationsverlust durch das Zerschneiden zusammengehöriger Informationen in verschiedene Fragmente und verbessert die Genauigkeit der Informationssuche des LLMs.
Plattformen wie X oder LinkedIn haben strikte Geschwindigkeitsbegrenzungen, was häufig zu HTTP 429- oder 403-Fehlern führt. Wenn ein synchroner Anwendungsprozess bei solchen vorübergehenden Fehlern sofort Wiederholungsversuche unternimmt, werden Serverressourcen erschöpft und die Wahrscheinlichkeit einer IP-Sperre steigt. Um die Systemresilienz zu gewährleisten, ist eine asynchrone Exception-Handling-Middleware erforderlich, die die Art der Ausnahme identifiziert und die Last auf dem Zielserver dynamisch anpasst.
Beim Design der Fehlerbehandlungs-Klasse ist eine strikte Unterscheidung zwischen transienten und permanenten Fehlern notwendig. HTTP-Statuscodes wie 429, 502, 503, 504 oder Fehlermeldungen mit 'timeout' oder 'connection refused' werden als transiente Fehler klassifiziert und für Wiederholungsversuche markiert. Im Gegensatz dazu werden Fehler wie 401 oder 400 als permanent eingestuft und sofort in eine Dead Letter Queue (DLQ) verschoben. Bei transienten Fehlern wird ein Exponential-Backoff-Algorithmus mit zufälligem Jitter in Millisekunden angewendet, um das "Thundering Herd"-Problem zu vermeiden, das bei gleichzeitigen Anfragewellen auftritt. Die Formel zur Berechnung der Wartezeit lautet:
Durch die Festlegung der initialen Basisverzögerung () auf 30 Sekunden und eines Maximums () von 600 Sekunden wird beim dritten Wiederholungsversuch eine verteilte Wartezeit von etwa 240 Sekunden gewährleistet, was die Sperrrichtlinien der Zielplattform umgeht.
Um kaskadierende Ausfälle zu verhindern, bei denen eine Störung oder Sicherheitsverschärfung einer bestimmten Plattform den gesamten Workflow lahmlegt, implementieren Sie ein Bulkhead-Pattern auf Redis-Basis in der Middleware-Ebene. Erstellen Sie anstelle einer einzelnen globalen Queue unabhängige Redis-Listen pro Zieldomäne (queue:bulkhead:twitter, queue:bulkhead:reddit, queue:bulkhead:general). Weisen Sie jedem Worker-Pool, der eine Queue verarbeitet, ein differenziertes Concurrency-Limit zu (z. B. 3 für Twitter, 25 für General Web). Verwenden Sie zur Verwaltung der Wiederholungspläne für fehlgeschlagene Aufgaben die „Sorted Sets“ von Redis, um Wiederaufnahme-Zeitstempel als Score zu registrieren und eine Routine für verzögerte Verarbeitung zu schreiben. Durch diese Bulkhead-Struktur wird bei einer API-Sperre eines bestimmten sozialen Netzwerks nur der zugehörige Worker in den Wartemodus versetzt, während die Erfolgsquote der Forschungsaufgaben des gesamten Agenten bei über 95 % gehalten wird.
Rohdaten, die wahllos aus verschiedenen Webquellen gescrapt wurden, enthalten oft Inkonsistenzen bei Datumsangaben oder Falschinformationen, was das LLM zu verzerrten Schlussfolgerungen verleiten kann. Bevor der Kontext in ein generatives KI-Modell eingespeist wird, sollte eine diskrete Validierungsschicht am Ende der Pipeline integriert werden, die die Zuverlässigkeit des Markdown-Inhalts berechnet und die numerische Konsistenz prüft, um Halluzinationen zu verhindern.
Entwerfen Sie eine deterministische Filterklasse, die die zeitliche Gültigkeit der gesammelten Metadaten und Gewichtungen je nach Plattformquelle berechnet. Dokumente, deren Zeitstempel in der Zukunft liegen oder die ungültige ISO-Datumsformate enthalten, werden sofort aus dem Datensatz entfernt. Deklarieren Sie zudem ein Dictionary, das Zuverlässigkeitsgewichtungen für Plattformquellen zuordnet: GitHub erhält 0,95, Wikipedia 0,90, während für soziale Medien wie Reddit (0,50) oder Twitter (0,40) niedrigere Standardwerte angesetzt werden. Erst durch eine Logik, die einen Bonus von 0,05 auf die Metadaten-Gewichtung gewährt, wenn Autor und Titel im Dokument intakt sind, wird der endgültige Vertrauensscore generiert. Informationswerte, deren Score unter einem Schwellenwert liegt, werden bei der Zusammenstellung des LLM-Prompts vollständig ausgeschlossen.
Zur abschließenden Qualitätssicherung der Ausgabedaten wird ein Scoring-Skript ausgeführt, das die generierten Antwortkandidaten mit dem Originalkontext abgleicht:
\b\d+(?:\.\d+)?%?\b), um einen Schnittmengenabgleich zwischen den numerischen Symbolmengen des Originaldatensatzes und den generierten Sätzen durchzuführen. Werden im Quelltext nicht vorhandene Werte oder Währungseinheiten erkannt, wird ein Flag für numerische Diskrepanz ausgelöst und über die Routing-Middleware sofort eine erneute Ausführung angefordert.Durch die Integration einer solch mehrschichtigen Validierungsschicht werden Probleme wie numerische Manipulationen oder falsche Zitate, die bei Crawling-basierten Agenten auftreten, auf Architekturebene blockiert, sodass nur vollständig verifizierte Forschungsergebnisse an den Endbenutzer geliefert werden.