RAG 评估集怎么从真实问题里整理出来

先说结论。

RAG 评估集不应该由开发者在上线前临时编题。更可靠的做法，是从客服工单、内部搜索、业务群和人工访谈中取得真实问题，再补来源、期望证据、风险和失败分类。

这篇文章给一条完整样本，展示它怎样从原始提问进入回归测试。

先定义哪些来源可以进入评估集

优先使用已经发生的业务问题：客服工单、帮助中心搜索词、内部问答、培训记录、历史邮件和人工转交记录。

采集前要确定脱敏规则和使用权限。客户姓名、联系方式、订单号等字段应删除或替换；不能用于测试的数据不要因为“只在内部”就默认可用。

原始问题不要立刻改写成标准问法

假设内部群里出现一条问题：“出差回来票丢了还能报吗？”

原始记录应保留问题文本、来源渠道、发生时间、提问角色和当时上下文。不要先改成“差旅票据遗失报销政策”，否则会丢掉真实用户的口语表达。

同时删除无关个人信息，并为样本分配稳定 ID，例如 travel-expense-001。

去重时保留有价值的不同问法

“票丢了能报吗”“没有发票怎么走报销”“电子票找不到怎么办”可能指向相近政策，也可能包含不同票据类型。

去重不是只保留一句最规范的话。应先判断它们是否期望同一证据、是否有不同条件；证据相同可以归为一组，条件不同则保留为独立样本。

标准答案必须回到有效文档

内容负责人需要找到当前有效的差旅制度，标记支持答案的章节，并写出关键结论与必要条件。若文档没有明确处理遗失票据，这个问题不能凭常识补答案。

此时样本的期望行为可以是“说明资料不足并转财务确认”，而不是生成一个看似合理的报销流程。评估集也在反向暴露知识缺口。

给样本补风险与评分规则

这条问题涉及费用处理，可以标记为需要引用、不得编造例外、条件缺失时需追问。评分拆成：

• 是否召回当前有效制度；
• 引用是否支持结论；
• 是否保留票据类型等关键条件；
• 是否虚构补救办法；
• 资料不足时是否正确转人工。

不要只写一个“正确答案”，否则评审者会因措辞差异给出不一致结论。

从一次评测进入失败归因

运行系统后，可能出现三类结果：

1. 没召回制度：检查切片、关键词、权限和索引状态。
2. 召回正确但结论遗漏条件：检查提示、上下文和回答约束。
3. 文档本身没有规则：交给内容所有者补充，不归因于模型。

每次失败都保存请求版本、候选证据、回答、评审理由和责任分类。只有这样，修复才有明确对象。

修复后怎样成为回归用例

当对应问题被修复，不要从评估集删除。把样本加入固定回归集合，并记录首次失败原因、修复版本和再次通过的证据。

后续文档更新、切片变化、检索配置调整或模型替换时，重新运行这条样本。回归的目标不是保证永远通过，而是及时发现旧能力被新变更破坏。

一份可直接使用的字段模板

| 字段 | 示例含义 | | --- | --- | | sample_id | 稳定样本编号 | | raw_question | 脱敏后的原始问法 | | source_channel | 工单、搜索、访谈等 | | category | 业务分类 | | expected_evidence | 当前有效文档与位置 | | key_points | 回答必须覆盖的条件 | | unacceptable_output | 禁止编造或越权内容 | | risk_level | 业务自定义风险级别 | | must_cite | 是否必须引用 | | owner | 内容评审人 | | failure_type | 资料、召回、排序、生成、权限 | | dataset_version | 所属评估集版本 |

字段可以按项目缩减，但原始问法、证据、评审规则和版本不应缺失。

没有真实问题时的替代方案

新项目可能还没有日志。可以让一线人员回忆近期实际查询，或基于真实流程做访谈采集，并明确标记来源为“人工采集”。

也可以从文档章节生成覆盖问题作为冷启动，但这些只能叫合成样本。它们适合检查基础覆盖，不能代表真实问法分布，也不能替代上线后的问题回流。

限制与常见误区

日志多不等于样本好。高频简单问题可能淹没低频高风险问题；用户原始回答也不一定正确，仍要由内容所有者确认。

不要把个人隐私直接复制进评估集，不要让同一批样本既用于反复调参又当最终验收，也不要用单一平均分隐藏权限泄露或高风险误答。

下一步从一条样本开始

先选一条最近真实发生的问题，完成脱敏、去重判断、证据标注、风险规则、首次运行和失败归因。跑通这条链后，再批量整理其他问题。

评估集的价值不在表格有多少行，而在每一行都能把用户问题、有效知识、系统结果和修复责任连起来。

适合谁，以及什么时候换一种办法

这套方法适合已经有客服工单、站内搜索、内部问答或用户访谈记录的 RAG 团队，尤其适合需要持续回归和明确内容责任人的项目。尚未接触真实用户、文档也在频繁重写的原型，不必先追求大评估集；它的最低开始是一条脱敏问题、一份有效证据、一条不可接受输出和一次人工评审。

它的优势是样本能连接真实失败与修复，限制是历史问题会带入既有用户分布和处理偏差，不能代表所有未来场景。没有真实日志时，可用业务人员访谈与合成覆盖题冷启动；涉及高风险规则时，还应增加专家编写的边界样本。我的建议是把真实问题集、合成覆盖集和固定验收集分开管理，不用一个平均分掩盖三者用途差异。

它解决的核心问题，是每次失败能不能回到资料、检索、生成或权限的具体环节。最小开始是一条已经脱敏的真实问题，为它标注当前有效证据、不可接受输出和一位业务评审人，再跑一次完整归因。