Cómo la Red de Bright Data Impulsa la Recopilación de Datos Web Públicos y Protege la Web

Amazon Bedrock Knowledge Bases es un servicio administrado para Generación Aumentada por Recuperación (RAG). Apúntalo a una fuente de datos y fragmenta, incrusta e indexa tus documentos, luego responde consultas con citas. Sus conectores incluyen Amazon S3, SharePoint y un Web Crawler nativo para páginas públicas.

Ese crawler cubre la web cooperativa. Muchos catálogos de productos, marketplaces y sitios de noticias se renderizan con JavaScript, están detrás de protección contra bots o sirven contenido diferente según el país. El crawler devuelve una carcasa, un bloqueo o el contenido del país equivocado. Esta guía alimenta esas páginas en una base de conocimiento a través de Bright Data y S3.

• Web Unlocker devuelve una página pública como Markdown en una solicitud, a menos que la página necesite interacción. Escribe cada página en S3 como .md más un sidecar .metadata.json.
• Hashea el contenido antes de escribir, para que una actualización re-incruste las páginas que reescribiste en lugar de todo el corpus.
• Mide la recuperación contra un conjunto dorado antes de escalar, porque tu fragmentación se establece en la fuente de datos y las claves de metadatos no filtrables se establecen en un índice S3 Vectors. No puedes cambiar ninguno de los dos después.
• Enruta por consulta. Recurre a una búsqueda en vivo cuando la puntuación máxima esté por debajo de un umbral de relevancia.

Por qué el Web Crawler nativo deja una brecha

La fuente de datos Web Crawler es un conector de primera parte, y para tus propias páginas estáticas es una buena opción. Hoy sus limitaciones dejan los datos web públicos a escala a Bright Data.

• Soporta sitios web estáticos. La documentación lo dice directamente, y el crawler no recupera páginas que se renderizan del lado del cliente. Muchos catálogos, paneles y páginas de listados se renderizan así, por lo que el crawler ve una carcasa vacía donde deberían estar los datos.
• Está construido para la web cooperativa. El crawler respeta robots.txt según la RFC 9309, y trata el sitio como no permitido cuando no encuentra ninguno. Se identifica como bedrockbot, y se detiene ante la protección contra bots por diseño.
• Tiene un límite de 25,000 páginas por sincronización y soporta un único almacén de vectores. Si superas ese límite, la sincronización falla y no ingiere nada. Ese almacén es actualmente Amazon OpenSearch Serverless, por lo que S3 Vectors no es una opción con el crawler.
• Devuelve páginas, no registros limpios. El crawler ingiere HTML. La navegación, los banners de cookies y el contenido estándar llegan junto con el contenido, y no hay un paso de extracción estructurada. Tus fragmentos llevan el ruido a los embeddings.

La consola etiqueta el Web Crawler como Vista previa en la pantalla donde lo eliges:

Nada de esto hace que el crawler sea la elección incorrecta para las páginas estáticas y cooperativas para las que fue construido. En el informe Datos para IA 2026 de Bright Data, el 90% de las organizaciones de IA dijeron que las restricciones de acceso están limitando sus iniciativas. Cloudflare reclasificó los crawlers de IA en julio de 2026. Dijo que bloquearía los crawlers de uso mixto por defecto a partir del 15 de septiembre de 2026, en páginas con publicidad para nuevos clientes, nuevos sitios y cuentas gratuitas sin cambios. Mantener el acceso funcionando requiere un esfuerzo continuo, y Bright Data lo hace por ti.

La arquitectura

El pipeline convierte una lista de URLs públicas en una base de conocimiento buscable y citada, y la mantiene actualizada. Bright Data gestiona el acceso y la conversión a Markdown. S3 es el punto de transferencia. Bedrock gestiona la indexación y la recuperación.

El diagrama muestra la ruta principal:

1. El loader llama al Web Unlocker de Bright Data para la protección contra bots, el enrutamiento geográfico y el renderizado de JavaScript, y recibe la página como Markdown.
2. El loader luego escribe cada página en Amazon S3 como un documento <slug>.md más un sidecar <slug>.md.metadata.json.
3. La base de conocimiento sincroniza la fuente de datos S3 con StartIngestionJob, y las ejecuciones posteriores son incrementales.
4. Bedrock fragmenta cada documento, lo incrusta con Titan Text Embeddings V2 y escribe los vectores en un almacén como Amazon S3 Vectors u OpenSearch Serverless.
5. Una aplicación llama a Retrieve para fragmentos sin procesar o a RetrieveAndGenerate para una respuesta fundamentada y citada.

Tres partes del wrapper de producción están fuera de esa ruta principal y el diagrama no las muestra. Un schedule de Amazon EventBridge activa el loader con la frecuencia que elijas, AWS Secrets Manager guarda el token de Bright Data, y la base de conocimiento asume un rol IAM de privilegio mínimo. El diagrama dibuja el loader como un Lambda, que es donde se ejecuta una vez que lo programas. A continuación, ejecutas el loader desde tu propia máquina para poder observar cada etapa primero.

Escribir en S3 es una elección más que una opción predeterminada, porque también puedes enviar documentos directamente a través de una fuente de datos personalizada y la API IngestKnowledgeBaseDocuments. El bucket es la mejor opción para un corpus scrapeado. Los objetos permanecen reproducibles, los sidecars te permiten inspeccionar el contrato de metadatos, y una ejecución fallida deja el corpus anterior intacto. La API Crawl de Bright Data también entrega en el mismo bucket de forma nativa.

Requisitos previos

• Una cuenta de AWS con acceso a Amazon Bedrock en una Región compatible, y Amazon Titan Text Embeddings V2 (amazon.titan-embed-text-v2:0) habilitado allí. Más un modelo de generación en la misma Región, si quieres respuestas escritas del Paso 5 en lugar de fragmentos sin procesar.
• Un principal de IAM que pueda crear buckets S3, bases de conocimiento y fuentes de datos de Bedrock, un almacén de vectores y el rol de servicio IAM que asume la base de conocimiento. El repositorio complementario lista las declaraciones de política exactas.
• Una cuenta de Bright Data con un token de API y una zona de Web Unlocker. Cada solicitud referencia la zona por nombre. Un nivel gratuito cubre los primeros 5,000 créditos cada mes, lo cual es suficiente para completar todos los pasos a continuación. Consulta el límite y la tarifa actuales en los precios de Web Unlocker, luego establece un límite de gasto en la zona.
• Python 3.10 o posterior con boto3 y requests.
• Conocimiento práctico de Amazon S3 e IAM.

El modelo de embedding establece tu dimensión vectorial, y el índice de tu almacén de vectores debe coincidir con él. Si creas el almacén manualmente y los dos no coinciden, la ingestión falla al momento de escribir. Titan Text Embeddings V2 soporta 256, 512 o 1024 dimensiones.

Verifica tu cuota de embedding antes de construir cualquier cosa, porque puede ser cero y nada en el flujo de creación te advierte. Una cuenta nueva puede tener una cuota bajo demanda de 0 solicitudes por minuto para el modelo de embedding. Esa cuota te permite crear la base de conocimiento y la fuente de datos normalmente, luego falla en cada trabajo de ingestión. Confírmalo en una llamada y solicita un aumento en Service Quotas si muestra cero:

aws service-quotas list-service-quotas --service-code bedrock --region YOUR_REGION \
  --query "Quotas[?contains(QuotaName,'Titan Text Embeddings V2')].[QuotaName,Value]" --output text

Ejecútalo contra la Región que realmente pretendes usar, porque AWS establece la cuota por Región, y la diferencia puede ser todo o nada. En una cuenta, el mismo día, Titan Text Embeddings V2 tenía una cuota bajo demanda aplicada de 0 solicitudes por minuto y 0 tokens por minuto en US East (N. Virginia):

En US East (Ohio) el mismo modelo tenía 60 solicitudes por minuto y 300,000 tokens por minuto:

Compara el valor aplicado con el predeterminado de AWS en la consola de Service Quotas. Una cuota de 60 frente a un predeterminado de 6,000 significa que la Región que funciona sigue ejecutándose a una centésima de la tasa de solicitudes estándar. La cuota de tokens junto a ella está en el valor predeterminado completo, por lo que las solicitudes por minuto es el límite que importa. Con aproximadamente 300 tokens por fragmento, 60 solicitudes por minuto equivalen a unos 18,000 tokens por minuto frente a un techo de 300,000. Eso es suficiente para un corpus pequeño. Es un cuello de botella para uno grande.

Dos mensajes de error en este pipeline nombran la causa incorrecta.

• AccessDeniedException en CreateKnowledgeBase, nombrando tu usuario y la acción. Esto generalmente significa un roleArn malformado en lugar de un problema de permisos, así que verifica la cadena ARN antes de auditar IAM.
• not able to call specified bedrock embedding model durante la ingestión. Esto parece un error de permisos, y una cuota de embedding en cero también lo produce. Invoca el modelo de embedding directamente como tú mismo, y si eso también genera throttling, tienes un problema de cuota.