第 11 章 — 持续更新与流水线优化
LLM Primer III: Enhancing Enterprise AI with RAG 章节走读的最末一篇。流水线没有「做完」这件事 — 文档在变、查询在漂、模型在换 — 负责它的团队学着在三种时间尺度上同时思考。
这一章为什么存在
一套 RAG 系统不是上线那天做完的。文档在变,查询在漂,模型自己几个月就换一代。团队三月份引以为豪的流水线,到了九月,在对着两代之前的嵌入做检索、给一个被悄悄换掉的基础模型做服务、回答一份没人画出来的、已经漂了的查询分布。这一章讲的是「保持当下」的那门工程 — 检测语料里变了什么、不重建就能让索引保持新鲜、不让延迟悄悄上爬、把生产里的遥测和团队真正动手做的改动之间的环合上。
11.1 Change Data Capture 与增量索引
每一支上线 RAG 的团队的第一反应,是每晚重建一遍索引。它跑得起。它长期也不对。每晚重建会把嵌入 API 花在没变的文档上、让索引最多落后 24 小时、并且随着语料增长不再装得进那个夜窗。成熟的样式是 Change Data Capture 驱动的增量索引 — 流水线对上游的事件反应,而不是去轮询。
三种事件要紧。Insert:新文档,解析、分块、嵌入、入库。Update:已有文档变了;把受影响的块重新嵌入。Delete:文档被移除;在它能再次出现在结果里之前把对应向量驱逐 — 这是 GDPR、CCPA 这一类合规框架的硬要求。让这件事可控的机器是「内容哈希」。第一次入库时,在嵌入旁边把规范化块文本的 SHA-256 存下。更新时,重切、重哈希、对比:没变的块留着、新的进嵌入、旧的走。一次段落编辑,变成一次嵌入调用,不是一千次。嵌入账单按编辑活动伸缩,而不是按语料体量伸缩。
更难的问题是顺序与一致性。事件会乱序到达;delete 可能赶在它本该跟的 update 之前。标准的解法是给每份文档加单调递增的版本,配条件写:只有事件的版本超过当前版本才应用。这让流水线幂等 — 重复事件不会污染索引 — 在规模上这不是优化,是正确性要求。合规场景再加 tombstone:一次逻辑 delete,在物理移除完成前就在查询时生效,删除被即刻尊重,物理清理异步收尾。
11.2 管延迟:语义缓存与模型分层
一次 RAG 调用在每一跳上都在累积延迟。守的方法是,在能证明不必要的时候少做事,两件技术承担了这件事的大头。一份传统缓存按查询字符串精确匹配作键,真实流量里的命中率几乎是零。语义缓存 按含义作键:把进来的查询嵌入,在最近查询的小缓存里搜,如果与最近邻的余弦相似度超阈值,就返回缓存的回答。「我们的退款政策是什么?」和「退款怎么搞?」共享零个字符串匹配,共享整个回答。
要紧的三个选择是相似度阈值(通用嵌入上余弦 0.93–0.97,对着留出流量调)、TTL(理想情况是绑到贡献块上 — 它们之中任何一块被重新嵌入时让缓存失效)、作用域(按租户、按访问角色、按任何可能让一个用户的回答漏到另一个用户的维度分区)。生产部署报告 30–60% 命中率,命中是几十毫秒,未命中是几秒,成本上同比省下 — 命中跳过嵌入和生成两步。
模型分层 负责那些必须用模型、又不该用现成最大模型的查询。两到三档:一个小、快、便宜的模型扛大头,一个更大的接小模型没自信的那批,还有可选的第三档应付长尾。路由是第一版生产部署最容易出错的地方。最简单的版本用查询侧的信号(短事实问 vs 分析问)。更好的用检索侧的信号(高且一致的相似度意味着小模型够用)。最讲究的先跑小模型,根据标定过的置信度升级 — 在边界上准,代价是升级的那批多一次推理。要一起盯的两个数是升级率和悔率;单看任何一个都会被骗。
11.3 持续反馈环
一条 RAG 流水线吐遥测吐个不停。大多数团队收着,少数把环合上。环有四段。收集:每一次查询、检索、生成、引用、用户交互,按一份稳定的 schema、带一个贯穿各阶段的稳定查询 id 记下来 — 没有这个 id,事后追一次回归会退化成猜。评估:第 9 和第 10 章的三件套两种模式跑,一种是按参考集离线采样追准确度,一种是在线行为代理(再生、复制、追问、放弃)追覆盖。哪一种单独都不够,合起来才能三角定位。
决定 是最难的一段,因为同一份信号能指向几种不同的修法。Context Relevance 下滑,可能是语料缺主题,可能是重排器退化,可能是嵌入模型与新词表不再匹配。区分得切片看 — 按主题、按文档时效、按嵌入版本、按租户 — 只盯聚合的团队,过一季度才发现,原来其中一片一直在拖低平均值。
应用 有三种权重。配置改动 — top-k、重排权重、混合 alpha、缓存阈值、升级规则 — 小时级 A/B、分钟级回滚,任何时刻可以同时跑几条。重新入库动作 — 把陈旧主题重嵌入、引入新源、驱逐过期文档 — 每周到按需,先在非生产副本上做、再升级。模型改动 — 换嵌入模型、换基础模型、重训定制重排 — 每季,带影子部署、并行评估、逐步切流量、可回滚。纪律在节奏上,而不在任何一次单独的改动上。一小条人工标注通道 — 也许每周一百条来自「模糊代理」的样本 — 让 LLM 法官保持标定,阻止环对它自己的代理过度优化。
第三本到这里收口,接下去要走到哪儿
我们从把检索增强生成当作那两个纯语言模型解不掉的问题 — 新鲜的知识和可验证的来源 — 的工程答案讲起。我们把架构从早期的嵌入—检索—塞,一路追到今天在生产里跑的模块化和 agentic 系统,沿路对每一颗组件都做了认真活 — 把结构从 PDF 里捞出来的解析器、决定「一份意义单位」是什么的分块器、收下结果的向量库、找出要紧内容的混合检索与重排、让系统不说谎的访问控制与匿名化、告诉我们这一切是否在工作的评测框架,以及现在这一条让它活着的持续更新机制。
RAG 不是一个产品品类。它是一门工程学问,大致由十几个子学问搭起来,每一个都可能是「能跑的系统」和「悄悄幻觉的系统」之间的那一线。把每个子学问都当回事的团队会做出在真实流量下立得住的东西。把任何一个当黑盒的团队不会。
系列继续在 LLM Primer IV — 用 MCP 设计 AI 认知。第三本讲的是把对的知识递到模型面前;第四本讲的是把对的手 — Model Context Protocol、用它的智能体、它们调的工具、它们累积的记忆。同一种架构感觉,同一个问题的另一面。活还在继续。
