❝
前段时间李飞飞团队的一篇文章受到业内广泛关注，宣传说是仅仅通过50美元的成本就炼了一个性能远超o1-preview，这也引起了我的兴趣，于是找这篇文章来读一下。
1. 简介
============
如题所示，这篇文章核心就是在验证"test-time scaling"这条定理，即在推理时增加推理时间，可以让模型的性能得到提升。
为验证此定理，本文构建了一个高质量的1K条数据集s1K，在Qwen2.5-32B-Instruct的基础上，对该数据集进行监督微调，微调在16张NVIDIA H100 GPU进行，共花费26分钟，按照H100的租赁成本，总成本约在50美元左右。
文章名称：s1: Simple test-time scaling
2. 数据集s1K构建
====================
本文首先讲了如何构建1000条数据组成的精华数据集s1K。
2. 1 收集原始数据
首先从16 个不同的来源收集初始的 59029 个问题，其中主要包括：
NuminaMATH(在线网站的30660个数学问题)
AIME(历史问题)
OmniMath(4238个竞赛级数学问题)
OlympicArena(各种奥林匹克竞赛的 4250 个问题，涵盖天文学、生物学、化学、计算机科学、地理、数学和物理学)
AGIEval(2385个标准化测试的问题，涵盖英语、法律和逻辑)
s1-prob(182个来自斯坦福大学统计系博士资格考试问题)
s1-teasers(23个具有挑战性的脑筋急转弯，常用于量化交易职位的面试)
2. 2 初步处理
对于每个问题，用Google Gemini Flash Thinking API生成推理过程和解决方案，得到问题-推理过程-解决方案的三元组。同时用8-gram对样本进行净化，并剔除重复数据。
2. 3 进一步筛选
主要从质量、难度、多样性三个角度进行进一步筛选。
质量角度：过滤生成三元组时出现API 错误的问题，并过滤问题中包含格式问题的字符串(不存在的图像引用、链接等低质信息)，从中挑选出384个样本。
难度角度：从两个指标进行评估：模型性能和推理长度。
模型性能方面，用Qwen2.5-7B-Instruct和Qwen2.5-32B-Instruct两个模型对问题进行推理，用Claude 3.5 Sonnet作为裁判，和正确答案进行对比，评估其正确性。如果回答正确，则说明是简单的问题，予以剔除。
推理长度方面，基于一个基本假设越困难的问题推理长度往往越长，通过评估两个推理模型产生的推理长度，来对问题难度进行评估，剔除推理长度短的问题。
经过一步的操作，样本总数剩下24496个。
多样性角度：先通过Claude 3.5 Sonnet对每个问题进行分类，从不同的分类领域中均匀挑选问题，其中再重复难度角度的筛选方式，在每个领域保留推理长度尽可能长的困难问题。
最终通过这三个角度的筛选，得到1000个样本。
3. Test-time scaling方法
=============================
这一节主要是讲如何通过强制干预(Budget forcing)，去调整模型输出的长度。
方法很简单，只是在模型输出内容时，通过对原本要输出中止符号时，强行添加Wait来鼓励它思考更多；强行添加Final Answer来直接截断输出，直接输出最终答案。
下图展示了一个干预的例子。
4. 实验结果
==============
本文用构建的s1K数据集在Qwen2.532B进行监督训练微调，得到s1-32B。
具体训练细节如下：
❝
使用 Qwen2.5-32B-Instruct作为基础模型，使用标记分隔符将思考阶段与回答阶段分开，具体用
<|im_start|>think 和 <|im_start|>answer;括起来，前后都有一个换行符。超参数设定：训练 5 个 epoch，批次大小为 16，以 bfloat16 精度进行训练，学习率为 1e − 5，线性预热 5%（16 步），在其余训练（299 步）中按照余弦时间表衰减到 0。使用 AdamW 优化器，β1 = 0.9，β2 = 0.95，权重衰减为 1e − 4。 16 个 NVIDIA H100 GPU 上，训练只需 26 分钟。
首先，本文验证了一下test-time scaling，即更长的思考时间，是否能输出准确率更高的结果。其结果如下图所示。可以看到，随着平均思考时间越长(思考输出的token越多)，模型准确率是有明显提升的。这里的2048/4096表示限制模型最大的思考token为2048/4096。这里的2x/4x/6x表示输出2/4/6个“wait”。
其次可以看出，test-time scaling也是存在边际效应的，即'4x‘和'6x'的效果差距并不明显，文章也提到，如果强行让模型不断思考，会让他输出重复的思考内容。
本文又验证了一下串行拓展(Sequential scaling)和并行拓展(Parallel scaling)哪个更好。所谓串行拓展，就是前文所描述的，在思考过程中加入wait，使其单次思考时间更长，并行拓展则是让它重新进行思考，最终结果通过类似投票的方式选择。对比结果如下图所示，可以看到串行是明显优于并行的，这比较符合直觉，因为串行拓展是有连续性的，思考就是由浅入深的过程。
s1-32B和其它模型在三个基础数据集上的性能评估对比如下表所示，可以看到，s1-32B的综合表现是高于o1-preview的，但和o1和Deepseek-r1等模型仍有一定差距。这也比较正常，毕竟参数量本身不是一个量级。
5. 消融实验
==============
本文列举了很多消融实验，这里我只挑两个看上去有意思的。
- 对数据集的消融
文章拿s1K和其它样本数据集1K-random(随机挑选的1K数据)、1K-diverse(只考虑领域多样性的1K数据)、1K-longest(让模型思考时间最长的1K数据)、59K-full(不经挑选的全部数据)进行对比，可以看到s1K的效果是逼近全部数据的，甚至在MATH500上还比全部数据性能高，说明通过这种方式构建数据集的方式是合理且有效的。
- 对延长提示词的消融
本文中，通过wait来延长模型的思考时间，这里又比较了其它的延长提示词，比如Alternatively、Hmm。结果发现wait还是略有优势，说明语言的艺术还是起到了略微效果。
总结
========
这篇文章除了数据集外，最主要的价值是提出了一种test-time scaling的策略，它并不是在模型推理是调整prompt，而是在模型训练微调时，强行改变模型的思考链，逼迫模型进行更长思考，这在一定程度上是有效的。
不过，回到最初的问题，很多宣传稿说它仅用“50美元”，就让大模型超o1-preview的性能，这种说法有一定误导性。这里的“50美元”涉及的成本，仅仅包括微调Qwen2.5-32B-Instruct的训练成本，而不包含在构建数据集上的大量API成本和做模型对比消融的成本。实际要做这种类似的工作，还是需要很高昂的财力投入。
此外，它仅在三个数据集上进行比较，在s1K中，存在偏向这三个领域的数据，因此这种对比方式可能存在不严谨之处，只是在特定领域超越o1。
现如今，无论是Deepseek R1还是这篇文章提到的策略，都是有意让模型输出速度变慢，以给时间做更深入的思考，从而提升准确率。在很多现实场景中，用户只需要一个大致的答案，而无需模型回答的足够精准，因此这种思考反而成了响应速度的负担，这可能是未来大模型在刷榜时需要考虑的一个问题。
本文使用 文章同步助手 同步
