判据必须定义在最终产物上
0次浏览0条评论0个赞
一份上线前的报告上每一层指标都是绿的：检索层说召回达标、服务层说时延达标、缓存层说命中率上升。上线第 1 周，用户仍然说「答得不对」。
「每一层都合格」的系统，端到端仍然不可用 —— 中间层的指标各自被优化，没有人对接口负责。
先说接口断在哪，再说判据该怎么写。
结论：判据挂在最终产物上，争议只在定义阶段付一次
系列占位：正文待补——判断、框架与落点先固定。先回答一个问题：为什么「每一层都合格」的系统，端到端仍然不可用？
把判据定义在最终产物上，会同时改变三件事：验收由谁执行（使用方而不是链路各段）、失败时回到哪一步（最后一段而不是第一段）、以及哪些「漂亮数字」根本不进验收表。
这不是更严格的验收，而是唯一能站住的验收 [2]；首页原则层面的第二条说的就是这件事 [3]。
骨架
-
中间指标为什么会失真：指标在链路里被逐段优化，段与段之间的接口没有人为它负责。
-
什么算「最终产物」：用户真正拿到、并且会用它做判断的那个东西 —— 不是链路里最漂亮的那个数字。
-
怎么定义：从使用方的验收动作倒推 → 写成一句可复核的话 → 指定谁在什么时候测 → 失败时回到哪一步。
-
三个反例：覆盖率很高但检索无用；时延分位数漂亮但首字抖动；精度指标达标但输出不可解析 —— 第三个反例的实测在 [1]。
-
一个对照：把同一条判据分别挂在中间层与最终产物上，验收结论会差在哪里。
小结与接下来
把判据挂在最终产物上，是一条能让争议提前结束的规则：争议在定义阶段付一次，而不是在验收阶段反复付。
下一站：当判据定了、也被测了，怎么保证”测出来的数”本身可信 —— 那是这一系列的第三篇。
参考文献
[1] 本站 · 先修量具，再谈性能：一次 8 卡推理调优复盘 — 同一类错误的另一个实例
[2] 本站 · 洞察的检验标准：五层递进，与三条能证伪的判据 — 判据要能证伪
[3] 本站 · 首页原则层面的第二条「判据定义在最终产物上」 — /#home-layer-6
相关文章
这篇的正文还没写完。
先把同一条线上已经写完的读完 —— 它们回答的是同一个问题。
评论
填个昵称就能发，不需要注册或登录