
你有没有遇到过这种情况:打车软件让你选"经济型"还是"舒适型",但你真正想要的其实是"半小时内到,花费不超过30块,而且车况别太差",三个条件同时满足。单选某一个维度,总觉得差点意思。
大语言模型做数学题的时候,也面临一模一样的烦恼。
**测试时扩展**
测试时扩展(Test-Time Scaling,简称TTS):指的是让AI模型在回答问题时多花点"脑力",比如多生成几条思路、互相比对、反复修改,以此换取更高的准确率,而不是靠训练阶段的参数升级。
这几年AI圈子里很火的一个做法,就是让大模型做数学竞赛题(比如AIME、HMMT这类赛事题)的时候,别只生成一次答案就交卷,而是多跑几条思路,互相验证,挑出最靠谱的那个。这样做准确率确实能往上蹿,但代价也明显:算力消耗蹭蹭涨,等待时间变长,花的钱也多了。
于是研究者们开始琢磨怎么把这笔"智力投资"花得更聪明。但问题是,几乎所有现有的优化方案,都只盯着一个维度使劲。
当优化只盯着一条线,会漏掉什么
想象你在健身房请了个私教,私教只会问你一个问题:"你想要更瘦还是更快?"
但你真正的目标可能是:体脂率降到18%以下,同时跑步配速提升到每公里5分钟以内,并且每周训练时间不超过5小时。这是三个条件一起满足,不是二选一。
现有的TTS优化方法,基本都在做"瘦"和"快"之间的权衡,业内管这个叫**帕累托前沿**(Pareto Frontier)。
**帕累托前沿**:在两个相互制约的目标(比如准确率和成本)之间,找到一系列"没有更优选择"的平衡点,想要某个指标更好,就必须牺牲另一个指标,这条边界线就是帕累托前沿。
比如有的方法专门优化"准确率-成本"这条线(花多少钱换多少准确率),有的方法专门优化"准确率-延迟"这条线(等多久换多少准确率)。但如果用户同时要求"准确率不低于90%,延迟不超过10秒,成本不超过5毛钱",这三个条件凑在一起,单独优化任何一条帕累托线,都可能找不到真正满足全部要求的方案。
论文里画了一张特别直观的图:三维空间里,有一个"用户需求区域"(像个立方体),也有一个"系统能做到的区域"(像个不规则的云团),两者的交集才是真正能让用户满意的地方。如果你只在"准确率-延迟"这个平面上找最优解,或者只在"准确率-成本"这个平面上找最优解,你找到的点很可能根本不在那个交集里。
这就是这篇论文想要解决的核心矛盾:**用户的需求从来都是多维度同时成立的,但现有方法习惯一次只优化一个维度**。
研究者们把这个新问题起了个名字,叫**个性化测试时扩展**(Personalized Test-Time Scaling)。目标很直白:不是找一条最优曲线,而是针对每个用户的具体要求,找到一个能同时满足准确率、延迟、成本三项要求的"执行方案"。
论文标题里那句"从Pareto到Preference"(从帕累托到偏好),说的就是这个转向:以前是找一条客观最优的曲线,现在是要满足每个人的主观偏好组合。
每个用户都单独搜一遍?那也太贵了
听起来思路挺合理,但马上冒出一个现实问题:如果每来一个新用户,都要重新跑一遍策略搜索,这个成本能接受吗?
论文里给了个数字,参照此前的AutoTTS系统,完整跑一轮策略发现需要**39.9美元和160分钟**。
这意味着什么?意味着如果你的产品有1000个不同需求画像的用户,光是搜索阶段就要烧掉近4万美元,等上超过100天(假设串行执行)。这显然不现实。
这就好比你开了家裁缝店,每个顾客来了都要从零开始量体裁衣、设计版型、打样、试穿,哪怕上一个顾客的身材和这一个几乎一样,你也完全不借鉴上一次的经验。效率低到离谱。
研究者们提出的解决方案叫**PersonTTS**,一个"摊销式"的智能体策略发现框架。
**摊销**(Amortized):把一次性的高昂成本,分摊到多次使用中去,让单次的边际成本大幅降低,这里具体指把策略搜索的经验,在不同用户之间复用,而不是每次从零开始。
PersonTTS的核心思路,说白了就是建一个"策略经验库"。当新用户来了,先从经验库里找一个需求最接近的"老顾客",把他当时用的策略拿来当初始版本,然后再根据新用户的具体情况做针对性调整。这就不是从零量体裁衣了,而是"找一个身材相近的人的版型,改一改就能用"。
控制器:AI推理背后那只看不见的手
要理解PersonTTS怎么工作,得先搞懂它要优化的东西到底是什么。
论文把AI做推理任务时的决策逻辑,抽象成一个叫**控制器**(Controller)的东西。
**控制器**:一段可执行的代码,负责决定在推理过程中要不要多开几条思路、用哪个模型、要不要让AI自我修正答案、什么时候该喊停收工,相当于整个推理过程的调度员。
控制器能做的事情包括五类动作:生成新的思路分支(Spawn)、继续推进某条分支(Continue)、让某条分支自我修正(Refine)、砍掉没希望的分支(Prune)、以及给出最终答案收工(Finish)。
这个设定其实挺像一个乐队指挥。
指挥不自己演奏乐器,但他决定什么时候加入哪件乐器、哪个声部该强一点、哪里该戛然而止。如果没有指挥(也就是没有控制器这层调度逻辑),乐手们(也就是AI的各条推理分支)就会各吹各的调,有的可能已经把答案算对了却还在傻乎乎地继续算,白白浪费资源;有的可能走错了方向却没人叫停,继续浪费算力生成一堆错误推理。控制器的存在,就是让整个过程有章法、不浪费。
论文里特别强调一点:控制器只能看到"公开观测信息",比如各条分支进行到第几步了、目前中间答案是什么、已经花了多少时间和钱,但是看不到标准答案,也拿不到"这道题答没答对"的反馈。这个设定模拟的是真实部署场景,AI在回答用户问题的时候,确实不知道正确答案是什么。
JSR:把三个目标拧成一股绳的评分标准
既然要同时满足三个条件,总得有个数字能告诉你这个策略到底合不合格。
论文定义了一个叫**JSR**的指标。
**联合满足率**(Joint Satisfaction Rate,简称JSR):在多次重复测试中,同时满足准确率下限、延迟上限、成本上限这三项要求的测试批次所占的比例,这是衡量一个策略是否"靠谱"的核心打分方式。
这里有个细节特别值得琢磨:JSR要求的是"同时满足",不是"平均表现好"。
举个例子,假设某个策略在100次测试里,有95次准确率达标,95次延迟达标,95次成本达标,听起来各项指标都挺不错对吧?但如果这三个"95次达标"彼此不重叠,极端情况下真正三项同时满足的批次可能只有85次甚至更低。JSR只认"三个条件在同一批测试里一起成立",这才是真实用户会感受到的体验。
这就像你点外卖的时候要求"30分钟送到、不洒汤、分量够",如果某个骑手平均来说30分钟送到的概率是95%,不洒汤的概率是95%,分量够的概率也是95%,但你真正在意的是这一单外卖是不是同时做到这三点,而不是看三个独立的平均分。
论文里还有一组数学证明,专门论证了一件事:**光看准确率、延迟、成本这三个指标各自的单独达标率,没办法反推出JSR**。换句话说,哪怕你知道一个策略在准确率上表现如何、在延迟上表现如何,你依然没法确定它的联合满足率,因为失败的情况可能分散在不同的测试批次里。这也是为什么PersonTTS坚持要在目标用户的具体需求下重新评估每一个候选策略,而不是直接套用别处的分数。
两条腿走路:经验复用和目标验证
PersonTTS的设计里藏着一个很微妙的平衡,就是怎么既利用过去的经验,又不盲目迷信过去的经验。
论文专门用了一节的篇幅去证明一件事:**一个策略在"老用户"那里表现好,不代表它在"新用户"那里也会表现好**,哪怕两个用户的需求看起来很接近。
原因在于,策略的代码逻辑本身是会读取用户需求参数的,换一个需求,策略的实际执行路径可能完全不同,不仅仅是打分标准变了。论文把这个现象拆解成两部分:一部分是"用同样的执行记录,换一套新的及格线去重新打分",这部分是可以精确计算的;另一部分是"策略在新需求下实际执行方式发生了变化",这部分是没法事先预测的,只能跑一遍真实测试才知道。
这就好比你有个朋友特别会做菜,你问他"清淡一点的菜你推荐什么",他说红烧肉少放点糖。但另一个朋友对"清淡"的理解是完全不放糖不放油,同样一句"少放点糖"的建议,落到两个人嘴里做出来的菜味道可能天差地别。食谱(策略代码)是一样的,但执行的人(面对的具体需求)不一样,结果就会跑偏。如果你光凭"这道菜在上一个朋友那里获得好评"就直接端给第二个朋友吃,大概率要翻车。
正因为这个原因,PersonTTS坚持一个设计原则:**检索来的策略只能当初始起点,最终是否采纳,必须在目标用户的真实需求下重新跑一遍评估**。
这个设计里具体包含两种复用机制,一种叫"初始化复用",一种叫"指导经验复用"。
**初始化复用**,做法是把用户的需求(准确率、延迟、成本三个数字)转换成标准化的坐标,然后在经验库里找坐标距离最近的历史用户,把那个用户当时用的策略代码拿来当作新一轮搜索的起点,而不是从一张白纸开始写。
**指导经验复用**,则是把过去所有策略搜索过程中积累的"什么情况该怎么改"的经验,提炼成一份固定不变的操作指南,论文里管这个叫**Guide**。
**Guide**:由一个独立的AI智能体,从历史上大量的策略修改案例中总结出来的一套"条件触发式"修改规则,比如"当延迟超标但还有算力余量时,应该优先减少推理深度而不是减少分支数量",这份指南在后续的新用户搜索中保持固定不变,但会持续指导新策略的生成。
这份Guide有点像一本老医生写的诊断手册。新来的实习医生(负责生成策略的AI智能体)拿到病人(新用户需求)的各项指标后,手册里会告诉他"遇到这种症状组合,通常该往这个方向排查",但最终开什么药方,还是要结合眼前这个病人的具体情况来定,不能照搬手册里某个历史病例的药方直接用在新病人身上。如果没有这本手册,每个实习医生都得自己从零摸索诊断思路,重复犯前人已经犯过的错误。
真刀真枪的测试:PersonTTS到底强在哪
光说理论没用,得看实际效果。研究团队在AIME和HMMT这两个数学竞赛题库上做了测试,用了六种不同规模的Qwen3模型(从0.6B到32B参数不等)。
测试设计得很严谨:训练用的"源用户画像"和测试用的"目标用户画像"是分开独立采样的,题目也分成了"训练阶段见过的题"和"完全没见过的题"两组,用来检验方法是不是真的学到了可泛化的策略,而不是单纯记住了答案。
结果相当惊人。
**在AIME的未见题目集上,PersonTTS的联合满足率达到83.85%,而对比的强基线方法中表现最好的也只有35.58%,差距超过48个百分点。**
这是什么概念?意味着同样面对100个不同的用户需求组合,传统方法里大约只有36个能被真正满足,PersonTTS能满足将近84个。换算成日常场景,这相当于一家外卖平台,过去每100单里有64单做不到"又快又好又便宜",换了新调度系统之后,只有16单做不到,配送体验提升了接近两倍。
更关键的是,这个优势在题目完全没见过的情况下依然成立,说明学到的不是某几道题的"小聪明",而是真正通用的策略设计逻辑。
| 方法 | AIME未见题(目标画像) | HMMT未见题(目标画像) |
|---|---|---|
| ASC(自洽性方法) | 0.00% | 4.98% |
| ESC(早停自洽性) | 0.00% | 4.98% |
| ParallelProbeSR | 9.35% | 11.51% |
| AutoTTS (β=0.5) | 16.03% | 3.23% |
| AutoTTS (β=1.0) | 35.47% | 0.15% |
| PersonTTS(无经验复用版) | 79.22% | 69.16% |
| **PersonTTS(完整版)** | **83.85%** | 77.28% |
有意思的是,哪怕去掉经验复用机制,只保留"直接针对联合需求做策略搜索"这一点,效果已经远超所有外部基线方法。这说明最大的那部分提升,其实来自于"把三个目标真正当成联合目标去优化"这个思路本身,而不是经验复用这个锦上添花的部分。
两种复用机制,谁更值钱
既然PersonTTS有两种经验复用方式(初始化复用和Guide指导),研究者们很自然地想知道:这两种机制各自贡献了多少,又是不是可以互相替代。
消融实验给出的答案挺有层次感。
**初始化复用主要起到的作用是"给搜索一个好的起跑点"**,相当于让策略搜索少走弯路,一上来就站在一个相对靠谱的位置,但对后续几轮的持续改进帮助有限。
**Guide则更多体现在"持续指导每一轮的修改方向"上**,而且它带来的提升在没见过的题目上表现得更稳定。
两者的效果并不是简单叠加的关系。论文的解释是,检索来的初始策略更像是"针对这个具体目标用户的先验起点",换一个用户可能就不适用了;而Guide提炼的是更通用的修改逻辑,不依赖某个具体的源策略,所以泛化能力更强。
这个发现让我想起学骑自行车的过程。
有人扶着你的车(相当于初始化复用)能让你一开始不至于摔倒,但那个人松手之后,你还是得靠自己掌握平衡的诀窍(相当于Guide提炼的通用规则)才能真正学会骑车。如果只有人扶你却没有掌握平衡的诀窍,车一撒手你照样摔;如果你懂平衡诀窍但一开始没人扶,你可能在最初几秒就摔倒了根本来不及运用诀窍。两者解决的是不同阶段的不同问题,所以效果不能简单相加。
更让人意外的是效率数据。在同样五轮策略搜索的预算下,**单独使用Guide机制,能让智能体调用的耗时降低约46%,花费降低约36%**。相比之下,单独使用初始化复用,主要是缩短了搜索耗时,花费却可能略微上升。这说明Guide提炼出来的经验确实减少了智能体反复试错和诊断问题所花的功夫,而初始化复用更多是给了一个省事的起点,但起点好不好高度依赖目标用户的具体情况。
经验库越大越好吗?答案没那么简单
既然经验复用这么有效,那是不是经验库里存的历史案例越多越好?研究者专门做了个实验来验证这件事。
他们把源用户经验库的规模分别设置成20个、60个、100个,在保持Guide和搜索预算不变的情况下,分别跑了对比实验。
结果显示,**在训练阶段见过的题目上,经验库越大,策略质量确实越好,100个样本的经验库比20个样本的表现要高出4到5个百分点**。这符合直觉:经验库里涵盖的用户需求类型越丰富,新用户越容易找到一个合适的参照对象。
但转到完全没见过的新题目上,这个规律就不那么稳了。**在AIME的未见题目上,经验库越大确实还是越好;但在HMMT的未见题目上,经验库从60个样本扩大到100个样本,表现反而从85.91%下降到了77.28%。**
这个结果挺值得玩味的。它说明单纯堆经验库的规模,并不能保证新用户在陌生题目上的表现也跟着线性提升。更大的经验库能提高在"熟悉场景"下找到合适起点的概率,但不一定能提高策略应对"全新场景"的能力。
这就好比一家连锁餐厅收集了1000份不同顾客的点餐偏好档案,理论上顾客越多,越容易找到跟你口味相近的参照对象。但如果有一天餐厅突然换了全新的菜单(相当于全新的题目分布),那些基于老菜单积累的偏好档案,参考价值就会打折扣,甚至可能因为参照了一个"看似相似但实际不适用"的档案,反而误导了新菜品的搭配推荐。研究者的结论是,光靠扩大经验库规模并不是万能解法,未来可能需要配合"检索可信度评估"之类的机制,判断一个检索结果到底值不值得信赖。
写在后面
读完这篇论文,最触动我的其实不是PersonTTS本身的技术设计,而是它提出问题的方式。
很多AI优化研究习惯用一条漂亮的帕累托曲线来展示成果,这条曲线确实很有说服力,图表往右上角或者左下角延伸,一看就是"进步"。但这篇论文提醒我们,真实世界里的用户从来不是活在某一条曲线上的,他们同时有好几个硬性要求,而且这些要求彼此之间经常是冲突的。只优化一条曲线,哪怕优化得再漂亮,都可能完全没解决用户真正的问题。
论文里那个关于"策略在不同用户之间不能直接迁移"的数学证明部分,我觉得是容易被忽略但其实挺重要的一块内容。它用公式严格说明了为什么"参考经验"和"直接套用经验"是两回事,这个区分看似学术,但对任何做推荐系统、做个性化服务的人来说,都是一个值得警惕的陷阱:别人身上验证过有效的方案,换到另一个人身上,必须重新验证,不能想当然地认为"这个人和那个人很像所以应该也有效"。
还有一个细节我觉得挺有意思,就是论文承认经验库规模扩大之后在陌生题目上反而出现了效果下降的情况,没有回避这个不完美的结果,而是把它当作一个值得追问的问题留在了文章里。这种对自己方法局限性的坦诚,某种程度上比那些"效果全面提升"的论文更可信。
下一次你打开某个AI产品,设置"准确率高一点、速度快一点、别太贵"这些滑块的时候,或许可以想一想,背后那个系统到底是在真正理解你这三个要求的组合,还是只是在某一条曲线上帮你挑了个折中点。
Q&A
Q1:个性化测试时扩展(Personalized Test-Time Scaling)是什么?
A:这是论文提出的新问题设定,指根据用户同时给出的准确率、延迟、成本三项要求,寻找能让三者同时满足的AI推理执行策略,而不是像以往方法那样只优化准确率和单一资源维度的权衡。
Q2:PersonTTS相比传统方法优势有多大?
A:在AIME未见题目上,PersonTTS的联合满足率达到83.85%,而对比的最强传统基线只有35.58%,差距超过48个百分点,在HMMT未见题目上同样有明显优势。
Q3:PersonTTS的经验复用机制是怎么工作的?
A:包含两部分,一是根据用户需求相似度检索历史策略当作搜索起点,二是用一份从历史搜索案例中提炼出的固定指南(Guide)指导后续修改,最终所有候选策略都要在目标用户的真实需求下重新评估才能被采纳。
好文章,需要你的鼓励
RGPO用"临时脚手架"破解大模型强化学习的奖励稀疏难题:先让模型独立解题,失败则分段放出标准解法引导重写,仅采纳经验证更优的答案。难题测试准确率从0跃至99.5%,语言模型平均分高出最强基线5.0分。
论文提出用MoE模型的路由器输出作为跨语言对齐目标,通过持续预训练对翻译句对施加路由KL散度损失,在不改变分词和架构的前提下让隐藏表示更接近,并在四个开源MoE模型、七种语言上验证了下游任务性能的一致提升。
DiffGate提出难度门控的教师指导机制,让验证器决定何时需要教师介入,仅对失败且困难的轨迹提供有界教师指导,结合GRPO强化学习,在数学与代码任务上显著提升解题覆盖率与跨领域迁移能力。
研究者用固定不变的16位二进制编码替代传统可训练词嵌入表,在17亿参数规模模型上训练1000亿token,证明模型仍可获得实质语言能力,揭示输入表并非必需,但性能略逊于可学习方案。