这是 PIA 系列的第三篇。 第一篇提出“渐进式智能”原则：永远先用能够解决问题的最低层级智能； 第二篇拆解三层智能的分工：规则与缓存（L1）、统计模型（L2）、LLM（L3）。 本篇回到工程现场，回答一个被忽视的问题：当业务在变、用户在变、问题本身也在生老病死时， 一个分层 AI 系统该怎样活着？ 核心结论是：PIA 不是一张静态架构图，而是一个带生命周期治理的运行时。 未来企业 AI 的竞争，不再是模型参数的竞争，而是智能调度的竞争。
需要说明的是，PIA 的生命周期治理、问题大类、垃圾回收等机制，是我在提出渐进式智能架构时首次作为企业 AI 工程原则系统阐述的，不是对现有运维手段的简单包装。
引言：架构不是静态图纸，而是活的生态
本文要讨论的不是某本书或某个框架里的“最佳实践清单”，而是我在提出 PIA 时必须回答的下一个问题：如果智能可以分层，那么分层之后怎么治理？
大多数企业 AI 系统的失败，不是死于模型不够聪明，而是死于知识的腐烂。
某电商客服规则库里有一条三年前的规则： “凡问退换货期限的，回答 30 天。” 后来政策改成 15 天，它没 miss、没报错、没触发告警， 每天自信地命中、自信地回答、自信地错。 直到法务上门，团队才发现规则库里躺着上千条这样的“僵尸规则”。
这就是分层系统最容易被低估的风险： 低层资产一旦过期，会从“低成本”变成“自信地犯错”。
真实业务里，问题不是静止的。 它会下沉、上浮、变异、消亡。 一条今天由 LLM 解决的新问题，明天可能沉淀成规则； 一条三年前固化的规则，今年可能因政策变化而失效； 一个曾经热门的业务线，可能在某个季度被整体关停。
如果架构只能“向上升级”，不能“向下沉淀”和“横向清理”， 它会逐渐变成一座堆满过期规则的垃圾场。 PIA 的第三层含义，正是要解决这个问题： 让分层系统跟着问题一起生长、一起衰老、一起更新。
过期的规则不是资产，是负债；它产生的不是确定性，是错误的确定性。
第一章：问题的完整生命周期
1.1 诞生（Unknown Unknown）→ 被认知 → 被固化
新问题进入系统时，通常是 Unknown Unknown： 系统既不知道它属于哪一类，也不知道该怎么解。
典型的入口是 LLM。 用户问了一个从未见过的问题，L1 miss、L2 低置信， 流量穿透到 L3，由 LLM 现场推理并给出答案。 这一步不是失败，而是问题的“出生证明”。
但 L3 的输出本身只是一次性答案。 如果系统到此为止，它不过是一个昂贵的在线问答机。 PIA 要求把这次解决变成可复用的资产：
- 个案沉淀：把高频 query→answer 写进缓存；
- 样本积累：把边界样本喂给 L2 分类器或 Reranker；
- 类级归纳：当缓存中同类个案积累到 50~200 条，用聚类浮现出问题类，再由 LLM 或人工提炼成规则或训练集。
这个过程就是从 Unknown Unknown → Known Unknown → Known Known 的完整链路。
反模式是“只缓存、不聚类、不泛化”。 缓存只能覆盖一模一样的 query，换种说法就 miss。 没有聚类和泛化，系统只是在“记住答案”，而不是“学会解法”。
1.2 环境变化 → 变异 → 失效上浮
问题被固化后，并不意味着一劳永逸。 业务环境会持续对它施加压力：
- 用户说法漂移：三年前说“退款”，现在说“仅退款”“七天无理由”；
- 政策调整：退换货期限从 30 天变成 15 天；
- 欺诈手法进化：同一类攻击不断换马甲；
- 产品形态变化：旧功能下线，新流程产生新问题。
这些变化会让原本的 Known Known 退化为 Known Unknown， 甚至重新变成 Unknown Unknown。
表现形式通常是： 原本 90% 停在某类 L2 的问题，开始大量上浮到 L3。 这不是 LLM 变强了，而是低层解法正在失效。
PIA 把这种现象称为失效上浮（Escalation by Decay）： 老问题的低层资产腐烂，问题自动浮回高层，等待被重新理解和再次下沉。
关键机制是：系统必须允许问题“向上走”。 如果低层必须给出答案，就会制造大量静默错误。 分层架构的安全网，正是“解不了就往上送”这条默认路径。
1.3 退役与消亡
不是所有问题都会永恒存在。 有些问题会自然消亡：业务下线、术语过气、产品改版。 有些问题会被主动关停：整类业务被裁撤。
消亡不是坏事。 坏的是消亡了却没人知道，规则库里继续养着一堆死资产。
退役的标志通常是：
- 连续 30~90 天零命中；
- 对应业务线的 API 流量归零；
- 意图体系中的该类 query 占比下降到阈值以下。
退役也不是直接删除。 应该先进入隔离区，观察是否有异常命中； 隔离期满，再归档或物理删除。
整个生命周期可以概括成一张图：
问题是活的：它会出生、会被认知、会被固化，也会变异、会失效、会消亡。架构必须承认这一点。
第二章：三种动态问题的应对机制
2.1 问题消亡 → 退役机制（TTL、命中率监控）
消亡是最容易处理、也最容易被忽略的动向。
机制设计：
- TTL（Time-To-Live）：每条规则、缓存条目、词典项都必须带过期时间。 业务规则通常 30~90 天审查一次，临时活动规则可能只有 7 天。
- 命中率监控：记录每个资产的命中次数和最近命中时间。 连续两个审查周期零命中，进入候选退役清单。
- 依赖标签：每个资产必须关联业务列表。 业务关停时，引用该业务的资产自动进入审查队列。
Checklist：
- 所有 L1 资产都有 TTL 和最后命中时间；
- 命中率报表按周产出，按业务线聚合；
- 候选退役资产先进隔离区，再决定是否删除；
- 核心规则退役前必须通过 Golden Set 回归。
关键指标：
- 命中率：单位时间内资产被命中次数占总 query 的比例。核心规则建议 >1%，低于阈值进入候选退役。
- TTL 覆盖率：带 TTL 的 L1 资产占比，目标 100%，缺失则强制补标。
- 退役周转：从候选退役到最终清理的平均天数，建议控制在 45 天以内。
反模式：把规则库当成只增不减的资产仓库。 过期的规则会污染命中结果，而且因为它们不 miss，不会被自然上浮机制发现。
2.2 问题变形 → 漂移检测（Embedding 分布、升级率）
变形是最隐蔽的动向。 问题没变，但问法变了；答案没变，但判断依据变了。
检测信号主要有三类：
-
Embedding 分布偏移： 对每类问题的历史 query 做 Embedding 聚类，形成稳定簇。 当新进来的 query 分布与历史簇的 KL 散度或 Wasserstein 距离持续增大，说明问题正在变形。
-
升级率（Escalation Rate）变化： 某类问题原本 80% 停在 L2，突然有 30% 上浮到 L3， 这是 L2 解法失效的最直接证据。
-
L2 置信度整体下滑： 分类器 Top-1 概率从 0.92 降到 0.75，说明输入空间正在偏离训练分布。
应对机制：
- 触发漂移告警后，把近期上浮到 L3 的 query 和答案作为新标注样本；
- 对 L2 分类器或检索索引做增量重训；
- 重训后跑 Golden Set 回归，确认新模型是否覆盖旧能力。
Checklist：
- 每类问题都有历史 Embedding 基准分布；
- 漂移检测按天跑，阈值按类设定；
- 漂移告警自动触发样本收集和重训流水线；
- 重训后必须用旧 Golden Set + 新边界样本双回归。
关键指标：
- Embedding 漂移分数：当前分布与历史基准分布的距离，例如 KL 散度或 Wasserstein 距离。超过 0.2σ 说明问法或语义正在偏移。
- 升级率变化：某类问题抵达 L3 的占比变化。单周绝对变化超过 10%，说明低层能力正在失效。
- L2 平均置信度：该类问题在 L2 的 Top-1 概率或检索相似度均值。连续下降超过 0.1，说明输入分布正在偏离训练集。
反模式：把升级率上升当成“LLM 用得更多了”而沾沾自喜。 没有漂移检测的系统，会长期用失效的 L2 硬撑，直到用户投诉爆发。
2.3 问题升级 → 金丝雀抽检 + Golden Set 回归
问题升级指的是：一个原本确定的问题，因环境剧变重新变得开放。 例如政策完全重写、新产品形态上线、监管口径突变。
好消息是，PIA 的被动升级机制本身就是第一道防线： L1 和 L2 解不了，自动上浮到 L3。 坏消息是，如果 L1 的规则“自信地给出错误答案”，系统不会上浮，只会静默犯错。
因此必须有两层额外防护：
金丝雀抽检（Canary Sampling）：
- 每天从 L1/L2 已解决的流量中，按 1%~5% 的比例抽样；
- 把这些 query 重新送到 L3 做复核；
- 如果 L3 输出与低层结果不一致，触发规则审查。
抽检比例不是越高越好。 对核心合规类问题可以抽到 10%，对低风险 FAQ 抽到 1% 就够。 关键是保持持续、随机、可审计。
Golden Set 回归：
- 每类问题维护 50~200 条标准测试集；
- 业务变更、模型升级、规则批量修改前，必须跑一遍；
- 只要 Golden Set 通过率下降，变更就不能上线。
Checklist：
- 每类核心问题都有 Golden Set；
- 金丝雀抽检比例按风险等级分层；
- L3 复核结果与低层不一致时，自动生成审查工单；
- 任何规则批量上线前必须通过 Golden Set 回归。
反模式：把 L1 的命中当成“一定正确”。 命中只能证明匹配了规则，不能证明规则没过时。
命中不等于正确。低层最危险的不是 miss，而是自信地给错答案。
第三章：冷启动到稳态的生长曲线
3.1 冷启动期：LLM 扛下一切
PIA 上线第一天，L1 是空的，L2 还没训练好， 几乎所有流量都会穿透到 L3。 这不是架构失败，而是婴儿的襁褓期。
这个阶段的特征是：
- L3 解决占比接近 100%；
- 单均成本最高，延迟最长（一次 L3 调用通常是 L1 的 1000~10000 倍成本）；
- 但所有 L3 输出都是种子数据，不能浪费。
加速冷启动的手段：
- 用历史日志离线挖掘高频 query，预生成规则；
- 让 LLM 批量生成种子规则，人工抽检高影响条目；
- 导入业务方已有的知识库、FAQ、SOP；
- 对线上流量做实时聚类，优先把高密度类下沉。
冷启动期的目标不是“省钱”，而是“尽快让系统进入成长期”。 每多拖一个月，就多付一个月的“全 LLM 税”。
3.2 成长期：快速下沉
当种子数据积累起来，L1 和 L2 开始接手越来越多的问题。 系统进入快速下沉阶段：
- L3 解决占比从 100% 降到 60%、40%、20%；
- 单均成本和延迟持续下降；
- 规则库、缓存、分类器以周为单位更新。
这个阶段的健康标志，是“LLM 流量占比不断萎缩”的曲线。 它不是系统变弱了，而是系统把确定性问题交给了更便宜的层级。
需要警惕的是：不要为了下沉而下沉。 把边界样本硬塞进 L1，会让规则膨胀； 把还不够稳定的问题硬交给 L2，会让分类器过拟合。 下沉必须过质量门：
- 规则覆盖的 query 必须有足够样本支撑（建议至少 20~50 条）；
- 分类器训练样本必须覆盖该类的主要变体；
- 所有下沉动作必须通过 Golden Set 回归。
3.3 稳态期：80/20 动态平衡
成熟业务最终会收敛到一个稳态分布。 按帕累托原则，经验数字大约是：
80% 的已知问题停在 L1/L2，20% 的流动性问题抵达 L3。
注意三个细节：
-
这个 80% 不是设计出来的，是长出来的。 业务越标准化，低层占比越高；业务越开放（创意、研究、咨询），L3 占比天然越高。
-
稳态不是静态，是动态平衡。 那 80% 的成员在不断更换：老问题消亡退役，新问题从 L3 下沉补位。 流入速率 ≈ 流出速率。
-
不同大类的稳态各不相同。 退换货类可能 95% 在 L1；复杂投诉类可能 50% 在 L3。 所以监控必须按类看，不能看全局平均值。
3.4 LLM 从主力退位为守门人
PIA 成熟的标志，不是 L3 流量为零。 L3 流量为零，意味着系统不再接触新问题，已经僵化。
成熟的标志是：
L3 只处理真正的长尾与新问题，且这个比例稳定在健康区间。LLM 从“主力”退位为“守门人”。
守门人的职责有三项：
- 解决未知问题；
- 复核低层结果，发现静默错误；
- 为新问题类的归纳提供原始推理样本。
把 80% 的确定性问题从 token 计费里解放出来， 剩下的 20% 才值得你最贵的智能。 这不是倒退，而是分层系统长成的样子。
第四章：问题大类是治理的基本单元
4.1 三种分法：业务意图、Embedding 聚类、解法视角
单条 query 决定“这一次停在哪层”， 但监控、下沉、退役这些治理动作，必须以“问题大类”为单位。
大类有三种分法，各有利弊：
1. 业务意图（Top-down）
人工定义意图体系：退款、查账、投诉、咨询政策…… 优点是可解释、可运营、权责清晰。 缺点是覆盖不了体系外的 Unknown Unknown。
2. Embedding 聚类（Bottom-up）
对历史 query 做 Embedding 聚类，让数据自己说话。 稳定的稠密簇 = 已被认知的类； 快速长出来的新簇 = 正在涌现的新问题，是发现 Unknown Unknown 的雷达； 簇的形状分裂 = 问题正在变种。
3. 解法视角（L1/L2/L3 分布）
同一业务意图内部，难度也可能不同。 “退款多久到账”是 L1 缓存题； “我这单为什么被拒”可能要 L3 查日志推理。 所以更精确的做法是：大类 = 业务意图 × 解决层级。
正确的实施方式是两条腿走路： 用业务意图起步，用日志聚类持续修正，两者定期对账。 聚类发现的新簇，要么并入现有意图，要么推动意图体系增加新类。
4.2 按类监控的指标
所有流量指标都要按类看，否则全局平均值会掩盖局部腐烂。
| 指标 | 计算方式 | 回答的问题 | 触发动作 |
|---|---|---|---|
| 层分布 | 该类 query 被 L1/L2/L3 解决的占比 | 这个类成熟了吗？ | L3 占比长期 >50% → 推动下沉 |
| 升级率趋势 | 本周 vs 上周抵达 L3 的占比变化 | 低层能力是否在失效？ | 单周变化 >10% → 漂移告警 |
| 单均成本 | 该类总成本 / 该类 query 数 | 哪个类最烧钱？ | 成本最高的类优先做下沉 |
| 命中率衰减 | 该类 L1 规则命中率的环比变化 | 规则是否过期？ | 连续下降 → 触发规则审查 |
| 新增 query 占比 | 该类中未匹配任何已知簇的 query 占比 | 是否有新子类涌现？ | 突增 → 触发聚类重跑 |
| Golden Set 通过率 | 该类标准测试集通过比例 | 改动是否破坏旧能力？ | 下降 → 阻止上线 |
按类监控的最大价值，是把“系统是否健康”从一句模糊判断，变成可行动的优先级列表。
4.3 类级消亡与“关业务变得很便宜”
比单条问题退役更彻底的，是整类问题的消亡。 业务关停就是一种“灭绝事件”：
- L1 的规则、词典、缓存条目，整批下线；
- L2 的分类器子模型、Embedding 索引、标注数据，整批退役；
- L3 为该业务定制的 Prompt、工具、知识库挂载，整批摘除；
- 意图体系中的这个分支，也要从 Router 的分类空间里移除。
这件事有一个容易被低估的好处： PIA 让“关业务”变得很便宜。
因为每一层的资产都按类组织、可枚举、可摘除， 关停一个业务就是一次干净的“整类回收”。 而在单体 LLM 系统里，这些知识融化在上下文和 Prompt 里，想摘都摘不干净。
类级消亡的触发条件：
- 该类流量连续 30 天低于基线的 5%；
- 业务方发出下线通知；
- 该类在聚类图中不再形成稳定簇。
单条 query 决定“这一次停在哪层”，问题大类决定“整个系统怎么演进”。
第五章：垃圾收集机制
流量归零是被动淘汰。 更主动、更干净的做法，是给智能资产引入垃圾收集（GC）机制。
5.1 引用计数（主动淘汰）
每条智能资产都维护一张“关联业务列表”。 资产创建时，必须声明它服务于哪些业务。 业务关停或下线时，引用计数减一； 计数归零，资产立即进入回收队列。
这类似于 Python 的引用计数：对象没人用了，就实时释放。
优点：
- 没有尸体堆积；
- 规则库、索引、模型仓库始终保持干净；
- 关停业务后可以立即清理相关资产。
缺点：
- 无法处理循环引用；
- 无法发现“声明了引用但业务实际不用”的虚假依赖。
Checklist：
- 资产 schema 把“关联业务”设为必填字段；
- 业务关停事件自动同步到资产管理系统；
- 引用计数归零的资产先进隔离区；
- 定期对账“声明引用”与“实际命中”。
5.2 标记-清除（定期大清扫）
引用计数的盲区，要靠可达性分析来解决。 每季度从“当前存活业务列表”出发，做一次标记-清除：
- 标记（Mark）：所有能从存活业务触达的资产，标记为“活”；
- 清除（Sweep）：剩下的孤儿资产——引用关系断了、没人记得的——统一清除。
这就像 JVM 的 GC：不能只看对象有没有被引用， 而要看它是否能从 GC Roots 可达。
标记-清除特别适合发现：
- 规则 A 引用规则 B、B 引用 A 的循环引用；
- 历史项目遗留的、没人维护的 Prompt 和工具；
- 业务迁移后忘记下线的旧索引。
5.3 分代回收
不同资产的寿命差了两个数量级，不能用同一种节奏回收。
- 新生代：缓存、会话别名、临时活动规则。生命周期从分钟级到周级，用短 TTL 高频自动回收。
- 老年代：核心规则、知识图谱、稳定分类器。生命周期从月级到年级，回收前必须人工确认并跑 Golden Set。
- 永久代：跨业务公共词典、基础实体链接。生命周期在年级以上，不自动删除，只审计和归档。
新生代可以大胆自动回收； 老年代回收前必须跑 Golden Set，确认没有破坏旧能力。
5.4 隔离区（防误杀）
GC 最大的风险是误杀。 回收不应该立即物理删除，而应该先进隔离区：
- 资产下线但保留 30~90 天；
- 期间任何 query 原本会命中它，就触发告警；
- 告警说明可达性分析漏了，立即复活并补标签；
- 隔离期满无异常，才归档或删除。
隔离区相当于给资产一个“临终申诉”的机会。 没有隔离区的 GC，和直接删库没有太大区别。
5.5 业务标签三种来源与置信度
GC 的前提是标签准确。 标签不能靠人肉维护，必须靠三条证据链组合：
| 标签来源 | 含义 | 置信度 | GC 中的角色 |
|---|---|---|---|
| 声明标签 | 资产为哪个业务创建 | 中 | 初始引用，创建时强制绑定 |
| 推断标签 | 资产实际被哪些业务命中 | 高 | 回收判据的主依据 |
| 机器标签 | LLM 从内容推断业务归属 | 低~中 | 存量补标，人工抽检 |
声明标签在资产入库时强制填写。 原则：无标签，不入库。 新建资产的标签成本几乎为零，因为“它为什么被造出来”本身就是答案。
推断标签来自运行时流量。 每次资产被命中，query 都携带业务上下文： 入口渠道、API Key、产品线、意图分类结果。 把命中日志按资产聚合，就得到真实的业务依赖分布。 流量不说谎，所以它是回收判据的主依据。
机器标签用于历史存量资产。 对老规则库里几万条没人记得来历的规则， 让 LLM 读规则内容、样本 query、命中上下文，批量推断业务归属。 人工只抽检高影响资产。
定期对账： 声明标签与推断标签不一致的资产，必须人工审查。 这种不一致往往意味着隐性依赖或标签腐烂。
标签不靠维护，靠产生时绑定、运行时验证、机器兜底。人只处理对账差异。
第六章：局限与开放问题
6.1 置信度是整套机制的软肋
被动升级依赖“每层能说我不行”， 但三层的置信度质量完全不同。
L1 的 hit/miss 最干净，但命中≠正确。 过期规则会自信地给出错误答案。
L2 的 softmax 概率和检索分数普遍不校准。 分类器经常以 0.99 的置信度犯错。
L3 的自验证最虚。 LLM 的自评能力已被大量研究证明不可靠，它经常自信地胡说。
所以实际部署时必须有一个校准层： temperature scaling、保序回归、Platt scaling。 升级阈值不能全局拍脑袋，必须按问题大类分别学习。
6.2 逐层贪心 ≠ 全局最优
串行升级是局部贪心决策。 从 L1 试到 L3 的总成本，可能高于直接路由到 L3。 更隐蔽的是锚定效应： 如果把 L2 的错误答案作为上下文传给 L3， LLM 倾向于顺着已有答案说，错误被放大而不是纠正。
因此升级决策应该是成本感知的： 每层预估“继续往下的期望总成本”，必要时跳层； 低层传给高层的只能是信号（miss / 低置信），不能是结论。
6.3 Router 的鸡生蛋问题
主动路由的判断器本身通常是一个 L2 模型。 问题随之而来：谁路由路由器？
分布漂移时，Router 往往最先失效。 而它一失效，整个系统会被批量送进错误的层。
Router 必须被纳入漂移监控， 而且永远保留降级路径： 当 Router 不确定时，退化为被动升级。
6.4 Unknown 误判为 Known：架构的测不准原理
Known / Known Unknown / Unknown Unknown 的划分， 依赖系统对“自己知道什么”的判断。
但系统最大的风险，恰恰是不知道自己不知道。 一旦 Unknown 被误判为 Known， 所有低层机制都会从“低成本”变成“自信地犯错”。
这是 PIA 体系里唯一无法靠机制根除的风险。 只能靠金丝雀抽检、OOD 检测、分布监控不断逼近。 它是这套架构的“测不准原理”。
6.5 下沉飞轮可能变成错误自循环
L3 的输出沉淀为规则时，如果质量门缺位， LLM 的错误会被固化成“确定性知识”，反复引用，自我强化。
所以下沉必须过质量门：
- 沉淀资产必须保留“来源为 LLM”的血缘标记；
- 核心规则下沉前必须人工抽检；
- 一旦发现上游错误，可以沿引用图整批回溯。
GC 机制在这里有了第二种用途： 不仅是清理死资产，也是追溯错误传播链的工具。
6.6 治理收益的规模门槛
GC、标签、隔离区、对账、金丝雀—— 这套治理体系本身有复杂度成本。
对低并发、单业务、短生命周期的系统， LLM-first 的浪费可能还没有治理成本高。
PIA 的回本场景很明确： 高频、多业务线、强合规、长生命周期的企业系统。 超出这个边界，简单方案反而更优。
一个能自己指出边界的架构思想，才经得起工程实践的检验。
结语：未来的竞争是智能调度
回头看这三篇。
第一篇立原则：永远用最小必要智能解决问题。 第二篇拆结构：三层智能匹配三类问题。 这一篇讲活法：问题有生老病死，系统就要有下沉、上浮、退役和 GC。
三层结构是骨架，双向流动是血液，分类治理是免疫系统。
过去三年，企业 AI 的军备竞赛只有一个方向：谁的模型大。 但当你真正把系统跑上一年，你会发现账单的大头不是最难的那 20%， 而是被 LLM 硬扛的、本该属于规则的那 80%。
未来企业 AI 的竞争， 可能不再是谁拥有最大的模型， 而是谁能够最合理地调度不同层次的智能。
真正成熟的 AI 系统，不是 LLM Everywhere，而是——
Progressive Intelligence：让智能像计算资源一样，按需、渐进、高效地发挥作用。
模型会过时，架构不会。 模型竞赛的赢家每六个月换一批， 而调度智能的能力，一旦长出来，就是复利。
相关阅读
- 系列第一篇：《渐进式智能：企业 AI 系统的新架构思想》（提出理念）
- 系列第二篇：《为什么 Rule、传统 ML 和 LLM 不会互相取代》（讲透三层智能）