Un LLM local recopiló anuncios a través del DOM y se detuvo tras la sexta solicitud

Un scraper convencional de sitios de anuncios suele fallar antes de extraer la primera línea útil: el servidor responde 403, limita la frecuencia de solicitudes o entrega una página generada por JavaScript. El autor del experimento probó otro camino: encargó a un Qwen local de clase 7B/8B trabajar con el sitio a través de un navegador normal y extraer los datos no por frágiles clases CSS, sino por rasgos semánticos.

En un ejemplo sencillo, la tarea era la siguiente: encontrar una estación de trabajo móvil poco común con una tarjeta gráfica concreta y recopilar el nombre, el precio, la ciudad y el enlace al vendedor. El agente abría los resultados en Edge controlado por Playwright, examinaba el DOM y buscaba puntos de referencia conocidos: el símbolo de moneda, un texto grande contiguo y el identificador del anuncio en el enlace. Si los datos del vendedor estaban en otra zona de la página, los registros se vinculaban por Item ID.

Por qué el DOM resultó más útil que el CSS

Una interfaz moderna puede cambiar los nombres de las clases con cada actualización. Un selector que funcionaba ayer mañana devuelve una lista vacía. Los rasgos textuales son más estables: el precio sigue incluyendo la divisa, la ficha lleva a una dirección única y el título permanece junto al precio en la estructura de la página.

El agente usó estos rasgos como referencias. Primero localizaba el nodo con el precio, luego subía hasta el contenedor de la ficha, extraía el título y el enlace, y después cotejaba campos adicionales por identificador. Este enfoque recuerda al trabajo de una persona: tampoco sabemos el nombre de la clase CSS de un botón, pero entendemos su función por su texto y su posición.

Hay además un resultado más interesante. En un anuncio, el título prometía una tarjeta gráfica de gama superior, mientras que la descripción indicaba un modelo inferior con 16 GB de memoria. El agente advirtió la discrepancia y marcó la ficha para revisión manual. Para un equipo de producto esto importa más que una vistosa demostración de autonomía: el modelo no se limitó a trasladar filas, sino que comprobó la coherencia de los datos dentro del anuncio.

Dónde el experimento chocó con la realidad

En la sexta solicitud la plataforma devolvió un error 429: demasiadas solicitudes. El agente dejó de hacer nuevas peticiones y generó un informe con los datos ya guardados. Es un comportamiento sensato, pero a la vez desmonta la rotunda tesis de una «victoria» sobre el sistema antifraude. Lanzar un navegador normal no hace invulnerable al sistema: la plataforma sigue viendo la frecuencia de las acciones y puede restringir el acceso.

Tampoco ha sido confirmada por una prueba independiente la precisión del cien por cien en la correspondencia de datos que declara el autor. Se desconocen el tamaño de la muestra, el número de fichas omitidas y la proporción de errores en otras páginas. El experimento incluyó depuración interactiva y observación manual, por lo que aún es pronto para llamar totalmente autónomo al sistema.

Existe además un límite legal. Poder leer una página técnicamente no equivale a tener permiso para una recopilación masiva de datos. Antes de ejecutar nada hay que revisar las condiciones de la plataforma, el archivo robots.txt, la carga admisible y las normas de tratamiento de datos personales. Los mecanismos de protección no deben considerarse una molestia que haya que eludir a escondidas.

Qué puede llevarse un desarrollador

El valor del trabajo no está en una receta para saltarse bloqueos, sino en una técnica de arquitectura. En escenarios permitidos, un agente de navegador puede combinar tres niveles: verificación visual de la captura de pantalla, análisis del DOM por marcadores semánticos y un búfer local que permita terminar correctamente tras un error.

En producción hacen falta límites estrictos de frecuencia, reintentos con retardo creciente, un registro de acciones, comprobación de la exhaustividad de la muestra y confirmación manual de los resultados dudosos. Conviene empezar en el sitio propio o en un entorno de pruebas donde haya permiso explícito para la automatización.

La conclusión práctica es simple: un LLM local pequeño ya es capaz de manejar un navegador y recopilar datos estructurados de una página dinámica. Pero un buen agente no se define por su capacidad de superar la protección a cualquier precio, sino por su capacidad de respetar los límites, advertir contradicciones y detenerse con seguridad cuando el sitio dice «basta».