我下意识的反应不是打开某个榜单找榜首，而是先问自己：这个榜单想回答什么问题。榜单像一张被压缩过的地图，能帮我们快速认路，也会把一些细节抹平。我平时给团队做选型，会把榜单当成初筛工具，把业务测试当成复测工具，两套东西一起看，心里才踏实。
这一章我想把“榜单体系”和“结果解读”拆开聊。国内外榜单不少，名字听起来都很权威，实际定位差别挺大。有人爱看聊天竞技场，有人盯学术基准，有人只信自己跑出来的业务题。我的态度比较朴素：先弄明白榜单怎么来的，再看它适不适合我的场景。
1.1 国内外主流评测榜单梳理与定位
我常把国外榜单分成三类来看。聊天偏好类里，LMSYS 的 Chatbot Arena 很有代表性，它靠用户盲测投票形成排名，读起来直观，偏真实对话体验。学术基准类里，MMLU、GSM8K、HumanEval 这些基准经常被榜单引用，HELM、OpenCompass 这类评测体系会把多项任务打包起来看。开源模型榜里，Hugging Face Open LLM Leaderboard 的关注度很高，很多开发者拿它看开源模型的整体表现。Artificial Analysis 这类独立分析站点会把性能、价格、速度放在一起，做大模型性能对比时挺有参考价值。
国内榜单我更习惯按“中文能力”和“应用导向”去理解。SuperCLUE、C-Eval、CMMLU 这些名字在中文评测里出现频率很高，侧重点各有不同，有的偏知识问答，有的偏中文理解，有的会覆盖推理和生成。FlagEval、AGI-Eval、OpenCompass 中文评测这类体系更接近覆盖较全的评测平台，维度铺得比较开。我在实际选型里会看它们的定位：是想测聊天体验，还是测考试能力，还是测业务任务完成度。定位弄错，排名看得越多越乱。
我还会提醒自己，榜单名字不等于榜单质量。一个榜单叫“大模型性能对比”，不代表它覆盖了成本、延迟、安全、长上下文这些生产指标。国外榜单对英文任务覆盖更充分，国内榜单对中文语境更友好，行业榜单可能更贴近垂直场景。我的做法是给每个榜单贴标签：偏好类、基准类、应用类、价格速度类。贴完标签再去看分数，脑子会清醒很多。
1.2 榜单评测维度、数据来源与更新机制对比
评测维度这块，我通常先看它有没有把“能力”拆开。语言理解、知识问答、数学推理、代码生成、多模态、长上下文、工具调用、安全对齐，这些维度放在一张总表里很容易被平均分掩盖。我更愿意看分项分数，再看权重怎么设。聊天类榜单偏主观体验，学术类榜单偏题目正确率，应用类榜单会加入任务完成度和人工评分。维度不同，大模型性能对比的结论就会跟着变。
数据来源也值得多问一句。公开题库跑分很常见，题目一旦公开，训练数据污染的风险就上来了。众包投票能反映偏好，投票人群的构成会影响结果。专家标注更细，成本也更高。企业真实请求脱敏后的评测集更贴近业务，公开程度往往有限。我看到一个榜单时，会翻它的说明页，看看题目来源、标注方式、防污染手段。说明页写得太含糊，我会把它的参考权重调低。
更新机制是我很在意的一点。静态榜单适合看历史截面，动态榜单更适合看当前状态。模型版本迭代很快，榜单如果几个月不更新，排名容易过期。我会看它有没有标注评测日期、模型快照、提示模板、采样参数。LiveBench 这类动态题库的思路，就是为了降低题目泄露带来的偏差。LMArena 持续收集投票，排名会随样本变化。榜单更新越透明，我做大模型性能对比时越敢引用。
1.3 同一模型在不同榜单中的排名差异及原因
同一个模型在不同榜单里排名不一样，这事太常见了。我拿同一个 API 去对照过几个榜单，聊天竞技场里表现靠前的模型，在数学基准里可能只算中游。中文榜单排得高的模型，换到英文任务上未必继续领先。排名像一面镜子，照的是榜单关心的那部分能力，不是模型的全部。
差异来源挺多。任务权重不同，总分就会被拉偏。提示词写法不同，模型输出风格会变。采样温度、few-shot 示例、系统提示、是否允许工具调用，都会影响得分。评测框架的解析逻辑也会掺进来，代码题看测试用例通过率，开放题看人工或模型裁判，裁判本身也有偏好。我见过同一模型在 A 榜单被夸“表达自然”，在 B 榜单被批“事实性不足”，两边说的可能都是真的。
模型版本和评测时间也会制造差异。榜单跑的可能是某个快照版本，我调用的是最新版 API，系统提示也不一样。投票人群的语言习惯、专业背景会影响偏好类排名。题库污染会让某些模型在公开题上虚高，换到私有测试集就掉下来。我看排名差异时，习惯先对齐版本、提示、参数、评测集，再看分数。对不齐，比较就像拿苹果和橘子比甜度。
1.4 榜单结果的适用边界与误读风险
榜单有边界，我的理解是：它擅长做横向初筛，不擅长替业务做最终决策。总分高，说明它在榜单覆盖的任务上表现不错，不代表它在我的客服场景、合同审阅场景、代码补全场景里同样好用。成本、延迟、并发、稳定性、安全合规，这些生产指标经常不在榜单主表里。把榜单榜首直接搬进生产，风险挺大。
误读风险里，我最怕“只看总分”。总分是权重设计后的结果，权重一变，排名就变。还有人把开源榜排名当成“开箱即用”的证明，开源模型的能力和部署工程、推理优化、微调数据强相关，榜单分数只是起点。数据污染、刷榜、评测集过拟合，这些坑在大模型性能对比里一直存在。榜单日期不看清，拿旧排名指导新选型，也容易踩空。
我的做法比较笨：榜单当筛子，业务当尺子。先按场景挑两三个相关榜单，圈出候选模型，再用自己的测试集跑一轮小规模对比。测试集不用很大，覆盖真实输入、边界输入、失败案例，配上人工抽检。榜单帮我缩小范围，业务测试帮我确认手感。这样看榜单，误读会少很多，选型也更有底。
我对这一章的理解是，榜单体系的价值在于“可比较”，结果解读的关键在“可解释”。弄明白榜单测什么、怎么测、什么时候测，大模型性能对比才不会变成追排名游戏。下一章我们会把视角拉到能力维度，继续拆语言、推理、多模态、安全这些分项表现。
总分榜单一出来，我第一眼还是会扫排名，第二眼就去找分项。总分像体检报告上的“整体健康”，看着舒坦，真到用药的时候还得看各项指标。我在团队里做大模型性能对比，习惯把能力拆成四块来聊：语言和知识、推理和代码、多模态和长上下文、安全与幻觉。四块拼起来，才勉强算一张能力画像。
这么拆还有个好处。同一款模型在不同能力上经常“偏科”，有的写东西顺手，做数学就露怯；有的代码题刷得漂亮，问个事实性问题反而编得理直气壮。我不太相信“全能选手”这种说法，更愿意按场景挑专长。
2.1 语言理解、生成质量与知识问答对比
语言理解这块，我感受最深的是中文的“坑”。拿客服对话测过一圈，用户说“那个昨天说的那个再给我发一下”，有的模型能顺着上下文接住，有的就开始胡乱猜。指代消解、省略补全、方言和网络用语，模型之间的差距比英文任务上明显。我试过拿一段带反讽的评论让模型判断情绪，旗舰款基本能读出“话里有话”，轻量款容易按字面意思理解，结果就跑了偏。
生成质量我常拿同一段产品文案去“盲测”。让几家模型各写一版，隐去名字发给同事打分。有意思的是，得分高的往往不是参数最大的那个，而是表达节奏更自然的。结构化输出更考验功力，比如让它吐一张规范的 JSON 表格，字段名、嵌套层级、转义字符，细节上拉开的差距挺大。我见过有的模型内容写得漂亮，格式一塌糊涂，接进程序里还得人工修。
知识问答是我最谨慎的一块。常识类问题大家表现都不错，时效性一上来就分化了。问一些近期的事件，不同模型的“知识新鲜度”能差好几个月。我一般会看两个指标：答得对不对，以及不知道的时候敢不敢说不知道。后一点特别关键，硬答比不答麻烦得多。
2.2 推理、数学与代码能力对比
推理能力的对比，我喜欢用“绕弯题”来试。比如给一段带条件的逻辑题，看模型会不会漏掉隐含前提。简单题上大家的分数都很体面，题目一长、条件一多，差距就藏不住了。有的模型愿意一步步拆，有的直接甩结论，甩得还挺自信。我看推理表现，会特别留意中间步骤能不能复现，过程写得清楚，结果可信度就高一截。
数学这块的分层特别明显。小学应用题几乎都能做，初中代数开始出现分化，竞赛题和证明题就是分水岭。我记得拿一道需要构造反例的题去测，能完整做下来的模型不多。有些模型算对了结果但过程是编的，这种“对答案错过程”的情况，放到生产环境里要格外小心。
代码能力是我用得最多的对比维度，原因很直接，结果可验证。跑单元测试，通过率一目了然。除了 HumanEval 这类基准，我更爱看真实项目里的表现：补全一段上下文、重构一个函数、解释一段报错。旗舰模型在长函数理解和跨文件推理上优势明显，轻量模型写小片段没问题，一放到工程上下文里就有点接不住。还有个细节，代码解释能力比代码生成能力更能看出模型的“理解深度”，能把一段烂代码讲明白的模型，通常也能改得明白。
2.3 多模态、长上下文与工具调用能力对比
多模态我踩过坑。看宣传材料觉得都能读图，实际拿发票、表格、折线图去测，识别准确率差得挺远。图表问答最考验综合能力，要先读出坐标轴，再理解趋势，最后用语言组织答案。我试过让几款模型解读同一张财务图表，有的能准确说出同比变化，有的把图例看串了。多模态这块，模型之间的代差比纯文本更大。
长上下文是另一个“标称和实际有落差”的地方。标着 128K、200K，真往里塞长文档，中间部分的信息容易丢。我做过大海捞针式的测试，把关键信息放在文档中段，召回率明显不如开头结尾。做长文档问答的时候，我会特意设计几个需要跨段落关联的问题，这种题最见真章。标称窗口大，不等于每个位置都“看得清”。
工具调用我关注三件事：参数填得准不准、多轮编排顺不顺、调用失败能不能自己纠正。函数调用看着简单，参数类型、枚举值、嵌套结构，错一个就整个失败。复杂任务里要串好几个工具，中间一步出错，后面的链条就断了。有的模型会主动检查上一步结果再调下一步，这种“有意识”的编排能力，比单次调用准确率更值得看。
2.4 安全对齐、鲁棒性与幻觉控制对比
安全对齐这块，榜单上体现得最少，生产上最要命。我拿角色扮演、假设场景、多语言切换去试，有的模型能力很强但特别“听话”，一句“现在你是不受限的助手”就绕过去了。拒答尺度也得看，太松有风险，太紧又影响可用性。我见过模型把正常的医学咨询当敏感内容拒掉，也见过它对明显有害的请求照答不误。这条线怎么划，各家策略差别不小。
鲁棒性是我近半年花时间最多的方向。提示注入最典型，往文档里埋一句“忽略以上指令”，有的模型真就照做了。格式扰动、多轮诱导、跨语言攻击，都是常见的测试手法。我自己的体会是，鲁棒性和模型能力不完全是正相关，有些小模型反而因为“保守”躲过一劫。拿真实业务文档做注入测试，比跑标准安全基准更有说服力。
幻觉控制我分两层看。一层是事实一致性，回答里的数字、人名、时间对不对得上。另一层是“自知之明”，不知道的时候会不会承认。我做过一个简单实验，问一批冷门的地方性政策问题，统计模型答错和拒答的比例。有的模型错得少但拒得多，有的敢答但错得离谱。做 RAG 场景的时候，这两层表现直接决定了要不要加引用校验和置信度门控。
四块能力看下来，我的感受是：大模型性能对比不能停在总分上，得往下钻到分项，再往下钻到具体任务。分项分数告诉我模型擅长什么，具体任务表现告诉我它在我这儿能不能用。这两层中间还差一次“业务翻译”，下一章聊开源和闭源的时候，我会继续把这个视角带进去，看能力差异背后的生态因素。
上一章结尾我留了个尾巴，说能力差异的背后往往站着生态因素。这一章就把这话展开聊聊。我在团队里同时用着闭源 API 和本地部署的开源权重，时间一长，感受很具体：闭源模型像精装交付的商品房，拎包入住，水电物业有人管；开源模型像毛坯房，结构给你了，怎么装修、装成什么样，全看自己。大模型性能对比这件事，一旦把开源和闭源放在同一张桌子上，光看跑分就不够了，得把迭代节奏、可控性、工程成本一并算进去。
这几年最明显的变化是追赶速度。前两年开源模型和闭源旗舰之间隔着一条“能用”和“好用”的河，现在这条河窄了很多，有些细分任务上甚至能摸到对岸。我自己的使用体感是，日常问答、文本改写、简单代码这类活儿，开源阵营的中等尺寸模型已经能扛住，差距主要集中在复杂推理和长链条任务上。可这个差距也不是固定的，每隔几个月就被刷新一次。
3.1 开源与闭源模型的能力梯队与追赶态势
我习惯把市面上的模型分成三个梯队来看。第一梯队是闭源旗舰，参数规模大、训练投入高，在推理、数学、多步骤工具调用这些硬骨头上领先。第二梯队是开源里的大尺寸模型，能力接近第一梯队的中上游，胜在权重公开、可以自己折腾。第三梯队是开源的小尺寸模型和端侧模型，单项能力不突出，胜在便宜、快、能塞进私有环境。分梯队看，比笼统地说“开源不如闭源”要准确得多。
追赶态势我用两个场景感受最深。一个是代码补全，开源模型这两年的进步肉眼可见，写常规业务代码、解释报错、补单元测试，已经能进生产流程。另一个是中文长文本理解，部分开源模型针对中文语料做了加强，读合同、读报告的表现不比闭源差。反过来说，遇到需要多步规划、需要严格遵循复杂格式的任务，闭源旗舰还是更稳。我的判断是，开源在“广度”上追得快，在“深度”上还差一口气。
这个梯队不是静止的。我见过某款开源模型发布时在榜单上冲得很高，过两个月就被新版本盖过去。闭源那边也一样，版本号一更新，昨天的结论就得重测。所以我做大模型性能对比的时候，很少下“谁永远更强”的结论，更愿意说“在当前这个时间点，这个任务上谁更合适”。模型迭代太快，结论的保质期很短。
3.2 版本迭代速度、透明性与可复现性对比
迭代速度这块，闭源模型的节奏由厂商定，用户只能等。好处是每次更新通常伴随能力提升和稳定性优化，坏处是你没法提前知道变了什么，有时候接口行为悄悄改了，线上效果跟着波动。我遇到过版本升级后输出风格变化、格式遵循度下降的情况，排查半天才发现是模型换了。这种“黑盒更新”对生产系统不太友好，得靠自己做回归测试兜底。
开源模型的迭代节奏更碎片化。官方版本之外，社区微调版、量化版、蒸馏版满天飞，选择多是好事，挑起来也累。我一般会盯住两三个维护活跃的版本，其他的当作备选。透明性上开源确实占优，权重、配置、部分训练细节能查到，出了问题可以往下挖。闭源模型只能从外部行为反推，像隔着一层毛玻璃看东西。
可复现性是我特别在意的一点。开源模型固定住版本和推理参数，今天跑出来的结果过几个月还能复现，这对做实验和写报告很重要。闭源模型的服务端可能在做量化、做负载均衡、做版本灰度，同样的输入两次调用结果不完全一致。做严肃评测时，我会对闭源模型多跑几轮取统计值，对开源模型则把随机种子和环境版本都记下来。两种做法不一样，心态也不一样。
3.3 微调、私有化部署与生态适配能力对比
微调这件事，开源模型给了实打实的操作空间。我做过把行业术语和内部话术灌进去的微调，效果立竿见影，模型开始说“人话”了。闭源模型也有微调服务，多数是托管式的，数据要传出去，可调的范围也有限。涉及敏感数据的场景，我基本只考虑开源路线，权重在本地，训练数据不出内网，这条底线绕不过去。
私有化部署是开源模型的另一个主场。硬件自己买、环境自己搭、推理框架自己选，吞吐和延迟能按业务调。代价是运维得自己扛，显存不够要量化，并发上来要加机器，模型升级要重新验证。我算过一笔账，小规模调用用闭源 API 更省心，调用量一大、又有数据合规要求，私有化部署的账才算得过来。这里的大模型性能对比不只看模型本身，还得看配套的推理引擎、量化方案、监控工具链。
生态适配能力容易被低估。开源模型的周边工具很丰富，量化、蒸馏、LoRA、推理加速，社区方案更新快，遇到问题搜一搜多半有人踩过坑。闭源模型的生态围绕厂商转，文档规范、SDK 齐全，可定制空间小。我个人的搭配是：核心链路用闭源保稳定，边缘场景和数据敏感的场景用开源保可控。两条腿走路，比押注单一路线踏实。
3.4 性能差距背后的数据、算力与工程因素
拉开差距的第一因素还是数据和算力。闭源旗舰动辄万卡级别的训练投入，数据清洗和配比是长期积累的功夫，这些不写在论文里，体现在模型的“手感”上。开源模型受限于预算，训练数据规模和多样性差一截，复杂推理上的短板往往从这里来。我见过一些开源模型在单项基准上很亮眼，一放到开放场景就露怯，原因多半是训练分布偏窄。
工程因素同样关键。推理优化、对齐策略、安全护栏，这些活儿做没做、做得多细，直接决定用户体验。闭源厂商有专门团队打磨这些细节，开源模型更多靠社区贡献，质量参差不齐。我拿同一批提示词去测，闭源模型在格式稳定性、拒答尺度把握上明显更整齐，开源模型偶尔会给出“惊喜”，也偶尔给出“惊吓”。
说这些不是要分个高下。我越来越觉得，开源和闭源的性能差距，本质上是资源投入和工程成熟度的差距，不是路线优劣的差距。选型的时候，我会把任务难度、数据敏感度、调用规模、团队运维能力摆在一起看。榜单上的分差是参考，能不能在自己的场景里稳定跑出预期效果，才是最终答案。下一章聊推理成本，这个话题会接着往下算账。
上一章我说推理成本要接着往下算账，这一章就把账本摊开。性能对比聊到最后，绕不开钱这个字，我见过不少团队在榜单上比得头头是道，一到预算会就卡壳。大模型性能对比如果只比跑分不比成本，选型报告写出来是悬空的。
我自己的体会是，成本这件事特别容易算偏。API 的报价单看起来清清爽爽，每百万 token 多少钱写得明明白白，可真正跑起来，账单跟预估能差出两三成。自建那边更复杂，一张卡的钱只是开头，后面还有一堆隐形支出在排队等着。
4.1 单位Token推理成本与API定价对比
闭源模型的 API 定价是明牌。输入多少钱、输出多少钱、有没有缓存折扣、batch 调用能不能打折，条款都摆在官网上。我上个月接了个内容改写的活儿，按公开价估了个数，月底拿到账单发现超了将近三成。查下来原因不复杂，输出 token 比预估的多，输入里重复的提示词占比又高，缓存没命中，折扣也没吃上。单价低不等于总价低，这是我交的第一笔学费。
开源模型自己部署的话，单 token 成本得自己摊。卡的钱、电费、机位、运维人力，一股脑摊到每个月的 token 消耗里，摊出来的数字跟 API 价没有直接可比性。我帮一个朋友算过，他那个规模用开源 7B 模型加一张消费级卡，摊下来单 token 成本只有 API 价的零头。换到 70B 那个量级，账就完全翻过来了，卡贵、电贵、吞吐还上不去，摊出来的单价反而比 API 贵。
这里有个细节很多人忽略。开源模型的单 token 成本不是固定值，量化做不做、batch 开多大、上下文多长，都能让单价浮动好几倍。我做过一次测试，同样一张卡跑同一个模型，开不开连续批处理，吞吐差出三倍多。聊大模型性能对比聊到成本这一层，不看推理配置只比单价，容易得出误导性的结论。
4.2 私有化部署的硬件、运维与弹性成本对比
硬件这块我列过一张清单。推理卡、服务器主板、内存、NVMe 存储、交换机、UPS、机柜改造，一项项列下来，数字不算不知道。买卡也不是一锤子买卖，按三年折旧摊，每个月的固定成本硬邦邦地压在那里。业务量上不来的时候，这笔折旧就成了纯负担。
运维人力是最容易被低估的隐形项。模型服务要有人盯着，驱动升级、量化版本更新、监控告警、故障排查，一个兼职工程师根本忙不过来。我见过一个团队兴冲冲买了两台推理服务器，结果没人专职维护，三天两头出故障，撑了半年又把主链路切回 API 了。那份折腾的成本，比 API 差价贵得多。
弹性是私有化部署真正的软肋。业务有波峰波谷，机器买多了平时闲置心疼，买少了峰值扛不住。云上 GPU 能按小时开，价格又比年付高出一大截。我现在的做法是核心流量走自建，溢出流量走云上 API 兜底，这套混合方案不优雅，账算下来最舒服。
4.3 吞吐、延迟、并发与能效表现对比
闭源 API 的延迟通常更稳，P99 有服务等级协议兜着。并发上去之后还是会排队，我遇到过高潮时段响应时间翻倍的情况，前端体感一下就差了。API 的吞吐上限不在自己手里，这个问题做容量规划的时候挺让人头疼。
自建的吞吐靠推理框架和量化策略撑起来。vLLM、SGLang 这些引擎，同一张卡跑出来的吞吐能差好几倍。我拿一个默认配置跑过基准，换成调优过的配置，吞吐直接翻了两番。量化也是同理，INT8 跟 FP16 一比，显存省一半、吞吐上一个台阶，精度损失多少得自己拿业务数据验。
能效这块平时没人细算。一张满载的推理卡功耗几百瓦，乘上机房的 PUE 系数，电费一年下来不是小数。跑同样的请求量，能效高的方案在长期账本上优势明显。我做大模型性能对比做到成本这一项的时候，会把每百万 token 的耗电量也列进去，这个指标在长期运营里比一次性采购价更重要。
4.4 不同调用规模下的成本曲线与盈亏平衡点
我把调用规模画成横轴、月成本画成纵轴，API 那条线基本是从原点出发的斜线，用多少花多少。自建那条线是先高后低的曲线，前期固定投入把线顶得很高，规模上去之后被摊薄。两条线交叉的位置，就是自己的盈亏平衡点。
这个点因人而异。月调用量几十万 token 的团队，用 API 省心省钱，没必要碰硬件。日调用量上亿 token 的业务，自建那本账算得明明白白，还能把数据留在内网。我在两个极端之间都待过，中间的纠结地带最磨人，账算来算去差不太多，拼的是团队对运维的承受力。
我的建议是先按 API 跑起来。把真实调用量、输入输出比例、业务峰值都摸清楚，等月账单稳定超过自建固定成本加运维人力的总和，再认真考虑迁移。大模型性能对比在成本维度上没有标准答案，只有适不适合自己这本账。规模会变，模型会换代，这个平衡点隔几个月就得重新算一次。
榜单上的分差，落到业务里经常对不上号。我印象很深的一次，某模型在通用评测里排得挺靠前，真接到客服系统里跑了三天，答非所问的比例高得吓人。换成另一个榜单排名中游的模型，反而稳得多。大模型性能对比做到场景这一层，才算是摸到了真东西。
我的看法是，场景评估没有统一的尺子。每个业务的输入长什么样、输出要多准、延迟能忍到多少，全都不一样。拿别人的结论直接套，八成要返工。下面这四个场景，是我这几年试错试出来的几条经验。
5.1 对话助手与内容生成场景对比
对话助手看起来是最简单的场景，实际上坑不少。我拿同一个提示词分别喂给几个主流模型，聊十轮左右就能看出差别。有的模型前面几轮温吞水，越聊越散，最后完全跑题。有的模型慢热，但多轮下来语气和立场能稳住。做客服类的应用，后面这种更值钱。
内容生成的对比更直接。我做过一批公众号文案的测试，同一个选题让五个模型各写三稿。写得快的模型，出稿速度确实爽，读下来一股模板味，句子结构几乎一模一样。慢一点的模型写得更像人话，偶尔还能冒出个我没想到的角度。生成质量的差距，不看样本量不看细节，根本比不出来。
这里有个我踩过的坑。早期测试只比单次输出，结论完全失真。后来改成连续生成二十篇，再看风格漂移、重复率、事实错误，排名直接翻了个个儿。做大模型性能对比，样本量太小得出的结论，导进选型报告里就是灾难。
长文生成又是另一回事。我让模型写两万字的技术手册，有的写着写着就忘了前面的设定，术语前后不一致。有的模型能撑住长程一致性，代价是速度慢一半。这个权衡没法从榜单上看出来，只能自己拿真实需求跑。
5.2 RAG、知识库与长文档处理场景对比
RAG 是我测试花时间最多的场景。这件事的复杂度在于，模型只是链条上的一环，检索器、切分策略、重排都得算进去。我搭过一套测试集，两百道题，答案全部来自内部的制度文档。同样的检索结果，喂给不同模型，答对率能差出十个百分点以上。
差距主要出在两个地方。一个是模型对噪声上下文的处理，检索回来的片段里混着无关内容，有的模型会被带偏，答得一本正经但完全错误。另一个是引用定位，有的模型能准确说清答案来自哪一段，有的就笼统带过。做知识库问答，第二个能力对用户信任度的影响特别大。
长文档处理我专门测过一次。一份一百多页的合同扔进去，让模型提取关键条款并做风险提示。上下文窗口够长的模型都能塞进去，读得质量差别很大。有的模型中间部分明显读虚了，开头结尾记得清楚，中间的关键条款漏了。这个现象我在好几个模型上都见过，位置靠中间的信息容易丢。
我的做法是把长文档任务拆开测。定位类问题、摘要类问题、跨章节推理类问题分开评估，再看总分。混在一起测出来的分数，掩盖的问题比暴露的多。大模型性能对比在 RAG 场景里，模型的能力只是一半，另一半在检索管线上，这个账要分开记。
还有一个容易忽略的点，是模型对格式的遵从度。我要求输出 JSON，带字段名和置信度。有的模型十次里能守住九次，有的三次就崩一次，格式一乱下游解析全挂。这种事榜单不会告诉你，上线之后才知道疼。
5.3 Agent、工具调用与复杂任务编排场景对比
Agent 场景是我认为最能拉开模型差距的地方。单轮问答看不出高下，一旦让模型自己规划步骤、调用工具、根据返回结果调整，能力差异就赤裸裸地摆出来了。我搭过一个测试环境，给模型五个工具，让它完成一个需要四步才能搞定的任务。
结果挺有意思。有的模型第一步就选错工具，后面全盘皆输。有的模型规划没问题，参数传错，工具报错之后不会自我纠正，在那儿反复重试同一个错误调用。还有的模型能根据报错信息调整参数，第二次就成功了。这三种表现的差距，比任何榜单上的分数差都直观。
多步任务的成功率会指数级衰减。单步成功率九成的模型，串到五步，端到端成功率就掉到六成以下。我在一个报表生成的场景里吃过这个亏，每个环节看着都挺稳，最后一算整体成功率，惨不忍睹。后来加了失败重试和人工兜底，才勉强上线。
工具调用的稳定性也值得单独说。我测过模型的函数调用格式正确率，主流模型在简单函数上都能做到接近满分。函数参数一复杂，嵌套结构一多，差距立刻显现。参数类型搞错的、必填项漏掉的、把字符串和数字搞混的，各种花样都有。
这一块我的建议是把 Agent 测试做成回归集。每次换模型或者升级版本，跑一遍同样的任务集，看端到端成功率和平均步数。大模型性能对比在 Agent 场景里，过程指标比结果指标更有诊断价值，知道错在哪一步，才知道该不该换。
5.4 行业垂直、端侧与隐私敏感场景对比
垂直行业的测试最费劲，也最值钱。我参与过一个医疗问答的评估，通用模型在公开评测里分数漂亮，扔到真实的病历问答里，专业术语理解错的、药品剂量说反的，问题一堆。换成在医学语料上继续训练过的模型，表现立刻不一样。
金融和法律的场景类似。合同审查、合规检查这类任务，对精确性的要求高到苛刻。我见过通用模型把条款里的"不超过"读成"不少于"，这种错误在别的场景里无伤大雅，在合同审查里就是事故。垂直模型的优势不在于更聪明，在于它不容易在最基础的地方翻车。
端侧场景是另一个维度。我把几个小参数量的模型塞进笔记本和手机里跑过，能不能跑起来是第一关，跑起来之后的质量是第二关。量化到 4bit 之后，有的模型还能保持基本可用，有的模型直接语无伦次。端侧场景的大模型性能对比，功耗、内存占用、首 token 延迟这些指标，权重比纯质量分还高。
隐私敏感的场景，很多时候不是模型能力的问题，是部署方式的问题。数据不能出院子的业务，闭源 API 直接出局，只能在开源模型里挑。这时候要比的就是私有化部署之后的能力保留度，我一般会在目标硬件上跑一遍业务测试集，看量化后的实际表现，而不是拿原始精度的分数做参考。
我最近的体会是，场景评估的颗粒度要跟业务重要性匹配。核心业务值得花两周搭一套完整的测试集，边缘业务跑个几百条样本看看方向就够了。把有限的评估精力撒胡椒面，每个场景都测得很浅，最后哪个场景的结论都不敢信，这才是最亏的。
做到第六个章节，我想聊聊选型这件事本身。前五章聊的都是怎么看性能、怎么测场景，可真正坐到决策桌上，手里的信息往往是碎片化的。榜单分数一堆、价格表一张、场景测试报告几份，怎么把这些拧成一股绳，落到一个具体的选择上，这才是最考验人的地方。
我自己经历过好几次选型翻车。有一次是太信榜单，把排名第一的模型直接接进生产，结果延迟扛不住，用户投诉一片。还有一次是太抠成本，选了便宜的方案，跑了两个月发现维护成本比省下来的调用费还高。这些教训让我慢慢摸索出一套自己的打法。
6.1 构建多维性能对比矩阵与权重设计
我现在的习惯是，不管选什么模型，先拉一张表出来。横轴是候选模型，纵轴是评估维度。维度一般分五类：任务质量、推理成本、响应延迟、稳定性、生态配套。每类下面再拆细项，比如任务质量拆成准确率、格式遵从度、拒答合理性，成本拆成单位 token 单价和私有化摊销。
这张表最难的环节是定权重。我见过不少团队在这上面栽跟头，所有人拍脑袋给个百分比，加起来等于一百就完事。真正靠谱的做法是从业务目标倒推。拿客服场景举例，延迟的权重我通常给到两成以上，用户等三秒就开始烦躁，等五秒直接关窗口。内容生成场景反过来，质量权重拉到四成，延迟可以让步。
还有一个办法我觉得挺实用，就是给每个维度设一条红线。低于红线直接淘汰，不参与加权计算。比如格式遵从度低于九成的模型，不管别的维度多漂亮，我都不考虑。红线这个机制能挡掉很多看着总分高、实际一用就崩的选择。
权重的数值不用追求精确。我试过用层次分析法算权重，算出来的结果跟拍脑袋差别不大。后来我就简化了，把维度分成三档：必须满足、重要、加分项。三档制比百分制好用得多，团队里谁都看得懂，讨论起来也不容易跑偏。
矩阵建好之后，我一般会做一次敏感性测试。把权重上下浮动两成，看排名会不会大洗牌。如果排名对权重特别敏感，说明候选模型之间的差距本来就不大，这种时候选哪个都行，不如挑便宜的或者生态好的。如果某个模型在大部分权重组合下都稳居前列，那它就值得重点考虑。
6.2 结合榜单、成本与场景的选型决策流程
我自己的决策流程分三步走，顺序不太能颠倒。第一步拿榜单做初筛，把候选池从几十个缩到五六个。第二步算成本，把明显超出预算的划掉。第三步拿真实场景的测试集跑一遍，用数据做最终裁决。
榜单初筛这一步，我主要看两件事。一是榜单的评测维度跟我业务的重合度，重合度低的榜单参考价值有限。二是榜单的更新日期，超过半年的榜单我基本只当背景信息看，模型迭代太快了，老榜单容易误导人。初筛的目的是排除，不是选出冠军，这个定位要摆正。
成本测算这块，我的经验是要算总账，不能只看 API 单价。私有化部署的硬件折旧、运维人力、扩容弹性，这些隐性成本加起来往往比 API 费用还高。我做过一个对比，某开源模型私有化部署的年化成本，折算到同等调用量上，比主流闭源 API 贵了三成。这个结论跟很多人的直觉相反。
场景验证是最后一道关，也是最花时间的一关。我的做法是从业务日志里抽两百到五百条真实请求，做成测试集，让候选模型各跑一遍，人工抽检加自动评分结合着来。这个环节我一般会给两周时间，急不得。跑完之后把结果填回 6.1 那张矩阵里，权重一乘，排名基本就出来了。
流程里有个细节我想强调一下，就是候选模型的数量要控制。我试过同时测八个模型，测到后面整个人都是晕的，数据也容易串。现在一般控制在三到四个，最多五个。少而精比多而杂强，决策效率也高得多。
还有一点，选型不是一锤子买卖。我现在的做法是设一个观察期，选定之后先小流量灰度跑一个月，盯着线上指标看。灰度期间发现问题的，及时换掉。这个机制救过我两次，一次是模型在高并发下延迟抖动超预期，一次是某类长尾请求的错误率明显偏高，都是测试环境里没暴露出来的。
6.3 性能对比中的常见误区与验证方法
我踩过的坑里，最常见的一个是只看总分不看分项。某次选型，两个模型总分只差零点几分，我随手选了高的那个。上线之后才发现，高分模型在长文本上的表现明显偏弱，而我的业务恰好是长文档处理为主。总分是平均出来的，平均值掩盖短板这件事，在模型选型里特别致命。
第二个误区是拿公开测试集的分数当业务表现的预判。公开测试集跟真实业务数据的分布差异很大，模型在 MMLU 上考九十分，不代表它在你的客服对话里也能拿九十分。我现在的规矩是，公开榜单只做参考，决策必须用自有数据。这条规矩帮我避开了不少坑。
样本量不足导致的误判也很常见。我早期做测试，每个模型跑二十条样本就下结论，后来复盘发现结论跟跑五百条样本的结果差了一大截。二十条样本里的随机波动，足以把排名搅乱。现在我的底线是每条测试集不少于两百条，核心场景拉到五百条以上。
验证方法这块，我总结了几条实用的。一是做交叉验证，同一批数据分三次跑，看结果的稳定性。二是做对抗测试，故意构造一些边界输入，看模型会不会崩。三是做回归测试，每次模型版本更新都跑一遍同样的测试集，看能力有没有退化。第三条最容易被忽略，可它恰恰是最重要的，模型升级不总是往好的方向走。
还有一个验证手段值得单独说，就是影子流量。把候选模型跟线上模型并行跑，同样的请求两边都发一份，只把线上模型的结果返回给用户，候选模型的结果拿来做对比分析。这个方法的好处是完全真实，坏处是要多花一份推理成本。核心业务我觉得这个钱值得花，边缘业务可以省。
我见过一个团队，选型报告写得特别漂亮，各种图表数据齐全，结果上线三个月就换模型了。后来一聊才知道，他们的测试集是从公开数据里拼的，跟真实业务八竿子打不着。验证方法再花哨，数据源头不对，结论就是空中楼阁。
6.4 大模型性能演进趋势与评测体系展望
这两年看下来，我的一个直观感受是模型之间的能力差距在收窄。两年前头部模型和腰部模型的差距是一道鸿沟，现在这道沟浅了不少。开源模型的追赶速度尤其快，半年前还差一截的能力，新版本一发布就补上了。这对选型来说其实是好事，选择的余地更大了。
评测体系也在变。早几年的榜单主要考通用知识，现在越来越多的榜单开始考 Agent 任务、长上下文、工具调用这些更贴近实际使用的能力。我觉得这个方向是对的，评测越贴近真实任务，榜单的参考价值就越高。不过场景化评测的成本也上去了，维护一套高质量的评测集，投入不比训练一个小模型少。
我预测接下来评测体系会往两个方向走。一个是动态化，用不断更新的题目防止模型刷榜，静态测试集被污染的问题已经挺严重了。另一个是个性化，企业用自己的业务数据搭私有评测集，公开榜单退回到初筛工具的位置。我现在给团队的建议就是尽早搭自己的评测集，越早搭越值钱。
成本趋势也值得说两句。推理成本这两年降得很快，同等能力的模型，单位 token 价格一年降一个数量级的情况我都见过。成本下降会改变选型的逻辑，以前因为贵而放弃的方案，现在可能就变得可行了。我做成本测算的时候，会把未来一年的降价预期考虑进去，不拿当前价格做死判断。
模型能力的演进方向，我个人比较关注的是幻觉控制和长程一致性。这两块是目前落地时最头疼的问题，也是模型之间差距最明显的地方。榜单上这两项的分差看着不大，实际用起来的体感差异非常大。我期待未来的评测体系能把这两项单独拎出来，给足权重。
最后说一句我的整体判断。大模型性能对比这件事，工具和方法会越来越成熟，但决策的核心还是人对业务的理解。模型是死的，业务是活的，把业务需求翻译成评估维度的能力，短期内 AI 替代不了。选型策略做得好不好，七分靠对业务的理解，三分靠对模型的了解，这个比例我到现在还这么认为。
