Usar LLMs para extraer datos estructurados de páginas web desordenadas

El problema de la fragilidad

Cada web scraper tiene la misma debilidad: selectores CSS. Escribes document.querySelector('.product-price .amount') y funciona perfectamente — hasta que el sitio rediseña, renombra la clase a price-value, la envuelve en un nuevo div, o cambia de HTML renderizado en servidor a un componente cargado por JavaScript.

Cuando tu scraper monitorea 50 sitios, al menos uno de ellos cambia algo cada semana. Pasas más tiempo manteniendo selectores que construyendo nuevas funcionalidades. Es una cinta de correr.

Aquí es donde los LLMs cambian el juego. En lugar de decirle a un scraper exactamente dónde encontrar el precio (ruta CSS frágil), le dices a un LLM “extrae el precio de esta página” y entiende cómo se ve un precio — independientemente de cómo esté estructurado el HTML.

Cómo funciona la extracción basada en LLM

El patrón básico es directo:

1. Obtener el contenido de la página (HTML o texto renderizado)
2. Limpiarlo (eliminar navegación, footers, scripts — mantener el contenido principal)
3. Enviarlo a un LLM con un prompt definiendo qué extraer y el esquema de salida esperado
4. Validar la respuesta estructurada contra tu esquema
5. Almacenar los datos validados

Así se ve en la práctica. Digamos que necesitas extraer información de producto de una página de e-commerce. El prompt podría ser:

Extrae la siguiente información de esta página de producto:
- name: el nombre del producto
- price: el precio actual como número (no el precio original/tachado)
- currency: el código de moneda (EUR, USD, GBP, etc.)
- in_stock: booleano, si el producto está disponible
- description: una breve descripción del producto (máx 200 caracteres)

Devuelve JSON válido que coincida con este esquema. Si un campo no puede determinarse, usa null.

El LLM lee el contenido de la página — HTML desordenado, formato inconsistente, múltiples precios (original, con descuento, solo para miembros) — y devuelve JSON limpio. Entiende que “19,99 EUR” y “$19.99” y “Precio: 19.99$” representan todos precios. Sabe que “En stock”, “Disponible”, “Envío en 2-3 días” y un icono de check verde significan todos que el producto está disponible.

Sin selectores CSS. Sin XPath. Sin regex que se rompe cuando alguien añade un espacio.

Cuándo usar LLMs vs parsing tradicional

Los LLMs no son un reemplazo del scraping tradicional — son un complemento. Aquí es cuando cada enfoque tiene sentido:

Usa selectores CSS/XPath tradicionales cuando:

• Scrapeas un solo sitio con estructura estable
• Los datos están en ubicaciones predecibles y consistentes
• Necesitas máxima velocidad y mínimo coste
• El volumen es extremadamente alto (millones de páginas por día)

Usa extracción por LLM cuando:

• Scrapeas muchos sitios con estructuras diferentes
• Los layouts cambian frecuentemente
• Los datos requieren interpretación (no solo localización)
• Necesitas extraer de texto no estructurado, no solo HTML estructurado
• El volumen es moderado (miles a decenas de miles de páginas por día)

Usa ambos cuando:

• Tienes una mezcla de fuentes estables e inestables
• Algunos campos son fáciles de localizar (CSS) y otros requieren comprensión (LLM)
• Quieres selectores CSS para velocidad con LLM como fallback cuando los selectores fallan

El enfoque híbrido es el más poderoso — similar a elegir entre API y scraping. Intenta primero la extracción CSS rápida y económica. Si falla o devuelve resultados sospechosos, recurre a la extracción LLM. Registra el fallback para poder actualizar tus selectores después si quieres.

Haciéndolo rentable

La preocupación obvia con la extracción por LLM es el coste. Enviar páginas HTML completas a una API LLM no es barato — y la mayoría de ese HTML es navegación, headers, footers y scripts irrelevantes.

Limpia antes de enviar. Elimina todo lo que no sea contenido principal. Quita todas las etiquetas <script>, <style>, <nav>, <header>, <footer>. Elimina atributos HTML que no llevan significado semántico (nombres de clase, IDs, atributos data). Convierte el HTML restante a texto limpio o markdown mínimo. Esto típicamente reduce el conteo de tokens un 80-90 %.

Usa el modelo correcto para el trabajo. No toda extracción necesita Claude Opus o GPT-4o. Para extracciones directas (nombre, precio, disponibilidad), modelos más ligeros como Claude Haiku o GPT-4o mini entregan 95 %+ de precisión a una fracción del coste. Reserva los modelos más capaces para extracciones complejas que requieren razonamiento — interpretar descripciones ambiguas, manejar múltiples niveles de precio, o extraer de contenido altamente no estructurado.

Agrupa páginas similares. Si extraes los mismos campos de 100 páginas del mismo sitio, a menudo puedes enviar múltiples contenidos de página en una sola llamada API con un prompt compartido. Esto reduce el overhead del prompt del sistema y la definición de esquema repetidos para cada página.

Cachea inteligentemente. Si una página no ha cambiado desde la última extracción (verifica con ETags o hashing de contenido), no re-extraigas. Solo esto puede reducir las llamadas API de LLM un 60-70 % para sitios que se actualizan infrecuentemente.

Con estas optimizaciones, el coste de extracción por LLM típicamente queda entre $0.001-0.01 por página — comparable a los costes de proxy que ya pagas por el scraping.

Salidas estructuradas: el avance de fiabilidad

La mejora más significativa en extracción basada en LLM durante el último año es el soporte de salidas estructuradas. Tanto Claude como GPT ahora soportan generación restringida — el modelo se ve forzado a devolver JSON válido que coincida con un esquema específico. No más parsear respuestas de texto libre esperando que el formato sea correcto.

Esto cambia todo para uso en producción. En lugar de promptear al modelo y luego escribir regex frágiles para extraer valores de su respuesta, defines un esquema JSON y la API garantiza que la respuesta coincida. Cada campo tiene el tipo correcto. Los campos requeridos siempre están presentes. Sin claves inesperadas ni corchetes faltantes.

Combinado con validación de esquema de tu lado (Zod, Pydantic), esto crea una doble red de seguridad que hace la extracción LLM tan fiable como el parsing tradicional para la mayoría de casos de uso.

Manejando los casos límite

Los LLMs son impresionantemente buenos en extracción, pero no son perfectos. Así es como manejar los casos donde tropiezan:

Datos ambiguos. Una página muestra tres precios — original, rebajado y solo para miembros. ¿Cuál debería devolver el LLM? Sé explícito en tu prompt. “Extrae el precio de venta actualmente mostrado visible para usuarios no logueados, no el precio original ni el precio de miembro.”

Valores alucinados. Ocasionalmente, un LLM generará datos que parecen plausibles pero no están en la página. Cruza los valores extraídos con el contenido bruto. Si el LLM devuelve un precio de 29,99 € pero el string “29,99” no aparece en ningún lugar del contenido de la página, márcalo para revisión.

Contenido multilingüe. Páginas en idiomas que el modelo maneja menos bien pueden tener menor precisión de extracción. Para casos de uso críticos, prueba la calidad de extracción por idioma y considera usar prompts específicos por idioma o pre-traducción.

Páginas grandes. Algunas páginas exceden la ventana de contexto del modelo incluso después de limpiar. Para estas, extrae primero la sección relevante (el contenedor de producto, el cuerpo del artículo) y solo envía esa sección al LLM.

Un ejemplo del mundo real

Construimos un sistema de monitoreo competitivo para una empresa minorista europea que rastrea precios en 120 sitios de e-commerce diferentes en 8 países. El enfoque tradicional habría requerido 120 configuraciones de scraper diferentes, cada una con selectores CSS específicos del sitio, mantenidas individualmente.

En su lugar, construimos 3 plantillas de scraper (una para páginas de producto único, una para páginas de listado, una para resultados de búsqueda) alimentadas por extracción LLM. El mismo esquema de prompt maneja páginas de producto en francés, alemán, italiano, español e inglés sin modificación. Cuando un sitio rediseña, el extractor sigue funcionando porque lee contenido, no estructura DOM.

El mantenimiento bajó de aproximadamente 15 horas por semana (arreglando selectores rotos) a cerca de 2 horas por semana (principalmente manejando nuevas estructuras de sitios no vistas antes). La precisión de extracción se mantiene en 97,5 % en todos los sitios, validada contra verificaciones manuales puntuales.

En SilentFlow, esta combinación de scraping inteligente y extracción potenciada por LLM está en el núcleo de lo que construimos. La web es desordenada, no estructurada y cambia constantemente. Los scrapers tradicionales luchan contra esa realidad. Los LLMs la abrazan — entendiendo el contenido como un humano lo haría, pero a una escala que ningún equipo humano puede igualar. El resultado es una extracción de datos más resiliente, más adaptable y, en definitiva, más fiable que cualquier enfoque basado en selectores.