El parser basado en selectores CSS se rompe cuando el sitio cambia su diseño. El parser basado en LLM no se rompe, pero cobra por cada página. En 2026, la elección entre ellos dejó de ser una cuestión de gusto: los precios de los modelos se dispararon en decenas de veces, y la misma página puede costar 3,000 o 20,000 tokens dependiendo de lo que envíes al modelo. A continuación, se presenta una comparación de tres enfoques en términos de costos, fiabilidad y tráfico de proxy, calculando para 1,000 y un millón de páginas.
En resumen: qué elegir
- Selectores (CSS/XPath) — un solo patrón de página, grandes volúmenes, diseño estable. El costo de extracción es casi nulo, pero el soporte recae en el desarrollador.
- Extracción LLM — muchos sitios diferentes, diseño inestable, tareas puntuales. Pagas por tokens en cada página y debes validar la respuesta.
- Híbrido — LLM escribe selectores una vez, luego funcionan los selectores, y el modelo se llama solo cuando la verificación de datos falla. Para la mayoría de los parsers permanentes, esto es lo óptimo.
Criterios de comparación
Comparamos en cinco puntos que realmente afectan el costo final y la calidad de los datos:
- costo de extracción por 1,000 páginas;
- comportamiento al cambiar el diseño;
- precisión y riesgo de valores inventados;
- velocidad y latencia;
- consumo de tráfico de proxy — como verás, depende poco del método elegido.
Cuánto cuesta la extracción LLM: calculamos según las tarifas de octubre de 2026
Precios oficiales por millón de tokens (entrada/salida) en la tarifa estándar:
- Gemini 2.5 Flash-Lite — $0.10 / $0.40;
- Gemini 3.1 Flash-Lite — $0.25 / $1.50;
- Claude Haiku 4.5 — $1 / $5;
- Gemini 3.5 Flash — $1.50 / $9.
Google y Anthropic tienen una API Batch con un 50% de descuento en entrada y salida — para el scraping donde la respuesta no es necesaria de inmediato, este es el primer palanca de ahorro.
La variable principal no es el modelo, sino lo que envías a él
Una página HTML cruda al ser enviada al modelo generalmente ocupa entre 10,000 y 40,000 tokens. Cloudflare, al lanzar la función Markdown for Agents, dio un ejemplo: la misma entrada de blog pesa 16,180 tokens en HTML y 3,150 tokens en Markdown — una reducción del 80%. Otras mediciones en noticias, documentación y tarjetas de productos muestran reducciones de entre 67% y 94%.
Para el cálculo, tomaremos las siguientes suposiciones: página cruda — 20,000 tokens, limpiada a Markdown — 3,000, más 500 tokens para instrucciones y esquema, y 300 tokens de salida en JSON. Para 1,000 páginas obtenemos:
| Modelo | HTML Crudo (20.5 millones de entrada) | Markdown (3.5 millones de entrada) |
|---|---|---|
| Gemini 2.5 Flash-Lite | ≈ $2.17 | ≈ $0.47 |
| Gemini 3.1 Flash-Lite | ≈ $5.58 | ≈ $1.33 |
| Claude Haiku 4.5 | ≈ $22.00 | ≈ $5.00 |
| Gemini 3.5 Flash | ≈ $33.45 | ≈ $7.95 |
La diferencia es de 70 veces entre la peor y la mejor opción con el mismo resultado. Dos tercios de esta diferencia provienen de la limpieza de la entrada, no de la elección del modelo. En un millón de páginas al mes, esto es alrededor de $470 o más de $33,000.
Otro detalle: los modelos Claude a partir de la versión 4.7 utilizan un nuevo tokenizador que, según datos de Anthropic, proporciona aproximadamente un 30% más de tokens para el mismo texto. Al comparar las cuentas de diferentes generaciones de modelos, ten en cuenta esto: Haiku 4.5 trabaja con el antiguo tokenizador.
Selectores: casi gratis, hasta que el sitio cambie
Ejecutar un selector CSS o XPath en una página ya descargada cuesta una fracción de milisegundo de CPU. En la guía de ScrapingBee, la estimación es que en un diseño estable, un selector es aproximadamente 10 veces más barato y rápido que la extracción LLM. En la práctica, la diferencia es aún mayor, porque el selector no tiene una solicitud de red a la API del modelo.
El costo de los selectores radica en el soporte:
- el sitio renombró una clase o envolvió un bloque en un nuevo div — el parser devuelve silenciosamente campos vacíos;
- las pruebas A/B muestran diferentes patrones a diferentes visitantes, y algunas páginas no se parsean;
- en 50 sitios diferentes mantienes 50 conjuntos de selectores.
El escenario más peligroso no es la caída, sino la corrupción silenciosa de datos: el selector agarra un elemento vecino, y durante semanas se escribe en la base de datos un precio antiguo en lugar del actual.
LLM: resistente al diseño, pero puede inventar
Los modelos no necesitan un camino exacto al elemento — buscan "precio" por su significado. Esto elimina el problema de las clases renombradas y los diferentes patrones. Pero surgen tres tipos de fallos típicos que describen todos los que han ejecutado tales parsers en producción:
- valores inventados — el modelo "adivina" un precio o artículo que no están en la página;
- campos omitidos — parte de los datos no se extraen;
- deriva de estructura — una cadena en lugar de un número, otro nombre de clave.
La protección es obligatoria: un esquema de respuesta estricto, validación (por ejemplo, Pydantic), temperatura = 0 y repetición en caso de error. Cero temperatura reduce la dispersión, pero no elimina completamente las alucinaciones. Para precios y existencias, es razonable agregar una verificación de "el valor realmente aparece en el texto de la página".
La latencia también es mayor: al tiempo de carga de la página a través de un proxy se le suma la respuesta del modelo — desde fracciones de segundo hasta varios segundos. Para monitoreo una vez al día, esto no importa, pero para rastrear caídas, es crítico.
Híbrido: LLM escribe selectores, no extrae datos
El tercer camino es directamente apoyado por bibliotecas populares. En Crawl4AI hay una función de generación de esquema: el modelo observa una vez muestras de HTML y devuelve un conjunto de selectores CSS/XPath, después de lo cual la extracción se realiza sin llamadas a LLM. La documentación enfatiza que este es un costo único, y el esquema se puede reutilizar sin restricciones; con varias muestras, el modelo a menudo elige selectores más resistentes por atributos en lugar de frágiles posicionales como nth-child.
El esquema operativo del híbrido:
- LLM genera selectores a partir de 3-5 muestras de páginas de un solo patrón.
- El parser trabaja con los selectores, cada entrada es verificada por un validador: campos en su lugar, tipos correctos, precio en un rango razonable.
- Si la proporción de entradas no válidas supera el umbral (digamos, 2-5%), la página pasa a extracción LLM, y el esquema se regenera.
- El nuevo esquema se ejecuta en una muestra de control y solo después reemplaza al antiguo.
Así, pagas por el modelo solo en momentos de cambio de diseño, y no por cada una de las millones de páginas.
Tabla resumen
| Criterio | Selectores | Extracción LLM | Híbrido |
|---|---|---|---|
| Costo de extracción | casi cero | $0.5–33 por 1,000 págs. | casi cero + llamadas únicas |
| Cambio de diseño | se rompe, a menudo en silencio | generalmente sobrevive | se repara automáticamente |
| Riesgo de datos inventados | ninguno (pero hay "no es el elemento") | existe, se necesita validación | mínimo |
| Velocidad | máxima | + respuesta del modelo en cada página | como los selectores |
| Muchos sitios diferentes | costoso de mantener | punto fuerte | bueno, esquema para cada patrón |
| Tráfico de proxy | igual — el modelo no reduce los bytes descargados | ||
Sobre proxies: LLM no ahorra tráfico
Un error común en los cálculos es pensar que un parser "inteligente" es más barato en la red. No es así: la conversión de HTML a Markdown ocurre después de la descarga, por lo que a través del proxy pasa la página completa con cualquier método de extracción. La excepción son los sitios donde el propietario ha habilitado la entrega de Markdown mediante el encabezado Accept: text/markdown (como en la función de Cloudflare), pero esta es una decisión del sitio, no tuya.
Para dar una idea: con un peso de HTML de 200 KB sin imágenes, 1,000 páginas equivalen a aproximadamente 0.2 GB, o alrededor de $0.54 en proxies residenciales a $2.70 por GB. Compara con la tabla anterior: al enviar HTML crudo a Claude Haiku 4.5, la cuenta por el modelo será 40 veces mayor que la cuenta por el proxy, mientras que con Markdown y Flash-Lite son comparables. Si renderizas páginas con un navegador sin cabeza, el tráfico aumentará varias veces — hay mediciones en nuestra comparación del consumo de tráfico de Playwright, Puppeteer y requests en 1,000 páginas.
Lo que realmente afecta el tráfico con cualquier método:
- no descargar imágenes, fuentes y analíticas si no son necesarias;
- buscar un API JSON interno en lugar de HTML;
- no hacer repeticiones innecesarias: cada baneo y reintento son bytes pagados. Más sobre por qué el costo por GB es engañoso, en el análisis del costo real de un registro exitoso.
Para catálogos simples sin protección anti-bots estricta, son suficientes proxies de centros de datos a $1.50 por GB; los residenciales son necesarios donde las IP de los hosting son bloqueadas a la entrada.
Recomendaciones para escenarios
- Monitoreo de precios de uno a tres marketplaces, cientos de miles de tarjetas. Híbrido o selectores limpios con validador. Conectar LLM solo para regenerar el esquema.
- Recolección de datos de cientos de sitios diversos (leads, ofertas, contactos). Extracción LLM en Markdown a través de un modelo barato en modo batch. No iniciar sin un esquema estricto y validación.
- Investigación puntual en miles de páginas. LLM: por unos pocos dólares ahorras días en escribir selectores.
- Datos donde un error cuesta dinero (precios para repricing, existencias). Selectores o híbrido más verificación del valor con el texto original de la página.
- RAG y bases de conocimiento. Aquí se necesita texto limpio, no estructura: conversión a Markdown sin extracción de campos, el modelo solo en la etapa de respuesta.
Conclusión
La extracción LLM no ha reemplazado a los selectores, sino que ha desplazado el punto de elección. Lo más barato es el híbrido: el modelo escribe y repara selectores, no lee cada página. Si no puedes evitar el modelo en cada página, primero limpia la entrada a Markdown y utiliza batch: estos dos pasos reducen la cuenta entre 5 y 10 veces antes de que empieces a elegir un modelo. Y recuerda que el tráfico de proxy no depende del método de extracción: debes ahorrar en lo que descargas, no en cómo lo procesas.