Menu d'accessibilité passer au contenu
day3

Token Optimization – Getting More from Less

18 min de lecture

Optimisation des jetons – Obtenir plus avec moins

Hier, nous vous avons montré comment créer des agents personnalisés avec une sélection chirurgicale d’outils. Aujourd’hui, nous allons plus loin :l’optimisation des jetons.

Choisir les bons outils n’est que la moitié du chemin. Ce qui change vraiment la donne, c’est l’optimisation des résultatsfournis par ces outils. Nous avons repensé l’architecture de nos pipelines de données afin d’offrir une précision maximale tout en utilisant40 à 80 % de jetons en moinsdans les résultats.

Voici comment nous avons procédé.

Le problème : l’inflation des données

Lorsque vous appelez un outil tel quescrape_as_markdownousearch_engine, l’API renvoie des données riches. Mais voici le hic : la plupart de ces données sont formatées pourles humains, et non pourles LLM.

Les API traditionnelles comportent des frais généraux inutiles :

  • Formatage redondant (gras, italique, titres) dont les LLM n’ont pas besoin
  • Des publicités et du contenu sponsorisé mélangés aux résultats organiques
  • Métadonnées d’images et éléments visuels qui gaspillent des jetons
  • Noms de champs incohérents et métadonnées redondantes

Pour un scraping web ou une requête de recherche classique, vous obtenez souvent3 à 5 fois plus de donnéesque ce dont le LLM a réellement besoin pour raisonner.

La solution : optimisation des jetons à deux niveaux

Nous avons mis en place unestratégie d’optimisation en deux couchesqui cible différents types de données :

  1. Remark + Strip-Markdownpour le contenu des pages web (scrape_as_markdown)
  2. Analyse de Light + Cleaning du Payloadpour les résultats des moteurs de recherche (search_engine)

Décomposons chaque couche.

Mais attendez… Pourquoi pas TOON ?

Vous vous demandez peut-être : qu’en est-il de TOON (Token-Oriented Object Notation) ? Nous l’avons initialement exploré comme troisième couche d’optimisation pour les Jeux de données structurés tels que les profils LinkedIn et les produits Amazon.

TOON est un format intelligent qui utilise l’indentation et les mises en page tabulaires pour réduire les jetons. Sur le papier, il permet de réaliser des économies de 30 à 60 % pour les tableaux uniformes d’objets identiques. Mais lorsque nous l’avons testé sur des réponses API réelles de Bright Data, nous avons découvert quelque chose d’important :

le délimiteur n’est pas le goulot d’étranglement, ce sont les données elles-mêmes.

L’illusion du délimiteur

Si l’on examine une réponse de profil LinkedIn typique, la plupart des jetons proviennent de :

  • Champs de texte longs (à propos,recommandations,activité[].titre)
  • URL longues (avatar,banner_image,activity[].link,credential_url)

Le délimiteur (n,|,t) ne représente qu’uneinfime partiedu nombre total de jetons.

Le saut de ligne (n) est déjà :

  • Un jeton unique très courantdans tous les principaux tokeniseurs LLM
  • Naturellement aligné avec la façon dont les modèles fragmentent le texte (orienté ligne)
  • N’apparaît pas dans les URL ni dans la plupart des textes, ce qui évite les problèmes d’échappement

Les séparateurs exotiques tels que|,^ oux1Fpeuvent réduire les guillemets à certains endroits, mais ils introduisent souventdes séquences multi-tokens raresqui annulent tout gain.

Réponse courte : si vous ne modifiez que le délimiteur,nest déjà la meilleure option pour ce type de données.

Les limites de TOON

TOON excelle pourles tableaux uniformes d’objets identiques, par exemple 1 000 enregistrements d’employés avec le même schéma. Mais les données web réelles provenant d’outils tels queweb_data_linkedin_person_profileouweb_data_amazon_productsont :

  • Hétérogènes— Objets imbriqués avec des schémas différents (expérience,formation, tableauxd'activités)
  • Non uniformes— Types de tableaux mixtes (certaines entrées ontimg, d’autres non)
  • Réponses à objet unique— La plupart des appels API renvoient 1 profil ou 1 produit, et non 1 000

Pour les structures profondément imbriquées ou non uniformes,le JSON minifié utilise souvent moins de jetons que TOON. La spécification TOON elle-même le reconnaît : TOON peut en fait utiliserplus dejetons que le JSON compact pour les objets uniques avec une imbrication profonde.

Le véritable levier : changez ce que vous envoyez, pas la façon dont vous le formatez

Voici l’idée qui importe :toute optimisation au niveau du format (JSON vs TOON vs YAML) est éclipsée par le simple fait de changer les données que vous envoyez.

Nous ne faisons pas tout cela : nos outils renvoient toutes les données des API de Bright Data. Mais noussupprimonsles valeursnulles, qui apparaissent fréquemment dans les réponses de Scraping web et gaspillent des jetons sans ajouter d’informations.

Le fait est queles ajustements des délimiteurs permettent d’économiser au mieux 5 à 10 %. Le filtrage du contenu permet d’économiser 20 à 80 %.TOON optimise la mauvaise variable pour les données web réelles.

Immaturité des outils

TOON est égalementtout nouveau: la première version de la spécification a été publiée le 2 novembre 2024. Il a littéralement un mois. JSON dispose de validateurs, d’éditeurs et de bibliothèques dans toutes les langues. TOON nécessite un analyseur syntaxique personnalisé et manque de soutien de la part de l’écosystème.

Un ingénieur l’a bien résumé : « La première fois que j’ai vu TOON, cela ressemblait à un brouillon à moitié terminé. Montrez-le à votre ingénieur backend, et il y a de fortes chances qu’il fronce les sourcils comme si vous lui aviez apporté un nouveau problème. »

Notre décision

Après avoir testé TOON sur des charges utiles réelles de Bright Data (profils LinkedIn, produits Amazon, SERP Google), nous avons conclu :

  • Pourles résultats de recherche: le formatParsed Lightde Bright Data (voir couche 2 ci-dessous) permet une réduction de 80 % des jetons grâce à un filtrage au niveau de l’API, sans encodage personnalisé nécessaire.
  • Pourle scraping web: Strip-markdown réduit les tokens de 40 % tout en conservant des réponses lisibles par l’homme, sans nécessiter de nouveau format.
  • Pourles jeux de données structurés: les véritables avantages proviennent dela suppression de champsetdu tronquage de texte, et non du remplacement de JSON par TOON.

TOON est une idée brillante pour les cas d’utilisation appropriés(Jeux de données uniformes massifs). Mais pour les réponses API Web hétérogènes, les optimisations standard l’emportent à chaque fois sur les formats exotiques.


Couche 1 : Remark + Strip-Markdown pour le Scraping web

Le défi : le gonflement du markdown

Notre outil scrape_as_markdown convertit n’importe quelle page web en markdown propre et compatible avec les LLM. Mais les convertisseurs de markdown bruts incluent souvent :

  • Une mise en forme redondante (gras, italique, titres) dont les LLM n’ont pas besoin pour raisonner
  • Texte alternatif et métadonnées des images
  • Des lignes vides et des incohérences d’espacement

Pour un article de blog ou une page produit classique, le markdown brut peut être3 à 5 fois plus longque le contenu principal.

La solution : Strip-Markdown

Nous utilisonsremark+strip-markdownpour réduire intelligemment le markdown en texte brut tout en préservant la structure :

Nous sommes reconnaissants au projetremarkpour son excellente bibliothèque de traitement du markdown. Envisagez de soutenir leur travail !

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

// À l'intérieur de l'outil scrape_as_markdown
const minified_data = await remark()
    .use(strip)
    .process(response.data);
return minified_data.value;

Qu’est-ce qui est supprimé ?

Le pluginstrip-markdownsupprime :

  • Gras/Italique**Important**devientImportant
  • Syntaxe d’image![alt text](image.png)devientalt text(si nécessaire) ou vide
  • Les titres### Section TitledevientSection Title(conserve le texte, supprime le balisage)
  • Blocs de code— Réduit les guillemets inversés et la mise en forme tout en conservant le contenu

Le résultat ?Un texte brut qui conserve la signification sémantiquemais supprime toute la surcharge de formatage.

Exemple : avant et après

Markdown brut (à partir de Web Unlocker) :

# Avis sur les produits

## Commentaires des clients

- **John D.** - ⭐⭐⭐⭐⭐
  *« Excellent produit ! Je le recommande vivement. »*
  [Lire la suite](https://example.com/review/123)

- **Sarah M.** - ⭐⭐⭐⭐
  *« Bon rapport qualité-prix. »*
  [En savoir plus](https://example.com/review/456)

![Image du produit](https://cdn.example.com/product.jpg)

[Acheter maintenant](https://example.com/buy)

Aprèsremark().use(strip).process():

Avis sur le produit

Commentaires des clients

John D. - ⭐⭐⭐⭐⭐
« Excellent produit ! Je le recommande vivement. »
Lire la suite

Sarah M. - ⭐⭐⭐⭐
« Bon rapport qualité-prix. »
Lire la suite

Image du produit

Acheter maintenant

Réduction des jetons : ~40 %pour une page complète.

Le LLM récupère toujours l’intégralité du texte des avis, les notes et les appels à l’action, mais sans les URL des liens, les chemins d’accès aux images ou la syntaxe de formatage Markdown.

Quand utiliser le balisage Markdown simplifié

Cette optimisation est parfaite pour :

  • Les tâches de synthèse— « Résumez cet article de blog ».
  • Analyse des sentiments— « Que pensent les clients de ce produit ? »
  • Extraction d’entités— « Extrayez les noms des entreprises et leurs coordonnées de cette page »

Si votre agent doitcliquer sur des liensounaviguer sur la page, utilisez plutôt nos outils du Navigateur de scraping (scraping_browser_navigate,scraping_browser_snapshot).


Couche 2 : Analyse de la lumière – Conçu pour les agents IA

Le problème : les API SERP traditionnelles n’ont pas été conçues pour les LLM

Les API traditionnelles des pages de résultats des moteurs de recherche (SERP) ont été conçues pour les humains qui naviguent sur les interfaces web. Elles renvoient tout :

  • Les publicités et le contenu sponsorisé dont votre agent n’a pas besoin
  • Des panneaux de connaissances et des extraits optimisés qui alourdissent les réponses
  • Champs de métadonnées redondants dans plusieurs conventions de nommage
  • Éléments visuels (miniatures, favicons) qui gaspillent des jetons
  • Recherches associées, suggestions de saisie semi-automatique et sections « Les internautes ont également demandé »

Résultat ? Une seule recherche pour 10 résultats peut renvoyer2 000 à 3 000 jetonsJSON, alors que votre agent LLM n’a besoin quedu lien, du titre et de la description.

Pour les agents IA qui exécutent des workflows de recherche en plusieurs étapes, c’est rédhibitoire. Chaque jeton supplémentaire s’ajoute à la fenêtre contextuelle, limitant ainsi le nombre de requêtes que vous pouvez exécuter avant d’atteindre les limites.

La solution : le format Parsed Light de Bright Data

Nous avons introduit le format de réponse APIParsed Light, spécialement conçu pour les agents IA qui ont besoin de rapidité et d’efficacité.

Voici ce qui le rend différent :

  • Uniquement les 10 premiers résultats organiques— Pas de publicités, pas de panneaux de connaissances, pas d’encombrement dans la barre latérale
  • Structure de champ cohérente— Chaque résultat comporteun lien,un titre,une description etun global_rank facultatif
  • Conception épurée— Pré-optimisé au niveau de l’API, vous n’avez donc pas besoin d’un post-traitement complexe
  • Temps de réponse plus rapides— Charges utiles plus petites = transfert réseau et Analyse plus rapides

Au lieu de se débattre avec des noms de champs incohérents et des réponses trop lourdes, Parsed Light fournit exactement ce dont les agents IA ont besoin :des résultats de recherche exploitables en un minimum de jetons.

Parsed Light en action

Lorsque vous appelez notre outilsearch_engineavec Google comme moteur, nous demandons automatiquement le formatparsed_lightde Bright Data :

// À l'intérieur de l'outil search_engine (pour 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',  // ← Le paramètre magique
    },
    headers: api_headers(ctx.api_token, ctx.client_name, 'search_engine'),
    responseType: 'text',
});

Ce que vous obtenez : un JSON propre et prévisible

Voici une réponse Parsed Light réelle pour une requête de recherche :

{
  "organic": [
    {
      "link": "https://example.com/pizza",
      "title": "Best Pizza in NYC - Joe's Pizza",
      "description": "Pizzeria familiale servant d'authentiques parts de pizza new-yorkaises depuis 1975...",
      "global_rank": 1
    },
    {
      "link": "https://example.com/pizza-guide",
      "title": "Les 10 meilleures pizzerias de New York",
      "description": "Découvrez les pizzerias les mieux notées dans les cinq arrondissements...",
      « global_rank » : 2,
      « extensions » : [
        {
          « type » : « site_link »,
          « link » : « https://example.com/pizza-guide/brooklyn »,
          « text » : « Brooklyn »
        }
      ]
    }
    // ... 8 résultats supplémentaires
]
}

Remarquez ce quin’apparaîtpas:

  • Pas de publicités ni de listes sponsorisées
  • Pas de panneaux de graphiques de connaissances
  • Pas de sections « Les gens demandent aussi »
  • Pas de champs de métadonnées redondants
  • Pas de caractères de contrôle Unicode ni de bruit de formatage

Juste10 résultats de recherche propres et classés,prêts à être traités par votre LLM.

Nettoyage supplémentaire : la touche finale

Même si l’effet Parsed Light effectue le gros du travail, nous appliquons une étape de post-traitement légère pour garantir une cohérence parfaite :

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 : {};

    // Normaliser pour n'obtenir que le lien, le titre et la description
    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;  // Ignorer les entrées non valides
            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};
}

Ce nettoyage final :

  1. Valide les types de données— S’assure quele lien,le titre etla descriptionsont des chaînes de caractères
  2. Supprime les espaces blancs— Supprime tous les espaces avant et après
  3. Filtre les entrées non valides— Ignore les résultats manquant des champs obligatoires
  4. Normalise la pagination— Convertitcurrent_pageen un format numérique cohérent
  5. Supprime les champs facultatifs— Supprimeglobal_ranketextensionspour que les réponses restent ultra-minimales

Le résultat estun JSON à toute épreuveque votre LLM peut analyser sans aucun cas limite.

Exemple : traditionnel vs. Analyse de Light

API SERP traditionnelle (avant 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 » : « C'est un excellent produit... »,
      « snippet_long » : « C'est un excellent produit doté de nombreuses fonctionnalités... »,
      « sous-titre » : « Caractéristiques du produit »,
      « note » : 4,5,
      « prix » : « 49,99 $ »,
      « image » : « https://cdn.example.com/image.jpg »,
      « favicon » : « https://example.com/favicon.ico »
    }
    // ... plus de 30 résultats supplémentaires, y compris des publicités, des panneaux de connaissances, etc.
  ],
  « knowledge_graph » : {...},
  « people_also_ask » : [...],
  « related_searches » : [...],
  « pagination » : {...}
}

Environ 2 500 jetonspour une réponse type.

Parsed Light (optimisé pour les agents IA) :

{
  "organic": [
    {
      "link": "https://example.com/product",
      "title": "Amazing Product Review",
      "description": "This is a great product...",
      "global_rank": 1
    }
    // ... 9 résultats supplémentaires (top 10 uniquement)
  ]
}

~600 jetonspour la même requête.

Aprèsclean_google_search_payload():

{
  « organic » : [
    {
      « link » : « https://example.com/product »,
      « title » : « Critique d'un produit exceptionnel »,
      « description » : « C'est un excellent produit... »
    }
  ],
  « current_page » : 1
}

~500 jetons, soit uneréduction de 80 %par rapport aux API SERP traditionnelles.

Pourquoi Parsed Light surpasse les analyseurs traditionnels

La plupart des API SERP analysent l’intégralité de la page et vous laissent le soin de faire le tri. Parsed Light est différent :

  • Préfiltré à la source— N’extrait que les résultats organiques, sans publicités ni barres latérales
  • Schéma standardisé— Noms de champs cohérents pour toutes les requêtes (pas desnippetvsdescriptionvssnippet_long)
  • Conception axée sur le LLM— Conçu dès le départ pour l’efficacité des jetons, et non comme une réflexion après coup
  • Temps de réponse inférieur à 1 seconde— Parsed Light est fourni via l’infrastructure de routage premium de Bright Data, spécialement conçue pour les applications d’IA critiques

Il ne s’agit pas seulement d’économiser des jetons, mais derepenser le fonctionnement des données SERP pour les agents IA.

Conçu pour les agents IA en temps réel

Parsed Light de Bright Data n’est pas seulement optimisé, il est conçu pour la vitesse. Avec des temps de réponse inférieurs à 1 seconde, il est idéal pour :

  • Enrichissement des données en temps réel— Agents effectuant des recherches en direct pendant les conversations des utilisateurs
  • Workflows de recherche en plusieurs étapes— Enchaîner plusieurs requêtes sans goulots d’étranglement liés à la latence
  • La vérification des faits— Validation instantanée des affirmations et des déclarations
  • Applications destinées aux utilisateurs— Fonctionnalités de recherche instantanées

Les API SERP traditionnelles peuvent prendre 3 à 5 secondes par requête. À grande échelle, cette latence s’accumule. Parsed Light fournit des résultats enmoins d’une seconde, ce qui permet à vos agents de rester réactifs et à vos utilisateurs de rester engagés.


Impact combiné : flux de travail réel

Suivons l’utilisation des jetons à travers un flux de travail réaliste d’un agent :

Tâche :« Trouver des articles sur la réglementation en matière d’IA, puis résumer les points clés de chaque source. »

Étape 1 : rechercher des articles

Appel de l’agent :search_engine({query: « réglementations en matière d'IA 2024 »})

Sans optimisation (API SERP traditionnelle) :~2 500 jetons (10 résultats + publicités + panneaux de connaissances)
Avec Parsed Light + nettoyage :~500 jetons
Économies :80 %(2 000 jetons économisés)

Étape 2 : Récupération des pages d’articles

Appels de l’agent :scrape_as_markdown({url: « https://example.com/article »})× 5 articles

Sans optimisation : environ 15 000 jetons (5 pages × 3 000 jetons/page)
Avec remark().use(strip): environ 9 000 jetons
Économies : 40 % (6 000 jetons économisés)

Étape 3 : Recherche supplémentaire

Appels de l’agent :search_engine({query: « EU IA Act details »})pour des recherches complémentaires

Sans optimisation : environ 2 500 jetons
Avec Parsed Light + nettoyage : environ 500 jetons
Économies : 80 % (2 000 jetons économisés)

Économies totales sur le flux de travail

Sans optimisation : 20 000 jetons
Avec optimisation : 10 000 jetons
Réduction globale : 50 % (10 000 jetons économisés)

À 3 $ par million de jetons d’entrée (tarification Claude Sonnet), cela représente une économie de 0,030 $ par flux de travail. En exécutant cette opération 1 000 fois par jour, vous économisez 30 $ par jour, soit 10 950 $ par an.

Mais la véritable valeur ajoutée ne réside pas seulement dans les économies réalisées, mais aussi dansle débit. Grâce à ces optimisations, vos agents peuvent exécuter des workflows plus complexes dans la même fenêtre contextuelle, accomplir leurs tâches plus rapidement et traiter des requêtes plus sophistiquées.


Pourquoi est-ce important pour les workflows des agents ?

L’optimisation des jetons ne concerne pas seulement les coûts. Elle permet égalementd’exécuter des workflows plus complexesdans les fenêtres contextuelles.

Avec une fenêtre contextuelle de 200 000 jetons :

  • Sans optimisation :vous pouvez traiter environ 10 workflows en plusieurs étapes avant d’atteindre la limite
  • Avec optimisation :vous pouvez traiter environ 20 workflows dans la même fenêtre

Cela représenteun gain de débit de 100 %pour la même infrastructure.

Et lorsque vous combinez cela avecles groupes d’outilsdu jour 1 (réduction de 60 à 95 % des jetons d’invite système) etles outils personnalisésdu jour 2 (sélection chirurgicale des outils), vous obtenez une réduction massive du nombre total de jetons sur l’ensemble du cycle de vie de l’agent (invite système + appels d’outils + réponses d’outils).

Détails techniques : dépendances des paquets

Les deux couches d’optimisation sont mises en œuvre à l’aide de bibliothèques open source éprouvées :

  • remark— Processeur Markdown (utilisé par MDX, Gatsby, Next.js)
  • strip-markdown— Plugin Remark pour supprimer le formatage

Il s’agit des mêmes outils que ceux utilisés par les sites de production traitant des millions de requêtes par jour.


Voyez la différence

Vous souhaitez mesurer l’impact ? Comparez le nombre de jetons :

  1. Appelez un outilsearch_engineet comptez les jetons dans la réponse
  2. Comparez avec une réponse API SERP traditionnelle pour la même requête
  3. Utilisez le tokenizer de votre fournisseur LLM (par exemple,tiktokenpour OpenAI/Claude)

Vous constaterez une réduction de 80 % sur les recherches Google, de 40 % sur les pages scrapées et de 50 % sur les Jeux de données structurés.

Il ne s’agit pas seulement d’optimisation, mais d’une refonte complète de la manière dont les données web doivent être fournies aux agents IA.


Résumé des statistiques de performance

Optimisation Outils concernés Réduction des jetons Cas d’utilisation
Strip-Markdown scrape_as_markdown ~40 Résumés de pages Web, extraction de contenu
Parsed Light search_engine (Google uniquement) ~80 Analyse des résultats de recherche, génération de prospects, flux de travail de recherche

Et ensuite ?

Demain (jour 4), nous lancerons des intégrations d’entreprise qui permettront à nos équipes d’utiliser notre serveur MCP sur les plateformes qu’elles utilisent déjà.

Restez à l’écoute.

Prêt à commencer?
Explorez le serveur MCP Web et commencez à construire des agents AI puissants.
Lire la documentation Voir le dépôt