🤖 AI

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

Cet article propose un cadre d'agent contraint et vérifiable qui remplace la génération de code non fiable en texte libre par des LLM par des configurations de collecteurs JSON typées et des pipelines d'exécution statiques afin de parvenir à une collecte de données sur le web ouvert déterministe, à bas coût et réutilisable.

Auteurs originaux : Bo Chen

Publié 2026-07-02

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Bo Chen

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous deviez embaucher un robot pour sortir et collecter des informations spécifiques sur des milliers de sites web différents chaque jour. Vous pourriez simplement dire au robot : « Va chercher les infos », en espérant qu'il comprenne comment faire. Mais comme l'explique l'article, cette approche de « foire d'empoigne » est comme envoyer un enfant dans une bibliothèque sans instructions ; il pourrait attraper les mauvais livres, trébucher sur des chaises ou revenir avec un mélange confus de pages.

Cet article propose une nouvelle façon de construire ces robots de collecte de données (appelés « agents ») qui rend l'échec sûr, prévisible et facile à corriger. Voici comment cela fonctionne, décomposé en concepts simples :

1. Le Problème : Le « Far West » du Web Scraping

Actuellement, si vous demandez à une IA d'écrire un code pour extraire les données d'un site web, elle essaie souvent d'écrire un tout nouveau script à partir de zéro à chaque fois.

Le Problème : Les sites web sont désordonnés et changent souvent. Si l'IA se trompe sur l'emplacement d'une étiquette de prix sur une page, tout le script casse.
Le Résultat : Vous obtenez des erreurs, des données brisées ou des scripts qui cessent de fonctionner dès qu'un site web met à jour sa mise en page. C'est comme essayer de construire une maison en devinant où placer chaque brique à chaque fois que vous en posez une.

2. La Solution : L'approche « Kit LEGO »

Au lieu de laisser l'IA écrire du code libre (comme écrire un roman), les auteurs la forcent à remplir un formulaire structuré (comme remplir une fiche d'instructions LEGO).

La Taxonomie (Les 6 types) : Le système demande d'abord : « Quel genre de tâche est-ce ? ». Il catégorise les tâches en six types spécifiques, comme un menu :
1. Recherche (Search) : Trouver des liens basés sur des mots-clés.
2. Liste (List) : Parcourir des pages d'articles (comme une archive de presse).
3. Détail (Detail) : Lire le contenu complet d'une seule page.
4. API : Demander directement des données à un ordinateur (comme commander à la carte).
5. Interactif (Interactive) : Cliquer sur des boutons ou taper sur des pages dynamiques.
6. Fichier (File) : Télécharger des PDF ou des fichiers Excel.
- Analogie : Au lieu de dire à un chef « fais à manger », vous lui dites « tu prépares une soupe », et il n'utilise que les outils et les recettes pour la soupe. Cela l'empêche d'essayer de faire un gâteau quand vous vouliez une soupe.
Les Contraintes (Les garde-fous) : L'IA n'est pas autorisée à inventer du nouveau code. Elle doit choisir dans une bibliothèque approuvée de « fonctions utilitaires » (outils pré-construits) et remplir les blancs d'un modèle.
- Analogie : Pensez à un jeu de « Mad Libs » où l'IA peut seulement remplir les espaces vides prévus, plutôt que d'écrire toute l'histoire elle-même. Cela garantit que la sortie est toujours dans un format compréhensible par l'ordinateur.

3. Le Processus : La boucle de « Test Drive »

Le framework ne lance pas le robot immédiatement. Il utilise une boucle stricte « Générer → Vérifier → Corriger » :

Générer : L'IA crée un fichier de configuration (un plan JSON) basé sur la requête de l'utilisateur.
Test Drive (Validation) : Avant de lancer la tâche complète, le système effectue un petit test peu coûteux sur seulement quelques pages.
Le Contrôle Qualité (L'arbitre) : Un système basé sur des règles (et non une IA) vérifie les résultats. Il demande : « Avons-nous obtenu les bons champs ? Les données sont-elles vides ? Est-ce que ça a planté ? »
- Point crucial : Si le test échoue, le système ne dit pas simplement « réessaie ». Il crée une « liste noire » spécifique de ce qu'il ne faut pas faire (ex : « Ne pas chercher le prix dans le pied de page »).
Corriger : L'IA réessaie, mais cette fois, elle est contrainte d'éviter les erreurs qu'elle vient de commettre.
Passage à l'échelle : Ce n'est que lorsque le test drive réussit que le système lance la collecte complète.

4. Les Résultats : Vitesse vs Perfection

Les auteurs ont testé cela sur 138 tâches de collecte de données différentes. Voici ce qu'ils ont trouvé :

Qualité en un coup (One-Shot) : Si vous voulez juste récupérer des données une seule fois maintenant, les autres méthodes qui laissent l'IA écrire du code libre peuvent obtenir des résultats légèrement meilleurs immédiatement (environ 70 % de succès contre 50 % pour cette méthode).
Le Compromis : Cependant, la méthode des auteurs est beaucoup plus rapide et beaucoup moins chère à exécuter de manière répétée.
- La Magie : Une fois le plan établi, la collecte réelle s'exécute sans utiliser aucune IA. Elle exécute simplement le plan pré-établi.
- Analogie : Les autres méthodes sont comme embaucher un traducteur humain pour chaque phrase lue. Cette méthode est comme embaucher un traducteur une fois pour écrire un dictionnaire, puis utiliser ce dictionnaire pour toujours.
Fiabilité : Lorsque le système échouait, il ne tombait pas en panne silencieusement. Il produisait un rapport d'erreur clair, permettant à la boucle de « Correction » de rectifier le tir. Dans leurs tests, cette boucle de rétroaction a transformé un système défaillant (0 % de taux de réussite) en un système parfait (100 % de taux de réussite).

Résumé

Cet article soutient que nous ne devrions pas essayer de rendre l'IA « parfaite » pour deviner comment extraire des données du web. Au lieu de cela, nous devrions contraindre l'IA à suivre des règles strictes, à utiliser des outils pré-construits et à effectuer un « test drive » avant le travail réel.

En échangeant un peu de perfection initiale contre un système vérifiable, réutilisable et peu coûteux, ce framework rend la collecte automatisée de données suffisamment fiable pour un usage programmé dans le monde réel (comme rassembler des actualités ou des données gouvernementales chaque matin) sans avoir besoin d'un humain pour corriger le code à chaque fois qu'un site web change.

Résumé Technique : Rendre l'échec sûr : Un cadre d'agent contraint et vérifiable pour la collecte de données sur le web ouvert

1. Définition du problème

Le papier traite de l'imprévisibilité de l'utilisation des grands modèles de langage (LLM) et des agents pour la collecte directe de données sur le web ouvert. Bien que les LLM puissent générer du code de scraping à partir de langage naturel, l'application directe souffre d'une fragilité structurelle due à l'hétérogénéité des pages web et à l'incohérence stochastique de la génération de code par les LLM. Les modes de défaillance courants incluent les erreurs de dépendance, les sélecteurs brisés, les décalages de schéma et les formats de sortie incohérents. Les pipelines traditionnels reposent sur un effort manuel, tandis que les approches d'agents non contraints manquent de vérifiabilité, ce qui rend difficile l'audit, la mesure ou la correction des échecs dans un environnement de production.

Le défi central est de passer d'un « raisonnement d'agent parfait » à un « pipeline de collecte vérifiable » où chaque étape de l'entrée et de la sortie peut être contrôlée, mesurée et auditée.

2. Méthodologie

Les auteurs proposent un cadre d'agent contraint et vérifiable qui remplace la génération de code libre par la génération de configurations de collecteurs JSON typées. Le système opère sur une boucle fermée « générer–exécuter–vérifier–corriger », découplant le rôle du LLM (compréhension des exigences et génération de configuration) du moteur d'exécution (DAG Airflow statiques).

2.1 Taxonomie des six types de collecteurs

Pour imposer des limites structurelles, le cadre définit une taxonomie de six types de collecteurs, chacun possédant des limites fonctionnelles explicites et des règles de composition :

Recherche (Search) : Découvre des URL candidates via des mots-clés (pas d'extraction de contenu).
Liste (List) : Parcourt des listes paginées pour trouver des liens de détails (pas d'extraction de contenu profond).
Détail (Detail) : Extrait des champs structurés d'une page unique.
API : Appelle des API publiques et mappe les champs de réponse (pas d'interaction avec le navigateur).
Interactif (Interactive) : Exécute des clics et des saisies sur des pages dynamiques (pas de contournement d'authentification/CAPTCHA).
Fichier (File) : Télécharge et analyse des fichiers publics (PDF, Excel).

2.2 Cadre d'agent contraint

Le cadre se compose de cinq modules opérant sous quatre catégories de contraintes :

Agent de compréhension des exigences : Convertit les descriptions en langage naturel ( $d$ ) en une représentation complète de la tâche ( $R$ ) en sondant proactivement le site cible (page d'accueil, sitemap, pages d'exemple) pour extraire le contexte de la source ( $x$ ).
Agent d'instanciation de collecteur : Génère des configurations JSON ( $M$ $M$ ) en utilisant une approche de « codage de référence + remplissage de gabarits ». Au lieu d'écrire du code, l'agent remplit des emplacements dans des modèles préconstruits, contraints par :
- Contraintes de type de tâche : Garantissant que le bon type de collecteur est sélectionné.
- Contraintes de structure de configuration : Imposant la conformité au schéma JSON.
- Contraintes de réutilisation d'outils : Réutilisant des fonctions utilitaires pré-construites plutôt que de générer du nouveau code.
Validation Airflow et exécution à l'échelle : Un DAG Airflow statique exécute les configurations JSON. Les exécutions de validation utilisent des paramètres de petit échantillon pour déplacer les erreurs vers une étape de pré-production à faible coût, tandis que les exécutions à l'échelle utilisent des paramètres de production. Cela garantit qu'aucun jeton (token) de LLM n'est consommé pendant l'exécution.
Module de contrôle de qualité : Un évaluateur déterministe basé sur des règles (sans LLM) note les résultats selon cinq dimensions : Structure, Contenu, Pertinence, Pièce jointe et Exécution. Il produit un score composite ( $S$ ) et un rapport d'erreur.
Module de correction par rétroaction : Convertit les rapports de qualité en contraintes de rétroaction structurées (ex: listes noires d'échecs, hypothèses prohibées). L'agent d'instanciation régénère la configuration sous ces nouvelles contraintes, formant une boucle fermée.

3. Principales contributions

Taxonomie des six types de collecteurs : Un système de classification formel avec des limites explicites et des règles de composition pour standardiser les tâches de collecte.
Cadre d'agent contraint : Un système qui déplace la sortie du LLM du code libre vers des configurations JSON typées sous une hiérarchie de quatre niveaux de contraintes imbriquées (type $\to$ modèle $\to$ utilitaire $\to$ validation).
Boucle fermée vérifiable : Un mécanisme « générer–exécuter–vérifier–corriger » utilisant un filtrage de qualité basé sur des règles et une correction de rétroaction structurée, permettant des signaux d'échec auditables.
Validation expérimentale multi-niveaux : Tests complets couvrant la classification des exigences, l'instanciation de collecteurs, les compromis qualité-coût par rapport aux baselines de LLM au runtime, et la compatibilité Airflow.

4. Résultats expérimentaux

Le cadre a été évalué sur un ensemble de 138 tâches de collecte (80 vérifiées à la source).

Classification des exigences : Le système a atteint un Macro-F1 de 0,7793 pour la classification des types de collecteurs à partir de descriptions, surpassant une baseline de mots-clés basée sur des règles (0,7562). Cependant, les auteurs notent que les descriptions seules sont insuffisantes pour les tâches ambiguës (ex: « détail » vs « liste »), nécessitant un sondage proactif.
Instanciation de collecteur : Le cadre contraint a atteint un score de qualité moyen de 0,5369 et un taux de réussite de 55,07 %, surpassant significativement la génération LLM non contrainte (qualité de 0,4876, correspondance de type de 18,84 %) et les baselines basées sur des règles.
Compromis Qualité-Coût (80 tâches vérifiées à la source) :
- Baselines LLM au runtime (ex: LLM contraint par schéma, Crawl4AI) : Ont atteint une qualité et un taux de réussite en un seul passage (one-shot) plus élevés (0,7051 et 0,6996 de qualité ; 81,25 % et 80,00 % de réussite) mais ont engendré des coûts élevés (3 400–4 200 jetons par exécution) et des temps d'exécution plus longs (14–16s).
- Cadre proposé : A atteint une qualité et un taux de réussite en un seul passage plus faibles (0,5631 et 50,00 %) mais a utilisé zéro jeton LLM lors de l'étape d'exécution et a obtenu le temps d'exécution le plus court (5,052s).
Correction par rétroaction : Appliquée à des configurations intentionnellement défectueuses, la correction par rétroaction a amélioré la qualité moyenne finale de 0,5087 à 0,9007 et le taux de réussite de 0,72 % à 100 %, démontrant l'efficacité du mécanisme de réparation pour les types de défauts connus.
Vérification d'ingénierie : Les 138 configurations générées étaient ancrées dans des modèles partagés (taux de réutilisation de 100 %) et ont été exécutées avec succès dans Airflow 2.8.0.

5. Signification et affirmations

Le papier positionne le cadre non pas comme un remplacement général de l'extraction par LLM au runtime, mais comme un chemin d'exécution réutilisable, à faible coût et vérifiable adapté à la collecte de données répétée et planifiée.

Philosophie de « Rendre l'échec sûr » : Les auteurs soutiennent qu'un échec contrôlé et explicite (via des contraintes de type, la validation de schéma et le filtrage basé sur des règles) est préférable à un succès non contrôlé et silencieux. Les échecs deviennent des signaux auditables et traçables plutôt que des corruptions de données silencieuses.
Reconnaissance des compromis : Le papier reconnaît modestement que, bien que les baselines LLM au runtime offrent une qualité en un seul passage supérieure, le cadre proposé offre un modèle de coût déterministe et amorti. En déplaçant les coûts du LLM vers une étape unique de génération de configuration, le cadre devient économiquement viable pour les tâches de collecte haute fréquence et planifiées où la vitesse d'exécution et le coût des jetons sont critiques.
Limites : Les auteurs déclarent explicitement les limites, notamment l'utilisation de exigences construites plutôt que de requêtes utilisateurs brutes, l'absence de tests de signification à long terme, et la sensibilité du système aux pages interactives complexes et aux frontières d'authentification. Le cadre est conçu pour des scénarios de collecte de données conformes et accessibles publiquement.