> 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-dataset-generation.md).

# 2027年LLM评测数据集生成：为什么测试集会失效

本文整理自 Duaer 文档站，讨论企业在构建 LLM 评测数据集时常见的失效原因，包括如何从真实任务出发、如何控制生成与人工审核流程、如何设计评分标准，以及如何判断数据集本身是否可靠。

## 为什么这件事比看起来更难

大多数做 LLM 功能的团队都会遇到同样的情况：演示效果不错，管理层问系统到底有多好，却没有任何数字可以回答。常见的捷径是让工程师花一个下午随手输入几个问题，这样得到的测试集看起来合理，实际能说明的问题很少。LLM 评测数据集生成，就是把企业真实的文档、工单和业务流程转化为带有已知标准答案的问题，使每一次模型、提示词或检索的调整都能用同一把尺子衡量。到 2027 年，已经度过试点阶段的企业不能再把这件事当作可选项，但多数团队仍然是临时凑合着做。

评测集需要代表人们真正会问的问题，包括那些不规范的问题：表述含糊的、需要多步推理的，以及系统应当拒绝回答的。编写正确的参考答案需要领域知识，而这些知识掌握在忙于本职工作的专家手中。原始文档也在不断变化，上个季度更新的一条政策，可能让上个月的一半参考答案悄悄失效，而且往往没人察觉。

合成生成可以缓解数量不足的问题，但会带来质量问题。基于单个段落生成的问题往往过于简单，常常只是对原文句子的改写。模型在这样的测试集上可能得分很高，但用户如果提出的问题跨越三份文档，或使用的是销售团队的用语而非政策手册中的措辞，模型就会失败。分数上升了，但它所反映的信号反而变弱了。

## 常见错误

第一个错误是只使用团队自己编写的问题。工程师倾向于写出反映自己如何理解系统的问题，而不是客服人员或采购分析师实际表达需求的方式。

第二个错误是用同一个文本块同时生成问题和答案。这样答案就天然位于该文本块之内，测试无法检验检索能否跨文档找到正确材料，只是在测单段文字的阅读理解能力。

第三个错误是遗漏负样本。如果测试集中没有知识库无法回答的问题，就没有任何指标衡量系统是否能承认自己的不确定性。在实践中，很多线上事故正是从这里开始的。

第四个错误是只相信一个总体分数。单一数字掩盖了哪些类别在失败。第五个错误是在上线后冻结测试集。真实流量到来后，线上日志是新测试用例的最佳来源，如果测试集从不吸纳这些内容，就会逐渐偏离现实。

## 从真实任务出发，并可控地用 LLM 生成

一个可用的数据集应从三类来源开始：现有系统或人工流程中的查询日志、支持工单或内部请求，以及与实际工作者的简短访谈。按意图对这些输入进行聚类。目标是覆盖不同任务类型，而不是单纯追求数量。四十个精心挑选、覆盖真实意图类别的问题，比四百个彼此雷同的问题更有价值。

例如，一个为售后支持团队构建助手的团队，可以先按产品线对真实工单分类，再按问题类型细分：安装、计费、保修和政策例外。每个类别都应包含若干条目。政策例外需要额外重视，因为错误答案在这里造成的损害最大。

如果底层知识库仍不稳定，应先解决这个问题。评测中出现的许多准确性问题，都可以追溯到分块、元数据和文档版本管理。我们关于[企业 RAG 知识库为何在 2027 年仍然回答不准确](https://doc.duaer.com/zh/guides/enterprise-rag-knowledge-base-build/)的指南更详细地讨论了这些上游原因。

LLM 可以用来扩大出题规模，前提是流程必须明确。一个可行的顺序是：按真实流量中该主题出现的频率加权，抽取文档片段；生成指定类型的问题，例如事实查找、比较、操作流程或不可回答类；生成引用支撑原文片段的候选答案；然后进行过滤。过滤应去除近似重复的问题、答案实际上不需要所引用片段即可得出的问题，以及对基线模型来说过于简单的条目。

生成与评判应使用不同的提示词，最好使用不同的模型。模型往往偏好自己的措辞，这会抬高分数。每个条目都应保存元数据：来源文档、文档版本、问题类型、难度标签，以及批准该条目的审核人。没有这些信息，之后就无法解释分数为何发生变化。

## 用评分标准进行核验与标注

生成的条目需要人工审核，至少在项目初期如此。试点阶段应审核每一条，待流程稳定后再改为随机抽检。评分标准应检查四个方面：参考答案是否正确，是否有引用的原文依据，是否完整，以及当原文中没有答案时拒答是否恰当。

要衡量审核人之间的一致性。如果两位专家经常对同一条目产生分歧，问题通常出在评分标准过于模糊，而不是人的问题。此时应收紧定义，补充边界案例的示例，并重新审核有争议的条目。建立在模糊标准之上的数据集，会产生看起来很精确、实际上毫无意义的分数。

一旦有了标注好的数据集和评分标准，循环就可以重复进行：抽样、生成、审核、打分，并将失败案例反馈回数据集。Duaer 是团队可以在自有知识库上搭建此类流程的一个平台，并能针对每个版本重新运行同一套问题，而不必每次从头重建。它的价值取决于评分标准和抽样设计的质量，因此上述人工环节仍然优先。

## 如何判断数据集本身是否合格

数据集本身也需要被评估。可以检查四件事。第一是覆盖度：将问题类型的分布与真实线上流量进行对比，标记过度或不足代表的类别。第二是区分度：运行一个刻意设计的弱基线和一个更强的配置。如果两者得分都超过 90%，说明测试集太容易，无法指导决策。第三是失败分析：按类别和来源文档拆解错误。某个政策领域内集中出现的失败，比总体下降几个百分点更具可操作性。第四是稳定性：多次重跑同一系统并观察方差。如果在配置未变的情况下分数大幅波动，说明测试集或评分方法需要改进。

如果你还需要了解系统编造事实的频率，可以为本数据集配套一项专门的检测。我们关于[在信任供应商数据之前如何验证 LLM 幻觉率](https://doc.duaer.com/zh/guides/llm-hallucination-rate-evaluation/)的文章，说明了如何设计这类测试，使其不会简单地奖励那些回答得很自信的系统。

## 本周可以做什么

选择一个已有明确负责人的工作流程。从过去一个月的日志或工单中抽取五十个真实问题。请一位领域专家为每个问题编写参考答案并注明来源，同时至少标出十条根据现有文档无法回答的问题。用当前系统运行这套测试，并按类别记录结果。暂时不要急于修复任何问题。第一次基线的意义在于：它告诉你系统的真实水平，并为之后的每一次改动提供一个固定的参照。

如果你希望在不自行编写脚本的情况下运行这一循环，可以访问 https://www.duaer.com 注册试用，先在自己文档的一小部分上测试这套流程。从小处开始，依据评分标准检查结果，只有当数字与专家的判断一致时，再逐步扩大范围。

一个好的评测数据集不是生成问题的堆砌，而是一个小而精、有标注、有代表性的数据集，它反映员工真正在做的工作，并随着这些工作的变化而保持更新。

## 常见问题

### 没有大量专家时间，如何快速搭建 LLM 评测集？

可以先从五十个真实问题开始，由一位领域专家为每个问题编写参考答案、注明来源，并标出至少十条无法从现有文档回答的问题。先完成第一次基线测试，再逐步扩充，不必一开始就追求数量。

### LLM 生成的问题可以直接用于评测吗？

不建议直接使用。生成的问题需要经过去重、过滤以及人工审核，确认参考答案正确、有原文依据，并且拒答判断恰当。生成与评判最好使用不同的提示词，甚至不同的模型，以减少评分偏差。

### 评测集多久需要更新一次？

只要知识库文档或真实业务问题发生变化，评测集就应随之更新。线上日志是新增测试用例的最佳来源，同时要记录每个条目的文档版本，以便在政策更新后及时发现失效的参考答案。