Token Optimization - Getting More from Less

Otimização de tokens – Obtendo mais com menos

Ontem mostramos como criar agentes personalizados com seleção cirúrgica de ferramentas. Hoje, vamos nos aprofundar:Otimização de tokens.

Selecionar as ferramentas certas é apenas metade da batalha. O que realmente faz a diferença é otimizar o que essas ferramentasretornam. Reestruturamos nossos pipelines de dados para oferecer precisão máxima, usando40-80% menos tokensnas saídas.

Veja como fizemos isso.

O problema: excesso de dados

Quando você chama uma ferramenta comoscrape_as_markdownousearch_engine, a API retorna dados ricos. Mas aqui está o problema: a maioria desses dados é formatada parahumanos, não paraLLMs.

As APIs tradicionais incluem sobrecarga desnecessária:

Formatação redundante (negrito, itálico, títulos) que os LLMs não precisam
Anúncios e conteúdo patrocinado misturados com resultados orgânicos
Metadados de imagem e elementos visuais que desperdiçam tokens
Nomes de campos inconsistentes e metadados redundantes

Para uma consulta de pesquisa típica ou um processo de scraping de dados, você geralmente obtémde 3 a 5 vezes mais dadosdo que o LLM realmente precisa para raciocinar.

A solução: otimização de tokens em duas camadas

Implementamos umaestratégia de otimização em camadasque visa diferentes tipos de dados:

Remark + Strip-Markdownpara conteúdo de páginas da web (scrape_as_markdown)
Parsing Light + Payload Cleaningpara resultados de mecanismos de pesquisa (search_engine)

Vamos detalhar cada camada.

Mas espere aí… por que não TOON?

Você deve estar se perguntando: e o TOON (Token-Oriented Object Notation)? Inicialmente, exploramos essa opção como uma terceira camada de otimização para Conjuntos de dados estruturados, como perfis do LinkedIn e produtos da Amazon.

O TOON é um formato inteligente que usa recuos e layouts tabulares para reduzir tokens. No papel, ele oferece uma economia de 30 a 60% para matrizes uniformes de objetos idênticos. Mas quando o testamos em respostas de API do mundo real da Bright Data, descobrimos algo importante:

O delimitador não é o gargalo — os dados em si são.

A ilusão do delimitador

Analisando uma resposta típica de perfil do LinkedIn, a maioria dos tokens vem de:

Campos de texto longos (sobre,recomendações,atividade[].título)
URLs longos (avatar,banner_image,activity[].link,credential_url)

O delimitador (n,|,t) é umapequena fraçãoda contagem total de tokens.

A nova linha (n) já é:

Um token único e muito comumem todos os principais tokenizadores LLM
Naturalmente alinhado com a forma como os modelos dividem o texto (orientado por linha)
Não aparece dentro de URLs ou na maioria dos textos, evitando problemas de escape

Separadores exóticos como|,^ oux1Fpodem reduzir as citações em alguns pontos, mas muitas vezes introduzemsequências raras de vários tokensque anulam quaisquer ganhos.

Resposta curta: se você apenas ajustar o delimitador,njá é o melhor possível para esse tipo de dados.

Onde o TOON fica aquém

O TOON se destaca emmatrizes uniformes de objetos idênticos— pense em 1.000 registros de funcionários com o mesmo esquema. Mas os dados da web do mundo real de ferramentas comoweb_data_linkedin_person_profileouweb_data_amazon_productsão:

Heterogêneos— objetos aninhados com esquemas diferentes (experiência,educação, matrizesde atividades)
Não uniformes— tipos de matrizes mistos (algumas entradas têmimg, outras não)
Respostas de objeto único— a maioria das chamadas de API retorna 1 perfil ou 1 produto, não 1.000

Para estruturas profundamente aninhadas ou não uniformes,o JSON minimizado geralmente usa menos tokens do que o TOON. A própria especificação TOON admite isso — o TOON pode realmente usarmaistokens do que o JSON compacto para objetos únicos com aninhamento profundo.

A verdadeira alavanca: mude o que você envia, não como você o formata

Aqui está a informação importante:qualquer otimização no nível do formato (JSON vs TOON vs YAML) é superada pela simples mudança dos dados que você envia.

Não fazemos tudo isso — nossas ferramentas retornam os dados completos das APIs da Bright Data. Masremovemosvaloresnulos, que aparecem com frequência em respostas de Scraping de dados e desperdiçam tokens sem adicionar informações.

A questão é:ajustes de delimitadores economizam ~5-10% na melhor das hipóteses. A filtragem de conteúdo economiza 20-80%.O TOON otimiza a variável errada para dados da web do mundo real.

Imaturidade das ferramentas

O TOON também énovinho em folha— o primeiro commit para a especificação foi em 2 de novembro de 2024. Ele tem literalmente um mês de vida. O JSON tem validadores, editores e bibliotecas em todas as linguagens. O TOON requer Parsing personalizado e carece de suporte do ecossistema.

Um engenheiro resumiu bem: “A primeira vez que vi o TOON, parecia o rascunho incompleto de alguém. Mostre-o ao seu engenheiro de back-end e é provável que ele franza a testa como se você tivesse lhe apresentado um novo problema.”

Nossa decisão

Depois de comparar o TOON com cargas úteis reais da Bright Data (perfis do LinkedIn, produtos da Amazon, SERPs do Google), concluímos:

Pararesultados de pesquisa: o formatoParsed Lightda Bright Data (veja a Camada 2 abaixo) oferece uma redução de 80% nos tokens por meio da filtragem no nível da API, sem a necessidade de codificação personalizada.
Parascraping de dados: o Strip-markdown reduz os tokens em 40%, mantendo as respostas legíveis por humanos — sem necessidade de um novo formato.
Paraconjuntos de dados estruturados: os ganhos reais vêm daeliminação de camposedo truncamento de texto, não da substituição de JSON por TOON.

O TOON é uma ideia brilhante para o caso de uso certo(conjuntos de dados uniformes massivos). Mas para respostas de API da web heterogêneas, as otimizações padrão sempre superam os formatos exóticos.

Camada 1: Remark + Strip-Markdown para Scraping de dados

O desafio: Markdown Bloat

Nossa ferramenta scrape_as_markdown converte qualquer página da web em markdown limpo e compatível com LLM. Mas os conversores de markdown bruto geralmente incluem:

Formatação redundante (negrito, itálico, títulos) que os LLMs não precisam para raciocinar
Texto alternativo e metadados de imagens
Linhas em branco e inconsistências de espaçamento

Para uma postagem de blog ou página de produto típica, o markdown bruto pode ser3 a 5 vezes mais longoque o conteúdo principal.

A solução: Strip-Markdown

Usamosremark+strip-markdownpara reduzir de forma inteligente o markdown a texto simples, preservando a estrutura:

Agradecemos ao projetoremarkpor sua excelente biblioteca de processamento de markdown. Considere apoiar o trabalho deles!

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

// Dentro da ferramenta scrape_as_markdown
const minified_data = await remark()
    .use(strip)
    .process(response.data);
return minified_data.value;

O que é removido?

O pluginstrip-markdownremove:

Negrito/Itálico—**Importante**torna-seImportante
Sintaxe de imagem—![alt text](image.png)torna-sealt text(se necessário) ou fica vazio
Títulos—### Título da seçãotorna-seTítulo da seção(preserva o texto, elimina a marcação)
Blocos de código— Reduz as crases e a formatação, mantendo o conteúdo

O resultado?Texto simples que mantém o significado semântico, mas elimina toda a sobrecarga de formatação.

Exemplo: Antes e depois

Markdown bruto (do Web Unlocker):

# Avaliações do produto

## Feedback do cliente

- **John D.** - ⭐⭐⭐⭐⭐
  *“Ótimo produto! Recomendo muito.”*
  [Leia mais](https://example.com/review/123)

- **Sarah M.** - ⭐⭐⭐⭐
  *“Bom custo-benefício.”*
  [Leia mais](https://example.com/review/456)

![Imagem do produto](https://cdn.example.com/product.jpg)

[Compre agora](https://example.com/buy)

Apósremark().use(strip).process():

Avaliações do produto

Feedback dos clientes

John D. - ⭐⭐⭐⭐⭐
“Ótimo produto! Recomendo muito.”
Leia mais

Sarah M. - ⭐⭐⭐⭐
“Boa relação custo-benefício.”
Leia mais

Imagem do produto

Compre agora

Redução de tokens: ~40%para uma página inteira.

O LLM ainda obtém todo o texto da avaliação, classificações e call to action, mas sem os URLs dos links, caminhos das imagens ou sintaxe de formatação markdown.

Quando usar o Stripped Markdown

Essa otimização é perfeita para:

Tarefas de resumo— “Resuma esta postagem do blog”
Análise de sentimentos— “O que os clientes acham deste produto?”
Extração de entidades— “Extraia nomes de empresas e informações de contato desta página”

Se o seu agente precisarclicar em linksounavegar pela página, use nossas ferramentas do Navegador de scraping (scraping_browser_navigate,scraping_browser_snapshot).

Camada 2: Parsed Light — Projetado para agentes de IA

O problema: as APIs SERP tradicionais não foram criadas para LLMs

As APIs tradicionais de página de resultados de pesquisa (SERP) foram projetadas para humanos que navegam em interfaces da web. Elas retornam tudo:

Anúncios e conteúdo patrocinado que seu agente não precisa
Painéis de conhecimento e trechos em destaque que sobrecarregam as respostas
Campos de metadados redundantes em várias convenções de nomenclatura
Elementos visuais (miniaturas, favicons) que desperdiçam tokens
Pesquisas relacionadas, sugestões de preenchimento automático e seções “as pessoas também perguntam”

O resultado? Uma única pesquisa por 10 resultados pode retornar2.000-3.000 tokensde JSON, quando seu agente LLM precisa apenas delink + título + descrição.

Para agentes de IA que executam fluxos de trabalho de pesquisa em várias etapas, isso é um fator decisivo. Cada token extra se acumula na janela de contexto, limitando o número de consultas que você pode executar antes de atingir os limites.

A solução: formato Parsed Light da Bright Data

Introduzimos o formato de respostaParsed LightAPI, desenvolvido especificamente para agentes de IA que precisam de velocidade e eficiência.

Veja o que o diferencia:

Apenas os 10 principais resultados orgânicos— sem anúncios, sem painéis de conhecimento, sem barra lateral desorganizada
Estrutura de campo consistente— cada resultado temlink,título,descrição eglobal_rank opcional
Design limpo— pré-otimizado no nível da API, para que você não precise de pós-processamento complexo
Tempos de resposta mais rápidos— cargas menores = transferência de rede e Parsing mais rápidos

Em vez de lutar com nomes de campos inconsistentes e respostas inchadas, o Parsed Light oferece exatamente o que os agentes de IA precisam:resultados de pesquisa acionáveis em tokens mínimos.

Parsed Light em ação

Quando você chama nossa ferramentasearch_enginecom o Google como mecanismo, solicitamos automaticamente o formatoparsed_lightda Bright Data:

// Dentro da ferramenta search_engine (para Google)
const response = await axios({
    url: 'https://api.brightdata.com/request',
    method: 'POST',
    data: {
        url: search_url('google', query, cursor),
        zona: ctx.unlocker_zona,
        format: 'raw',
        data_format: 'parsed_light',  // ← O parâmetro mágico
    },
    headers: api_headers(ctx.api_token, ctx.client_name, 'search_engine'),
    responseType: 'text',
});

O que você obtém: JSON limpo e previsível

Aqui está uma resposta real do Parsed Light para uma consulta de pesquisa:

{
  "organic": [
    {
      "link": "https://example.com/pizza",
      "title": "A melhor pizza de Nova York - Joe's Pizza",
      "description": "Pizzaria familiar que serve autênticas fatias de pizza nova-iorquina desde 1975...",
      "global_rank": 1
    },
    {
      "link": "https://example.com/pizza-guide",
      "title": "As 10 melhores pizzarias de Nova York",
      "description": "Descubra as pizzarias mais bem avaliadas em todos os cinco distritos...",
      "classificação global": 2,
      "extensões": [
        {
          "tipo": "link do site",
          "link": "https://example.com/pizza-guide/brooklyn",
          "texto": "Brooklyn"
        }
      ]
    }
    // ... mais 8 resultados
]
}

Observe o quenãoestá presente:

Sem anúncios ou listagens patrocinadas
Sem painéis de gráfico de conhecimento
Sem seções “as pessoas também perguntam”
Sem campos de metadados redundantes
Sem caracteres de controle Unicode ou ruído de formatação

Apenas10 resultados de pesquisa limpos e classificados,prontos para serem processados pelo seu LLM.

Limpeza adicional: o toque final

Mesmo com o Parsing fazendo o trabalho pesado, aplicamos uma etapa de pós-processamento leve para garantir uma consistência perfeita:

função 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 : {};

    // Normalizar para apenas link, título, descrição
    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;  // Ignorar entradas inválidas
            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};
}

Esta limpeza final:

Valida os tipos de dados— Garante queo link,o título ea descriçãosejam strings
Corta espaços em branco— Remove quaisquer espaços à esquerda/direita
Filtra entradas inválidas— Ignora resultados sem campos obrigatórios
Normaliza a paginação— Convertecurrent_pagepara um formato numérico consistente
Remove campos opcionais— Removeglobal_rankeextensõespara manter as respostas ultra-mínimas

O resultado éum JSON à prova de falhasque seu LLM pode analisar sem casos extremos.

Exemplo: Tradicional vs. Parsed Light

API SERP tradicional (antes do 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": "Este é um ótimo produto...",
      "snippet_long": "Este é um ótimo produto com muitos recursos...",
      "subtitle": "Recursos do produto",
      "rating": 4.5,
      "price": "$49.99",
      "image": "https://cdn.example.com/image.jpg",
      "favicon": "https://example.com/favicon.ico"
    }
    // ... mais de 30 resultados, incluindo anúncios, painéis de conhecimento, etc.
  ],
  "knowledge_graph": {...},
  "people_also_ask": [...],
  "related_searches": [...],
  "pagination": {...}
}

~2.500 tokenspara uma resposta típica.

Parsed Light (otimizado para agentes de IA):

{
  "organic": [
    {
      "link": "https://example.com/product",
      "title": "Avaliação incrível do produto",
      "description": "Este é um ótimo produto...",
      "global_rank": 1
    }
    // ... mais 9 resultados (apenas os 10 primeiros)
  ]
}

~600 tokenspara a mesma consulta.

Apósclean_google_search_payload():

{
  "organic": [
    {
      "link": "https://example.com/product",
      "title": "Avaliação incrível do produto",
      "description": "Este é um ótimo produto..."
    }
  ],
  "current_page": 1
}

~500 tokens— umaredução de 80%em relação às APIs SERP tradicionais.

Por que o Parsed Light supera os analisadores tradicionais de Parsing

A maioria das APIs SERP analisa a página inteira e deixa você com a tarefa de limpar a bagunça. O Parsed Light é diferente:

Pré-filtrado na fonte— extrai apenas resultados orgânicos, sem anúncios ou barras laterais
Esquema padronizado— nomes de campos consistentes em todas as consultas (semsnippetvs.descriçãovs.snippet_long)
Design LLM-first— criado para eficiência de tokens desde o início, não como uma ideia tardia
Tempos de resposta inferiores a 1 segundo— O Parsed Light é servido através da infraestrutura de roteamento premium da Bright Data, projetada especificamente para aplicações de IA de missão crítica

Não se trata apenas de economizar tokens, mas derepensar como os dados SERP devem funcionar para agentes de IA.

Criado para agentes de IA em tempo real

O Parsing da Bright Data não é apenas otimizado — ele foi projetado para ser rápido. Com tempos de resposta inferiores a 1 segundo, ele é ideal para:

Enriquecimento de dados em tempo real— Agentes que realizam pesquisas ao vivo durante conversas com usuários
Fluxos de trabalho de pesquisa em várias etapas— encadeie várias consultas sem gargalos de latência
Verificação de fatos— Validação instantânea de alegações e declarações
Aplicativos voltados para o usuário— Recursos baseados em pesquisa que parecem instantâneos

As APIs SERP tradicionais podem levar de 3 a 5 segundos por consulta. Em grande escala, essa latência se agrava. O Parsed Light fornece resultados emmenos de 1 segundo, mantendo seus agentes responsivos e seus usuários engajados.

Impacto combinado: fluxo de trabalho no mundo real

Vamos rastrear o uso de tokens por meio de um fluxo de trabalho realista de um agente:

Tarefa:“Encontre artigos sobre regulamentações de IA e resuma os pontos principais de cada fonte”.

Etapa 1: Pesquisar artigos

Chamadas do agente:search_engine({query: "regulamentações de IA 2024"})

Sem otimização (API SERP tradicional):~2.500 tokens (10 resultados + anúncios + painéis de conhecimento)
Com Parsing Light + limpeza:~500 tokens
Economia:80%(2.000 tokens economizados)

Etapa 2: extrair páginas de artigos

Chamadas do agente:scrape_as_markdown({url: "https://example.com/article"})× 5 artigos

Sem otimização: ~15.000 tokens (5 páginas × 3.000 tokens/página)
Com remark().use(strip): ~9.000 tokens
Economia: 40% (6.000 tokens economizados)

Etapa 3: Pesquisa adicional

Chamadas do agente:search_engine({query: "detalhes da Lei de IA da UE"})para pesquisa de acompanhamento

Sem otimização: ~2.500 tokens
Com Parsing Light + limpeza: ~500 tokens
Economia: 80% (2.000 tokens economizados)

Economia total no fluxo de trabalho

Sem otimização: 20.000 tokens
Com otimização: 10.000 tokens
Redução geral: 50% (10.000 tokens economizados)

A US$ 3 por milhão de tokens de entrada (preço do Claude Sonnet), isso representa uma economia de US$ 0,030 por fluxo de trabalho. Execute isso 1.000 vezes por dia e você economizará US$ 30/diaou US$ 10.950/ano.

Mas o valor real não é apenas a economia de custos, éo rendimento. Com essas otimizações, seus agentes podem executar fluxos de trabalho mais complexos na mesma janela de contexto, concluindo tarefas mais rapidamente e lidando com consultas mais sofisticadas.

Por que isso é importante para fluxos de trabalho de agentes

A otimização de tokens não se resume apenas ao custo. Trata-se depermitir fluxos de trabalho mais complexosdentro das janelas de contexto.

Com uma janela de contexto de 200 mil tokens:

Sem otimização:você pode processar cerca de 10 fluxos de trabalho com várias etapas antes de atingir o limite
Com otimização:você pode processar cerca de 20 fluxos de trabalho na mesma janela

Isso representaum aumento de 100% na produtividadecom a mesma infraestrutura.

E quando você combina isso comos Grupos de Ferramentasdo Dia 1 (redução de 60-95% nos tokens de prompt do sistema) eas Ferramentas Personalizadasdo Dia 2 (seleção cirúrgica de ferramentas), você obtém uma redução total massiva de tokens em todo o ciclo de vida do agente (prompt do sistema + chamadas de ferramentas + respostas de ferramentas).

Detalhes técnicos: dependências do pacote

Ambas as camadas de otimização são implementadas usando bibliotecas de código aberto testadas em batalha:

remark— Processador Markdown (usado por MDX, Gatsby, Next.js)
strip-markdown— Plug-in Remark para remoção de formatação

Essas são as mesmas ferramentas usadas por sites de produção que processam milhões de solicitações por dia.

Veja a diferença

Quer medir o impacto? Compare as contagens de tokens:

Chame uma ferramentasearch_enginee conte os tokens na resposta
Compare com uma resposta tradicional da API SERP para a mesma consulta
Use o tokenizador do seu provedor LLM (por exemplo,tiktokenpara OpenAI/Claude)

Você verá uma redução de 80% nas pesquisas do Google, 40% nas páginas raspadas e 50% nos Conjuntos de dados estruturados.

Isso não é apenas otimização, é uma reformulação completa de como os dados da web devem ser entregues aos agentes de IA.

Resumo das estatísticas de desempenho

Otimização	Ferramentas afetadas	Redução de tokens	Caso de uso
Strip-Markdown	`scrape_as_markdown`	~40%	Resumos de páginas da Web, extração de conteúdo
Parsed Light	`search_engine` (apenas Google)	~80%	Parsing de resultados de pesquisa, geração de leads, fluxos de trabalho de pesquisa

O que vem a seguir?

Amanhã (dia 4), lançaremos integrações empresariais que levam nosso servidor MCP para as plataformas que suas equipes já utilizam.

Fique ligado.