2. AI Search 托管了哪些工作

一套 AI Search 实例包含数据源、内置存储、解析器、Embedding 模型、向量索引、可选的关键词索引以及查询接口。下面这张图把离线索引和在线查询放在一起观察：

左侧是知识准备。文件上传后，AI Search 先把 PDF、HTML、Markdown 等内容转换为可处理的文本，再按配置切成 Chunk。每个 Chunk 经过 Embedding 后写入内置向量索引；如果启用了关键词检索，还会同时建立 BM25 索引。

右侧是用户查询。问题会进入向量检索、关键词检索或两者结合的混合检索。候选结果可以经过过滤、权重调整和重排，最后通过 search() 返回给应用，也可以继续交给 chatCompletions() 生成答案。

Cloudflare 的 AI Search 工作原理 与我们前面学习的两条 RAG 链路是一致的。区别在于解析、Embedding 和索引被放进了托管服务，应用仍然负责用户身份、业务权限、对话状态和最终产品体验。

3. 三种数据来源

AI Search 目前可以接收三类数据源。

内置存储适合刚开始学习或允许用户上传文件的应用。每个实例都带有由 R2 和 Vectorize 支撑的存储与向量索引，我们可以在控制台上传文件，也可以通过 Items API 写入。文件上传后会立即进入索引队列，不需要额外建立 R2 Bucket。

网站适合博客、帮助中心和公开文档。AI Search 根据 Sitemap 找到页面，定期检查变化，并把页面正文转成 Markdown。网站必须已经接入同一个 Cloudflare 账户；如果站点没有 Sitemap，爬虫便无法确定要访问哪些页面。

R2 Bucket适合已经把原始资料保存在对象存储中的项目。R2 继续作为文件事实来源，AI Search 按计划同步新增、修改和删除的对象。这种方式更适合生产环境，因为原文件的生命周期不依赖某一个搜索实例。

三种来源并不互斥。一个实例可以抓取公开网站，同时通过内置存储接收补充文件。Cloudflare 当前支持 Markdown、MDX、PDF、HTML、Word、Excel、CSV、图片和多种源代码文件，但单个文件不能超过 4 MB。完整格式与限制应以 数据源文档 为准。

4. Search 与 Chat Completions

AI Search 暴露了两个容易混淆的入口。

search() 只负责检索。它返回命中的 Chunk、来源、总分以及向量、关键词和重排等评分明细，不替应用生成答案。我们可以把结果交给自己的 LangChain、LangGraph 或外部模型，因此检索与生成仍然能够单独测试。

chatCompletions() 会先检索，再使用配置好的模型生成答案。返回值中既有模型回答，也有本次使用的 Chunk。它适合简单的 2-Step RAG，也能以 SSE 方式流式返回。

对于第一版知识库问答，可以先使用 chatCompletions() 验证数据是否可用。进入真实项目后，更建议先调用 search()，把候选资料、质量判断和生成过程放在自己的工作流中。这样出现错误时，我们能分清是没有检索到资料，还是模型没有正确使用资料。

5. 向量、关键词与混合检索

只启用向量检索时，系统按语义相似度找内容。用户问「请一天假找谁审批」，即使原文写的是「短期年假由直属负责人批准」，两者仍可能匹配。

关键词检索使用 BM25，更擅长错误码、接口名、型号和原文短语。搜索 ERR_AUTH_1042 时，精确包含这个字符串的文档通常比一段泛泛讨论身份认证的文字更重要。

混合检索会同时运行两种搜索，再通过 RRF 或 Max 方式合并排名。Cloudflare 推荐多数场景从 RRF 开始，因为它按名次融合，不要求向量分数与 BM25 分数处在同一尺度。具体机制可以参考 Hybrid Search 文档。

对于中文技术知识库，建议创建实例时就启用向量和关键词两套索引。Embedding 可以先选择 @cf/baai/bge-m3 或 @cf/qwen/qwen3-embedding-0.6b，再用自己的中文问题集比较。Embedding 模型在实例创建后不能直接更换，模型选错时通常要建立新实例并重新索引，所以不要只凭英文演示决定。

6. AI Search 与 Vectorize

Vectorize 是向量数据库，负责保存向量并执行相似度搜索。它不会替我们解析 PDF、设计切块、调用 Embedding、维护网站同步或生成答案。

AI Search 是位于 Vectorize 之上的完整检索服务。新创建的实例带有内置向量索引，我们不需要直接操作底层 Vectorize。需要完全控制向量 ID、父子块、多路召回和索引版本时，可以继续使用 Vectorize 自己搭建；需要快速完成文档问答时，AI Search 更省工程成本。

可以把两者的区别记成：Vectorize 提供检索基础能力，AI Search 提供已经组装好的知识库检索流程。前者自由度更高，后者交付速度更快。

7. 适合与不适合的场景

技术博客、产品文档、内部制度、FAQ 和客服资料很适合从 AI Search 开始。这些资料以文本为主，更新方式明确，问题通常可以由少量来源片段回答。

如果项目要求复杂的父子块检索、图数据库关系查询、跨模态定制、非常细的字段权限，或者必须完全掌握索引迁移过程，托管配置可能不够灵活。AI Search 仍处于 Beta，生产系统还要接受能力和价格继续变化这一事实。

对于 AI 电子伴侣，还有一条边界要提前说明：公开课程文章可以放进同一个知识库，用户私密记忆却不能只依靠前端传入的过滤条件。私密数据需要独立实例或服务端强制生成的权限范围，后面的生产文章会专门讨论。

8. 本组文章的实践路线

接下来我们会用一个「员工制度助手」贯穿示例。知识库包含请假制度、报销规则和办公设备说明。创建实例以前，我们先把 Embedding、查询改写、重排和生成模型的职责梳理清楚，再依次完成资料导入、Worker 查询、中文混合检索调优、LangGraph 接入，以及同步、权限、评测和费用控制。

这条路线不会把控制台上的一次成功查询当作完成。每一步都会保留原始问题、检索结果和来源，让我们能够说明系统为什么给出这个答案。

9. 总结

Cloudflare AI Search 是托管式 RAG 检索服务。它接管了文档解析、切块、Embedding、索引和数据同步，也提供向量、关键词、混合检索、重排与答案生成，但用户身份、业务权限和质量验收仍然属于应用。

下一篇会单独讨论 AI Search 的模型选型。我们会从价格、效果和适用范围三个角度比较 Embedding、Reranker 与生成模型，并给出适合中文技术知识库的起步组合。