Construyendo un Pipeline de Datos Web para tu Producto de IA
TL;DR
Construya un pipeline de datos web de IA en torno a documentos aceptados respaldados por fuentes, no a un recuento de solicitudes HTTP completadas.
Separe descubrimiento, adquisición, transformación, validación, almacenamiento, indexación y actualización para que cada etapa pueda ser reintentada de manera independiente.
Comience con una página representativa por plantilla, luego expanda un manifiesto de URL delimitado.
Nstdata Crawl puede manejar descubrimiento de sitios, rastreo recursivo, renderización de JavaScript, enrutamiento por proxy y múltiples formatos de salida a través de la API de Crawl.
Realice un seguimiento de los hashes de contenido y las versiones de índice para que las correcciones y eliminaciones puedan ser propagadas.
¿Qué Produce un Pipeline de Datos Web para un Producto de IA?
Un pipeline útil produce un documento versionado o un registro estructurado que el producto puede rastrear hasta una fuente. Para RAG, la salida podría ser Markdown dividido en fragmentos con URLs de origen y caminos de encabezados. Para una característica de extracción, podría ser un objeto JSON tipado con evidencia para cada campo. El pipeline también debería producir registros de fallos: un tiempo de espera, página bloqueada o documento rechazado es un resultado a investigar, no una razón para desaparecer silenciosamente una URL. El producto Nstdata Crawl es una opción gestionada para los pasos de adquisición y conversión discutidos aquí.
El trabajo comienza antes de la obtención. Identifique fuentes permitidas, tipos de página objetivo, expectativas de actualización y la pregunta que el producto de IA debe responder. Un agente de soporte capacitado en la documentación del producto necesita una política de actualización diferente a la de una característica de monitoreo de precios. La guía del pipeline RAG de Databricks separa la preparación del documento de la indexación y el servicio; mantenga esos límites visibles en su propio diseño.
Prepare una lista de fuentes aprobadas; una página estática, una página dinámica y un caso de error; una cuenta de Nstdata y una clave de API de Crawl del lado del servidor si usa adquisición gestionada; y un almacenamiento tanto para registros aceptados como para resultados de trabajos. Defina una clave estable como source_id + canonical_url + extractor_version. Un hash de contenido detecta cambios, pero no es un sustituto de la identidad de URL: dos páginas pueden contener el mismo contenido genérico mientras representan productos diferentes.
Para Nstdata Crawl, la solicitud documentada usa x-api-key, Content-Type: application/json, url y formats. El descubrimiento del sitio también requiere maxDepth, maxPages, includeUrls y excludeUrls explícitos. Los trabajos gestionados estándar utilizan enrutamiento por proxy incorporado, por lo que no se requiere configuración separada de Host, Puerto, Nombre de Usuario, Contraseña o Protocolo. Verifique los límites actuales de la cuenta y las reglas de acceso a la fuente antes de escalar.
¿Cómo Construir el Primer Pipeline Funcional?
Método 1: Prototipo con una URL conocida
Use este camino cuando una aplicación ya conozca la página a recuperar.
Paso 1: Definir un fixture de aceptación
Registre el título esperado, dos frases distintivas, enlaces requeridos y la URL de origen para una página aprobada. Decida qué elemento faltante rechaza el documento.
Paso 2: Obtener Markdown y HTML
La documentación de Crawl muestra una ruta de inicio rápido de una sola página. Almacene la clave en NSTDATA_API_TOKEN y envíe una página representativa:
curl--output response.json --request POST \"https://api.nstdata.io/api/v1/crawl/scrape/submit-sync"\--header"x-api-key: ${NSTDATA_API_TOKEN}"\--header"Content-Type: application/json"\--data'{"url":"https://example.com/","formats":["markdown","html"],"onlyMainContent":true}'
Los documentos públicos contienen etiquetas conflictivas en algunas otras rutas de raspado sincrónicas y asincrónicas; use el inicio rápido documentado y compare la solicitud generada por su Playground antes de la implementación en producción.
Paso 3: Validar el resultado anidado
Verifique data.success, data.status y data.data.metadata.statusCode antes de aceptar markdown. Si la respuesta contiene markdownRef o htmlRef, recupere el token exacto con GET /api/v1/crawl/storage/read?st={ref}. Compare el cuerpo con su fixture; no trate el HTTP 200 externo como prueba de una página útil.
Método 2: Descubrir una sección de sitio delimitada
Use este camino cuando la lista de URL misma deba ser recopilada.
Paso 1: Establecer límites
Elija una URL de inicio, maxDepth, maxPages, includeUrls y excludeUrls. Excluya rutas de búsqueda, de cuenta y generadas por consulta a menos que sean parte del alcance del producto.
Paso 2: Enviar el rastreo
Llame a POST /api/v1/crawl con formats:["markdown"], guarde data.id, luego consulte GET /api/v1/crawl/status/{crawlId}. Un trabajo de sitio descubre enlaces de manera recursiva; no es un punto final de URL a granel ilimitado.
Paso 3: Conciliar resultados
Recuperar GET /api/v1/crawl/pages/{crawlId} y seguir la paginación devuelta. Almacenar por separado las cuentas de enviadas, completadas, fallidas, rechazadas y aceptadas. Comparar el conjunto de URL descubiertas con cualquier mapa del sitio o inventario de fuentes que ya mantenga.
Método 3: Mantener la adquisición local
Utilizar un cliente HTTP local cuando las fuentes sean estables, estáticas y estén dentro de su capacidad operativa. Obtener con un tiempo de espera, ritmo por host y un límite en el tamaño de la respuesta. Analizar el HTML guardado, luego aplicar el mismo accesorio de aceptación y contrato de almacenamiento que el camino administrado. Esta opción le da control directo, pero hace que su equipo sea responsable de la renderización del navegador, selección de proxy, reintentos y observabilidad cuando la fuente cambia.
Escribir un objeto de adquisición en bruto inmutable y un documento aceptado separado. El registro aceptado debe contener source_url, final_url, fetched_at, status_code, content_hash, format, extractor_version, y un puntero al artefacto en bruto. Para RAG, también almacene los ID de fragmentos, rutas de encabezados y versión de índice. Indexar solo registros aceptados; una actualización fallida no debe reemplazar un buen documento por uno vacío.
Hacer que la publicación en el índice de búsqueda sea idempotente. Si un hash de documento no ha cambiado, omitir la re-inserción a menos que el fragmentador o el modelo de inserción hayan cambiado. Si se elimina una página, registrar una lápida y eliminar sus fragmentos de los índices de servicio. Mantener las marcas de tiempo de origen e índice separadas para que una respuesta pueda revelar cuán actual es su evidencia. La guía de diseño de Azure RAG enfatiza la evaluación a través de ingestión, recuperación y calidad de respuesta.
Ejecutar el conjunto de accesorios después de cada cambio de parser o configuración. Rastrear registros aceptados por URL enviada, campos requeridos faltantes, URL canónicas duplicadas, tiempo desde el cambio de fuente hasta la actualización de índice y costo por registro aceptado. Muestre salidas de cada plantilla, no solo de las páginas más fáciles. Para un producto de IA, agregar evaluación a nivel de respuesta: ¿puede el recuperador localizar el documento correcto y cita el modelo el rango de fuente que respalda su respuesta?
Nstdata Crawl puede reducir el trabajo de adquisición, pero no elige su esquema de campo ni evalúa una respuesta. Utilice Cloud Browser para flujos de trabajo que necesitan interacción continua con la página en lugar de conversión de página a datos. Mantenga bien definidos estos límites de producto al diseñar el pipeline.
Dar a cada etapa una identidad de entrada y salida durable. El descubrimiento debe emitir un manifiesto de URL con política de fuente e ID de ejecución. La adquisición debe guardar un artefacto en bruto y un resultado terminal para cada URL, incluyendo fallos. La transformación debe hacer referencia al ID de artefacto y versión de parser. La indexación debe hacer referencia a la versión del documento aceptado. Con estos enlaces, un trabajador puede volver a intentar su propia etapa sin reproducir cada etapa anterior.
Para un producto de múltiples sitios, particionar el manifiesto por fuente. Un sitio de documentación, un catálogo de productos y un feed de noticias tienen diferentes tasas de actualización y plantillas de página. Mantener cuotas por fuente y presupuestos de error para que un sitio roto no consuma toda la cola. Un propietario de fuente debe poder pausar una partición sin detener la colección válida en otros lugares.
Utilizar un procesamiento al menos una vez con escrituras idempotentes cuando la ejecución perfecta exactamente una vez es impráctica. Un trabajador puede terminar de escribir un documento y fallar antes de reconocer su mensaje en la cola. Al reiniciarse, verá ese mensaje nuevamente. Una clave estable como source_id + canonical_url + content_hash + parser_version le permite reconocer la misma versión. No deduplicar únicamente en el hash de contenido: dos páginas legítimas pueden contener texto corto idéntico mientras tienen significados de fuente diferentes.
Establecer un estado terminal para fallas. retry_pending debe tener un próximo tiempo elegible y cuenta de intentos. rejected debe tener una razón de calidad de contenido o política. failed_terminal debe preservar el último error. Un tablero que cuenta solo complete deja al equipo incapaz de conciliar el manifiesto de URL con los documentos entregados.
¿Cómo Previene que Datos Incorrectos Alcancen el Índice?
Utilice un paso de promoción en lugar de escribir un resultado de obtención directamente en el almacenamiento de servicio. Compare el candidato con la versión aceptada anterior. Verifique el tipo de página esperado, el título, el contenido relevante mínimo, el idioma, los campos requeridos y los cambios sospechosos en la longitud. Una caída del 95% en la longitud del texto puede ser una reescritura válida, pero merece inspección antes de un reemplazo automatizado. Para registros estructurados, valide tipos, monedas, unidades e identidad de entidades en lugar de solo la sintaxis JSON.
Mantenga una última versión válida y marque su antigüedad con precisión. Si una actualización produce una página de inicio de sesión o un error, el producto actual debería mostrar el registro más antiguo con un indicador de obsolescencia o suprimirlo de acuerdo con su caso de uso. No debe publicar la captura fallida como contenido actual. Ese mismo paso de promoción es donde pertenecen el filtrado de políticas y la minimización de datos personales.
Para RAG, pruebe la recuperación después de la promoción. Un trabajo de incrustación exitoso no prueba que se devolverá el fragmento correcto. Mantenga un pequeño conjunto de preguntas cuyas respuestas se correspondan con tramos de origen conocidos; compare la recuperación y las citas después de cada cambio de índice. Esto separa un fallo de extracción de un fallo de fragmentación o clasificación.
Para la extracción estructurada, mantenga el tramo de evidencia para cada campo. Si un precio cambia inesperadamente, un revisor puede inspeccionar el texto exacto de la página o la captura renderizada que lo produjo. Esto es más útil que un objeto JSON sin procedencia. El mismo registro puede volver a validarse cuando cambian las reglas comerciales, y los campos erróneos pueden corregirse sin tratar toda la recopilación como inutilizable.
No. Indexe solo las páginas que superen las comprobaciones de estado, contenido, alcance y semántica.
P: ¿Puede una actualización exitosa empeorar el producto?
Sí. Un muro de consentimiento o página incompleta recién obtenida puede reemplazar contenido bueno a menos que la validación bloquee la promoción.
P: ¿Cuál es la primera prueba de escala útil?
Pruebe varias plantillas y casos de fallo bajo el mismo contrato de aceptación antes de aumentar el volumen de páginas.
Este tutorial de Python pasa de una página estática a registros validados y renderizado gestionado. Incluye ejemplos ejecutables, diagnóstico de fallos, controles de versión y un contrato de datos listo para inteligencia artificial.
Marcus Chen
Oct. 29th 2026
Rastrea sitios web completos con una sola solicitud API
99,8% de éxito con renderizado JavaScript
Obtén datos limpios, listos para LLM, en múltiples formatos
Convierte cualquier sitio web en Markdown, HTML, JSON, enlaces, PDF y más, sin gestionar infraestructura de rastreo.
