Serie Accelerator: Creación de un raspador web resiliente con LangGraph y TrueFoundry

El equipo de ventas está en pánico: la semana que viene habrá una importante conferencia sobre el cuidado de la salud. En el sitio web del evento figuran 200 ponentes (médicos, ejecutivos e investigadores) repartidos en una docena de subpáginas paginadas. Para crear una lista de clientes potenciales, alguien tiene que abrir el sitio, hacer clic en un nombre, copiar los detalles en una hoja de cálculo, abrir una nueva pestaña, buscar a esa persona en LinkedIn, copiar la URL del perfil y volver a pegarla.

Tienen que hacerlo 200 veces.

Para los ingenieros, esta solicitud suele dar como resultado una secuencia de comandos rápida de Python que utiliza Selenium o BeautifulSoup. Inspecciona la fuente de la página, busca el div con el nombre del orador de la clase y extrae el texto. Funciona perfectamente durante aproximadamente una semana. Luego, el sitio web actualiza su marco de interfaz, las clases de CSS cambian y el script se bloquea.

Construimos el Perfil: Crawler acelerador para detener este ciclo. Es un agente autónomo que navega por los sitios web y extrae datos basándose en lo que dice la página, no en cómo está estructurado el HTML.

Así es como diseñamos la solución utilizando LangGraph para la orquestación, Playwright para la interacción y TrueFoundry para administrar la infraestructura.

El cambio: de los selectores DOM a la extracción semántica

La razón principal por la que los scripts de scraping fallan es porque se basan en el Document Object Model (DOM). Si le dices a un script que busque div.content-wrapper > h2.title, se interrumpirá en el momento en que un desarrollador cambie el nombre de una clase.

Pasamos a un enfoque de agencia. No se lo decimos al bot donde los datos están ubicados en píxeles. En su lugar, enviamos el HTML renderizado (convertido a Markdown) a un LLM. El modelo lee el texto igual que lo haría un humano. Entiende que una sección denominada «Oradores principales» contiene los datos que queremos, independientemente de las etiquetas subyacentes.

• A la antigua usanza (frágil): Selectores CSS codificados que se interrumpen en las actualizaciones de la interfaz de usuario.
• Nueva forma (resiliente): Comprensión semántica que se adapta a los cambios de diseño.

Análisis profundo de la arquitectura

Necesitábamos un sistema que pudiera gestionar la toma de decisiones, no solo un guion lineal. La aplicación debe decidir: ¿Esta entrada es una URL o solo el nombre de una empresa? ¿Hemos conseguido un captcha? ¿Esta página es una lista de personas o una sola biografía?

Elegimos LangGraph para modelar este flujo de trabajo como una máquina de estados, especialmente cuando Langflow frente a LangGraph las decisiones favorecen la orquestación estatal.

El flujo lógico

El sistema funciona en bucle en lugar de en línea recta:

1. Enrutador de entrada: El sistema comprueba si el usuario proporcionó una URL directa o solo el nombre de la empresa. Si se trata de un nombre, utiliza una herramienta de búsqueda para encontrar primero el dominio correcto.
2. Navegación sigilosa: Usamos una instancia de Playwright modificada para cargar la página. Gestiona automáticamente los banners de consentimiento de las cookies y las imágenes que se cargan de forma diferida.
3. Filtrado vectorial (la optimización): Una sola página de conferencia puede tener 200 enlaces de navegación. Introducir todos ellos en una ventana de contexto de LLM es lento y caro. Nosotros utilizamos Incrustación rápida para incrustar el texto del enlace y consultar un local Qarant instancia. Esto filtra la lista hasta los 10 enlaces principales relacionados con «Equipo» o «Oradores».
4. Extracción: El LLM analiza el contenido filtrado y extrae las entidades estructuradas (nombre, rol, empresa).
5. Enriquecimiento: Por último, revisamos los nombres extraídos y utilizamos una herramienta de búsqueda (Tavily) para encontrar sus perfiles específicos de LinkedIn.

Esta es la arquitectura del sistema:

‍

Integración de infraestructura y TrueFoundry

La ejecución de navegadores sin memoria y agentes de LLM en producción crea problemas operativos: pérdidas de memoria de Chromium, límites de velocidad en las API de LLM y la necesidad de aislar los procesos.

Lo implementamos en True Foundry para hacer frente a estas restricciones específicas.

1. The AI Gateway (observabilidad y almacenamiento en caché)

Esta aplicación hace un uso intensivo de los LLM para tomar decisiones de navegación. Sin gobernanza, los costos se disparan rápidamente. Redirigimos todas las llamadas modelo a través del Puerta de enlace de IA TrueFoundry.

• Almacenamiento en caché: Si el agente raspa el mismo sitio dos veces, la puerta de enlace entrega las respuestas de LLM almacenadas en caché para los pasos de extracción. Esto reduce significativamente la latencia y el costo.
• Límite de velocidad: Establecemos límites estrictos por usuario para evitar que se agoten las cuotas de API durante los trabajos por lotes de gran tamaño.
• Conmutación por error: Si OpenAI sufre un tiempo de inactividad, el Gateway redirige automáticamente las solicitudes a Anthropic o Azure OpenAI sin fallar en el rastreo.

2. Protocolo de contexto modelo (MCP)

Estructuramos la aplicación utilizando Protocolo de contexto modelo (MCP). El «Crawler» no es solo una función de Python, es un servidor MCP. Esto nos permite configurar el entorno del navegador en un entorno aislado. Si el navegador se bloquea (lo que ocurre con frecuencia en sitios con mucho contenido de JavaScript), no se elimina la lógica principal de la aplicación.

Diagrama de infraestructura

Comparación entre script y agente

Comparamos el enfoque estándar del script de Python con esta arquitectura.

Manejo de casos extremos

Construir el camino feliz es fácil. Hacerlo confiable requirió resolver tres problemas de ingeniería específicos:

1. Datos duplicados: Los perfiles suelen aparecer en varias páginas (por ejemplo, tanto en «Liderazgo» como «Acerca de nosotros»). Hemos añadido un Nodo de deduplicación al final del gráfico. Pasa la lista completa a un LLM más pequeño y económico para combinar los registros en función de la similitud de los nombres antes de enriquecerlos.
2. Detección de antibots: Los WAF modernos detectan fácilmente al dramaturgo estándar. Hemos incorporado al contenedor Docker la función de dramaturgo no detectado, que corrige la huella digital del navegador (objeto Navigator, proveedor de WebGL) para que aparezca como un dispositivo de usuario estándar.
3. Límites de fichas: Las páginas grandes con políticas de privacidad y pies de página desperdician fichas. Usamos fragmentación basada en encabezados para dividir la rebaja. El LLM solo procesa los fragmentos relacionados con el «equipo» o los «ponentes», descartando el resto.

Conclusión

Esta arquitectura resuelve la «última milla» de la adquisición de datos al reemplazar los frágiles scripts por agentes adaptables. Al ejecutarlo en TrueFoundry, nos aseguramos de que el sistema sea observable, con costos controlados y escalable.

Hoy mismo puede implementar esta arquitectura exacta, incluida la configuración de Gateway y los agentes dockerizados, desde la biblioteca de aplicaciones de TrueFoundry.

‍