跳到主要内容

上生产 — 延迟、安全、成本与那张 KPI 表

这一章讲三件事: 「答得不好」在生产环境里到底是哪四种病; 延迟、安全、成本这三座非 AI 的大山各长什么样; 以及「上线」怎么从一句口号变成一张写满数字的需求表。 原书第 4 章刻意不给端到端代码——生产 RAG 是分布式系统, 依赖的是特定环境的基础设施,一个 notebook 装不下。我们照它的口径讲设计。

1. 顶层全景:为什么「好玩」和「敢用」是两回事​

POC 阶段,一个好模型 + 指向文档 + 向量相似度,就能答出题。 书里把话说得很直:如果目标是可扩展、安全、快、承载关键业务—— 那完全是另一回事1。

而且这一章的内容有一大半你看着眼熟:高可用、负载均衡、容器、密钥管理、 持续集成——生产 RAG 的大头是通用软件工程,不是 AI。本书只聚焦 RAG 特有的部分,这一章的主走查,就是把一个 POC 系统按五个关卡逐关改造: 质量、延迟、安全、厂商与团队、成本,最后落成一张 KPI 表。

2. 核心原理(一):「答得不好」的四种病​

用户不信任就流失,应用等于不存在2。书里把响应质量问题拆成四个病因, 每个的修法完全不同——这就是第 11 章失败分类学的预演:

病因典型样子修法
① 库里没有相关数据问「Nvidia vs SambaNova 的风险对比」:SambaNova 是私企,库里零公开文件,检索照样检回不相关的事实,模型照样生成3补数据,但要走 staging(预发布)流程:新进的数据先入暂存集,自动检索测试通过才推入生产索引4
② 检索管线弱文档多了匹配变难第 08 章的两段管线(混合搜索 + 重排)
③ 模型幻觉检索事实不完整时,模型会「gap-filling」——拿参数里的印象把缺口补上;生成的文本部分有据,不是真假二元,而是一条光谱5第 08 章的检测与纠正
④ prompt 没调好缺「不知道就说不知道」这类退路指令第 06 章的模板经验 + 跨大量查询测试

注意病因①:系统任何组件都没坏,它照样给出坏答案。 这就是书里反复说的「garbage in, garbage out」—— 也是为什么「补数据」这件事不能直接往线上库里倒,要有质检门4。

3. 核心原理(二):延迟——先给预算,再谈优化​

书里给了明确的数字预算6:

段预算
检索段(向量 + 混合 + 重排)平均 ≤ 300 毫秒
生成段(小模型)2-3 秒
生成段(顶级前沿模型)5-10 秒,reasoning 模型更高
幻觉检测/纠正再加

参照物:公开版 ChatGPT 级别的端到端体验就是几秒;也就是说, 检索段的 300 毫秒只是总预算的零头,生成才是大头。而且只看平均不够, 要控尾部延迟(P95——95% 的请求快于这个值,剩下 5% 再慢也在此限内), 复杂查询最容易在尾部爆掉7。

主走查第 ② 关:延迟怎么压下去​

书里给的手段按层次排8:

  ① 架构并行化:微服务解耦,一个轻量的 orchestrator(编排器,管分发与汇总)
     同时把查询扇出(fan-out)给向量库与词法搜索——
     检索延迟 = 最慢那一路的时间,而不是两路之和;
     每个服务按自己的瓶颈独立扩缩(编排器吃 CPU、向量库吃 I/O、LLM 吃 GPU)
  ② 换小模型:POC 用前沿模型图省事,生产可换小快模型——
     但必须跑第 11 章的评测确认质量没掉
  ③ 推理服务器:vLLM / TensorRT-LLM / TGI,
     核心是 continuous batching(连续批处理:把并发请求的生成拼在一起算)
     与 paged attention(分页注意力:长上下文下省显存的管理术)。
     书里原话:「这一软件层没有商量余地(non-negotiable)」
  ④ 缓存(见下)

缓存四层,与它的天敌​

缓存(把算过的结果存起来,下次直接取)在 RAG 里有四个可以放的位置9:

层存什么命中条件
响应缓存最终答案同一个查询原样再来
检索缓存查询的向量 → 块列表同一查询
块缓存块 ID → 块文本省掉后端存储调用
语义缓存相似查询的答案「How do I reset my password?」与「I need to change my password」字面不同,但嵌入后足够近(书例阈值 0.85)就算命中

第四层最值钱:自然语言里同一个问题几乎不会逐字重复。 而缓存的天敌是失效(invalidation):答案对应的文档改了,缓存里的旧答案 就必须清掉。只靠 TTL(存活时间)到期是被动挨打;书里的做法是摄入管线发事件 (消息队列广播「这份文档更新了」),缓存服务订阅(登记收听某类消息的)事件、主动清掉相关条目10。

4. 核心原理(三):安全与隐私是三个攻击面的纵深防御​

书里把防线画在三层:摄入层、存储层、生成层11。挑最承重的三件讲。

第一件:PII 脱敏分三档,档位决定可用性。 PII(personally identifiable information,个人身份信息)处理不是「打码」一个词能打发的12:

  原文:「Dr. Smith prescribed Tylenol to Forrest」(Smith 医生给 Forrest 开了泰诺)

  档一 masking(遮盖)/nulling(删除):
      「XXXX prescribed YYYY to ZZZZ」
      → 谁也答不了「医生给某人开了什么药」——上下文关系全灭
  档三 entity-aware redaction(实体感知脱敏,typed masking):
      「[DOCTOR_NAME] prescribed [MEDICATION] to [PATIENT_NAME]」
      → 隐私隐去了,语义结构还在,查询仍然可用

书里用 Microsoft Presidio 做了演示:Analyzer 引擎识别「人名/电话号码」, Anonymizer 引擎替换成 <PERSON> <PHONE_NUMBER> 这类类型标签13。

第二件:权限必须在查询流里执行。 只把「这位用户有权看的数据」传给模型, 前提是全库文档在摄入时挂上了一致的权限元数据14。

第三件:发给外部 LLM 的数据本身就是泄漏面。 公网 API 提供商可能记录、 缓存你的请求;脱敏后的模式仍可能泄信息。高敏感数据的答案是私有化部署开源模型 (gpt-oss、Llama、Qwen、DeepSeek 都是写作时的候选)15。

5. 核心原理(四):厂商、团队与 TCO​

厂商混乱​

自己拼装 RAG,意味着逐个集成:内容提取、表格图像解析、高级检索、幻觉检测、 安全合规、知识图谱——书里给了一张集成复杂度(集成一个组件有多麻烦的程度)检查表(API 形态、限流、批处理、 数据格式转换、加密与合规认证、P95/P99 延迟与违约罚则、监控、支持)16。 最痛的一行是:出了 bug 时,你成了多个厂商支持团队之间的协调员—— turnkey(交钥匙)平台的价值就是单一问责点17。第 10 章专讲平台。

团队:四个技能桶​

RAG 处在机器学习、软件工程、领域知识的交叉口。书里列了四个技能桶: ML 工程、数据工程、DevOps/MLOps、安全合规18。规模感:书里提到大型金融机构 识别出多达 400 个生成式 AI 用例;成熟企业头两年至少能找出 30 个 有显著价值的19。

TCO:那个 3-5 倍的经验数​

书里最关键的财务经验值得原样记住:「DIY RAG 的初始成本估算出了名地不可靠, 实际生产开支常超预算 3-5 倍」20。参照物:第 07 章那笔 $4,916/月的账, 只是「理想运行」口径,不含厂商管理、安全、灾备、多区部署这些间接成本。

两个控制手段:

  • 预算告警 + 限流:月预算 50%/80%/100% 阈值告警;限流同时防故障放大和 「denial-of-wallet」(钱包拒绝服务——恶意用户刷爆你的 API 账单)21;
  • 级联模型(cascading model):路由器先发给小快便宜的模型, 置信度够就直接返回,复杂或失败才升级到贵的前沿模型22。

6. 核心原理(五):把「上线」写成数字​

POC 复盘之后,书里要求把生产目标写成一张 KPI 表。下面是从书里那张表 (Table 4-2,作者注明数据来自其平台客户经验)摘的几行,看的是口径23:

维度POC 实测生产目标
查询延迟(50 条样本的均值/中位)7.5s / 8.5s4.5s / 4s
可用性未测≥ 99.99%(一年停机不超过约 53 分钟)
幻觉率—≤ 0.05(5%)
检索仅向量向量 + 混合 + 相关性重排 + 多样性重排
切块固定固定 + 语义
数据源本地 PDFPDF/DOCX/PPTX/HTML + 网页/S3/Snowflake/Notion,每日刷新

表里的质量指标(CP、CR、AR、UMBRELA)第 11 章全部会讲。 这张表的读法不在具体数字,而在于:每一个维度都有可测的口径, 且 POC 的实测值被原样保留作对照。

上线之后才是真正开始。书里描了一个反复出现的模式:上线头几天查询量冲高, 两三周后掉回一个小得多的日常量——那多半意味着哪里出了问题 (答得没用?太慢?),要靠日志与赞/踩反馈定位24。

7. 作者的判断与证据​

  • 「3-5 倍超支」与「400 个用例」是作者从自家客户经验里来的行业判断, 方向可信,倍数因组织而异;
  • 延迟预算表(300ms / 2-3s / 5-10s)是经验值,不是测量报告;
  • KPI 表作者明说是示例值——我们照引,也只当示例;
  • 「推理服务器层没有商量余地」是强判断,证据是 continuous batching 与 paged attention 在业界的普及度,成立。

8. 边界与局限​

  • 本章刻意不含基础设施即代码的细节——不同云、不同合规下写法完全不同;
  • 缓存的「语义命中」阈值 0.85 是书例,你的数据要重新校准;
  • 安全一节没覆盖内部人员威胁与供应链安全;
  • 数字全部是 2026 年快照。

9. 可带走的​

  1. 质量四病因:缺数据、检索弱、幻觉、prompt——先定位是哪一条,再动手;
  2. 延迟先定预算:检索 ≤300ms,生成才是大头;控尾部(P95)不只看平均;
  3. fan-out 让检索延迟等于最慢一路,不是各路之和;每个微服务按自己的瓶颈扩缩;
  4. 缓存四层,语义缓存最值钱;失效要靠事件驱动,不能只靠 TTL;
  5. PII 脱敏选 entity-aware:保住语义结构,数据才仍可用;
  6. 权限在查询期过滤,前提是摄入期的元数据纪律;
  7. TCO 经验数 3-5×;预算告警 + 限流 + 级联模型是三个控制阀;
  8. 上线目标写成 KPI 表,POC 实测值留作对照;上线两三周后的用量回落是报警信号。

10. 原文地图​

主题原书章原文位置
POC vs 生产Chapter 4text/50-ch04-chapter-4-deploying-rag-to-production.txt:12(搜「whole other story」)
SambaNova 缺数据例Response Quality…text/51-fm-response-quality-and-reduced-hallucinations.txt:37(搜「SambaNova」)
staging 质检门Response Quality…text/51-fm-response-quality-and-reduced-hallucinations.txt:49(搜「staging」)
gap-fillingResponse Quality…text/51-fm-response-quality-and-reduced-hallucinations.txt:82(搜「gap-filling」)
延迟预算High Latencytext/52-fm-high-latency.txt:7(搜「300 ms」)
尾部延迟High Latencytext/52-fm-high-latency.txt:45(搜「95th percentile」)
fan-out/编排器High Latencytext/52-fm-high-latency.txt:61(搜「fan-out」)
推理服务器High Latencytext/52-fm-high-latency.txt:88(搜「continuous batching」)
缓存四层、0.85、失效High Latencytext/52-fm-high-latency.txt:132(搜「semantic cache」) · :155(搜「0.85」) · :135(搜「invalidation」)
脱敏三档、PresidioData Security and Privacytext/53-fm-data-security-and-privacy.txt:20(搜「entity-aware」) · :23(搜「Presidio」)
权限过滤、外部 LLM 泄漏Data Security and Privacytext/53-fm-data-security-and-privacy.txt:76(搜「RBAC」) · :94(搜「on-prem」)
厂商清单与检查表Vendor Chaos…text/54-fm-vendor-chaos-and-integration-woes.txt:58(搜「Complexity assessment checklist」)
400 用例、四技能桶Team and Expertisetext/55-fm-team-and-expertise.txt:7(搜「four hundred」) · :17(搜「Machine learning engineering」)
TCO 3-5×、denial-of-wallet、级联Total Cost of Ownershiptext/56-fm-total-cost-of-ownership.txt:67(搜「3–5x」) · :87(搜「denial-of-wallet」) · :93(搜「cascading」)
KPI 表Define Goals and Requirementstext/59-fm-define-goals-and-requirements.txt:28(搜「7.5」) · :38(搜「99.99」) · :47(搜「Hallucation」)
用量回落模式Define Goals and Requirementstext/59-fm-define-goals-and-requirements.txt:172(搜「query volume peak」)

Footnotes​

  1. 出处:「Chapter 4. Deploying RAG to Production」第 12 段(text/50-ch04-chapter-4-deploying-rag-to-production.txt:12,搜「whole other story」)。 ↩

  2. 出处:「Response Quality and Reduced Hallucinations」第 7 段(text/51-fm-response-quality-and-reduced-hallucinations.txt:7,搜「trust」)。 ↩

  3. 出处:「Response Quality and Reduced Hallucinations」第 37 段(text/51-fm-response-quality-and-reduced-hallucinations.txt:37,搜「SambaNova」)。 ↩

  4. 出处:「Response Quality and Reduced Hallucinations」第 49 段(text/51-fm-response-quality-and-reduced-hallucinations.txt:49,搜「staging」)。 ↩ ↩2

  5. 出处:「Response Quality and Reduced Hallucinations」第 82 段(text/51-fm-response-quality-and-reduced-hallucinations.txt:82,搜「gap-filling」)与第 88 段(同文件,搜「spectrum of factuality」)。 ↩

  6. 出处:「High Latency」第 7 段(text/52-fm-high-latency.txt:7,搜「300 ms」)。补充(不在书里,来自通用知识):99.99% 可用性折算一年停机约 52.6 分钟。 ↩

  7. 出处:「High Latency」第 45 段(text/52-fm-high-latency.txt:45,搜「95th percentile」)。 ↩

  8. 出处:「High Latency」第 52-88 段(text/52-fm-high-latency.txt:61,搜「fan-out」;:88,搜「continuous batching」)。 ↩

  9. 出处:「High Latency」第 106-135 段(text/52-fm-high-latency.txt:132,搜「semantic cache」;:155,搜「0.85」)。 ↩

  10. 出处:「High Latency」第 135 段(text/52-fm-high-latency.txt:135,搜「invalidation」)与第 229-247 段(同文件,搜「Redis」)。TTL=time to live,缓存条目的存活时长。 ↩

  11. 出处:「Data Security and Privacy」第 4 段(text/53-fm-data-security-and-privacy.txt:4,搜「defense-in-depth」)。 ↩

  12. 出处:「Data Security and Privacy」第 14-20 段(text/53-fm-data-security-and-privacy.txt:20,搜「entity-aware」)。 ↩

  13. 出处:「Data Security and Privacy」第 23-63 段(text/53-fm-data-security-and-privacy.txt:23,搜「Presidio」)。 ↩

  14. 出处:「Data Security and Privacy」第 85-100 段(text/53-fm-data-security-and-privacy.txt:76,搜「RBAC」)。 ↩

  15. 出处:「Data Security and Privacy」第 100 段(text/53-fm-data-security-and-privacy.txt:100,搜「on-prem」)。 ↩

  16. 出处:「Vendor Chaos and Integration Woes」第 58-108 段(text/54-fm-vendor-chaos-and-integration-woes.txt:58,搜「Complexity assessment checklist」),原书 Table 4-1。 ↩

  17. 出处:「Vendor Chaos and Integration Woes」第 110 段(text/54-fm-vendor-chaos-and-integration-woes.txt:110,搜「coordinator」)。 ↩

  18. 出处:「Team and Expertise」第 17-42 段(text/55-fm-team-and-expertise.txt:17,搜「Machine learning engineering」)。 ↩

  19. 出处:「Team and Expertise」第 7 段(text/55-fm-team-and-expertise.txt:7,搜「four hundred」)。 ↩

  20. 出处:「Total Cost of Ownership」第 67 段(text/56-fm-total-cost-of-ownership.txt:67,搜「3–5x」)。 ↩

  21. 出处:「Total Cost of Ownership」第 73-87 段(text/56-fm-total-cost-of-ownership.txt:87,搜「denial-of-wallet」)。 ↩

  22. 出处:「Total Cost of Ownership」第 93-103 段(text/56-fm-total-cost-of-ownership.txt:93,搜「cascading」)。 ↩

  23. 出处:「Define Goals and Requirements」第 10-108 段(text/59-fm-define-goals-and-requirements.txt:28,搜「7.5」;:38,搜「99.99」;:47,搜「Hallucation」),原书 Table 4-2。补充(不在书里,来自通用知识):99.99% 可用性折算一年停机约 52.6 分钟。 ↩

  24. 出处:「Define Goals and Requirements」第 172 段(text/59-fm-define-goals-and-requirements.txt:172,搜「query volume peak」)。 ↩