GPT、Gemini 和其他 AI 模型的版本迭代很快,标题里同时出现旧年份和新型号,会让文章在发布后迅速失真。更可靠的做法不是选一个“年度王者”,而是用固定任务集、明确评分标准和完整运行记录,判断哪个产品在当前业务条件下更合适。
本页已移除旧版的笼统胜负结论,保留原 URL 以避免不必要的地址变更。以下框架适用于网页聊天产品和 API,但两者必须分开测试:网页产品可能自动选择模型或启用搜索等工具,API 则需要记录明确模型标识和参数。
一、模型对比前必须记录的环境
- 测试日期、国家/地区、语言和设备;
- 产品名称、界面显示的模型或模式标签、账号计划;
- 是否开启联网搜索、文件分析、代码执行、图片或深度研究;
- API 测试时的完整模型 ID、参数、系统/开发者指令和工具定义;
- 提示词版本、来源文件版本和任务集版本;
- 每个任务的多次原始输出、延迟、错误和成本记录。
如果某个产品没有显示底层模型,不要自行猜测;记录界面实际显示的产品或模式标签即可。
二、建立代表真实工作的任务集
至少覆盖以下几类,并为每类准备正确答案或人工审核标准:
- 事实约束:只根据一组一手资料回答,检查是否虚构来源和数字;
- 结构化输出:把相同文档转成固定字段,检查漏项和格式通过率;
- 长上下文:在多份资料中寻找矛盾、版本与限制条件;
- 多语言任务:保留专业术语、数字、单位和语气;
- 推理与计算:给出可由程序或标准答案验证的结果;
- 真实工作流:例如 SEO Brief、客服分类、产品对比或代码修改,并统计人工返工量。
不要只用谜题或公开排行榜代表企业任务。OpenAI 的评估指南也强调,测试应与实际使用分布一致,并结合清晰指标与人工判断。
三、一个可调整的评分表
| 维度 | 默认权重 | 验收方法 |
|---|---|---|
| 事实与功能正确性 | 35 | 与一手来源、标准答案或自动测试比较 |
| 指令遵循 | 25 | 检查格式、边界、禁止项和必须包含项 |
| 来源可追溯 | 15 | 逐条打开引用,确认支持对应结论 |
| 多次运行一致性 | 15 | 同题多次运行,记录关键结论波动 |
| 延迟、成本与人工修改 | 10 | 记录响应时间、费用和人工修正分钟数 |
这组权重只是示例,不是通用行业标准。医疗、法律或合规任务应提高事实和专业审核权重;创意任务可以提高多样性,但不能降低产品事实和安全底线。
四、减少评测偏差
- 使用相同输入和工具条件;条件不同就分组报告;
- 随机排列并隐藏产品名称,让审核人盲评;
- 控制输出长度,避免审核人天然偏好更长答案;
- 除数字评分外设置通过/失败门槛;重大事实错误可以直接判失败;
- 用两名以上审核人校准评分表,保存分歧;
- 模型更新、提示词变化或工具变化后重新运行回归测试。
五、怎样发布对比结论才不误导
结论必须带上任务集、日期、产品/模型标签、样本数和工具条件。例如:“在本次 40 个中文产品资料提取任务中,按预先定义的字段通过率比较,某方案表现更好;该结论不代表写作、编程或其他版本。”
不要使用“2026 永久第一”“全面碾压”“所有人都该换”等标题。产品能力、价格、限额和隐私政策可能变化,读者应打开官方文档确认当前信息。
官方资料入口
框架与链接核验日期:2026 年 7 月 24 日。本文没有执行并发布当前各模型的全量基准,因此不声称某一家在所有任务中获胜。

