命中率要拆维度
整体命中率好看，可能是因为少数高频问题贡献了大部分请求。怎么做：按业务线、租户与问题类型分别统计，再看长尾部分的命中情况；边界是命中率不是越高越好，靠放宽相似阈值刷出来的命中会把错误率一起推高。
路由准确率
路由把请求分给不同模型，准确率指分到能力匹配模型的请求占比。怎么测：用标注样本回放，比较路由结果与人工判定；边界是规则路由与模型路由各有盲区，复杂请求应保留人工兜底或升级通道，不能让路由决定最终质量。
陈旧率
缓存里的答案在知识更新后是否仍被返回，是可信度的关键。怎么做：为缓存条目记录来源版本，知识变更时按标签批量失效；边界是失效策略过粗会造成命中率骤降，需要在准确与成本之间定阈值，并定期抽样核对。
降级成功率
主模型超时或缓存不可用时，系统能否按预案降级并给出可接受的回答。为什么重要：缓存与路由增加了链路环节，任何一环故障都会放大。做法是定期注入故障验证降级路径，记录降级期间的用户反馈与人工介入量。
单位请求成本
把缓存、网关、向量化与运维成本按请求数摊开，才能判断投入是否划算。怎么做：按业务线归因，区分固定成本与随量变化的成本；边界是语义缓存的向量化调用本身有成本，命中率低时可能越用越贵，应设开关按业务启用。
适用与不适用
适合谁
- 已上线语义缓存或模型路由、需要证明效果的产品团队
- 要为优化项目申报资源、需要指标依据的负责人
- 承接多租户业务、需要按客户核算成本的服务商
不适合谁
- 尚未上线、连基础调用量统计都没有的团队
- 只关心功能是否可用、不做成本核算的项目
典型场景
某在线教育平台的答疑入口接入语义缓存与多模型路由。运营先按学科与问题类型拆命中率，发现数学题命中高、开放问答几乎不命中；又用标注样本回放路由，发现长问题被频繁分给小模型。团队调整阈值与长度规则后重新测了一轮，才把看板口径固化下来。
可执行步骤
- 确定统计口径与拆分维度，写入看板指标说明并组织业务方评审确认
- 用近三个月的历史请求做回放并建立首轮基线，记录样本量与时间窗
- 标注一批覆盖各类型的样本回放路由，统计分错、漏分的比例及原因
- 注入超时与缓存失效故障，验证降级路径并记录用户可见提示与耗时
- 按业务线做成本归因并定期复算，形成月度可对比的报表与结论口径
常见坑
- 只看整体命中率，长尾问题全部穿透到后端，成本没有降下来却以为缓存已经发挥了作用。
- 为提升命中率而放宽相似阈值，答非所问的比例上升，用户投诉反而增加，最后只能整体回退。
- 知识更新后不失效缓存，旧答案持续返回，业务方对系统失去信任，宁可不用也不愿继续反馈。
- 路由规则写死在代码里，每次调整都要走发版，错过业务高峰的调优窗口，只能事后补救并复盘。
自检与验收清单
- 指标口径与拆分维度是否书面化并经业务方确认
- 是否用近三个月的历史请求建立了首轮基线数据
- 路由是否有标注样本验证分错与漏分的具体比例
- 知识更新是否会触发相关缓存批量失效并留痕
- 成本是否按业务线归因，是否按月定期复算并留档
常见问题
命中率多高算合格？
没有通用标准，要看业务重复率与错答代价。高频重复的客服问答可以较高，开放咨询与创作类偏低。建议先测出基线与纠错率再定目标；只看命中率容易把错误答案也算成成绩。
语义缓存值得上吗？
在问题表达多样但语义重复的场景有效，比如制度问答与产品参数。它对阈值敏感，需要标注样本调参，还要算向量化调用的额外成本。低命中业务上语义缓存往往不划算。
路由用规则还是用模型？
多数场景先用规则，覆盖已知的任务类型与长度特征，再把边界交错的请求交给模型或人工。纯模型路由难以解释，出问题时不易复盘；规则加人工兜底更稳，也便于逐步调优。