要选一个大模型做应用，一般人的做法就是打开当下的模型排行榜，找分数靠前的。但真正用起来问题才陆续出现，比如AI 报告写得漂亮，但事实还要逐条核对，或者代码生成很快，但合进项目却出了新问题，又或者工具调用显示成功，文件仍然没保存对。
这些落差有一个共同原因：我们拿来比较的成绩，没有完整回答实际工作中的问题。写出答案、写对答案，以及把事情办完，验收条件各不相同。
可以产生的很清晰的判断是：应用评测最终要看，AI 能否在可接受的成本下，稳定完成具体工作。所以，公开基准帮助我们找到值得测试的候选，自己的任务评测再决定能不能采用。
沿着这个判断看写作、知识库、编程、数据分析、Agent 和多模态，就容易理解为什么需要不同基准，每个场景都有自己的完成条件，分数只有对应这些条件，才有选型价值。
如果要求只是“这个模型要聪明、准确、好用”，几乎任何排行榜都能拿来参考，却很难据此作出选择。要求具体到“根据原始材料生成报告，事实可核对，修改后可以发布”，我们才知道该测什么。
评测基准就是事先约定好题目、运行条件和评分办法的一套测试。它测得再认真，也只能回答规定范围内的问题，评测前先写清交付物和完成条件，才能判断一项公开成绩与自己的需求有多接近。
还要明确被测对象。单独给模型一道题，主要观察模型能力；把检索、工具、提示词和执行环境接起来，检查的就是整套系统。比如，模型读懂了文档，知识库仍可能因为没检索到那份文档而回答错误。
评测对象的三个层次。
对于应用选型，我更建议优先比较完整系统的任务表现。基础能力成绩可以帮助排查原因，但用户等待结果、核对内容和返工所花的时间，都取决于整套系统的表现。
下面就结合六类场景的区别，搞清楚用户究竟要验收什么？
写作任务的交付物是一份供人阅读和使用的内容。模型遵守字数、格式和关键词要求，当然有用；但一份结构完整、语气流畅的报告，仍可能把待讨论的意见写成已经确定的决定。
IFEval 把能够自动核验的指令做成测试，例如字数范围、关键词等。它提供的是指令遵循方面的证据。报告是否忠实于材料、重点是否清楚、读者是否容易看懂，还需要另一层检查。
所以，写作助手的评测应当把硬要求与内容质量分开：格式、必填项交给程序检查；事实、遗漏和表达由评审对照材料判断。比较两份输出时，隐藏模型名称，用同一套标准审阅，会比凭品牌印象打分更有用。
如果借助另一个模型打分，也要抽查它的判断，防止把篇幅更长、措辞更自信误当成质量更好。对实际采用的决定，值得再记录一项：使用者为了把初稿改到可交付，花了多少时间。输出快几秒，却要多核对半小时，效率优势就未必成立。
写作可以容纳一定的表达差异，依据资料回答问题则需要更明确的证据。假设用户问某项费用能否报销，系统要找到适用条款，读清条件，再给出结论。少一步，都可能生成一段看着合理、实际用不了的回答。
这也是知识库评测不能只看最终答案的原因。采用“先检索资料，再让模型回答”的 RAG 方法时，错误可能出在检索，也可能出在阅读和推理。把它们合成一个准确率，虽然方便比较，却不方便修复。
LongBench v2采用长上下文中的多类任务，并通过选择题评价理解和推理。它适合提供材料给到之后的能力证据。RAGBench则提供问题、文档、生成回答及相应标注，包含回答是否得到文档支持等信息，可用于研究和检验 RAG 评估方法。两者关注的问题不同。
资料图：THUDM / LongBench 团队｜LongBench v2 题目长度与专家作答情况
图中阅读重点
左图横轴为按词数划分的输入长度区间，颜色代表任务类别；右图是专家作答时间分组中的正确与错误题数。
自己的系统可以做一次有用的对照：先把支持答案的材料直接交给模型，再运行完整检索流程。直接提供材料能答对，完整流程却答错，就优先查资料是否找全、上下文是否选对；材料齐全仍答错，再查模型对条件的理解。
验收时应分别检查答案是否正确、引用是否支持结论，以及证据不足时系统是否承认不知道。碰巧答对却引用错误的回答，后续很难复核；准确引用旧规定却漏掉新规定，同样不能交付。知识库的价值在于减少查证工作，评测就应沿着这件事来设计。
知识库问答需要把结论追溯到资料，编程任务则可以进一步把结果放进环境里运行。不过，运行什么，仍然决定了分数的含义。写出一道代码题的解法，与在现有项目里修复错误，需要处理的上下文和约束差别很大。
LiveCodeBench使用竞赛题等材料，覆盖代码生成、执行和测试输出预测等任务。对于明确题意下的代码能力，这些测试很有参考价值；团队如果打算让 AI 维护仓库，就还需要仓库级任务的证据。
SWE-Bench Pro V2这类评测把代码补丁应用到指定环境，再检查问题是否解决。任务更接近项目修改，也更依赖测试质量、运行环境和 Agent 的工作方法。
因此，给团队选择编程助手，我会优先看它在目标项目上能否定位问题、通过修复测试，并且不破坏原有功能。后者要靠回归测试检查。只记录“生成了补丁”，验收还没有完成。
评测用的测试也需要复核，OpenAI 在 2026 年 2 月讨论 SWE-bench Verified时，指出题目质量和数据污染问题，并停止报告该项分数。这是该机构的分析与选择，不能推成所有机构的共同决定；但它提醒我们，测试通过能提供多强的证据，取决于测试本身是否可靠。
在数据分析里，代码运行成功只是中间结果。假设 AI 要计算月度收入，查询可以顺利返回数字，却把退款算了进去，或者把下单时间当成收款时间。程序没有报错，业务问题仍然答错了。
Spider 2.0面向企业级 Text-to-SQL 工作流，任务涉及数据库结构、文档和复杂查询环境。它所反映的难点是：生成查询前，系统要先理解数据放在哪里、字段怎样关联，以及环境中的约束。
资料图：Spider 2.0 作者团队｜企业级 Text-to-SQL 工作流示意
图中阅读重点
左侧是数据库、文档与代码环境，右侧是查询生成及执行反馈。看懂一句需求只是起点，还要找到适用的结构和口径。
如果主要工作是用 Python 处理数据，可以参考DS-1000，它提供覆盖 NumPy、Pandas 等库的数据科学代码任务，通过执行和约束检查评价结果。这类测试有助于判断代码能力，具体业务中的统计口径仍需自己补上。
业务验收应先写清统计对象、时间范围、单位和去重规则，再核对结果。保留查询、代码及关键中间结果，是为了让审核者查清数字从哪里来，而不是只面对一个无法追溯的结论。
如果一套分析助手给出了正确数字，却把相关关系解释成因果关系，报告仍然可能误导决策。因此，数据分析至少需要分别检查计算结果与结论是否成立。评测越接近实际使用，就越不能停在“执行成功”这一项上。
06、工具调用与 Agent：检查任务结束后的实际状态
写报告、答问题和分析数据，都还有人阅读结果。Agent 一旦开始保存文件、修改记录或操作软件，评测就得继续往后检查：系统说完成之后，目标环境到底发生了什么变化？
Berkeley Function Calling Leaderboard，简称 BFCL，观察函数调用相关能力，不同版本包含单轮、多轮及 Agent 相关子项。它能帮助检查工具选择和参数等问题。选对工具、填对参数，是任务完成所需的一部分。
τ-bench 系列进一步把用户交互、规则和工具放进可运行环境，检验一段流程能否完成。通过桌面界面操作软件的任务，则可以参考OSWorld 2.0，接口调用与桌面点击面对的环境不同，选基准时要与准备采用的操作方式对应。
资料图：Sierra / τ-bench 团队｜τ²-bench 中用户与 Agent 的工具交互片段
图中阅读重点
左侧用户通过工具查看并开启移动数据；右侧 Agent 检查并修改漫游设置，最后还要验证网络是否恢复。
对自己的 Agent，最终检查应落在实际状态上：目标路径中有没有正确文件，记录中的字段是否按要求修改，操作失败时有没有留下半成品。自然语言里的“已完成”，只能作为待核对的输出。
还需要对同类任务重复运行，记录失败发生在哪一步。某次演示顺利结束，说明这条路径可能走通；准备交给用户长期使用，则需要知道成功能否稳定复现、失败后是否容易发现和处理。
07、多模态与文档：从“看见信息”测到“理解关系”
前面几类任务主要讨论模型怎样处理内容和执行动作。输入换成图片后，还多了一项检查：模型读到的信息，是否对应正确的对象和位置？
读报告时，模型即使识别对了数字，也可能看错列标题或金额单位。对于文档应用，这些关系直接决定答案能否使用。只检查文字识别，无法完整评价读文档的能力。
经典DocVQA任务要求根据文档图像回答问题，答案从图中提取；ChartQA围绕图表问答，涉及视觉信息和逻辑推理。前者帮助观察信息查找，后者让我们关注数值与年份、系列、图例等信息之间的关系。DocVQA 项目还有其他任务，引用成绩时应注明具体数据集。
如果准备让 AI 读扫描报告，就用实际会收到的清晰度和版式测试，加入多栏、跨页、单位变化等情况。让模型指出答案所在的位置，也有助于复核它是否找对依据。测试内容应随应用输入而变：文档表现好，并不能顺带说明视频和语音也处理得好。
六类应用的交付物不同，比较方法却有一个共同要求：测试条件必须说清楚，否则，我们无法判断分数变化来自能力提升，还是来自题目、预算或运行方式的变化。
首先核对版本和子集。τ-bench 的 2.0.0 发布说明就明确提醒，沟通检查、判定及提示等发生变化，新版成绩不能直接与 1.x 比较。同一个项目名称，并不保证始终使用同一把评分尺度。
随后核对尝试和资源预算。十次里至少成功一次，与通常第一次就能完成，给用户带来的体验不同。更多推理、工具调用和重试可能提高完成率，也会增加等待和开销。比较候选系统时，应一起记录任务完成情况、耗时和成本。
还要说明比较的是模型还是应用。研究模型差异，需要尽量固定提示、工具和预算；采购应用，可以比较各自优化后的完整系统，但应保留配置说明。两种比较都有价值，结论需要对应各自的对象。
比较成绩前需要核对的四类条件。
平均分之外，要单独看不能接受的失败。例如，系统大部分题都答得不错，却反复搞错金额单位，其他题目的高分无法消除这项使用障碍。关键错误的验收条件，应由实际后果决定。模型评分要抽查，测试用例和训练数据污染也需要关注，不能因为评分自动完成就省去复核。
做到这里，公开基准已经帮助我们分清了候选系统的能力与短板。最后的采用决定，需要回到真实工作：哪些任务值得交给 AI，做到什么程度可以接受，失败到什么程度就要暂停使用？
起步时可以先整理一批有代表性的任务，写清输入、可用资料、允许的操作和完成条件。常见任务反映日常价值，材料缺失、数据冲突、工具报错等情况帮助发现使用边界。中文应用要加入自己的中文材料、缩写和专业术语。
验收标准尽量对应可观察的结果。文件是否正确保存、计算结果是否一致，可以由程序检查；文章是否清楚、专业判断是否合理，需要合适的评审人员。法律、医疗等专业应用，应由相应专家参与。
用于改进系统的样本和最终验收的样本要分开。开发者可以反复研究前一组，但如果一直对照验收题调整提示词，分数上涨就难以说明系统处理新任务的能力。资料来源、时间和版本也应记录清楚。
公开基准筛选，自有任务验收。
每轮保留输出、工具轨迹、失败原因、耗时和成本。修改以后重跑相关任务，并检查原本做对的任务有没有退步。这些记录既帮助选型，也帮助决定后续该换模型，还是先修检索、工具和流程。本文提供资料梳理与评测建议，未对候选模型进行实测。
如果一个候选系统在你的任务上更稳定、返工更少，使用成本也能接受，那么即使它的公开排名稍低，也可能是更合适的选择。值得肯定的是，有价值的评测，最终应当让这样的采用决定有据可查。
