← #804

马里奥遇见帕累托

文章摘要

Antoine Mayerowitz 这篇「滚动叙事」（scrollytelling）式的交互文章，用《马里奥赛车 8》的配车问题，把经济学家 Vilfredo Pareto 一个多世纪前提出的概念讲得极为直观。

出发点是一个每个玩家都遇到过的困境：在《马里奥赛车 8》里，选择角色、车身、轮胎和滑翔翼不只是审美问题，它对胜负的影响不亚于你的驾驶技术。每一类都有几十个选项，每个选项又有一组彼此独立的属性（速度、加速、操控、重量、越野、迷你涡轮），组合起来是天文数字。好消息是很多选择纯属外观（属性完全相同），但即便去重之后，仍有数千种组合需要抉择。

如果只看单一维度，问题很简单：想跑得最快就按速度排序，库巴（Bowser）和瓦里奥（Wario）看起来是无脑之选。但你不能只看速度——还要考虑加速，因为被道具击中后需要迅速恢复。一旦引入第二个维度，「最优」就不再是平凡的问题，你必须做权衡。

这时帕累托登场。作者用可交互的散点图展示：某些选项在任何情况下都是被「支配」（dominated）的。文中拿可怜的库巴・特鲁帕（Koopa）举例——猫版碧姬公主在同样加速下速度更高，奇诺比珂在同样速度下加速更高，那么无论你的偏好如何，都没有理由选 Koopa。把所有「不会在两个维度上同时被支配」的选项挑出来，就构成了帕累托前沿（Pareto front / frontier）。

作者随后强调了一个关键的、常被误解的点：前沿上的选项并非同样好。你多半不会选前沿最边缘的那个，因为你想在速度与加速之间保持某种平衡。帕累托效率是一个客观标准，用来剔除劣势选项，但最终决策仍然要你自己做——你的操作风格和技术水平决定了你给各项属性分配多大权重，而这些偏好会揭示前沿上最适合你的那一个。文章接着把每一整套（角色+车身+轮胎+滑翔翼）组合都画成一个点，让选择空间爆炸性膨胀，再次演示帕累托前沿如何收拾局面。

最后作者把话题拉回现实：这个模式无处不在。你想要一顿又便宜又好吃的饭？一份高薪、轻松又有成就感的工作？一个低风险高回报的投资组合？一种柔韧、强度高又易于生产的材料？一套既公平又高效的税制？一个高质量、同时又快又便宜的 LLM？这些都是多目标优化问题，都必须做权衡。他补了一句重要的前提说明：如果你已经确切知道每个维度的权重（也就是知道自己的效用函数），那么问题就退化成单目标优化，你把各维度加权合成一个量去优化即可，根本不需要帕累托。帕累托真正的用处，是在效用函数未知或不确定的情况下——它客观地帮你排除所有次优选项，虽然不能一上来就指出唯一最优解，但你可以在这批有效选项里实验，挑出最适合自己的那个。

致谢部分作者也坦白了简化：文中展示的属性其实会被换算成并非总是线性的游戏内衍生数值；除角色外，其他部件各有 4 项速度与 4 项操控数值，他做了简单平均；效用函数的具体形式也被完全隐去，而它其实相当关键。

HN 评论精华

这是一篇 2024 年的旧文重发（Retr0id 和 devin 都贴出了两年前的讨论链接），因此讨论主要围绕可视化效果、游戏事实核查和概念的现实应用展开。

jerf 贡献了最有价值的一条延伸，把概念带回了软件工程：开发者经常听到「我们不能在不牺牲 Y 的情况下获得更多 X」，最常见的版本是「我们不能在不牺牲用户体验的情况下提升安全性」。带着帕累托的概念去看，你会发现这句话当且仅当你已经处在安全性与用户体验的帕累托前沿上时才成立。而现实中很多这类自信断言，其面对的系统显然根本不在前沿上，你完全可以两者兼得。他还补了一个陷阱：在商业环境里你永远无法抛弃「钱」这个维度，所以除非你一开始就把钱列为比较维度之一，否则它会自己溜进来，把问题变成三维——而正如文章所说，维度增加会让前沿显著扩大，这有好有坏。munchbunny 补充说，一旦把成本纳入考量，确实会看到更多真正处于帕累托最优边界上的情况。voidhorse 则从这里划出了「写代码」与「工程」的分界：工程就是对系统设计做出有依据的权衡；但他提醒，并非所有问题都有漂亮的解，很多空间里存在多个有效点仍需人来选，而且帕累托优化问题在规模足够大时会变成 NP 难。
游戏事实核查方面出现了分歧。demibabs 认为文章不够准确：在《马里奥赛车》里加速的重要性出人意料地低，并不是选择最优组合时的主要因素；真正的最优组合只由速度和迷你涡轮决定。__s 从速通角度佐证：《超级马里奥赛车》速通用库巴/大金刚，MK8 速通同样选处在前沿边缘的库巴——「需要加速是技术问题」。但 paytonjjones 反驳说速通是单人跑图，正常对局有道具，再强的玩家也躲不掉某些全屏道具，因此会受益于加速——这也正是文章提到的、竞技玩家偏好平衡型（碧姬公主）组合的原因。Jepacor 讲了个生动的例子：他帮忙主持的一场 MK8 比赛上，有个孩子选了库巴并把速度点满，结果每个弯都过不去；换成 meta 组合后立刻从第 10 名冲到第 2 名——「这游戏在选车环节就能把自己坑得这么惨，其实挺奇怪的」。latexr 则给出了反向的实用主义辩护：如果你在一群新手里遥遥领先到能领先整整一圈，选库巴等于给自己上难度，降低胜率但提升全场乐趣。
关于文章形式，讨论呈两极。andai 惊叹「这是某种 3D PowerPoint，他是怎么做的」，作者 superMayo 亲自现身回复：源码在 GitHub 上，这种形式叫 scrollytelling，他从 mlu-explain.github.io 借鉴了很多，3D 部分用 Three.js 加自定义顶点着色器。但 ShinyLeftPad 报告移动端严重损坏（其他人表示 Firefox on Android 正常），voidnullvalue 直言不喜欢这种臃肿的网页设计、滚了一会儿就点了返回。Xirdus 在 Firefox 阅读模式下只看到 5 段文字，追问是不是丢了大部分内容——duskdozer 确认交互图表是滚动时由 JavaScript 生成的，天然无法被阅读器无障碍地读取。
a3w 的开场白引出了一段关于教学法的讨论：他说自己看不懂前几天另一篇（同样讲帕累托的）帖子，但这篇看懂了。applfanboysbgon 由此感慨：当你用具体、可代入的场景、简单的语言和有用的可视化来教，而不是用抽象的 X、Y、foo、bar 加上每三个词就冒出一个陌生术语，很多东西对更多人来说会变得极其易懂——「我们在教学法上真的得做得更好」。prvc 提出了完全相反的偏好：他的注意力恰恰在别人迟迟不进入正题、纠缠于本身并不有趣的细节时消散。
实际应用的例子也不少。yathern 说他就是从这个网站学会帕累托前沿的，随后做了 minipcs.zip，把迷你主机按算力与价格（以及其他指标）作图并标出帕累托前沿。dorfsmay 认出老项目管理三角（便宜、好、快）其实是这个概念的一个特例。Agentlien 则对文中的日常例子提出异议：他并不希望「轻松」是工作要优化的维度，对他来说有成就感的工作恰恰意味着充满深度技术挑战；他想要的是没有多余摩擦、没有人际戏码、低压力，但绝不是轻松。Georgelemental 回应：那你只是在效用函数里给「成就感」更高权重而已；换成一位需要为家庭留出时间和精力的单亲父母，可能宁愿要「轻松」，代价是无聊的苦差。
玩家们的私人恩怨也很好看：hspeiser 说他和哥哥常年玩这个，哥哥总赢，自己偶尔赢一次就跟过节一样——现在才发现哥哥的组合正好在帕累托前沿上，而自己的差得远，「哥你完了，下次再战」。moomin 代表一群爸爸提出了另一个优化目标：什么车能让我保持竞争力、但大概率输给孩子？jedberg 反其道而行之：「我得一直赢到赢不动为止，好让那小子知道自己的位置。他每次都更接近了，我知道我的日子快到头了。」