RAG 应用的答案质量，不取决于模型有多聪明，而取决于你喂给它的数据有多干净。
这是亚马逊云科技官方博客里一句看似平淡的开场白，却戳中了企业级 RAG 落地最痛的点：大模型本身已经足够强，真正拖后腿的，是那些从网页上抓下来的、带着导航栏、弹窗、登录墙和动态渲染噪音的脏数据。2026 年 11 月 2 日，AWS 在 Machine Learning 博客发布了一篇实操文章，给出了一套把公开网页内容喂进 Amazon Bedrock Knowledge Bases 的完整流水线方案——核心工具不是 AWS 自家产品，而是一个在 GitHub 上拿到约 86.1k stars 的开源爬虫 Crawl4AI。
这件事值得注意的地方在于，它标志着 RAG 工程的重心正在从“选什么模型”转向“怎么把数据洗干净”。当托管知识库把向量化、索引、检索全部包办之后，唯一还留在开发者手里的变量，就是 ingestion 之前的那一步：抓取和清洗。
托管 RAG 越省事，入口数据越关键
Amazon Bedrock Knowledge Bases 是 Bedrock 的全托管 RAG 能力。托管知识库（Managed Knowledge Base）已经把 ingestion、存储、索引、检索全部接管：开发者只需连接数据源，无需预置或扩缩容向量库，embedding 和 reranking 默认使用服务托管模型。
省事有代价。正因为后面所有环节都被自动化了，数据入口的质量就成了唯一能决定答案上限的杠杆。AWS 这篇文章要解决的，正是“网页”这类最难伺候的数据源：HTML 是非结构化的，页面是动态渲染的，导航和页脚是噪音，还有登录墙和反爬机制挡路。直接把 URL 丢进知识库，等于把垃圾原封不动地搬进向量库。
AWS 给出的答案是一个六步流水线：EventBridge 按配置的调度启动 AWS Fargate 上的 ECS 任务，任务用 Crawl4AI 爬取配置的公开网站，把每个页面转成 Markdown 并附带一个元数据 sidecar 文件，上传到支撑知识库数据源的 S3 存储桶，然后启动 Bedrock Knowledge Bases 的 ingestion job；Bedrock 读取新增和变更的对象，解析、按选定策略分块、生成 embedding 并索引到向量库。
这里的分工边界画得很清楚：Crawl4AI 的角色在准备好源文档和元数据 sidecar 后就结束了；从 ingestion 开始，解析、分块、embedding、索引、检索全部由 Bedrock Knowledge Bases 接管。爬虫只负责把网页变成干净的文档，剩下的交给托管服务。
为什么是 Crawl4AI，而不是自己写爬虫
Crawl4AI 是 GitHub 用户 unclecode 维护的开源项目，Apache-2.0 许可，定位是“面向 LLM 和 AI agent 的网页爬虫”，核心能力是把任意网站转成干净的、LLM-ready 的 Markdown。截至 2026 年 11 月初，它的 stars 约 86.1k，forks 约 9k，已经是这个细分赛道里最受关注的开源项目之一。
AWS 选它不是偶然。网页抓取这件事，自己从零写脚本的成本被严重低估了：要处理 JavaScript 动态渲染，就得挂浏览器；要绕过反爬，就得模拟人类行为；要提取正文，就得跟无穷无尽的页面模板搏斗。Crawl4AI 把这些脏活累活封装成了开箱即用的能力——基于 Playwright 的浏览器导航或轻量 HTTP 请求，智能正文提取，异步处理，而且不需要 API key。
更关键的是输出格式。Crawl4AI 吐出来的是 Markdown，而不是原始 HTML。对 RAG 来说，Markdown 意味着更少的噪音 token、更清晰的层级结构、更高的检索信噪比。AWS 的流水线正是利用了这一点：每个页面对应一份 Markdown 文档加一份 JSON 元数据 sidecar，文件名是 page.md.metadata.json，携带抓取时间、来源 URL、内容分类等信息，供后续元数据过滤使用。
这其实是一种工程上的“职责分离”：让专业工具做专业的事。爬虫负责把网页变成文档，Bedrock 负责把文档变成可检索的知识。两边各守边界，比在 Bedrock 里硬塞一套爬虫逻辑要干净得多。
安全设计暴露了企业 RAG 的真实焦虑
如果只看功能，这篇文章最精彩的部分其实是安全章节。AWS 没有一上来就讲怎么爬，而是花了大量篇幅讲“怎么不把秘密泄露出去”——这恰恰是企业级 RAG 落地时最真实的焦虑。
这套流水线的安全设计有几个值得逐条看的细节。一个是最小权限 IAM：CDK stack 只授予 Fargate 任务角色三个权限——对指定 S3 bucket 前缀的 s3:PutObject、对目标知识库的 bedrock:StartIngestionJob 和 bedrock:GetIngestionJob、对单个配置参数的 ssm:GetParameter。EventBridge 的任务启动、容器镜像拉取、日志投递各有独立角色。整个流水线不读取也不列出 S3，不调用 InvokeModel，也不调用 Retrieve——一个爬虫流水线本来就不需要这些权限。
另一个是 secrets 管理。CDK app 把非秘密的流水线设置存在 Parameter Store 的明文 String 参数里，任务定义中只放参数名。AWS 明确警告：不要把密码、cookie、token 或其他秘密放进 CDK context 或这个参数。因为要爬的网站如果需要登录，凭据处理必须在容器内通过安全的 secrets 管理服务注入，而不是写在代码或配置里。
再加上容器加固：容器以 non-root 用户运行，CDK app 每次 synthesis 都跑 cdk-nag 的 AWS Solutions 检查。这些细节单独看都不起眼，但合起来传递了一个信号——爬取公开网页的流水线，在企业眼里同样是安全边界的一部分，而不是“只是个爬虫而已”。
检索质量要在 ingestion 之前就想清楚
文章的最后部分讲怎么验证检索质量，这里藏着一个容易被忽略的工程顺序：先用 Retrieve 测试代表性问题，再加入 generation。
托管知识库默认使用 hybrid search（混合检索），配合托管 embedding 模型时还会用托管 reranker 对结果重排序。开发者可以用 sidecar 里的元数据缩小结果范围——示例的默认配置会给每个页面打上 content_category=web 的标签，然后查询“最近 7 天内爬取的页面中最多 5 个 chunk”。这个示例要求 Boto3 1.43.32 或更高版本。
但真正决定检索上限的，是 ingestion 时选定的分块策略。这里有个硬性约束：托管知识库目前只支持 built-in/default 或 fixed-size 分块。default 分块会把文本切成约 300 token 的 chunk 并保留句子边界，适合简单散文；fixed-size 分块允许你指定最大 token 数和重叠比例，更可预测但也更容易切断逻辑段落。更高级的 semantic、hierarchical、自定义 Lambda 分块，是客户自建知识库（customer-managed knowledge base）才有的能力。
这意味着一个反直觉的结论：分块策略在 ingestion 那一刻就被焊死了，事后无法更改。所以正确的工程顺序不是“先 ingest 再说”，而是在 ingestion 之前就用真实问题测试不同分块策略的效果，看检索出来的 chunk 而不是只看最终答案。chunk 太小，检索精准但上下文不够；chunk 太大，上下文够了但向量匹配被稀释。这个权衡必须在数据进门之前想清楚。
RAG 的下半场，拼的是数据入口工程
把这篇博客放回更大的图景里看，它其实是 RAG 工程成熟化的一个信号。早期大家讨论 RAG，焦点在 embedding 模型选哪个、向量库用什么、要不要 rerank。到了托管知识库普及的阶段，这些都被云厂商打包成了默认选项，开发者手里剩下的、真正能拉开差距的变量，就是 ingestion 之前的数据入口工程。
网页内容只是第一个场景。文档、PDF、数据库、内部 Wiki、工单系统，每一种数据源都需要自己的“抓取—清洗—结构化—元数据标注”流水线。Crawl4AI 这类工具的价值，不在于它是个爬虫，而在于它把“网页到 LLM-ready Markdown”这段最脏的路标准化了。
对正在做企业 RAG 的团队来说，这篇文章给的可操作建议很明确：把数据入口当成独立模块设计，别让爬虫逻辑塞进应用代码；在 ingestion 之前先用真实问题验证分块和检索效果；哪怕爬的是公开网页，也要按企业安全标准设计权限和 secrets 管理。
模型决定 RAG 的下限，数据决定 RAG 的上限。当云厂商把向量化和检索都变成默认服务之后，真正的护城河只剩下一个：你能不能比对手更快、更干净地把世界上的信息搬进自己的知识库。
快报