Cuando la extracción con LLM deja de ser rentable

Firecrawl cobra 1 crédito por hacer scraping de una página y 5 créditos por extraer campos estructurados de la misma página (Firecrawl pricing, 2026). Eso es un recargo de 5x por el mismo HTML, enviado a través de un modelo.

La propuesta es real: describes lo que quieres, recibes un JSON de vuelta, sin selectores que mantener. Para diseños inestables y objetivos de una sola vez, justifica el recargo. Pero para el pipeline de producción que extrae 500k páginas de productos al día de las mismas cinco tiendas, no es así.

Hemos visto a equipos implementar la extracción con LLM por defecto, llegar al mes de facturación y empezar a buscar una salida. La solución no suele ser abandonar los LLM. Consiste en colocarlos en el lugar adecuado del pipeline.

Los números se complican rápidamente

Tomemos a Firecrawl en el extremo más barato. El scraping más la extracción con IA cuesta 6 créditos por página sin crawl, y 7 créditos con crawl (ScrapeGraphAI breakdown, 2026). Procesar 100k páginas al día en su plan de crecimiento cuesta aproximadamente $21 000 al mes antes de reintentos, y antes de haber pagado por un solo proxy.

Ejecuta tu propio pipeline de LLM y los números cambian, pero no disminuyen. GPT-4o cuesta $2.50 por millón de tokens de entrada y $10 por millón de salida (PricePerToken, 2026). Una página de producto después de la conversión a markdown consume entre 4k y 8k tokens de entrada. Digamos 6k de entrada y 200 de salida para un bloque JSON. Con 100k páginas al día, eso representa $360 diarios, $11 000 mensuales por una tarea que los selectores CSS hacen gratis tras una única configuración.

Ese es el modelo barato. Pasa a Claude Sonnet 4.6 ($3 de entrada, $15 de salida) y la factura se duplica (PE Collective, 2026). Pasa a un modelo de razonamiento y añade una penalización de 3 a 10 veces más, dependiendo de cuánto piense antes de responder.

Nada de eso tiene en cuenta los fallos. Una tasa de alucinación del 3-5% parece inofensiva hasta que haces las cuentas. Con 100k páginas al día, eso representa entre 3000 y 5000 registros erróneos que entran en tu data warehouse, con una apariencia idéntica a los correctos porque el modelo los entregó con total seguridad. Como señaló DataHen: "No es que la IA se equivoque a veces. Es que se equivoca con total seguridad." (DataHen, 2026).

Lo que hacen realmente los equipos experimentados

Lee la documentación de los proveedores que realmente ejecutan scrapers en producción y el patrón es constante: híbrido. Utiliza el LLM para analizar la página una vez y luego ejecuta código determinista barato para todo lo que sigue.

Zyte lo explica claramente en su propia documentación: "En lugar de usar un LLM por página, utiliza tu LLM para generar selectores CSS para los campos deseados a partir del HTML sin procesar de una primera página, y usa esos selectores para analizar todas las demás páginas." (Zyte LLM guide, 2026). Apify recomienda el mismo flujo en su guía de 2026: prueba primero con selectores CSS y recurre al LLM cuando fallen (Apify 2026 guide). Una publicación en DEV Community sobre un despliegue en producción describió la arquitectura con exactitud: la ruta del selector almacenada en caché no cuesta nada, y el LLM solo se activa cuando falla la validación (DEV.to, 2026).

Así que la división en producción se ve así:

El LLM inicializa el selector (una llamada por objetivo, fracciones de un centavo)
El selector se ejecuta en cada página (gratis)
Un validador (normalmente una regex o una comprobación de presencia) detecta desviaciones
Las desviaciones activan una nueva inicialización, semanas o meses después

El coste por página se desploma de ~$0.005 a muy por debajo de $0.0001. La calidad aumenta porque el procesamiento determinista no alucina. Y gastas tokens en el trabajo para el que los LLM son realmente buenos: interpretar estructuras nuevas, no repetir como un loro una estructura que ya has mapeado.

Dónde los LLM sí justifican su coste

Este no es un artículo en contra de los LLM. Hay muchos trabajos de extracción donde el modelo es exactamente la herramienta adecuada y los números de los créditos cuadran:

Diseños inestables que cambian semanalmente. Los selectores que se rompen cada martes cuestan más en tiempo de ingeniería de lo que cuesta la extracción con LLM en tokens. Ejecuta el modelo.
Objetivos de cola larga que nunca volverás a visitar. No compensa escribir un selector. Ejecuta el modelo.
Contenido no estructurado donde el resultado es en sí mismo un resumen. De descripciones de puestos a habilidades, de artículos a afirmaciones, de reseñas a análisis de sentimiento. Los selectores no pueden ayudar. Ejecuta el modelo.
Páginas con campos opcionales distribuidos en distintas variantes de diseño. Una sola plantilla con veinte renderizados condicionales es exactamente donde los LLM superan a las cadenas de regex.

Analiza tu pipeline. Ordena los objetivos por volumen. El 20% superior por número de peticiones casi siempre tiene una estructura estable (por eso están en el 20% superior: los integraste deliberadamente). Son candidatos para usar selectores. La cola larga es el lugar del modelo.

Qué significa esto para tu stack

El discurso de los proveedores en 2026 quiere que uses la extracción con LLM por defecto. El precio por créditos hace que parezca razonable en proyectos pequeños. Deja de ser razonable cuando escalas, de la misma manera que el tamaño del pool de proxies dejó de predecir el éxito real una vez que la señal subyacente se rompió.

Tres conclusiones para los equipos que construyen pipelines reales:

Separa la obtención del procesamiento. Si tu proveedor de scraping solo devuelve JSON extraído por LLM, no podrás recurrir a los selectores cuando llegue la factura. Elige una infraestructura que te entregue el HTML y te permita elegir la ruta de extracción.
Almacena en caché de forma agresiva a nivel de selector. Los selectores generados se pueden reutilizar en miles de páginas. La llamada costosa es la generación, no el uso.
Mide el coste por registro, no por página. Un pipeline que cuesta $0.001 por página pero entrega un 5% de registros erróneos cuesta más que uno que cuesta $0.005 por página y entrega datos limpios. El almacenamiento, las consultas posteriores y la limpieza final tienen un impacto importante.

Elige la parte aburrida

La extracción con LLM por defecto es la opción ideal para una demostración, pero la incorrecta para producción. Los equipos que lo están haciendo bien son los que tratan a los LLM como una herramienta para entender una página, no como una herramienta para leer una página. El código determinista y aburrido sigue ganando la batalla del volumen en 2026; el modelo gana la de la novedad. Ambos tienen su lugar en el stack.

En FourA, Single y Browser devuelven la respuesta sin procesar (HTML, DOM renderizado, headers, body) y se detienen ahí. Ya sea que proceses con selectores, lo envíes a un modelo o hagas ambas cosas, es tu decisión. No añadimos un multiplicador de créditos por una extracción que no realizamos.