在此页面上
简短的回答
有用的评估数据集记录每个案例的输入、相关上下文、预期行为、出处和失败类别。将授权的真实示例与仔细审查的合成案例相结合，并保留一组保留的调整不应影响的决策。
拿走什么
- 存储案例存在的原因，而不仅仅是其提示和答案。
- 综合示例扩大了覆盖范围，但需要独立验证。
- 保持数据集更改的版本化和可审查性。
已检查来源 .研究综合和 Rubrex 建议。示例和本地实验均已标记；它们不是客户结果。
最近的工作使数据集结构成为一种设计选择
HieraRAG 是 2026 年 6 月的预印本，研究了 RAG 基准中综合问题的粒度。它将粒度定义为在特定检索配置中评估的内容。这支持询问数据集暴露了哪些区别，而不是假设更多的问题会自动创建更好的基准。
评估数据和训练数据服务于不同的决策
训练示例有助于改变模型的行为。评估数据集根据参考证据或评分标准测试定义的行为。 Rubrex 建议将用于调整提示或模型的案例与保留的决策集分开。如果团队研究失败的测试并更改系统以通过它，则保留该案例作为回归检查，但使用新保留的案例来评估更改是否具有普遍性。
综合示例可以帮助涵盖异常输入、缺失证据或权限边界。在接受之前，根据源材料检查每个问题和预期结果。记录示例是如何创建的以及它代表的失败。大型训练语料库或自动生成的问答对的集合本身并不是经过验证的评估集。
在收集示例之前定义记录
Rubrex 建议使用不可变标识符、输入、允许的上下文、预期行为、源类别、收集日期和审阅者状态的案例记录。对于使用工具的工作流程，包括初始状态和授权的最终状态。对于开放式写作，请使用固定的标题，而不是要求一个精确的句子。
记录案例是否来自生产、支持升级、领域专家或合成生成。即使无法保留原始交互，也要保留其起源的公共安全描述。数据集不应该因为日志导出方便而悄悄获取敏感信息。
刻意建立覆盖范围
在编写提示之前将产品映射到有意义的部分。示例包括任务类型、文档年龄、输入长度、证据可用性、语言和用户权限。当产生不可能出现的组合时，避免使用完整的笛卡尔积。优先考虑与实际暴露或特定故障假设的组合。
对于合成案例，指定受到压力的行为，并使用单独的审核步骤验证输入是否合理且参考是否受支持。模型可以生成有缺陷的问题和匹配的有缺陷的答案。这两个工件之间的一致性不是独立验证。
| 场 | 目的 |
|---|---|
| case_id | 跨运行和修订的稳定身份 |
| expected_behavior | 可观察的要求，包括可接受的不确定性 |
| 出处 | 来源、使用许可和收集上下文 |
| slice_tags | 代表的任务和失败条件 |
| review_status | 谁或什么验证了引用以及是否仍然存在歧义 |
说明性示例：版本化策略问题
福利助理收到有关当前保单和存档保单的问题。为当前问题、明确的历史问题和没有日期的问题创建不同的案例。预期行为有所不同：使用当前规则、历史答案或澄清适用日期。在一个简单的例子中仅仅改变名称就会忽略这一区别。
将这些案例与政策版本联系起来，这样真正的政策更新就不会显得是模型回归。通过审查和解释消除无效的期望，而不是从数据集中删除困难的案例。
将数据集视为维护的产品工件
将开发集与决策集分开并记录对每个集的访问。通过轻量级审查队列添加新的失败案例。报告分数时，请确定数据集版本并解释重大更改。将上个月的一种任务组合的结果与本月另一种任务组合的结果进行比较可能会混淆流量变化与模型改进。
证据的局限性
数据集是构建的样本，而不是未来流量的完整模型。 HieraRAG 的发现涉及特定的研究设置。这里的记录设计和政策示例是 Rubrex 建议，而不是该研究的复制品。
常见问题
数据集可以完全合成吗？
它在早期设计期间可能很有用，但其真实性和覆盖范围需要验证。明确其合成来源，并将其与授权的真实用途（如果有）进行比较。
参考文献应该是准确答案吗？
对确切的任务使用准确的答案。对于开放式输出，定义所需的事实、不可接受的行为和可接受的变化。
来源和进一步阅读
本简报背后的主要来源。来源的研究结果适用于其自身的研究条件； arXiv 上的出版物不建立同行评审。
- RAG 基准应该有多细粒度？综合问题生成的分层框架 arXiv · 2026 · 预印本已审核： 摘要和出版记录.已访问 2026年9月25日.