唯命中率论
命中率高不代表有效，靠宽松阈值换来的命中会带来错答。为什么常见：命中率最容易统计，也最容易被要求作为考核项。纠正方式是同时看纠正率与投诉量，把命中率与准确率放在一张看板上，任一项恶化都要回退阈值。
路由当负载均衡
路由的目标是能力匹配，不是把请求平均分配。怎么区分：负载均衡看资源水位，路由看任务难度与模型特长。边界是缺少难度判定时，宁可规则优先加人工兜底，也不要用随机分配掩盖问题，否则出错后无法复盘。
缓存键忽略权限
缓存键只拼问题文本，不拼租户与权限，A 用户可能读到 B 的答案。为什么危险：这类问题在测试中很难发现，上线后才暴露。做法是键里包含租户、角色与知识库版本；边界是权限变化时要主动失效，不能等自然过期。
假定必然省钱
缓存有资源、向量化与人力成本，命中率低时总支出可能上升。怎么做：上线前算净收益，上线后按月复算；边界是把缓存当默认项而不做测算，等于把优化变成新的固定成本，越用越难解释这笔投入。
只有一层缓存
单一层级的缓存要么太靠近业务难以共享，要么太集中容易成为单点。为什么分层：热点与长尾的访问特征不同。做法是热点放近端、共享放集群，并统一版本号；边界是层级增加后失效传播更难，要有统一的失效事件通道。
适用与不适用
适合谁
- 已上线缓存或路由、需要复盘效果的产品与运维团队
- 准备引入语义缓存、想先避开常见坑的技术负责人
- 要把优化效果向管理层汇报的负责人
不适合谁
- 尚未有稳定调用量、缓存还谈不上优化的业务
- 只接受正面结论、不愿做对照指标的项目
典型场景
某政务热线助手在高峰期频繁返回旧政策口径，排查发现缓存键只有问题文本，政策更新后未失效，不同区县的权限差异也被忽略。团队改为键里包含地区与知识版本，政策变更触发批量失效，并把命中率与纠错率放到同一张周报里评审。
可执行步骤
- 梳理缓存键应当包含的维度并组织评审，逐项标明取舍理由与依据文件
- 为命中率配一个准确率对照指标，两者同屏展示并分别设置告警阈值
- 明确路由依据，并把规则与模型的分工写进配置说明和评审记录之中
- 建立知识变更触发缓存失效的通道，执行失败要重试并告警到值班人
- 按月复算缓存的净收益并决定去留，结论提交业务负责人确认并签字
常见坑
- 只报命中率不报纠错率，管理层以为优化成功，实际投诉在增加，问题往往很久才被发现。
- 缓存键不含租户与角色，跨用户返回答案，已属于数据泄露，影响远超性能问题本身的范围。
- 政策或制度更新后只靠自然过期，旧口径持续返回，业务方逐渐不敢再用这套系统来作答。
- 把路由写成随机分配，复杂问题被频繁分给小模型，答非所问的比例上升且难以追溯原因。
自检与验收清单
- 缓存键包含哪些维度是否评审过并写明理由要求
- 是否把命中率与准确率放在同一张看板上对照
- 知识变更是否触发缓存失效，过程是否可以追溯
- 路由依据是否书面化，出问题能否逐条复盘归因
- 缓存净收益是否按月复算并留下书面结论材料
常见问题
命中率高就说明缓存有效吗？
不一定。命中可能来自放宽阈值带来的错误匹配，表面省了调用，实际增加纠正成本。判断要看命中后的纠错率与投诉量，两者同时改善才算有效，否则应先收紧阈值再谈优化。
缓存键要不要带用户标识？
涉及个人数据或权限差异时必须带。键里应包含租户、角色与知识库版本，权限变化时主动失效。只按问题文本做键，在多租户场景下极易出现跨用户返回，属于数据泄露。
路由能用大模型来判断吗？
可以，但要有兜底与可解释记录。模型判断本身有延迟与成本，也可能把简单问题分给大模型。常见做法是规则优先覆盖高频类型，剩余请求再交给模型判断，并保留人工升级通道。