🤖 AI

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

Este artículo propone un marco de agentes restringido y verificable que reemplaza la generación de código de forma libre e impredecible de los LLM por configuraciones de colectores JSON tipados y canales de ejecución estáticos para lograr una recolección de datos de la web abierta determinista, de bajo costo y reutilizable.

Autores originales: Bo Chen

Publicado 2026-07-02

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Bo Chen

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que necesitas contratar a un robot para que salga a recolectar información específica de miles de sitios web diferentes cada día. Podrías simplemente decirle al robot: "Ve a buscar las noticias", y esperar que él mismo descubra cómo hacerlo. Pero, como explica el artículo, este enfoque de "todo vale" es como enviar a un niño a una biblioteca sin instrucciones; podrían agarrar los libros equivocados, tropezar con las sillas o regresar con un desorden de páginas mezcladas.

Este artículo propone una nueva forma de construir estos robots recolectores de datos (llamados "agentes") que hace que el proceso sea seguro ante fallos, predecible y fácil de reparar. Así es como funciona, desglosado en conceptos sencillos:

1. El Problema: El "Lejano Oeste" del Web Scraping

Actualmente, si le pides a una IA que escriba código para extraer datos de un sitio web, a menudo intenta escribir un guion completamente nuevo desde cero cada vez.

El Problema: Los sitios web son desordenados y cambian con frecuencia. Si la IA adivina mal dónde se encuentra la etiqueta de un precio en una página, todo el guion se rompe.
El Resultado: Obtienes errores, datos corruptos o guiones que dejan de funcionar en el momento en que un sitio web actualiza su diseño. Es como intentar construir una casa adivinando dónde van los ladrillos cada vez que colocas uno.

2. La Solución: El enfoque del "Kit de LEGO"

En lugar de dejar que la IA escriba código libre (como escribir una novela), los autores la obligan a completar un formulario estructurado (como completar una hoja de instrucciones de LEGO).

La Taxonomía (Los 6 tipos): El sistema primero pregunta: "¿Qué tipo de trabajo es este?". Categoriza las tareas en seis tipos específicos, como un menú:
1. Búsqueda (Search): Encontrar enlaces basados en palabras clave.
2. Lista (List): Recorrer páginas de artículos (como un archivo de noticias).
3. Detalle (Detail): Leer el contenido completo de una sola página.
4. API: Pedir datos directamente a una computadora (como pedir algo de un menú).
5. Interactivo (Interactive): Hacer clic en botones o escribir en páginas dinámicas.
6. Archivo (File): Descargar archivos PDF o Excel.
- Analogía: En lugar de decirle a un chef "haz la cena", le dices "estás haciendo una sopa" y solo utiliza las herramientas y recetas para la sopa. Esto evita que intente hornear un pastel cuando querías una sopa.
Las Restricciones (Los rieles de seguridad): La IA no tiene permitido inventar código nuevo. Debe elegir de una biblioteca preaprobada de "funciones de utilidad" (herramientas preconstruidas) y completar los espacios en blanco de una plantilla.
- Analogía: Piensa en ello como un juego de "Mad Libs" donde la IA solo puede rellenar los espacios específicos proporcionados, en lugar de escribir la historia completa por sí misma. Esto asegura que la salida esté siempre en un formato que la computadora pueda entender.

3. El Proceso: El bucle de "Prueba de Manejo"

El marco de trabajo no envía al robot inmediatamente. Utiliza un bucle estricto de "Generar → Verificar → Corregir":

Generar: La IA crea un archivo de configuración (un plan JSON) basado en la solicitud del usuario.
Prueba de Manejo (Validación): Antes de ejecutar el trabajo completo, el sistema realiza una prueba pequeña y económica en solo unas pocas páginas.
El Control de Calidad (El Árbitro): Un sistema basado en reglas (no una IA) verifica los resultados. Pregunta: "¿Obtuvimos los campos correctos? ¿Los datos están vacíos? ¿Hubo un error crítico?".
- Punto Crucial: Si la prueba falla, el sistema no se limita a decir "inténtalo de nuevo". Crea una "lista negra" específica de lo que no se debe hacer (por ejemplo: "No busque el precio en el pie de página").
Corregir: La IA lo intenta de nuevo, pero esta vez se le obliga a evitar los errores que cometió anteriormente.
Escalar: Solo cuando la prueba de manejo pasa, el sistema ejecuta el trabajo de recolección completo.

4. Los Resultados: Velocidad vs. Perfección

Los autores probaron esto en 138 tareas de recolección de datos diferentes. Esto fue lo que encontraron:

Calidad de un solo intento (One-Shot): Si solo quieres obtener datos una vez ahora mismo, otros métodos que permiten a la IA escribir código libre podrían obtener resultados ligeramente mejores de inmediato (aproximadamente un 70% de éxito frente al 50% de este método).
El Intercambio (Trade-off): Sin embargo, el método de los autores es mucho más rápido y mucho más barato de ejecutar repetidamente.
- La Magia: Una vez creado el plan, la recolección real se ejecuta sin utilizar ninguna IA. Simplemente ejecuta el plan preestablecido.
- Analogía: Otros métodos son como contratar a un traductor humano para cada frase que lees. Este método es como contratar a un traductor una vez para escribir un diccionario, y luego usar ese diccionario para siempre.
Fiabilidad: Cuando el sistema fallaba, no fallaba silenciosamente. Producía un informe de error claro, lo que permitía al bucle de "Corregir" rectificarlo. En sus pruebas, este bucle de retroalimentación convirtió un sistema fallido (0% de tasa de aprobación) en uno perfecto (100% de tasa de aprobación).

Resumen

Este artículo argumenta que no deberíamos intentar que la IA sea "perfecta" adivinando cómo extraer datos de la web. En su lugar, debemos limitar a la IA para que siga reglas estrictas, utilice herramientas preconstruidas y realice una "prueba de manejo" antes de realizar el trabajo real.

Al cambiar un poco de perfección inicial por un sistema que es verificable, reutilizable y económico de ejecutar, este marco de trabajo hace que la recolección automatizada de datos sea lo suficientemente confiable para un uso programado en el mundo real (como recopilar noticias o datos gubernamentales cada mañana) sin necesidad de que un humano repare el código cada vez que un sitio web cambia.

Resumen Técnico: Hacer que el fallo sea seguro: Un marco de agentes con restricciones y verificable para la recolección de datos en la web abierta

1. Definición del Problema

El artículo aborda la falta de fiabilidad al utilizar Modelos de Lenguaje de Gran Escala (LLMs) y agentes para la recolección directa de datos en la web abierta. Aunque los LLMs pueden generar código de raspado (scraping) a partir de lenguaje natural, su aplicación directa sufre de una fragilidad estructural debido a la heterogeneidad de las páginas web y la inconsistencia estocástica de la generación de código por parte de los LLMs. Los modos de fallo comunes incluyen errores de dependencia, selectores rotos, desajustes de esquemas e inconsistencias en los formatos de salida. Los pipelines tradicionales dependen del esfuerzo manual, mientras que los enfoques de agentes sin restricciones carecen de verificabilidad, lo que dificulta la auditoría, la medición o la corrección de fallos en un entorno de producción.

El desafío central es pasar de un "razonamiento de agente perfecto" a un "pipeline de recolección verificable" donde cada etapa de entrada y salida pueda ser comprobada, medida y auditada.

2. Metodología

Los autores proponen un marco de agentes con restricciones y verificable que reemplaza la generación de código de forma libre por la generación de configuraciones de recolectores en formato JSON tipado. El sistema opera sobre un bucle cerrado de "generar–ejecutar–comprobar–corregir", desacoplando el rol del LLM (comprensión de requisitos y generación de configuración) del motor de ejecución (DAGs estáticos de Airflow).

2.1 Taxonomía de Seis Tipos de Recolectores

Para imponer límites estructurales, el marco define una taxonomía de seis tipos de recolectores, cada uno con límites funcionales explícitos y reglas de composición:

Búsqueda (Search): Descubre URLs candidatas mediante palabras clave (sin extracción de contenido).
Lista (List): Recorre listas paginadas para encontrar enlaces de detalle (sin extracción profunda de contenido).
Detalle (Detail): Extrae campos estructurados de una sola página.
API: Llama a APIs públicas y mapea campos de respuesta (sin interacción con el navegador).
Interactivo (Interactive): Ejecuta clics y entradas en páginas dinámicas (sin eludir autenticación o CAPTCHAs).
Archivo (File): Descarga y analiza archivos públicos (PDF, Excel).

2.2 Marco de Agentes con Restricciones

El marco consta de cinco módulos que operan bajo cuatro categorías de restricciones:

Agente de Comprensión de Requisitos: Convierte descripciones en lenguaje natural ( $d$ ) en una representación completa de la tarea ( $R$ ) mediante el sondeo proactivo del sitio objetivo (página de inicio, sitemap, páginas de muestra) para extraer el contexto de la fuente ( $x$ ).
Agente de Instanciación de Recolector: Genera configuraciones JSON ( $M$ $M$ ) utilizando un enfoque de "codificación de referencia + llenado de espacios de plantilla". En lugar de escribir código, el agente llena espacios en plantillas preconstruidas restringidas por:
- Restricciones de tipo de tarea: Asegurando que se seleccione el tipo de recolector correcto.
- Restricciones de estructura de configuración: Imponiendo el cumplimiento del esquema JSON.
- Restricciones de reutilización de herramientas: Reutilizando funciones de utilidad preconstruidas en lugar de generar código nuevo.
Validación y Ejecución a Escala en Airflow: Un DAG estático de Airflow ejecuta las configuraciones JSON. Las ejecuciones de validación utilizan parámetros de muestras pequeñas para desplazar los errores a una etapa de preproducción de bajo costo, mientras que las ejecuciones a escala utilizan parámetros de producción. Esto asegura que no se consuman tokens de LLM durante la ejecución.
Módulo de Control de Calidad: Un evaluador determinista basado en reglas (sin LLM) califica los resultados en cinco dimensiones: Estructura, Contenido, Relevancia, Adjunto y Ejecución. Produce una puntuación compuesta ( $S$ ) y un informe de errores.
Módulo de Corrección por Retroalimentación: Convierte los informes de calidad en restricciones de retroalimentación estructuradas (por ejemplo, listas negras de fallos, hipótesis prohibidas). El agente de instanciación regenera la configuración bajo estas nuevas restricciones, formando un bucle cerrado.

3. Contribuciones Clave

Taxonomía de Seis Tipos de Recolectores: Un sistema de clasificación formal con límites explícitos y reglas de composición para estandarizar las tareas de recolección.
Marco de Agentes con Restricciones: Un sistema que desplaza la salida del LLM de la generación de código libre a configuraciones JSON tipadas bajo una jerarquía de cuatro niveles de restricciones anidadas (tipo $\to$ plantilla $\to$ utilidad $\to$ validación).
Bucle Cerrado Verificable: Un mecanismo de "generar–ejecutar–comprobar–corregir" que utiliza puertas de control de calidad basadas en reglas y corrección de retroalimentación estructurada, permitiendo señales de fallo auditables.
Validación Experimental Multinivel: Pruebas exhaustivas que cubren la clasificación de requisitos, la instanciación de recolectores, las compensaciones de calidad-costo frente a los baselines de LLM en tiempo de ejecución y la compatibilidad con Airflow.

4. Resultados Experimentales

El marco fue evaluado en un conjunto de datos de 138 tareas de recolección (80 verificadas por la fuente).

Clasificación de Requisitos: El sistema alcanzó un Macro-F1 de 0.7793 en la clasificación de tipos de recolectores a partir de descripciones, superando a un baseline de palabras clave basado en reglas (0.7562). Sin embargo, los autores señalan que las descripciones por sí solas son insuficientes para tareas ambiguas (ej. "detalle" vs. "lista"), lo que requiere un sondeo proactivo.
Instanciación de Recolector: El marco restringido logró una puntuación de calidad promedio de 0.5369 y una tasa de éxito del 55.07%, superando significativamente la generación de LLM no restringida (calidad de 0.4876, coincidencia de tipo del 18.84%) y los baselines basados en reglas.
Compensación Calidad-Costo (80 Tareas Verificadas por la Fuente):
- Baselines de LLM en Tiempo de Ejecución (ej. LLM con restricción de esquema, Crawl4AI): Lograron una mayor calidad de un solo paso (0.7051 y 0.6996) y tasas de éxito (81.25% y 80.00%) pero incurrieron en altos costos (3,400–4,200 tokens por ejecución) y tiempos de reloj más largos (14–16s).
- Marco Propuesto: Logró una calidad de un solo paso menor (0.5631) y una tasa de éxito inferior (50.00%) pero utilizó cero tokens de LLM en la etapa de ejecución y logró el menor tiempo de reloj (5.052s).
Corrección por Retroalimentación: Al aplicarse a configuraciones intencionalmente defectuosas, la corrección por retroalimentación mejoró la calidad promedio final de 0.5087 a 0.9007 y la tasa de éxito de 0.72% a 100%, demostrando la eficacia del mecanismo de reparación para tipos de defectos conocidos.
Verificación de Ingeniería: Las 138 configuraciones generadas se basaron en plantillas compartidas (tasa de reutilización del 100%) y se ejecutaron con éxito dentro de Airflow 2.8.0.

5. Significado y Reivindicaciones

El artículo posiciona el marco no como un reemplazo general para la extracción de LLM en tiempo de ejecución, sino como una vía de ejecución reutilizable, de bajo costo y verificable adecuada para la recolección de datos programada y repetitiva.

Filosofía de "Hacer que el Fallo sea Seguro": Los autores argumentan que un fallo controlado y explícito (mediante restricciones de tipo, validación de esquema y puertas de control basadas en reglas) es preferible a un éxito silencioso y no controlado. Los fallos se convierten en señales auditables y trazables en lugar de corrupción silenciosa de datos.
Reconocimiento de Compensaciones: El artículo reconoce modestamente que, si bien los baselines de LLM en tiempo de ejecución ofrecen una calidad de un solo paso superior, el marco propuesto ofrece un modelo de costo determinista y amortizado. Al desplazar los costos del LLM a un paso de generación de configuración de una sola vez, el marco se vuelve económicamente viable para tareas de recolección de alta frecuencia y programadas donde la velocidad de ejecución y el costo de los tokens son críticos.
Limitaciones: Los autores declaran explícitamente limitaciones, incluyendo el uso de requisitos construidos en lugar de solicitudes de usuario puras, la falta de pruebas de significancia de largo alcance y la sensibilidad del sistema ante páginas interactivas complejas y límites de autenticación. El marco está diseñado para escenarios de recolección de datos públicos y de cumplimiento normativo.