Accelerator Series: Een Veerkrachtige Web Scraper Bouwen met LangGraph en TrueFoundry

Het salesteam is in paniek – er is volgende week een belangrijk gezondheidszorgcongres. De website van het evenement toont 200 sprekers -- artsen, executives en onderzoekers -- verspreid over een dozijn gepagineerde subpagina's. Om een leadlijst op te stellen, moet iemand de site openen, op een naam klikken, de gegevens naar een spreadsheet kopiëren, een nieuw tabblad openen, naar die persoon zoeken op LinkedIn, de profiel-URL kopiëren en deze terugplakken.

Ze moeten dit 200 keer doen.

Voor engineers resulteert dit verzoek meestal in een snel Python-script waarin Selenium of BeautifulSoup wordt gebruikt. Je inspecteert de broncode van de pagina, zoekt de div met de class speaker-name en extraheert de tekst. Dit werkt ongeveer een week perfect. Daarna werkt de website zijn frontend-framework bij, veranderen de CSS-classes en crasht het script.

We hebben de Profile Crawler accelerator gebouwd om deze cyclus te stoppen. Het is een autonome agent die navigeert op websites en gegevens extraheert op basis van wat er op de pagina staat, niet op basis van hoe de HTML is gestructureerd.

Hier is hoe we de oplossing hebben ontworpen met LangGraph voor orchestratie, Playwright voor interactie en TrueFoundry om de infrastructuur te beheren.

De Verschuiving: Van DOM Selectors naar Semantische Extractie

De belangrijkste reden waarom scraping-scripts mislukken, is hun afhankelijkheid van het Document Object Model (DOM). Als je een script vertelt te zoeken naar div.content-wrapper > h2.title, zal het breken op het moment dat een ontwikkelaar een class-naam wijzigt.

We zijn overgestapt op een op agents gebaseerde aanpak. We vertellen de bot niet waar de gegevens zich pixel-gewijs bevinden. In plaats daarvan voeden we de gerenderde HTML (omgezet naar Markdown) aan een LLM. Het model leest de tekst net zoals een mens dat zou doen. Het begrijpt dat een sectie met het label "Keynote Speakers" de gewenste gegevens bevat, ongeacht de onderliggende tags.

• Oude Manier (Kwetsbaar): Hardgecodeerde CSS selectors die breken bij UI-updates.
• Nieuwe Manier (Veerkrachtig): Semantisch begrip dat zich aanpast aan lay-outwijzigingen.

Diepgaande Architectuur

We hadden een systeem nodig dat beslissingen kon nemen, niet zomaar een lineair script. De applicatie moet beslissen: Is deze invoer een URL of gewoon een bedrijfsnaam? Kwamen we een captcha tegen? Is deze pagina een lijst met mensen of een enkele biografie?

We hebben gekozen voor LangGraph om deze workflow als een state machine te modelleren, vooral waar Langflow vs LangGraph beslissingen de voorkeur geven aan statusvolle orchestratie.

De Logische Stroom

Het systeem werkt in een lus in plaats van een rechte lijn:

1. Input Router: Het systeem controleert of de gebruiker een directe URL heeft opgegeven of alleen een bedrijfsnaam. Als het een naam is, gebruikt het eerst een zoektool om het juiste domein te vinden.
2. Stealth Navigatie: We gebruiken een aangepaste Playwright-instantie om de pagina te laden. Het verwerkt automatisch cookie- toestemmingsbanners en lazy-loading afbeeldingen.
3. Vector Filtering (De Optimalisatie): Een enkele congrespagina kan 200 navigatielinks bevatten. Al deze links doorgeven aan het LLM-contextvenster is traag en duur. We gebruiken FastEmbed om de linktekst in te bedden en een lokale Qdrant-instantie te bevragen. Dit filtert de lijst tot de top 10 links die relevant zijn voor "Team" of "Speakers."
4. Extractie: Het LLM parsed de gefilterde inhoud en extraheert gestructureerde entiteiten (Naam, Rol, Bedrijf).
5. Verrijking: Ten slotte lopen we door de geëxtraheerde namen en gebruiken we een zoektool (Tavily) om hun specifieke LinkedIn-profielen te vinden.

Hier is de architectuur van het systeem:

‍

Infrastructuur en TrueFoundry Integratie

Het uitvoeren van headless browsers en LLM agents in productie veroorzaakt operationele problemen: geheugenlekken vanuit Chromium, snelheidslimieten op LLM API's en de noodzaak voor procesisolatie.

We hebben dit uitgerold op TrueFoundry om deze specifieke beperkingen op te vangen.

1. De AI Gateway (Observability & Caching)

Deze applicatie maakt veelvuldig gebruik van LLM's voor navigatiebeslissingen. Zonder governance lopen de kosten snel op. We routeren alle modelaanroepen via de TrueFoundry AI Gateway.

• Caching: Als de agent dezelfde site twee keer scraped, levert de Gateway gecachete LLM-respons voor de extractiestappen. Dit vermindert de latentie en kosten aanzienlijk.
• Rate Limiting: We stellen strikte limieten per gebruiker in om uitputting van het API-quota te voorkomen tijdens grote batchopdrachten.
• Failover: Als OpenAI uitval ondervindt, herleidt de Gateway aanvragen automatisch naar Anthropic of Azure OpenAI zonder dat de crawl mislukt.

2. Model Context Protocol (MCP)

We hebben de applicatie gestructureerd met behulp van het Model Context Protocol (MCP). De "Crawler" is niet zomaar een Python-functie; het is een MCP Server. Dit stelt ons in staat om de browseromgeving te sandboxen. Als de browser crasht (wat vaak gebeurt bij zware JavaScript-sites), haalt dit de hoofdlogica van de applicatie niet onderuit.

Infrastructuurdiagram

Vergelijking: Script vs. Agent

We hebben de standaard Python-scriptaanpak vergeleken met deze architectuur.

Omgaan met Randgevallen

Het bouwen van het ideale pad is eenvoudig. Om het betrouwbaar te maken, moesten drie specifieke engineeringproblemen worden opgelost:

1. Dubbele Gegevens: Profielen verschijnen vaak op meerdere pagina's (bijv. zowel "Leadership" als "About Us"). We hebben een Deduplication Node toegevoegd aan het einde van de graph. Het geeft de volledige lijst door aan een kleiner, goedkoper LLM om records samen te voegen op basis van naamsvergelijking vóór verrijking.
2. Anti-Bot Detectie: Standaard Playwright wordt gemakkelijk gedetecteerd door moderne WAF's. We hebben undetected-playwright geïmplementeerd binnen de Docker-container, wat de browserfingerprint (Navigator object, WebGL vendor) aanpast om te verschijnen als een standaard gebruikersapparaat.
3. Tokenlimieten: Grote pagina's met privacybeleid en footers verspillen tokens. We gebruiken header-based chunking om de markdown op te splitsen. Het LLM verwerkt alleen chunks die relevant zijn voor "Team" of "Speakers" en gooit de rest weg.

Conclusie

Deze architectuur lost de "Last Mile" van data-acquisitie op door kwetsbare scripts te vervangen door adaptieve agents. Door dit uit te voeren op TrueFoundry zorgen we ervoor dat het systeem observeerbaar, kostenbeheersbaar en schaalbaar is.

U kunt precies deze architectuur -- inclusief de Gateway-configuratie en gecontaineriseerde agents -- vandaag nog uitrollen vanuit de TrueFoundry applicatiebibliotheek.

‍