Alimentando su sistema RAG con datos web frescos (Paso a Paso)
TL;DR
Un pipeline de ingestión RAG necesita un rastreo de fuente de verdad, una identidad de documento estable y un camino de actualización; las incrustaciones por sí solas no mantienen las respuestas actuales.
Utilice un rastreo de sitio para el descubrimiento de documentación limitado, luego valide cada página antes de limpiarla, dividirla, incrustarla e indexarla.
Almacene source_url, crawled_at, content_hash, y una ID de página estable con cada fragmento para que las actualizaciones y citas se mantengan manejables.
Trate el código a continuación como un plano de integración: los campos de la API siguen la documentación actual de Nstdata y de la biblioteca, pero el camino de extremo a extremo no se ejecutó con credenciales en vivo.
Introducción: Los datos frescos de la web son un problema de ingestión
Nstdata Crawl es la capa de colección en este flujo de trabajo; su visión general del producto describe la recuperación de páginas y sitios para los pipelines de datos en downstream.
Un modelo de lenguaje puede explicar una API a partir de sus datos de entrenamiento y aún así darle un nombre de parámetro obsoleto. Un sistema RAG reduce esa brecha al recuperar documentos en el momento de la respuesta, pero la recuperación es tan actual como los documentos ya indexados. Para alimentar un sistema RAG con datos frescos de la web, necesita un camino repetible desde las URL de origen hasta los registros validados y una forma de reemplazar o eliminar registros antiguos.
Esta guía construye ese camino para la documentación pública: Nstdata Crawl → Validación de Markdown → fragmentos conscientes de encabezados → incrustaciones → Chroma → recuperación. Se enfoca en la ingestión y frescura, no en entrenar un modelo. Nstdata Crawl maneja la adquisición de páginas y la conversión de contenido; su aplicación aún posee la política de datos, la segmentación, la indexación, el control de acceso y la evaluación de respuestas. La guía actual de Crawl describe la salida de Markdown, tareas de página/sitio, SDK de Python, estado de tareas y referencias de resultados grandes en su .
La ingestión de datos RAG es el proceso que convierte el material de origen en registros que un sistema de recuperación puede buscar. Los datos de entrenamiento del modelo están incorporados en los pesos del modelo. Un índice RAG es una colección externa, reemplazable de documentos e incrustaciones. Los datos web en vivo son lo que su colector recupera de un sitio ahora; no llegan al modelo hasta que su pipeline lo valida e indexa.
Si una página de docs cambia a las 10:00 pero su índice se reconstruye semanalmente, una consulta a las 10:05 puede aún recuperar las instrucciones de la semana pasada. La respuesta puede sonar fluida y estar aún obsoleta. Registre tanto cuando se recopiló el origen como qué versión del contenido fue indexada para hacer visible ese retraso.
Pipeline a simple vista
Etapa
Entrada → salida
Verificación principal
Descubrir
dominio, sitemap o lista de URL → URLs permitidas
¿Están las URLs dentro del alcance y permitidas?
Rastrear
URL → Markdown y metadatos de página
¿Completó la tarea y el cuerpo contiene el contenido esperado?
Normalizar
página recuperada → registro de documento canónico
¿Son estables la URL, el título, la versión y el hash del contenido?
Dividir
documento → pasajes recuperables
¿Se mantuvieron intactos los encabezados, el código y las tablas?
Incrustar y almacenar
pasajes → vectores más metadatos
¿Coinciden la dimensión del vector y los IDs de registro con el índice?
Recuperar y responder
pregunta → evidencia y respuesta citada
¿Se puede rastrear la respuesta a los pasajes de origen actuales?
Requisitos previos y la pila de ejemplo
Utilice Python 3.10 o posterior, un token de Nstdata Crawl, una clave de proveedor de incrustaciones y una colección de Chroma. Instale los SDK y bloquee las versiones resueltas en su proyecto después de una ejecución de staging:
Las versiones exactas deben registrarse en su archivo de bloqueo porque el comportamiento del SDK puede cambiar. El entorno utilizado para preparar este borrador no tiene credenciales de Crawl ni de OpenAI, por lo que las llamadas al servicio a continuación no se han ejecutado en vivo.
Paso 1: Seleccionar y descubrir fuentes web
Comience con un inventario corto en lugar de rastrear un dominio entero. Para un sitio de docs, incluya las páginas actuales de producto y referencia de API, luego excluya login, búsqueda, archivos de registro de cambios y rutas de marketing no relacionadas si están fuera de la base de conocimientos. Utilice un sitemap y enlaces de navegación juntos cuando necesite comparar las URL declaradas con las páginas alcanzables. Un sitemap es una pista de descubrimiento, no prueba de que cada página listada sea útil o actual.
Utilice un raspado de una sola página cuando una URL conocida sea toda la entrada. Utilice el rastreo de todo el sitio cuando desee un descubrimiento limitado a partir de una página de inicio. Las solicitudes de Crawl actuales exponen maxDepth, maxPages, includeUrls, excludeUrls, ignoreQuery y onlyMainContent; elija límites conservadores e inspeccione la lista de páginas descubiertas antes de indexar. Para un recorrido separado del lado de la base de datos de vectores, consulte Crawl a Pinecone.
Paso 2: Rastrear una página a Markdown
El SDK de Python documentado expone submit_scrape_task_sync y get_markdown(). Esta solicitud es adecuada para una URL conocida con un tiempo de respuesta predecible:
import os
from nstdata_ai_crawl import Format, NstDataClient, ScrapeRequestDto
with NstDataClient(os.environ["NSTDATA_API_TOKEN"])as client: result = client.submit_scrape_task_sync(ScrapeRequestDto( url="https://docs.example.com/api/authentication", formats=[Format.MARKDOWN], timeout=60_000, onlyMainContent=True,))markdown = result.data.get_markdown()ifnot markdown orlen(markdown.strip())<200:raise ValueError("Crawl returned empty or unexpectedly short content")
Un intercambio HTTP exitoso no es lo mismo que una página utilizable. Verifica el éxito de la tarea, la longitud del cuerpo, los encabezados esperados o una frase conocida, y los metadatos devueltos antes de marcar la página como aceptada. Para páginas más lentas, utiliza el flujo de tarea asíncrono y sondea el ID devuelto; la guía oficial también documenta el progreso de la página y las referencias de resultados. No supongas que existe un callback de webhook: los documentos actuales dicen que no se admiten webhooks.
Para páginas renderizadas con JavaScript, primero inspecciona si el texto requerido falta en la salida normal. Solo habilita el renderizado del navegador o una espera/acción documentada cuando una página realmente lo necesite. Renderizar de forma extra añade latencia y puede hacer que un crawl sea más complejo de diagnosticar.
Paso 3: Normalizar y preservar la procedencia
Antes de fragmentar, convierte el resultado obtenido en un registro estable. Mantén los metadatos de origen separados del texto del cuerpo:
from dataclasses import dataclass
from datetime import datetime, timezone
from hashlib import sha256
@dataclassclassPageRecord: url:str title:str markdown:str crawled_at:str content_hash:strdefmake_record(url:str, title:str, markdown:str)-> PageRecord: normalized ="\n".join(line.rstrip()for line in markdown.splitlines()).strip()return PageRecord( url=url, title=title or url, markdown=normalized, crawled_at=datetime.now(timezone.utc).isoformat(), content_hash=sha256(normalized.encode("utf-8")).hexdigest(),)
Un hash de contenido permite que la tubería omita páginas sin cambios. Normaliza solo el ruido que es verdaderamente irrelevante: preserva encabezados, bloques de código, tablas de parámetros, advertencias y enlaces de origen. Eliminar material estándar no es un permiso para reescribir los hechos del autor.
Paso 4: Fragmentar alrededor de la estructura del documento
Para documentos técnicos, divide en encabezados antes de aplicar un límite de tokens o caracteres. Un fragmento debe llevar su ruta de encabezado para que un párrafo recuperado aún tenga contexto:
defheading_sections(markdown:str): current =[] body =[] in_fence =Falsefor line in markdown.splitlines():if line.strip().startswith("```"): in_fence =not in_fence
if line.startswith("#")andnot in_fence and body:yield" / ".join(current),"\n".join(body).strip() body =[]if line.startswith("#")andnot in_fence: level =len(line)-len(line.lstrip("#")) current = current[:level -1]+[line[level:].strip()] body.append(line)if body:yield" / ".join(current),"\n".join(body).strip()
Este pequeño divisor mantiene juntos los ejemplos con bloques, pero no impone un techo de tokens. Agrega una segunda pasada consciente del tokenizador para secciones largas y pruébalo contra tu muestra de código más larga. Los usuarios de frameworks pueden comparar esa línea base con los actuales conceptos de divisor de texto de LangChain. Evita adivinar un tamaño de fragmento universal: compara la recuperación en preguntas que requieren detalles de parámetros, contexto de sección transversal y código.
Paso 5: Incorporar y almacenar registros
Crea una incrustación por fragmento y escribe el texto y los metadatos con ella. Chroma puede persistir una colección local; sus APIs upsert y query están documentadas en la guía de colección de Chroma. El modelo del proveedor y la dimensión de incrustación de Chroma deben coincidir si pasas vectores precomputados. La actual guía de incrustaciones de OpenAI documenta el punto final de texto a vector utilizado en este ejemplo.
En producción, envíe embeddings en lotes, reintente solo errores transitorios del proveedor y limite el tamaño del lote según los límites del proveedor. Haga que los ID sean deterministas, por ejemplo sha256(canonical_url + heading_path + chunk_text). Cuando una página cambia, elimine los IDs de fragmentos de la página antigua antes de insertar su nuevo conjunto, o use un espacio de nombres versionado y cambie después de la validación.
Paso 6: Recuperar y responder con evidencia
Incorpore la pregunta del usuario con el mismo modelo, consulte la colección y pase los principales pasajes más las URL de origen al LLM. Exija que la respuesta cite las URL proporcionadas y que indique cuándo la evidencia recuperada es insuficiente. La salida de recuperación es evidencia para inspeccionar, no una prueba de que la respuesta sea correcta.
Un conjunto de evaluación útil incluye hechos directos, preguntas de parámetros de API, preguntas cuya respuesta abarca dos secciones y preguntas que deberían devolver "no encontrado". Haga un seguimiento de la tasa de aciertos de recuperación y la corrección de citas por separado de la fluidez de la respuesta.
Paso 7: Mantener el índice fresco
Programe recorridos de nuevo según la volatilidad de la fuente y la consecuencia de respuestas obsoletas. Almacene el último hash exitoso por URL canónica. Si un nuevo recorrido exitoso tiene el mismo hash, omita la re-inserción. Si es diferente, reemplace los fragmentos antiguos. Trate un tiempo de espera o un 403 temporal como desconocido, no como prueba de que la fuente fue eliminada. Confirme una eliminación con verificaciones repetidas o un cambio autoritativo del mapa del sitio antes de eliminar contenido indexado.
Un trabajo cron puede lanzar un comando de ingestión en Python, pero el trabajo debe escribir un registro de ejecución: ID de ejecución, tiempos de inicio/final, URL descubiertas, páginas aceptadas, hashes cambiados, páginas eliminadas, URL fallidas y recuento de incrustaciones. Para obtener una visión general de lo que maneja Crawl frente al trabajo propiedad de la aplicación, consulte la guía de pila de datos web de Nstdata.
Costos, escalabilidad y modos de fallo comunes
Un recuento de páginas no es una estimación de costos completa. Incluya solicitudes de Crawl, tráfico de proxy facturado por separado cuando se use, tokens de incrustación para contenido cambiado, escrituras/almacenamiento de vectores y uso de modelos de tiempo de respuesta. Su propia fórmula debería ser:
costo de ingestión mensual = unidades de recorrido exitosas + tráfico de proxy + tokens de incrustación de texto cambiado + almacenamiento de vectores + programación/operaciones
Mida las páginas aceptadas en lugar de las URL enviadas. Los fallos comunes incluyen indexar páginas vacías, dimensiones de incrustación que no coinciden, dejar vectores obsoletos después de una actualización, perder URLs de origen durante la fragmentación y medir solo la calidad de la respuesta mientras se ignoran las fallas de recuperación. Agregue una puerta de validación antes de indexar y una prueba de fuente adversarial antes de poner los resultados del recorrido a disposición de un modelo.
Lista de verificación de ingestión completa
Mantenga una lista de permitidos y un inventario de URL con URLs canónicas.
Valide el estado, la completitud del cuerpo, el título y los metadatos de la fuente después de cada recorrido.
Preserve encabezados, código, tablas y hashes de contenido a través de la normalización.
Use IDs de fragmentos deterministas y mantenga un mapeo de página a fragmento.
Re-inserte solo contenido cambiado; distinga las páginas eliminadas de las solicitudes fallidas.
Evalúe la recuperación, citas, comportamiento de respuestas obsoletas y costo en un conjunto de preguntas fijo.
Los datos web frescos alcanzan una respuesta RAG solo después de que su canal descubra, recupere, valide, normalice, fragmenta, incruste e indexe. Nstdata Crawl puede proporcionar la recuperación de páginas y la capa de conversión de Markdown; la aplicación aún debe poseer la procedencia, política de actualización, ciclo de vida de vectores y verificaciones de respuesta. Comience con un pequeño conjunto de URLs representativas, demuestre el comportamiento de cobertura y eliminación, y luego escalare el programa.
La ingestión de datos RAG convierte documentos de origen en registros validados, fragmentados e incrustados que un sistema de recuperación puede buscar.
Q: ¿Cómo mantengo los datos web en RAG frescos?
Siga las URLs canónicas y los hashes de contenido, recorra de nuevo en un horario que coincida con la volatilidad de la fuente y reemplace o elimine fragmentos antiguos solo después de validar el nuevo estado de la fuente.
Q: ¿Puede RAG usar sitios web en vivo directamente?
Un índice RAG no se actualiza automáticamente desde un sitio web en vivo; un colector y un trabajo de ingestión deben recuperar e indexar nuevo contenido antes de que la recuperación pueda usarlo.
Q: ¿Con qué frecuencia debo actualizar una base de conocimientos RAG?
Elija un intervalo de actualización según la frecuencia con que cambia la fuente y el impacto de una respuesta obsoleta, luego mida las tasas de cambio reales y los retrasos de actualización.
Q: ¿Crawl reemplaza la fragmentación y las incrustaciones?
No. Crawl recupera y transforma páginas; su aplicación aún elige fragmentos, modelos de incrustación, almacenamiento vectorial, reglas de actualización y evaluación.
Entender las siete dimensiones de la calidad de los datos RAG y cómo validar las páginas rastreadas, comparar entradas limpias y sin procesar, preservar la procedencia y diagnosticar fallos de recuperación. Separa errores de extracción, recuperación y generación para que los equipos puedan depurar la etapa correcta.
Lena Zhou
Oct. 20th 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.