RAG 平台 — build vs buy 的完整算账
这一章讲三件事: 「自建还是买平台」这笔账的正确算法; 很多团队各自自建之后会出现的「RAG sprawl」治理危机; 以及一个真实平台的 API 走查——看看「平台」两个字具体意味着什么。 注意先交代利益相关:本章的演示平台 Vectara 是本书作者创立的公司。 内容本身如实可靠,但「选平台」的结论请把这一点读进去。
1. 顶层全景:平台到底把什么藏起来了
RAG 平台(书里也叫 RAG-as-a-service、turnkey 平台)把前几章讲的 大部分组件——嵌入、向量库、混合搜索、重排、护栏、幻觉检测—— 藏到一个开发者 API 后面。你只管两件事:响应基于什么数据、 怎么接进你的业务流程1。
DIY: 你 → 选嵌入模型 → 选向量库 → 搭检索 → 搭重排 → 写 prompt → 接护栏 → 接幻觉检测
每一步:选型、集成、供给、扩缩、打补丁、监控——全是你的
平台: 你 → upload_file(文档) / query(问题)
其余全部:平台的
图说:本章主走查:同一份《宠物政策》PDF,在平台上从上传到带幻觉分的答案,
一共几次 API 调用。
公平的对照不是「自由 vs 不自由」,而是:DIY 的逐组件控制, 同时意味着供给、集成、扩缩、维护全是你的责任2; 平台的代价则是锁定(lock-in)与迁移成本3。
2. 核心原理(一):逐组件对照
书里把平台该有什么、DIY 里对应什么,逐组件过了一遍。挑三件最承重的:
检索管线是「最 impactful 的组件」。 而且它还有一层少有人提的身份: 安全边界——只把最相关、已验证的数据交给负责生成的 LLM,本身就是降幻觉、 防跑偏的第一道闸4。
prompt 治理。 DIY 里,每次换模型都要重调 prompt;平台把 prompt 变成 中央治理的资产——一个企业级统一的口径与安全姿态5。
多 LLM 支持。 模型行为会随时间漂移——书里举了 GPT-4o 的「sycophancy incident」(谄媚事件:某次更新后模型变得过度附和用户,厂商回滚)为例。 平台替你持续测试跟踪各家模型的行为变化;要自带模型(BYO LLM)或微调模型, 要先确认平台支持6。
嵌入与向量库两条也值得记住:平台一般内置嵌入模型,允许自带嵌入(BYO) 是未来风险的缓冲——但换嵌入模型意味着全库数据重新编码7; 向量库在 DIY 侧的自由(开源 Milvus/Qdrant/Weaviate,或 Snowflake/MongoDB 内嵌) 永远绑着同一句:控制 = 责任8。
3. 核心原理(二):连接器——平台差距最实在的地方
第 07 章讲了摄入管线多难建;而它的上游还有一层:数据从哪来。 企业的数据散在邮件、Google Drive、SharePoint、Notion、Jira、Confluence、 Salesforce、Box、Dropbox 里,每个源都要一个连接器(connector—— 负责从某个系统把数据持续抽出来的组件)9。
评估连接器,书里给了六问:支持什么格式?刷新机制?错误处理 (部分失败、跳过的文件要可见)?RBAC 与权限同步是不是实时?部署难度? 日志监控?10
数量是平台间的真实差距:LangChain 130+ 连接器,LlamaIndex 160+, Airbyte 600+(内置增量同步与 CDC),Meltano 600+,Datavolo 300+11。 但数量之外有个坑:同一个连接器名下,能力可能不齐——某家的 Gmail 连接器能用、Outlook 不行;Jira 连接器只导工单不导附件12。
4. 核心原理(三):RAG sprawl——各自为政的代价
这是本章治理浓度最高的一节。RAG sprawl:公司里每个团队各自选向量库、 嵌入模型、LLM,各自搭一套13。三个后果:
- policy drift(策略漂移):安全与合规保证,随各管线各自的修改慢慢侵蚀 ——营销团队用了不合规的向量库存未脱敏的欧盟客户数据,法务另建一套;
- 重复建设:两个团队在同一批数据上部署同一个大嵌入模型,摄入成本翻倍;
- 安全孤岛:每个 DIY 应用都是一座要单独防护的孤岛;平台是单一加固边界, 共享组件的漏洞一处修补、全体受益。
作者给这个现象找了个历史对应物:shadow IT(员工绕过 IT 部门自建系统) 的新化身「shadow AI」,风险大了一个数量级14。 平台的治理答案是「golden path」(黄金路径):统一批准的向量库、 自动 PII 脱敏、统一的权限模型——让「走正道」成为阻力最小的路15。
5. 核心原理(四):部署选项是一条责任光谱
| 选项 | 谁管什么 | 适合 |
|---|---|---|
| SaaS(软件即服务:直接用厂商托管好的在线服务) | 厂商管全栈 | 多数平台只支持这个;最快上线 |
| VPC(虚拟私有云) | 平台跑在你云账户的隔离段里 | 要更多网络与数据控制 |
| on-premises(本地部署) | 全是你的:GPU、推理服务器、开源模型、OCR 的本地替代、编排、补丁 | air-gapped(物理断网)、数据绝不出域16 |
云端三巨头的产品(Bedrock Knowledge Bases、Vertex AI Search、Azure AI Search) 是中间态:它们是「服务平台」,你仍要自己接组件;真正的端到端平台 (Vectara、Nuclia)给出单一统一 API17。
6. 主走查:宠物政策 PDF 的平台之旅
书里用 Vectara 的真实 API 走了一遍,逐步看18:
① 建 corpus(语料容器:一组摄入数据的隔离空间,不同应用用不同 corpus)
→ 拿到 corpus key;选平台内置的嵌入模型(Boomerang)
② 申请 API key:三种——personal(全权)/ query-only(只能查)/
query+index(可查可写)——权限在 key 层面就分开了
③ upload_file("pet_policy.pdf")
→ 平台幕后做四步:抽文本 → 按句子切块(默认策略) → 嵌入入库 →
文本存独立文本库;响应里带回元数据(Producer: Skia/PDF m118…)
与 storage_usage(9215 bytes)
④ query:「Are pets allowed in the office?」
一次调用里带的参数(都是「用参数选能力」):
lexical_interpolation=0.025 ← 打开混合搜索并设定词法权重
limit=50 ← 第一段取 50 个候选
context: sentences_before/after=2 ← 每个命中块前后各带 2 句
reranker=Rerank_Multilingual_v1 ← 打开重排
generation: max_used_search_results=7, enable_factual_consistency_score
→ 返回:摘要(鸟可以且受鼓励但有守则;猫狗不许)
+ Factual Consistency Score = 0.77734375(有据一致性分)
⑤ 幻觉纠正:correct_hallucinations 端点,输入生成文本+检索文档
→ 返回逐处的 original/corrected/explanation
⑥ 管理 API:列语料、列文档、管 key、管用户、查查询历史——
中央 IT 靠它们做自动化治理
把这六次调用和第 09 章那五关对照着看,平台的本质就清楚了: 那些组件的能力全都存在,你只是用 API 参数选择它们—— 而不是自己把它们建出来19。
7. 作者的判断与证据
- 「检索管线是最 impactful 的组件」「平台是中央控制面」是作者的架构判断, 与第 08 章的技术内容前后一致;
- 平台定价两档(按量付费的开发者档 $50-500/月、企业年订阅)是写作时点的 市场快照20;
- 全书最重的一个类比出现在本章结尾,值得记住:今天没有人自建数据库引擎, 都用 Oracle/Microsoft/Databricks/Snowflake,专注应用层——RAG 正在发生 同样的专业化分工21。这是作者的立场陈述,也是他的商业主张, 两者在本章完全重合——读时请记得第 1 节交代过的利益相关。
8. 边界与局限
- 本章是全书利益相关最浓的一章:平台例全部来自作者自家产品。 对照其他平台时,请自己补一手调研;
- 「平台=单一问责点」在出事故时也可能变成「单一甩锅点」——SLA 条款 比架构图更重要,书里没有展开合同面;
- 锁定成本只有定性描述,没有迁移的实测数据;
- BYO 嵌入/LLM 的支持度随平台快速变化。
9. 可带走的
- build vs buy 的正确算法:DIY 的真实成本 = 基础设施维护 + 研究设计测试 + 持续运维,不只是 token 费;
- 检索管线同时是安全边界——这是它「最 impactful」的第二层含义;
- 连接器看六问,不看数量;同名连接器能力可能不齐;
- RAG sprawl 三害:策略漂移、重复建设、安全孤岛;golden path 让守规矩成为阻力最小的路;
- 部署是责任光谱:SaaS → VPC → on-prem,控制与负担同步递增;
- 平台的本质 = 能力已存在,用 API 参数选择;API key 分级(personal/query-only/query+index)是权限设计的现成参考;
- 数据库类比:专业化分工的浪潮轮到 RAG 了——这是作者的判断,带着他的商业立场。
10. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 平台定义 | Chapter 5 | text/60-ch05-chapter-5-the-rag-platform.txt:9(搜「RAG-as-a-service」) |
| DIY vs 平台、锁定 | Chapter 5 | text/60-ch05-chapter-5-the-rag-platform.txt:19(搜「granular control over each component」) · :37(搜「lock-in」) |
| 检索=安全边界 | Chapter 5 | text/60-ch05-chapter-5-the-rag-platform.txt:100(搜「critical safety boundary」) |
| sycophancy 事件 | Chapter 5 | text/60-ch05-chapter-5-the-rag-platform.txt:133(搜「sycophancy」) |
| 向量库「控制=责任」 | Chapter 5 | text/60-ch05-chapter-5-the-rag-platform.txt:82(搜「Snowflake」) |
| 连接器六问与数量 | Chapter 5 | text/60-ch05-chapter-5-the-rag-platform.txt:223(搜「Airbyte」) · :253(搜「LangChain」) |
| 连接器名实不齐 | Chapter 5 | text/60-ch05-chapter-5-the-rag-platform.txt:287(搜「Jira」) |
| RAG sprawl、shadow AI、golden path | Chapter 5 | text/60-ch05-chapter-5-the-rag-platform.txt:302(搜「policy drift」) · :334(搜「golden path」) · :343(搜「shadow AI」) |
| 部署选项 | Chapter 5 | text/60-ch05-chapter-5-the-rag-platform.txt:413(搜「VPC」) · :432(搜「air-gapped」) |
| 平台走查 | Chapter 5 | text/60-ch05-chapter-5-the-rag-platform.txt:501(搜「corpus」) · :620(搜「pet_policy」) · :811(搜「lexical_interpolation」) · :850(搜「0.77734375」) · :895(搜「correct_hallucinations」) |
| 数据库类比 | Chapter 5 | text/60-ch05-chapter-5-the-rag-platform.txt:1053(搜「Oracle」) |