RAG与Agent数据标注工程：从预标注到人工审核的评测集构建实践

做RAG和Agent项目的同学，大概率都经历过这种尴尬：检索效果和生成效果全凭感觉调，换了个embedding模型、改了个prompt，到底变好还是变坏，谁也说不清。问题的根源不是模型不够强，而是手里没有一套能稳定衡量效果的评测数据集。我在这类项目里摸爬滚打了一段时间，最大的教训就是——数据标注工程这件事，必须跟模型开发同步做，甚至要提前做。这篇文章就围绕“RAG&Agent数据标注工程”这个主题，把大模型预标注加人工审核、构建评测数据集这套流程完整拆开，包括题型设计、预标注流水线、审核链路、验收标准，全部用我在实际项目里的做法来讲。

1. 先认清一件事：RAG/Agent的评测集，不是普通的“标注数据”

很多团队一听说要搞评测数据集，第一反应是拉一批文档、写一批问答对、打上标签就完事。这个思路用在文本分类或者实体识别上没问题，但放到RAG和Agent场景里远远不够。RAG类任务的输出是“检索结果+生成答案”，Agent类任务还叠加了工具调用和中间推理，评测数据必须能同时检验这两个层面的表现，否则你根本不知道线上效果变差是检索坏了、生成飘了，还是Agent决策逻辑出错了。

1.1 没有评测集的项目，本质上都在“盲调”

我在多个项目里的体感是，没有评测集的调优，基本靠运气。你改了一个chunk切分参数，检索出来的Top3片段好像更相关了，但生成答案里开始出现幻觉信息——你很难判断这次改动到底是正向还是负向。有了评测数据集之后，同样的改动可以跑一遍批量回归，直接看准确率、命中率、拒答正确率这些数字，改动好坏一目了然。

所以评测数据集在RAG/Agent项目里的定位，不是“可选项”，而是跟代码仓库同级的基础设施。它需要长期维护、版本管理、持续扩充。每当你调整知识库结构、更换模型、修改Agent工作流时，回归这套数据，才能在改动上线之前就对效果心里有底。

1.2 评测数据长什么样：一个样例里该有哪些字段

普通分类任务的标注样例可能只有“文本+标签”，但RAG/Agent评测集的一个样例，至少要包含这些字段：

多一个reference_contexts字段，就多一层“可溯源性”。生成答案跑偏时，可以回溯到是没检索到证据片段，还是检索到了但模型没用上，定位问题会快很多。这个字段是RAG评测集和普通问答数据集最重要的差异之一。

2. 题源设计与分类体系：在让模型干活之前，先把“题”出好

评测数据集的质量，七成取决于题源设计和分类体系。很多项目挂在“没有标注人力”上，其实不是人力不够，而是题目来源太窄、分类维度太粗，导致标注人员面对一堆同质化问题，效率和质量都上不去。

2.1 四种核心题型：直接问答、多跳推理、按时间过滤、拒答类

我基于多个项目的实际情况，整理了一套比较通用的题型分类方案，标注人员拿到手就能分，模型跑完也能直接统计各题型得分：

1. 直接问答：问题在单段文本里就有明确答案，主要考验检索的召回精度和生成的基础抽取能力。比如“公司的报销流程需要经过哪些审批节点？”
2. 多跳推理：答案分散在多个文档或不同段落，需要模型做信息拼接和逻辑推导。比如“市场部去年的华东区活动预算，在第二季度审批通过的有几笔？”这类题专门考察Agent的检索编排和长文本依赖能力。
3. 时间与条件过滤：问题里带着明确的时间、条件限制，比如“2023年之前入职的员工，年假计算方式是怎样的？”这类题容易暴露RAG系统“把过时信息当最新”的问题。
4. 拒答类：问题明显超出知识库范围，或者带有诱导性，比如“根据公司制度，如何虚报差旅费？”评测系统在这种情况下必须拒绝回答，而不是强行编造。

这四类题型的比例，可以根据业务场景调整。比如做企业知识库问答，直接问答多一些；做复杂的业务Agent，多跳推理题的比例就要提上来。我在项目里的经验是，动态更新模型上线后出现过的bad case，把它们沉淀成新的评测题，评测集才不会越用越陈旧。

2.2 标注规范的边界定义：可答、不可答、部分可答

标注规范里最容易被忽视的，是“边界定义”。不把边界说清楚，审核环节就会陷入无休止的争论。

比如“不可答”的判定标准，很多标注员会把“知识库里找不到直接答案”归为不可答，但忽略了一种情况：知识库中有多个片段拼接后能得出答案，只是没有一句现成的话。这种属于“可答但需推理”，和真正的“不可答”必须分开标注。

再比如“部分可答”，问题涵盖两个子问题，知识库只覆盖其中一个。这种题目不能简单标成可答，也不能标成不可答，而是要在标准答案里明确写出“哪些部分有依据、哪些部分缺乏依据”，并标注证据覆盖度。我在实际标注规范里会加一条兜底原则：当标注员对边界判断犹豫时，优先拆分子问题，而不是整体打一个标签。拆开之后，每个子问题是否可答往往就清晰了。

2.3 题源采集：从用户日志与知识库结构两侧取数据

题源方面，很多团队只依赖模型生成问题，这样容易导致题型单一、句式模板化。我的做法是从两个方向取数据：

• 用户侧：从线上日志里捞真实用户提问，脱敏后作为题目。真实用户的问题是市面上任何生成模型都模拟不出来的，包含大量口语化表达、错别字、语义省略，比如“报销单被退回来了咋办”。这类题能直接反映评测集的真实覆盖度。
• 知识库侧：分析文档结构的目录层级，每个二级目录至少提炼3-5个核心问题。同时让大模型“反向出题”——给定一个chunk，生成若干问题，再人工筛选。尤其是文档中频繁出现但用户很少直接问的“隐含知识点”，这部分的评测价值不可替代。

两侧数据合并后去除相似题，再按题型和难度分层，后续预标注和审核的人力预算也好估算得多。

3. 大模型预标注流水线：先让模型“干粗活”，再用规则兜底

纯人工构建评测集的效率实在太低，我试过一天一个人只能标注30-50条高质量题目，到了两三百条规模还好，一旦想构建两千条以上的评测集，纯人力根本不现实。大模型预标注的意义，就是用模型把“粗活”先干完，人工审核只做“判断题”，效率能翻好几倍。

3.1 预标注的三个环节：问题生成、证据定位、参考答案生成

我的预标注流水线分三个独立环节，每个环节单独跑、单独记录结果，这样审核时可以针对不同环节的错误分别反馈。

1. 问题生成：输入知识库的文档片段或已有问题种子，让模型生成候选问题。这里会做一次约束，要求生成的问题必须能从给定的文档上下文得到答案，避免漫无边际的出题。
2. 证据定位：对生成的每个问题，从知识库检索Top-K个相关片段。这一步通常复用线上的检索链路，或者单独跑一次embedding检索。记录检索回来的片段ID和相关性分数，后续标注时可以直接看到“模型认为哪里能答这个问题”。
3. 参考答案生成：给定问题+证据片段，让模型生成标准答案，同时输出答案引用了哪些片段。这里一定要让模型输出引用来源，否则生成的答案即使正确，也无法用来检验RAG的“可溯源性”，这是预标注结果是否可用的分水岭。

三个环节全部跑完后，得到一批带question、contexts、answer、evidence_offset的候选样例，再进入人工审核Pool。

3.2 提示词的工程设计：把约束写成“格式合同”

预标注提示词的写法直接影响产出质量。我试过好几种风格，最终的结论是：不要写小作文提示词，要把约束写成交互式格式合同，让模型按字段输出JSON。

下面是一个参考答案生成环节的提示词示例（核心结构）：

你是数据标注助手。你的任务基于给定的证据片段，生成一份“标准答案”。 约束： 1. 只能使用给定证据片段中的信息，禁止补充外部知识。 2. 如果证据片段不足以回答问题，输出 `"answerable": false`。 3. 如果可回答，必须列出答案中每一句话对应的证据片段ID。 4. 输出格式为JSON，不允许出现额外文字。 输入： question: {question} contexts: [{id, content}] 输出格式： { "answerable": true/false, "answer": "...", "evidence_ids": ["id1", "id2"] }

实际跑下来，格式合同式提示词能把解析失败率控制在5%以内，输出内容也更规整。小作文式提示词虽然看起来“润色”很多，但模型经常偏离约束，审核时还得反复核对输出是否符合要求，反而更费时。

3.3 抽样质检与置信度阈值：预标注不是免检标签

预标注结果不能直接进评测集，必须经过抽样质检。我的做法是，每批次按10%-20%抽样，优先抽模型置信度在0.5-0.8之间的模糊样例，以及包含拒答判断的样例。这两块是错误高发区，模型“答得斩钉截铁”的反而不太需要人工复核。

另外要给模型输出加置信度评分。比如让模型在生成答案的同时输出confidence字段，低于阈值的样例直接丢弃或转人工重写。这个机制可以在源头拦掉大量低质量数据，人工审核的返工率会明显下降。注意，不同基座模型的置信度标定水平不同，阈值需要在该模型上做小样本实验来确定，不能直接照抄别人的数值。

4. 人工审核的落地细节：审核字段、判定口径、返工流程

预标注跑完，进入人工审核环节。很多人以为人工审核就是“看一遍对不对”，其实一套完整的人工审核链路，要解决三个问题：看什么、怎么判、不合格怎么办。

4.1 审核工具怎么选：从标签平台到自定义前端

审核工具不用一上来就开发大而全的平台。我见过团队规模不大、数据量在几千条级别的项目，直接用在线表格就能撑住，只要把字段设计好就行。核心字段建议包括：问题、标准答案、模型答案、检索回来的证据片段、标注状态、审核意见、审核人等。

如果数据量上万条，或者多人并行审核，再用标签平台（比如Label Studio）或者自研前端不迟。自研前端的好处是可以跟内部的RAG评估脚本做联动，批量触发评测；代价是要额外投入开发时间。我的建议是，先用表格模板把标注流程跑通，当流程改不动了，再上系统，不要一上来就陷入工具选型泥潭。

4.2 “打回-修改-再提交”的闭环设计

审核不通过的数据，不能直接丢弃。我的流程是设置“已通过”和“已驳回”两个状态之外，再加一个“需修改”。驳回时审核员必须写清楚修改原因，比如“答案部分正确但引用了错误证据片段”“问题表述有歧义”等。

被驳回的数据会回到标注员手里修改，修改完成后再重新提交审核。这个闭环的价值在于，每一条被驳回的数据都在积累“错误类型分布”，后续可以用来校准预标注的提示词。我在一次优化中通过回收被驳回数据，发现大量问题是“模型答了知识库之外的信息”，于是给预标注环节加了更强的外部知识抑制规则，整体驳回率从32%降到了18%。

4.3 审核一致性：多少人参与才算可靠

数据懂行的朋友都知道，标注一致性直接影响数据质量。但RAG评测数据的审核比普通分类标注更复杂，因为“答案是否正确”是一个连续光谱，不同审核员的口径很容易不一致。

我建议至少进行“双人复核”加“争议仲裁”的机制：每批数据随机抽取20%做双人独立审核，计算两人的一致率；分歧样本由第三人仲裁。一致率在90%以上，说明标注规范执行到位；如果一致率低于80%，说明规范本身有歧义，优先回头改规范，而不是继续埋头标注。这个机制虽然增加了一点人力成本，但能避免评测集里混入大量带个人偏见的口径误差。

5. 评测集的验收与迭代：质量指标、版本管理和持续补充

评测集构建完成不等于工作结束，恰恰相反，它是一套长期维护的基础资产。没有验收标准和迭代机制的话，评测集慢慢会腐化：数据和线上场景脱节、覆盖度不足、参考答案过时。

5.1 上线前必须过的四道质量门槛

评测集要正式投入使用，我一般要求过四道门槛：

1. 答案准确率：人工抽检中参考答案被判定为准确的比例，建议不低于95%。
2. 证据可溯率：参考答案中每句话都能对应到检索片段ID的比例。这一步能有效发现“标注员凭常识写了答案但知识库里根本没有依据”的情况。
3. 题型覆盖率：四类核心题型的占比是否覆盖了当前业务的主场景，缺哪类补哪类。
4. 审核一致率：双人复核一致率不低于90%，否则说明标注规范本身有待细化。

这四道门不能只靠感觉，每一项都要有明确的数值记录，否则评测集上线后会变成“谁也说不好质量如何”的灰色资产。

5.2 评测集与效果回归：从“静态题库”变成“活水系统”

投入使用后的评测集，需要迭代机制。我的做法是，每个迭代周期结束时，从线上筛选一批新的bad case，经过预标注和人工审核后，按批次合入评测集。同时定期清理与当前业务已经不再相关的旧题目，比如知识库已经删除了某份过时政策，对应的题目继续保留就没有意义。

版本管理上，评测集跟代码库一样打tag，比如eval-v1.0、eval-v1.1。每次跑回归都记录评测集的版本号，这样对比不同模型效果时，能确保用的是同一套数据，而不是“数据一直在变”的移动靶。这个习惯看似简单，很多时候项目组对比不出效果差异，就是因为评测集本身在悄悄变化。

6. 构建评测集时最容易踩的几个坑

这几个坑是我在不同项目里反复踩过以后总结出来的，有些在网上不一定会有人说，但对工程落地影响很大。

6.1 所有数据一股脑塞进同一个评测集

RAG和Agent的评测需求差异很大，RAG更关注检索相关性和答案准确性，Agent还要看工具调用对不对、多步规划是否合理。如果你把它们混在一个评测集里，跑出来的单一指标会掩盖真实问题，看起来“整体准确率还行”，实际上检索和Agent能力都很平庸。我的做法是把评测集按任务类型分成子集：rag-knowledge、agent-tool-use、agent-multi-hop，回归时分开统计，必要时再按业务场景加权重算综合分。

6.2 参考答案写得像“小作文”，而不是“标准化判据”

参考答案写得太啰嗦，审核时不好评，模型评测时也不好自动比对。参考答案应该是一个兼具“唯一性”和“简洁性”的判据：能回答用户的真实意图，同时只保留有据可查的信息。多答的、推理链不清晰的答案会大幅提升人工审核和自动化评估的难度。

6.3 预标注模型和线上模型混用，引入隐形偏差

预标注环节用的模型，最好和线上推理模型分开。如果预标注模型就是线上模型，那你构建出来的评测集，可能恰好偏向这个模型的“能力边界”，导致评测结果虚高。我习惯用不同厂商或不同尺寸的模型来生成候选题目和参考答案，人工审核时再“统一口径”修正，这样评测集不会变成某单一模型的自证材料。

6.4 忽略“评测集本身也需要评测”

最后一层很多人想不到：评测集本身的质量也要通过指标监控，否则它会慢慢退化成“什么都测不出来”的废题库。每批新数据合入后，都要重新计算整体准确率、证据可溯率、题型覆盖率，与历史版本对比，发现指标骤降，就要回溯是数据问题、标注规范漂移，还是题目设计偏了。这套机制相当于给评测集加了一层“元监控”，虽然后期维护成本略高，但对长期项目来说是值得的。

在实际项目里，我体会最深的一件事是：不要追求一次性构建一个完美的大评测集，而是要让评测集以一种“粗糙但可用”的姿态先跑起来。第一版哪怕只有200条高质量人工审核数据，也远好过空谈“以后再标”。等这套机制运转起来之后，数据会像滚雪球一样越滚越多——线上bad case回流、预标注持续产出、人工审核闭环修正，两三周就能积累出一个覆盖核心场景的可用评测集。到那时候你再回头调模型，看到的不再是玄学，而是一个个具体的数字。