# 用任务评测比较 LLM

## 本文提供什么

这是一套评测方法，不是实测榜单，不宣称任何模型胜出。先从实时目录选择候选公开路由，确认协议与必要能力，再为生成实验设定已获批准的预算。

比较应从真实工作负载开始：信息抽取、客服回复、代码修改和长文档分析的验收标准不同。公开榜单不能代替使用有授权、具代表性数据进行的任务测试。

## 建立小而可复核的数据集

收集实际要解决的任务样本，删除敏感信息并记录使用权限。覆盖常见输入、困难边界、模糊请求，以及应该拒绝或转交人工的情况。将保留测试集与提示词开发集分开，避免反复调参使测试集变成训练素材。

在查看回答前制定评分规则。信息抽取应分别评估必填字段正确率和格式错误；客服回复应检查事实依据与业务规则；代码任务应运行适用测试，并审核是否改动了无关行为。表达流畅不代表任务成功。

## 让运行条件可比较

| 记录项 | 作用 |
| --- | --- |
| 公开 ID、协议、日期与声明能力 | 模型命名和可用性可能变化 |
| 提示词版本、数据集版本和输出上限 | 避免隐藏的输入差异 |
| SDK 版本、重试策略、并发和超时 | 客户端行为会影响观测结果 |
| 首段文本时间与总耗时 | 流式响应感受与完成速度不同 |
| 原生用量、账号价格依据与最终扣费 | 仅 Token 数不足以证明总成本 |
| 完成、失败、截断或中断状态 | 失败不能从统计分母中消失 |

应比较等价任务，而不是跨协议照抄不支持的参数。可以统一的设置保持一致，不能统一的差异明确披露。重复部分样本以了解波动，不要把小样本写成精确的总体结论。

## 评分与决策

条件允许时，让人工评审不知道模型身份。先记录通过率和评分，再查看费用。模型裁判评分应与人工及确定性检查分开，裁判可能与候选模型具有相似偏差。

报告应包含样本量、失败尝试、评测日期、配置和不确定性。比较每个通过验收任务的成本，而不只是每个返回答案的成本。质量与延迟各有优势时说明取舍，不宣称通用冠军。

部署决策应从有限试运行和明确回滚条件开始。本文不会替你切流或执行评测。继续阅读[协议迁移](/zh/docs/llm/protocols)、[费用与用量](/zh/docs/llm/cost-and-usage)和[错误排查](/zh/docs/llm/errors-and-retries)。