1.1 什么是模型准确率排行：从单一分数到综合榜单
我自己刚接触大模型那会，最迷惑的一件事就是——打开各种榜单，满屏都是数字和百分比，某个模型今天排第一，明天就掉到第五。当时我以为"模型准确率排行"就是把模型考一遍试，谁分高谁就牛。后来踩过几次坑才明白，事情远没有这么简单。
模型准确率排行，本质上是把不同模型放在一套统一的任务集合上跑一遍，然后按照某种规则打分排序。它像学生时代那种全市联考的排名表，考的都是同一张卷子，分数可比。区别在于，大模型的"卷子"是分科目的，有的是考知识问答，有的是考数学推理，有的是考代码补全，还有的专门测长文本理解。一张榜单只反映一个切片，把好多切片拼起来，才勉强看出一个模型的轮廓。
早期那些排行确实挺粗糙的，基本上就是单一准确率数字定生死。一个模型在测试集上答对多少题，除以总题数，得出一个百分比。听着挺公平，实操里各种问题。题目难度分布不均、答案判定规则模糊、有的模型靠"见过原题"刷分。我自己拿同一个模型在不同榜单上的名次对比过，前后能差出十来个身位，一度怀疑是不是看错了。
所以现在的准确率排行越来越像"综合榜单"：给不同维度分配权重，把准确率、响应速度、价格、安全合规性这些东西揉到一起，生成一个综合分。这个综合分更好看，也更接近产品选型时的真实需求。代价是——权重怎么设，主观得很。榜单背后的设计者一调参数，名次就可能翻盘。
1.2 准确率排行的核心指标：准确率、鲁棒性、推理成本与安全性
准确率这个指标，说白了就是"答对的题数除以总题数"。我在做选型的时候最容易被它吸引，因为它直观。一个模型标着 88% 的准确率，另一个 81%，我会本能地偏向第一个。问题是这个数字本身很脆弱，题目换个问法、答案换个格式，结果就能上下浮动好几点。
鲁棒性是我后来才重视起来的维度。它测的是模型在输入被干扰、措辞被改动、上下文被加噪声之后，还能不能稳住输出质量。有的模型在标准测试集上成绩漂亮，一旦把题目换成口语化表达，准确率就垮掉一大截。这种"温室里考出来的高分"，放到真实业务里很容易翻车。我遇到过一次，线上用户的提问方式跟评测集完全不一样，模型答得七零八落。
推理成本跟安全性这两年权重一直在涨。推理成本直接关系到你每千次调用的账单，贵的模型在排行榜上名次靠前，但你未必用得起。安全性涉及的是模型会不会输出有害内容、会不会被诱导绕过限制。我自己做过一个内部小评测，发现某个在法律问答上准确率很高的模型，遇到违规话题的拒答表现特别差。放到对外产品里，这就不是"考试扣分"的问题了，是要担责任的。
这几个指标之间经常打架。准确率高的模型往往推理成本也高，安全性做得严的模型有时候会变得过度保守，连正常问题都推三阻四。排行榜给它们配权重的时候，其实是在回答一个更根本的问题：你到底看重什么。
1.3 常见评测基准与数据来源：MMLU、GSM8K、HumanEval、C-Eval 等
MMLU 可能是被引用最多的基准之一，它的全称是"大规模多任务语言理解"，覆盖了从数学到法律到医学的几十个学科，题目多是四选一。这个基准的好处是覆盖面广，能测出模型的知识广度。坏处也明显，四选一这种形式，模型蒙对的概率本身就存在，而且不少题目在网上流传已久，有没有被训练数据"背下来"，说不清楚。
GSM8K 走的是另一条路，专注小学数学应用题。题目不难，考的是多步推理能力。我自己拿几个模型跑过这个基准，差距特别明显：有的模型能一步步把推理过程写清楚，有的直接给答案但答案是错的。这个基准的好处是答案唯一、判定简单，坏处是它测的推理能力偏窄，只能看数学场景。
HumanEval 针对代码生成，给一段函数签名和注释，让模型补全代码，然后跑单元测试验证。这个基准的判定很硬核，跑不过测试就是错，没有模棱两可的空间。我在做代码助手选型时特别看重它，但后来发现 HumanEval 的题目规模偏小，而且有些模型针对它做过优化，分数虚高。
C-Eval 是中文语境下的评测集，覆盖学科也挺全。国内团队做中文应用时，会拿它当主要参考。它的价值在于贴合中文表达习惯，很多英文基准翻译过来跑，模型表现会失真。数据来源这块，我自己的经验是——不能只信企业自报的分数，多方交叉比对方能看出门道。有的榜单是学术机构维护，更新慢但相对中立；有的是厂商自己发的，漂亮归漂亮，权重设多少全看他们想突出什么。
1.4 排行榜的价值与边界：为什么高分不等于业务高效果
排行榜最大的价值在于省时间。面对几十上百个模型，我不可能一个个从零测起，榜单帮我快速缩小范围，把明显不合适的筛掉。它给了我一个粗略的坐标系，知道市面上大致有哪几个梯队，谁在知识问答上强，谁在代码任务上领先。
但它的边界也特别清楚——高分跟业务效果好，是两码事。评测集是固定的、封闭的，业务场景是流动的、开放的。用户提问带着错别字、带着口语、带着前后矛盾的上下文，这些在标准测试集里基本见不到。我见过准确率榜首的模型，在真实客服场景里表现平平，也见过榜单中游的模型，因为稳定性好、响应快，反而更适合落地。
榜单缺失的一块是"业务对齐"。没有哪个公开排行榜知道你卖的是什么产品、你的用户长什么样、你能接受多少延迟。这些只能靠自己做内部评测来补。我现在的习惯是，把公开榜单当"初筛工具"，把内部任务集当"终审法官"。榜单告诉我这个模型大概行不行，内部评测告诉我它到底行不行。
另外一点值得警惕的是刷榜动机。榜单有名气之后，就会有团队专门针对它做优化，把分数堆上去。这种分数溢价，跟真实能力的距离会越拉越大。所以我每看到一个高出同侪一大截的分数，第一反应不是惊喜，是想搞清楚它是怎么做到的。
2.1 大模型准确率排行榜最新的头部模型变化
我差不多每隔两周就会去刷一遍几个主流榜单，说实话，最近这一年刷榜的体验跟坐过山车差不多。去年还能记住谁是第一名，现在头部那几个位置换得太频繁了，今天 GPT 系的新版本上去，过一个月 Claude 又反超，再过一阵子某个国产模型突然杀进前三。我一度把榜单截图存下来做对比，发现半年时间头部名单换掉了差不多一半。
这种变化背后其实是发布节奏在提速。各家厂商基本保持两三个月一次大更新的频率，每次更新都针对性补短板，数学弱就堆数学数据，代码弱就加代码训练。我自己观察到的一个规律是，新模型发布后的头两周，通常会带着一堆漂亮的分数冲榜，这个时候的成绩往往最好看。等过一两个月，第三方复测出来，分数会回落到一个更真实的位置。
头部变化的另一个特点是差距在收窄。早几年第一名跟第十名能差出十几个百分点，现在头部几个模型之间常常只差一两个点，有时候甚至落在误差范围里。这个变化对选型的影响挺大的——以前看排名就能定，现在得看具体任务上的得分，因为综合排名第一的模型，未必在你的场景里赢。
我现在的习惯是不追"当前第一名"，而是盯"第一梯队"。梯队里那几个模型的分数咬得很紧，谁排前面谁排后面，参考价值有限。真正有信息量的是它们跟自己上一代比进步了多少，以及在新出现的评测维度上表现如何。
2.2 闭源模型与开源模型的排名差异
闭源和开源在榜单上的位置关系，这两年明显在变。我印象里 2023 年的时候，开源模型能挤进前十就算新闻了。到了现在，同参数级的开源模型在不少单项上已经能摸到闭源第一梯队的门槛，数学和代码这两个方向尤其明显。我自己测过几个开源模型，做代码补全这类任务，输出质量跟闭源差距已经很小了。
差异主要还是集中在综合能力上。闭源模型在长尾知识、冷门领域问答、多轮对话的稳定性这些地方，整体还是领先。我拿同一个医学相关的问题问过开源和闭源模型，开源那个答得挺流畅，但细节上有几处编造，闭源的会明确说这个信息它不确定。这种"知道边界在哪"的能力，榜单上的分数不一定能体现出来。
榜单差异也有评测条件的原因。闭源模型调用时，厂商后端可能用了更高的推理算力，比如多次采样投票、更长思维链，这些都会拉高分数。开源模型如果自己本地部署，受限于显存和延迟，往往要量化、要限制输出长度，实际跑出来的分数会比官方报告的低一截。我吃过这个亏，看官方榜单选了个开源模型，自己部署完发现效果打了折扣。
还有一个容易被忽略的点：开源模型的榜单表现跟推理框架关系很大。同一个模型权重，用不同的推理引擎、不同的量化精度，分数能差好几个点。闭源模型就没这个烦恼，你调 API 拿到的是厂商调好的版本。这个差异在选型时得算进去。
2.3 不同任务维度的准确率表现：知识、数学、代码、长文本与多模态
我自己做选型时最大的体会是——不要看总榜，要看分项榜。综合排名靠前的模型，往往是在好几个维度上都还行，但没有任何一个是绝对最强。真正的问题在于，你的业务到底吃哪个维度。
知识类任务上，闭源大模型整体稳一些，尤其是需要调用大量事实性内容的场景。开源模型在常见知识上表现不错，遇到偏门领域就容易露怯。我做过一个历史类问答的小测试，开源模型对中国古代史的细节回答准确率明显低于闭源，尤其是涉及具体年份和人物关系的问题。
数学和代码这两个维度，开源追得最猛。GSM8K 这类小学数学题，头部开源模型基本都能做到九成以上。代码任务上，HumanEval 的分数差距已经很小，有的开源模型甚至能反超一些闭源的中端版本。我在实际写代码辅助工具时发现，开源模型在补全单函数这种任务上完全够用，涉及跨文件重构、理解整个项目结构的场景，闭源还是更靠谱。
长文本是个很有意思的维度。榜单上标着 128K、200K 上下文窗口的模型一大把，真正能在长文档里精准定位信息的没几个。我测过"大海捞针"这类任务，把一句话藏在一大段材料中间让模型找，有的模型标称支持超长上下文，实际在中间位置就开始丢信息。这个维度的分数水分比较大，得自己拿业务文档测才准。
多模态是最近榜单变化最剧烈的方向。图像理解、图表问答、视频理解这些任务，半年内头部名单几乎换了一遍。我的感受是这个方向还在快速迭代期，今天的第一名可能下个月就被另一个模型在细分任务上超过。选多模态模型的时候，我会更看重它在具体任务上的表现，比如 OCR 准不准、图表数据读得对不对，而不是看综合排名。
2.4 榜单时效性、更新频率与数据污染风险
榜单的时效性是个很现实的问题。我关注过几个榜单，有的每周更新，有的几个月才动一次。更新慢的榜单看久了会误导人，你以为是当前格局，实际上已经是半年前的状态。我有一次拿着一个季度前的榜单做选型，选出来的模型在当时已经不算最优了，白折腾一轮。
更新频率高也不全是好事。有的榜单为了保持活跃度，频繁加入新模型，但评测流程做得不细致，分数波动很大。我见过同一个模型在同一榜单上两周内分数差出五个点的情况，这种波动大概率来自评测条件不稳定，而不是模型真变了。看榜单的时候，我会顺手看一眼它的更新日志和评测方法说明，方法写得含糊的，参考价值就打折扣。
数据污染是我现在最警惕的一件事。公开测试集在网上流传久了，很可能进了某些模型的训练数据。表现出来就是模型对某些题目答得又快又准，但你把题目里的数字换一下、条件改一下，它就不会了。我遇到过一道数学题，模型给出的解法直接背了标准答案，但中间步骤跟题目条件对不上，一看就是"记住"了而不是"算出来"的。
判断污染的方法，我摸索出几个土办法。一个是看模型有没有给出推理过程，纯背答案的模型往往跳过步骤。另一个是拿自己构造的新题去测，尤其是把公开题目改写过的那种。还有就是看模型在同一个知识点上的表现是否一致，如果某几道题秒杀、同类的其他题却一塌糊涂，多半有问题。榜单上那些高出同侪一大截的分数，我现在都会先打个问号，再去找复测数据对照。
榜单本身也在想办法应对污染。有的开始用私有测试集，有的定期轮换题目，有的引入了动态生成的评测任务。这些做法能缓解问题，但没法根治。我自己的做法是，公开榜单只当参考坐标，真正的判断还是靠内部任务集，那个数据集不会外传，也就不会被污染。
3. 开源模型准确率评测对比：方法、结果与选型
3.1 开源模型准确率评测对比的主流方法与统一条件
我自己做开源模型对比评测有个习惯，拿到一个新模型之后不急着跑分，先把评测环境搭一遍。原因很简单，开源模型跟闭源不一样，它没有厂商给你调好的后端，同样的权重在不同机器、不同推理框架下能跑出不同的成绩。我试过同一个 7B 模型，用 transformers 原生推理跑 GSM8K，准确率是 68%，换成 vLLM 加批处理，同样的题目跑出来 74%。这不是模型变聪明了，是推理过程更稳定了。
评测条件里我觉得最容易被忽略的是提示词模板。开源模型通常有自己推荐的 chat template，你不按它那套来，分数能掉一大截。我见过有人直接套通用 prompt 去测 Qwen 系列，结果比官方报告低十几个点，问题就出在模板上。后来我的做法是，评测前先把模型的 config 和 tokenizer 配置文件翻一遍，确认它期望的对话格式，再动手跑。
采样参数也是个变量。temperature 设成 0 跟设成 0.7，选择题和数学题的准确率能差出好几个点。有些评测框架默认用贪心解码，有些默认采样，两个结果放在一起比就等于关公战秦琼。我现在固定一套自己的评测配置，所有模型都用同一套参数跑，这样出来的对比才有意义。
统一条件说起来容易，做起来麻烦。开源模型的评测要统一的东西太多了：量化精度、上下文长度限制、输出截断长度、few-shot 示例数量。我的经验是把这些写成一份评测说明文档，每次跑之前对着清单核一遍。听起来有点笨，但这个笨办法帮我省掉了很多次返工。
3.2 同参数级开源模型准确率横评
按参数级横向对比是我最常做的一件事。手里的显存有限，7B 到 14B 这个区间是我用得最多的。这个参数段的模型竞争也最激烈，几乎每个月都有新版本冒出来。我一般会挑五六个同级别的模型，用同一套题目跑一遍，重点看它们在不同任务上的分布。
一个很明显的感受是，同参数级的模型在通识类任务上差距不大。MMLU 这种综合知识测试，7B 级别的头部模型基本都落在 60% 到 68% 之间，分差往往只有几个点，考虑到评测误差，这个差距有时候不算显著。我拿几个模型答同一套高中物理题，正确率都在七成上下，错的地方也高度重合，都是那些需要多步推理的题。
数学和代码上的分化就明显多了。同样是 7B，有的模型 GSM8K 能到 80%，有的卡在 55% 上不去。这个差距不是靠参数量解释的，是训练数据的配比问题。我关注的一个模型，迭代了两个版本，参数没变，就因为数学数据加多了，GSM8K 涨了二十多个点。代码任务上也是类似的情况，HumanEval 的 pass@1 在同参数级里能从 30% 到 60% 多，跨度很大。
中文能力这块，国产开源模型整体占优。我做过一个中文常识和古文理解的测试，国产模型的表现明显比同参数级的海外开源模型好。海外模型不是不会中文，是在中文的语感、成语、文化背景这些细节上容易出错。做中文业务的话，这个维度的差距得算进选型里。
长文本和指令遵循是拉开差距的另外两个维度。同参数级的模型，标称的上下文窗口可能都是 32K，实际在长文档里的信息检索准确率能差一倍。指令遵循也是，有的模型你让它输出 JSON，它就老实输出 JSON，有的模型会自作主张加一段解释。这些在榜单分数上不一定看得出来，得自己设计测试用例。
3.3 开源模型与闭源模型的准确率差距及追赶趋势
我每年会做一次开源跟闭源的对比，看看差距到底还剩多少。2023 年那会儿，最强开源跟最强闭源之间差着两代，综合任务上差不多有二十个点的鸿沟。现在这个说法已经不成立了，在数学、代码这些结构化任务上，开源的头部队列已经贴着闭源第一梯队，有的单项还能反超。
知识问答这类任务上，差距还在。我拿一堆需要专业知识的问题测过，闭源模型在冷门领域的准确率还是高一截，尤其是需要交叉验证、需要承认自己不知道的场景。开源模型有时候会硬答，答得还挺流畅，但内容经不起推敲。这个差距我觉得不全是参数量的原因，跟训练数据的质量和覆盖面关系更大。
长尾能力是另一个分水岭。常见任务上开源追得很紧，遇到边界情况和少见场景，闭源模型的稳定性优势就出来了。我测过一个多轮对话场景，前面几轮开源模型跟闭源打得有来有回，到第七八轮开始引入复杂条件的时候，开源模型就开始跑偏，忘了前面说过的约束。
追赶速度确实快。我自己的观察是，开源模型跟闭源头部的时间差从一年多缩短到了半年左右。这个趋势对做业务的人来说是好事，意味着你能用更低的成本拿到接近的效果。我现在的策略是，核心链路用闭源保底，边缘任务和量大管饱的场景用开源，两边搭配着来。
3.4 从评测对比到落地选型：成本、许可、部署与生态
评测分数好看不等于能落地，这一点我踩过不少坑。选开源模型的时候，我会把成本、许可、部署和生态这几件事放在一起考虑，分数只是其中一项。
成本这块，开源不等于免费。自己部署要买卡、要运维、要处理并发，这些隐性成本加起来不一定比调 API 便宜。我算过一笔账，一个 7B 模型如果只是小规模自用，租个云上的 GPU 实例就够了，但如果要撑起一定并发，硬件投入和运维人力折算下来，跟用闭源 API 的花费可能差不多。量小的时候闭源反而更划算，量大到一定程度，开源的边际成本优势才出来。
许可协议我每次都会认真读。有的开源模型标着 Apache 2.0，商用没限制，用起来省心。有的模型是自定义协议，比如要求月活超过某个数就得单独申请，或者禁止某些用途。我见过有人把研究许可的模型直接拿去商用，后来被要求下架。这种事提前看清楚就能避免。
部署环节要考虑的东西更多。模型能不能量化、量化后掉多少分、支不支持主流推理框架、显存占用多少，这些都会影响实际能不能跑起来。我倾向选生态好的模型，社区里有人做过量化版本、有人写过部署文档、有人在推理框架里支持过，遇到问题能搜到答案。冷门模型跑起来是能跑，卡住的时候没人帮你。
生态还包括微调工具、数据集、周边配套。一个模型如果 LoRA 微调的教程满天飞，说明社区活跃，你想定制的时候门槛就低。有的模型发布之后几乎没更新，工具链也没人维护，用起来就得多花很多时间自己填坑。我的判断标准很简单，看这个模型在 huggingface 上的下载量、issue 活跃度，还有第三方工具的支持情况，这些信号比榜单名次更能说明它能不能长期用。
选型最后还是要回到具体任务上。我现在给业务选模型，会先拿真实数据做一轮小规模测试，看它在实际任务上的表现，再结合成本和部署条件做决定。榜单帮我缩小范围，最后一锤定音的还是自己的测试结果。
4. 模型准确率排行的应用、局限与未来趋势
4.1 如何用排行榜辅助模型选择：任务匹配与场景验证
我选模型的时候，排行榜是我第一个打开的东西。它像一张地图，告诉我现在有哪些选手、大概在什么位置。但地图不能代替走路，榜单上的名次跟我实际要解决的问题之间隔着一段距离。我一般会先看榜单的分类，找到跟我任务最接近的那一栏。做代码补全就盯 HumanEval 和 MBPP，做数学推理就看 GSM8K 和 MATH，做中文知识问答就翻 C-Eval 和 CMMLU。这样能把候选范围从几十个缩到五六个。
缩小范围之后，我会做一轮任务匹配。榜单上的综合分高不代表我的场景里表现好。我做过一个电商客服的意图识别任务，需要模型理解很口语化的中文，还夹杂错别字和网络用语。榜单上排名靠前的一个模型，在 C-Eval 上分数很高，但实际测试的时候，它对“这个多少钱包邮不”这种句子的意图判断还不如一个排名低几位的国产模型。原因就是评测基准里的中文太正式了，跟真实用户说的话不一样。
场景验证这一步不能省。我的做法是从业务日志里抽几百条真实输入，人工标好答案，做成一个小型测试集。再拿榜单上的候选模型逐个跑，看准确率、看延迟、看输出格式的稳定性。这个测试集不用很大，但一定要有代表性，覆盖高频场景和边界情况。跑完这一轮，榜单的参考价值才算真正落地。
4.2 排行解读的常见误区：刷榜、过拟合与评测偏差
榜单看多了，我慢慢发现有些分数是“做”出来的。刷榜这件事在圈子里不算秘密。有些模型团队会针对公开评测集做优化，甚至把测试集的题目混进训练数据里。我遇到过一个模型，在某个数学基准上分数高得离谱，结果换一套同难度但没公开的题目，准确率直接掉了三十个点。这种分数就是纸面上的，拿到实际业务里一用就露馅。
过拟合是另一个坑。公开评测集就那么多题，模型见过了、记住了，考的时候自然分高。这跟学生背答案去考试一个道理，考的是记忆力不是解题能力。我判断一个模型有没有过拟合，会看它在不同基准上的方差。如果一个模型在某个基准上特别突出，其他基准上平平，我就会多留个心眼。更靠谱的做法是找一些新发布的、还没被广泛使用的评测集来交叉验证。
评测偏差也经常被忽略。每个基准都有自己的偏好。MMLU 偏学术知识，GSM8K 是英文小学数学应用题，HumanEval 是 Python 函数补全。这些跟真实业务里的任务分布可能差很远。我做过一个法律文书摘要的任务，榜单上那些通用能力强的模型表现一般，反而是一个在特定法律语料上微调过的小模型更好用。榜单衡量的是通用能力，我的任务需要的是专用能力，这两者不能直接画等号。还有提示词和解码参数的敏感性。同一个模型，换个提示词模板，分数能波动好几个点。有些榜单用的是默认配置，有些用的是精心调过的提示词。我对比不同榜单的时候会注意它们有没有公开评测细节，如果没有，这个分数我就打个折扣看。
4.3 未来趋势：动态评测、多模态准确率排行与可信评估
我觉得排行榜往后最大的变化是从静态走向动态。现在的榜单大多是固定题目、定期更新，这就给了刷榜空间。未来可能会有更多动态评测平台，题目从真实用户请求里随机抽样，或者定期更换私有测试集。这样模型没法提前准备，分数更接近真实能力。我关注到一些社区已经在做这件事了，用众包方式收集新题目，实时更新排行榜。
多模态准确率排行会越来越重要。现在的榜单主要看文本，但实际应用里图片、音频、视频越来越多。我最近在测一些多模态模型，发现文本榜单上的排名跟图像理解能力几乎不相关。有的模型文本分数很高，但让它看一张图表回答问题，错误率惊人。未来肯定会出现针对多模态任务的专门排行，比如图像描述、视频问答、语音转写准确率这些维度。
可信评估是另一个方向。准确率只是模型能力的一个切面，安全、鲁棒、公平、可解释这些维度同样重要。我见过一个模型在标准测试集上准确率很高，但遇到对抗样本就胡言乱语，或者在涉及敏感话题时输出不稳定。未来的排行榜应该把这些维度也纳入进来，形成一个综合报告，而不是只给一个分数。我期待看到更多第三方审计和模型卡，让评估过程更透明。
4.4 实践清单：建立内部准确率排行与持续评测机制
我自己在团队里推了一套内部评测机制，用下来效果不错。建业务测试集是起点，从真实数据里采样，覆盖主要场景和边界情况。这个测试集要定期更新，把新出现的案例加进去，把过时的删掉。标注质量要控制，宁可少一点也要准。我们现在的测试集大概有五百条，每个季度刷新一次。
自动化评测流水线这块，每次有新模型发布，或者我们自己的微调版本更新，就自动跑一遍测试集，输出准确率、延迟、成本这些指标。结果存进一个内部排行榜，按任务类型分类展示。这样团队里谁想选模型，不用每次都重新跑，直接看内部榜单就行。自动化还有一个好处是减少人为误差，同样的脚本同样的参数，结果可比。
持续监控和模型上线后的跟踪也不能少。模型上线之后，准确率不是一成不变的。数据分布会漂移，用户行为会变化，模型本身也可能因为版本更新出现性能波动。我们会定期抽样线上请求，人工评估一部分，跟内部测试集的结果做对比。一旦发现明显下降，就触发重新评测或者微调。内部排行榜不是为了追求一个绝对分数，而是为了建立一套决策依据。榜单帮我们快速筛选，真实测试帮我们确认，持续监控帮我们兜底。这套机制跑顺了，选模型这件事就从拍脑袋变成了有据可依。
