微信扫一扫,关注公众号

  • 科技行者

  • 算力行者

见证连接与计算的「力量」

首页 花一块钱美元,让AI在圆形装箱问题上刷新世界纪录

花一块钱美元,让AI在圆形装箱问题上刷新世界纪录

2026-10-30 11:39
分享至:
----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.-
2026-10-30 11:39 • 科技行者

2026年某天,几个研究者盯着一张账单发愁。

他们想用AI自动优化一个几何学难题,叫圆形装箱问题(把26个大小可变的圆塞进一个正方形,让所有圆的半径加起来最大)。思路不新鲜,Google DeepMind的AlphaEvolve已经证明这条路能走通。但当他们真正跑起来才发现,一次完整的优化实验要烧掉几十美元,有的多智能体方案甚至要花掉50美元才能跑出一个像样的结果。

**这就像雇了一个非常聪明的顾问,但他按小时收费,而且思考越深入收费越贵。**

你当然希望他想得越深越好,但预算是有限的。如果你的目标只是"让他在固定时间内想得尽量多",那很可能最后账单爆炸,效果却没提升多少。这篇来自新加坡国立大学、华盛顿大学、普林斯顿大学和斯坦福大学团队的论文,核心就是在问一个被所有人忽略的问题:我们到底该用什么标准去衡量这些AI优化系统的好坏?

被忽略的那个维度:钱

先说清楚这件事到底难在哪。

LLM引导的进化算法

LLM-guided evolutionary methods:让大语言模型充当"变异器",不断对一段代码或一个解法提出修改建议,再用评估器打分,保留表现好的版本,像自然选择一样一代代迭代出更优解。

这类方法最近火起来,是因为AlphaEvolve在2025年证明了它能真正解决有实用价值的数学和工程问题,而不只是刷榜。但几乎所有后续工作,包括开源的OpenEvolve、ShinkaEvolve,衡量方式都是同一个套路:固定迭代次数,看谁分数更高。

问题来了。如果你允许模型多想几步、多生成几个候选方案,分数自然会涨。这在机器学习里有个专门的名字。

测试时扩展

test-time scaling:AI系统在推理(而非训练)阶段投入更多计算资源,往往能获得更好的结果,这个现象在近两年的大模型研究中反复被验证。

那么一个方法"分数更高",到底是因为它真的更聪明,还是因为它偷偷多花了钱、多算了几遍?论文作者的判断是,如果不把成本钉死,几乎没法分辨这两件事。**这不是吹毛求疵,而是整个评测体系的一个漏洞。**

一个方法如果平均每次迭代要花4.35美分(论文里提到的AdaEvolve的数字),而另一个方法每次只花0.97美分,直接比较它们跑100轮之后谁分数高,其实毫无意义,因为前者可能已经花了后者4倍以上的钱。这就好比两个人比谁更会理财,一个每月花10万,一个每月花2万,最后看谁账户余额多——这根本不是在比理财能力,是在比谁本金多。

新尺子:BA-AUC

为了解决这个比较上的不公平,作者提出了一个新指标。

预算感知曲线下面积

BA-AUC(Budget-Aware Area Under the Curve):把"目前找到的最好解法得分"画成一条随累计花费变化的曲线,然后计算这条曲线在某个固定预算(比如1美元)范围内的面积。面积越大,说明这个方法在花同样的钱时,平均表现越好,不只是终点分数高。

这个指标的巧妙之处在于,它不只看"花完预算后的最终答案",还看"这一路上每一分钱花得值不值"。想象两个人同样给了100元去买菜,一个人前80元就把菜买齐了,剩下20元是锦上添花;另一个人前80元啥都没买到,最后20元才匆忙凑出一顿饭。两人最终都买够了菜(终点分数一样),但显然前者的购物过程效率高得多,你更愿意下次还找他去买菜。BA-AUC就是在衡量这个"购物过程"的效率,而不只是"买到了没有"。

有了这把新尺子,作者才能真正回答那个问题:怎样设计一个既省钱又好用的进化算法?

两个大脑分工:贵的想策略,便宜的写代码

答案的核心,是一个叫FrugalEvo的框架,设计思路其实很直白。

![图1](fig1)

过去的方法,无论是AlphaEvolve还是OpenEvolve,用的都是同一个模型既想策略又写代码。这就像让一位麦肯锡战略顾问亲自下场写Excel公式一样,贵是贵在"想法"上,但把贵的脑力资源耗在了"执行"这种重复劳动上。

FrugalEvo把这两件事拆开了,让一个强模型专门负责"想",一个弱模型专门负责"做"。论文里的具体配置是GPT-5.6 Terra(贵的,负责策略探索)配GPT-5.6 Luna(便宜的,负责代码实现和调试),或者GLM-5.3配它的Flash版本。

这个分工能生效的前提,是编程这件事本身存在"想法"和"执行"价值不对等的特点。一个好的算法思路,比如"用约束优化配合线性规划微调半径",一旦想清楚了,具体写出可执行代码这件事,对一个便宜模型来说完全够用,它只需要不断试错、看报错信息改bug,这是体力活不是脑力活。

**真正值钱的是那个"换个角度试试"的灵感,不是把灵感敲成代码的手速。**

反过来想,如果让贵模型自己一条龙做到底会怎样?论文的消融实验给出了答案:在Signal Processing任务上,全程用高成本模型(Terra+Terra)的平均得分是0.685,而分工合作的FrugalEvo是0.778,足足高出接近10个百分点。原因很直白,贵模型每次调用都在吃预算,如果它既要想策略又要反复调试代码里的bug,很快预算就耗尽了,根本轮不到探索第二个、第三个想法。

如果反过来,全程只用便宜模型呢?在Circle Packing任务上分数掉到2.6346(对比完整方案的2.636),差距看起来不大,但论文指出低成本模型"不擅长识别哪些策略真的有前途",它能写代码,却缺乏判断一个方向是否值得深挖的直觉。这就像让一个执行力很强但经验不足的新人自己定战略,他能把每个想法执行得很漂亮,但选错了方向,再漂亮的执行也是白费。

让缓存替你省钱:提示词的排列顺序大有讲究

FrugalEvo还有一个不太起眼但很实用的设计,叫缓存高效的进化流程。

这个设计建立在一个技术细节上。

提示词缓存

prompt caching:许多LLM API(如OpenAI的接口)支持对重复出现的提示词前缀进行缓存,重复部分只收取很低的费用,而不是每次都按全价计费。

这意味着,如果你每次给模型的提示词开头部分几乎一样,只是结尾那一小段在变化,那么开头那部分的费用可以大幅压低。FrugalEvo的做法是,有意识地把"不怎么变的内容"(任务说明、输出格式要求)放在提示词最前面,把"经常变的内容"(比如最新一次评估反馈)放在最后面。

这就像整理行李箱。你把这次旅行每天都要用的东西,牙刷、充电器,放在箱子最外层固定的格子里,每天拿取路径都一样;把今天才决定要带的临时物品,比如某个会议特需的文件,放在箱子最上面随手能换的位置。如果反过来,把常用物品随意塞在箱子最底下,每次翻找都要把整个箱子倒腾一遍,耗时耗力。提示词的排布本质上在做同一件事,把"固定不变"和"经常变化"的内容分层安放,让系统能识别出哪部分可以直接复用,不用每次都重新"结算"。

这个看似微小的工程细节,直接体现在了结果上:图1(c)显示,FrugalEvo平均每次迭代只花0.97美分,而AdaEvolve要花4.35美分,相差超过4倍。

先热身再冲刺:冷启动阶段的意义

FrugalEvo还设计了一个叫做冷启动的小环节。

冷启动

Cold Start:在正式进化开始前,先用便宜模型对最初给的那个简单示例程序做几轮快速优化,直到分数不再提升,把这个优化过的版本作为后续策略探索的起点。

为什么要加这一步?因为如果直接拿题目给的那个很粗糙的初始程序去让贵模型分析、想策略,贵模型很可能被这个烂底子带偏,提出的策略质量也会打折扣。

这就好比请一位建筑设计师来改造一间毛坑式的旧厨房。如果你直接让他从这个毛坯状态开始构思方案,他可能得先花大量脑力去理解这堆乱七八糟的管线走向,设计灵感被琐碎细节淹没。但如果你先找个水电工把最基本的水管电线理顺,哪怕没有美感,至少功能正常,设计师再来的时候就能直接聚焦在"怎么让厨房更好用更好看"这件事上。消融实验也验证了这点:去掉冷启动后,Circle Packing任务的平均分从2.635989掉到2.632417,肉眼可见的下降。

实打实的战绩:从数学题到真实系统

说了这么多设计理念,实际效果怎么样?论文在20个真实任务上做了测试,覆盖数学优化、系统优化和算法竞赛三大类。

圆形装箱

Circle Packing:把26个半径可变的圆塞进单位正方形,让所有圆的半径之和最大化,是一个经典的几何优化难题,常被用作检验优化算法能力的标杆任务。

结果相当亮眼。用GPT-5.6 Terra+Luna组合,FrugalEvo花1.68美元就把半径之和从初始的0.9598提升到2.635996,这个数字甚至超过了AlphaEvolve公开报告的2.635000。换成更便宜的GLM-5.3+Flash组合,花0.55美元也能达到2.635990。作为对比,那些动用多个智能体协同作战的方案,比如CORAL和SwarmResearch,平均要花掉约50美元才能达到类似水平(分别是2.635985和2.635996)。

换算一下,这相当于花不到2%的钱,拿到了和百倍预算同等甚至更好的成绩。

在信号处理任务上,FrugalEvo达到0.78912分,远超所有基线方法中最好的AdaEvolve(0.73677)。在Heilbronn Convex几何问题上,FrugalEvo匹配了AlphaEvolve的最优结果0.03094。在5个系统优化任务(来自ADRS基准,涵盖专家负载均衡、GPU显存分配、SQL前缀缓存等真实工程场景)上,FrugalEvo在4个任务上拿下最高的BA-AUC。在10个来自AtCoder竞赛改编的算法题上(ALE-Bench-Lite),FrugalEvo平均分1924.9,超过表现最好的基线OpenEvolve(1887.5)将近40分。

| 任务类型 | FrugalEvo表现 | 对比基线最佳 | 成本 |

|---|---|---|---|

| 圆形装箱 | **2.635996** | AlphaEvolve 2.635000 | $1.68 |

| 信号处理 | **0.78912** | AdaEvolve 0.73677 | $2预算内 |

| 算法竞赛均分 | **1924.9** | OpenEvolve 1887.5 | $1预算内 |

这些数字背后,是FrugalEvo在不同任务里"长出"了完全不同的解题风格。在圆形装箱问题上,它学会了用五行布局配合不对称偏移,再用约束优化(SLSQP)和线性规划来精修。在系统任务里的专家负载均衡问题上,它找到了一套结合贪心复制、负载感知分配和局部交换微调的调度策略。这些都不是人提前设计好的,是整个进化流程自己摸索出来的。

这套方法的边界在哪

诚实地说,FrugalEvo不是万能钥匙。

论文作者自己坦白了两个局限。第一个局限是,这套方法天生适合"代码能自动跑、自动打分"的场景,比如数学证明、算法竞赛、系统调度,答案对不对电脑说了算。但如果换到生物学这种需要真实湿实验才能验证的领域,整套自动化循环就转不动了,因为没有一个"评估器"能瞬间告诉你这个方案好不好,你得真的去培养细胞、做实验,这个反馈周期是以天甚至月计算的,不是以秒计算的。

第二个局限更有意思。引导策略探索这一环,靠的是人工精心写好的提示词模板,而不是让系统自己去学习"怎么提问题才能问出好策略"。这意味着换一个全新领域,可能还得有人坐下来重新设计一套提示词,这中间有多少专家经验是隐性嵌入在里面的,论文没有细说,但可想而知不会少。

写在后面

读完这篇论文,有个念头一直在脑子里转:我们习惯把AI系统的能力和它用的模型大小、算力规模直接挂钩,默认"更强的模型等于更好的结果"。但FrugalEvo给出的那张$0.55就刷新世界纪录的截图提醒我,很多时候瓶颈根本不在模型能力,而在整个系统设计有没有把钱花在真正值钱的地方。

另一个让我意外的细节是,高成本模型全程参与反而会拖累整体表现,这和直觉是反的。我们总以为"最强的那个模型从头到尾负责"肯定最靠谱,但论文的消融实验说得很清楚,贵模型如果被迫去处理调试代码这种重复劳动,它的"想法生产力"反而被稀释了。这其实在提醒一件更普遍的事:资源分配不是越多越好,而是要分配到真正能产生杠杆效应的那个环节上。

这个思路放到别的场景里也适用。一个团队里最资深的工程师,如果每天忙着改格式、修小bug,而不是去想架构,那他的"高成本"就被浪费在了"低价值"的事情上。FrugalEvo某种程度上是在用一套自动化系统,把这个常识重新证明了一遍。

Q&A

Q1:FrugalEvo是什么?

A:FrugalEvo是一个成本感知的大语言模型引导程序进化框架,核心思路是用一个强大但昂贵的模型负责探索优化策略,用一个便宜模型负责实现和调试代码,再配合缓存高效的提示词设计,在固定预算下获得更好的优化结果。

Q2:BA-AUC指标解决了什么问题?

A:过去评测LLM优化方法只看固定迭代次数后的最终分数,忽略了成本差异,导致花钱多的方法可能被误认为更聪明。BA-AUC通过计算"最优得分随累计花费变化"曲线下的面积,能公平比较不同方法在同样预算下的真实效率。

Q3:FrugalEvo在圆形装箱问题上表现如何?

A:用GPT-5.6 Terra和Luna组合,FrugalEvo只花1.68美元就将半径之和优化到2.635996,超过AlphaEvolve公开报告的2.635000;用GLM-5.3和Flash组合只需0.55美元就能达到2.635990,远低于动辄花费50美元的多智能体方案。

分享至
0赞

好文章,需要你的鼓励

推荐文章
----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.-