Scraping moderno: de 500 líneas a 50 con LLMs

Llevo años haciendo scraping. El patrón clásico: abres la web, inspeccionas el DOM, identificas selectores, escribes XPath, los pruebas, funcionan, los despliegas… y dos semanas después la web cambia un <div> y todo se rompe.

Los LLMs cambiaron este juego. No del todo — los selectores siguen siendo más rápidos y baratos cuando funcionan — pero para webs caóticas o cambiantes, la diferencia es brutal.

El enfoque tradicional

Pongamos que quieres extraer precios de productos de 30 tiendas distintas. El enfoque tradicional implica:

• Escribir selectores específicos para cada tienda.
• Mantenerlos cuando cambia el HTML.
• Gestionar casos raros: variantes, descuentos, sin stock…
• Tener un parser por tienda. 30 tiendas = 30 parsers.

El enfoque con LLMs

El enfoque moderno es más aburrido pero mucho más robusto:

1. Descargas el HTML (o mejor: el texto limpio).
2. Le pasas al LLM un schema de lo que quieres extraer.
3. El modelo devuelve JSON estructurado.

Un parser con LLM no se rompe cuando cambian el HTML. Se rompe cuando cambian el negocio.

Cuándo NO usarlo

No es magia. Tiene tres costes reales:

• Dinero: cada llamada cuesta. Para volumen alto, calcula bien.
• Latencia: un modelo tarda segundos. Un selector, milisegundos.
• Determinismo: el modelo puede equivocarse. Necesitas validación.

Para scrapear una web bien estructurada y estable, los selectores siguen ganando.

La combinación ganadora

Lo que mejor me funciona en producción es una capa híbrida:

• Selectores para las webs conocidas y estables.
• LLM como fallback cuando los selectores fallan.
• Validación con un schema (Zod, Pydantic) siempre.

Así tienes lo mejor de los dos mundos: velocidad cuando funciona, robustez cuando no.

---

— Adrián Pastora

Si te ha resultado útil y quieres aplicar algo de esto en tu empresa, hablemos.