第 25 篇 质量事故排查效果掉了怎么定位根因第二季第 9 篇 · 温习第 09 篇的〈三种评测与三层结构golden set 必须冻结〉、第 03 篇的〈十种失败模式〉、第 09 篇的〈漂移的三种来源〉 · 新增从监控发现掉点到定位根因的实战——假掉判定、排查决策树、按环节二分定位、变更比对法、五类高频根因、应急顺序、复盘模板、故障案例库温习第一季的三条结论第 09 篇〈三种评测与三层结构golden set 必须冻结〉衡量 AI 产品好坏需要三类评测配合并按检索 / 上下文 / 生成三层结构拆开度量用于横向对比效果的 golden set 必须冻结否则版本之间无法公平比较。第 03 篇〈十种失败模式〉LLM 的常见失败被归纳成十种模式如幻觉、越界、指令不遵循、上下文丢失等排查的第一步永远是先判断它属于哪一类失败而不是笼统地调参数。第 09 篇〈漂移的三种来源〉上线后效果会随时间漂移漂移来自三种来源数据侧变化、用户行为变化、模型侧变化第一季讲清了为什么会掉但没讲掉下来之后怎么定位到具体是哪一处变了。第一季把该用什么评测、失败有哪几类、漂移从哪来讲透了但监控告警亮起、指标真的往下掉的那一刻团队往往仍是一团乱——没人知道先查哪、怎么查、查到什么程度算查完。本篇结论先行排查的本质是二分 时间相关性——先把问题按层按段切小再用变更时间轴锁定嫌疑而不是靠拍脑袋逐环节乱试。一、先判断是真掉还是假掉三种假掉告警亮起的第一反应不应该是去修而应该是先确认它真的掉了。第一季冻结 golden set 的意义在事故排查里第一次显现你有没有一个固定基准能回答相对上周今天确实更差了吗。很多事故其实根本不是事故叫它假掉。假掉有三种对应三种不同的误判来源。① 样本波动统计意义上的噪声。评测集太小、或只看当天随机样本单日波动就会被当成趋势。今天 100 条里有 8 条失败明天 6 条后天 11 条——这未必是效果变了可能只是样本量不够、置信区间很宽。判据把时间窗口拉长如取 7 日滚动均值看是否仍在历史正常波动带内波动带应用 golden set 的历史数据来定而不是凭感觉。② 用户构成变化流量结构变了不是模型变了。一次营销活动带来大量新用户他们的问法、领域、难度分布和老用户不同整体指标被稀释或拉低。这不是效果掉了而是用户画像变了。判据把指标按用户分层新/老、渠道、地区拆开看若掉点只出现在新增的那一层基本可判定为构成变化而非质量退化。③ 指标口径被改动测的东西变了不是产品变了。最隐蔽的一种。有人悄悄改了评测 prompt、改了打分规则、把模糊匹配改成精确匹配、或把样本集换了指标自然跳变却被误读成效果崩了。判据先核对评测配置与 golden set 是否被改过确认口径一致后再谈涨跌。一张快速排除表作为告警后的第一道关卡可疑假掉类型典型误判信号2 分钟快速验证若排除则进入真掉流程样本波动只看单日/小样本未看滚动均值拉 7 日滚动均值对比历史波动带均值确实突破波动带下沿用户构成变化同期有新渠道/活动引入按用户分层拆指标看掉点是否只在新层各层普跌非构成问题指标口径改动近期有人动过评测配置/打分规则diff 评测配置与 golden set 版本口径一致变动非配置导致确认是真掉之后才进入下面的决策树。这一步平均能挡掉相当一部分事故——它们本不需要任何人去修模型。二、排查决策树从掉的是哪层出发二分第一季讲了三层结构检索 / 上下文 / 生成和十种失败模式本篇把它们接成一个可执行的排查流程。决策树的核心动作只有两个词二分和对齐时间。先从掉的是全部场景还是特定场景切第一刀再逐步收窄。下面用文本树把路径画出来再配一张路径示例表。效果掉已确认非假掉 ├─ 第一刀全部场景 vs 特定场景 │ ├─ 全部场景普跌 → 看近期是否有全局变更(模型/底座/网关) → 跳变更比对法(四) │ └─ 仅特定场景跌 → 第二刀是否对应特定失败模式 │ ├─ 是(如只幻觉/只越界) → 对照失败模式库(第03篇)定位环节 │ └─ 否(散点) → 第三刀近期有什么变更 │ ├─ 有变更且时间吻合 → 锁定变更项(四) │ └─ 无变更/不吻合 → 第四刀用户行为是否漂移 │ ├─ 是 → 问法/场景变了(五④) │ └─ 否 → 进入按环节二分定位(三)逐段替换验证路径触发条件下一步动作典型根因指向全场景普跌 有全局变更所有场景同步下滑优先查变更比对四模型/底座/网关五②单场景跌 对应失败模式只某一类问法出错查该模式相关环节检索/生成特定缺陷五①单场景散点跌 有变更掉点零散但时间吻合变更锁定变更项回滚尝试验证prompt/参数/知识库五③无变更却跌没动过任何东西也在掉查用户漂移 按环节替换上游数据/用户行为五①④决策树的价值不在画得好看而在强迫你每次只切一刀、每一刀都把搜索空间砍掉一半。最忌讳的是跳过分层直接进日志大海捞针——那等于把二分法退化成穷举法。三、按环节二分定位法把系统切成五段逐段替换验证当决策树走到无明确变更或散点就需要把端到端系统物理切开逐段用替换法验证。把一个 RAG / Agent 系统切成五段检索与召回retrieval上下文组装context assembly切分、拼接、引用生成generationLLM 调用与提示后处理post-processing格式、截断、过滤集成integration与业务系统的接口、超时、缓存替换法的原理把某一段的输出固定为已知正确的输入喂给下游看最终质量是否恢复。恢复了说明问题在被替换的那一段没恢复问题在更下游。这是比看日志猜可靠得多的定位方式。环节替换/钉死方法喂入已知正确内容观察指标若质量恢复说明若仍差说明检索与召回直接喂入人工确认正确的检索结果跳过真实检索答案是否变对问题在检索召回/排序问题在更下游上下文组装用固定好的上下文块替换动态拼接是否仍丢引用/错位切分/拼接逻辑有问题生成或后处理生成固定上下文 固定 prompt换模型或回旧模型是否随模型变化模型侧或 prompt后处理/集成后处理绕过格式/截断/过滤直接看原始生成是否因截断致错后处理裁剪过度上游集成用固定响应替代真实业务接口返回端到端是否恢复接口/超时/缓存链路前段执行纪律按上表从上往下逐段钉不要在没钉检索时就去改生成——顺序错了你可能在下游反复横跳却始终碰不到真问题。替换法最大的好处是结论可复现换个人用同样钉法会得到同样结论排查不再依赖谁的直觉准。四、变更比对法最有效也最常被跳过如果决策树或替换法都指向某次变更那变更比对法就是最快的闭环。它简单到不可思议拉出近期所有变更和指标时间轴叠在一起看先找时间相关性再谈因果。但因为它太朴素团队常常跳过它直接去调参结果花三天发现是三天前改的 prompt。要拉的变更清单至少覆盖下面几类且每类都要带时间戳变更类别具体项谁可能动时间轴比对要点prompt / 系统指令提示词、few-shot、约束规则算法/产品是否出现在掉点之前模型 / 底座模型版本、供应商、降级策略平台供应商是否同日有更新/限流检索参数TopK、阈值、重排开关、混合权重检索改动是否影响召回集知识库文档增删改、切片更新运营是否引入冲突/过期内容数据源上游接口、字段、站点改版数据/后端字段缺失或结构变化集成配置超时、缓存 TTL、网关、限流后端是否出现截断/旧缓存命中核心原则先看时间相关性再谈因果。时间吻合是必要非充分条件——变更和掉点同天发生不代表变更就是原因但它是最高优先级的嫌疑。实操上把掉点时刻往前推 0–72 小时列出所有变更按时间排序优先排查掉点前最近一次变更并用回滚或灰度验证它。更前置的防线是变更门禁任何影响效果的变更上线前后必须跑一遍 golden set 回归把变更 → 指标变化的因果证据留下来出事时不用临时翻日志。五、五类高频根因与特征把历次事故的真实根因归类高频的只有五类。把它们做成一张特征表排查时拿着症状对号入座比凭空猜快得多。根因类别典型症状快速验证方法修复动作① 上游数据变了答案突然引用旧/缺失信息知识库已更新却召回旧的比对知识库版本与源站查字段缺失重建索引/补数据/修抽取② 模型侧变了同一 prompt 输出风格/质量突变尤其降级时回滚到旧模型版本对比 golden set锁版本/关降级/换供应商③ prompt/参数副作用改了某条约束却引发另一类失败如加格式要求却丢内容逐一回退近期 prompt 改动灰度回归改完必跑 golden④ 用户行为漂移新问法/新场景涌入老评测覆盖不到看 query 分布变化新意图聚类补样本/扩知识/调路由⑤ 集成层问题偶发截断、超时、缓存命中旧结果难复现查日志超时率/缓存命中率/接口契约提超时/清缓存/修契约逐一说明① 上游数据变了。最常被误判成模型变差。源站改版、字段缺失、知识库更新后索引没重建都会让答案引用旧内容。验证要直接比库里的版本和源站现在的版本而不是只看模型输出。② 模型侧变了。供应商静默更新、自动降级到小模型、限流导致截断都会让同一 prompt 表现突变。验证靠回滚模型版本——这是为什么第一季强调要能锁版本、留回退开关。③ prompt/参数副作用。改一条约束常常捅破另一处。例如为防幻觉加了只引用给定上下文却顺带让模型不敢补全常识。验证靠逐一回退近期 prompt 改动定位是哪一条引入的副作用。④ 用户行为漂移。不是系统坏了是用户变了。新问法、新场景涌入老评测集覆盖不到指标自然下滑。验证看 query 分布对新增意图聚类决定是补样本还是扩知识。⑤ 集成层问题。最隐蔽、最难复现。超时把长回答截断、缓存命中了旧结果、网关改了字段模型本身没问题。验证看日志的超时率、缓存命中率、接口契约是否变动。六、应急与修复的顺序先止损再定位后根治事故现场和日常优化最大的区别是你没时间先研究清楚。正确顺序是止血优先于定位定位优先于根治。把一个还在流血的系统先拽回可用再去查为什么最后才谈怎么不再发生。止损手段适用情形代价注意降级切回旧模型/旧链路确认新版本劣化且可回退能力暂时下降需保留回退开关回滚撤掉某次变更变更比对锁定嫌疑变更回到上一稳定态先确认变更可逆限流限制受影响功能问题范围不清、影响面在扩大部分用户不可用配清晰告知人工兜底转人工/置提示高风险且无法快速修人力成本设触发阈值与话术止血动作的三条纪律可逆、有告知、有边界。不要用全量下线删库这种不可逆重拳去救一个局部问题降级和限流都要给用户明确提示别让用户在沉默中踩坑止血范围要圈定别顺手把无关功能也关了。定位与根治必须等止血完成后再做——一边流血一边研究只会让影响面持续扩大。七、复盘模板可直接套用每次事故结束必须有一份像样的复盘否则同样的坑三个月后再踩一次。下面给一个可直接复制填写的模板——注意它和写事故报告的区别复盘的核心不是追究人而是补系统缺口。质量事故复盘模板每次事故必填归档进故障案例库 ══════════════════════════════════ 【一、现象与影响面】 - 告警时间 / 发现人 - 影响范围场景/用户比例/请求量 - 严重程度P0-P3 - 用户可感知表现 【二、时间线】 - 首次掉点时刻 - 关键变更时间戳附变更单号 - 止血时刻 / 恢复时刻 - 定位完成时刻 【三、根因】 - 直接根因哪一段、哪一次变更 - 深层根因为什么发生/为什么没拦住 - 归属类别对应五类高频根因①②③④⑤ 【四、为什么没早发现】 - 监控缺口哪项指标没覆盖 - 评测缺口golden set 是否漏了这类 case - 流程缺口变更是否有门禁回归 【五、修复动作】 - 已做止血定位根治 - 验证方式golden set 回归结果 【六、防复发措施】 - 补进 golden set 的 case___ 条 - 新增/调整监控项 - 新增变更门禁规则 - 责任人与截止日 纪律复盘 24 小时内完成初稿措施必须可验收不接受加强关注之类空话。八、把每次事故变成资产故障案例库第一季把 LLM 的失败归成十种模式第 03 篇那是已知失败的分类法事故排查沉淀下来的案例库是把自己系统真实发生过的失败也结构化起来。两者呼应失败模式库告诉你理论上会怎么坏案例库告诉你我们这儿实际怎么坏过、怎么修好的。建库的最小字段现象摘要一句人话归属的失败模式挂到第 03 篇十类之一根因类别挂到本篇五类之一影响的环节检索/上下文/生成/后处理/集成验证方法当时怎么定位的修复动作与防复发措施关联变更单号使用纪律每次新事故先查案例库有没有类似的复盘完再回填。案例库不是档案柜是排查时的先验知识——它让第二次、第十次事故的平均定位时间持续下降而不是每次都从零开始。一页速查质量事故排查 · 一页速查 ───────────────────────── 第一步确认真掉非假掉 假掉三型样本波动(看7日滚动均值) / 用户构成变化(分层拆) / 口径改动(diff评测配置) 全都没中才进入真掉流程 决策树(二分对齐时间) 全场景普跌→查全局变更(四) 单场景跌→是否对应失败模式→是则查该环节,否则查变更/漂移 无变更仍跌→用户漂移按环节替换(三) 按环节替换法(五段)钉死某段喂已知正确输入 检索→上下文→生成→后处理→集成 逐段二分,从上往下 变更比对法拉6类变更(表四)叠时间轴,先相关性再因果,掉点前72h优先 前置防线变更门禁上线前后必跑 golden set 回归 五类根因(表五)①上游数据 ②模型侧 ③prompt/参数 ④用户漂移 ⑤集成层 应急顺序先止损(降级/回滚/限流/人工)→再定位→后根治 止血三纪律可逆 / 有告知 / 有边界 复盘模板(七)现象/时间线/根因/为何没早发现/修复/防复发 资产化每次事故回填故障案例库,挂失败模式根因类别,做排查先验常见坑不确认就修告警亮起直接去改模型结果是样本波动或口径改动白忙一场。只看单日数据没拉滚动均值把正常噪声当成趋势虚惊一场。不分用户层把用户构成变化当成质量退化去修根本没坏的东西。跳过变更比对直接调参三天后发现是三天前改的 prompt。看日志猜根因不用替换法逐段钉靠感觉定位来回试错浪费时间。没冻结 golden set版本对比无从谈起每次都说不清到底差多少。止血和定位顺序反边流血边研究影响面持续扩大。回滚不可逆止血动作没留回退开关撤了更糟。复盘写空话只写加强监控措施不可验收三月后再踩同一坑。事故不沉淀同样根因反复发生没有案例库做先验每次从零开始。结语排查不是靠经验拍脑袋逐环节试而是靠二分把问题切小 时间轴把嫌疑锁定先确认真掉还是假掉再用决策树把范围收窄到层与段用替换法逐段验证用变更比对法找时间相关性最后用复盘把每次事故沉淀成案例库——这样第二次事故的平均定位时间才会持续下降。本文为「AI 产品经理入门与进阶」系列第二季第 9 篇总第 25 篇。温习自第 09 篇《评测工程把好不好变成可测的数字》、第 03 篇《LLM能力边界与失败模式图鉴》。数据来源本篇排查决策树、替换法验证表、变更比对表、五类根因表、应急决策表与复盘模板均为可操作框架示例数值如 7 日波动窗口、P0-P3、72 小时为说明性量级非真实阈值。具体数值随技术迭代变化请以最新数据为准。