评测或运营同学常遇到这种情况：模型答得好不好，谁都能说两句，但真要写成周报、做成看板、跟上周对比，就卡在「用什么数说话」。这篇不讨论哪个模型更强，只讲怎么把响应质量拆成可采集、可比较、可复现的指标：分几层、每层量什么、口径怎么定、不适用的情况怎么标。
评测或运营同学常遇到这种情况：模型答得好不好，谁都能说两句，但真要写成周报、做成看板、跟上周对比，就卡在「用什么数说话」。这篇不讨论哪个模型更强，只讲怎么把响应质量拆成可采集、可比较、可复现的指标：分几层、每层量什么、口径怎么定、不适用的情况怎么标。
核心思路一句话：别指望一个「质量分」包打天下，先把一次响应拆成几类互不干扰的数，各自记清楚口径，再谈怎么合成、怎么比。下面按分层、采集、打分、报告四步走，每一步都给能直接照着做的做法。
先分层：一次响应能被拆成哪几类数
把响应质量分成三层来记：结果层管「能不能用、对不对」，过程层管延迟、重试、截断这类链路表现，成本层管 token 消耗与调用次数。三层各记各的，别混在一张表里，否则一个指标掉了你根本分不清是模型变差还是链路抖动。先定层，再定层里的具体项。
- 结果层
- 输出能不能直接交付给用户，细分客观项与主观项两类
- 过程层
- 从发请求到拿到完整回复之间发生的延迟、重试、截断等链路信号
- 成本层
- 单次响应消耗的 token、调用次数、以及重跑带来的额外开销
- 响应 ID
- 给每次响应绑的唯一标识，配合任务类型才能跨期比对
结果层里一定要分客观项和主观项。客观项比如格式是否合法、字段是否齐、引用能不能点开核对；主观项比如语气、可读性、信息密度。客观项可以让脚本判，主观项必须靠评分表约束，否则同一段回复换个人打就是另一个分，根本没法复现。分不清这两类的后果是：你以为在比模型，其实在比评分人的心情。
- 每条记录先绑响应 ID 和任务类型，同一批任务之间才能比，跨任务类型直接平均是最常见的错误
- 客观项和主观项分列在两张表，合成总分前先各自算完，别让主观分稀释客观分的信号
- 开放式创意任务、多轮对话中途的回复不适用单一分数，改用多项评分加文字备注
- 一个任务类型至少固定一套指标项，中途加项要标出从哪期开始，否则趋势线是假的
采集口径：采样、时间窗与失败样本怎么记
采集口径比指标本身更容易出岔子。采样上先写清是全量还是抽检、抽多少、谁来抽；抽检要写明抽样方式，随机会不会偏向某类任务，前后两期换了抽样方式数字就不可比。时间窗也要先定死，按天还是按周，同一口径至少连续跟几期再看趋势，单期波动别急着下结论。
| 口径要素 | 要写清的内容 | 常见坑 |
|---|---|---|
| 采样方式 | 全量或抽检、抽样比例、抽样人 | 两期抽样规则不同还拿来比 |
| 时间窗 | 按天/按周、统计截止点 | 月初月末天数不同导致假波动 |
| 失败样本 | 超时、报错、空回复、截断各占独立状态位 | 失败样本被排除在分母外，质量虚高 |
| 脱敏规则 | 入库前脱敏字段、原始日志保留范围 | 原始日志留太多，合规风险大 |
失败样本必须入库，而且不能和成功样本混成一个「差评」。超时是一个状态，报错是另一个状态，空回复和被截断又各是各的状态。如果它们从分母里消失，你算出来的「质量达标率」会虚高，看板上看不到问题，运营却在群里天天被用户骂。脱敏要做在落库之前，原始日志只留必要字段，具体留哪些字段可以参照站内 /safety 分区里日志与脱敏相关的文章。
打分与权重：把主观判断变成可比的数
主观项要变成可比的数，靠的是评分表而不是评分人的经验。每项给出几个档位，每档配一句可观察的描述，比如「信息完整但需要用户追问一次」对应哪一档。评分人对着描述打，而不是对着印象打。多个评分人时先做一轮交叉打分对齐口径，分歧大的项要么把描述写细，要么直接降权或从指标里去掉。
- 写评分表每个主观项列档位，每档写一句能观察到的事实描述，避免「好/较好/一般」这种没法验证的词
- 做交叉打分同一批样本让两名评分人独立打，比对分歧项，分歧集中在哪就把哪档的描述磨细
- 定权重权重按业务影响定，不按好不好算定；权重定了至少一个统计周期内不改，改了要在报告里注明从哪期生效
- 小样本处理单一评分人或样本量很小的批次，只报分布不报平均值，避免把小样本波动读成质量变化
权重这件事有个反直觉的点：越难算的项往往越该有分量。格式合法率很好算，但用户真正在意的是内容能不能直接用。所以定权重时先问一句「这项坏了，用户会不会立刻发现」，会就加权。不适用的情况也说清楚：评分人只有一个、或者这批样本量小到分布都撑不起来时，别硬算加权总分，只报各档占比就够了。
从数字到结论：报告怎么写、阈值怎么设
报告只写三件事：本期数值、与上期的差、差异的可能来源。来源不确定就写「待查」，不要为了报告好看编原因。阈值分两档设，预警线触发先复核样本，确认不是口径问题再动；停用线才触发切换或回滚。两档之间留出缓冲，否则天天触发预警，团队会直接无视告警。
- 把质量指标和延迟、可用率放在同一个视图里看，质量掉的同时延迟也动，问题多半在链路不在模型
- 每期报告固定格式，数值、差值、可能来源三段，缺哪段就标「本期缺」而不是省略
- 阈值触发后先复核样本，再决定是调口径还是动配置，别一报警就直接切
- 历史报告留档，换口径时注明生效期，不然半年后没人说得清那条曲线为什么断了一截
| 指标层 | 看什么 | 掉了先查哪里 |
|---|---|---|
| 结果层客观项 | 格式合法率、字段齐备率 | 输出解析规则或提示词约束 |
| 结果层主观项 | 各档占比、评分人一致性 | 评分表描述或评分人培训 |
| 过程层 | 延迟、重试率、截断率 | 网关、超时配置、上下文长度 |
| 成本层 | 单次 token 消耗、重跑次数 | 提示词长度或缓存策略 |
阈值具体设多少、当前各层数字长什么样，别拍脑袋，到站内页面核对当时的数字再定：价格与用量相关的看 /price-watch，链路速度相关的看 /tools/speed-test，检测报告格式可以直接套 /tools/quality-check 的模板，站点可信度对比参考 /sites 与 /rankings。定好一版就固定下来跟几期，再微调。
下一步把上面四步套到你手上的一个任务类型上，先用站内检测工具的模板跑一遍，再对着 /price-watch 和 /tools/speed-test 核对当时的实际数字，比空想指标靠谱。→常见问题
只有主观感受，能不能不建指标表直接写结论？
可以写，但只能当线索不能当结论。建议先用一张最简表把「任务类型、样本量、主要问题、出现频次」记下来，哪怕只记两周，也能看出是普遍现象还是个别案例；没有这张表，跨期比较和追责都无从谈起。
响应质量的分数能不能直接跟别的团队的数字比？
通常不能。分数受评分表、采样方式、任务难度影响，不同团队口径不同，直接比会得出相反结论。要比就比趋势：各自跟自己的历史比，并说明口径；真要横向比，先把评分表、样本量和任务类型三项对齐。
指标看起来没变化，但用户反馈变差了，怎么办？
先怀疑覆盖面：现有任务类型是否漏掉了用户实际在用的场景，失败样本是否没进分母。做法是临时加一批针对性样本做定点复测，对照原始日志确认现象，再决定是补指标还是改采集口径，别急着调阈值。
