🤖 AI

Making Failure Safe: A Constrained, Verifiable Agent Framework for Open-Web Data Collection

Dit artikel stelt een beperkt, verifieerbaar agent-framework voor dat onbetrouwbare vrije vorm LLM-codegeneratie vervangt door getypeerde JSON-collectorconfiguraties en statische executiepipelines om deterministische, goedkope en herbruikbare open-web datacollectie te bereiken.

Oorspronkelijke auteurs: Bo Chen

Gepubliceerd 2026-07-02

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Bo Chen

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een robot moet inhuren om elke dag specifieke informatie te verzamelen van duizenden verschillende websites. Je zou de robot simpelweg kunnen vertellen: "Ga het nieuws ophalen," en hopen dat hij zelf uitzoekt hoe hij dat moet doen. Maar zoals het artikel uitlegt, is deze "vrije voor alles"-aanpak als het sturen van een kind naar een bibliotheek zonder instructies; ze kunnen de verkeerde boeken pakken, over stoelen struikelen of terugkomen met een rommelige verzameling pagina's.

Dit artikel stelt een nieuwe manier voor om deze gegevensverzamelingsrobots (genaamd "agents") te bouwen, die foutbestendig, voorspelbaar en gemakkelijk te herstellen maakt. Dit is hoe het werkt, onderverdeeld in eenvoudige concepten:

1. Het Probleem: Het "Wilde Westen" van Web Scraping

Momenteel, als je een AI vraagt om code te schrijven om een website te scrapen, probeert het vaak elke keer een gloednieuw script vanaf nul te schrijven.

Het Problek: Websites zijn rommelig en veranderen vaak. Als de AI het fout raadt over waar een prijskaartje zich op een pagina bevindt, breekt het hele script.
Het Resultaat: Je krijgt fouten, gebroken data, of scripts die stoppen met werken zodra een website zijn lay-out aanpast. Het is alsof je probeert een huis te bouwen door elke keer opnieuw te raden waar de stenen moeten komen.

2. De Oplossing: De "LEGO-set" Aanpak

In plaats van de AI vrije code te laten schrijven (zoals het schrijven van een roman), dwingt de auteur de AI om een gestructureerd formulier in te vullen (zoals het invullen van een LEGO-instructieblad).

De Taxonomie (De 6 Typen): Het systeem vraagt eerst: "Wat voor soort taak is dit?" Het categoriseert taken in zes specifieke typen, zoals een menu:
1. Zoeken (Search): Links vinden op basis van trefwoorden.
2. Lijst (List): Door pagina's met items bladeren (zoals een nieuwsarchief).
3. Detail (Detail): De volledige inhoud van een enkele pagina lezen.
4. API: Direct een computer om data vragen (zoals bestellen van een menu).
5. Interactief (Interactive): Op knoppen klikken of typen op dynamische pagina's.
6. Bestand (File): PDF's of Excel-bestanden downloaden.
- Analogie: In plaats van een chef te vertellen dat hij "het diner moet maken", vertel je hem: "Je maakt een soep," en hij gebruikt alleen de gereedschappen en recepten voor soep. Dit voorkomt dat hij probeert een taart te bakken wanneer je een soep wilde.
De Beperkingen (De Veiligheidsrails): De AI mag geen nieuwe code verzinnen. Het moet een selectie maken uit een vooraf goedgekeurde bibliotheek van "utility functions" (voorgebouwde tools) en de gaten in een sjabloon invullen.
- Analogie: Denk aan een "Mad Libs"-spel waarbij de AI alleen de specifieke lege plekken mag invullen die worden aangeboden, in plaats van het hele verhaal zelf te schrijven. Dit zorgt ervoor dat de output altijd in een formaat staat dat de computer kan begrijpen.

3. Het Proces: De "Proefrit" Loop

Het framework stuurt de robot niet direct op pad. Het gebruikt een strikte "Genereren → Controleren → Herstellen" loop:

Genereren: De AI maakt een configuratiebestand (een JSON-plan) op basis van de gebruikersaanvraag.
Proefrit (Validatie): Voordat de volledige taak wordt uitgevoerd, voert het systeem een kleine, goedkope test uit op slechts enkele pagina's.
De Kwaliteitscontrole (De Scheidsrechter): Een op regels gebaseerd systeem (geen AI) controleert de resultaten. Het vraagt: "Hebben we de juiste velden gekregen? Is de data leeg? Is het gecrasht?"
- Cruciaal Punt: Als de test mislukt, zegt het systeem niet alleen "probeer het opnieuw." Het maakt een specifieke "blacklist" van wat niet te doen (bijv. "Zoek de prijs niet in de footer").
Herstellen: De AI probeert het opnieuw, maar wordt dit keer gedwongen om de fouten die het net maakte te vermijden.
Opschalen: Pas wanneer de proefrit slaagt, voert het systeem de volledige gegevensverzameling uit.

4. De Resultaten: Snelheid versus Perfectie

De auteurs testten dit op 138 verschillende gegevensverzamelingstaken. Dit is wat ze vonden:

Eén-kans Kwaliteit (One-Shot Quality): Als je de data nu meteen één keer wilt ophalen, kunnen andere methoden die de AI vrije code laten schrijven, direct iets betere resultaten behalen (ongeveer 70% succes versus 50% voor deze methode).
De Afweging: Echter, de methode van de auteurs is veel sneller en veel goedkoper om herhaaldelijk uit te voeren.
- De Magie: Zodra het plan is gemaakt, wordt de eigenlijke verzameling uitgevoerd zonder dat er überhaupt AI wordt gebruikt. Het voert simpelweg het vooraf gemaakte plan uit.
- Analogie: Andere methoden zijn als het inhuren van een menselijke vertaler voor elke zin die je leest. Deze methen is als het eenmaal inhuren van een vertaler om een woordenboek te schrijven, en dat woordenboek vervolgens voor altijd te gebruiken.
Betrouwbaarheid: Wanneer het systeem faalde, faalde het niet stilzwijgend. Het produceerde een duidelijk foutrapport, waardoor de "Herstel"-loop de fout kon corrigeren. In hun tests veranderde deze feedbackloop een falend systeem (0% slagingspercentage) in een perfect systeem (100% slagingspercentage).

Samenvatting

Dit artikel betoogt dat we niet moeten proberen de AI "perfect" te maken in het raden hoe het te webscrepen. In plaats daarvan moeten we de AI beperken om strikte regels te volgen, voorgebouwde tools te gebruiken en een "proefrit" te doen voordat het echte werk begint.

Door een beetje aanvankelijke perfectie in te ruilen voor een systeem dat verifieerbaar, herbruikbaar en goedkoop te draaien is, maakt dit framework geautomatiseerde gegevensverzameling betrouwbaar genoeg voor dagelijks gebruik (zoals het elke ochtend verzamelen van nieuws of overheidsgegevens) zonder dat er telkens een mens de code moet repareren wanneer een website verandert.

Technische Samenvatting: Het maken van falen veilig: Een beperkt, verifieerbaar agent-framework voor open-web datacolectie

1. Probleemdefinitie

Het artikel behandelt de onbetrouwbaarheid van het direct gebruiken van Large Language Models (LLM's) en agents voor open-web datacolectie. Hoewel LLM's scraper-code kunnen genereren vanuit natuurlijke taal, lijdt directe toepassing aan structurele broosheid door heterogene webpagina's en de stochastische inconsistentie van LLM-codegeneratie. Veelvoorkomende foutmodi zijn afhankelijkheidsfouten, gebroken selectors, schema-mismatches en inconsistente outputformaten. Traditionele pipelines vertrouwen op handmatige inspanning, terwijl onbeperkte agent-benaderingen een gebrek aan verifieerbaarheid hebben, wat het moeilijk maakt om fouten te auditeren, te meten of te corrigeren in een productieomgeving.

De kernuitdaging is de verschuiving van "perfecte agent-redenering" naar een "verifieerbare collectie-pipeline" waarbij de inputs en outputs van elke fase gecontroleerd, gemeten en geaudit kunnen worden.

2. Methodologie

De auteurs stellen een beperkt, verifieerbaar agent-framework voor dat vrije codegeneratie vervangt door de generatie van getypeerde JSON-collectorconfiguraties. Het systeem werkt op basis van een "genereer–executeer–controleer–corrigeer" closed-loop, waarbij de rol van de LLM (begrip van vereisten en configuratiegeneratie) wordt ontkoppeld van de executie-engine (statische Airflow DAG's).

2.1 Zes-type Collector Taxonomie

Om structurele grenzen af te dwingen, definieert het framework een taxonomie van zes collectortypes, elk met expliciete functionele grenzen en compositieregels:

Search (Zoeken): Ontdekt kandidaat-URL's via trefwoorden (geen inhoudsextractie).
List (Lijst): Navigeert door gepagineerde lijsten om detail-links te vinden (geen diepe inhoudsextractie).
Detail (Detail): Extraheert gestructureerde velden van een enkele pagina.
API: Roept publieke API's aan en mapt responsvelden (geen browserinteractie).
Interactive (Interactief): Voert klikken en invoer uit op dynamische pagina's (geen omzeiling van auth/CAPTCHA's).
File (Bestand): Downloadt en parseert publieke bestanden (PDF, Excel).

2.2 Beperkt Agent-Framework

Het framework bestaat uit vijf modules die opereren onder vier categorieën beperkingen:

Requirement Understanding Agent (Agent voor begrip van vereisten): Zet natuurlijke taalbeschrijvingen ( $d$ ) om in een volledige taakrepresentatie ( $R$ ) door proactief de doelwebsite te onderzoeken (homepage, sitemap, voorbeeldpagina's) om broncontext ( $x$ ) te extraheren.
Collector Instantiation Agent (Agent voor collector-instantiatie): Genereert JSON-configuraties ( $M$ $M$ ) met behulp van een "referentie-codering + template slot-filling" benadering. In plaats van code te schrijven, vult de agent slots in vooraf gebouwde templates in, die worden beperkt door:
- Taaktype-beperkingen: Zorgen dat het juiste collectortype wordt geselecteerd.
- Configuratie-structuurbeperkingen: Afdwingen van JSON Schema-compliance.
- Tool-reuse beperkingen: Hergebruik van vooraf gebouwde utility-functies in plaats van het genereren van nieuwe code.
Airflow Validatie & Schaalbare Executie: Een statische Airflow DAG voert de JSON-configuraties uit. Validatieruns worden uitgevoerd met parameters voor kleine samples om fouten te verschuiven naar een goedkope pre-productiefase, terwijl schaalruns productieparameters gebruiken. Dit zorgt ervoor dat er tijdens de executie nul LLM-tokens worden verbruikt.
Quality Check Module (Kwaliteitscontrole module): Een op regels gebaseerde, deterministische evaluator (geen LLM) scoort resultaten over vijf dimensies: Structuur, Inhoud, Relevantie, Bijlage en Executie. Het produceert een samengestelde score ( $S$ ) en een foutenrapport.
Feedback Correction Module (Feedback-correctie module): Zet kwaliteitsrapporten om in gestructureerde feedback-beperkingen (bijv. fouten-blacklists, verboden hypothesen). De instantiatie-agent regenereert de configuratie onder deze nieuwe beperkingen, wat een closed-loop vormt.

3. Belangrijkste Bijdragen

Zes-type Collector Taxonomie: Een formeel classificatiesysteem met expliciete grenzen en compositieregels om collectietaken te standaardiseren.
Beperkt Agent-Framework: Een systeem dat de output van de LLM verschuift van vrije code naar getypeerde JSON-configuraties onder een viergetraps geneste beperkingshiërarchie (type $\to$ template $\to$ utility $\to$ validatie).
Verifieerbare Closed-Loop: Een "genereer–executeer–controleer–corrigeer" mechanisme met gebruik van op regels gebaseerde kwaliteitscontrole en gestructureerde feedback-correctie, wat auditeerbare foutsignalen mogelijk maakt.
Multi-level Experimentele Validatie: Uitgebreide testen die requirement-classificatie, collector-instantiatie, kwaliteit-kostenafwegingen tegenover runtime LLM-baselines en Airflow-compatibiliteit dekken.

4. Experimentele Resultaten

Het framework werd geëvalueerd op een dataset van 138 collectietaken (80 bron-geverifieerd).

Requirement Classificatie: Het systeem behaalde een Macro-F1 van 0,7793 bij het classificeren van collectortypes uit beschrijvingen, waarmee het een op trefwoorden gebaseerde regel-baseline (0,7562) versloeg. De auteurs merken echter op dat beschrijvingen alleen onvoldoende zijn voor ambigue taken (bijv. "detail" vs. "list"), wat proactief onderzoek noodzakelijk maakt.
Collector Instantiatie: Het beperkte framework behaalde een gemiddelde kwaliteitsscore van 0,5369 en een pass rate van 55,07%, wat aanzienlijk beter is dan onbeperkte LLM-generatie (0,4876 kwaliteit, 18,84% type match) en op regels gebaseerde baselines.
Kwaliteit-Kosten Afweging (80 Bron-geverifieerde Taken):
- Runtime LLM Baselines (bijv. Schema-constrained LLM, Crawl4AI): Behaalden een hogere one-shot kwaliteit (0,7051 en 0,6996) en pass rates (81,25% en 80,00%) maar brachten hoge kosten met zich mee (3.400–4.200 tokens per run) en langere wall-clock tijden (14–16s).
- Voorgesteld Framework: Behaalde een lagere one-shot kwaliteit (0,5631) en pass rate (50,00%) maar gebruikte nul LLM-tokens tijdens de executiefase en bereikte de laagste wall-clock tijd (5,052s).
Feedback Correctie: Wanneer toegepast op opzettelijk gebrekkige configuraties, verbeterde de feedback-correctie de gemiddelde uiteindelijke kwaliteit van 0,5087 naar 0,9007 en de pass rate van 0,72% naar 100%, wat de effectiviteit van het herstelmechanisme voor bekende defecttypes aantoont.
Engineering Verificatie: Alle 138 gegenereerde configuraties waren gebaseerd op gedeelde templates (100% reuse rate) en werden succesvol uitgevoerd binnen Airflow 2.8.0.

5. Betekenis en Claims

Het artikel positioneert het framework niet als een algemene vervanging voor runtime LLM-extractie, maar als een herbruikbaar, goedkoop en verifieerbaar executiepad dat geschikt is voor herhaalde, geplande datacolectie.

Filosofie van "Het maken van falen veilig": De auteurs stellen dat gecontroleerd, expliciet falen (via type-beperkingen, schema-validatie en op regels gebaseerde gating) te verkiezen is boven ongecontroleerd, stilzwijgend succes. Fouten worden auditeerbare, traceerbare signalen in plaats van stille datacorruptie.
Erkenning van Trade-offs: Het artikel erkent bescheiden dat hoewel runtime LLM-baselines een superieure one-shot kwaliteit bieden, het voorgestelde framework een deterministisch, geamortiseerd kostenmodel biedt. Door de LLM-kosten te verschuiven naar een eenmalige configuratiegeneratiestap, wordt het framework economisch levensvatbaar voor hoogfrequente, geplande collectietaken waar executiesnelheid en tokenkosten cruciaal zijn.
Beperkingen: De auteurs benoemen expliciet beperkingen, waaronder het gebruik van geconstrueerde vereisten in plaats van ruwe gebruikersverzoeken, het gebrek aan long-horizon significantietoetsen, en de gevoeligheid van het systeem voor complexe interactieve pagina's en authenticatiegrenzen. Het framework is ontworpen voor compliant, publiekelijk toegankelijke datascenario's.