Token Optimization - Getting More from Less

Token-Optimierung – Mit weniger mehr erreichen

Gestern haben wir Ihnen gezeigt, wie Sie benutzerdefinierte Agenten mit präziser Tool-Auswahl erstellen können. Heute gehen wir noch einen Schritt weiter:Token-Optimierung.

Die Auswahl der richtigen Tools ist nur die halbe Miete. Der eigentliche Durchbruch ist die Optimierungder Ergebnisse dieser Tools. Wir haben unsere Datenpipelines neu gestaltet, um maximale Genauigkeit zu erzielen und gleichzeitig40 bis 80 % weniger Tokenin den Ausgaben zu verwenden.

So haben wir das gemacht.

Das Problem: Datenüberflutung

Wenn Sie ein Tool wiescrape_as_markdownodersearch_engine aufrufen, gibt die API umfangreiche Daten zurück. Aber hier ist der Haken: Die meisten dieser Daten sind fürMenschen formatiert, nicht fürLLMs.

Herkömmliche APIs enthalten unnötigen Overhead:

Redundante Formatierungen (Fettdruck, Kursivschrift, Überschriften), die LLMs nicht benötigen
Werbung und gesponserte Inhalte, die mit organischen Ergebnissen vermischt sind
Bildmetadaten und visuelle Elemente, die Tokens verschwenden
Inkonsistente Feldbenennung und redundante Metadaten

Bei einem typischen Web-Scraping oder einer Suchanfrage erhalten Sie oft3-5 Mal mehr Daten, als das LLM tatsächlich für die Argumentation benötigt.

Die Lösung: Zweistufige Token-Optimierung

Wir haben einemehrschichtige Optimierungsstrategieimplementiert, die auf verschiedene Arten von Daten abzielt:

Remark + Strip-Markdownfür Webseiteninhalte (scrape_as_markdown)
Parsed Light + Payload Cleaningfür Suchmaschinenergebnisse (search_engine)

Schauen wir uns die einzelnen Ebenen genauer an.

Aber Moment mal – warum nicht TOON?

Sie fragen sich vielleicht: Was ist mit TOON (Token-Oriented Object Notation)? Wir haben es zunächst als dritte Optimierungsebene für strukturierte Datensätze wie LinkedIn-Profile und Amazon-Produkte untersucht.

TOON ist ein cleveres Format, das Einrückungen und tabellarische Layouts verwendet, um Tokens zu reduzieren. Auf dem Papier liefert es 30-60 % Einsparungen für einheitliche Arrays identischer Objekte. Als wir es jedoch mit realen API-Antworten von Bright Data testeten, stellten wir etwas Wichtiges fest:

Das Trennzeichen ist nicht der Engpass – es sind die Daten selbst.

Die Trennzeichen-Illusion

Betrachtet man eine typische LinkedIn-Profilantwort, stammen die meisten Tokens aus:

Langen Textfeldern (Über mich,Empfehlungen,Aktivität[].Titel)
Langen URLs (avatar,banner_image,activity[].link,credential_url)

Das Trennzeichen (n,|,t) macht nur einenwinzigen Bruchteilder Gesamtzahl der Tokens aus.

Zeilenumbruch (n) ist bereits:

eineinzelnes, sehr häufiges Tokenin allen gängigen LLM-Tokenizern
Natürlich abgestimmt auf die Art und Weise, wie Modelle Text in Blöcke unterteilen (zeilenorientiert)
Erscheint nicht in URLs oder den meisten Texten, wodurch Escape-Probleme vermieden werden

Exotische Trennzeichen wie|,^ oderx1Fkönnen an einigen Stellen das Quoting reduzieren, führen jedoch häufig zuseltenen Multi-Token-Sequenzen, die alle Vorteile zunichte machen.

Kurze Antwort: Wenn Sie nur das Trennzeichen anpassen, istnfür diese Art von Daten bereits so gut wie möglich.

Wo TOON zu kurz greift

TOON glänzt beieinheitlichen Arrays identischer Objekte– denken Sie an 1.000 Mitarbeiterdatensätze mit demselben Schema. Aber reale Webdaten aus Tools wieweb_data_linkedin_person_profileoderweb_data_amazon_productsind:

Heterogen– verschachtelte Objekte mit unterschiedlichen Schemata (Erfahrung,Ausbildung,Aktivitätsarrays)
Uneinheitlich– gemischte Array-Typen (einige Einträge habenimg, andere nicht)
Antworten mit einzelnen Objekten– Die meisten API-Aufrufe geben 1 Profil oder 1 Produkt zurück, nicht 1.000

Bei tief verschachtelten oder uneinheitlichen Strukturenverwendet minimiertes JSON oft weniger Token als TOON. Die TOON-Spezifikation selbst räumt dies ein – TOON kann tatsächlichmehrToken als kompaktes JSON für einzelne Objekte mit tiefer Verschachtelung verwenden.

Der eigentliche Hebel: Ändern Sie, was Sie senden, nicht wie Sie es formatieren

Hier ist die wichtige Erkenntnis:Jede Optimierung auf Formatebene (JSON vs. TOON vs. YAML) wird durch eine einfache Änderung der gesendeten Daten in den Schatten gestellt.

Wir tun das nicht – unsere Tools geben die vollständigen Daten aus den APIs von Bright Data zurück. Aber wirentfernenNullwerte, die häufig in Antworten des Web-Scraping-Prozesses vorkommen und Tokens verschwenden, ohne Informationen hinzuzufügen.

Der Punkt ist:Durch Anpassungen der Trennzeichen lassen sich bestenfalls 5–10 % einsparen. Durch Inhaltsfilterung lassen sich 20–80 % einsparen.TOON optimiert die falsche Variable für reale Webdaten.

Unreife der Tools

TOON ist ebenfallsbrandneu– der erste Commit zur Spezifikation erfolgte am 2. November 2024. Es ist buchstäblich einen Monat alt. JSON verfügt über Validatoren, Editoren und Bibliotheken in jeder Sprache. TOON erfordert ein benutzerdefiniertes Parsing und bietet keine Unterstützung für das Ökosystem.

Ein Ingenieur hat es treffend formuliert: „Als ich TOON zum ersten Mal sah, sah es aus wie jemandes halbfertiger Notizblock. Zeigen Sie es Ihrem Backend-Ingenieur, und es besteht die Möglichkeit, dass er die Stirn runzelt, als hätten Sie ihm ein neues Problem gebracht.“

Unsere Entscheidung

Nachdem wir TOON anhand realer Bright Data-Nutzdaten (LinkedIn-Profile, Amazon-Produkte, Google-SERPs) getestet hatten, kamen wir zu folgendem Schluss:

FürSuchergebnisse:Das Parsed Light-Formatvon Bright Data (siehe Layer 2 unten) reduziert die Tokens um 80 % durch Filterung auf API-Ebene – eine benutzerdefinierte Codierung ist nicht erforderlich.
FürWeb-Scraping: Strip-Markdown reduziert Tokens um 40 % und sorgt gleichzeitig dafür, dass die Antworten für Menschen lesbar bleiben – kein neues Format erforderlich.
Fürstrukturierte Datensätze: Die wirklichen Vorteile ergeben sich ausdem Weglassen von Feldernunddem Kürzen von Text, nicht aus dem Ersetzen von JSON durch TOON.

TOON ist eine brillante Idee für den richtigen Anwendungsfall(massive einheitliche Datensätze). Bei heterogenen Web-API-Antworten sind Standardoptimierungen jedoch immer besser als exotische Formate.

Ebene 1: Remark + Strip-Markdown für Web-Scraping

Die Herausforderung: Markdown-Bloat

Unser Tool „scrape_as_markdown” konvertiert jede Webseite in sauberes, LLM-freundliches Markdown. Roh-Markdown-Konverter enthalten jedoch häufig:

Redundante Formatierungen (Fettdruck, Kursivschrift, Überschriften), die LLMs für ihre Schlussfolgerungen nicht benötigen
Bild-Alt-Text und Metadaten
Leere Zeilen und inkonsistente Abstände

Bei einem typischen Blogbeitrag oder einer Produktseite kann rohes Markdown3- bis 5-mal längersein als der Kerninhalt.

Die Lösung: Strip-Markdown

Wir verwendenremark+strip-markdown, um Markdown intelligent auf reinen Text zu reduzieren und dabei die Struktur beizubehalten:

Wir sind demRemark-Projektfür seine hervorragende Markdown-Verarbeitungsbibliothek sehr dankbar. Bitte unterstützen Sie deren Arbeit!

import {remark} from 'remark';
import strip from 'strip-markdown';

// Innerhalb des Tools scrape_as_markdown
const minified_data = await remark()
    .use(strip)
    .process(response.data);
return minified_data.value;

Was wird entfernt?

Das Plugin„strip-markdown” entfernt:

Fett/Kursiv—**Wichtig**wird zuWichtig
Bildsyntax–![alt text](image.png)wird zualt text(falls erforderlich) oder leer
Überschriften–### Abschnittstitelwird zuAbschnittstitel(behält Text bei, entfernt Markup)
Code-Blöcke– Reduziert Backticks und Formatierungen, behält aber den Inhalt bei

Das Ergebnis?Einfacher Text, der die semantische Bedeutung beibehält, aber alle Formatierungsaufwendungen entfernt.

Beispiel: Vorher und nachher

Rohes Markdown (aus Web Unlocker):

# Produktbewertungen

## Kundenfeedback

- **John D.** - ⭐⭐⭐⭐⭐
  *„Tolles Produkt! Sehr zu empfehlen.“*
  [Weiterlesen](https://example.com/review/123)

- **Sarah M.** - ⭐⭐⭐⭐
  *„Gutes Preis-Leistungs-Verhältnis.“*
  [Weiterlesen](https://example.com/review/456)

![Produktbild](https://cdn.example.com/product.jpg)

[Jetzt kaufen](https://example.com/buy)

Nachremark().use(strip).process():

Produktbewertungen

Kundenfeedback

John D. – ⭐⭐⭐⭐⭐
„Tolles Produkt! Sehr zu empfehlen.“
Weiterlesen

Sarah M. – ⭐⭐⭐⭐
„Gutes Preis-Leistungs-Verhältnis.“
Weiterlesen

Produktbild

Jetzt kaufen

Token-Reduzierung: ~40 %für eine ganze Seite.

Das LLM erhält weiterhin den gesamten Bewertungstext, die Bewertungen und die Handlungsaufforderung, jedoch ohne die Link-URLs, Bildpfade oder Markdown-Formatierungssyntax.

Wann sollte Stripped Markdown verwendet werden?

Diese Optimierung eignet sich perfekt für:

Zusammenfassungsaufgaben– „Fassen Sie diesen Blogbeitrag zusammen“
Sentimentanalyse– „Was halten Kunden von diesem Produkt?“
Entitätsextraktion– „Extrahieren Sie Firmennamen und Kontaktinformationen aus dieser Seite“

Wenn Ihr Agentauf Links klickenoderauf der Seite navigieren muss, verwenden Sie stattdessen unsere Scraping-Browser-Tools (scraping_browser_navigate,scraping_browser_snapshot).

Ebene 2: Parsed Light – Entwickelt für KI-Agenten

Das Problem: Herkömmliche SERP-APIs wurden nicht für LLMs entwickelt

Herkömmliche SERP-APIs (Search Engine Result Page) wurden für Menschen entwickelt, die Webschnittstellen durchsuchen. Sie geben alles zurück:

Anzeigen und gesponserte Inhalte, die Ihr Agent nicht benötigt
Wissensfelder und Featured Snippets, die die Antworten aufblähen
Redundante Metadatenfelder über mehrere Namenskonventionen hinweg
Visuelle Elemente (Miniaturansichten, Favicons), die Tokens verschwenden
Verwandte Suchanfragen, Autovervollständigungsvorschläge und Abschnitte „Andere Nutzer fragen auch“

Das Ergebnis? Eine einzige Suche nach 10 Ergebnissen kann2.000 bis 3.000 JSON-Tokenzurückgeben, obwohl Ihr LLM-Agent nurden Link, den Titel und die Beschreibung benötigt.

Für KI-Agenten, die mehrstufige Recherche-Workflows ausführen, ist dies ein Dealbreaker. Jedes zusätzliche Token summiert sich im Kontextfenster und begrenzt die Anzahl der Abfragen, die Sie ausführen können, bevor Sie an Grenzen stoßen.

Die Lösung: Das Parsed Light Format von Bright Data

Wir haben dasParsed LightAPI-Antwortformat eingeführt – speziell entwickelt für KI-Agenten, die Geschwindigkeit und Effizienz benötigen.

Das Besondere daran:

Nur die 10 besten organischen Ergebnisse– keine Anzeigen, keine Knowledge Panels, keine unübersichtliche Seitenleiste
Konsistente Feldstruktur– Jedes Ergebnis verfügt übereinen Link,einen Titel,eine Beschreibung und optionaleinen global_rank
Übersichtliches Design– Voroptimiert auf API-Ebene, sodass keine komplexe Nachbearbeitung erforderlich ist
Schnellere Antwortzeiten– Kleinere Nutzlasten = schnellere Netzwerkübertragung und Parsing

Anstatt sich mit inkonsistenten Feldnamen und aufgeblähten Antworten herumzuschlagen, liefert Parsed Light genau das, was KI-Agenten brauchen:verwertbare Suchergebnisse in minimalen Tokens.

Parsed Light in Aktion

Wenn Sie unsersearch_engine-Toolmit Google als Suchmaschine aufrufen, fordern wir automatisch dasparsed_light-Formatvon Bright Data an:

// Innerhalb des search_engine-Tools (für Google)
const response = await axios({
    url: 'https://api.brightdata.com/request',
    method: 'POST',
    data: {
        url: search_url('google', query, cursor),
        Zone: ctx.unlocker_zone,
        format: 'raw',
        data_format: 'parsed_light',  // ← Der magische Parameter
    },
    headers: api_headers(ctx.api_token, ctx.client_name, 'search_engine'),
    responseType: 'text',
});

Was Sie erhalten: Sauberes, vorhersehbares JSON

Hier ist eine tatsächliche Parsed Light-Antwort für eine Suchanfrage:

{
  "organic": [
    {
      "link": "https://example.com/pizza",
      "title": "Best Pizza in NYC - Joe's Pizza",
      "description": "Familiengeführte Pizzeria, die seit 1975 authentische New Yorker Pizzastücke serviert...",
      "global_rank": 1
    },
    {
      "link": "https://example.com/pizza-guide",
      "title": "Die 10 besten Pizzerien in NYC",
      "description": "Entdecken Sie die bestbewerteten Pizzerien in allen fünf Stadtbezirken...",
      „global_rank”: 2,
      „extensions”: [
        {
          „type”: „site_link”,
          „link”: „https://example.com/pizza-guide/brooklyn”,
          „text”: „Brooklyn”
        }
      ]
    }
    // ... 8 weitere Ergebnisse
]
}

Beachten Sie, wasnichtvorhanden ist:

Keine Anzeigen oder gesponserte Einträge
Keine Knowledge-Graph-Panels
Keine Abschnitte „Andere Nutzer fragen auch“
Keine redundanten Metadatenfelder
Keine Unicode-Steuerzeichen oder Formatierungsfehler

Nur10 saubere, sortierte Suchergebnisse, die Ihr LLM verarbeiten kann.

Zusätzliche Bereinigung: Der letzte Schliff

Auch wenn Parsing die Hauptarbeit übernimmt, führen wir einen leichten Nachbearbeitungsschritt durch, um eine perfekte Konsistenz zu gewährleisten:

function clean_google_search_payload(raw_data){
    const data = raw_data && typeof raw_data=='object' ? raw_data : {};
    const organic = Array.isArray(data.organic) ? data.organic : [];
    const pagination = data.pagination && typeof data.pagination=='object'
        ? data.pagination : {};

    // Normalisieren auf nur Link, Titel, Beschreibung
    const organic_clean = organic
        .map(entry=>{
            if (!entry || typeof entry!='object')
                return null;
            const link = typeof entry.link=='string' ? entry.link.trim() : '';
            const title = typeof entry.title=='string'
                ? entry.title.trim() : '';
            const description = typeof entry.description=='string'
                ? entry.description.trim() : '';
            if (!link || !title)
                return null;  // Ungültige Einträge überspringen
            return {link, title, description};
        })
        .filter(Boolean);

    const parsed_page = Number(pagination.current_page);
    const current_page = Number.isFinite(parsed_page) && parsed_page>0
        ? parsed_page : 1;

    return {organic: organic_clean, current_page};
}

Diese abschließende Bereinigung:

Validiert Datentypen– Stellt sicher, dassLink,Titel undBeschreibungZeichenfolgen sind
Entfernt Leerzeichen– Entfernt alle führenden/nachfolgenden Leerzeichen
Filtert ungültige Einträge– Überspringt Ergebnisse, in denen erforderliche Felder fehlen
Normalisiert die Paginierung– Konvertiertcurrent_pagein ein einheitliches Zahlenformat
Entfernt optionale Felder– Entferntglobal_rankundextensions, um die Antworten so minimal wie möglich zu halten

Das Ergebnis istein absolut sicheres JSON, das Ihr LLM ohne Ausnahmen parsen kann.

Beispiel: Traditionell vs. Parsed Light

Traditionelle SERP-API (vor Parsed Light):

{
  "ads": [...],
  "organic": [
    {
      "link": "https://example.com/product",
      "url": "https://example.com/product",
      "cache": {"url": "https://webcache.google.com/..."},
      "title": "Amazingu2003Productu2003u2003Review",
      "heading": "Amazing Product Review",
      "name": "Product Review",
      "description": "This   is   a   great   product...",
      „snippet”: „Dies ist ein großartiges Produkt...”,
      „snippet_long”: „Dies ist ein großartiges Produkt mit vielen Funktionen...”,
      „subtitle”: „Produktmerkmale”,
      „rating”: 4,5,
      „price”: „49,99 $”,
      „image”: „https://cdn.example.com/image.jpg”,
      „favicon”: „https://example.com/favicon.ico”
    }
    // ... über 30 weitere Ergebnisse, darunter Anzeigen, Knowledge Panels usw.
  ],
  „knowledge_graph”: {...},
  „people_also_ask”: [...],
  „related_searches”: [...],
  „pagination”: {...}
}

~2.500 Tokenfür eine typische Antwort.

Parsed Light (optimiert für KI-Agenten):

{
  "organic": [
    {
      "link": "https://example.com/product",
      "title": "Amazing Product Review",
      "description": "This is a great product...",
      "global_rank": 1
    }
    // ... 9 weitere Ergebnisse (nur die Top 10)
  ]
}

~600 Tokensfür dieselbe Abfrage.

Nachclean_google_search_payload():

{
  „organic”: [
    {
      „link”: „https://example.com/product”,
      „title”: „Amazing Product Review”,
      „description”: „Dies ist ein großartiges Produkt...”
    }
  ],
  „current_page”: 1
}

~500 Tokens– eineReduzierung um 80 %gegenüber herkömmlichen SERP-APIs.

Warum Parsed Light herkömmliche Parser übertrifft

Die meisten SERP-APIs analysieren die gesamte Seite und überlassen Ihnen die Bereinigung des Durcheinanders. Parsed Light ist anders:

Vorab an der Quelle gefiltert– Extrahiert nur organische Ergebnisse, keine Anzeigen oder Seitenleisten
Standardisiertes Schema– Einheitliche Feldnamen für alle Abfragen (keinSnippetvs.Beschreibungvs.Snippet_long)
LLM-first-Design– Von Anfang an auf Token-Effizienz ausgelegt, nicht als nachträglicher Einfall
Reaktionszeiten unter 1 Sekunde– Parsed Light wird über die Premium-Routing-Infrastruktur von Bright Data bereitgestellt, die speziell für missionskritische KI-Anwendungen entwickelt wurde

Hier geht es nicht nur um die Einsparung von Tokens, sondern darum,neu zu überdenken, wie SERP-Daten für KI-Agenten funktionieren sollten.

Entwickelt für Echtzeit-KI-Agenten

Parsed Light von Bright Data ist nicht nur optimiert, sondern auch auf Geschwindigkeit ausgelegt. Mit Antwortzeiten von unter einer Sekunde ist es ideal für:

Echtzeit-Datenanreicherung– Agenten, die während der Unterhaltungen mit Benutzern Live-Lookups durchführen
Mehrstufige Forschungsabläufe– Verkettung mehrerer Abfragen ohne Latenzengpässe
Faktenüberprüfung– Sofortige Validierung von Behauptungen und Aussagen
Benutzerorientierte Anwendungen– Suchgestützte Funktionen, die sich sofort anfühlen

Herkömmliche SERP-APIs können 3–5 Sekunden pro Abfrage benötigen. Bei großem Umfang summiert sich diese Latenz. Parsed Light liefert Ergebnisse inweniger als 1 Sekunde, sodass Ihre Agenten reaktionsschnell bleiben und Ihre Benutzer engagiert bleiben.

Kombinierte Wirkung: Workflow in der Praxis

Verfolgen wir die Verwendung von Tokens anhand eines realistischen Mitarbeiter-Workflows:

Aufgabe:„Finden Sie Artikel über KI-Vorschriften und fassen Sie dann die wichtigsten Punkte aus jeder Quelle zusammen.“

Schritt 1: Suche nach Artikeln

Agent ruft auf:search_engine({query: „KI-Vorschriften 2024”})

Ohne Optimierung (herkömmliche SERP-API):~2.500 Tokens (10 Ergebnisse + Anzeigen + Knowledge Panels)
Mit Parsed Light + Bereinigung:~500 Tokens
Einsparungen:80 %(2.000 Tokens eingespart)

Schritt 2: Artikel-Seiten scrapen

Agent-Aufrufe:scrape_as_markdown({url: „https://example.com/article“})× 5 Artikel

Ohne Optimierung: ~15.000 Tokens (5 Seiten × 3.000 Tokens/Seite)
Mit remark().use(strip): ~9.000 Token
Einsparungen: 40 % (6.000 Token eingespart)

Schritt 3: Zusätzliche Recherche

Agent-Aufrufe:search_engine({query: „EU KI Act details”})für Folgeuntersuchungen

Ohne Optimierung: ~2.500 Token
Mit Parsed Light + Bereinigung: ~500 Token
Einsparungen: 80 % (2.000 Token eingespart)

Gesamtersparnis im Workflow

Ohne Optimierung: 20.000 Token
Mit Optimierung: 10.000 Tokens
Gesamtersparnis: 50 % (10.000 Token eingespart)

Bei 3 $ pro Million Eingabetoken (Preise von Claude Sonnet) sind das 0,030 $ Einsparungen pro Workflow. Wenn Sie dies 1.000 Mal pro Tag ausführen, sparen Sie 30 $ pro Tagoder 10.950 $ pro Jahr.

Der eigentliche Wert liegt jedoch nicht nur in den Kosteneinsparungen, sondern auchim Durchsatz. Mit diesen Optimierungen können Ihre Agenten komplexere Workflows im gleichen Kontextfenster ausführen, Aufgaben schneller erledigen und anspruchsvollere Anfragen bearbeiten.

Warum dies für Agentic-Workflows wichtig ist

Bei der Token-Optimierung geht es nicht nur um Kosten. Es geht darum,komplexere Workflowsinnerhalb von Kontextfensternzu ermöglichen.

Mit einem Kontextfenster von 200.000 Token:

Ohne Optimierung:Sie können ~10 mehrstufige Workflows verarbeiten, bevor Sie das Limit erreichen.
Mit Optimierung:Sie können ~20 Workflows im selben Fenster verarbeiten

Das isteine 100-prozentige Steigerung des Durchsatzesbei gleicher Infrastruktur.

Wenn Sie dies mitden Tool-Gruppenvon Tag 1 (60–95 % Reduzierung der System-Prompt-Token) undden benutzerdefinierten Toolsvon Tag 2 (chirurgische Tool-Auswahl) kombinieren, erzielen Sie eine massive Reduzierung der Gesamt-Token über den gesamten Lebenszyklus des Agenten (System-Prompt + Tool-Aufrufe + Tool-Antworten).

Technische Details: Paketabhängigkeiten

Beide Optimierungsebenen werden mit bewährten Open-Source-Bibliotheken implementiert:

remark– Markdown-Prozessor (verwendet von MDX, Gatsby, Next.js)
strip-markdown– Remark-Plugin zum Entfernen von Formatierungen

Dies sind dieselben Tools, die auch von Produktionswebsites verwendet werden, die täglich Millionen von Anfragen verarbeiten.

Sehen Sie den Unterschied

Möchten Sie die Auswirkungen messen? Vergleichen Sie die Token-Anzahlen:

Rufen Sie einsearch_engine-Toolauf und zählen Sie die Tokens in der Antwort
Vergleichen Sie diese mit einer herkömmlichen SERP-API-Antwort für dieselbe Anfrage
Verwenden Sie den Tokenizer Ihres LLM-Anbieters (z. B.tiktokenfür OpenAI/Claude).

Sie werden eine Reduzierung um 80 % bei Google-Suchen, um 40 % bei gescrapten Seiten und um 50 % bei strukturierten Datensätzen feststellen.

Dies ist nicht nur eine Optimierung, sondern ein völliges Umdenken darüber, wie Webdaten an KI-Agenten geliefert werden sollten.

Zusammenfassung der Leistungsstatistiken

Optimierung	Betroffene Tools	Token-Reduzierung	Anwendungsfall
Strip-Markdown	`scrape_as_markdown`	~40	Zusammenfassungen von Webseiten, Extraktion von Inhalten
Parsed Light	`search_engine` (nur Google)	~80 %	Parsing von Suchergebnissen, Lead-Generierung, Forschungsworkflows

Was kommt als Nächstes?

Morgen (Tag 4) veröffentlichen wir Unternehmensintegrationen, die unseren MCP-Server auf die Plattformen bringen, die Ihre Teams bereits nutzen.

Bleiben Sie dran.