AI推理优化新方向：PersonTTS让模型按用户偏好找方案

你有没有碰到过这种场景：打开打车软件，页面上摆着"经济型"和"舒适型"两个选项，可你心里想的其实是"半小时内到、花费不超过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）是什么？

论文给出的新问题设定是：用户会同时提出准确率、延迟、成本三项要求，系统要找出一种AI推理执行策略，让这三项要求同时得到满足；以往的做法只盯着准确率与单一资源维度之间的权衡。

Q2：PersonTTS相比传统方法优势有多大？

A：在AIME未见题目上，PersonTTS的联合满足率达到83.85%，而对比的最强传统基线只有35.58%，差距超过48个百分点，在HMMT未见题目上同样有明显优势。

Q3：PersonTTS的经验复用机制是怎么工作的？

这套做法分两块。一块按用户需求的相似度去检索历史策略，拿它当搜索起点；另一块用一份固定指南（Guide）来指导后续修改，这份指南是从历史搜索案例里提炼出来的。所有候选策略最后都得在目标用户的真实需求下重新评估，通过了才会被采用。