你的 SRE 复盘模板遗漏了决定每次 LLM 故障的六个关键字段

当你第一次用经典的 SRE 复盘（Postmortem）模板来分析 LLM 事故时，模板赢了，而事故输了。时间线、诱因、缓解措施、预防措施 —— 每个字段都填好了，每个复选框都勾选了，但在文档的最后，没人能回答唯一重要的问题：究竟是哪个变量发生了变动？不是部署事件。不是基础设施故障。不是代码变更。而是 Prompt 的修订、路由选择的模型切片、未触发报警的 Eval 评分所用的 Judge 配置、质量投诉发生时的检索索引状态、规划器（Planner）正在组合的工具 Schema 版本，或者是异常时间段内的流量组合。这些在模板里都没有对应的一行。

SRE 模板并不是为那些“事实来源是观察到的行为而非代码路径”的系统设计的。在 LLM 技术栈中默默变动的变量，正是模板从未需要列举的变量。强行借用模板，只会产生那种被归类为“持续调查中”的“我们不知道发生了什么变化”的复盘报告。

这并不是反对无责文化或 SRE 工作流。这两者都可以完美迁移。核心观点是，文档中的字段 —— 作者必须回答的明确提示 —— 需要为 LLM 系统实际具备的变量构建第二套方案。如果没有这些提示，复盘作者盯着空白的“诱因”框，只能写下“模型退化”，因为页面上没有任何字段要求他们去查看 Judge 配置。

SRE 模板缺失的六个字段

传统的 SRE 复盘将受测系统视为在给定输入、代码和配置下的确定性系统。复盘模板的“诱因”部分假设你可以通过阅读部署日志和基础设施仪表盘来识别变化。对于 LLM 系统，有六个变量超出了这个范畴，每一个都需要在文档中占据一行。

事故发生时的 Prompt 修订版本。 不是今天存在于 main 分支中的 Prompt，而是产生异常输出那一刻渲染出的 Prompt。Prompt 会通过系统提示词编辑、Few-shot 库轮换、检索上下文注入以及按请求组合的动态指令块发生演变。“我们改了几个字”在变更日志中看起来只是单行 diff；但在行为上，它可能是一次完整的重新校准。该字段必须捕获字面上渲染出的 Prompt，以及组成它的每个组件的版本 ID。

模型版本和路由切片。 单个产品表面通常通过路由器运行在多个模型层级上（廉价模型的快速路径、困难查询的高价模型兜底、合规要求的区域特定变体）。当某个切片的质量下降时，复盘需要知道受影响的请求落在了哪个切片中。“我们使用的是 Model X”这句话有两个错误：产品使用了多个模型，且受影响的用户昨天被路由到的模型可能与今天不同。

Judge 配置和 Eval 状态。 未能捕捉到退化的 Eval 套件本身也是一个系统，拥有自己的 Prompt、模型、评分标准和数据集版本。当事故暴露出 Eval 漏掉了故障时，你需要上次发布通过时的 Judge 配置快照 —— 而不是当前的 Judge 配置，因为后者可能已经在恐慌中被修改了。没有这个快照，“Eval 是在真实的损坏状态下通过的，还是 Eval 评分的对象根本就不对？”这个问题将无法回答。

检索索引状态和新鲜度延迟。 由 RAG 驱动的功能依赖于内容不断变化的索引：文档被添加、删除、重新嵌入、重新排序。复盘需要事故期间提供服务的索引版本（或 commit/快照 ID）、当时相对于事实来源的延迟，以及是否有任何部分索引重建正在进行中。“索引陈旧”是 SRE 模板视为基础设施故障的一种 Bug 类型；但在 LLM 系统中，陈旧 6 小时和陈旧 4 天会产生不同的行为，并对应不同的缓解后行动。

工具 Schema 版本和组合图。 调用外部工具的 Agent 依赖于工具目录的 Schema —— 每个工具接受什么参数、返回什么形状、携带什么权限范围。工具提供商会在不和你协调的情况下更改响应形状。一家供应商增加了一个可空字段、弃用了一个枚举值，或悄悄收紧了速率限制，都可能导致你的规划器（Planner）在两个请求之间从正常变为崩溃。复盘需要事故发生时生效的 Schema 版本，以及产生故障的具体组合（工具 A → 工具 B → 工具 C）。

流量组合和输入分布。 SRE 复盘很少记录输入分布，因为确定性系统并不以同样的方式依赖它。LLM 系统则不然：多意图查询的长尾峰值、营销邮件后冷缓存请求的异常激增、导致流量转向不同模型变体的地域转移 —— 这些都会引发看起来像模型退化但其实不是的行为事故。该字段需要事故窗口内的请求类别直方图，并与基准线进行对比。

必须增加的故障类型分类

SRE 模板通常会问“这是哪种类型的故障？”，并提供常见的选项：停机、延迟增加、数据损坏、安全事件、容量耗尽。这些都无法描述主导 LLM 生产故障的失效模式。复盘模板需要增加五种额外的故障类型，每种类型都有其专属的诊断清单。

静默质量退化 (Silent quality regression)。没有触发错误，没有违反 SLO，没有报警——但在数小时内，相当一部分用户得到的答案变差了。这是最难处理的一类，因为 SRE 监控流水线没有任何可以上报的指标。它通常通过用户投诉、支持工单激增或数天后才波及的下游产品指标暴露出来。复盘引导问题：“最早检测到这一情况的用户信号是什么？从发生到检测到之间有多长的延迟？”

评测模型导致的漏报 (Judge-induced false negative)。评测套件通过了，但模型依然上线了存在退化的版本。Bug 出在 Judge（评测模型）身上，而不是模型：Judge 的提示词没有惩罚某种失效模式；Judge 模型的偏差与候选模型的偏差一致（导致它给自信的错误答案打高分）；或者评分标准已经过时。复盘引导问题：“批准该发布的评测是否运行了最新的 Judge 配置？Judge 上次根据人工标签进行校准是什么时候？”

检索过期故障 (Retrieval staleness incident)。索引提供的是一个已经偏离真实数据源的世界观，而模型的回答与其看到的过期视图是一致的。模型的表现是正确的，是索引欺骗了它。复盘引导问题：“故障期间的刷新延迟是多少？哪些源数据变更尚未反映出来？哪些查询落在了过期的分片上？”

加载中…