Cloudflare AI Search 如何索引和检索你的内容

• 原文标题：How AI Search works
• 作者：Cloudflare
• 内参日期：2026-08-11
• 来源类型：blog
• 原文：https://developers.cloudflare.com/ai-search/concepts/how-ai-search-works/
• 标签：context engineering

官方概念页，讲向量检索与关键词检索怎么配合完成索引与召回。2 分钟，适合当作自建检索方案前的口径对齐材料。

导读

Cloudflare AI Search

核心观点

• AI Search 是一个托管搜索服务（managed search service）：接一个网站、一个 R2 bucket，或者直接上传自己的文档，它就把内容索引好，供自然语言查询。开发者不需要自己搭检索基础设施。
• 整个产品被拆成两个核心过程，一异步、一同步，这是理解全文的骨架：
• 索引（Indexing）：异步过程，把内容转换成向量和关键词索引。连接数据源或上传文件时自动触发。
  • 查询（Querying）：同步过程，由用户查询触发。用向量检索、关键词检索或两者共同取回最相关的内容，并可选地生成回答。
• 查询链路上有一半环节标着 optional——查询改写、关键词检索、融合、重排——它们是留给使用者的质量旋钮，不是默认路径的一部分。
• 产品的托管边界写得很明确：AI Search 建在 Vectorize 之上，把 Vectorize 之外的整条搜索流水线补齐了。想自己管向量用 Vectorize，想要托管的内容搜索用 AI Search。

索引：一条把任意内容变成两套索引的异步流水线

• 索引在两种情形下自动开始：连接一个数据源，或者通过 Items API 上传文件。使用者不需要手动触发。
• 索引过程有六个确定的步骤：
• 数据摄取（Data ingestion）：AI Search 从已连接的数据源读取内容，或接收通过 Items API 上传的文件。
  • Markdown 转换（Markdown conversion）：用 Workers AI 的 Markdown Conversion 把受支持的数据类型转成结构化 Markdown。原文点明这一步的目的是「ensures consistency across diverse file types」——在千差万别的文件类型之间建立一致性。
  • 分块（Chunking）：抽取出的文本被切成更小的片段，目的是提高检索粒度（improve retrieval granularity）。
  • 嵌入（Embedding）：每个 chunk 用 Workers AI 的嵌入模型转换成向量。
  • 关键词索引（Keyword indexing）：当关键词检索被启用时，每个 chunk 还会额外建一份 BM25 关键词匹配索引。
  • 存储（Storage）：向量、关键词索引和内容本身一起被存下来，随时可供检索。
• 图片有专门的处理路径：先用 Workers AI 做目标检测（object detection），再做 vision-to-language 转换，把图片变成 Markdown 文本，然后并入同一条流水线。※ 这意味着图片并不是被单独索引，而是被翻译成文字后与其他内容同等对待。

索引不是一次性动作：两种数据源的更新节奏

• 连接了数据源的实例：AI Search 会定期检查更新，并自动索引变化的部分。内容变了，索引跟着变。
• 使用内置存储（built-in storage）的实例：新文件在上传时就被索引。
• 两种模式的共同点是索引的持续性由服务方负责，使用者不需要自己写同步逻辑或调度任务。

查询：九步链路与两个出口

• 索引完成后，AI Search 即可实时响应终端用户的查询。查询流水线的完整顺序是：
• 接收查询：查询工作流从你向 AI Search 的 Chat Completions 或 Search 端点发请求开始。
  • 查询改写（Query rewriting，可选）：用 Workers AI 的某个 LLM 重写输入查询，把原始问题转换成更有效的检索查询，以提升检索质量。
  • 查询嵌入（Embedding the query）：改写后的（或原始的）查询被转换成向量——关键在于用的是与索引你的数据时同一个嵌入模型。
  • 向量检索（Vector search）：查询向量与已存储的向量做匹配，找出语义相似的内容。
  • 关键词检索（Keyword search，可选）：启用混合检索时，一次 BM25 关键词检索与向量检索并行运行。
  • 融合（Fusion，可选）：使用混合检索时，向量结果与关键词结果按配置的 fusion 方法合并。
  • 重排（Reranking，可选）：一个 cross-encoder 模型把查询和文档放在一起评估，对结果重新打分。
  • 内容取回（Content retrieval）：返回最相关的 chunk 及其来源内容。如果你用的是 Search 端点，流程到此为止，内容在这一步就返回了。
  • 回答生成（Response generation）：如果你用的是 Chat Completions 端点，一个文本生成模型基于取回的内容生成回答，行为由 system prompt 决定。
• 两个出口的区别是整条链路的分水岭：
• Search 端点：只做检索，把 chunk 和来源还给你，生成环节由你自己决定怎么做。
  • Chat Completions 端点：一路走到底，直接返回生成好的回答。

可选环节的意义：默认路径与质量旋钮

• 必经环节只有四个：接收查询、查询嵌入、向量检索、内容取回。这是最短、最快的默认路径。
• 四个可选环节（查询改写、关键词检索、融合、重排）分布在链路的不同位置，各自解决不同问题：
• 查询改写作用在入口，改善的是「问题问得好不好」。
  • 关键词检索与融合作用在召回，补的是纯语义检索对精确词、专有名词的短板。
  • 重排作用在排序，用 cross-encoder 联合评估查询与文档，换取更准的相关性判断。
• 索引侧与查询侧的可选项是成对出现的：只有索引时启用了关键词索引，查询时才可能跑 BM25 与融合。

与 Vectorize 的分工：托管边界画在哪

• 原文最后一段给出了产品定位的准绳：AI Search 建在 Vectorize 之上，并围绕它补齐了搜索流水线的其余部分（adds the rest of the search pipeline around it）。
• 选择依据被压缩成一句对照：想自己管理向量（manage vectors yourself）就用 Vectorize；想要对自己内容的托管搜索（managed search over your content）就用 AI Search。
• ※ 换句话说，Vectorize 提供的是向量数据库这一层能力，AI Search 卖的是转换、分块、嵌入、索引更新、检索编排、生成这一整套流程的托管。

编辑部补充｜Cloudflare AI Search 全景

它是什么：一条托管的 RAG 流水线

原文只讲了索引与查询两个流程，没说这个产品在 Cloudflare 全家桶里的位置。AI Search 官方文档首页 给的定位是「让任何应用或 agent 加上搜索能力，而不必自己搭一整套检索基础设施」；产品页 更直白，把它叫做 automatic RAG pipeline——摄取、索引、查询三段全包，开发者只负责接数据源和发问题。

它不是凭空造的：底层用 Vectorize 存向量、Workers AI 跑 Markdown 转换与嵌入推理、R2 可以直接当数据源。原文结尾那句「想自己管向量就用 Vectorize，想要托管搜索就用 AI Search」，说的正是这层关系。

它原来叫 AutoRAG

这是理解这个产品最重要的一条背景。它 2025-04-07 以 AutoRAG 之名开放 beta，2025-09-25 更名为 AI Search，同时开放多家模型供应商支持（发布记录）。

更名不只是换个招牌，API 形状也换了：旧路径 /autorag/rags/ 换成 /ai-search/instances/，请求体从单个 query 字段改成 OpenAI 风格的 messages 数组，API token 权限项也从 AutoRAG 换成 AI Search（迁移指南）。旧端点官方说「会继续可用」，但没给明确的日落时间表。所以你在网上搜到的多数中文教程还停留在 AutoRAG 时代，照抄会踩路径不对的坑。

原文没展开的检索侧细节

原文把 hybrid search、fusion、reranking 都标成 optional 一笔带过，这三件事恰恰是检索质量的主战场：

• hybrid search：向量与 BM25 关键词检索并行跑，需要建实例时把 index_method.vector 和 index_method.keyword 同时置 true（hybrid search 文档）。代价是容量减半——付费版纯向量实例上限 100 万文件，开了关键词索引降到 50 万。
• fusion：两路结果合并有两种算法，默认 Reciprocal Rank Fusion（按两边的排名位置打分，官方推荐的通用选择），另一种是 Max（取两边归一化分数的较大值，适合已知某一路明显更强的场景）。
• reranking：默认关闭，开启后用 cross-encoder 模型把 query 和候选 chunk 放在一起重新打分。当前可选模型是 @cf/baai/bge-reranker-base，最低分阈值取值 0 到 1、默认 0.4；官方明示会增加一次请求步骤，延迟上升（reranking 文档）。 模型侧一共五个可换位点：图转 Markdown、嵌入、查询改写、重排、生成。嵌入模型只能在创建实例时选定、之后不可改，生成模型随时可改；选 Smart Default 则由 Cloudflare 替你选并随时间自动升级（模型配置）。接第三方模型（OpenAI、Anthropic 等）要先把 provider key 放进 AI Gateway，再把 gateway 接到 AI Search。

三种接入面与多租户

查询有三个入口：Workers binding、REST API、以及 MCP server——最后这个意味着它可以直接挂给 agent 当检索工具用。

做 SaaS 的多租户隔离有两条路（多租户文档）：官方推荐一租户一实例，靠 namespace binding 在运行时动态建删，隔离最硬；租户多而小的场景可以共用一个实例、按文件夹路径组织内容，查询时用 metadata filter 收窄到该租户的目录。

价格与限额（2026-08-11 时点）

开放 beta 期间 AI Search 本身在限额内免费，存储、向量索引、Browser Run 用量都已含在内；单独计费的只剩 Workers AI 和 AI Gateway。迁到托管基础设施之前，R2、Vectorize 等是分开计费的，老文章的成本估算不再适用（限额与价格）。

几个容易撞上的硬限额：单文件最大 4 MB；免费版每实例 10 万文件、每月 2 万次查询、每天爬 500 页；付费版实例数上限 5000、查询不限量。自定义 metadata 字段每实例最多 5 个、单值 500 字符——原文没提这条，但它直接决定了你能设计多复杂的过滤维度。

近期演进方向（2026 年）

2026-06-18 所有实例完成向托管基础设施迁移；2026-07-30 补齐了 Agents SDK、Vercel AI SDK、LangChain 的接入指南；2026-08-06 加了 Cloudflare Access 保护的自定义域名，以及一个叫 Discover 的解析类型，专门用来爬没有完整 sitemap 的网站。方向很清楚：从「一个 RAG 工具」往「agent 的默认检索后端」上靠。

资料来源

• Cloudflare AI Search 文档首页（访问日期 2026-08-11）
• How AI Search works（访问日期 2026-08-11）
• AI Search Release note（访问日期 2026-08-11）
• Migrate from AutoRAG Search API（访问日期 2026-08-11）
• Hybrid search（访问日期 2026-08-11）
• Reranking（访问日期 2026-08-11）
• Models（访问日期 2026-08-11）
• Multitenancy（访问日期 2026-08-11）
• Limits and pricing（访问日期 2026-08-11）
• Cloudflare AI Search 产品页（访问日期 2026-08-11）

概念网络

关键概念

托管搜索服务（managed search service）

context：文章开篇给 AI Search 的定性。它的边界是「Connect a website, an R2 bucket, or upload your own documents」，之后索引与检索都由服务方负责，使用者只提供内容和自然语言查询。

费曼一下：不是给你一套零件让你自己装一台搜索引擎，而是给你一个插口——把内容塞进去，问题问出来，中间那条流水线归他们管。

索引（Indexing）

context：AI Search 两个核心过程之一，被明确标为**异步（asynchronous）**过程，作用是把内容转换成向量和关键词索引，在连接数据源或上传文件时自动运行。

费曼一下：相当于图书馆入库。书运到了不着急借出去，先编目、贴标签、上架，慢慢做完；等有人来找书，才知道去哪一层哪一排取。

查询（Querying）

context：另一个核心过程，被标为**同步（synchronous）**过程，由用户查询触发，用向量检索、关键词检索或两者取回最相关内容，并可选地生成回答。

费曼一下：读者站在柜台前问一句话，就得马上有人跑去书架取回来。异步与同步的分界，本质上是「什么事可以慢慢做」与「什么事必须当场做完」的分工。

Markdown 转换与一致性

context：索引流水线的第二步，用 Workers AI 的 Markdown Conversion 把受支持的数据类型转成结构化 Markdown，原文给出的理由是「ensures consistency across diverse file types」。

费曼一下：与其让后面每个环节都学会认识十几种文件格式，不如在最上游一次性把它们翻译成同一种语言。以一次转换换来下游的简单，是典型的工程取舍。

图像的 vision-to-language 转换

context：图片的专门处理路径——先做 object detection，再做 vision-to-language，把图片转成 Markdown 文本。

费曼一下：图片不被当成图片索引，而是先被「讲述」成一段文字，再和普通文档走同一条路。搜索系统能理解图片，靠的是把画面翻译成语言。

分块（Chunking）与检索粒度

context：抽取出的文本被切成更小的片段，原文给出的目的是 improve retrieval granularity（提高检索粒度）。

费曼一下：把一整本书当成一个检索单位，命中了也不知道该看哪一页。切成小块，命中的就是那一段，取回的内容才够精确。

嵌入模型的两端对称

context：索引时每个 chunk 用 Workers AI 的嵌入模型转成向量；查询时，查询也被「transformed into a vector using the same embedding model used to embed your data」。

费曼一下：语义检索靠的是在同一个坐标系里比距离。内容和问题必须由同一个模型翻译成坐标，否则量出来的距离没有意义。

BM25 关键词索引

context：索引侧的可选步骤——启用关键词检索时，每个 chunk 额外建一份 BM25 匹配索引；对应查询侧启用混合检索时并行跑的关键词检索。

费曼一下：向量检索擅长理解意思，但对精确的词、编号、专有名词容易失手。关键词索引补的正是这一块，靠字面命中兜底。

混合检索与融合（Fusion）

context：查询侧的可选环节。启用混合检索时，BM25 关键词检索与向量检索并行运行，两路结果再按配置的 fusion 方法合并。

费曼一下：两个眼睛看同一个东西，各自给出一份排名，再按某种规则合成一份。关键不在于哪一路更强，而在于合并的规则怎么定。

重排与 cross-encoder

context：查询侧的可选环节，位于内容取回之前。一个 cross-encoder 模型「re-scores results by evaluating the query and document together」。

费曼一下：前面的检索是把问题和文档各自变成向量再比距离，两边从没真正见过面。重排则是把问题和候选文档摆在一起通读一遍再打分——更准，但代价是每个候选都要重算一次。

Search 端点与 Chat Completions 端点

context：查询工作流的两个入口，也是两个出口。用 Search 端点时，内容在 content retrieval 这一步就返回；用 Chat Completions 端点时，再由文本生成模型基于取回内容生成回答。

费曼一下：一个只负责把材料找齐交给你，一个负责把材料读完写成答案。选哪个，取决于你想不想自己掌控生成那一步。

查询改写（Query rewriting）

context：查询链路的第一个可选环节，用 Workers AI 的某个 LLM 把原始输入「transforming the original query into a more effective search query」，以提升检索质量。

费曼一下：用户问得含糊，检索就找得含糊。先让模型把问题重新问一遍，问得更适合被检索，后面每一步的质量都跟着抬升。

托管边界（AI Search 与 Vectorize 的分工）

context：文章结尾的定位说明——AI Search 建在 Vectorize 之上，并围绕它补齐搜索流水线的其余部分；想自己管向量用 Vectorize，想要托管搜索用 AI Search。

费曼一下：同一个厂商把同一件事切成两个价位卖。你要么买向量数据库自己编排流程，要么买整条流水线交出编排权。选择的实质是：这一层的判断，你想不想自己做。

概念网络

graph TD
C1["AI Search 托管搜索服务"]
C2["索引 异步过程"]
C3["查询 同步过程"]
C4["Markdown 转换"]
C5["图像 vision-to-language"]
C6["分块 Chunking"]
C7["嵌入模型两端对称"]
C8["BM25 关键词索引"]
C9["查询改写"]
C10["向量检索"]
C11["混合检索与融合"]
C12["重排 cross-encoder"]
C13["Search 与 Chat Completions"]
C14["Vectorize 自管向量"]
C1 -->|层级| C2
C1 -->|层级| C3
C2 -->|首步| C4
C4 -->|覆盖| C5
C4 -->|因果| C6
C6 -->|因果| C7
C6 -->|可选| C8
C7 -->|支撑| C10
C8 -->|支撑| C11
C10 -->|支撑| C11
C3 -->|可选入口| C9
C9 -->|因果| C10
C11 -->|可选| C12
C12 -->|支撑| C13
C3 -->|两个出口| C13
C1 ---|分工| C14

• 最高一层是一次二分：C1 把自己拆成 C2（索引，异步）和 C3（查询，同步）。这条分界线决定了后面所有环节的位置——凡是「可以慢慢做」的都落在索引侧，凡是「必须当场做完」的都落在查询侧。
• 索引侧是一条严格的因果链：C4（Markdown 转换）→ C6（分块）→ C7（嵌入）。这条链条不可交换顺序，因为每一步都要求上一步已经把内容收敛成它能处理的形态。C5（图像转换）不是独立分支，而是 C4 的一个覆盖面——图片被翻译成文字后并入主链，而不是另起一条路。
• C7 是全网络唯一横跨两侧的节点。嵌入既发生在索引时（每个 chunk），也发生在查询时（用户的问题），而且原文强调必须是同一个模型。它是向量检索 C10 成立的前提：坐标系统一，距离才有意义。
• C8 与 C11 构成一对跨侧的呼应关系：索引侧启用了 BM25 关键词索引，查询侧才可能跑混合检索与融合。这是全文里可选项成对出现的最清楚的例子——查询侧的能力上限，在索引时就已经被决定了。
• C10 与 C8 在 C11 处汇合，是互补而非替代：向量检索给语义相似，关键词检索给字面命中，融合负责把两份排名合成一份。它们之间是张力关系——若两路总是给出同样答案，融合就没有存在必要。
• C9、C11、C12 是三个装在不同位置的质量旋钮：C9 在入口改善提问，C11 在召回补齐短板，C12 在排序上提高精度。三者都标着 optional，说明它们不是流程的必要构件，而是用延迟与成本换准确率的可调项。
• C13 是整条查询链的终点分叉：Search 端点在内容取回后就返回，Chat Completions 端点继续走完生成。同一条流水线，切在哪里，决定了产品交付给你的是材料还是答案。
• C14 与 C1 是分工关系，也是全文的收束：Vectorize 提供向量这一层，AI Search 把 C2 到 C13 的整条流水线包起来。两者不是竞品而是同一件事的两个抽象层次——选择哪一个，等于选择你想在哪一层保留自己的判断。

费曼 x3

把检索做成产品，最见功力的地方不是模型，而是把一件事拆成两件事：一件异步，一件同步。内容进来的时候不着急，转换、分块、嵌入、建索引，慢慢做完；用户提问的时候一秒都等不得，向量比对、关键词命中、融合、重排，一路跑到答案。这条分界线画对了，后面的工程问题才有解；画错了，要么索引拖垮响应，要么响应逼着索引偷工减料。

真正精巧的设计藏在两端的对称里。你的内容被某个嵌入模型转成向量，用户的问题也必须被同一个模型转成向量——原文写得很克制，只说 the same embedding model used to embed your data。这听着像实现细节，其实是整套语义检索成立的前提：只有落在同一个坐标系里，距离才有意义。不少人自建检索时换了嵌入模型却没重建索引，效果莫名其妙地垮掉，根子就在这句话上。

第二个值得琢磨的动作，是把一切先变成 Markdown。PDF、网页、图片，形态天差地别，但只要统一成结构化文本，后面的分块和嵌入就只需要面对一种输入。图片的处理尤其能说明问题：先做目标检测，再做 vision-to-language，把画面翻译成文字，然后并入同一条流水线。与其让每个下游环节都学会认识十几种格式，不如在最上游一次性收敛——这是工程上典型的以一次转换换全局的简单。

查询那条链上，一半的步骤标着 optional：查询改写、关键词检索、融合、重排。它们不是可有可无的装饰，而是留给你的旋钮，而且装在不同位置——改写作用在提问，关键词与融合作用在召回，重排作用在排序。默认路径最短最快，每拧开一个，都是拿延迟和成本换准确率。拧到哪一格，取决于你的场景能容忍什么，而不是取决于哪一档听起来更高级。

最后一句最该记住：AI Search 建在 Vectorize 之上，把剩下的流水线围着它补齐了。想自己管向量就用 Vectorize，想要托管的搜索就用 AI Search。选择托管从来不只是选择省事，而是承认自己在这一层没有独特的判断——然后把判断力省下来，留给你真正与众不同的那一层。