Cloudflare Vectorize 与 RAG 入门：理解搜索与 AI 回答的区别

先说结论：Vectorize 缩短问题与页面之间的距离

网站可能已经有完善的指南与 FAQ，但访客仍然找不到它们。常见原因是页面标题使用的词，与访客提问使用的词并不相同。

例如，页面写的是“账户设置”，访客却会问“登录后该做什么？”或“我不明白初始设置”。Vectorize 能按语义而非仅按完全相同的词找到接近的公开内容，从而缩短这段距离。

它不会创造新事实，也不会自动修正过时信息。它的价值在于为已经发布、可以信任的信息建立更自然的入口。Cloudflare 也将 Vectorize 用于语义搜索、推荐和分类等场景。Cloudflare Vectorize 官方文档

先理解：什么是 RAG？

RAG 是 Retrieval Augmented Generation 的缩写。可以简单理解为：先搜索相关信息，再让 AI 使用这些信息生成回答。

可以把 Vectorize 看作图书管理员的检索目录：它查找语义接近的资料。RAG 则是完整的工作流程：找到资料、阅读选定来源，再附带来源说明来回答问题。

它不是直接把问题发送给 AI，而是先从自己的公开信息中取回相关资料，再把资料作为上下文交给模型。Cloudflare 将“把向量搜索得到的上下文加入发送给 LLM 的 prompt”称为 RAG。Cloudflare 官方说明

Vectorize 与 RAG 的职责不同

部件	职责	单独可以做什么
Pagefind	在页面中查找词语	快速查找产品名、专有名词和错误代码
Vectorize	查找语义接近的信息	返回改述和关联页面的候选项
RAG	使用检索到的依据生成 AI 回答	返回回答及其来源页面链接

Vectorize 不会生成回答。RAG 也不只是搜索。只有把检索、依据筛选、回答生成和来源展示作为同一份契约设计，读者才能核对回答。

图：普通搜索适合精确词语；语义搜索适合改述和相关信息。不要用一种取代另一种，而要分配不同角色。

何时最能发挥作用

适合引入 Vectorize 的场景	应先完善信息设计的场景
用户用不同说法询问同一件事	公开页面、草稿和内部信息没有清晰边界
FAQ、指南、规格和案例分布在多页	内容过时，无法判断哪一页是当前依据
希望把读者带到下一篇相关页面	只需要快速找产品名、型号或错误代码
回答需要附上原始页面链接	计划让 AI 自由回答却不展示来源

语义搜索不能替代信息质量。先明确公开内容的责任边界，再用一小组代表性问题检查会返回哪些页面。

分三阶段开始

不必一开始就制作聊天机器人。按下面的顺序可以在保持安全的同时观察价值。

1. 保留普通搜索：继续用 Pagefind 查找产品名和错误代码。
2. 增加关联页面搜索：用 Vectorize 展示与问题接近的公开页面，并用代表性问题评估结果。
3. 增加有依据的回答：只有定义了可用页面、来源链接和拒答条件后，才加入 RAG。

图：普通搜索仍是基础，因此可以逐步验证语义搜索和 AI 回答，必要时安全回退。

这样可以先验证搜索信息本身是否正确，再优化 AI 回答的呈现。

RAG 的回答从筛选依据开始

要决定的事	容易开始的选择	原因
问题范围	只回答公开网站的信息	避免把草稿或内部信息误用于回答
依据显示	每个回答链接到原页面	读者可以核对回答
依据不足时	说明“无法确认”	避免看似合理的猜测
搜索分离	输入时使用 Pagefind；明确操作后使用 Vectorize／RAG	传输范围、成本和等待时间更容易理解
更新基准	使用已发布 HTML 与其发布状态	不把草稿和未公开修改混入回答依据
评估方法	核对代表性问题及其原始页面链接	不只凭“看起来合理”的回答判断质量

RAG 不能保证绝不出错。corpus 的选择、依据的确认以及明确何时不回答，决定了它的质量。

图：RAG 不把搜索结果直接当作回答，而是核验来源，只把可用依据连接到回答和引用。

从判断到实现，接下来可以这样阅读

1. 安全实现 Vectorize 的详细指南：公开 HTML corpus、content hash、差量同步、Preview／Production 隔离和 rate limit。
2. 面向咨询 AI 聊天的技术设计：AI 输入、API 边界与 URL 允许列表。
3. 用 Astro 与 Cloudflare 扩展官网的整体设计：静态网站如何安全增加搜索与 AI 功能。

把“需要更好的搜索”和“需要可追溯来源的 AI 指引”分开判断，所需的实现与验证就会更清楚。