在 AI 广泛应用之前测量一个系统的能力通常意味着人工打标、抽样统计和专家评审。到了大模型阶段这套做法突然变得不够用了模型可以在几小时内处理上万条文本、代码和对话但同一批样本跑两遍结果可能不同基准测试分数很高落地到业务场景却频繁出错。于是出现了“AI 时代的测量革命”The Measurement Revolution in the Age of AI这类讨论。核心问题不是模型能不能给出答案而是我们能不能对模型的输出做可信的测量并从中得到可信的推断。这篇文章从“测量革命”切入目标很具体带你把一条最小可复现的模型评估流水线跑通内容包括评估指标怎么选、测试集怎么设计、批量推理怎么写、置信区间和显著性检验怎么做以及分数不稳定、基准泄漏、结论翻转这些问题该按什么顺序排查。适用读者是正在做大模型应用的开发者、算法工程师以及需要根据指标做技术决策的产品和技术负责人。读完以后你可以把同一套方法用到文本分类、信息抽取、RAG 问答、Agent 任务评估等场景至少不会再拿 30 条样本的准确率去决定一个模型能不能上线。1. 先理解 AI 时代的“测量革命”到底在解决什么问题1.1 测量革命有两层含义用 AI 测量测量 AI“测量革命”这个词容易让人误解成“AI 来了测量问题自动解决了”。实际上它包含两个方向。第一个方向是“用 AI 做测量”。过去统计一篇客服工单属于哪个分类需要人工读文本、打标签、复核现在可以用模型批量判断。过去做用户反馈分析需要抽几百条样本人工编码现在可以用 Prompt 让模型输出结构化标签。测量成本降低了测量规模变大了这是革命性的一面。第二个方向是“测量 AI”。模型本身是一种新的测量对象。它不像普通软件那样有确定的输入输出映射同一个问题温度不为 0 时每次答案都不同同一个模型换一个 Prompt 表述能力表现可能差别很大。我们需要一套方法去回答“这个模型或这套 AI 系统到底行不行”。这两个方向叠加才是完整的测量革命我们既要用模型去替代部分人工测量又要对模型本身进行可信测量。如果只看到第一层很容易把评估简化为“跑几个 benchmark 得分”忽略了第二层里最麻烦的可信性问题。1.2 可信测量要回答的三个问题指标、样本、推断任何可信测量最终都要回答三个问题。第一指标是什么。也就是“好”怎么定义。文本分类可以用准确率、精确率、召回率问答可以用答案正确率生成任务可以用人工评分或 LLM-as-a-Judge。指标定义不清楚后面所有数字都没有意义。第二样本是什么。指标必须在一个具体的样本集合上计算。这个集合是否覆盖业务场景难度是否合理有没有和模型训练数据重叠样本集合决定了测量结果能推广到哪类场景。第三推断怎么做。我们永远无法在一个时刻测完所有可能的输入只能测一个有限样本。要从样本上的指标推断系统在总体上的表现必须引入置信区间、显著性检验这类统计工具。否则就会出现“A 模型比 B 模型高 2 个百分点到底是不是随机波动”这种无法回答的问题。实际项目里很多评估报告只写了第一个问题第二个问题靠“随便抽几百条”第三个问题直接忽略。这正是“可信测量”要补的部分。1.3 为什么基准分数高不等于业务可用假设你在公开榜单上看到一个模型某项任务分数比另一个模型高 5 分就把它选为线上模型。这样做的风险至少有三种。风险一是数据泄漏。公开基准的测试集可能出现在模型训练数据里模型相当于提前看过答案分数虚高。学术上叫 contamination业务上叫“模型背过题”。风险二是分布偏移。公开基准里的文本风格、领域、难度和你的真实业务数据往往不同。线上用户不会按测试集的套路说话评测分数自然无法代表线上效果。风险三是测量本身有噪声。大模型输出带随机性测试集只有几十条评估器本身也可能漏判最后得到的差异很可能是噪声而不是真实差异。所以可信测量的重点不是追求一个看起来很漂亮的分数而是让分数背后有一整套可辩护的过程指标是怎么定义的、样本是怎么来的、差异是否通过了统计检验。这就是本文要构建的最小可信测量流水线。2. 可信测量的地基把指标、校准和统计推断放在同一张图上2.1 指标选择准确率之外还有哪些常用口径不同任务适合不同指标。先看一个典型的分类任务。假设模型要把客服工单分成“退货”“换货”“退款”等类别评估时会产生四类结果真正例、假正例、真负例、假负例。基于这四类结果可以定义准确率Accuracy预测正确的样本数除以总样本数。类别均衡时直观类别不均衡时容易被多数类带偏。精确率Precision预测为某类的样本中确实属于该类的比例。衡量“判得准不准”。召回率Recall真实属于某类的样本中被正确预测出来的比例。衡量“找得全不全”。F1 分数精确率和召回率的调和平均。两者都重要时使用。对于文本生成或问答类任务还有另一套口径Exact Match模型输出和参考答案完全一致才算对适合短答案、代码生成等场景。ROUGE / BLEU基于 n-gram 重叠的文本相似度适合摘要、翻译但对语义改写不敏感。LLM-as-a-Judge用一个更强的模型按评分标准给输出打分适合开放性生成任务但需要先验证裁判模型的稳定性。人工评分成本最高、通常最可信适合小样本验收。指标不是越多越好。关键是一开始就明确任务目标再选定一两个核心指标和两三个辅助指标。核心指标用于决策辅助指标用于解释。2.2 基准测试与数据泄漏模型“背过答案”怎么办数据泄漏是评测中最隐蔽的问题。它不一定是故意作弊而是模型训练语料本身就包含了公开数据。你在某个公开评测集上测出一个高分可能只是因为这个测试集已经在预训练阶段被模型看到过。判断是否存在泄漏常用的检查方式有几种把测试集中若干条原文喂给模型观察它是否表现出明显记忆痕迹例如能续写出非常具体的人名、数字和来源。检查测试集发布时间和模型训练数据截止时间。如果测试集发布于模型训练截止之后泄漏风险较低否则需要警惕。在内部业务测试集上复跑同一条评测对比公开集和内部集的分数差异。差异过大时优先怀疑公开集存在泄漏。所以生产环境评估应该以自建业务测试集为主公开基准只作为参考。自建测试集的数据应该来自真实业务日志并且用一定的时间窗口隔离例如取 3 月之前的线上数据做测试集避免和近期模型蒸馏或微调数据混在一起。2.3 校准模型说 90% 可信真的可信吗很多模型接口会返回概率或置信度例如“这个工单有 92% 的概率属于退款”。这个数字是否可信取决于模型是否被校准过。校准的定义是在所有模型认为置信度为 p 的样本中真实正确的比例也应该接近 p。如果模型说 90% 可信的样本里实际正确率只有 60%说明模型过度自信反过来如果置信度很低但正确率很高说明模型过度保守。评估校准有一个常用做法把样本按置信度分桶例如 0-0.5、0.5-0.7、0.7-0.9、0.9-1.0分别计算每个桶的平均置信度和真实准确率然后画校准曲线或计算 ECEExpected Calibration Error。对大模型尤其要小心很多模型并不会给出真正经过校准的概率特别是使用了 temperature 采样之后概率分布会被拉平或压缩。需要把它当作“分数”而不是“概率”来解读。如果业务要基于置信度做阈值判断例如“低于 80% 转入人工”一定要先用自建测试集验证这个阈值的真实精确率和召回率。2.4 统计推断从 30 条样本到 95% 置信区间假设你在 30 条测试样本上得到准确率 90%也就是 27 条正确。能不能说系统真实准确率就是 90%不能。30 条样本的估计波动很大单点估计没有表达不确定性。正确的做法是计算置信区间。最常用的方法之一是自助法Bootstrap从已有结果中做有放回抽样重复成千上万次每次计算一个准确率再取这些准确率的 2.5% 和 97.5% 分位数得到 95% 置信区间。它的思想是模拟“如果我们换一批类似的样本结果可能落在哪里”。另一个常用工具是显著性检验。比较两个模型时不能只看点估计要判断差异是否可能是随机波动造成的。对于分类结果McNemar 检验是常见的配对检验方法因为它考虑的是两个模型在同一批样本上“一个对一个错”的不一致情况。这两类工具下文都会给出可以直接运行的代码。3. 搭建最小可信测量环境依赖、测试集和评估器3.1 Python 依赖与运行环境为了跑通下面的流水线需要一个能调用大模型的 Python 环境。推荐使用 Python 3.10 或更高版本并先创建一个虚拟环境。下面的示例使用 OpenAI 兼容接口可以替换成本地部署的 vLLM、Ollama 或其他兼容服务。python -m venv .venv source .venv/bin/activate # Windows 下使用 .venv\Scripts\activate pip install openai numpy scipy三个依赖的用途openai调用 OpenAI 兼容的模型接口。不同服务商的接口差异已经很小大部分兼容/v1/chat/completions。numpy用于计算指标和自助法置信区间。scipy用于 McNemar 检验计算二项分布概率。如果还需要统计精确率和召回率可以安装scikit-learn但为了展示内部原理本文会手写这些计算。注意安装依赖时不要固定猜测版本。落地前先执行pip list确认openai、numpy、scipy的实际版本并阅读对应版本的接口变更说明尤其是openai客户端从openai.ChatCompletion.create改为client.chat.completions.create之后旧代码需要相应调整。3.2 测试集设计覆盖正常、边界和对抗三种样本测试集是整个评估的地基。设计时至少覆盖三类样本。第一类正常样本。来自真实业务日志难度适中代表系统日常面对的大多数输入。数量要够这是指标的主干。第二类边界样本。输入格式不规范、缺少关键信息、意图模糊、长度极端。这类样本最容易暴露系统的稳定性问题。第三类对抗样本。指刻意构造的、容易让模型出错的输入例如相似但不同类别的文本、带误导信息的句子、混合多个意图的长文本。对抗样本不应该占到很大比例否则会过度拉低分数但至少要有一批来检验鲁棒性。测试集应该保存为带结构的数据文件。推荐 JSONL 格式每行一个样本。下面是一个客服工单分类任务的示例{id: case-001, input: 我昨天买的手机屏幕碎了想换一台新的, expected: 换货} {id: case-002, input: 订单还没发货能取消吗, expected: 退款} {id: case-003, input: 退换货地址在哪里运费谁出, expected: 退货} {id: case-004, input: 你们客服电话多少我要投诉, expected: 人工客服}每行包含四个字段唯一 ID、模型输入、期望结果、可选的难度标签。expected字段后续用于计算准确率、精确率、召回率等指标。3.3 选自己写评估器还是用评估框架现在有不少评估框架例如 DeepEval、RAGAS、promptfoo它们封装了测试集管理、指标计算和报告生成。是否值得引入取决于团队阶段。学习阶段建议自己写最小流水线。因为评估的难点不在框架 API而在“指标定义是否合理、样本是否可靠、差异是否显著”。自己写一遍能看清每个数字是怎么来的。生产阶段可以引入框架。这时候团队已经知道自己的评估口径框架可以帮我们自动化跑回归、生成报告、对接 CI/CD。但要注意框架自带的评分器不一定适合你的业务例如用通用 LLM 裁判给专业客服话术打分可能和人工判断偏离很大。框架只提供通道标准和验证责任仍然在团队自己。4. 实现一条可复现的“测量与推断”流水线4.1 项目结构与数据格式下面的最小项目只有四个文件llm-eval/ ├── requirements.txt ├── data/ │ └── test_cases.jsonl ├── eval_metrics.py └── run_evaluation.pytest_cases.jsonl上一节设计的测试集。eval_metrics.py指标计算、自助法置信区间、McNemar 检验。run_evaluation.py调用模型推理、保存结果、输出报告。先把测试集放到data/test_cases.jsonl然后定义一个读取函数。这里不直接依赖 pandas保持依赖最小。import json def load_cases(path: str) - list[dict]: cases [] with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if line: cases.append(json.loads(line)) return cases读取后不要立刻跑模型先打印样本数量、类别分布。类别极端不均衡时要调整指标或采样方式。4.2 定义任务、提示词和模型调用封装下面示例的任务是客服工单分类。模型的系统提示词要求只输出类别标签方便后续做 Exact Match 或归一化比较。from openai import OpenAI client OpenAI( api_keyYOUR_API_KEY, base_urlYOUR_COMPATIBLE_ENDPOINT, ) SYSTEM_PROMPT ( 你是一个客服工单分类器。 根据用户输入从以下类别中选择一个输出退货、换货、退款、人工客服。 只输出类别名不要输出其他内容。 ) def classify(text: str, temperature: float 0.0) - str: resp client.chat.completions.create( modelyour-model-name, temperaturetemperature, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: text}, ], ) return resp.choices[0].message.content.strip()这里的关键点是temperature0.0。分类任务希望输出稳定所以把采样温度降到最低。注意temperature0.0也不能保证绝对稳定因为部分推理后端仍可能引入并行采样或内核层面的随机性但通常已经能显著降低波动。如果模型可能输出空白、多余标点或不在类别内的值后处理要做归一化去空格、去标点、统一大小写。类别多了之后建议在代码里写一个合法类别集合如果输出不在集合内记录为UNKNOWN这些样本在分析时单独看。4.3 批量推理与结果采集批量推理时要考虑三个工程问题失败重试、并发控制、结果持久化。生产环境不能因为一次网络超时就让整个评估中断。import json import time def run_evaluation(cases_path: str, results_path: str, delay: float 0.2): cases load_cases(cases_path) results [] for case in cases: for attempt in range(3): try: pred classify(case[input]) break except Exception as exc: print(fcase {case[id]} attempt {attempt 1} failed: {exc}) if attempt 2: pred UNKNOWN else: time.sleep(1.5) results.append({ id: case[id], input: case[input], expected: case[expected], prediction: pred, }) print(f{case[id]}: expected{case[expected]}, prediction{pred}) with open(results_path, w, encodingutf-8) as f: for r in results: f.write(json.dumps(r, ensure_asciiFalse) \n) return results示例里故意没有做并发请求原因是并发会引入参数调整成本和限流风险。真实测试集可能很大生产评估建议自己维护一个可控的并发池并把每次请求的重试次数、超时时间、日志全部落到单独文件里。结果保存为 JSONL 以后指标计算和结果分析可以分开执行不必每次重跑模型。4.4 计算指标、置信区间和显著性检验先计算基础指标。下面用手写方式实现二元分类的精确率、召回率和 F1以“退货”类为例其他类别按同样逻辑扩展。import numpy as np def compute_binary_metrics(results: list[dict], target: str) - dict: tp sum(1 for r in results if r[prediction] target and r[expected] target) fp sum(1 for r in results if r[prediction] target and r[expected] ! target) fn sum(1 for r in results if r[prediction] ! target and r[expected] target) precision tp / (tp fp) if tp fp 0 else 0.0 recall tp / (tp fn) if tp fn 0 else 0.0 f1 2 * precision * recall / (precision recall) if precision recall 0 else 0.0 return { target: target, precision: precision, recall: recall, f1: f1, tp: tp, fp: fp, fn: fn, }总体准确率可以单独计算然后用自助法给出置信区间def compute_accuracy(results: list[dict]) - float: correct sum(1 for r in results if r[prediction] r[expected]) return correct / len(results) if results else 0.0 def bootstrap_ci(results: list[dict], n_bootstrap: int 2000, seed: int 42) - tuple: rng np.random.default_rng(seed) n len(results) accuracies [] binary_scores np.array([1.0 if r[prediction] r[expected] else 0.0 for r in results]) for _ in range(n_bootstrap): sample rng.choice(binary_scores, sizen, replaceTrue) accuracies.append(sample.mean()) lower np.percentile(accuracies, 2.5) upper np.percentile(accuracies, 97.5) return round(lower * 100, 2), round(upper * 100, 2)比较两个模型时用 McNemar 检验。它只需要两个统计量模型 A 错而模型 B 对的样本数以及模型 A 对而模型 B 错的样本数。from scipy.stats import binom def mcnemar_p_value(results_a: list[dict], results_b: list[dict]) - float: b 0 # A 错B 对 c 0 # A 对B 错 for ra, rb in zip(results_a, results_b): correct_a ra[prediction] ra[expected] correct_b rb[prediction] rb[expected] if not correct_a and correct_b: b 1 elif correct_a and not correct_b: c 1 if b c 0: return 1.0 # 双侧检验 p 2 * binom.cdf(min(b, c), b c, 0.5) return min(p, 1.0)McNemar 检验的直觉是两个模型有分歧的样本数固定为 bc如果两个模型能力相同分歧应该大致对半开。如果 b 远大于 c说明模型 B 在模型 A 出错的地方表现更好这种差异不太可能是偶然。p 0.05通常被认为是显著差异但这只是一个约定业务上还要结合差异大小和成本判断。5. 关键参数与配置采样、温度、样本量和随机种子5.1 temperature 和 top_p随机性从哪里来大模型推理时temperature和top_p控制输出的随机性。对评估尤其重要因为你不能在一个抖动很大的条件下做测量。temperature越低概率分布越尖锐模型越倾向于选最高概率的 token越高分布越平输出越多样。评估类型任务通常设 0生成类任务要按真实业务环境设置不能因为追求稳定就长期用 0因为线上用户可能见到完全不同的生成分布。top_p是核采样参数只从累计概率达到 p 的 token 集合中采样。实践中建议二选一调整不要同时大幅调节两个参数否则参数空间会变得难以调试。参数与评估的关系参数推荐值作用错误配置的表现temperature分类评估 0生成评估按线上值控制采样随机性随机性过大指标无法复现top_p默认 1 或按模型文档控制候选 token 集合和 temperature 同时乱调结果难以解释max_tokens按任务长度设置限制输出长度输出被截断指标偏低seed部分服务支持设置为固定值帮助复现不支持 seed 时只能靠多次运行平均5.2 样本量与置信区间宽度怎么权衡样本量过小置信区间会很宽任何结论都站不住。样本量过大评估成本上升而且提升趋缓。对于分类准确率可以粗略估算n 个样本下 95% 置信区间宽度大约与1.96 * sqrt(p * (1 - p) / n)成正比。假设预期准确率 p0.9n100 时区间宽度约 ±6 个百分点n400 时约 ±3 个百分点。如果你的业务决策需要区分 3 个百分点的差异100 条样本显然不够。实际项目建议分两步先跑 100 条左右做快速探针确认没有接口错误、输出格式异常、类别映射错误再扩展到 300-500 条做正式评估。如果评估的是高风险场景例如医疗、金融风控样本量还要更大并且要补充人工抽检。5.3 随机种子与可复现性评估报告必须可复现。至少做三件事固定推理参数temperature、top_p、max_tokens 写入评估配置。固定评估脚本版本代码和 Prompt 的改动都要记录建议纳入版本管理。固定随机种子自助法置信区间要用固定 seed如果模型服务支持 seed 参数也一并固定。即使全部固定大模型服务端仍可能因为负载、量化、分布式推理产生微小差异。稳妥做法是把推理结果落盘指标报告基于落盘结果生成而不是每次现场重新调用模型。5.4 任务到指标的选型速查表不同任务适合不同指标快速选型时可以参考下表任务类型推荐指标需要注意文本分类 / 意图识别Accuracy、Precision、Recall、F1类别不均衡时看宏平均 F1短答案问答Exact Match对措辞敏感需配合归一化摘要 / 翻译ROUGE、BLEU无法完全反映语义质量需人工抽检开放生成LLM-as-a-Judge、人工评分裁判模型需要先做一致性验证代码生成单元测试通过率编译通过不等价于功能正确RAG 问答答案正确率、引用命中率还要评估检索召回和排序指标6. 运行验证把测量结果变成可信结论6.1 完整运行流程与预期输出运行流程分三步读取测试集、调用模型推理、计算指标。python run_evaluation.py python eval_metrics.py假设测试集有 100 条样本模型 A 的推理结果保存为results_a.jsonl预期输出大致如下accuracy: 86.00% 95% CI: [79.50, 92.00] per-class metrics: - 退货: precision0.88, recall0.82, f10.85 - 换货: precision0.90, recall0.84, f10.87 - 退款: precision0.84, recall0.91, f10.87 - 人工客服: precision0.78, recall0.86, f10.82再对模型 B 跑同一批测试集两个模型做 McNemar 检验McNemar p-value: 0.0137 A 错 B 对: 12 A 对 B 错: 3p0.0137 0.05说明模型 B 的 3.5% 优势不太可能是随机波动。但这不是上线决策的充分条件还要考虑成本、延迟和少数类别表现。6.2 结果如何解读解读指标时至少看三层。第一层总体指标。准确率和置信区间给出整体水平。区间过宽就说明样本量不够结论要谨慎。第二层分类别指标。看哪些类别精确率低、哪些类别召回率低。精确率低意味着模型容易误判成这个类别召回率低意味着真实属于这个类别的样本被漏掉很多。这两类问题的处理方向完全不同。第三层错误样本。把预测和期望不一致的样本单独导出逐条看是标注错误、任务歧义、Prompt 指令不清、还是模型能力不足。很多情况下指标“差”不是模型的问题而是测试集或评估口径的问题。6.3 学习环境与生产环境的验证差异学习环境跑通最小流水线验证目标是“链路通了、数字能算出来”。所以测试集可以只有几十条模型可以用本地小模型重试和并发都可以简化。生产环境的需求完全不同测试集必须来自真实业务采样并做敏感信息脱敏。推理要带完整日志、超时、重试、限流、成本统计。结果要落盘指标报告要带版本号、模型名、Prompt 版本、测试集版本。除了核心指标还要人工抽检至少 50 条确认自动化指标和人工判断一致。评估前要确认没有把线上用户真实数据直接用于打分后再回流到训练避免新一轮泄漏。注意生产环境的“验证通过”不是指指标达到某个阈值而是指评估过程可复现、误差可量化、失败原因可追溯。指标只是一个输出评估流程本身才是可信度的来源。7. 常见问题排查分数不稳定、基准泄漏、结论翻转7.1 同一批样本跑两遍分数对不上现象同一测试集、同一个模型上次准确率 86%这次变成 84%。可能原因有三个。第一推理参数不一致例如上次 temperature0这次改了配置。第二模型服务端存在随机性即使 temperature0某些推理引擎仍可能因为批处理、量化产生微小差异。第三评估代码和结果文件被覆盖上次结果没有落盘。检查方式先比对两次调用模型的配置文件和 Prompt 是否一致再查看推理结果文件是否还在最后重新运行并记录模型服务端版本。处理建议固定参数结果落盘指标基于落盘结果计算。如果服务端波动明显将测试集重复运行 3 次取指标均值和波动范围而不是跑一次就下结论。7.2 模型在测试集上表现好上线后明显变差现象离线准确率 90%线上监控准确率只有 75%。这通常是分布偏移而不是模型退化了。离线测试集来自标注好的历史数据线上输入是实时用户请求两者在表述方式、领域、长度、噪声程度上差异很大。处理建议上线前检查测试集是否覆盖边界样本和对抗样本上线后建立线上抽样回流机制每周抽取一部分线上输入按统一标准标注持续更新测试集。把测试集当成一个活资产而不是一次性产物。7.3 30 条样本换了一版 Prompt结论就翻盘现象样本量很小只改了几个字的 Prompt模型 A 和模型 B 的排名就反过来了。这不是模型性能不稳定而是测量噪声太大。30 条样本的准确率标准差非常高单点差异没有统计意义。处理建议扩大样本量至少 100 条起步比较两个模型时同时输出置信区间和 McNemar p 值如果确实只能小样本评估就明确写清结论置信度低不能用于上线决策。7.4 用 LLM 当裁判评自己结果虚高现象让一个模型给另一个模型的输出打分分数很高但人工抽检发现质量问题很多。原因通常是裁判 Prompt 定义不清晰、评分标准过于宽松或者裁判模型本身在偷懒倾向于给高分。LLM-as-a-Judge 不是不可用而是必须验证裁判的可靠性。检查方式抽取 50 条打分结果对比人工打分和 LLM 打分的一致性计算一致率或相关性同时查看高分样本里是否存在明显错漏。处理建议使用独立裁判模型不要用被测模型自己评分标准写具体给出正例和反例每个维度单独打分不要一个总分定期用人工标注集校准裁判模型。7.5 排查顺序与预防措施表遇到评估结果异常时按优先级排查问题现象常见原因检查方式处理建议分数跑两遍不一致参数或服务端随机性比对参数和结果文件固定参数、结果落盘、多次运行取均值离线和线上差异大分布偏移或数据泄漏对比测试集和线上样本分布持续更新线上采样测试集小样本结论翻转样本量不足计算置信区间扩大样本用显著性检验LLM 裁判虚高评分标准模糊或裁判偷懒人工抽检一致性独立裁判、具体标准、定期校准指标和人工感受不符指标口径错误导出错误样本逐条看修正指标定义增加人工抽检8. 最佳实践与扩展方向从一次测量走向持续评估体系8.1 可落地的五条最佳实践第一指标定义先于模型运行。在写评估代码之前先把任务类型、核心指标、参考答案格式写清楚并让业务方确认。指标定义不明确时后面所有步骤都会被推倒重来。第二测试集纳入版本管理。测试集和代码一样要有版本。Prompt 改了、模型换了、业务规则变了都要在评估报告里记录对应的版本号。否则三个月后回看一份 86% 的报告根本不知道测的是什么。第三评估结果必须带不确定性。任何指标报告都要给出样本量和置信区间。两个模型对比必须有显著性检验不能只看点估计。第四自动化指标和人工抽检结合。纯自动化指标容易被 Prompt 表达和参考答案质量带偏。每次发布前至少人工抽检 50 条确认自动化评分和人工判断一致。第五评估过程可重放。推理结果落盘、评估脚本固定、随机种子固定。任何人拿到同一份结果文件都能复现同一份报告。8.2 扩展方向Agent、RAG 与生产监控文本分类评估只是起点。当前更常见的评估场景是 RAG 问答和 AI Agent。RAG 评估比单轮问答复杂至少包含三部分检索质量召回率、命中率、排序指标、生成质量答案正确性、忠实度、引用命中率、端到端效果。检索错了但生成对了或者生成内容没有依据这两类错误需要用不同指标捕捉。AI Agent 评估更复杂因为 Agent 有多步动作、工具调用、状态变化。常见做法是任务级成功率定义一个目标状态判断 Agent 是否在限定步数和成本内达成目标。同时要记录中间动作序列失败后能回溯是哪一步选错了工具或参数。生产环境还可以把评估指标接入监控线上抽样请求进入评测任务队列定期计算偏移量当指标连续下降或超出阈值时触发告警。这时评估不再是一次性行为而是持续反馈回路。8.3 发布前的测量检查清单以下清单适合每次模型或 Prompt 发布前过一遍测试集是否从真实业务采样是否覆盖正常、边界、对抗三类样本。测试集发布时间和模型训练数据是否有重叠是否做了泄漏检查。评估参数是否固定并记录包括 temperature、top_p、max_tokens、seed。推理结果是否落盘指标报告是否包含模型版本、Prompt 版本、测试集版本。核心指标是否带置信区间模型对比是否做了显著性检验。是否有人工抽检记录抽检结果与自动化指标是否一致。失败样本是否单独导出一份是否明确了错误类型和后续改进项。AI 时代的测量革命并不是“有了大模型就能自动获得可信结论”。它真正改变的是测量成本和测量规模同时也把指标设计、数据隔离、统计推断这些基本功推到了每一位 AI 工程实践者面前。先跑通这条最小流水线再逐步补齐样本量、裁判校准和持续监控才能在模型能力快速迭代时仍然保持对每一次结论的信心。 大模型评估怎么做：构建可信测量流水线
在 AI 广泛应用之前测量一个系统的能力通常意味着人工打标、抽样统计和专家评审。到了大模型阶段这套做法突然变得不够用了模型可以在几小时内处理上万条文本、代码和对话但同一批样本跑两遍结果可能不同基准测试分数很高落地到业务场景却频繁出错。于是出现了“AI 时代的测量革命”The Measurement Revolution in the Age of AI这类讨论。核心问题不是模型能不能给出答案而是我们能不能对模型的输出做可信的测量并从中得到可信的推断。这篇文章从“测量革命”切入目标很具体带你把一条最小可复现的模型评估流水线跑通内容包括评估指标怎么选、测试集怎么设计、批量推理怎么写、置信区间和显著性检验怎么做以及分数不稳定、基准泄漏、结论翻转这些问题该按什么顺序排查。适用读者是正在做大模型应用的开发者、算法工程师以及需要根据指标做技术决策的产品和技术负责人。读完以后你可以把同一套方法用到文本分类、信息抽取、RAG 问答、Agent 任务评估等场景至少不会再拿 30 条样本的准确率去决定一个模型能不能上线。1. 先理解 AI 时代的“测量革命”到底在解决什么问题1.1 测量革命有两层含义用 AI 测量测量 AI“测量革命”这个词容易让人误解成“AI 来了测量问题自动解决了”。实际上它包含两个方向。第一个方向是“用 AI 做测量”。过去统计一篇客服工单属于哪个分类需要人工读文本、打标签、复核现在可以用模型批量判断。过去做用户反馈分析需要抽几百条样本人工编码现在可以用 Prompt 让模型输出结构化标签。测量成本降低了测量规模变大了这是革命性的一面。第二个方向是“测量 AI”。模型本身是一种新的测量对象。它不像普通软件那样有确定的输入输出映射同一个问题温度不为 0 时每次答案都不同同一个模型换一个 Prompt 表述能力表现可能差别很大。我们需要一套方法去回答“这个模型或这套 AI 系统到底行不行”。这两个方向叠加才是完整的测量革命我们既要用模型去替代部分人工测量又要对模型本身进行可信测量。如果只看到第一层很容易把评估简化为“跑几个 benchmark 得分”忽略了第二层里最麻烦的可信性问题。1.2 可信测量要回答的三个问题指标、样本、推断任何可信测量最终都要回答三个问题。第一指标是什么。也就是“好”怎么定义。文本分类可以用准确率、精确率、召回率问答可以用答案正确率生成任务可以用人工评分或 LLM-as-a-Judge。指标定义不清楚后面所有数字都没有意义。第二样本是什么。指标必须在一个具体的样本集合上计算。这个集合是否覆盖业务场景难度是否合理有没有和模型训练数据重叠样本集合决定了测量结果能推广到哪类场景。第三推断怎么做。我们永远无法在一个时刻测完所有可能的输入只能测一个有限样本。要从样本上的指标推断系统在总体上的表现必须引入置信区间、显著性检验这类统计工具。否则就会出现“A 模型比 B 模型高 2 个百分点到底是不是随机波动”这种无法回答的问题。实际项目里很多评估报告只写了第一个问题第二个问题靠“随便抽几百条”第三个问题直接忽略。这正是“可信测量”要补的部分。1.3 为什么基准分数高不等于业务可用假设你在公开榜单上看到一个模型某项任务分数比另一个模型高 5 分就把它选为线上模型。这样做的风险至少有三种。风险一是数据泄漏。公开基准的测试集可能出现在模型训练数据里模型相当于提前看过答案分数虚高。学术上叫 contamination业务上叫“模型背过题”。风险二是分布偏移。公开基准里的文本风格、领域、难度和你的真实业务数据往往不同。线上用户不会按测试集的套路说话评测分数自然无法代表线上效果。风险三是测量本身有噪声。大模型输出带随机性测试集只有几十条评估器本身也可能漏判最后得到的差异很可能是噪声而不是真实差异。所以可信测量的重点不是追求一个看起来很漂亮的分数而是让分数背后有一整套可辩护的过程指标是怎么定义的、样本是怎么来的、差异是否通过了统计检验。这就是本文要构建的最小可信测量流水线。2. 可信测量的地基把指标、校准和统计推断放在同一张图上2.1 指标选择准确率之外还有哪些常用口径不同任务适合不同指标。先看一个典型的分类任务。假设模型要把客服工单分成“退货”“换货”“退款”等类别评估时会产生四类结果真正例、假正例、真负例、假负例。基于这四类结果可以定义准确率Accuracy预测正确的样本数除以总样本数。类别均衡时直观类别不均衡时容易被多数类带偏。精确率Precision预测为某类的样本中确实属于该类的比例。衡量“判得准不准”。召回率Recall真实属于某类的样本中被正确预测出来的比例。衡量“找得全不全”。F1 分数精确率和召回率的调和平均。两者都重要时使用。对于文本生成或问答类任务还有另一套口径Exact Match模型输出和参考答案完全一致才算对适合短答案、代码生成等场景。ROUGE / BLEU基于 n-gram 重叠的文本相似度适合摘要、翻译但对语义改写不敏感。LLM-as-a-Judge用一个更强的模型按评分标准给输出打分适合开放性生成任务但需要先验证裁判模型的稳定性。人工评分成本最高、通常最可信适合小样本验收。指标不是越多越好。关键是一开始就明确任务目标再选定一两个核心指标和两三个辅助指标。核心指标用于决策辅助指标用于解释。2.2 基准测试与数据泄漏模型“背过答案”怎么办数据泄漏是评测中最隐蔽的问题。它不一定是故意作弊而是模型训练语料本身就包含了公开数据。你在某个公开评测集上测出一个高分可能只是因为这个测试集已经在预训练阶段被模型看到过。判断是否存在泄漏常用的检查方式有几种把测试集中若干条原文喂给模型观察它是否表现出明显记忆痕迹例如能续写出非常具体的人名、数字和来源。检查测试集发布时间和模型训练数据截止时间。如果测试集发布于模型训练截止之后泄漏风险较低否则需要警惕。在内部业务测试集上复跑同一条评测对比公开集和内部集的分数差异。差异过大时优先怀疑公开集存在泄漏。所以生产环境评估应该以自建业务测试集为主公开基准只作为参考。自建测试集的数据应该来自真实业务日志并且用一定的时间窗口隔离例如取 3 月之前的线上数据做测试集避免和近期模型蒸馏或微调数据混在一起。2.3 校准模型说 90% 可信真的可信吗很多模型接口会返回概率或置信度例如“这个工单有 92% 的概率属于退款”。这个数字是否可信取决于模型是否被校准过。校准的定义是在所有模型认为置信度为 p 的样本中真实正确的比例也应该接近 p。如果模型说 90% 可信的样本里实际正确率只有 60%说明模型过度自信反过来如果置信度很低但正确率很高说明模型过度保守。评估校准有一个常用做法把样本按置信度分桶例如 0-0.5、0.5-0.7、0.7-0.9、0.9-1.0分别计算每个桶的平均置信度和真实准确率然后画校准曲线或计算 ECEExpected Calibration Error。对大模型尤其要小心很多模型并不会给出真正经过校准的概率特别是使用了 temperature 采样之后概率分布会被拉平或压缩。需要把它当作“分数”而不是“概率”来解读。如果业务要基于置信度做阈值判断例如“低于 80% 转入人工”一定要先用自建测试集验证这个阈值的真实精确率和召回率。2.4 统计推断从 30 条样本到 95% 置信区间假设你在 30 条测试样本上得到准确率 90%也就是 27 条正确。能不能说系统真实准确率就是 90%不能。30 条样本的估计波动很大单点估计没有表达不确定性。正确的做法是计算置信区间。最常用的方法之一是自助法Bootstrap从已有结果中做有放回抽样重复成千上万次每次计算一个准确率再取这些准确率的 2.5% 和 97.5% 分位数得到 95% 置信区间。它的思想是模拟“如果我们换一批类似的样本结果可能落在哪里”。另一个常用工具是显著性检验。比较两个模型时不能只看点估计要判断差异是否可能是随机波动造成的。对于分类结果McNemar 检验是常见的配对检验方法因为它考虑的是两个模型在同一批样本上“一个对一个错”的不一致情况。这两类工具下文都会给出可以直接运行的代码。3. 搭建最小可信测量环境依赖、测试集和评估器3.1 Python 依赖与运行环境为了跑通下面的流水线需要一个能调用大模型的 Python 环境。推荐使用 Python 3.10 或更高版本并先创建一个虚拟环境。下面的示例使用 OpenAI 兼容接口可以替换成本地部署的 vLLM、Ollama 或其他兼容服务。python -m venv .venv source .venv/bin/activate # Windows 下使用 .venv\Scripts\activate pip install openai numpy scipy三个依赖的用途openai调用 OpenAI 兼容的模型接口。不同服务商的接口差异已经很小大部分兼容/v1/chat/completions。numpy用于计算指标和自助法置信区间。scipy用于 McNemar 检验计算二项分布概率。如果还需要统计精确率和召回率可以安装scikit-learn但为了展示内部原理本文会手写这些计算。注意安装依赖时不要固定猜测版本。落地前先执行pip list确认openai、numpy、scipy的实际版本并阅读对应版本的接口变更说明尤其是openai客户端从openai.ChatCompletion.create改为client.chat.completions.create之后旧代码需要相应调整。3.2 测试集设计覆盖正常、边界和对抗三种样本测试集是整个评估的地基。设计时至少覆盖三类样本。第一类正常样本。来自真实业务日志难度适中代表系统日常面对的大多数输入。数量要够这是指标的主干。第二类边界样本。输入格式不规范、缺少关键信息、意图模糊、长度极端。这类样本最容易暴露系统的稳定性问题。第三类对抗样本。指刻意构造的、容易让模型出错的输入例如相似但不同类别的文本、带误导信息的句子、混合多个意图的长文本。对抗样本不应该占到很大比例否则会过度拉低分数但至少要有一批来检验鲁棒性。测试集应该保存为带结构的数据文件。推荐 JSONL 格式每行一个样本。下面是一个客服工单分类任务的示例{id: case-001, input: 我昨天买的手机屏幕碎了想换一台新的, expected: 换货} {id: case-002, input: 订单还没发货能取消吗, expected: 退款} {id: case-003, input: 退换货地址在哪里运费谁出, expected: 退货} {id: case-004, input: 你们客服电话多少我要投诉, expected: 人工客服}每行包含四个字段唯一 ID、模型输入、期望结果、可选的难度标签。expected字段后续用于计算准确率、精确率、召回率等指标。3.3 选自己写评估器还是用评估框架现在有不少评估框架例如 DeepEval、RAGAS、promptfoo它们封装了测试集管理、指标计算和报告生成。是否值得引入取决于团队阶段。学习阶段建议自己写最小流水线。因为评估的难点不在框架 API而在“指标定义是否合理、样本是否可靠、差异是否显著”。自己写一遍能看清每个数字是怎么来的。生产阶段可以引入框架。这时候团队已经知道自己的评估口径框架可以帮我们自动化跑回归、生成报告、对接 CI/CD。但要注意框架自带的评分器不一定适合你的业务例如用通用 LLM 裁判给专业客服话术打分可能和人工判断偏离很大。框架只提供通道标准和验证责任仍然在团队自己。4. 实现一条可复现的“测量与推断”流水线4.1 项目结构与数据格式下面的最小项目只有四个文件llm-eval/ ├── requirements.txt ├── data/ │ └── test_cases.jsonl ├── eval_metrics.py └── run_evaluation.pytest_cases.jsonl上一节设计的测试集。eval_metrics.py指标计算、自助法置信区间、McNemar 检验。run_evaluation.py调用模型推理、保存结果、输出报告。先把测试集放到data/test_cases.jsonl然后定义一个读取函数。这里不直接依赖 pandas保持依赖最小。import json def load_cases(path: str) - list[dict]: cases [] with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if line: cases.append(json.loads(line)) return cases读取后不要立刻跑模型先打印样本数量、类别分布。类别极端不均衡时要调整指标或采样方式。4.2 定义任务、提示词和模型调用封装下面示例的任务是客服工单分类。模型的系统提示词要求只输出类别标签方便后续做 Exact Match 或归一化比较。from openai import OpenAI client OpenAI( api_keyYOUR_API_KEY, base_urlYOUR_COMPATIBLE_ENDPOINT, ) SYSTEM_PROMPT ( 你是一个客服工单分类器。 根据用户输入从以下类别中选择一个输出退货、换货、退款、人工客服。 只输出类别名不要输出其他内容。 ) def classify(text: str, temperature: float 0.0) - str: resp client.chat.completions.create( modelyour-model-name, temperaturetemperature, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: text}, ], ) return resp.choices[0].message.content.strip()这里的关键点是temperature0.0。分类任务希望输出稳定所以把采样温度降到最低。注意temperature0.0也不能保证绝对稳定因为部分推理后端仍可能引入并行采样或内核层面的随机性但通常已经能显著降低波动。如果模型可能输出空白、多余标点或不在类别内的值后处理要做归一化去空格、去标点、统一大小写。类别多了之后建议在代码里写一个合法类别集合如果输出不在集合内记录为UNKNOWN这些样本在分析时单独看。4.3 批量推理与结果采集批量推理时要考虑三个工程问题失败重试、并发控制、结果持久化。生产环境不能因为一次网络超时就让整个评估中断。import json import time def run_evaluation(cases_path: str, results_path: str, delay: float 0.2): cases load_cases(cases_path) results [] for case in cases: for attempt in range(3): try: pred classify(case[input]) break except Exception as exc: print(fcase {case[id]} attempt {attempt 1} failed: {exc}) if attempt 2: pred UNKNOWN else: time.sleep(1.5) results.append({ id: case[id], input: case[input], expected: case[expected], prediction: pred, }) print(f{case[id]}: expected{case[expected]}, prediction{pred}) with open(results_path, w, encodingutf-8) as f: for r in results: f.write(json.dumps(r, ensure_asciiFalse) \n) return results示例里故意没有做并发请求原因是并发会引入参数调整成本和限流风险。真实测试集可能很大生产评估建议自己维护一个可控的并发池并把每次请求的重试次数、超时时间、日志全部落到单独文件里。结果保存为 JSONL 以后指标计算和结果分析可以分开执行不必每次重跑模型。4.4 计算指标、置信区间和显著性检验先计算基础指标。下面用手写方式实现二元分类的精确率、召回率和 F1以“退货”类为例其他类别按同样逻辑扩展。import numpy as np def compute_binary_metrics(results: list[dict], target: str) - dict: tp sum(1 for r in results if r[prediction] target and r[expected] target) fp sum(1 for r in results if r[prediction] target and r[expected] ! target) fn sum(1 for r in results if r[prediction] ! target and r[expected] target) precision tp / (tp fp) if tp fp 0 else 0.0 recall tp / (tp fn) if tp fn 0 else 0.0 f1 2 * precision * recall / (precision recall) if precision recall 0 else 0.0 return { target: target, precision: precision, recall: recall, f1: f1, tp: tp, fp: fp, fn: fn, }总体准确率可以单独计算然后用自助法给出置信区间def compute_accuracy(results: list[dict]) - float: correct sum(1 for r in results if r[prediction] r[expected]) return correct / len(results) if results else 0.0 def bootstrap_ci(results: list[dict], n_bootstrap: int 2000, seed: int 42) - tuple: rng np.random.default_rng(seed) n len(results) accuracies [] binary_scores np.array([1.0 if r[prediction] r[expected] else 0.0 for r in results]) for _ in range(n_bootstrap): sample rng.choice(binary_scores, sizen, replaceTrue) accuracies.append(sample.mean()) lower np.percentile(accuracies, 2.5) upper np.percentile(accuracies, 97.5) return round(lower * 100, 2), round(upper * 100, 2)比较两个模型时用 McNemar 检验。它只需要两个统计量模型 A 错而模型 B 对的样本数以及模型 A 对而模型 B 错的样本数。from scipy.stats import binom def mcnemar_p_value(results_a: list[dict], results_b: list[dict]) - float: b 0 # A 错B 对 c 0 # A 对B 错 for ra, rb in zip(results_a, results_b): correct_a ra[prediction] ra[expected] correct_b rb[prediction] rb[expected] if not correct_a and correct_b: b 1 elif correct_a and not correct_b: c 1 if b c 0: return 1.0 # 双侧检验 p 2 * binom.cdf(min(b, c), b c, 0.5) return min(p, 1.0)McNemar 检验的直觉是两个模型有分歧的样本数固定为 bc如果两个模型能力相同分歧应该大致对半开。如果 b 远大于 c说明模型 B 在模型 A 出错的地方表现更好这种差异不太可能是偶然。p 0.05通常被认为是显著差异但这只是一个约定业务上还要结合差异大小和成本判断。5. 关键参数与配置采样、温度、样本量和随机种子5.1 temperature 和 top_p随机性从哪里来大模型推理时temperature和top_p控制输出的随机性。对评估尤其重要因为你不能在一个抖动很大的条件下做测量。temperature越低概率分布越尖锐模型越倾向于选最高概率的 token越高分布越平输出越多样。评估类型任务通常设 0生成类任务要按真实业务环境设置不能因为追求稳定就长期用 0因为线上用户可能见到完全不同的生成分布。top_p是核采样参数只从累计概率达到 p 的 token 集合中采样。实践中建议二选一调整不要同时大幅调节两个参数否则参数空间会变得难以调试。参数与评估的关系参数推荐值作用错误配置的表现temperature分类评估 0生成评估按线上值控制采样随机性随机性过大指标无法复现top_p默认 1 或按模型文档控制候选 token 集合和 temperature 同时乱调结果难以解释max_tokens按任务长度设置限制输出长度输出被截断指标偏低seed部分服务支持设置为固定值帮助复现不支持 seed 时只能靠多次运行平均5.2 样本量与置信区间宽度怎么权衡样本量过小置信区间会很宽任何结论都站不住。样本量过大评估成本上升而且提升趋缓。对于分类准确率可以粗略估算n 个样本下 95% 置信区间宽度大约与1.96 * sqrt(p * (1 - p) / n)成正比。假设预期准确率 p0.9n100 时区间宽度约 ±6 个百分点n400 时约 ±3 个百分点。如果你的业务决策需要区分 3 个百分点的差异100 条样本显然不够。实际项目建议分两步先跑 100 条左右做快速探针确认没有接口错误、输出格式异常、类别映射错误再扩展到 300-500 条做正式评估。如果评估的是高风险场景例如医疗、金融风控样本量还要更大并且要补充人工抽检。5.3 随机种子与可复现性评估报告必须可复现。至少做三件事固定推理参数temperature、top_p、max_tokens 写入评估配置。固定评估脚本版本代码和 Prompt 的改动都要记录建议纳入版本管理。固定随机种子自助法置信区间要用固定 seed如果模型服务支持 seed 参数也一并固定。即使全部固定大模型服务端仍可能因为负载、量化、分布式推理产生微小差异。稳妥做法是把推理结果落盘指标报告基于落盘结果生成而不是每次现场重新调用模型。5.4 任务到指标的选型速查表不同任务适合不同指标快速选型时可以参考下表任务类型推荐指标需要注意文本分类 / 意图识别Accuracy、Precision、Recall、F1类别不均衡时看宏平均 F1短答案问答Exact Match对措辞敏感需配合归一化摘要 / 翻译ROUGE、BLEU无法完全反映语义质量需人工抽检开放生成LLM-as-a-Judge、人工评分裁判模型需要先做一致性验证代码生成单元测试通过率编译通过不等价于功能正确RAG 问答答案正确率、引用命中率还要评估检索召回和排序指标6. 运行验证把测量结果变成可信结论6.1 完整运行流程与预期输出运行流程分三步读取测试集、调用模型推理、计算指标。python run_evaluation.py python eval_metrics.py假设测试集有 100 条样本模型 A 的推理结果保存为results_a.jsonl预期输出大致如下accuracy: 86.00% 95% CI: [79.50, 92.00] per-class metrics: - 退货: precision0.88, recall0.82, f10.85 - 换货: precision0.90, recall0.84, f10.87 - 退款: precision0.84, recall0.91, f10.87 - 人工客服: precision0.78, recall0.86, f10.82再对模型 B 跑同一批测试集两个模型做 McNemar 检验McNemar p-value: 0.0137 A 错 B 对: 12 A 对 B 错: 3p0.0137 0.05说明模型 B 的 3.5% 优势不太可能是随机波动。但这不是上线决策的充分条件还要考虑成本、延迟和少数类别表现。6.2 结果如何解读解读指标时至少看三层。第一层总体指标。准确率和置信区间给出整体水平。区间过宽就说明样本量不够结论要谨慎。第二层分类别指标。看哪些类别精确率低、哪些类别召回率低。精确率低意味着模型容易误判成这个类别召回率低意味着真实属于这个类别的样本被漏掉很多。这两类问题的处理方向完全不同。第三层错误样本。把预测和期望不一致的样本单独导出逐条看是标注错误、任务歧义、Prompt 指令不清、还是模型能力不足。很多情况下指标“差”不是模型的问题而是测试集或评估口径的问题。6.3 学习环境与生产环境的验证差异学习环境跑通最小流水线验证目标是“链路通了、数字能算出来”。所以测试集可以只有几十条模型可以用本地小模型重试和并发都可以简化。生产环境的需求完全不同测试集必须来自真实业务采样并做敏感信息脱敏。推理要带完整日志、超时、重试、限流、成本统计。结果要落盘指标报告要带版本号、模型名、Prompt 版本、测试集版本。除了核心指标还要人工抽检至少 50 条确认自动化指标和人工判断一致。评估前要确认没有把线上用户真实数据直接用于打分后再回流到训练避免新一轮泄漏。注意生产环境的“验证通过”不是指指标达到某个阈值而是指评估过程可复现、误差可量化、失败原因可追溯。指标只是一个输出评估流程本身才是可信度的来源。7. 常见问题排查分数不稳定、基准泄漏、结论翻转7.1 同一批样本跑两遍分数对不上现象同一测试集、同一个模型上次准确率 86%这次变成 84%。可能原因有三个。第一推理参数不一致例如上次 temperature0这次改了配置。第二模型服务端存在随机性即使 temperature0某些推理引擎仍可能因为批处理、量化产生微小差异。第三评估代码和结果文件被覆盖上次结果没有落盘。检查方式先比对两次调用模型的配置文件和 Prompt 是否一致再查看推理结果文件是否还在最后重新运行并记录模型服务端版本。处理建议固定参数结果落盘指标基于落盘结果计算。如果服务端波动明显将测试集重复运行 3 次取指标均值和波动范围而不是跑一次就下结论。7.2 模型在测试集上表现好上线后明显变差现象离线准确率 90%线上监控准确率只有 75%。这通常是分布偏移而不是模型退化了。离线测试集来自标注好的历史数据线上输入是实时用户请求两者在表述方式、领域、长度、噪声程度上差异很大。处理建议上线前检查测试集是否覆盖边界样本和对抗样本上线后建立线上抽样回流机制每周抽取一部分线上输入按统一标准标注持续更新测试集。把测试集当成一个活资产而不是一次性产物。7.3 30 条样本换了一版 Prompt结论就翻盘现象样本量很小只改了几个字的 Prompt模型 A 和模型 B 的排名就反过来了。这不是模型性能不稳定而是测量噪声太大。30 条样本的准确率标准差非常高单点差异没有统计意义。处理建议扩大样本量至少 100 条起步比较两个模型时同时输出置信区间和 McNemar p 值如果确实只能小样本评估就明确写清结论置信度低不能用于上线决策。7.4 用 LLM 当裁判评自己结果虚高现象让一个模型给另一个模型的输出打分分数很高但人工抽检发现质量问题很多。原因通常是裁判 Prompt 定义不清晰、评分标准过于宽松或者裁判模型本身在偷懒倾向于给高分。LLM-as-a-Judge 不是不可用而是必须验证裁判的可靠性。检查方式抽取 50 条打分结果对比人工打分和 LLM 打分的一致性计算一致率或相关性同时查看高分样本里是否存在明显错漏。处理建议使用独立裁判模型不要用被测模型自己评分标准写具体给出正例和反例每个维度单独打分不要一个总分定期用人工标注集校准裁判模型。7.5 排查顺序与预防措施表遇到评估结果异常时按优先级排查问题现象常见原因检查方式处理建议分数跑两遍不一致参数或服务端随机性比对参数和结果文件固定参数、结果落盘、多次运行取均值离线和线上差异大分布偏移或数据泄漏对比测试集和线上样本分布持续更新线上采样测试集小样本结论翻转样本量不足计算置信区间扩大样本用显著性检验LLM 裁判虚高评分标准模糊或裁判偷懒人工抽检一致性独立裁判、具体标准、定期校准指标和人工感受不符指标口径错误导出错误样本逐条看修正指标定义增加人工抽检8. 最佳实践与扩展方向从一次测量走向持续评估体系8.1 可落地的五条最佳实践第一指标定义先于模型运行。在写评估代码之前先把任务类型、核心指标、参考答案格式写清楚并让业务方确认。指标定义不明确时后面所有步骤都会被推倒重来。第二测试集纳入版本管理。测试集和代码一样要有版本。Prompt 改了、模型换了、业务规则变了都要在评估报告里记录对应的版本号。否则三个月后回看一份 86% 的报告根本不知道测的是什么。第三评估结果必须带不确定性。任何指标报告都要给出样本量和置信区间。两个模型对比必须有显著性检验不能只看点估计。第四自动化指标和人工抽检结合。纯自动化指标容易被 Prompt 表达和参考答案质量带偏。每次发布前至少人工抽检 50 条确认自动化评分和人工判断一致。第五评估过程可重放。推理结果落盘、评估脚本固定、随机种子固定。任何人拿到同一份结果文件都能复现同一份报告。8.2 扩展方向Agent、RAG 与生产监控文本分类评估只是起点。当前更常见的评估场景是 RAG 问答和 AI Agent。RAG 评估比单轮问答复杂至少包含三部分检索质量召回率、命中率、排序指标、生成质量答案正确性、忠实度、引用命中率、端到端效果。检索错了但生成对了或者生成内容没有依据这两类错误需要用不同指标捕捉。AI Agent 评估更复杂因为 Agent 有多步动作、工具调用、状态变化。常见做法是任务级成功率定义一个目标状态判断 Agent 是否在限定步数和成本内达成目标。同时要记录中间动作序列失败后能回溯是哪一步选错了工具或参数。生产环境还可以把评估指标接入监控线上抽样请求进入评测任务队列定期计算偏移量当指标连续下降或超出阈值时触发告警。这时评估不再是一次性行为而是持续反馈回路。8.3 发布前的测量检查清单以下清单适合每次模型或 Prompt 发布前过一遍测试集是否从真实业务采样是否覆盖正常、边界、对抗三类样本。测试集发布时间和模型训练数据是否有重叠是否做了泄漏检查。评估参数是否固定并记录包括 temperature、top_p、max_tokens、seed。推理结果是否落盘指标报告是否包含模型版本、Prompt 版本、测试集版本。核心指标是否带置信区间模型对比是否做了显著性检验。是否有人工抽检记录抽检结果与自动化指标是否一致。失败样本是否单独导出一份是否明确了错误类型和后续改进项。AI 时代的测量革命并不是“有了大模型就能自动获得可信结论”。它真正改变的是测量成本和测量规模同时也把指标设计、数据隔离、统计推断这些基本功推到了每一位 AI 工程实践者面前。先跑通这条最小流水线再逐步补齐样本量、裁判校准和持续监控才能在模型能力快速迭代时仍然保持对每一次结论的信心。