[从零训练一个500B大语言模型] 23/25：怎样知道这个模型真的练好了？

训练目录里留下了三个版本。A是监督微调以后保存的基线，B和C又经过了上一轮奖励训练。打开聊天窗口，三个都能回答问题。B做数学题时更利落，C的解释更完整，A则是一直留着作对照的老版本。

到了要交付的时候，问题反而变难了。几次顺眼的回答不足以让我决定把哪一个交给用户。我需要知道，新版本究竟多做对了什么，又把哪些原来会的事情做坏了。

于是，三个模型先留在原地。我打开一张空白表格，把第一批用户会问的问题写在最左边。

先把用户的问题写到试卷上

这个500B模型先作为通用文本助手提供服务。用户会贴一份说明书，让它找出操作步骤；会交来一段生硬的文字，请它改写；也会问数学、代码，或者在几轮对话里慢慢补齐需求。

这些事情给试卷划出了五块：阅读材料后回答、写作与改写、数学和代码辅助、多轮澄清，以及信息不足与边界处理。每一块都要有中英文、长短材料和不同难度。尤其是最后一块，材料里没有答案时，模型应该把缺失说清楚。

第一批只做200题，每类40题，先让评分流程跑起来。其中一道阅读题给出一份设备维护说明，问：“出现这种故障，先检查哪一项？”模型写了一段很流畅的回答，却把第二步放在了第一步前面。

“回答流畅”显然不够。我把这道题拆成四个检查点：引用的信息是否正确，是否回答了问题，步骤顺序是否正确，有没有添进说明书没有要求的操作。审核者按这四项重新看答案，分歧就容易定位了。

数学题可以核对答案，代码题可以运行测试。运行代码的环境与评分程序分开，时间和资源受到限制，模型也不能修改测试。开放回答先由模型评审筛选，再由人工复核困难样本。展示答案时隐藏版本名字、随机交换顺序，看看评分是否会被篇幅和语气带走。

这200题帮助我们把尺子做出来。题目和评分规则都被团队反复看过，因此它们进入开发材料。接下来挑模型，要换一套独立的验证题。

盲评：评审不知道答案来自哪个模型，减少版本名字等身份信息对判断的影响。

封起来的那一套，最后才打开

验证题按五类各准备1,000道，用来比较A、B、C。评估负责人另外保管一套封存的验收题，等候选冻结后才运行。

这三个用途要一直分清。开发题允许反复查看，帮助修模型和评分器；验证题用于挑版本；最终验收题检查被选中的版本能否通过交付门槛。任何题一旦拿给训练团队分析并用于改进，就记入开发材料，下一次封存验收补入新题。

题目的来源也跟着分开。代码按项目或题目家族划分，长文按文档来源划分。训练材料里用过一份说明书，换个问法仍然可能考的是同一段内容。第八篇的数据去重记录在这里又用上了：我们沿着来源核查，而不只比较句子像不像。

图中的前三份材料分别负责改进、选择和最终验收。沿下面的箭头往前走，先冻结候选，再打开封存试卷，评审通过以后才进入小流量试运行。

公开基准也保留在报告里，方便与其他模型比较。我固定EleutherAI评估框架的版本，连同数据版本、提示模板、采样设置和评分程序一起存下来。自己的新题与公开成绩并排放，后面每次改模型，都能沿着相同记录复查。

验收集：在版本交付前，按固定规则检查模型是否达到目标的任务集合。

评估污染：测试材料或高度相似内容进入训练过程，使测试成绩高估模型处理新任务的能力。

B多答对了二十题，却先被留下来

结果出来后，我先把数学和中文长文两列放到一起。A的数学正确率是70%，B是72%，C是75%；长文那一列，A是80%，B掉到75%，C升到81%。

B提高的两分值得往下看。我打开逐题记录：它把A答错的80道改对了，同时把A答对的60道做错。700道加80，再减60，最后是720道。

新增的80道和丢掉的60道，各自指向不同的能力变化。只看72%这个总数，它们会被挤成一个“净增20题”。而另一份长文试卷更直接：B少做对了50道。第一批用户恰好要靠模型读说明书、找条件，这五个百分点会落在他们每天的问题上。

在看成绩以前，我给这次交付定过规则：主攻能力要有明确的提高证据，其他关键类别的退步风险控制在2个百分点以内。B的长文成绩已经越过了这条线，于是留回训练侧修正。A继续保留，C进入下一步检查。

C看起来更好，但换一批新题，分数可能上下波动。我让评估记录把这种不确定性也算出来：比较同一道题的新旧结果，估计改善幅度可能落在哪个范围。范围全在零以上，才有更充分的依据说主攻能力提高了。

数学这组题，C把100道错题改对，又丢掉50道原来的对题，净增50道。配对近似给出的改善范围约为2.6至7.4个百分点。长文净增10道，范围约为−0.6至2.6个百分点。数学的提高有了支持，长文的退步风险也在事先规定的容差内。剩下三类任务还要逐一检查，任何一列都不能被这两列替代。

配对比较：把两个模型在同一道题上的结果放在一起分析，减少题目难度差异带来的干扰。

置信区间：依据样本和统计方法，为指标变化估计的不确定性范围。

怎样把逐题变化换成统计范围？

对于1,000道独立题，记改对的数量为a、改错的数量为b。差值为d = (a − b) ÷ 1,000。配对正态近似的标准误差可写为√[((a + b) ÷ 1,000 − d²) ÷ 1,000]，再用d ± 1.96 × 标准误差计算95%近似区间。

B的80道改对与60道改错，差值是2个百分点，区间约为−0.3至4.3个百分点，跨过了零。C的数学题是100道改对、50道改错，区间约为2.6至7.4个百分点；长文是40道改对、30道改错，区间约为−0.6至2.6个百分点。

正式报告可以按题目或任务家族重采样，估计差值区间。一组题只是同一模板换数字时，就以模板家族为单位，保留题目之间的相关性。补题前先固定下一批规模与分析节点，避免每添几题就反复尝试放行。

本次具体门槛是：每个关键类别的新旧差值，配对95%区间下界高于−2个百分点；主攻能力的差值区间下界高于零。严重安全问题另外逐项解决。

一份漂亮回答，可能把任务带到别处

能力表筛到了C，评估还没有结束。阅读任务里，外部材料可能夹着一句指令，要求模型忽略用户的问题、改做别的事情。如果它跟着走，前面那道维护说明答得再好，也解决不了这个问题。

安全题因此按真实入口来准备：给材料插入干扰指令，检查任务是否被带偏；在输入中放入权限不同的字段，检查哪些内容会被输出；让工具调用遇到目标不清或执行失败，检查它是否越过权限、是否能够停下来说明问题。

2026年Anthropic公开的非预期模型行为调查帮助我补充了这类检查方向。落到自己的模型上，每个场景仍要有明确的允许行为、完整输入输出和工具记录。发现严重问题，就修模型、提示或系统边界，再把相关场景加入以后每版都要跑的回归集。

初次开放的范围也跟着收紧：先提供文本回答。外部写入与执行能力留在受控环境里，逐项通过验收再开放。这样，最后那张安全记录上的“0项未解决”，有一组明确的测试范围与产品权限对应。

回归集：每次改模型或系统后重新运行的固定任务，用来发现已经解决的问题是否再次出现。

成绩过关以后，用户还要等多久

C留在候选名单上，我把它接到试运行环境，继续贴进那份说明书。回答正确，但用户还会在意另外两件事：屏幕多久开始出现文字，中间会不会一直卡着。

服务目标提前写好了。普通短问答中，95%的请求在2秒内开始输出，生成阶段每token的典型间隔控制在50毫秒附近；长文单独记录输入长度和等待时间。这里的95%可以直观地理解为，一百个请求中大约九十五个已经等到了第一个输出。

压测从低负载开始，逐步增加请求。每次使用相同的输入与输出长度分布，记录延迟、错误和GPU成本。一次只发一个问题时的速度，也许很好看，但真正决定需要多少机器的，是持续有人提问时还能不能守住等待时间。

同一题尝试几次，也会改变这笔账。用户只得到一次回答，就报告一次生成的成功率。需要验证器重试的功能，则把重试次数、总等待和费用一起测。我把这条规则写进记录，避免“生成八次终于答对”被混进一次回答的成绩。

三份版本的记录逐渐汇到同一张表里。下面摘出其中几行，完整报告仍保留五类任务及每项安全检查：

C的1.8秒没有超过2秒目标，生成间隔、其他任务和错误率继续放在报告中核对。表里少了哪一项，就补完那一项。全部条件满足后，才把它冻结为最终验收候选。

尾部延迟：一批请求中较慢那部分的等待时间，例如第95百分位。

把候选变成一份能交付的版本

我把C的权重、分词器、聊天模板和服务配置固定下来，交给评估负责人运行封存的验收题。这里检查的是这一份完整交付物：换了模板或服务配置，用户实际拿到的行为也可能变化，版本记录就要跟着更新。

封存结果按同样的门槛评审，通过以后，先让少量用户使用。A和回滚配置继续保留；新出现的问题经过隐私处理与审核，进入后续开发和回归记录。一次验收给了我们开放当前范围的依据，后面的真实使用继续告诉我们该改哪里。

回头看训练目录，三个文件仍然都在，但它们的去向已经清楚了。A负责兜底，B回去修长文，C沿着完整检查进入试运行。我终于能回答最初那个问题：选择它，是因为哪些能力提高、哪些能力守住了，以及它能在怎样的等待时间内提供服务。

接下来，我要把刚才那个试运行窗口背后的机器摆清楚。一次提问怎样从浏览器走到GPU，又怎样一段一段回到用户面前，这会决定服务能接住多少人。