命中质量而非数量
除了命中率，还要看命中后的纠错率与投诉量。为什么：命中率可以通过放宽阈值提高，但代价是错误答案。做法：把纠错率作为一级指标，与命中率同屏展示；边界是纠错来源要可归类，否则无法判断是缓存问题还是知识问题。
路由分布与漂移
按模型统计请求分布，出现明显偏移要追查原因。怎么做：设基线并做同比告警；边界是业务结构变化也会导致偏移，需与业务日历对照，避免把正常波动当成故障，也不要把故障当成正常波动。
容量与驱逐
关注内存水位、驱逐速率与热点键分布，驱逐突增往往意味着容量不足或键设计有问题。为什么重要：驱逐会直接拉低命中并抬高后端压力。做法：设水位告警并预留扩容路径；边界是扩容有延迟，突发流量要靠限流兜底。
失效执行审计
每次知识或权限变更都应触发失效，并记录影响范围与执行结果。怎么做：把失效做成可查询的任务，失败要重试并告警；边界是批量失效可能造成短时穿透，需错峰执行并观察后端水位变化。
配置变更与回退
阈值、规则与开关的变更要留版本、走灰度、可一键回退。为什么单列：多数线上问题来自配置改动而非代码缺陷。做法：配置中心化并记录操作人；边界是回退要能在分钟级完成，否则故障期间只能干等。
适用与不适用
适合谁
- 已上线缓存或网关、需要建立值班机制的团队
- 多业务共用一套策略、需要防止互相影响的平台部门
- 要把优化效果持续运营下去的产品负责人
不适合谁
- 只有演示环境、没有线上流量的项目
- 不接受配置版本管理、习惯直接改生产的小团队
典型场景
某出行平台的智能客服在一次阈值调整后投诉上升，值班先回退了配置，再查看命中质量看板，发现新阈值把一批多义问题合并了。团队随后把阈值变更纳入灰度流程，先在单个城市生效，观察一天后再扩大范围，并把回退操作写进了值班手册。
可执行步骤
- 把命中率与纠错率放在同一张看板上，按业务线分别同屏展示并告警
- 为路由分布设置基线与同比告警，出现偏移时对照业务日历核对原因
- 监控内存水位与驱逐速率变化，预留扩容路径、限流兜底方案并演练
- 把缓存失效做成可查询的任务，失败自动重试并告警到值班人手机上
- 配置变更走灰度并保留一键回退，逐条记录操作人与时间戳信息和理由
常见坑
- 只看命中率不看纠错率，阈值被不断放宽，错误答案增加却没人负责，最后只能整批回滚停用缓存。
- 驱逐速率突增却没有告警，后端压力上来才发现缓存已失效，排查方向一开始就错，白耗一整天。
- 批量失效安排在业务高峰执行，短时穿透把后端打满，原本稳定的服务被迫限流、报警并降级处理。
- 配置改动没有版本记录，出问题无法定位到具体变更，只能整站回滚，影响面被放大好几倍且无人认领。
自检与验收清单
- 是否把命中率与命中之后的纠错率放在一起监控
- 路由分布是否设置基线、同比告警与复核责任人
- 驱逐速率与内存水位是否都已设置阈值与告警
- 缓存失效任务是否可以查询、重试并追溯到责任人
- 配置变更是否可以一键回退，并记录操作人与时间
常见问题
命中率下降一定是故障吗？
不一定。知识库结构调整、业务问法变化、模型升级都会让命中率变化。先看纠错率与投诉量，再对照变更时间轴；如果质量没有下降，命中率波动可以接受，不必急着调阈值。
告警多了会不会麻木？
会。建议按影响分级，只对影响用户的问题发即时告警，其余进日报。告警要带定位信息与建议动作，否则值班只能先问人。定期回看告警有效率，把长期无效的规则删掉。
回退要准备到什么程度？
至少做到配置可版本化、回退有脚本、操作有记录、责任人有名单。回退演练要覆盖缓存不可用与阈值错误两类场景并记录耗时。只写在文档里的回退方案，在故障时基本用不上。