Menú de Accesibilidad saltar al contenido
day3

Token Optimization – Getting More from Less

17 min de lectura

Optimización de tokens: sacar más partido con menos

Ayer le mostramos cómo crear agentes personalizados con una selección quirúrgica de herramientas. Hoy profundizamos en el tema:optimización de tokens.

Seleccionar las herramientas adecuadas es solo la mitad del trabajo. Lo que realmente marca la diferencia es optimizar lo que esas herramientasdevuelven. Hemos rediseñado nuestras canalizaciones de datos para ofrecer la máxima precisión y, al mismo tiempo, utilizarentre un 40 % y un 80 % menos de tokensen los resultados.

Así es como lo hemos hecho.

El problema: exceso de datos

Cuando se llama a una herramienta comoscrape_as_markdownosearch_engine, la API devuelve datos enriquecidos. Pero aquí está el problema: la mayoría de esos datos están formateados parahumanos, no paraLLM.

Las API tradicionales incluyen una sobrecarga innecesaria:

  • Formato redundante (negrita, cursiva, encabezados) que los LLM no necesitan
  • Anuncios y contenido patrocinado mezclados con resultados orgánicos
  • Metadatos de imágenes y elementos visuales que desperdician tokens
  • Nombres de campos inconsistentes y metadatos redundantes

En el caso de un rastreo típico de una página web o una consulta de búsqueda, a menudo se obtienenentre 3 y 5 veces más datosde los que el LLM realmente necesita para el razonamiento.

La solución: optimización de tokens en dos capas

Hemos implementado unaestrategia de optimización por capasque se centra en diferentes tipos de datos:

  1. Remark + Strip-Markdownpara el contenido de páginas web (scrape_as_markdown)
  2. Parseo de Light + Cleaning de Payloadpara los resultados de los motores de búsqueda (search_engine)

Analicemos cada capa.

Pero, un momento, ¿por qué no TOON?

Quizás te preguntes: ¿qué pasa con TOON (Token-Oriented Object Notation)? Inicialmente lo exploramos como una tercera capa de optimización para Conjuntos de datos estructurados, como perfiles de LinkedIn y productos de Amazon.

TOON es un formato inteligente que utiliza sangría y diseños tabulares para reducir los tokens. Sobre el papel, ofrece un ahorro del 30-60 % para matrices uniformes de objetos idénticos. Pero cuando lo probamos en respuestas API reales de Bright Data, descubrimos algo importante:

El delimitador no es el cuello de botella, sino los datos en sí mismos.

La ilusión del delimitador

Si observamos una respuesta típica de un perfil de LinkedIn, la mayoría de los tokens provienen de:

  • Campos de texto largos (acerca de,recomendaciones,actividad[].título)
  • URL largas (avatar,banner_image,activity[].link,credential_url)

El delimitador (n,|,t) es unapequeña fraccióndel recuento total de tokens.

La nueva línea (n) ya es:

  • Un token único y muy comúnen todos los principales tokenizadores LLM
  • Alineado de forma natural con la forma en que los modelos fragmentan el texto (orientado a líneas)
  • No aparece dentro de las URL ni en la mayor parte del texto, lo que evita problemas de escape

Los separadores exóticos como|,^ ox1Fpueden reducir las comillas en algunos puntos, pero a menudo introducensecuencias raras de múltiples tokensque anulan cualquier ventaja.

Respuesta breve: si solo se modifica el delimitador,nya es lo mejor que se puede conseguir para este tipo de datos.

Dónde falla TOON

TOON destaca enmatrices uniformes de objetos idénticos, como 1000 registros de empleados con el mismo esquema. Pero los datos web del mundo real de herramientas comoweb_data_linkedin_person_profileoweb_data_amazon_productson:

  • Heterogéneos: objetos anidados con diferentes esquemas (matrices deexperiencia,educación,actividad).
  • No uniformes: tipos de matrices mixtas (algunas entradas tienenimg, otras no).
  • Respuestas de un solo objeto: la mayoría de las llamadas a la API devuelven 1 perfil o 1 producto, no 1000.

Para estructuras profundamente anidadas o no uniformes,el JSON minificado suele utilizar menos tokens que TOON. La propia especificación TOON lo admite: TOON puede utilizarmástokens que el JSON compacto para objetos únicos con anidamiento profundo.

La verdadera palanca: cambia lo que envías, no cómo lo formateas

He aquí la idea importante:cualquier optimización a nivel de formato (JSON frente a TOON frente a YAML) queda eclipsada por el simple hecho de cambiar los datos que envías.

Nosotros no hacemos todo eso: nuestras herramientas devuelven los datos completos de las API de Bright Data. Peroeliminamos los valoresnulos, que aparecen con frecuencia en las respuestas de Scraping web y desperdician tokens sin añadir información.

La cuestión es quelos ajustes de los delimitadores ahorran, como mucho, entre un 5 % y un 10 %. El filtrado de contenido ahorra entre un 20 % y un 80 %.TOON optimiza la variable equivocada para los datos web del mundo real.

Inmadurez de las herramientas

TOON también escompletamente nuevo: el primer compromiso con la especificación fue el 2 de noviembre de 2024. Literalmente, tiene un mes de antigüedad. JSON tiene validadores, editores y bibliotecas en todos los lenguajes. TOON requiere un parseo personalizado y carece de soporte del ecosistema.

Un ingeniero lo expresó muy bien: «La primera vez que vi TOON, me pareció el borrador a medio terminar de alguien. Si se lo enseñas a tu ingeniero de backend, es posible que frunza el ceño como si le hubieras traído un nuevo problema».

Nuestra decisión

Después de comparar TOON con cargas útiles reales de Bright Data (perfiles de LinkedIn, productos de Amazon, SERP de Google), llegamos a la siguiente conclusión:

  • Paralos resultados de búsqueda: el formatoParsed Lightde Bright Data (véase la capa 2 más abajo) ofrece una reducción del 80 % de los tokens mediante el filtrado a nivel de API, sin necesidad de codificación personalizada.
  • Parael scraping web: Strip-markdown reduce los tokens en un 40 % y mantiene las respuestas legibles para los humanos, sin necesidad de un nuevo formato.
  • Paraconjuntos de datos estructurados: las verdaderas ventajas provienen deeliminar camposytruncar texto, no de sustituir JSON por TOON.

TOON es una idea brillante para el caso de uso adecuado(conjuntos de datos uniformes masivos). Pero para respuestas API web heterogéneas, las optimizaciones estándar siempre superan a los formatos exóticos.


Capa 1: Remark + Strip-Markdown para el Scraping web

El reto: la sobrecarga de Markdown

Nuestra herramienta scrape_as_markdown convierte cualquier página web en un markdown limpio y compatible con LLM. Pero los convertidores de markdown sin procesar suelen incluir:

  • Formato redundante (negrita, cursiva, encabezados) que los LLM no necesitan para el razonamiento
  • Texto alternativo y metadatos de imágenes
  • Líneas vacías e inconsistencias en el espaciado

En una entrada de blog o página de producto típica, el markdown sin procesar puede serentre 3 y 5 veces más largoque el contenido principal.

La solución: Strip-Markdown

Utilizamosremark+strip-markdownpara reducir de forma inteligente el marcado a texto sin formato, conservando la estructura:

Agradecemos al proyectoremarksu excelente biblioteca de procesamiento de markdown. ¡Considera apoyar su trabajo!

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

// Dentro de la herramienta scrape_as_markdown
const minified_data = await remark()
    .use(strip)
    .process(response.data);
return minified_data.value;

¿Qué se elimina?

El complementostrip-markdownelimina:

  • Negrita/Cursiva**Importante**se convierte enImportante
  • Sintaxis de imagen![texto alternativo](imagen.png)se convierte entexto alternativo(si es necesario) o se deja vacío
  • Encabezados### Título de la secciónse convierte enTítulo de la sección(conserva el texto, elimina el marcado)
  • Bloques de código: reduce las comillas invertidas y el formato, pero conserva el contenido

¿El resultado?Texto sin formato que conserva el significado semántico, pero elimina toda la sobrecarga de formato.

Ejemplo: antes y después

Markdown sin procesar (de Web Unlocker):

# Reseñas de productos

## Comentarios de los clientes

- **John D.** - ⭐⭐⭐⭐⭐
  *«¡Un producto fantástico! Muy recomendable».*
  [Leer más](https://example.com/review/123)

- **Sarah M.** - ⭐⭐⭐⭐
  *«Buena relación calidad-precio».*
  [Leer más](https://example.com/review/456)

![Imagen del producto](https://cdn.example.com/product.jpg)

[Comprar ahora](https://example.com/buy)

Después deremark().use(strip).process():

Reseñas del producto

Opiniones de los clientes

John D. - ⭐⭐⭐⭐⭐
«¡Un producto fantástico! Muy recomendable».
Leer más

Sarah M. - ⭐⭐⭐⭐
«Buena relación calidad-precio».
Leer más

Imagen del producto

Comprar ahora

Reducción de tokens: ~40 %para una página completa.

El LLM sigue obteniendo todo el texto de las reseñas, las valoraciones y las llamadas a la acción, pero sin las URL de los enlaces, las rutas de las imágenes ni la sintaxis de formato Markdown.

Cuándo utilizar Stripped Markdown

Esta optimización es perfecta para:

  • Tareas de resumen: «Resume esta entrada del blog».
  • Análisis de opiniones: «¿Qué opinan los clientes sobre este producto?».
  • Extracción de entidades: «Extraiga los nombres de las empresas y la información de contacto de esta página».

Si su agente necesita hacerclic en enlacesonavegar por la página, utilice nuestras herramientas del Navegador de scraping (scraping_browser_navigate,scraping_browser_snapshot).


Capa 2: Parsed Light: diseñado para agentes de IA

El problema: las API SERP tradicionales no se crearon para los LLM

Las API tradicionales de la página de resultados del motor de búsqueda (SERP) se diseñaron para que los humanos navegaran por las interfaces web. Devuelven todo:

  • Anuncios y contenido patrocinado que su agente no necesita
  • Paneles de conocimiento y fragmentos destacados que sobrecargan las respuestas
  • Campos de metadatos redundantes en múltiples convenciones de nomenclatura
  • Elementos visuales (miniaturas, favicons) que desperdician tokens
  • Búsquedas relacionadas, sugerencias de autocompletado y secciones de «la gente también pregunta»

¿El resultado? Una sola búsqueda de 10 resultados puede devolverentre 2000 y 3000 tokensde JSON, cuando su agente LLM solo necesitael enlace, el título y la descripción.

Para los agentes de IA que ejecutan flujos de trabajo de investigación de varios pasos, esto es un factor decisivo. Cada token adicional se acumula en la ventana de contexto, lo que limita el número de consultas que se pueden ejecutar antes de alcanzar los límites.

La solución: el formato Parsed Light de Bright Data

Hemos introducido el formato de respuesta APIParsed Light, diseñado específicamente para agentes de IA que necesitan velocidad y eficiencia.

Esto es lo que lo hace diferente:

  • Solo los 10 resultados orgánicos principales: sin anuncios, sin paneles de conocimiento, sin barras laterales que distraigan
  • Estructura de campos coherente: cada resultado tieneun enlace,un título,una descripción yun global_rank opcional.
  • Diseño limpio:preoptimizado a nivel de API, por lo que no es necesario un posprocesamiento complejo.
  • Tiempos de respuesta más rápidos: cargas útiles más pequeñas = transferencia de red y Parseo más rápidos.

En lugar de lidiar con nombres de campos inconsistentes y respuestas infladas, Parsed Light ofrece exactamente lo que los agentes IA necesitan:resultados de búsqueda procesables en tokens mínimos.

Parsed Light en acción

Cuando llamas a nuestra herramientasearch_enginecon Google como motor, solicitamos automáticamente el formatoparsed_lightde Bright Data:

// Dentro de la herramienta 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',  // ← El parámetro mágico
    },
    headers: api_headers(ctx.api_token, ctx.client_name, 'search_engine'),
    responseType: 'text',
});

Lo que obtienes: JSON limpio y predecible

Aquí tienes una respuesta real de Parsed Light para una consulta de búsqueda:

{
  "organic": [
    {
      "link": "https://example.com/pizza",
      "title": "La mejor pizza de Nueva York: Joe's Pizza",
      "description": "Pizzería familiar que sirve auténticas porciones de pizza neoyorquina desde 1975...",
      "global_rank": 1
    },
    {
      "link": "https://example.com/pizza-guide",
      "title": "Las 10 mejores pizzerías de Nueva York",
      "description": "Descubre las pizzerías mejor valoradas de los cinco distritos...",
      "global_rank": 2,
      "extensions": [
        {
          "type": "site_link",
          "link": "https://example.com/pizza-guide/brooklyn",
          "text": "Brooklyn"
        }
      ]
    }
    // ... 8 resultados más
]
}

Fíjate en lo quenoaparece:

  • No hay anuncios ni listados patrocinados
  • No hay paneles de gráficos de conocimiento
  • No hay secciones «la gente también pregunta»
  • Sin campos de metadatos redundantes
  • Sin caracteres de control Unicode ni ruido de formato

Solo10 resultados de búsqueda limpios y clasificados,listos para que su LLM los procese.

Limpieza adicional: el toque final

Incluso con Parsed Light haciendo el trabajo pesado, aplicamos un paso de posprocesamiento ligero para garantizar una consistencia perfecta:

función 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 a solo enlace, título y descripción
    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;  // Omitir entradas no vá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 limpieza final:

  1. Valida los tipos de datos: garantiza queel enlace,el título yla descripciónsean cadenas.
  2. Recorta los espacios en blanco: elimina los espacios iniciales y finales
  3. Filtra las entradas no válidas: omite los resultados que no contienen los campos obligatorios
  4. Normaliza la paginación: conviertecurrent_pagea un formato numérico coherente
  5. Elimina los campos opcionales: eliminaglobal_rankylas extensionespara mantener las respuestas ultra minimalistas

El resultado esun JSON a prueba de fallosque su LLM puede parsear sin casos extremos.

Ejemplo: tradicional frente a Parsed Light

API SERP tradicional (antes de 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 es un producto excelente...",
      "snippet_long": "Este es un producto excelente con muchas características...",
      "subtitle": "Características del producto",
      "rating": 4.5,
      "price": "$49.99",
      "image": "https://cdn.example.com/image.jpg",
      "favicon": "https://example.com/favicon.ico"
    }
    // ... Más de 30 resultados adicionales, incluyendo anuncios, paneles de conocimiento, etc.
  ],
  "knowledge_graph": {...},
  "people_also_ask": [...],
  "related_searches": [...],
  "pagination": {...}
}

~2500 tokenspara una respuesta típica.

Parsed Light (optimizado para agentes de IA):

{
  "organic": [
    {
      "link": "https://example.com/product",
      "title": "Amazing Product Review",
      "description": "This is a great product...",
      "global_rank": 1
    }
    // ... 9 resultados más (solo los 10 primeros)
  ]
}

~600 tokenspara la misma consulta.

Después declean_google_search_payload():

{
  "organic": [
    {
      "link": "https://example.com/product",
      "title": "Reseña de un producto increíble",
      "description": "Este es un producto fantástico..."
    }
  ],
  "current_page": 1
}

~500 tokens, lo que supone unareducción del 80 %con respecto a las API SERP tradicionales.

Por qué Parsed Light supera a los analizadores tradicionales de parseo

La mayoría de las API SERP analizan toda la página y te dejan a ti la tarea de limpiar el desorden. Parsed Light es diferente:

  • Prefiltrado en el origen: solo extrae resultados orgánicos, sin anuncios ni barras laterales.
  • Esquema estandarizado: nombres de campos coherentes en todas las consultas (sinfragmentosfrente adescripcionesfrente afragmentos largos).
  • Diseño LLM-first: creado para la eficiencia de tokens desde el primer día, no como una idea de último momento.
  • Tiempos de respuesta inferiores a 1 segundo: Parsed Light se sirve a través de la infraestructura de enrutamiento premium de Bright Data, diseñada específicamente para aplicaciones de IA de misión crítica.

No se trata solo de ahorrar tokens, sino dereplantearse cómo deben funcionar los datos SERP para los agentes de IA.

Creado para agentes de IA en tiempo real

Parsed Light de Bright Data no solo está optimizado, sino que está diseñado para la velocidad. Con tiempos de respuesta inferiores a 1 segundo, es ideal para:

  • Enriquecimiento de datos en tiempo real: agentes que realizan búsquedas en directo durante las conversaciones de los usuarios.
  • Flujos de trabajo de investigación de varios pasos: encadenar múltiples consultas sin cuellos de botella de latencia.
  • Verificación de datos: validación instantánea de afirmaciones y declaraciones.
  • Aplicaciones orientadas al usuario: funciones basadas en búsquedas que se sienten instantáneas

Las API SERP tradicionales pueden tardar entre 3 y 5 segundos por consulta. A gran escala, esa latencia se acumula. Parsed Light ofrece resultados enmenos de 1 segundo, lo que mantiene a sus agentes receptivos y a sus usuarios comprometidos.


Impacto combinado: flujo de trabajo en el mundo real

Rastreemos el uso de tokens a través de un flujo de trabajo realista de un agente:

Tarea:«Buscar artículos sobre la normativa en materia de IA y resumir los puntos clave de cada fuente».

Paso 1: Buscar artículos

El agente llama a:search_engine({query: «normativa sobre IA 2024»})

Sin optimización (API SERP tradicional):~2500 tokens (10 resultados + anuncios + paneles de conocimiento)
Con Parsed Light + limpieza:~500 tokens
Ahorro:80 %(2000 tokens ahorrados)

Paso 2: extraer páginas de artículos

Llamadas del agente:scrape_as_markdown({url: "https://example.com/article"})× 5 artículos

Sin optimización: ~15 000 tokens (5 páginas × 3000 tokens/página)
Con remark().use(strip): ~9000 tokens
Ahorro: 40 % (6000 tokens ahorrados)

Paso 3: Investigación adicional

Llamadas del agente:search_engine({query: "EU IA Act details"})para investigación de seguimiento

Sin optimización: ~2500 tokens
Con Parsed Light + limpieza: ~500 tokens
Ahorro: 80 % (2000 tokens ahorrados)

Ahorro total en el flujo de trabajo

Sin optimización: 20 000 tokens
Con optimización: 10 000 tokens
Reducción total: 50 % (10 000 tokens ahorrados)

A 3 $ por cada millón de tokens de entrada (precio de Claude Sonnet), se ahorran 0,030 $ por flujo de trabajo. Si se ejecuta 1000 veces al día, se ahorran 30 $ al díao 10 950 $ al año.

Pero el valor real no es solo el ahorro de costes, sino tambiénel rendimiento. Con estas optimizaciones, sus agentes pueden ejecutar flujos de trabajo más complejos en la misma ventana de contexto, completando las tareas más rápidamente y gestionando consultas más sofisticadas.


Por qué es importante para los flujos de trabajo de los agentes

La optimización de tokens no se limita al coste. Se trata depermitir flujos de trabajo más complejosdentro de las ventanas de contexto.

Con una ventana de contexto de 200 000 tokens:

  • Sin optimización:puede procesar ~10 flujos de trabajo de varios pasos antes de alcanzar el límite.
  • Con optimización:puede procesar ~20 flujos de trabajo en la misma ventana

Eso suponeun 100 % más de rendimientocon la misma infraestructura.

Y si se combina esto conlos grupos de herramientasdel día 1 (reducción del 60-95 % en los tokens de solicitud del sistema) ylas herramientas personalizadasdel día 2 (selección quirúrgica de herramientas), se obtiene una reducción total masiva de tokens en todo el ciclo de vida del agente (solicitud del sistema + llamadas a herramientas + respuestas de herramientas).

Detalles técnicos: Dependencias de paquetes

Ambas capas de optimización se implementan utilizando bibliotecas de código abierto probadas en combate:

  • remark: procesador Markdown (utilizado por MDX, Gatsby y Next.js)
  • strip-markdown: complemento de Remark para eliminar el formato

Estas son las mismas herramientas que utilizan los sitios de producción que procesan millones de solicitudes al día.


Vea la diferencia

¿Quiere medir el impacto? Compare el recuento de tokens:

  1. Llama a una herramientasearch_enginey cuenta los tokens en la respuesta
  2. Compárelo con una respuesta tradicional de la API SERP para la misma consulta
  3. Utilice el tokenizador de su proveedor de LLM (por ejemplo,tiktokenpara OpenAI/Claude).

Verá una reducción del 80 % en las búsquedas de Google, del 40 % en las páginas rastreadas y del 50 % en los Conjuntos de datos estructurados.

No se trata solo de optimización, sino de un replanteamiento completo de cómo se deben entregar los datos web a los agentes de IA.


Resumen de estadísticas de rendimiento

Optimización Herramientas afectadas Reducción de tokens Caso de uso
Strip-Markdown scrape_as_markdown ~40 Resúmenes de páginas web, extracción de contenido
Parsed Light search_engine (solo Google) ~80 % Parseo de resultados de búsqueda, generación de clientes potenciales, flujos de trabajo de investigación

¿Qué viene después?

Mañana (día 4), lanzaremos integraciones empresariales que llevarán nuestro servidor MCP a las plataformas que ya utilizan sus equipos.

Estén atentos.

¿Listo para empezar?
Explora el servidor MCP de la web y comienza a construir potentes agentes de IA.
Leer documentación Ver el Repositorio