Cloudflare AI Search 与 Vectorize：选择 RAG 技术栈

Cloudflare AI Search 与 Vectorize 的选择，取决于团队需要自行负责多少检索管道。向量数据库可以查找相似向量，但业务搜索功能还需要有用的源材料、导入、权限、更新，以及能够证明返回信息确实回答了问题的证据。

如果 AI Search 的托管导入和检索方式适合你的来源，而且希望减少自行维护的管道，可以选择 AI Search。如果需要直接控制嵌入、索引和检索行为，而且有能力维护这些组件，可以选择 Vectorize。在添加生成式答案之前，应先用真实搜索问题和权限边界评估两者。

设想一家经销商拥有产品手册、内部流程和客户专属协议。找到相似段落只是任务的一部分。员工必须看到正确版本，客户协议必须保持受限，答案还应指向支持该答案的文档。

本文借助这一假设系统比较实施责任，不假定托管管道能够理解你的文档质量，也不假定自定义检索一定表现更好。

Cloudflare AI Search 与 Vectorize：比较实际工作

Cloudflare 的管道文档 区分了托管 AI Search 与更底层的 Vectorize 数据库。AI Search 处理索引和检索周边的步骤；使用 Vectorize 时，则由应用提供并管理向量。这个区别比询问哪个产品更适合聊天机器人更有用。

搜索功能仍需要应用边界。确定谁可以提交问题、哪些来源允许使用，以及结果是段落列表还是生成的解释。文档助手与搜索框可以共享基础设施，但验收标准可能不同。

如果不熟悉这些术语，我们的 RAG 指南 介绍了整体模式。本文讨论的是由谁负责实现，尤其是在文档处理或检索规则较为特殊时。

从来源清单开始

来源清单应记录权威存放位置、文档负责人、更新流程与访问规则，也要纳入过时副本和相互矛盾的文档。搜索可能更高效地暴露这些问题，却不会替你解决问题。

对于经销商而言，当前手册和旧版手册可能包含同样看似合理的答案。调整相似度阈值前，应添加版本上下文，并制定哪份文档具有权威性的编辑规则。检索质量也部分取决于内容治理。

不要一开始就导入尽可能大的语料库。选择范围明确的文档集合，并安排一位能够判断结果是否有用的负责人。这个人也能识别该集合不应该回答哪些问题。

将检索质量与答案质量分开

根据真实任务创建问题集，包括产品名称、缩写、准确零件编号以及需要多个段落才能回答的问题。加入故意无法回答的问题，以及用户没有相关文档访问权限的案例。

首先只检查检索到的证据，不生成正文。结果是否包含一位了解业务的同事会采用的段落？当前文档的排序是否合理？返回文字是否足以理解指令，而不是孤立的片段？

随后单独评估答案生成。措辞优美的答案可能掩盖薄弱的检索，而有用段落也可能被错误地概括。将这些评估分开，才能在失败时明确下一步。

Cloudflare 将元数据过滤 列为搜索配置的一部分。应将过滤器视为需要配置和测试的机制，不能据此认定应用已识别正确的用户或租户。

保留精确标识符

语义相似性有助于处理措辞不同的问题，但某些业务任务需要精确的标识符、修订版本或错误码。同事挑选替换零件时，近似匹配可能比没有结果更糟。

评估中应包含这些案例。不能仅因搜索能回答宽泛描述性问题，就忽略它混淆相邻产品编号的情况。应确定应用是优先精确匹配、要求澄清，还是只显示来源结果而不生成答案。

直接负责 Vectorize 会改变什么

Vectorize 文档 提供数据库层的说明。自定义应用还必须建立文档处理、嵌入选择、标识符、来源查找与更新处理机制。每项选择既带来灵活性，也产生运维义务。

应为文档块定义版本化表示，使团队能够识别生成某个已存储向量的来源修订版本、提取过程与嵌入配置。这份记录有助于解释为什么后续重建索引会改变结果。

规划删除路径时，应像规划插入路径一样认真。如果协议被撤回，应用需要停止通过所有相关检索和缓存路径返回其内容。导入作业成功，并不能证明旧内容已经消失。

当这些选择确实影响负载，而且团队能够评估时，自定义检索才有充分理由。如果主要理由只是某篇教程让插入向量显得很简单，就很难证明其价值。

明确比较运维责任

任一方案都不能消除运维责任。必须有人知道来源同步何时失败、文档为何缺失，以及排序变化是否可以接受。

对经销商而言，一份有用的事故报告可能说明手册已接收但提取失败。如果报告只说搜索端点运行正常，内容负责人就无法据此解决问题。

扩大语料库之前先理解成本

将初始实施与导入、查询处理、存储和支持分开。相关负载不仅包括用户问题，也包括文档变更与重新处理。即使搜索界面使用量很低，只要来源集合频繁变化，后台工作仍可能很大。

要求两种方案基于同一语料库和问题集，提供范围明确的 GBP 报价。应计入修复源材料、实施权限、验证结果，以及培训文档集合维护人员的投入。

自定义管道应计入重建索引与迁移工作。改变嵌入方式可能需要平行索引和另一轮评估。托管搜索则应评估：现有控制能否在不改变架构的情况下满足未来要求。

避免编造每次回答成本。可靠的用量估算需要经过核实的供应商费率，以及实测的文档大小、查询、生成和重试假设。在这些数字尚不可得时，可以围绕责任作出架构决策，但预算不能假装已经掌握这些数据。

先验收搜索功能，再委托开发助手

约定什么样的结果才可用：来源正确、修订版本适当、段落上下文充分，并能按照用户的普通权限打开文档。还应提供明确的空结果状态及报告错误结果的方式。

要求复核人员在更新和删除后重复评估。这是在测试系统能否随着集合变化持续保持可用性，而不只是展示首次导入成功。

当检索对任务而言足够可靠后，再添加生成式答案。保留引用，并明确说明证据不足的情况。不能仅因语言模型可以写出看似合理的一段文字，就回答没有依据的问题。

我们的 AI 集成试点 可以比较范围明确的语料库，在实施范围扩大前约定权限和评估契约。请提供来源位置、访问模型与示例问题，索取检索实施方案 。这些细节比笼统要求一个企业聊天机器人更有用。

常见问题

AI Search 可以替代 Vectorize 吗？ 两者工作在不同层级。AI Search 提供托管搜索管道，Vectorize 则为应用管理的向量提供数据库。实际选择取决于你需要控制和维护多少检索基础设施。

哪个方案的答案更好？ 没有你的文档和问题，就无法判断任何一方。先评估检索，再评估生成式答案。来源质量、权限规则和精确标识符的处理，可能比产品名称更重要。

托管搜索意味着不再需要开发人员吗？ 它可以减少管道实施工作，但应用仍需要身份、访问决策、来源集成、有用的失败状态与评估。开发量取决于工作流和现有系统。

可以防止私有文档出现在公开答案中吗？ 应明确设计并测试这个边界。根据已认证身份与来源访问规则推导允许的来源。加入查询其他用户文档、以及未获权限就打开返回引用的尝试。

应该立即索引所有公司文档吗？ 从范围明确、负责人能够判断结果的集合开始。扩大范围前，先处理过时副本与矛盾材料。如果没人能解释哪份文档具有权威性，大索引也没有用。

检索试点应该包含什么？ 包括来源清单、代表性问题、精确标识符案例、无法回答的问题与权限测试。报告应区分解析、检索和生成故障，让下一步工程工作明确。

如何为搜索维护编制预算？ 计入文档同步、异常复核、变更后的评估及支持责任。自定义管道还应计入处理和索引迁移。接受持续费用估算前，应要求提供实测的用量假设。