在第 2 章和第 3 章中，你已经学习了关于 DIY RAG 的全部内容——从嵌入模型和向量数据库这些基础组件，到混合搜索、重排序和幻觉检测等更高级组件。第 4 章探讨了为什么把一个 DIY RAG 应用从简单的概念验证推进到完全生产就绪的部署，往往比最初看起来更复杂；它强调了在真实环境中扩展 RAG 所涉及的关键挑战，并建议了成功进行生产级 DIY 部署所需采取的步骤。
“RAG 平台”（也称为 RAG-as-a-service 或 turnkey RAG）指的是一种技术平台，它在开发者 API 背后实现了大部分甚至全部 RAG 组件。这抽象掉了构建 RAG 的大量复杂性，让开发者可以转而专注于 RAG 应用本身——响应应该基于什么数据，以及应用如何集成进你的业务或应用流程。
在本章中，我们将介绍 RAG 平台提供什么，以及如何选择最符合你需求的平台。我们会用 Vectara 演示这类平台的使用方式。
DIY RAG 与平台化 RAG
当你构建 DIY RAG 技术栈时，你可以对 RAG 流水线中的每个组件进行细粒度控制。这包括选择和配置向量数据库，例如 Pinecone、Weaviate、Zilliz、Qdrant；托管并服务任何嵌入模型，例如 Cohere 的 Embed v4 或 Qwen3-Embedding-0.6B；定义并实现切分策略；以及定制 LLM 的生成过程。
定制 RAG 技术栈的权力掌握在你手中，但底层基础设施的供应、集成、扩展和维护责任也同样在你手中。
相比之下，RAG 平台提供的是一套托管的端到端解决方案，抽象掉基础设施复杂性。开发者通过 API 与服务交互，从自己的数据源摄取数据，选择并配置检索流水线，选择嵌入模型或生成模型，并用最少设置部署一个 RAG 应用。
正是这种摆脱基础设施负担的能力，赋予了 RAG 平台优势：使用 DIY 方法时，你会把大量精力花在非核心任务上，例如服务器供应、向量数据库优化、确保高可用和低延迟，以及管理每个组件的安全更新。RAG 平台提供商会接管这些运维开销，让你只需要专注于构建应用逻辑并向终端用户交付价值。这意味着更快的开发周期、更低的 DevOps 工作量，以及潜在更低的前期基础设施成本，因为这类服务通常以按需付费或订阅制提供。
此外，RAG 平台通常自带针对低延迟、高准确率和成本效率的内置优化，利用提供商在管理大规模 RAG 系统方面的专业能力。RAG 平台提供商还可能开箱即用地提供数据源连接器、高级监控和可观测性，以及安全和隐私合规能力；如果用 DIY 方式复制这些能力，则需要大量工程投入。
如图 5-1 所示，RAG 平台提供了一个中央控制平面，使组织能够围绕安全性、准确性、成本和性能进行治理。
虽然 DIY 方法提供最大灵活性和定制能力，但 RAG 平台因其便利性、部署速度和较低运维复杂度，正变得越来越有吸引力。不过，这种易用性也伴随着平台锁定风险，以及在未来需要更换提供商时可能产生的迁移成本。
现在，你已经知道 RAG 技术栈中有哪些组件，以及它们如何工作（来自第 2 章和第 3 章），你已经具备了作出决策所需的基础：是创建自己的 RAG 系统，还是使用 RAG 平台，并结合组织需求权衡优缺点。在本章中，我们会讨论一些细微差别，帮助你完善理解，并作出充分知情的决策。
图 5-1 展示了一个 RAG 平台如何为 IT 治理提供集中式管理，覆盖安全性、准确性和成本，并支持标准化以及开发者交互。
图 5-1 RAG 平台支持对安全性、准确性、成本和性能进行集中式管理，同时让开发者能够与标准化的 “RAG API” 交互
核心 RAG 能力
第一个考虑因素当然是 RAG 响应质量，而响应质量取决于数据摄取能力，以及查询/检索流水线能力。下面我们逐一回顾这些组件，以便更好理解每一项在 DIY 与平台之间的取舍。
嵌入模型
许多 RAG 平台会提供默认嵌入模型。如果你需要支持非英语语言，那么理解该嵌入模型对其他语言的支持情况，以及它在你所需语言上的表现，就非常重要。
一些 RAG 平台提供商支持 bring-your-own（BYO，自带）嵌入模型。这个功能会给你带来一些额外安心感，并降低未来风险：如果内置嵌入模型不适合未来某个使用场景，你可以直接替换为一个可能更合适的新嵌入模型。即便如此，也要记住，你已经为所有数据生成过嵌入向量；切换到新嵌入模型需要重新编码整个数据集，这会增加额外时间和成本。
正如你在第 2 章中学到的，嵌入模型有不同大小，也就是不同向量维度。更大的向量维度可能捕捉更细腻的语义细节，从整体上带来更高检索准确率。然而，这并不总是会对整体准确率产生同等显著影响，尤其是当检索第二步结合了强大的重排序模型时。关于重排序的详细讨论，见第 3 章“高级检索”。
从计算角度看，更高维度的向量处理成本更高。索引这些更大的向量需要更多计算能力和时间；在 DIY 设置中，这意味着要投资更强大的 CPU 或 GPU。查询也会变得更消耗资源，因为计算高维向量之间的相似度分数（例如余弦相似度）需要更多操作。这可能导致延迟增加，或需要更多计算实例来维持性能，从而增加运维成本。
在 RAG 平台中，内存需求或计算需求的增加由供应商承担，并通常反映在定价中。因此，如果 BYO 嵌入模型是一个要求，应询问供应商是否支持该选项，并确保理解这可能带来的额外成本。
向量数据库
当你构建自己的 RAG 技术栈时，可以选择 Milvus、Qdrant 或 Weaviate 这样的开源向量数据库，也可以选择 Pinecone 这样的专有向量数据库，或者使用 Snowflake、MongoDB 等现有数据库中内嵌的向量功能。无论使用哪一种，它通常都会让你对索引策略、分片、硬件或云基础设施选择进行细粒度控制，使你能够根据特定数据、查询模式和性能要求进行优化，同时更好地管理故障隔离。显然，这种控制伴随着设置、持续维护、扩展、安全补丁，以及对向量数据库管理内部专业能力的需求。即便软件是开源的，这些也可能转化为显著运维开销和隐藏成本。
这里一个重要考虑因素是嵌入模型的维度。更大的向量大小虽然可能捕捉更细腻的语义细节，但也可能带来更高存储需求，导致额外成本和更高延迟。对 DIY 技术栈而言，支持更高向量维度会显著影响存储和处理成本。
RAG 平台会将向量数据库作为托管服务的一部分打包，把向量数据库设置、配置、扩展、维护和优化的复杂性留给提供商。显然，更大向量对 RAG 平台成本也有影响，因此可能反映在它们的定价中。
如果你需要深度定制，并且拥有管理复杂数据库基础设施的工程人才，DIY 可能是一个不错选择。反过来，如果上市速度、易用性和卸载运维负担很重要，并且你可以接受提供商所选向量数据库的能力，那么 RAG 平台可能是一条更高效路线。
高级检索
正如我们已经多次提到的，健壮且准确的检索流水线，很可能是 RAG 中对准确结果影响最大的组件。当你构建 DIY RAG 技术栈时，通常会从向量搜索开始，也就是嵌入向量之间的余弦相似度，正如第 2 章所描述的那样；随后很快会用混合搜索以及一个或多个重排序选项来改进这个基线。除了性能之外，这条流水线也是一个关键安全边界；通过将提供给生成式 LLM 的上下文缩小到最相关且经过验证的数据，你可以显著降低幻觉和“跑偏”响应的风险。
当你构建自己的技术栈时，需要实现这条健壮检索流水线的每一个部分。一旦有了向量数据库并选定嵌入模型，向量搜索相对容易。然而，实现混合搜索和重排序器可能是更困难的任务，可能需要额外专业能力、时间和精力。但它很重要——这正是检索相关性和系统可靠性获得真正大幅提升的地方。
在考虑 DIY 与 RAG 平台时，要仔细查看 RAG 平台提供商所提供的检索能力，以及它们是否承诺持续在检索方面创新，并将其与你团队在构建和维护搜索技术方面的技能与专业能力进行比较。
提示词工程
DIY RAG 技术栈中的主要提示词工程工作，是你在把检索到的 chunks 发送给生成式 LLM 时使用的最终提示词。正如你在第 2 章和第 3 章看到的，这个提示词有两个关键目的。第一，它是指导 LLM 执行任务的主提示词：总结检索出的 chunks，并为用户查询提供连贯响应。第二，谨慎的提示词设计（以及持续更新）可以用于对抗提示词注入攻击，并有助于减少幻觉和偏见。
遗憾的是，不是所有 LLM 在提示词方面的行为都一样。有些 LLM 对提示词中的指令遵循得很好，而另一些并不总是遵循你的指令。因此，不要把提示词看成在 DIY RAG 技术栈中设置一次就可以遗忘的东西——随着新 LLM 可用，以及不同使用场景和应用出现，你可能需要调整它。
在这里，RAG 平台提供了显著战略收益。除了深厚的提示词工程专业能力，以及持续跟进 LLM 特定细微差别之外，这些平台还支持集中式提示词治理。在企业规模下，这可以防止不同团队之间出现不一致的安全姿态，并确保安全协议、幻觉检查和偏见缓解措施，在每个应用中被统一应用。
支持多个 LLM
使用 DIY RAG 技术栈时，你对调用哪个 LLM 拥有完全控制和灵活性。你可以使用 OpenAI、Anthropic 或 Google 等商业选项，也可以使用 Llama 4、Qwen、Kimi 或 DeepSeek 等开放权重模型。
为你的 RAG 系统选择正确的 LLM 看起来可能很容易，但这里有一个细微点需要考虑：LLM 的性能特征可能会随时间变化。也就是说，它们处理或响应各种输入的方式可能发生变化；例如，可以参考 GPT-4o sycophancy incident。如果你使用开放权重模型，那么必须自己在配有 GPU 的机器上托管它。
从这个角度看，RAG 平台提供商会成为你的可信合作伙伴，帮助你确定最适合应用使用的 LLM，承担测试各种 LLM 的负担，追踪它们不断变化的特征，并确保你的 RAG 应用正常工作，并端到端维持高质量生成响应。
在某些应用中，使用在行业特定数据集上微调过的 LLM 可能有益。使用 DIY RAG 时，你可以轻松实现这一点，并将 LLM 替换为自托管的微调版 LLM。使用 RAG 平台时，具备 BYO LLM 能力非常重要；如果你预期应用技术栈中会包含微调后的生成式 LLM，一定要与 RAG 平台提供商深入了解该能力。
幻觉检测和修正
正如我们在第 3 章“控制 RAG 中的幻觉”中讨论过的，幻觉检测和修正是 RAG 流程中的关键组件。
通过识别 LLM 返回的、与检索 chunks 中信息在事实上不一致的响应，并修正这些响应，你可以显著提升 RAG 应用的响应质量。
在考察 RAG 平台提供商时，务必确认其是否支持这项能力。如果你使用 DIY RAG 技术栈，则需要规划如何在技术栈中实现这些组件，并长期支持它们。
除了核心 RAG 能力之外，还必须考虑你的数据源，以及应用中的数据摄取会是什么样子。
数据源
许多 RAG 平台提供商支持越来越多数据源的数据连接器，例如电子邮件系统、Google Drive、SharePoint、Notion、Jira、Confluence、网页、内部文档、各种数据库系统、Salesforce，甚至 Box 或 Dropbox 文件。
如果你正在考虑 RAG 平台，应深入了解可用数据连接器，确保它们符合你的要求：
支持哪些文件格式？
连接器是否支持数据刷新？
错误处理如何管理？连接器能否暴露部分失败或数据缺口（例如被跳过的文件），以确保 LLM 不会基于不完整知识库工作？连接器能否从错误中优雅恢复？
连接器是否支持细粒度 RBAC 和实时权限同步，以防止数据泄漏，并确保用户只能检索自己有权查看的信息？
在你的 IT 环境中部署它容易还是困难？
有哪些日志和监控能力可以确保健壮且稳定的数据连接？
如果你使用 DIY RAG 技术栈，有三种方式处理外部数据：
自己构建并维护这些连接器，并在需要时添加新连接器。
使用 Airbyte 这样的开源数据连接器项目，或使用包含数据连接器的 LLM 编排框架，例如 LlamaIndex 或 LangChain。
使用 Airbyte Cloud、LlamaCloud 或类似商业解决方案。
无论采用哪种方式，都必须严肃审视应用所需的数据源，并考虑实现连接器的工作量——不仅是初始摄取，也包括数据刷新和更新。
表 5-1 对几个可用于 DIY RAG 的数据连接器项目进行了比较。虽然这仍在持续演化，新的连接器也在不断出现。
表 5-1 开源数据连接器项目
| 项目名称 | 连接器总数近似值 | 数据刷新支持 |
|---|---|---|
| LangChain | 130+ | 外部调度器 + 向量存储操作 |
| LlamaIndex | 160+ | LlamaCloud 支持增量更新 |
| Airbyte | 600+ | 内置增量同步（cursor、CDC）、调度、向量数据库目标处理 |
| Meltano | 600+ | 是，只要存在实现它的 Singer tap |
| Datavolo（Snowflake 的一部分） | 300+ | 是，基于 NiFi 的处理器支持真正的增量获取 |
如你所见，大多数提供商都内置了相当多数据源的连接器，数量从 130 到 600 不等。除了简单的数据源类型列表之外，理解每个连接器具体如何工作，以及它是否支持你拥有且需要摄取的具体数据，也非常重要。
例如，电子邮件连接器可能支持 Gmail，但不支持 Outlook。HubSpot 连接器可能只导入客户关系管理（CRM）系统的一部分。Jira 连接器可能只导入 tickets，而不导入它们的附件。
RAG 蔓延与集中式治理
构建 DIY RAG 虽然可以对 RAG 流水线提供完整细粒度控制，但也可能导致所谓 RAG sprawl——组织中出现大量彼此分散、独立管理的 RAG 应用。
每个这样的 RAG 应用可能都有自己的向量数据库选择，例如 Weaviate、Zilliz 等；自己的嵌入模型和生成式 LLM；以及不同的数据摄取流程实现。这很快会变成中央 IT 的噩梦，因为中央 IT 必须管理多种类型的 RAG 组件，每种都有自身复杂性，而且其中许多可能与组织政策不兼容。
从安全角度看，每个 DIY RAG 应用可能都有自己的访问控制、数据处理政策和安全配置实现，这会让统一执行安全措施和有效监控漏洞变得困难。这种碎片化会导致“policy drift”（策略漂移），即随着各个流水线在缺乏集中监督的情况下被更新或修改，安全和合规保障会随时间逐渐被侵蚀。
这种缺乏标准化可能会无意中导致保护级别不同的数据孤岛，增加数据泄露、未授权访问，以及违反 GDPR 或 California Consumer Privacy Act（CCPA）等法规的风险。
这正是 RAG 平台真正可能发光的地方，因为它通常提供一种集中化、标准化的方法来部署和管理 RAG 应用，包括以下服务：
管理 IT 资源，例如存储和计算，包括 CPU 和 GPU；
内置数据治理、可观测性、可审计性和发布流程机制；
安全功能，例如健壮的访问控制机制、加密协议和审计追踪。
这种在所有 RAG 应用中一致应用 IT 政策的能力，有助于避免 RAG 蔓延。
举例来说，考虑这样一个场景：市场部门构建了一个 RAG 应用，却无意中使用了不合规的向量数据库，并在没有适当 GDPR 掩码的情况下摄取了原始欧盟客户数据。与此同时，法务团队为合同审查构建了另一个独立 RAG 系统，使用不同且高度安全的 LLM。中央 IT 无法看见市场应用的合规风险，也无法执行统一的数据处理标准。RAG 平台通过提供一条预配置的“黄金路径”解决这个问题。它会强制使用已批准的向量存储，并自动对所有新应用应用 PII 脱敏规则，而不管应用是哪个部门构建的。
这种集中化也能防止资源重复并降低成本。在 RAG 蔓延环境中，数据科学团队可能为某个特定项目部署了一个大型且昂贵的嵌入模型。销售团队在不知情的情况下，可能随后在同一数据上为自己的聊天机器人部署完全相同的模型，从而使摄取成本翻倍。这种重复不仅限于数据；两个团队现在都在为单独存储付费，使用高需求 GPU/CPU 资源运行推理，并占用不同工程和 DevOps 团队进行升级和维护。
从纯安全角度看，这种整合至关重要。当 RAG 应用蔓延时，每个应用都会成为一个单独、孤立的目标，必须独立进行安全保护、监控和修补。漏洞扫描器甚至可能不知道法务团队新建了一个 RAG 应用。而基于平台的方法提供了一个单一且加固过的边界，供安全团队管理。它允许安全团队应用一致的基于角色访问控制，执行统一加密标准，并一次性在所有 RAG 应用上运行全面漏洞测试。如果某个共享组件中发现新漏洞，就可以在平台层面修补一次，立即保护每个使用该组件的应用，而不是到处寻找数十个孤立且有风险的部署。
直到今天，企业仍在努力避免“shadow IT”，也就是组织中某个部门或个人在 IT 或安全团队不知情的情况下使用 IT 相关硬件或软件；而现在，它们正更加努力地避免它的新化身：“shadow AI”。正如这些例子所展示的，根本挑战在于，shadow AI 的成本、合规和安全风险要高出几个数量级。
成本与维护
除了安全和治理之外，还要考虑在 DIY RAG 系统和 RAG 平台之间选择所带来的财务和运维影响。
DIY 方法通常是 RAG 旅程的第一步，因为团队会学习生成式 AI，并构建第一个原型，快速向组织展示价值，同时理解影响最大的使用场景。
如果只考虑直接订阅费用，也就是使用 LLM 的 token 成本，DIY 往往看起来更便宜。然而，如果不仔细监控和控制 API 使用，并持续优化，即使是直接 API 使用成本也可能快速膨胀。
不过，RAG 的真实成本包含更多内容。要获得更现实的图景，应考虑以下方面导致的成本：
底层基础设施的设置、配置和持续维护，例如向量数据库、LLM、嵌入模型、重排序器等；
每个 RAG 组件研究、设计和测试所需的大量时间；
维护基础设施、修补安全漏洞、更新模型和算法、重新设计提示词、改进检索流水线、控制幻觉缓解，以及随着使用量增长扩展基础设施所带来的持续运维负担。
这些责任需要一支具备专业技能的专门团队，代表着持续运营支出，也会消耗本可用于交付核心业务创新的内部资源。
相比之下，RAG 平台会把许多（虽然不是全部）持续维护和运维开销转移给供应商。这可以帮助将高且不可预测的 TCO 替换为更可预测的 TCO，通常采用以下两种不同定价模式之一：
面向开发者的消费模型
这类模型是为自下而上的采用设计的，具有免费层和较低的初始月度订阅费（50–500 美元），其中包含一组基础资源。不过，TCO 仍然是可变的，因为成本由细粒度的按需付费超额使用驱动。示例包括 Ragie.ai 和 LlamaCloud。
一体化企业模型
这类模型面向大型企业设计，并以 TCO 可预测性为定价目标（Vectara 是一个例子）。它们通常采用年度订阅，包含一个大型年度“credits”包——credits 是一种抽象价值单位，会将所有底层成本（API 调用、数据存储、计算和检索）打包成单一、可预测的指标。
无论定价是基于消费还是年度订阅，这些费用都覆盖更新、安全和平台演进。考虑到可扩展性和面向未来，RAG 平台提供了一条更顺畅路径，因为供应商有动力让平台保持在技术前沿，纳入 LLM、检索技术和安全实践方面的最新进展，让客户可以专注于自己的具体 RAG 使用场景。
部署选项
在考虑 RAG 技术栈的部署选项时，要记住：选择 SaaS 解决方案、更可定制的 VPC 部署，还是完全自管理的本地部署，会影响你对系统的控制程度、支持 SLA、责任边界和资源分配。
DIY RAG 部署选项
对于 DIY RAG 来说，很明显，你拥有很大灵活性，几乎可以部署到任何地方。限制来自组件本身。
例如，如果你的向量数据库是托管服务，而你需要一个本地部署的 RAG 系统，那么就需要选择另一个向量数据库并在本地部署。类似地，在本地环境中，由于政策可能禁止数据离开你的环境，你可能无法使用基于商业 API 的 LLM、嵌入模型或重排序器，而需要改用自托管 LLM。
RAG 平台部署选项
大多数 RAG 平台供应商只支持 SaaS 部署选项，在这种模式下，供应商管理整个技术栈，并直接向超大规模云提供商支付基础设施成本。不过，也有一些供应商支持 VPC 和本地部署选项。在 SaaS 模式中，许多 RAG 平台提供商会确保适当的安全和数据治理控制到位，以确保其 SaaS 产品符合 HIPAA（美国 Health Insurance Portability and Accountability Act）、GDPR（欧盟 General Data Protection Regulation）或 SOC-2（Service Organization Controls 2）。然而，你的组织可能要求对数据和环境拥有更大控制权，甚至要求“air-gapped”安装，即没有任何数据离开你的系统。如果是这种情况，SaaS 方法根本不可行。
将 RAG 平台部署在 AWS、Azure 或 Google Cloud 等公有云提供商的 VPC 中，可以确保 RAG 应用运行在云中的隔离网段内，从而允许对网络安全和数据隐私进行更细粒度控制。这种模型要求你的团队具备更多云架构和 MLOps 专业能力，以管理 RAG 应用及其云资源，通常适合已经实现其他云应用，或有可以在受控云环境中满足的合规要求的企业。
RAG 平台的本地部署代表最高控制等级，同时也意味着最大责任。将整个 RAG 技术栈，包括所有硬件和软件组件，托管在组织自有数据中心内，可以确保数据永远不会离开公司的物理边界。这种方法通常受到拥有高度敏感数据的公司青睐，例如金融服务公司或医疗公司，也适合具有严格监管义务或需要 air-gapped（无外部互联网连接）环境的组织。
虽然本地 RAG 提供最大安全性和低延迟访问，但它要求解决特定架构挑战：
硬件基础设施
（CAPEX 与 OPEX）：你用大量前期硬件投资替代 API 成本。高性能 RAG 需要企业级 GPU，例如 Nvidia A100/H100，并且需要足够 VRAM 将 LLM 权重保存在内存中。
本地模型推理
由于 air-gapped 环境阻止调用外部 API（例如 OpenAI），你无法使用商业 LLM。相反，你必须依赖开放权重模型或自托管模型，例如 Llama 4、Mistral、DeepSeek、gpt-oss，并管理本地推理服务器。受影响的不只是 LLM；标准摄取流水线通常依赖云端 OCR 或解析 API，而在本地部署中，你必须为每个步骤部署本地替代方案，包括嵌入模型、重排序器，以及面向图片或表格的多模态处理工具。
运维开销
你的团队要全面负责管理基础设施、修补 OS 安全漏洞、手动更新模型权重、管理容器编排（通常通过 Kubernetes），以及所有系统的日志记录和监控。
归根结底，在 SaaS、VPC 和本地 RAG 之间作出决定，取决于对组织优先事项的谨慎评估，包括数据安全、控制权、定制需求、可用技术能力、预算以及期望部署速度。这里没有一刀切答案；SaaS 优先考虑易用性和速度，本地部署优先考虑控制和数据隔离，而 VPC 提供灵活的中间路线。
为了提供一个完整 RAG 平台的示例，下一节我们来看 Vectara，回顾它的标准化 API，以便更好理解它的 API 如何帮助开发者控制数据摄取、查询参数化和幻觉缓解，并防止 RAG 蔓延。
示例 RAG 平台：Vectara
构建 RAG 的 DIY 方法，需要选择并集成每个组件，无论这些组件是开源的，例如 LlamaIndex、LangChain、Weaviate 等，还是托管服务，例如 Cohere、Pinecone、Gemini 和 OpenAI。
主要云服务提供商提供了介于 DIY 和平台之间的中间路线，例如 Amazon Bedrock Knowledge Bases、Google Cloud Vertex AI Search 和 Azure AI Search 这样的“服务平台”。它们是强大的工具包，可以简化 DIY，但仍然要求开发者选择、配置和编排多个组件，例如接入单独的向量数据库，或手动串联检索和生成 API 调用。
这与真正的端到端 RAG 平台形成对比，例如 Vectara 或 Nuclia。后者将所有组件（文档抽取、切分、嵌入、向量存储、检索、生成和幻觉检测）打包进一个统一 API 中，对开发者隐藏复杂性。这让开发者可以专注于构建自己的 RAG 应用，而不是管理 RAG 基础设施。
为了看到 RAG 平台如何实际工作，我们会通过代码演示这些原则。我们将使用 Vectara 作为示例平台，因为我们可以方便获取演示所需组件；不过，你也可以用 Nuclia 等其他选项做类似探索。
开始使用
要开始使用 Vectara，首先创建一个账户（图 5-2）。拥有账户后，就可以使用 Console，这是一个基于 Web 的界面，用于管理你的 Vectara 账户、corpora 和数据。
图 5-2 展示了 Vectara Console 界面，包括管理 corpora、查询数据和配置搜索参数的选项。
图 5-2 Vectara Console，可用于管理 Vectara 账户、创建 corpus、上传数据并尝试查询
在 Vectara 中，corpus 指的是你摄取的所有数据在经过预处理、清洗和组织以便查询之后所处的虚拟容器。每个 corpus 都是隔离的，允许你为不同应用拥有不同数据集。例如，你可能有一个 corpus 用于公司内部文档，另一个用于客户支持 tickets，第三个用于产品评论。
Vectara 中的 documents 是位于 corpus 中的单个信息单元，随后用于搜索和生成查询响应。
现在你已经理解这些基本术语，是时候创建一个 corpus 了（图 5-3）：
导航到 “Corpora” 部分，通常在左侧边栏。
点击 “Create corpus”。
系统会提示你提供以下信息：
Name
你的 corpus 的用户友好名称。
Key（corpus key）
用于 API 请求的唯一 corpus 标识符。
Description（可选）
你想用于解释 corpus 内容或用途的任何文本。
Embedding model
选择用于向量化数据的模型。在这个例子中，请选择 “Boomerang”，也就是 Vectara 内置嵌入模型。
Filter attributes（可选但推荐）
定义你打算用于过滤的元数据字段。你需要指定属性名称、数据类型（text、integer、boolean、real），以及它适用于文档级别（doc）还是文档部分级别（part）。你还可以选择是否为其建立索引，以加速过滤。
创建之后，corpus 就准备好接收数据了。
图 5-3 展示了 Vectara Console 中的 “Create corpus” 页面，包含输入名称和 key 的字段，以及配置 corpus 的选项。
图 5-3 Vectara Console 中的 “Create corpus” 页面
在你真正使用 API 操作 corpus 之前，需要创建一个 Vectara API key。Vectara 中有三类 API key：
Personal API key
该 key 对你的 Vectara 账户中的任何 API 操作提供完整权限。
Query-only API key
顾名思义，该 key 只提供对 corpus 的查询访问权限。
Query+index API key
这种 key 同时提供索引数据（直接索引或通过文件上传）和查询 corpus 的权限。
对于下面所有示例，我们会使用 corpus key “RAGBOOK”，并假设你已经在代码示例中创建了 query+index API key 或 personal API key。
注意
Vectara 也支持通过 OAuth 2.0 访问所有 API 功能（而不是通过 API key），但深入讨论这一点超出了本书范围。如果你有兴趣了解更多，可以查看文档页面。
将数据摄取进 Vectara
现在我们已经准备好一个 corpus，下面看看 Vectara 提供哪些上传和索引数据的选项。
文件上传
我们从文件上传开始：你可以使用 upload_file endpoint 将各种类型的文件上传进 Vectara，例如 PDF、Word、PPT、HTML、Markdown 或文本。下面是一个示例：
import requests
import os
corpus_key = "RAGBOOK"
api_key = os.getenv("VECTARA_API_KEY")
url = f"https://api.vectara.io/v2/corpora/{corpus_key}/upload_file"
payload={}
files=[
('file',
( 'pet_policy',
open('pet_policy.pdf','rb'),
'application/octet-stream')
)
]
headers = {
'Accept': 'application/json',
'x-api-key': api_key
}
response = requests.request(
"POST",
url,
headers=headers,
data=payload,
files=files
)
res = response.json()
print(res)
API 响应提供了关于文件上传操作的有用信息：
{
'id': 'pet_policy',
'metadata': {
'Producer': 'Skia/PDF m118 Google Docs Renderer',
'Title': 'Employee Handbook - Company Pet Policy'
},
'storage_usage': {'bytes_used': 9215, 'metadata_bytes_used': 5803}
}
背后发生的是：
Vectara 接收了文件内容。在这个例子中，它是一个 PDF 文件，因此 Vectara 从文件中抽取了实际文本。
这些文本使用 Vectara 默认切分策略进行了切分，该策略称为“sentence chunking”。
Vectara 的 Boomerang 嵌入模型被应用到每个 chunk 上，生成向量嵌入。这些向量被存储进 Vectara 内部向量数据库。每个 chunk 的文本（如果有元数据，也包含元数据）会与向量嵌入一起，存储在单独文本数据库中，该数据库是 Vectara RAG 技术栈的一部分。
这个过程展示了平台的抽象能力：文本抽取、多模态处理、切分、嵌入和向量存储管理的全部复杂性，都由平台处理。这种方法是 RAG 平台的共同目标：无论规模如何，都通过 API 提供一致的开发者体验。
通过文件上传，你可以使用可选参数选择额外能力，例如：
选择应用到文件的切分策略：sentence 或 fixed chunking。
启用文件中的表格抽取或图片抽取，确保上传文档中嵌入的表格或图片能够在 RAG 流水线中被正确处理。
给文档附加元数据字段。例如，在 PDF 文档中，你可能想把作者名称或创建日期作为元数据字段附加上去。
这种通过 API 参数定制摄取流程的能力，体现了我们在任何 RAG 平台中都会看到的特点：平台中已经存在许多能力，你通过配置 API 调用参数来选择使用哪一种；这与 DIY 形成对比，在 DIY 中你必须自己构建和维护每一项能力。
直接数据摄取
除了文件上传之外，你还可以直接将文本数据摄取进 Vectara。这适用于那些并非来自单个文件的数据，而是来自数据库，或 Notion、Jira、Confluence、Salesforce、Slack 等其他来源的数据。
下面是如何直接把文本摄取进 Vectara 的示例：
import requests
import json
import os
corpus_key = "RAGBOOK"
api_key = os.getenv("VECTARA_API_KEY")
url = f"https://api.vectara.io/v2/corpora/{corpus_key}/documents"
payload = json.dumps({
"id": "selected-works-of-shakespeare",
"type": "structured",
"title": "William Shakespeare, Greatest Hits",
"metadata": {
"timespan": "26 April 1564---23 April 1616",
"stars": 5,
"author": "William Shakespeare"
},
"sections": [
{
"title": "King Lear",
"text": """Synopsis: King Lear, intending to divide his power and kingdom
among his three daughters, demands public professions of their love. His
youngest daughter, ...""",
"sections": [
{
"title": "Act I",
"text": """KENT: I thought the king had more affected the Duke of
Albany than Cornwall.\nGLOUCESTER: It did always seem so to us...""",
"metadata": {
"stage-instructions": "Enter KENT, GLOUCESTER, and EDMUND"
}
},
{
"title": "Act II",
"text": "EDMUND: Save thee, Curan. ...",
"metadata": {
"stage-instructions": "Enter EDMUND, and CURAN meets him"
}
}
]
},
{
"title": "Antony and Cleopatra",
"text": """PHILO: Nay, but this dotage of our general's\nO'erflows the
measure: those his goodly eyes, ..."""
}
]
})
headers = {
'Content-Type': 'application/json',
'Accept': 'application/json',
'x-api-key': api_key
}
response = requests.request("POST", url, headers=headers, data=payload)
res = response.json()
print(res)
响应是：
{
'id': 'selected-works-of-shakespeare',
'metadata': {
'timespan': '26 April 1564---23 April 1616', 'stars': 5,
'author': 'William Shakespeare'
},
'storage_usage': {'bytes_used': 468, 'metadata_bytes_used': 1005}
}
在这个例子中，我们摄取了一些来自《李尔王》的文本。如代码所示，我们添加了一些文档级元数据，文本本身则被拆分成 sections。注意 sections 也可以嵌套，以支持数据源中文本的复杂表示，并且我们也可以为每个 section 添加元数据。
现在，我们的 Vectara corpus 中已经有了一些数据，下面看看如何使用 API 执行查询。
运行查询
你可能还记得，第 1 章描述过的查询流程包括：让查询经过完整检索流水线处理，其中可能包括向量搜索、混合搜索和重排序；然后构造一个包含被检索 chunks 作为上下文的提示词，并调用生成式 LLM 生成响应；最后一步是幻觉检测和修正。
和数据摄取一样，RAG 平台 API 会简化查询过程，通常简化为一个 API 调用。在 Vectara 中，它看起来如下：
url = f"https://api.vectara.io/v2/corpora/RAGBOOK/query"
query_str = "Are pets allowed in the office?"
payload = json.dumps({
"query": query_str,
"search": {
"lexical_interpolation": 0.025,
"offset": 0,
"limit": 50,
"context_configuration": {
"sentences_before": 2,
"sentences_after": 2
},
"reranker": {
"type": "customer_reranker",
"reranker_name": "Rerank_Multilingual_v1"
}
},
"generation": {
"max_used_search_results": 7,
"response_language": "eng",
"prompt_name": "vectara-summary-ext-24-05-med-omni",
"enable_factual_consistency_score": True
}
})
headers = {
'Content-Type': 'application/json',
'Accept': 'application/json',
'x-api-key': api_key
}
response = requests.request("POST", url, headers=headers, data=payload)
res = response.json()
Search_results = res['search_results'])
print(res['summary'])
print(f"Factual Consistency Score: {res['factual_consistency_score']}")
输出是：
Pets are allowed in the office at Vectara, but with specific guidelines. Birds
are permitted and even encouraged in the workspace, although there are
particular rules to follow [2]. However, common household pets like cats and
dogs are not allowed on Vectara campuses [7].
Factual Consistency Score: 0.77734375
这里，我们输出了 summary 和 factual consistency score（也就是幻觉分数）。当然，res 变量包含完整的被检索 chunks；这里只是没有打印出来，因为它会占据多页内容。
注意上面的例子，虽然隐藏了大量细节，但查询 API 仍然允许相当多的灵活性和控制：
lexical_interpolation 决定是否启用混合搜索，以及使用哪个插值值。
选择使用哪个重排序器。
选择 generation_preset_name，它决定生成式 LLM 和提示词。
决定将多少搜索结果（chunks）发送给生成式 LLM，也就是 max_used_search_results。
还有一个参数没有在上面的例子中使用：stream_response。当它设置为 true 时，Vectara 响应会以“流式”方式返回生成响应，而不是以单个文本字符串返回。这使你的应用用户界面能够在响应逐词生成时显示查询响应，而不是等待最终响应一次性显示出来。
在第 3 章中，我们提到不仅可以检测幻觉，还可以修正幻觉。在上面的查询调用中，你已经看到 Vectara 查询调用会随每个响应返回 factual consistency score，帮助你检测可能包含幻觉的响应。接下来，我们看 Vectara 另一个用于修正幻觉的 API 选项。
幻觉修正
通过 Vectara 的 correct_hallucinations API endpoint，你可以修正查询流程中检测到的幻觉。
让我们看看它如何工作：
url=f"https://api.vectara.io/v2/hallucination_correctors/correct_hallucinations"
payload = json.dumps({
"generated_text": hallucinated_response,
"documents": [
{"text": r["text"]}
for r in search_results
],
"model": "vhc-large-1.0"
})
headers = {
'Content-Type': 'application/json',
'Accept': 'application/json',
'x-api-key': api_key
}
response = requests.request("POST", url, headers=headers, data=payload)
res = response.json()
print(hallucinated_response)
print(res['corrected_text'])
我们得到：
Pets are allowed in the office at Vectara, but with specific guidelines.
Birds are permitted and even encouraged in the workspace, but there are no rules
to follow [2]. However, common household pets like cats and snakes are not
allowed on the Vectara campuses [7].
Pets are allowed in the office at Vectara, but with specific guidelines.
Birds are permitted and even encouraged in the workspace, but there are specific
guidelines to follow. However, common household pets like cats and dogs are not
allowed on the Vectara campuses.
可以看到，错误事实（“no rules” 和 “snakes”，原文中以红色高亮）被基于原始文本正确修正了。
我们也可以显示导致修正文本的实际 corrections：
print(res['corrections'])
结果为：
[{'original_text': 'Birds are permitted and even encouraged in the workspace,
but there are no rules to follow [2].',
'corrected_text': 'Birds are permitted and even encouraged in the workspace,
but there are specific guidelines to follow.',
'explanation': 'The source states that birds are permitted and encouraged, but
also explicitly mentions that there are specific guidelines and peculiarities
to the policy. The response incorrectly claims there are no rules to follow,
which is contradicted by the source.'},
{'original_text': 'common household pets like cats and snakes are not allowed
on the Vectara campuses [7].',
'corrected_text': 'common household pets like cats and dogs are not allowed on
the Vectara campuses.',
'explanation': 'The source specifies that cats and dogs are not allowed, but
does not mention snakes as common household pets or as being specifically
banned. The response adds "snakes" without support from the source.'}]
这个拆解很有用，因为它展示了原始文本中的具体片段，并针对每个片段展示了具体修正以及修正解释。
接下来，我们看一些其他 Vectara API 调用，可用于检索文档完整内容或文档摘要。
其他 RAG 管理 API Endpoints
虽然 ingest/upload 和 query 是最常用的 API endpoints，但 Vectara 还包含许多用于管理的 API endpoints。例如：
Corpora
列出所有 corpora、创建 corpus、删除 corpus。
Documents
列出所有文档；删除文档；检索文档全文或摘要。
API keys
列出 API keys，创建和删除 API keys。
用户管理
在账户中创建用户，并指定其权限。列出所有用户，删除用户，以及为用户重置密码。
查询历史
查看查询历史，以及与账户相关的其他分析信息。
例如，下面是列出 corpus 中所有文档的方法：
url = f"https://api.vectara.io/v2/corpora/RAGBOOK/documents"
headers = {
'Content-Type': 'application/json',
'Accept': 'application/json',
'x-api-key': api_key
}
response = requests.request("GET", url, headers=headers)
res = response.json()
res
结果为：
{'documents': [{'id': 'pet_policy',
'metadata': {'Producer': 'Skia/PDF m118 Google Docs Renderer',
'Title': 'Employee Handbook - Company Pet Policy',
'title': 'Employee Handbook - Company Pet Policy'}},
{'id': 'selected-works-of-shakespeare',
'metadata': {'timespan': '26 April 1564---23 April 1616',
'stars': 5,
'author': 'William Shakespeare',
'title': 'William Shakespeare, Greatest Hits'}}],
'metadata': {'page_key': ''}}
正如预期，我们看到两个文档，一个来自通过文件上传操作摄取的 pet_policy.pdf 文档，另一个是通过索引操作作为文本摄取的文档。
选择 RAG 平台时，重要的是确保该平台存在类似 API endpoints，以支持自动化各种管理任务。这让中央 IT 能够更好地管理多个 RAG 应用，理解摄取和查询活动，在用户加入和离开组织时管理用户，并在组织内所有 RAG 应用上自动化重要 IT 任务。
总结
在本章中，我们讨论了 RAG 平台相较于 DIY 方法的优缺点。你已经看到，DIY RAG 提供最大灵活性和控制力，但代价是时间和精力——不仅体现在初始实现上，也体现在持续维护、升级和 DevOps 支持上，同时还包括由各类供应商带来的直接成本。如果你选择 DIY RAG，那么考虑总体拥有成本非常有价值。
如果你拥有不止一个 RAG 应用，DIY 方法还可能导致 RAG 蔓延，带来额外成本和重复劳动。由于 RAG 平台能够防止 RAG 蔓延，并使组织可以拥有一个面向所有 RAG 应用的中央平台，因此它们作为替代方案正在持续演进，并变得越来越有吸引力。
这与数据库世界并不不同——如今，几乎没有人还在构建自己的专用数据库系统。相反，他们会与 Oracle、Microsoft、Databricks 或 Snowflake 这样的数据库供应商合作，专注于使用数据库的应用层，并向提供商支付数据库许可证费用，让提供商处理数据库复杂性。这种专业分工让开发团队能够专注于核心业务逻辑——也就是创造独特价值的应用——而不是重新发明数据库查询优化器这种深而复杂的工程。类似的专业分工现在正在 RAG 中出现，使团队能够构建强大的 RAG 应用，而不必先成为托管 LLM、向量搜索、重排序、切分策略、多模态数据处理和嵌入模型方面的专家。
无论你是构建 DIY RAG 技术栈，还是使用 RAG 平台，最重要的事情之一都是衡量检索和 LLM 响应质量——不仅是在初始上线时，也要随着时间持续衡量。在下一章中，我们将讨论 RAG 评估这一重要问题。
