用 Crawl4AI 改善 Bedrock 知识库入库质量

给网页知识库换一个更强的模型，未必能解决回答不准的问题。如果送进去的是导航菜单、重复页脚和过期页面，检索环节就已经偏了。AWS 这篇文章讨论的，是怎样在 Amazon Bedrock Knowledge Bases 入库前，把网页整理成更适合检索的内容。

作者的建议很克制：先用托管 Web Crawler；只有需要正文提取、抓取边界控制或自定义元数据时，再加 Crawl4AI。文章提供了完整工程路径，也明确列出了示例距离生产可用还缺什么，适合正在做文档问答和网站知识库的开发者参考。

什么时候才需要自己加一层爬虫

Amazon Bedrock Knowledge Bases 负责数据摄取、存储、索引和检索。对于 managed knowledge base，向量存储不需要自行部署和扩容，embedding 和 reranking 默认也由服务管理。

网页入口优先选 Amazon Bedrock Web Crawler：配置获授权的种子 URL 或 sitemap，设置范围和速率即可。它遵守 robots.txt，支持等待 JavaScript 加载内容；首次全量抓取之后，同步处理新增、更新和删除。

Crawl4AI 的价值在于入库前的加工。作者列出三种需求：

• 用 DefaultMarkdownGenerator 配合 PruningContentFilter，减少导航等模板内容，同时保留标题、列表和表格。
• 用可选 CSS selector 提取指定区域，并通过种子来源、路径、主机、深度、页数和 URL 模式限制遍历。
• 给文档附加来源 URL、抓取时间和业务属性，供检索时过滤。

需要控制送进知识库的内容，才值得增加这层准备流程。

这里处理的是已知网站的批量入库，不是 Amazon Nova Web Grounding 那类推理时实时访问网页。示例也只抓公开页面，没有实现登录会话。遇到登录站点，作者建议先评估托管爬虫的 basic、form-based 和 SAML authentication；自行扩展则要补会话处理、AWS Secrets Manager 凭据管理和安全审查。

Markdown 和元数据怎样进入知识库

流程由 Amazon EventBridge 定时启动 Amazon ECS 上的 AWS Fargate task，再依次执行抓取、上传 Amazon S3、启动摄取。容器入口是 scripts/container_entrypoint.py，启动时从 AWS Systems Manager Parameter Store 读取非敏感配置。

Crawl4AI 到文件准备完成就结束工作。后续解析、切块、生成向量和索引，仍交给 Bedrock。

抓取使用 BFSDeepCrawlStrategy 做广度优先遍历，浏览器配置为 headless=True、java_script_enabled=True。示例通过 mean_delay 控制请求间隔，并设置 max_range=0、semaphore_count=1。完整实现还处理 URL 过滤、总页数限制和重定向检查，不能把正文中的简化片段直接当成全部边界控制。

正文清洗也不是精确规则。PruningContentFilter 依靠启发式判断，作者明确要求检查代表性输出：去掉了菜单，却顺手删掉正文里的关键说明，同样会损害检索。

每个 page.md 必须配一个同位置的 page.md.metadata.json。下面这段展示了带类型的元数据格式，解决来源追踪和条件过滤的问题：

{
  "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"}
    }
  }
}

要留意 crawled_at_epoch 使用 NUMBER。sidecar 上限是 10 KB；示例发现超限后，会在写入这对文件之前报错。数据源的 Metadata files prefix 应留空，让服务按文档旁的文件读取元数据。

上传只发送本轮生成的路径，但上传是累加的。某页这次没抓到，或者从种子中移除了，不会自动删除旧 S3 对象。清理过期内容需要删除正文和 sidecar，再启动摄取；若启用 deletion protection，还要检查删除比例阈值，超限可能跳过删除阶段。

先验证检索，再接生成回答

切块策略在创建数据源时选择，之后不能直接修改，需要新建数据源。managed knowledge base 的默认切块为 300 tokens、20% overlap，还支持自定义最大 token 数和重叠比例，或用 No chunking 把每个文件视为一个块。customer-managed knowledge base 另有 semantic 和 hierarchical chunking 等选项。

这些是可选机制，不是效果结论。作者没有给出哪种策略准确率更高的对照实验，要求用代表性页面和问题自行比较。

下面的代码直接检查召回片段，限定 content_category=web，并只返回最近七天抓取页面中的最多五个块：

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])

关键是 managedSearchConfiguration：customer-managed 类型应改用 vectorSearchConfiguration，过滤算子的支持范围也取决于向量存储。运行示例需要 Boto3 1.43.32 或更高，可执行 python -m pip install "boto3>=1.43.32"。managed 类型不支持 startsWith 和 stringContains。

managed knowledge base 使用 hybrid search，采用默认托管 embedding 模型时还会使用托管 reranker。检索验证通过后，managed 类型通过 AgenticRetrieveStream 获取片段、回答和引用；customer-managed 类型使用 RetrieveAndGenerate。

这里有个容易误读的地方：crawled_at_epoch 表示抓取时间，不代表网页内容最近更新。旧文章重新抓一次，也会进入这组结果。另外，元数据过滤不能充当权限边界；文档级权限需要 ACL 文件，示例没有生成它们。

我的判断

我认同作者把托管连接器放在首选位置。自建流程的收益是控制力，代价则包括内容清洗、删除同步、任务调度和监控。文章没有提供 Crawl4AI 相对托管爬虫的召回率、延迟或成本对照，因此不能据此认定增加清洗就一定提高回答质量。

示例的运行状态尤其需要重新定义。它没有防止任务重叠，也没有配置重试策略、死信队列和告警。摄取任务显示 COMPLETE 时，部分文档仍可能失败，而容器退出码依旧是 0。只盯任务是否成功，很容易漏掉知识缺口。

默认任务为 2 vCPU、4 GB，等待摄取时最多轮询 30 分钟，这段时间也计费；超时退出并不会停止摄取。Container Insights、VPC flow logs、KMS key、public IPv4，以及可选 NAT gateway 和 interface endpoints 都可能增加费用。对于更新不频繁的小型文档站，这些运维成本可能比抓取逻辑更值得先算清。

原文末尾的 Guardrails 段落被截断，无法据此补全其生产安全建议。

能拿来做什么

• 给前端组件文档或公开技术文档建知识库时，先验证托管 Web Crawler 的覆盖情况。只有菜单、侧栏等内容确实干扰召回，再尝试 CSS selector 和 Markdown 清洗。
• 首次部署保留 maxDepth=1、maxPages=25，先用 --dry-run 检查页面范围和正文输出，再扩大抓取。部署需要 Python 3.10+、Node.js、AWS CLI v2、AWS CDK CLI v2 和运行中的 Docker。
• 在 Node 或前端问答界面接入生成回答前，先固定一组问题检查 Retrieve 的片段、页面覆盖和 source_url。切块或清洗规则调整后，重新跑这组问题。
• 准备定时运行时，把过期页面删除、文档失败告警和任务防重叠列入上线工作。默认 rate(24 hours) 只是调度频率，不能代替同步完整性的检查。