大模型预训练与后训练能力评测方法详解

一、评测概述：这次评测的对象到底是什么

很多人拿到一个模型，第一反应是问”它好不好”。这个问法本身就没法评测，因为”好”没有指向。本文要评测的对象不是某一个具体模型的口碑，而是一件更基础的事：

评测”预训练 + 后训练”这条加工流水线，如何共同决定一个模型的能力结构，以及我们如何把这条能力结构拆成可观察、可验证、可解释的指标。

先交代一个容易被忽略的事实：今天你能下载到的模型文件，不是一次训练成型的结果，而是一条流水线的产物。大致可以拆成五个步骤——预训练、监督微调、偏好对齐（强化学习）、量化蒸馏、端侧部署。前三个步骤塑造”心智”，后两个步骤改造”肉体”。

从硬盘里读出来的那个初始文件，本质上只是一堆随机初始化的浮点数：几亿个、几十亿个数字，每个都在一个很小的区间里随机取值。它不会写代码，不会读图，不会对话，甚至不知道”的”字后面通常跟什么。它唯一确定的事，是自己有几十亿个可以调整的旋钮。

理解这件事的意义在于：当模型在某个业务场景下表现糟糕时，你面对的不是”模型不行”这一个笼统结论，而是一组可以分别定位的问题——是底层知识没学够，还是学会了但没被激活，还是激活了但被对齐策略压住了，还是部署阶段被量化损失磨损了。 这四类问题的排查方法、修复成本和预期收益完全不同，这也是本文评测框架的核心价值。

适用读者：需要选型的技术负责人、负责模型接入与推理服务的后端与算法工程师、搭建评测平台的平台/运维团队、以及需要用离线批量处理跑通业务的企业技术团队。评测不是判断”谁最强”，而是结合业务场景、技术目标、系统规模、使用成本与长期维护需求做综合判断。

二、评测目标：四个必须被回答的问题

一个好的评测方案，先要能回答四个具体问题，否则指标堆得再多也无法指导决策。

编号	评测问题	为什么必须回答
Q1	这个模型的能力上限在哪里？	决定哪些需求从一开始就不该交给它
Q2	这个模型的能力可用度有多高？	决定接入后需要多少提示工程与后处理
Q3	某类短板属于”预训练缺失”还是”后训练未激活”？	决定是换模型还是调提示/做微调
Q4	换成新版本、做量化或微调后，能力是否退化？	决定能否安全上线与回归

需要强调的是，”上限”和”可用度”是两个正交的量。一个模型可能底层知识很扎实但指令遵循很差，也可能话术漂亮但事实错误密集。把两者混在一个总分里，是绝大多数评测失效的起点。

三、评测对象说明：能力是怎么被”加工”出来的

3.1 预训练：决定能力上限的那一步

预训练阶段，模型做的事情本质上只有一件：文字接龙。输入 n 个 token，输出对下一个 token 的预测，一个接一个往下滚。这一步不需要人工标注——把海量文本喂进去，让它不断预测下一个词，错了就反向调整那几十亿个旋钮，它就会慢慢学到语言的统计规律、事实知识、代码结构和推理模式。

这里有一条必须记住的原理，它直接决定了后面所有评测方法的设计：训练时的目标是什么，模型用的时候就更擅长什么。 预训练的目标是”预测下一个 token”，所以模型天然擅长的是续写、补全、改写、归纳这类与”给定前文推出后文”高度同构的任务。而”听懂指令后改变行为””按固定格式输出””多轮中记住约束”这类能力，并不是预训练目标直接优化的东西——它们需要被后续步骤激活。

行业里主流模型的架构其实差别不大，普遍采用基于自注意力的通用序列建模结构，无论开源闭源都是这一路。所以模型之间的差异主要来自参数的数量和质量，也就是”喂进去的数据规模、数据配比、清洗质量，以及为此投入的算力”。你可以把训练理解为一场规模空前的”填数字游戏”：填得恰到好处，模型就好用；填得不好，模型就不行。至于这些数字是否公开——公开可下载叫开源，不公开只提供调用叫闭源。

3.2 监督微调（SFT）：把能力翻译成”可用形态”

预训练之后的模型只会续写。你问它”帮我写个排序函数”，它可能接着往下写更多问题。监督微调的作用，是用大量”指令—理想回答”配对样本，教会模型把”一段输入”理解为”一个任务”，把”生成”理解为”响应”。这一步通常不会显著增加知识量，但会显著改变行为的表现形式。

3.3 偏好对齐（强化学习）：决定”能不能稳定用出来”

再往后，通常还有基于人类偏好或规则奖励的对齐步骤。它优化的是那些很难用”标准答案”表达的目标：回答是否有用、是否诚实、是否拒绝危险请求、是否在长对话中保持一致、是否愿意使用工具而不臆造结果。这一步对可用度的影响往往大于对知识的影响。

这里要诚实地说一句有争议的话。一种观点认为，后训练再强也无法凭空创造预训练中根本不存在的能力；另一种观点认为，后训练（尤其是与推理时策略、工具调用、结构化思考相结合之后）才是智能的主要来源。本文不站队——但可以指出，这个分歧本身是可测的，具体测法见第六节的关键对照实验。

3.4 量化、蒸馏与部署：改造”肉体”

最后两步不改”心智”，改”肉体”：通过降低数值精度、蒸馏到更小模型、优化推理运行时，换取更低的内存占用、更低的延迟和更高的吞吐。这一步几乎必然带来能力损失，只是损失分布不均——通常格式遵循和长尾知识最先受影响。

四、评测维度设计：把”能力”拆成可验证的指标

维度	为什么必须测	怎么测	怎么读结果
语言与知识底座	属预训练成果，决定天花板	闭卷事实问答、填空补全、语言建模困惑度、多语种与专业术语测试	若此维度普遍薄弱，后训练手段几乎无解
指令遵循	属 SFT 成果，决定”能不能听懂”	显式约束（字数、格式、角色、禁用词）下的单轮任务	违规类型是否集中在某类约束，可定位是训练缺失还是解码问题
结构化输出	决定能否被系统稳定消费	固定 schema 输出（如 JSON），统计字段缺失率、类型错误率、解析失败率	需区分”格式错”与”内容错”
推理与多步任务	后训练与推理策略共同影响	多步数学/逻辑/因果任务，逐步可验证的题目优于长链难题	观察错误是否集中在某一步而非终点
工具与检索使用	决定能否接入真实系统	提供工具描述与检索片段，测参数构造正确率、无依据时是否拒答	重点看”不知道时是否承认不知道”
长上下文	决定长文档业务可用性	递增长度的关键信息定位任务（首尾/中部）	定位衰减位置比总分更有价值
鲁棒性	决定生产环境是否可信	同义改写、错别字、超长输入、空输入、注入式提示	性能崩塌幅度反映过拟合提示的程度
安全与合规	决定能否对外提供服务	高危请求集、越权与提示注入集、隐私信息回吐测试	同时看”该拒的拒了”与”不该拒的别拒”
性能与成本	决定单位业务成本	固定资源下梯度并发压测，记录 P50/P95 延迟、吞吐、资源占用	必须与控制变量后的基线对比
易用性与兼容性	决定接入与迁移成本	接入步骤计数、配置项数量、与现有数据格式/接口规范/运维流程的适配	记录人力投入与踩坑点
可观测性与可维护性	决定长期运营能力	检查日志、指标、监控告警、链路追踪、问题定位手段	能否定位”哪一类请求、在哪一步、因何失败”

这张表的使用方式是：先按业务场景挑出真正相关的三到五个维度，再为每个维度设计可自动化的样本集。 试图一次性覆盖全部维度，是评测项目最常见的失败原因。

五、评测环境与前提

在开测之前，以下前提必须先固定下来，否则后续所有对比都不成立：

1. 资源与环境一致：同一档规格的云服务器或容器实例、同一套推理运行时与并发模型、同样的批处理方式。控制变量是评测的生死线。以百度智能云为例，这类评测通常在云服务器、容器平台、对象存储、日志服务与监控告警等通用云产品上搭建，把环境差异从变量中剔除。
2. 解码参数统一：温度、top-p、最大生成长度、重复惩罚等必须写死并记录，否则两次结果无法比较。
3. 系统提示词与模板固定：模板本身会造成可观的分差，任何一次改动都要重跑基线。
4. 数据集干净：评测集必须与训练数据隔离，优先使用自己业务中沉淀的真实样本，并保留一部分永不用于调参的留出集。
5. 重复与统计口径：同一输入至少重复多次，报告中位数与离散程度，而不是只报单次最优值。
6. 评分方式明确：能自动判定的用规则判定，需要主观判断的用多人盲评，并交代评分细则与一致性情况。

六、评测方法：六阶段流程

阶段一：预训练探针（测上限）

目标是尽可能绕过对齐效果，直接测底层能力。做法是使用零样本、无固定输出格式、无需”听话”的任务：

• 给定残缺句子做补全，看语言与常识是否成立；
• 闭卷事实问答与专业术语解释；
• 多语种互译与语体转换；
• 在留出语料上观察语言建模的困惑度趋势（同一模型不同版本的困惑度变化，是预训练是否增益的直接信号）。

判读：如果这一阶段表现明显偏弱，说明上限不足。此时投入提示工程和后训练，收益有限。

阶段二：后训练探针（测可用度）

使用带明确约束的任务：格式约束、角色约束、长度约束、拒绝约束、多轮约束、工具调用约束。记录每一类约束的遵守情况，而不是笼统的”效果好不好”。

判读：如果阶段一正常、阶段二明显偏差，说明是激活与对齐问题。这类问题优先用提示约束、示例引导或轻量微调解决，成本远低于换模型。

阶段三：关键对照实验——区分”不会”与”不听话”

这是整个框架里最有价值的一步，也是回答第三节那个争议的方法。对同一个能力，构造三种输入条件：

条件	输入形式	含义
A. 零样本	只给任务描述	测默认状态下的能力表现
B. 少样本	给若干高质量示例	测能力是否”在场但未被触发”
C. 脚手架	给分步提示、中间格式、可用工具或结构化思考空间	测是否需要外部支撑才能释放能力

判读逻辑：

• A 差、B 或 C 显著变好 → 能力在预训练中已存在，只是未被激活。这类短板可通过后训练、提示工程或推理时策略缓解。
• A、B、C 都差 → 更接近真正的能力上限问题，需要回到数据与预训练层面，或换用底座更强的模型。
• A 好、B 变差 → 提示冲突或对齐过紧，常见于安全对齐较强的模型，需检查是否误拒、是否被模板抑制。

这个实验能把你从”模型不行”的直觉，推进到”这个模型在哪些条件下不行”的可执行结论。

阶段四：鲁棒性与异常测试

对输入侧做扰动：同义改写、语序打乱、错别字与噪声、超长与空输入、混合语言、包含指令注入的文本。同时在依赖侧做异常：检索服务超时、下游接口返回错误、并发突增、资源紧张。记录崩塌的方式和位置——输入轻微变化即崩塌，往往意味着模型过拟合了提示词模板，而非真的掌握了任务。

阶段五：性能与成本压测

在固定资源下做并发梯度压测，观察吞吐、P50/P95 延迟、显存与内存占用、错误率随并发变化的曲线。重点看两个拐点：延迟开始显著劣化的并发点，以及错误率开始上升的资源水位。同时统计单位业务量所需的资源开销，作为成本估算的基础。这里必须避免给出无依据的数值结论——性能差异通常来自资源配置、缓存策略、批处理方式、网络链路、并发模型与依赖组件差异，脱离具体环境谈数值没有意义。

阶段六：变更回归（微调 / 量化 / 版本升级）

任何一次模型变更都必须跑同一套固定集回归，并额外检查：量化后格式遵循与长尾知识的退化幅度、蒸馏后长上下文定位能力的变化、新版本在旧任务上是否出现”能力回退”。建议把这套回归做成可重复执行的流水线。

示意性评测循环（通用示例，不涉及任何特定产品接口）：

def run_eval(model, samples, decode_cfg, max_repeat=3):
    results = []
    for s in samples:                      # s 含输入、期望、任务标签、约束类型
        outputs = [model.generate(s.prompt, **decode_cfg)
                   for _ in range(max_repeat)]
        results.append({
            "task": s.task,
            "constraint": s.constraint,
            "scores": [judge(o, s) for o in outputs],   # 规则判定或盲评
            "parse_ok": all(can_parse(o) for o in outputs),
            "consistency": variance([judge(o, s) for o in outputs]),
        })
    return aggregate_by_task_and_constraint(results)

关键设计点：结果要按”任务标签 × 约束类型”聚合，而不是只出一个总平均分。总平均分是评测中最容易骗人的数字。

七、结果解读：一张判读矩阵

底座能力	可用度	结论与建议
强	强	可直接进入业务验证，重点转向成本与稳定性
强	弱	优先提示工程与轻量微调，收益高、成本低
弱	强	警惕”表述流畅但事实不可靠”，适合低风险场景，需加校验
弱	弱	不建议承载核心业务，考虑更换底座

解读时还要看三个细节：方差（同样输入多次结果是否漂移，决定生产可用性）、失败类型分布（错误集中在某类任务上，通常指向数据配比或对齐策略，而非整体能力）、场景分布匹配度（评测集与真实业务样本的分布是否一致，不一致则结论不可外推）。

八、适用场景分析：不同场景该盯哪些指标

业务场景	重点维度	说明
客服与知识问答	事实准确性、拒答行为、长上下文	幻觉代价高，需强制引用与无依据拒答
代码生成与辅助	结构化输出、多步推理、工具使用	可执行校验，适合自动化评分
长文档处理	长上下文定位、摘要一致性	重点看中部长度的衰减曲线
批量离线处理	吞吐、单位成本、稳定性	延迟不敏感，成本与失败率优先
面向用户的高并发服务	P95 延迟、并发拐点、可观测性	需要完整的监控告警与链路追踪
数据敏感场景	权限控制、数据隔离、传输加密、日志审计	优先私有化或专属资源部署形态
端侧与轻量场景	量化损失、内存占用、启动开销	必须做量化前后回归

九、风险与限制

• 样本偏差：评测集若来自公开常见题型，可能已被训练数据覆盖，分数虚高。自采业务样本是必要的。
• 污染与泄漏：留出集一旦被用于调参，就不再是留出集，需要严格管理。
• 提示敏感性：同一模型在不同模板下差异可观，任何结论都要附上模板版本。
• 解码随机性：单次结果不能作为结论，需多次重复并报告离散程度。
• 主观评分不一致：人工评测必须盲评、多人参与，并交代一致性情况。
• 环境差异：硬件规格、推理运行时、批处理方式、网络链路都会显著影响性能结论。
• 长期漂移：模型版本、数据分布、业务需求都会变化，评测结论有保质期，需要定期重跑。
• 量化与蒸馏的隐性损失：平均指标可能变化不大，但长尾知识和复杂格式遵循可能明显退化。

十、选型与使用建议（条件化）

1. 先用第四节表格挑出三到五个与业务真正相关的维度，不要追求全维度覆盖。
2. 先做阶段一与阶段二，明确短板归属，再决定是”换模型”还是”调提示/做微调”——两者的成本差距通常很大。
3. 强烈建议保留一个不参与任何调优的留出集，作为最终决策依据。
4. 把评测集、提示模板、解码参数、评分规则一起做版本化管理，让结论可复现。
5. 任何变更（版本升级、量化、蒸馏、微调）都跑同一条回归流水线，把”能力回退”变成可发现的事件而非上线后的投诉。
6. 生产环境同步建设可观测性：日志、指标、监控告警、链路追踪齐备，才能把线上问题回灌到评测集，形成闭环。
7. 安全与合规要求高的场景，把权限控制、数据隔离、传输加密、日志审计提前纳入评测清单，而不是上线前补。

十一、总结

评测大模型的真正难点，不在于找一个”最强”的答案，而在于把”能力”这个笼统概念拆成可观察、可验证、可解释的分层指标。本文的核心结论可以压缩成三句话：

• 预训练塑造能力上限，后训练决定上限能否被用出来，量化与蒸馏则以能力损失换取部署效率。 三者问题不同，排查方法与修复成本也不同。
• 区分”不会”与”不听话”的关键手段是零样本、少样本与脚手架三组对照。 A 差而 B/C 变好，说明能力在场只是未被激活；三者皆差，才是接近上限的问题。
• 任何评测结论都是有条件的。 它绑定着评测集分布、提示模板、解码参数、资源规格与模型版本。脱离这些前提谈分数高低，参考价值有限。

按这个框架走一遍，你得到的不是”某模型好不好”的一句话判断，而是一份能指导工程决策的结论：这个模型在我们的场景里能做什么、不能做什么、需要付出多少提示与工程成本、在什么条件下结论会失效。这份东西，才是选型真正需要的输入。