> For the complete documentation index, see [llms.txt](https://doc.duaer.com/zh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.duaer.com/zh/guides/llm-evaluation-datasets-2027.md).

# LLM 评测数据集 2027：采购前先建立你自己的测试集

本文整理自 Duaer 文档站，围绕企业 AI 落地中的 LLM 评测数据集，说明为什么公开榜单不足以支撑选型决策，以及如何在采购前构建反映自身业务的测试集。

## 公开榜单与通用基准为什么不够用

大多数企业 AI 团队会参考公开基准分数来选择模型：模型在通用推理测试中排名靠前，于是进入试点。两个月后，试点团队却发现助手自信地引用了去年已经废止的退款政策，把两条名称相近的产品线混为一谈，还拒绝回答关于内部流程的合理问题。基准本身并没有错，它只是衡量了另一项工作。

这正是「LLM 评测数据集」这一概念要解决的核心痛点。模型的通用能力是一个问题，它能否处理你的文档、术语、用户和风险容忍度，则是另一个问题。如果没有反映自身业务的数据集，每一次模型对比都会变成对营销宣传的对比。对于同时依赖知识库的团队，问题更加突出，因为回答质量取决于检索效果、文档时效性和提示词设计，而不只是基础模型本身。

公开基准是为共享而设计的，题目干净、自包含、用语规范。真实的企业问题则不同：一线员工输入的可能是带内部缩写的半截句子；财务分析师问的数字可能只存在于某个表格页签里；法务人员需要答案精确引用某个特定日期生效的条款版本。

还存在数据污染的问题。公开数据集已经在网络上被大量复制、讨论，并被纳入训练语料。高分可能反映的是记忆能力，而不是对新材料进行推理的能力。对于采购决策来说，这种不确定性的代价很高。

务实的结论很简单：用公开基准过滤明显的短板，然后构建私有评测集来做真正的决策。

## 团队构建数据集时的常见错误

第一个错误是只收集顺利场景的问题。团队往往写下二三十个自认为助手应当答好的问题，跑完测试后就宣布系统可以上线。这类数据集从不包含含糊的请求、超出范围的问题，也不包含「我不知道」才是正确行为的场景。一个总是作答的模型在这样的数据集上会显得非常优秀。

第二个错误是在会议室里编题，而不是从真实场景中采集。项目经理虚构的问题往往整齐、规范。而来自客服工单、聊天记录和内部搜索词的问题则杂乱得多，也更能代表真实情况。

第三个错误是省略参考答案。如果没有明确的正确答案或支撑段落清单，评审人员只能凭感觉判断输出好坏。两个人读同一个回答，可能对「是否足够好」给出不同结论，团队也就没有稳定的方式来比较不同版本。

第四个错误是一次性建好数据集之后就不再更新。政策会调整，产品会改名，法规会修订。反映的是去年知识的测试集，会开始奖励错误的行为。

## 如何构建合适的数据集

从来源开始。最有价值的素材通常已经在企业内部：知识库的搜索日志、转交人工处理的工单、员工反复回答的常见问题，以及具有合规效力的文档。可以访谈两三位领域专家，问他们新员工最常犯哪些错误，这些答案往往能揭示最难的案例。

接下来要有意识地抽样，而不是随机抽样。可以按意图（查找、比较、流程、计算）、按难度（单文档还是多文档）、按风险（低风险信息还是涉及资金、合同或患者安全的决策）对问题分层。几百条分布均衡的问题，比从单一简单类别中抽取的几千条问题更有信息量。

然后为每个条目编写参考材料。对于基于检索的系统，记录应当支撑答案的一个或多个段落；对于生成类任务，写一个简短的标准答案和一份评分准则，明确必须包含什么、不能声称什么，以及在什么情况下拒答才是正确的。让两名评审人员对一部分题目独立标注，并统计他们的一致程度。如果分歧频繁，说明评分准则不清晰，需要先修订，然后才能对任何模型打分。

最后，把数据集的一部分拆出来作为保留集，在调整提示词或检索参数时不使用它。否则团队会逐渐针对测试集优化，而不是针对真实的业务问题优化。

## 评测流程中的敏感数据保护

评测数据集往往包含企业中最敏感的材料：客户留言、合同条款、员工记录。为了图方便把它们复制到外部工具中，会带来与其他数据流转相同的合规风险。应将数据集、参考答案和评分日志保留在受控环境内，只向被测系统发送必要的最少内容。如果测试不依赖个人身份信息，就对其进行脱敏处理。如果组织有数据驻留要求，也应同样适用于评测环境，而不仅仅是生产环境。

团队还需要决定谁可以查看哪些条目。涉及定价或法律解释的数据集可能需要限制访问权限，同时应培训评审人员：一旦在样本中发现真实客户记录，该怎么处理。

## 如何衡量真正重要的指标

单一的准确率数字隐藏了太多信息。应当把结果拆分到与业务相匹配的维度上。有用的指标包括：有据性（论断是否有引用来源支撑）、引用准确性（被引用的段落是否真的这样说）、正确拒答（当来源中没有答案时系统是否拒绝作答）、对冲突文档的处理、延迟以及每次查询的成本。应按类别报告结果，而不只报告总体数字。一个在常见问题上表现良好、却在风险最高的问题上失败的系统，不应仅凭平均分就获得批准。

应把评测当作回归测试套件来运行。每当模型、提示词、检索索引或分块策略发生变化，就用同一套题目重新跑一遍并进行对比。小的改动常常会产生意想不到的副作用，而回归视角是发现这些副作用的唯一可靠方式。为每次运行保留一份简单的日志，记录版本标识，以便日后审计时能够解释当初为何选择某个配置。

对于致力于控制幻觉的团队，数据集还可以包含刻意设计的无法回答的问题和带有误导性前提的问题。我们的指南 [如何在采购前测试幻觉率](https://doc.duaer.com/zh/guides/llm-hallucination-rate-evaluation/) 说明了如何解读这类结果，而不依赖供应商的汇总结论。

## 本周可以做什么，以及如何在 Duaer 上开始

先挑选一个高价值的工作流，例如某个部门的内部制度问答。从日志或工单中导出约一百条真实问题，去除个人数据，并将其归为五到六个类别。为每个问题写下预期答案或支撑该答案的来源段落，并标出那些正确响应应当是拒答的问题。请两位同事独立标注其中十条，并比较结果。这样，你就拥有了第一版真正反映自身业务、而不是排行榜的数据集。

数据集建立之后，把每个候选模型或检索方案都在它上面运行一遍，就会从一场争论变成一套可重复的常规流程。如果团队希望直接运行这一闭环，而不必自己搭建脚本和看板，可以试用 [Duaer](https://www.duaer.com)，它能把问题、参考材料和对比运行结果集中管理。它无法替代领域专家的判断，但能减少维护测试集和结果时的人工工作量。

## 在 Duaer 上开始建立你自己的评测集

如果你的团队即将在 2027 年选择模型或知识助手，请在签约之前先建立测试集。访问 [https://www.duaer.com](https://www.duaer.com) 注册，用你自己的问题和文档试用这套流程，并以你的业务真正关心的标准来评判结果。

通用基准能告诉你模型总体上擅长什么；只有来自你自己工作的数据集，才能告诉你它是否已经为你的公司做好准备。

## 常见问题

### 企业为什么不能只看公开基准来选择大模型？

公开基准衡量的是通用能力，题目通常干净、自包含，并且可能已被模型训练时见过。企业真实的问题则涉及内部术语、最新政策和特定文档，还需要模型在信息不足时正确拒答。只看公开分数，很难预测模型在自己业务中的表现。

### 构建内部评测集需要从哪里开始？

可以先选定一个高价值的工作流，例如某个部门的内部制度问答。从搜索日志、客服工单或常见问题中收集约一百条真实问题，去除个人信息，按类别分组，并为每题写出预期答案或支撑来源。随后请两位同事独立标注一部分题目，检验评分准则是否清晰。

### 评测集中为什么要包含应当拒答的问题？

如果数据集只包含系统能够回答的问题，一个总是给出答案的模型就会显得表现很好，但实际上可能会编造内容。加入来源中没有答案、前提有误或超出服务范围的问题，才能检验系统是否会在不确定时坦诚说明，这对降低企业的合规和决策风险非常关键。