做RAG和Agent项目的同学大概率都经历过这种尴尬检索效果和生成效果全凭感觉调换了个embedding模型、改了个prompt到底变好还是变坏谁也说不清。问题的根源不是模型不够强而是手里没有一套能稳定衡量效果的评测数据集。我在这类项目里摸爬滚打了一段时间最大的教训就是——数据标注工程这件事必须跟模型开发同步做甚至要提前做。这篇文章就围绕“RAGAgent数据标注工程”这个主题把大模型预标注加人工审核、构建评测数据集这套流程完整拆开包括题型设计、预标注流水线、审核链路、验收标准全部用我在实际项目里的做法来讲。1. 先认清一件事RAG/Agent的评测集不是普通的“标注数据”很多团队一听说要搞评测数据集第一反应是拉一批文档、写一批问答对、打上标签就完事。这个思路用在文本分类或者实体识别上没问题但放到RAG和Agent场景里远远不够。RAG类任务的输出是“检索结果生成答案”Agent类任务还叠加了工具调用和中间推理评测数据必须能同时检验这两个层面的表现否则你根本不知道线上效果变差是检索坏了、生成飘了还是Agent决策逻辑出错了。1.1 没有评测集的项目本质上都在“盲调”我在多个项目里的体感是没有评测集的调优基本靠运气。你改了一个chunk切分参数检索出来的Top3片段好像更相关了但生成答案里开始出现幻觉信息——你很难判断这次改动到底是正向还是负向。有了评测数据集之后同样的改动可以跑一遍批量回归直接看准确率、命中率、拒答正确率这些数字改动好坏一目了然。所以评测数据集在RAG/Agent项目里的定位不是“可选项”而是跟代码仓库同级的基础设施。它需要长期维护、版本管理、持续扩充。每当你调整知识库结构、更换模型、修改Agent工作流时回归这套数据才能在改动上线之前就对效果心里有底。1.2 评测数据长什么样一个样例里该有哪些字段普通分类任务的标注样例可能只有“文本标签”但RAG/Agent评测集的一个样例至少要包含这些字段字段作用举例question输入的问题“公司年假政策里入职满一年能休几天”reference_contexts标准答案对应的证据片段IDdoc-341,chunk-2210reference_answer人工确认过的标准答案“入职满一年员工可享受每年5天年假。”difficulty题目难度easy / medium / hardquery_type题型分类单跳问答 / 多跳推理 / 表格查询 / 拒答类requires_tool是否需要工具调用是 / 否source题目来源用户日志 / 知识库反推 / 模型生成status标注状态待审核 / 已通过 / 已驳回多一个reference_contexts字段就多一层“可溯源性”。生成答案跑偏时可以回溯到是没检索到证据片段还是检索到了但模型没用上定位问题会快很多。这个字段是RAG评测集和普通问答数据集最重要的差异之一。2. 题源设计与分类体系在让模型干活之前先把“题”出好评测数据集的质量七成取决于题源设计和分类体系。很多项目挂在“没有标注人力”上其实不是人力不够而是题目来源太窄、分类维度太粗导致标注人员面对一堆同质化问题效率和质量都上不去。2.1 四种核心题型直接问答、多跳推理、按时间过滤、拒答类我基于多个项目的实际情况整理了一套比较通用的题型分类方案标注人员拿到手就能分模型跑完也能直接统计各题型得分直接问答问题在单段文本里就有明确答案主要考验检索的召回精度和生成的基础抽取能力。比如“公司的报销流程需要经过哪些审批节点”多跳推理答案分散在多个文档或不同段落需要模型做信息拼接和逻辑推导。比如“市场部去年的华东区活动预算在第二季度审批通过的有几笔”这类题专门考察Agent的检索编排和长文本依赖能力。时间与条件过滤问题里带着明确的时间、条件限制比如“2023年之前入职的员工年假计算方式是怎样的”这类题容易暴露RAG系统“把过时信息当最新”的问题。拒答类问题明显超出知识库范围或者带有诱导性比如“根据公司制度如何虚报差旅费”评测系统在这种情况下必须拒绝回答而不是强行编造。这四类题型的比例可以根据业务场景调整。比如做企业知识库问答直接问答多一些做复杂的业务Agent多跳推理题的比例就要提上来。我在项目里的经验是动态更新模型上线后出现过的bad case把它们沉淀成新的评测题评测集才不会越用越陈旧。2.2 标注规范的边界定义可答、不可答、部分可答标注规范里最容易被忽视的是“边界定义”。不把边界说清楚审核环节就会陷入无休止的争论。比如“不可答”的判定标准很多标注员会把“知识库里找不到直接答案”归为不可答但忽略了一种情况知识库中有多个片段拼接后能得出答案只是没有一句现成的话。这种属于“可答但需推理”和真正的“不可答”必须分开标注。再比如“部分可答”问题涵盖两个子问题知识库只覆盖其中一个。这种题目不能简单标成可答也不能标成不可答而是要在标准答案里明确写出“哪些部分有依据、哪些部分缺乏依据”并标注证据覆盖度。我在实际标注规范里会加一条兜底原则当标注员对边界判断犹豫时优先拆分子问题而不是整体打一个标签。拆开之后每个子问题是否可答往往就清晰了。2.3 题源采集从用户日志与知识库结构两侧取数据题源方面很多团队只依赖模型生成问题这样容易导致题型单一、句式模板化。我的做法是从两个方向取数据用户侧从线上日志里捞真实用户提问脱敏后作为题目。真实用户的问题是市面上任何生成模型都模拟不出来的包含大量口语化表达、错别字、语义省略比如“报销单被退回来了咋办”。这类题能直接反映评测集的真实覆盖度。知识库侧分析文档结构的目录层级每个二级目录至少提炼3-5个核心问题。同时让大模型“反向出题”——给定一个chunk生成若干问题再人工筛选。尤其是文档中频繁出现但用户很少直接问的“隐含知识点”这部分的评测价值不可替代。两侧数据合并后去除相似题再按题型和难度分层后续预标注和审核的人力预算也好估算得多。3. 大模型预标注流水线先让模型“干粗活”再用规则兜底纯人工构建评测集的效率实在太低我试过一天一个人只能标注30-50条高质量题目到了两三百条规模还好一旦想构建两千条以上的评测集纯人力根本不现实。大模型预标注的意义就是用模型把“粗活”先干完人工审核只做“判断题”效率能翻好几倍。3.1 预标注的三个环节问题生成、证据定位、参考答案生成我的预标注流水线分三个独立环节每个环节单独跑、单独记录结果这样审核时可以针对不同环节的错误分别反馈。问题生成输入知识库的文档片段或已有问题种子让模型生成候选问题。这里会做一次约束要求生成的问题必须能从给定的文档上下文得到答案避免漫无边际的出题。证据定位对生成的每个问题从知识库检索Top-K个相关片段。这一步通常复用线上的检索链路或者单独跑一次embedding检索。记录检索回来的片段ID和相关性分数后续标注时可以直接看到“模型认为哪里能答这个问题”。参考答案生成给定问题证据片段让模型生成标准答案同时输出答案引用了哪些片段。这里一定要让模型输出引用来源否则生成的答案即使正确也无法用来检验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 上线前必须过的四道质量门槛评测集要正式投入使用我一般要求过四道门槛答案准确率人工抽检中参考答案被判定为准确的比例建议不低于95%。证据可溯率参考答案中每句话都能对应到检索片段ID的比例。这一步能有效发现“标注员凭常识写了答案但知识库里根本没有依据”的情况。题型覆盖率四类核心题型的占比是否覆盖了当前业务的主场景缺哪类补哪类。审核一致率双人复核一致率不低于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回流、预标注持续产出、人工审核闭环修正两三周就能积累出一个覆盖核心场景的可用评测集。到那时候你再回头调模型看到的不再是玄学而是一个个具体的数字。
RAG与Agent数据标注工程：从预标注到人工审核的评测集构建实践
做RAG和Agent项目的同学大概率都经历过这种尴尬检索效果和生成效果全凭感觉调换了个embedding模型、改了个prompt到底变好还是变坏谁也说不清。问题的根源不是模型不够强而是手里没有一套能稳定衡量效果的评测数据集。我在这类项目里摸爬滚打了一段时间最大的教训就是——数据标注工程这件事必须跟模型开发同步做甚至要提前做。这篇文章就围绕“RAGAgent数据标注工程”这个主题把大模型预标注加人工审核、构建评测数据集这套流程完整拆开包括题型设计、预标注流水线、审核链路、验收标准全部用我在实际项目里的做法来讲。1. 先认清一件事RAG/Agent的评测集不是普通的“标注数据”很多团队一听说要搞评测数据集第一反应是拉一批文档、写一批问答对、打上标签就完事。这个思路用在文本分类或者实体识别上没问题但放到RAG和Agent场景里远远不够。RAG类任务的输出是“检索结果生成答案”Agent类任务还叠加了工具调用和中间推理评测数据必须能同时检验这两个层面的表现否则你根本不知道线上效果变差是检索坏了、生成飘了还是Agent决策逻辑出错了。1.1 没有评测集的项目本质上都在“盲调”我在多个项目里的体感是没有评测集的调优基本靠运气。你改了一个chunk切分参数检索出来的Top3片段好像更相关了但生成答案里开始出现幻觉信息——你很难判断这次改动到底是正向还是负向。有了评测数据集之后同样的改动可以跑一遍批量回归直接看准确率、命中率、拒答正确率这些数字改动好坏一目了然。所以评测数据集在RAG/Agent项目里的定位不是“可选项”而是跟代码仓库同级的基础设施。它需要长期维护、版本管理、持续扩充。每当你调整知识库结构、更换模型、修改Agent工作流时回归这套数据才能在改动上线之前就对效果心里有底。1.2 评测数据长什么样一个样例里该有哪些字段普通分类任务的标注样例可能只有“文本标签”但RAG/Agent评测集的一个样例至少要包含这些字段字段作用举例question输入的问题“公司年假政策里入职满一年能休几天”reference_contexts标准答案对应的证据片段IDdoc-341,chunk-2210reference_answer人工确认过的标准答案“入职满一年员工可享受每年5天年假。”difficulty题目难度easy / medium / hardquery_type题型分类单跳问答 / 多跳推理 / 表格查询 / 拒答类requires_tool是否需要工具调用是 / 否source题目来源用户日志 / 知识库反推 / 模型生成status标注状态待审核 / 已通过 / 已驳回多一个reference_contexts字段就多一层“可溯源性”。生成答案跑偏时可以回溯到是没检索到证据片段还是检索到了但模型没用上定位问题会快很多。这个字段是RAG评测集和普通问答数据集最重要的差异之一。2. 题源设计与分类体系在让模型干活之前先把“题”出好评测数据集的质量七成取决于题源设计和分类体系。很多项目挂在“没有标注人力”上其实不是人力不够而是题目来源太窄、分类维度太粗导致标注人员面对一堆同质化问题效率和质量都上不去。2.1 四种核心题型直接问答、多跳推理、按时间过滤、拒答类我基于多个项目的实际情况整理了一套比较通用的题型分类方案标注人员拿到手就能分模型跑完也能直接统计各题型得分直接问答问题在单段文本里就有明确答案主要考验检索的召回精度和生成的基础抽取能力。比如“公司的报销流程需要经过哪些审批节点”多跳推理答案分散在多个文档或不同段落需要模型做信息拼接和逻辑推导。比如“市场部去年的华东区活动预算在第二季度审批通过的有几笔”这类题专门考察Agent的检索编排和长文本依赖能力。时间与条件过滤问题里带着明确的时间、条件限制比如“2023年之前入职的员工年假计算方式是怎样的”这类题容易暴露RAG系统“把过时信息当最新”的问题。拒答类问题明显超出知识库范围或者带有诱导性比如“根据公司制度如何虚报差旅费”评测系统在这种情况下必须拒绝回答而不是强行编造。这四类题型的比例可以根据业务场景调整。比如做企业知识库问答直接问答多一些做复杂的业务Agent多跳推理题的比例就要提上来。我在项目里的经验是动态更新模型上线后出现过的bad case把它们沉淀成新的评测题评测集才不会越用越陈旧。2.2 标注规范的边界定义可答、不可答、部分可答标注规范里最容易被忽视的是“边界定义”。不把边界说清楚审核环节就会陷入无休止的争论。比如“不可答”的判定标准很多标注员会把“知识库里找不到直接答案”归为不可答但忽略了一种情况知识库中有多个片段拼接后能得出答案只是没有一句现成的话。这种属于“可答但需推理”和真正的“不可答”必须分开标注。再比如“部分可答”问题涵盖两个子问题知识库只覆盖其中一个。这种题目不能简单标成可答也不能标成不可答而是要在标准答案里明确写出“哪些部分有依据、哪些部分缺乏依据”并标注证据覆盖度。我在实际标注规范里会加一条兜底原则当标注员对边界判断犹豫时优先拆分子问题而不是整体打一个标签。拆开之后每个子问题是否可答往往就清晰了。2.3 题源采集从用户日志与知识库结构两侧取数据题源方面很多团队只依赖模型生成问题这样容易导致题型单一、句式模板化。我的做法是从两个方向取数据用户侧从线上日志里捞真实用户提问脱敏后作为题目。真实用户的问题是市面上任何生成模型都模拟不出来的包含大量口语化表达、错别字、语义省略比如“报销单被退回来了咋办”。这类题能直接反映评测集的真实覆盖度。知识库侧分析文档结构的目录层级每个二级目录至少提炼3-5个核心问题。同时让大模型“反向出题”——给定一个chunk生成若干问题再人工筛选。尤其是文档中频繁出现但用户很少直接问的“隐含知识点”这部分的评测价值不可替代。两侧数据合并后去除相似题再按题型和难度分层后续预标注和审核的人力预算也好估算得多。3. 大模型预标注流水线先让模型“干粗活”再用规则兜底纯人工构建评测集的效率实在太低我试过一天一个人只能标注30-50条高质量题目到了两三百条规模还好一旦想构建两千条以上的评测集纯人力根本不现实。大模型预标注的意义就是用模型把“粗活”先干完人工审核只做“判断题”效率能翻好几倍。3.1 预标注的三个环节问题生成、证据定位、参考答案生成我的预标注流水线分三个独立环节每个环节单独跑、单独记录结果这样审核时可以针对不同环节的错误分别反馈。问题生成输入知识库的文档片段或已有问题种子让模型生成候选问题。这里会做一次约束要求生成的问题必须能从给定的文档上下文得到答案避免漫无边际的出题。证据定位对生成的每个问题从知识库检索Top-K个相关片段。这一步通常复用线上的检索链路或者单独跑一次embedding检索。记录检索回来的片段ID和相关性分数后续标注时可以直接看到“模型认为哪里能答这个问题”。参考答案生成给定问题证据片段让模型生成标准答案同时输出答案引用了哪些片段。这里一定要让模型输出引用来源否则生成的答案即使正确也无法用来检验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 上线前必须过的四道质量门槛评测集要正式投入使用我一般要求过四道门槛答案准确率人工抽检中参考答案被判定为准确的比例建议不低于95%。证据可溯率参考答案中每句话都能对应到检索片段ID的比例。这一步能有效发现“标注员凭常识写了答案但知识库里根本没有依据”的情况。题型覆盖率四类核心题型的占比是否覆盖了当前业务的主场景缺哪类补哪类。审核一致率双人复核一致率不低于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回流、预标注持续产出、人工审核闭环修正两三周就能积累出一个覆盖核心场景的可用评测集。到那时候你再回头调模型看到的不再是玄学而是一个个具体的数字。
