简历中的效果指标是如何测量出来的？

核心回答

我会从指标定义、数据与基线、测量过程、结果适用范围四方面解释简历上的数字，让对方能够理解它是怎样算出来的。

1. 说明测的是什么。 统计单位是请求、任务还是用户，什么算成功，分子和分母是什么，超时、失败和无法判定的样本如何处理。
2. 说明和谁比较。 数据来自什么时间、包含多少样本，旧方案是什么；对照时固定任务集和共同条件，并记录模型、Prompt、代码、知识库等实际版本。
3. 说明怎么得到结果。 由执行日志、评分脚本或人工评审逐条判定，再汇总。耗时要区分平均值、P95 和测量起止点；质量评分要说明是客观验收，还是按统一标准进行的人工或模型评分。
4. 说明数字能代表什么。 离线测试结果与线上真实流量分开，报告样本量、重复测量及波动范围；线上变化还要结合对照条件判断原因。

例如，假设同一组 100 条任务中，旧版通过 70 条、新版通过 80 条，通过率就是从 70% 到 80%，提高 10 个百分点，相对提升约 14.3%。还需要解释任务来源、通过标准和两版配置，才能说明这个改善适用于什么场景。

展开说明

1. 先把简历里的一个指标定义完整

以“问数准确率提升”为例，可以把指标定义为：在预先确定的适用任务中，最终查询结果满足参考口径的任务数，除以纳入评测的任务总数。成功判定可以检查数值、时间范围、分组维度和必要字段；SQL 能执行，只能说明执行层面通过，不能直接说明回答正确。

分母要在测量前确定。纳入后发生超时或执行失败的任务应按已约定规则计入结果，不能只在成功返回的请求中计算“总体成功率”。不适用、重复、用户取消或无法判定的样本也要有一致处理方式，并给出相应数量，避免两版采用不同排除条件。

数据来源应说明采样时间窗口、任务类型和样本数量。真实日志、人工构造和合成样本可以组合，但要知道各占多少，是否覆盖简历声称的业务范围。同一任务跑多次，还要区分“多少个不同任务”和“多少次执行”；取最好一次得到的分数，不能直接代表每次使用时的稳定性。

2. 保留基线、版本和逐条结果

基线可以是上一个稳定版本、原有规则方案或改动前的流程，要说明它原来达到什么水平。比较新版时，用同一批任务、参考答案和评分规则；调参使用的数据与最后验收的数据分开，避免一直按测试题优化。

除模型名称外，还应记录实际使用的模型版本或可追溯配置、完整 Prompt、代码版本、检索参数、知识库或数据库快照。数据采集窗口、评测执行时间也要分别说明：同样的问题在不同时间查询到不同数据，变化可能来自数据本身。对实时网页或外部 API，可以保留当时的内容快照或响应，另行衡量访问实时信息的能力。

比较耗时还要记录硬件、并发、输入长度、缓存是否预热、重试及外部服务条件。若想测某项改动的贡献，就尽量只改变该项，或做拆分对照；若同时换了模型、Prompt 和检索方案，测得的是这套新版本的整体变化。

逐条结果可以关联任务 ID、版本、输入、原始输出、开始结束时间、评分与判定依据。汇总脚本从这些记录计算指标，后续就能查看哪些任务改善、哪些退化，以及是否存在漏记或重复计数。

3. 把提升比例和耗时口径算清

沿用前面的假设算例，通过率的绝对变化是 80% - 70% = 10 个百分点；相对提升是 (80% - 70%) / 70% ≈ 14.3%。如果改报“未通过率下降”，旧版为 30%，新版为 20%，相对下降又是 (30% - 20%) / 30% ≈ 33.3%。它们描述同一组结果的不同侧面，表达时应写明口径。

耗时也要先定义起止点。例如报告任务可从服务收到请求计到结果文件可交付；模型首 Token 延迟只测用户何时看到第一段输出。若同条件下平均耗时从 20 秒变为 12 秒，按这个假设计算就是平均耗时下降 40%，并不同时说明吞吐或尾部延迟改善了多少。

平均值是各请求耗时之和除以请求数；P95 描述较慢一端的分布位置。采用最近秩法时，100 条有效耗时从小到大排序，取第 95 条；实际报告还要说明所用统计方法。平均值下降而 P95 变差，可能意味着少数用户等待更久，因此两者值得同时观察。

成功、失败与超时的耗时应分别报告。超时请求通常只知道等待已达到超时阈值，不能把它当成已正常完成的真实耗时，也不能静默删除后只报成功请求的平均值。多机器或多批次统计时，应合并原始分布或相容直方图，不能简单平均各自的 P95。

4. 客观验收与主观评分分别说明

有明确结果的任务，优先检查实际产物。例如问数对照同一数据快照下的参考结果，文件处理检查内容和格式，业务操作检查最终状态。规则本身也要验证，避免把等价正确答案判错。

报告可读性、分析完整性等开放式质量，可以由人工按评分表判定，但应说明维度、分档锚点、评审人数和抽样方式。例如“结论有依据且覆盖要求”与“表达流畅”分别评分，评审时尽量隐藏版本标签；有分歧的样本再核对依据。人工评分可以被规范和复核，不等于随意凭感觉打分。

使用 LLM-as-Judge 时，同样固定评分提示词和评委模型配置，用人工标注样本校准，并保存评分理由。模型给出的 4.2 分或平均偏好分，应称为相应评分，不能直接改称“客观准确率”。

5. 离线结果、线上结果与波动范围

离线固定任务集便于逐条比较版本，结论应带上数据范围。线上指标来自真实使用，还会受到用户构成、时间、流量、缓存和外部服务变化影响。如果要判断新版造成了什么变化，可以在合适的随机化单位上设置同期对照组，预先确定主要指标，并同时观察质量、延迟和错误率等相关变化。

例如同一用户会连续多轮交互，分组时就要考虑会话和用户的一致性；企业内用户可能互相影响时，还需考虑更高层的分组。单纯拿上周和本周的均值比较，可以描述观察到的变化，但对原因的解释会受到这些条件变化的限制。

报告时给出样本数、分层结果及合理的不确定性估计。离线同题对照应按任务配对分析，重复执行要考虑同一任务内的相关性；线上统计也要与随机化单位一致。100 条里多通过 10 条是一个观察结果，是否足够稳定，还要看逐条改善与退化、样本分布和实验设计，不能仅凭百分比断定。

常见追问

只有人工抽检，能否形成效果指标？

可以。说明抽了哪些样本、如何抽样、谁按什么规则判断，以及无法判定和评审分歧怎样处理。结果代表的是该抽样与判定条件下的表现；样本很少时，给出数量和波动比报很多小数位更有帮助。

面试官问“这个数字怎么测的”，怎样简洁回答？

按“任务与口径—数据与基线—运行和评分—结果与范围”讲一条完整链路。例如：“在同一批留出任务上，对旧版和新版使用相同参考规则逐条验收，保存配置和运行结果，再统计通过数与总数；耗时从请求进入到结果可交付计算，并同时看平均值与 P95。”随后补上自己实验的实际样本量和结果。

测量结果很好，为什么用户仍觉得不好用？

先核对测量覆盖的是不是用户当前的任务，以及采样分布、数据时间和评分标准是否匹配。再看是否只统计成功请求、只看平均值，或把格式通过当成内容正确。回到具体失败记录，比继续增加一个汇总分数更容易找出差异。

对应教程

参考资料