Cuando construyes aplicaciones de Generación Aumentada de Recuperación (RAG), la calidad de las respuestas depende de los datos que ingieres. Amazon Bedrock Knowledge Bases es la capacidad de RAG completamente administrada de Amazon Bedrock. Con Amazon Bedrock Managed Knowledge Base, conectas tus fuentes de datos y Amazon Bedrock administra la ingesta, el almacenamiento, el indexado y la recuperación por ti. No provisionas ni escalas un almacén de vectores, y el incrustado y la reordenación utilizan modelos administrados por el servicio de forma predeterminada.

Para el contenido web, comienza con el conector de fuente de datos Amazon Bedrock Web Crawler para bases de conocimiento administradas. Le proporcionas las URL de semilla o los mapas del sitio que estás autorizado a rastrear, y este lo hace dentro del alcance y los límites de velocidad que estableces. Las sincronizaciones programadas mantienen tu base de conocimiento actualizada a medida que cambian las páginas, y el conector puede esperar a que se cargue el contenido con JavaScript. No hay un rastreador que debas construir, alojar o operar, por lo que este conector es el punto de partida para la mayoría del contenido de sitios web públicos.

Algunas fuentes necesitan un control más sobre lo que llega a la base de conocimiento. Es posible que desees indexar solo la región de contenido principal de cada página, eliminar la navegación y otros elementos de plantilla, o adjuntar tus propios atributos de metadatos a cada documento. Para ese tipo de material de origen, puedes ampliar el alcance de tu base de conocimiento con un paso de preparación construido con Crawl4AI, un rastreador de Python de código abierto. El paso escribe Markdown y un archivo de metadatos auxiliar para cada página en Amazon Simple Storage Service (Amazon S3), y la base de conocimiento ingiere ambos a través de su fuente de datos de Amazon S3.

En esta publicación, te mostramos cómo elegir la ruta de ingesta web adecuada e implementar una preparación personalizada para el contenido que necesita un procesamiento adicional. Luego, comienzas la ingesta en una base de conocimiento administrada y validas la calidad de recuperación. El repositorio aws-samples proporciona el flujo de trabajo completo como una implementación de ejemplo.

Esta es una ingesta por lotes de propiedades web conocidas, no un acceso web en tiempo real en el momento de la inferencia, como Web Grounding con Amazon Nova.

Visión general de la solución

Comience con el Amazon Bedrock Web Crawler cuando pueda alcanzar e indexar las páginas que necesita. Respeta robots.txt, y después del primer crawl completo, cada sincronización captura solo el contenido agregado, actualizado y eliminado.

Utilice el camino de preparación de Crawl4AI cuando el material de fuente pública necesita uno o más de los siguientes antes de la ingesta:

• Preparación de Markdown estructurado: Utilice DefaultMarkdownGenerator con un filtro de contenido de poda para reducir la navegación y otros elementos de boilerplate mientras se conservan los encabezados, listas y tablas. Debido a que la poda es heurística, revise la salida representativa de sus sitios.
• Extracción dirigida y acotada: Extraiga solo la región de la página que coincide con un selector CSS opcional. Restrinja el recorrido de amplitud primero por origen de semilla, ámbito de página/ruta/host, profundidad y límites de página, y patrones de URL.
• Metadatos personalizados: Adjunte URLs de origen, marcas de tiempo de crawl, tipo de contenido y sus propios atributos a cada documento, para que pueda filtrar los resultados de recuperación en ellos.

Debido a que las bases de conocimiento administradas y administradas por el cliente admiten fuentes de datos de Amazon S3, el camino de Crawl4AI funciona con cualquiera de los dos tipos. Esta publicación utiliza una base de conocimiento administrada y señala las diferencias donde una base de conocimiento administrada por el cliente difiere.

El resto de esta publicación sigue la muestra companion. Trate su arquitectura y valores predeterminados como un punto de partida, no como requisitos de Amazon Bedrock Knowledge Bases.

De forma predeterminada, la muestra ejecuta la tarea de AWS Fargate en una subred pública, donde alcanza sus sitios web configurados a través de una puerta de enlace de internet. El rol de Crawl4AI termina una vez que ha preparado los documentos de origen y los metadatos sidecars. A partir de la ingesta, Amazon Bedrock Knowledge Bases maneja el análisis, la división en partes, la incrustación, la indexación y la recuperación. El siguiente diagrama muestra el camino de Crawl4AI desde la programación hasta la recuperación.

Figura 1: El camino de ingesta de Crawl4AI a Amazon S3 para Amazon Bedrock Knowledge Bases

Los pasos numerados en el diagrama se corresponden con el siguiente flujo de trabajo:

1. Amazon EventBridge inicia la tarea de Amazon Elastic Container Service (Amazon ECS) en AWS Fargate según el horario configurado.
2. La tarea rastrea los sitios web públicos que configuró y prepara Markdown con un sidecar de metadatos para cada página.
3. La tarea carga los archivos preparados en el bucket de Amazon S3 que respalda la fuente de datos de la base de conocimientos.
4. La tarea inicia un trabajo de ingesta de bases de conocimientos de Amazon Bedrock.
5. Amazon Bedrock Knowledge Bases lee los objetos nuevos y modificados, los analiza y aplica la estrategia de chunking que seleccionó.
6. Crea incrustaciones y las indexa en el almacén de vectores de la base de conocimientos, que Amazon Bedrock administra para una base de conocimientos administrada.
7. Su aplicación de inteligencia artificial generativa consulta la base de conocimientos para obtener fragmentos relevantes o para obtener una respuesta generada con citas.

La tarea lee su configuración de canal no secreta desde AWS Systems Manager Parameter Store al inicio.

El flujo de trabajo procesa solo páginas públicas y no implementa sesiones autenticadas. Para sitios que requieren inicio de sesión, evalúe primero las opciones de autenticación del rastreador web de Amazon Bedrock, que incluyen autenticación básica, basada en formularios y SAML. Ampliar la muestra con autenticación requiere control de sesiones, credenciales en AWS Secrets Manager y una revisión de seguridad.

Cómo funciona el flujo de trabajo

La aplicación de AWS Cloud Development Kit (AWS CDK) empaqueta la implementación en una imagen de contenedor durante la implementación. Cuando se dispara el horario, el contenedor ejecuta scripts/container_entrypoint.py y ejecuta el rastreo, la carga y la ingesta en secuencia. Los siguientes tres pasos explican la lógica principal.

Paso 1: Rastrear y extraer contenido

El paso de rastreo realiza un rastreo limitado y escribe un archivo Markdown con un sidecar de metadatos para cada página preparada con éxito. El siguiente extracto es simplificado. El módulo src/crawl4ai_bedrock_kb/crawl.py contiene el ritmo de semilla completo, el filtrado y el alcance de URL, los límites de página y las comprobaciones de redireccionamiento:

async def crawl_and_prepare(config: PipelineConfig, output_dir: str) -> list[str]:
    written, seen = [], set()
    pages_crawled = 0
    browser_config = BrowserConfig(headless=True, java_script_enabled=True)

    async with AsyncWebCrawler(config=browser_config) as crawler:
        for seed in config.seed_urls:
            remaining = config.crawl.max_pages - pages_crawled
            if remaining <= 0:
                break

            strategy = BFSDeepCrawlStrategy(
                max_depth=config.crawl.max_depth,
                max_pages=remaining,
                filter_chain=FilterChain([
                    SeedScopeFilter(seed, config.crawl.scope),
                    # Optional include/exclude URLPatternFilter objects are added here.
                ]),
            )
            run_config = CrawlerRunConfig(
                deep_crawl_strategy=strategy,
                markdown_generator=DefaultMarkdownGenerator(
                    content_filter=PruningContentFilter()
                ),
                css_selector=config.crawl.css_selector,  # Optional page region.
                check_robots_txt=config.crawl.check_robots_txt,
                mean_delay=config.crawl.request_delay_seconds,
                max_range=0,
                semaphore_count=1,
            )

            results = await crawler.arun(url=seed, config=run_config)
            for result in results:
                if pages_crawled >= config.crawl.max_pages:
                    break
                pages_crawled += 1
                requested_url = result.url
                source_url = getattr(result, "redirected_url", None) or requested_url
                if not SeedScopeFilter(seed, config.crawl.scope).apply(source_url):
                    continue  # Recheck the effective destination after redirects.
                canonical = _canonical_url(source_url)
                if canonical in seen:
                    continue
                seen.add(canonical)
                if not result.success or not result.markdown:
                    continue

                md_result = result.markdown
                markdown = (
                    getattr(md_result, "fit_markdown", None)
                    or getattr(md_result, "raw_markdown", None)
                    or (md_result if isinstance(md_result, str) else "")
                )
                if not markdown:
                    continue

                # The complete implementation adds title, crawl timestamps, content
                # type, and configured custom attributes to this metadata.
                written.extend(
                    _write_document(
                        output_dir,
                        _base_name(source_url),
                        markdown,
                        {"source_url": source_url},
                    )
                )
    return written

Amazon Bedrock Knowledge Bases admite varios formatos de documento para fuentes de datos de Amazon S3, incluyendo texto plano, HTML, Markdown, PDF y DOCX. El flujo de trabajo escribe Markdown porque conserva encabezados, listas y tablas sin llevar todo el HTML crudo a la ingesta.

Paso 2: Cargar en Amazon S3

El paso de carga envía cada documento de Markdown preparado y su metadato de sidecar coincidente al bucket de S3 configurado, bajo el flujo de trabajo de s3Prefix. Para page.md, el sidecar debe llamarse page.md.metadata.json, el nombre de archivo de origen completo con .metadata.json agregado. El flujo de trabajo almacena cada sidecar en la misma ubicación de S3 que su documento. Amazon Bedrock limita cada metadato de sidecar a 10 KB. Si un sidecar excedería ese límite, la ejecución se detiene con un error antes de escribir cualquiera de los archivos.

Cada atributo en el sidecar utiliza el formato tipado que aceptan tanto las bases de conocimiento administradas como las administradas por el cliente para las fuentes de datos de Amazon S3. El sidecar abreviado siguiente, formateado para una mejor legibilidad, muestra tres de los atributos que escribe el flujo de trabajo:

{
  "metadataAttributes": {
    "source_url": {
      "value": {"type": "STRING", "stringValue": "https://www.example.com/services/permits"}
    },
    "crawled_at_epoch": {
      "value": {"type": "NUMBER", "numberValue": 1790640000}
    },
    "content_category": {
      "value": {"type": "STRING", "stringValue": "web"}
    }
  }
}

La canalización carga solo las rutas producidas por la búsqueda actual, por lo que no se envían archivos locales obsoletos.

Paso 3: Deje que las bases de conocimiento de Amazon Bedrock dividan, incrusten y indexen

Después de que el contenido esté en S3, un trabajo de ingesta entrega cada documento a la canalización de ingesta de la fuente de datos. De forma predeterminada, una base de conocimiento administrada analiza cada archivo con su analizador administrado, que selecciona automáticamente un enfoque de análisis para su contenido. Seleccione la estrategia de división al conectar la fuente de datos. No podrá cambiarla después, así que evalúe las opciones antes de crear una fuente de datos de producción. Una base de conocimiento administrada ofrece las siguientes estrategias de división:

• División predeterminada utiliza fragmentos de tamaño fijo de 300 tokens con un 20 por ciento de superposición.
• División de tamaño fijo divide el contenido por una cuenta de tokens máxima y un porcentaje de superposición que establezca.
• Sin división trata cada archivo como un fragmento único, para contenido que ya ha dividido.

Los límites de los fragmentos y los resultados de recuperación dependen del contenido y la estrategia seleccionada, así que compare las opciones con páginas representativas y preguntas de evaluación. Para cambiar estrategias más tarde, cree una nueva fuente de datos. Para obtener más información, consulte Personalizar la ingesta para una fuente de datos. Una base de conocimiento administrada por el cliente también ofrece división semántica y jerárquica, y opciones de análisis adicionales. Para obtener detalles, consulte Cómo funciona la división de contenido para las bases de conocimiento.

El flujo de trabajo luego inicia un trabajo de ingesta para que la base de conocimiento procese los nuevos documentos. El siguiente extracto simplificado de src/crawl4ai_bedrock_kb/ingest.py muestra la llamada:

def start_ingestion_job(config: PipelineConfig) -> str:
    # Start an Amazon Bedrock knowledge base ingestion job and return its ID.
    client = boto3.client("bedrock-agent", region_name=config.region)
    response = client.start_ingestion_job(
        knowledgeBaseId=config.knowledge_base_id,
        dataSourceId=config.data_source_id,
    )
    return response["ingestionJob"]["ingestionJobId"]

Las mismas llamadas a StartIngestionJob y GetIngestionJob funcionan para ambos tipos de base de conocimiento, y también puedes monitorear el progreso en la consola.

Implementar la solución

En esta sección, implementas el flujo de trabajo en tu cuenta de AWS con AWS CDK. Solo las condiciones previas de la base de conocimiento difieren entre los dos tipos de base de conocimiento. Cuando hayas terminado, sigue los pasos en la sección Limpieza para eliminar los recursos.

Requisitos previos

Antes de empezar, asegúrate de que tienes:

• Una cuenta de AWS.
• Una de las siguientes bases de conocimiento:
  • Una base de conocimiento administrada, que se utiliza en este artículo, en una región de AWS donde están disponibles las bases de conocimiento administradas. Para obtener instrucciones, consulta Crear una base de conocimiento administrada y el conector de Amazon S3. En el origen de datos, deja Prefijo de archivos de metadatos vacío, porque el flujo de trabajo escribe cada archivo de metadatos auxiliar junto con su documento.
  • Una base de conocimiento administrada por el cliente existente. Para agregar un origen de datos de Amazon S3, consulta Conectar a Amazon S3 para tu base de conocimiento. El flujo de trabajo escribe un archivo de metadatos auxiliar para cada documento, así que confirma que tu tienda de vectores puede almacenar y filtrar esos atributos, como se describe en Metadatos y filtrado. Por ejemplo, un índice de vector de Amazon OpenSearch Serverless debe utilizar el motor faiss. Un índice de vector de Amazon Aurora necesita una columna de metadatos personalizada o una columna para cada atributo de metadatos. Con Amazon S3 Vectors, una capacidad de Amazon S3, puedes adjuntar hasta 1 KB de metadatos personalizados a cada vector, así que mantén los atributos que agregues cortos.
• Una fuente de datos de Amazon S3 en esa base de conocimientos cuyo estado es AVAILABLE. Puede ser una nueva fuente de datos o una que ya utilice. Debe utilizar el bucket de S3 que configure para este flujo de trabajo. Si la fuente de datos filtra contenido por prefijo o patrón de archivo, los filtros deben permitir los archivos que el flujo de trabajo escribe bajo su s3Prefix (predeterminado web-content/).
• La base de conocimientos, el bucket de S3 y la pila que implementa todo en una región.
• Autorización para rastrear los sitios web públicos que configure.
• Una estación de trabajo de implementación con Git, Python 3.10 o posterior, Node.js, la interfaz de línea de comandos de AWS (AWS CLI) versión 2, la CLI de AWS CDK v2 y un motor de contenedor compatible con Docker en ejecución. La guía de implementación enumera la versión mínima de la CLI de AWS CDK.
• Credenciales de AWS configuradas en la estación de trabajo de implementación con permiso para inicializar el entorno de destino y implementar la pila de CDK.
• Un entorno de CDK inicializado en la cuenta y región de destino. Los pasos de implementación incluyen el comando de inicialización.

Solo necesita la estación de trabajo para compilar e implementar. Después de la implementación, el programa ejecuta la tarea en AWS.

Implementar el flujo de trabajo programado

Clonar el repositorio companion e instalar las dependencias de implementación:

git clone https://github.com/aws-samples/sample-crawl4ai-bedrock-knowledge-base.git
cd sample-crawl4ai-bedrock-knowledge-base/deploy
python -m venv .venv
source .venv/bin/activate  # Windows PowerShell: .venv\Scripts\Activate.ps1
python -m pip install -r requirements.txt

Mantener Docker en ejecución. Establecer AWS_DEFAULT_REGION en la región de su base de conocimientos primero, porque cdk deploy utiliza la región de su entorno o perfil de AWS, no la que está en el comando de inicialización. Inicializar la cuenta y región de destino una vez, si es necesario. Luego, implementar la pila con su base de conocimientos, fuente de datos, bucket de S3 y URLs de semilla autorizadas:

export AWS_DEFAULT_REGION=REGION  # Windows PowerShell: $env:AWS_DEFAULT_REGION = "REGION"
cdk bootstrap aws://ACCOUNT_ID/REGION

cdk deploy \
  -c knowledgeBaseId=ABCDEFGHIJ \
  -c dataSourceId=KLMNOPQRST \
  -c s3Bucket=amzn-s3-demo-bucket \
  -c 'seedUrls=["https://www.example.com/services"]' \
  -c maxDepth=1 \
  -c maxPages=25

Reemplazar cada valor de ejemplo, incluyendo ACCOUNT_ID, REGION y las cuatro claves de contexto requeridas, con los suyos propios. Los valores de ejemplo son sintácticamente válidos, por lo que un comando no editado implementa una pila que apunta a un bucket que no posee. También puede establecer estas claves en cdk.json.

Los valores de maxDepth y maxPages limitan la primera búsqueda a un nivel de enlace y 25 páginas. Aumentarlos después de revisar la salida preparada. Para previsualizar qué páginas prepara una búsqueda, también puede ejecutar la canalización localmente con --dry-run, como se describe en el README. El nombre de la pila es fijo, por lo que otro cdk deploy en la misma cuenta y región actualiza esta pila.

La muestra crea una imagen de contenedor ARM64 de forma predeterminada. Si Docker en su estación de trabajo x86_64 no puede crear imágenes ARM64, agregue -c cpuArchitecture=X86_64 al comando cdk deploy.

Si su cuenta activa VPC Block Public Access, la tarea no puede llegar a Internet desde la subred pública predeterminada. Para comprobar el modo, ejecute aws ec2 describe-vpc-block-public-access-options. En modo de solo ingreso, implemente con -c egressMode=nat, que agrega una puerta de enlace NAT con cargos por hora. El modo bidireccional también necesita una exclusión, como describe la guía de implementación.

La pila no crea ni modifica su base de conocimientos o fuente de datos.

Con el programa rate(24 hours) predeterminado, la primera ejecución comienza cuando la implementación crea la regla de Amazon EventBridge. Para seguir esa ejecución, use el comando en la salida TailLogsCommand, que cdk deploy imprime cuando finaliza. Una ejecución exitosa registra job_status: COMPLETE. Para iniciar otra ejecución fuera del programa, use el comando en la salida RunTaskCommand después de que finalice la ejecución actual. Para enumerar las salidas más adelante, ejecute aws cloudformation describe-stacks --stack-name Crawl4aiBedrockKbCrawler --region REGION --query "Stacks[0].Outputs".

La guía de implementación cubre la configuración restante, incluidos los límites de crawl, el programa, la red, la arquitectura de contenedores, el monitoreo y las ejecuciones bajo demanda.

Validar la calidad de recuperación

Después de la ingesta, pruebe preguntas representativas con Retrieve antes de agregar generación. Una base de conocimientos administrada utiliza búsqueda híbrida. Cuando utiliza el modelo de incrustación administrado predeterminado, también vuelve a clasificar los resultados con su clasificador administrado. Puede reducir los resultados con los metadatos de los sidecars. La configuración predeterminada de la muestra agrega content_category establecido en web a cada página. El siguiente ejemplo devuelve hasta cinco fragmentos de esas páginas que se crawlearon en los últimos siete días. Requiere el SDK de AWS para Python (Boto3) 1.43.32 o posterior, que puede instalar con python -m pip install "boto3>=1.43.32". Reemplace la región y el ID de la base de conocimientos con sus propios valores:

import time

import boto3

client = boto3.client("bedrock-agent-runtime", region_name="us-east-1")
week_ago = int(time.time()) - 7 * 24 * 60 * 60

response = client.retrieve(
    knowledgeBaseId="ABCDEFGHIJ",
    retrievalQuery={"text": "How do I apply for a building permit?"},
    retrievalConfiguration={
        "managedSearchConfiguration": {
            "numberOfResults": 5,
            "filter": {
                "andAll": [
                    {"equals": {"key": "content_category", "value": "web"}},
                    {"greaterThan": {"key": "crawled_at_epoch", "value": week_ago}},
                ]
            },
        }
    },
)

for result in response["retrievalResults"]:
    print(result.get("metadata", {}).get("source_url"), result["content"]["text"][:200])

El ejemplo pasa un timestamp entero, que ambos tipos de base de conocimientos aceptan en filtros numéricos. Una base de conocimientos administrada no admite los filtros startsWith y stringContains. Para una base de conocimientos administrada por el cliente, pase el mismo filtro en vectorSearchConfiguration en lugar de managedSearchConfiguration. Los operadores que admite dependen de su tienda de vectores.

El filtrado de metadatos puede mejorar la precisión de recuperación, pero no es un límite de autorización. Si diferentes usuarios deben ver diferentes páginas, el conector de Amazon S3 para bases de conocimiento administradas admite control de acceso a nivel de documento con archivos de lista de control de acceso (ACL) que usted proporciona. La muestra no crea archivos ACL.

Para generar respuestas desde una base de conocimiento administrada, use recuperación agente. La operación AgenticRetrieveStream devuelve los resultados recuperados y una respuesta generada con citas a esos resultados. Para una base de conocimiento administrada por el cliente, use RetrieveAndGenerate. En ambos casos, cada resultado citado incluye los metadatos source_url de su sidecar, que su aplicación puede presentar como la fuente que enfrenta al usuario.

Evalúe la relevancia de recuperación, la cobertura de la página de origen y la calidad de la cita cada vez que cambie la preparación de contenido, la división en partes o la configuración de recuperación. Para los ajustes de recuperación que puede personalizar, consulte Configurar y personalizar consultas para bases de conocimiento administradas.

Ejecutarlo repetidamente

Cada evento programado lanza una tarea independiente de Fargate. La pila no evita ejecuciones superpuestas, así que elija un intervalo más largo que la duración de crawl y ingestion esperada. Una ejecución fallida no se anuncia, porque la muestra no agrega una política de reintento, cola de carta muerta o alarma. Un trabajo de ingestion también puede informar COMPLETE cuando algunos documentos no se ingieren, y la tarea sale con código 0. La tarea registra las razones de falla del trabajo. Agregue el monitoreo que necesite, incluida una alarma sobre esas razones de falla, antes de confiar en el programa.

Cada ejecución incurre en cargos de Fargate por el tamaño de tarea configurado, que predeterminadamente es de 2 vCPU y 4 GB. La tarea sigue ejecutándose mientras sondea el trabajo de ingesta durante un máximo de 30 minutos, por lo que un trabajo de ingesta lento extiende el tiempo de tarea facturable. Si la ingesta tarda más, la tarea sale con un código distinto de cero y el trabajo de ingesta sigue ejecutándose. La pila activa Container Insights para el cluster, y registros de flujo para una Amazon Virtual Private Cloud (Amazon VPC) que crea. Ambos agregan cargos de Amazon CloudWatch. La clave AWS KMS de la pila tiene un cargo mensual, y la dirección IPv4 pública de la tarea es facturada mientras la tarea se ejecuta. Con egressMode=nat o privateEndpoints=true, la puerta de enlace NAT y los puntos de conexión de interfaz son facturados por hora, incluso cuando no se ejecuta ninguna tarea. El uso de la base de conocimientos es facturado por separado. Para obtener más detalles, consulte precios de Amazon VPC y precios de Amazon Bedrock.

Las cargas son aditivas: eliminar una URL o perder una página durante una crawl posterior no elimina sus objetos S3 existentes. Para eliminar contenido obsoleto, elimine el documento obsoleto y el sidecar coincidente bajo el prefijo configurado, y luego vuelva a iniciar la ingesta. Si activa la salvaguarda de eliminación de documentos (protección contra eliminación) para una fuente de datos de base de conocimientos administrada, verifique su umbral. Una sincronización que eliminaría más del porcentaje de documentos especificado omite su fase de eliminación, por lo que esos documentos siguen indexados. Para iniciar la ingesta automáticamente cada vez que cambian objetos en el bucket, consulte Construya y despliegue una solución de sincronización automática para bases de conocimientos de Amazon Bedrock.

Consideraciones de IA responsable

Los pasajes recuperados se convierten en el contexto que un modelo base utiliza para generar una respuesta. Aplique los siguientes controles antes de ejecutar este flujo de trabajo en producción:

• Amazon Bedrock Guardrails: Adjunte un guardrail a su recuperación agente o solicitudes de RetrieveAndGenerate para aplicar filtros de contenido, temas denegados, filtros de palabras y filtros de información sensible. La recuperación agente solo admite la acción de guardrail BLOCK, no MASK.
• Verificaciones de anclaje contextual: Active la verificación de anclaje contextual de Guardrails contextual grounding check para puntuar cada respuesta por su anclaje con respecto a los pasajes recuperados y por su relevancia para la consulta. El guardrail bloquea las respuestas que obtienen una puntuación inferior a los umbrales que establezca. Para la recuperación agente, puede ejecutar la verificación en la respuesta generada con la API ApplyGuardrail. La verificación admite casos de uso de respuesta a preguntas y resumen, pero no casos de uso de chatbot conversacional.
• Trate el contenido rastreado como entrada no confiable: Las páginas web preparadas se convierten en contexto del modelo, por lo que el texto de una página pública puede intentar inyectar una solicitud a través de la recuperación. No confíe solo en los guardrails para detectarlo. Restrinja las URL de semilla a sitios que confíe y aplique los patrones de filtrado de ingesta descritos en la siguiente sección antes de que el contenido llegue a la base de conocimientos.
• Citas y revisión humana: Devuelva citas con cada respuesta generada para que los usuarios puedan verificar las afirmaciones con respecto a la página de origen. Para casos de uso de mayor riesgo, mantenga a un revisor humano en el ciclo.

Consideraciones de seguridad y cumplimiento

Revise las siguientes consideraciones antes de ejecutar este flujo de trabajo con contenido de producción:

• Utilice objetivos de rastreo público confiables: Las URL de semilla y la configuración de rastreo son configuración de implementación, y la tarea de Fargate permite el acceso saliente para que pueda llegar a sitios web públicos. En el modo de red predeterminado de la muestra, la tarea se ejecuta en una subred pública con una IP pública. Configure solo sitios públicos autorizados. No utilice esta muestra para rastrear puntos de conexión privados o internos. Revise los controles de salida y destino de red antes de adaptar el flujo de trabajo para otros modelos de confianza.
• Respete las directivas de rastreo: El flujo de trabajo activa la verificación robots.txt de Crawl4AI de forma predeterminada, y la ruta de CDK la fija con una clave de contexto para deshabilitarla. Verifique que tenga autorización para rastrear los sitios de destino, de acuerdo con la Política de uso aceptable de AWS.
• Límite de velocidad: Configure retrasos entre solicitudes para evitar abrumar los sitios web de origen.

Limpieza

Para evitar cargos continuos, elimine los recursos creados durante este recorrido:

• Desde el directorio deploy/ del repositorio, ejecute cdk destroy en la misma región, con los mismos cuatro valores requeridos -c que pasó a cdk deploy. La aplicación verifica estos valores en cada comando. Esto elimina la regla de Amazon EventBridge de la pila, el clúster de ECS, la definición de tarea, los grupos de registros, los roles de IAM, el parámetro de Parameter Store y los grupos de seguridad, y la VPC si la pila la creó. También programa la clave de AWS KMS de la pila para su eliminación después de un período de espera de 30 días. No elimina una VPC importada, su base de conocimientos, su bucket de S3 o los objetos que la workflow subió. CDK también mantiene la imagen del contenedor y las plantillas en sus recursos de inicialización. También deja el grupo de registros de Container Insights del clúster, cuyo nombre comienza con /aws/ecs/containerinsights/Crawl4aiBedrockKbCrawler-.
• Para eliminar el contenido web ingerido, elimine los objetos preparados bajo s3://<bucket>/<prefix> y sincronice la fuente de datos nuevamente. Si la salvaguarda de eliminación de documentos está activada para una fuente de datos de base de conocimientos administrada, una sincronización que eliminaría más del porcentaje umbral de documentos omite su fase de eliminación.
• Elimine la base de conocimientos administrada solo si la creó exclusivamente para este recorrido. Una base de conocimientos administrada no tiene una tienda de vectores separada para eliminar.
• Para una base de conocimientos administrada por el cliente, elimine la fuente de datos de Amazon S3 solo si la creó para este recorrido. Su política de eliminación de datos determina si Amazon Bedrock también elimina las incrustaciones de vectores de la fuente de datos de su tienda de vectores.

Conclusión

En esta publicación, aprendió cómo extender las bases de conocimientos de Amazon Bedrock a contenido web público autorizado que necesita preparación antes de la ingesta. Una tarea programada de Fargate utiliza Crawl4AI para crawling limitado, prepara Markdown con page.md.metadata.json de sidecars, los sube a una fuente de datos de Amazon S3 y comienza la ingesta. La base de conocimientos luego maneja el análisis, la división en fragmentos, las incrustaciones, el índice, la recuperación y las respuestas fundamentadas con citas.

Comience con el Amazon Bedrock Web Crawler en una base de conocimientos administrada para la mayoría de los sitios web públicos. Utilice el camino de Crawl4AI cuando necesite control sobre qué parte de cada página se indexa o qué metadatos viaja con ella. Para empezar, implemente el flujo de trabajo programado de Fargate desde el repositorio de sample-crawl4ai-bedrock-knowledge-base de acompañamiento, y luego valide la calidad de recuperación y las citas con contenido representativo antes de escalar.

Aprenda más

Para obtener más información sobre los servicios y patrones en esta publicación, consulte los siguientes recursos:

• Crear una base de conocimiento administrada
• Amazon Bedrock Web Crawler para bases de conocimiento administradas
• Conector de Amazon S3 para bases de conocimiento administradas
• Usar recuperación agente para consultar una base de conocimiento
• Crawl4AI en GitHub
• Ejemplos de bases de conocimiento en aws-samples/amazon-bedrock-samples

Reconocimientos

Este producto incluye software desarrollado por UncleCode como parte del proyecto Crawl4AI.

Acerca de los autores