大模型评估指标有哪些：别用一个分数判断全部能力

看到模型评测结果时，很多人会先找一个总分，再据此判断哪个模型更强。这个方法在做初步筛选时有点用，但到了实际应用阶段就不够了。模型可能在知识问答上表现不错，却经常不按格式输出；也可能回答很流畅，却会把没有依据的内容说得很确定。不同问题需要不同指标，不能让一个分数替所有能力发言。

评估的真正目的，是回答一个更具体的问题：在给定的任务、数据、约束和资源下，模型能不能稳定完成工作。这里的‘完成’既包括内容正确，也包括格式合规、风险可控、速度可接受和成本能承受。一个模型只有在这些条件同时满足时，才算真正适合上线。

因此，评估指标应该从业务任务倒推。先明确模型要做什么，再确定哪些错误最不能接受，最后选择能发现这些错误的指标。这样做出来的评测集可能没有公开榜单那么漂亮，却更能说明模型在真实系统里的价值。

任务正确性是最基础的一层，关注模型有没有完成题目要求。分类任务可以看准确率、精确率、召回率和 F1；信息抽取可以逐字段比较，统计字段是否正确、是否遗漏；数学和代码任务则需要把结果交给计算器、测试用例或执行环境验证。不同任务的正确性定义不同，不能把所有问题都换算成同一个准确率。

对于有标准答案的任务，自动评分比较方便，但要确认评分规则没有把格式差异误判成内容错误。例如同一个日期可能有多种合法写法，同一个分类结果可能带有解释文字。评分程序应当先做必要的规范化，再判断核心内容是否正确。

对于开放式写作和总结，往往没有唯一答案。此时可以拆开看事实覆盖、关键点完整性、结构清晰度和语言质量，也可以让评审者按统一标准打分。评审标准越具体，结果越容易复现，‘读起来不错’这种印象式评价越少。

事实一致性主要用于知识库问答、文档总结和带引用的回答。它不只问答案是否通顺，而是检查回答中的关键判断能不能从给定材料中找到依据。模型可能引用了正确主题，却偷偷补充了材料里没有的时间、数字或因果关系，这些都可能造成实际风险。

评估时可以把回答拆成若干个可核验的陈述，再逐条判断：材料是否支持，模型有没有改变原意，引用位置是否对应。如果系统要求模型在没有依据时拒答，还要单独测试资料缺失的样本，观察模型会不会主动说明无法判断。

这类指标通常不能只依赖另一个模型来打分。自动评审可以提高效率，但重要场景仍需要人工抽查或规则核验。对于金额、日期、政策条款和医疗建议等内容，外部知识源或结构化校验往往比生成式评分更可靠。

指令遵循关注模型是否理解并执行了任务约束。例如要求只输出 JSON、限制为三点、保留原字段、使用指定语气，或者在资料不足时明确拒绝回答。答案内容大致正确，但没有满足这些约束，放入自动化流程后仍然可能被判定为失败。

可以把指令遵循拆成格式通过率、约束满足率、完整性和拒答恰当率。格式通过率检查结构能否被程序解析；约束满足率检查长度、数量、字段和顺序；完整性检查有没有漏掉要求；拒答恰当率则检查模型在不能完成时是否给出合适的说明。

评测样本要覆盖简单和组合约束。只测‘输出三点’很容易通过，但‘根据材料列出三项风险，保留原文编号，缺少证据的项目标记为待核实，并以 JSON 输出’才能看出模型能否同时处理多个要求。

安全评估关注模型是否会生成有害内容、泄露敏感信息、绕过限制或执行不该执行的指令。不能只测试模型面对直接请求时的回答，还要加入改写、诱导、上下文混入和多轮对话等情况，观察安全边界在复杂输入下是否仍然稳定。

公平与偏见评估则要看模型对不同群体、身份、地区和表达方式的处理是否出现不合理差异。并不是所有差异都意味着偏见，但如果问题内容相同，只因为名字、性别或其他身份线索变化，回答质量和结论就明显改变，就值得进一步核查。

安全指标常用违规率、敏感内容命中率、越权成功率和拒答恰当率等方式记录。指标本身不能替代风险判断，尤其要保留失败样本和上下文，确认问题是模型本身造成的，还是提示词、检索内容或系统权限设计造成的。

响应性能决定模型能不能进入真实产品。常见指标包括首字延迟、完整响应时间、吞吐量、并发下的 P50 和 P95 延迟、超时率以及失败重试率。平均延迟看起来不错，但如果少数请求特别慢，用户仍然会明显感到不稳定，因此要同时观察分位数。

性能测试要尽量接近线上输入。短问题和长文档的占用不同，普通请求和多轮对话的缓存也不同；单用户测试得到的速度，不能直接推断多用户并发时的表现。测试时要记录模型版本、精度、上下文长度、硬件和推理参数，避免不同条件下的结果被放在一起比较。

流式输出还需要区分首字出现和全部回答完成。首字很快只能说明服务开始返回内容，不代表完整回答已经结束。如果用户需要等待结构化结果或工具调用完成，完整响应时间和超时率可能更重要。

成本指标包括接口调用费用、每次请求的 Token 消耗、服务器和显存占用、能耗、存储以及运维成本。对于本地部署，还要计算模型加载、量化、扩容和故障处理的成本；对于接口调用，则要注意输入上下文和输出长度都会影响单次费用。

不能只比较单价，还要看完成一次有效任务需要几次请求。一个模型如果经常需要重试、补问或人工修改，实际成本会高于表面价格。可以用‘每千次成功任务成本’或‘每个合格结果的平均成本’来比较，这比单独看每次请求的价格更接近业务现实。

资源约束也会反过来影响质量。例如为了降低显存使用而进行量化，可能导致某些任务准确率下降；为了减少延迟而截断上下文，可能遗漏关键材料。评测表中同时记录资源与质量，才能看出优化是否真的划算。

一次完整的离线评测，可以从定义目标开始。先写清楚模型的输入、输出、限制条件和成功标准，再构建一批具有代表性的样本。样本要包含正常情况、边界情况、容易混淆的情况和资料不足的情况，并记录每条样本的参考答案或评分规则。

接着统一模型的提示词、采样参数和上下文设置，先用自动指标批量跑出结果，再进行人工抽样复核。自动指标适合处理数量和格式，人工复核适合识别语义错误、表达问题和隐性偏见。两者结合，比单纯让模型互相打分更稳妥。

评测结束后，应该保存原始输出、模型版本、参数、时间和环境信息。这样在更换模型、修改提示词或加入检索后，才能知道变化来自哪里。失败样本也不应被删除，它们往往是下一轮评测集最有价值的部分。

离线评测能帮助我们做选择，但不能覆盖所有真实输入。上线后还要持续观察请求量、回答质量、延迟、吞吐、成本、安全事件和失败样本。对知识库系统来说，检索是否命中、上下文是否正确拼接也应该单独监控，否则模型回答变差时很难判断问题出在检索还是生成。

线上数据不能未经处理就全部拿来训练或评测。需要注意隐私、权限和敏感信息，先做脱敏和访问控制，再从中筛选具有代表性的失败样本。样本回流后，更新评测集，重新跑离线测试，形成‘发现问题、分析原因、调整方案、再次验证’的循环。

监控指标的作用不是做一个漂亮的仪表盘，而是尽快发现变化。模型升级、提示词修改、知识库更新、流量突增和硬件变更，都可能让原本稳定的结果发生波动。只要保留版本和关键样本，团队就能更快定位问题并决定是否回滚。

如果是信息抽取，优先关注字段准确率、召回率、格式通过率和缺失字段处理；如果是知识库问答，重点看检索命中、事实一致性、引用质量和拒答恰当率；如果是客服助手，还要加入语气、问题解决率、转人工率和安全事件；如果是实时应用，则必须把延迟、吞吐和超时率放进核心指标。

指标不需要一开始就全部纳入。可以先选出三到五个最能反映成功标准的指标，再增加安全、成本和性能指标，避免评测表过于复杂，最后却没有人维护。关键是每个指标都要能对应一个决策：是否上线、是否换模型、是否修改提示词，或者是否需要人工介入。

大模型评估没有一张适用于所有项目的标准答案。好的评估体系应该随着任务和系统变化而调整，但每次调整都要保留原因、版本和结果。这样得到的不是一次性的排名，而是一套能帮助团队持续改进的工作方法。