通用大模型 SFT 阶段 · 多轮对话项目标注规则文档
本文档适用于所有参与本项目的标注员与质检员，请在上岗前完整阅读并通过规则测试。多轮规则需在单轮规则基础上额外掌握，两份文档配合使用。
1
项目背景与目标
1.1 项目背景
本项目为某国产通用大语言模型（参数规模 70B）SFT 阶段的多轮对话数据建设项目。模型已完成预训练及单轮 SFT，但在实际多轮对话场景中暴露出以下核心问题，需通过本次数据标注进行针对性修复：
| 问题类型 | 具体表现 | 对用户的影响 |
|---|---|---|
| 上下文遗忘 | 对话超过 4 轮后，模型频繁"忘记"用户在首轮提供的关键信息（如订单号、姓名、需求背景） | 用户被迫重复提供信息，体验极差 |
| 指代消解失败 | 对"它""这个""上面说的"等代词无法准确还原指代对象 | 回答对象错误，答非所问 |
| 角色漂移 | 长对话中模型风格前后不一，或忘记 system prompt 中设定的角色人设 | 产品体验不一致，信任感下降 |
| 过度拒绝 | 对合理的追问（如"能再详细一点吗"）频繁触发安全拒绝 | 功能失效，用户流失 |
多轮标注规则在单轮四维规则基础上，额外新增三个多轮专项维度：指代省略、重复摘抄、上下文一致性。标注时需同时检查单轮维度和多轮专项维度。
1.2 项目目标
模型侧目标
- 修复多轮上下文遗忘问题，支持 ≥ 8 轮连贯对话
- 准确识别并还原对话中的指代词与省略成分
- 在全轮次中保持 system prompt 设定的角色人设
- 减少对正常追问的误拒绝行为
数据侧目标
- 产出 ≥ 20,000 条通过质检的多轮对话样本
- 平均对话轮次 ≥ 4 轮，覆盖 8 轮以上场景
- 覆盖 5 大场景、≥ 50 个细分意图类别
- 标注一致性（Kappa 值）达到 ≥ 0.70
- 最终数据集质检通过率 ≥ 95%
1.3 场景分布规划
| 场景 | 细分说明 | 目标数量 | 占比 | 难度 |
|---|---|---|---|---|
| 智能客服 | 电商退换货、物流查询、账号问题 | 5,000 条 | 25% | 低-中 |
| 代码助手 | 需求迭代、Bug 修复、代码解释 | 4,000 条 | 20% | 高 |
| 知识问答 | 政策法规、科学常识、历史地理 | 4,000 条 | 20% | 中 |
| 创意写作 | 故事续写、文案改写、风格转换 | 3,500 条 | 17.5% | 中 |
| 角色扮演 | 人设维持、情感陪伴、情景对话 | 3,500 条 | 17.5% | 中 |
2
数据概览
2.1 数据来源与规模
原始数据池
~35,000
条（含低质数据）
目标通过量
20,000
条（预计通过率 ~57%）
平均对话轮次
4~8
轮（user+assistant 各算一轮）
平均 token 数
~1,200
tokens / 条（含 system）
2.2 数据来源构成
| 来源类型 | 描述 | 占比 | 处理方式 |
|---|---|---|---|
| 真实用户日志（脱敏） | 来自合作平台的历史对话记录，已通过差分隐私脱敏处理 | 30% | 人工筛选 + 质量过滤 |
| 人工种子 + 模型扩写 | 标注员撰写前 2 轮种子对话，由基础模型续写后人工逐轮审核 | 40% | 人工核查每轮回复 |
| Human-Human 全人工撰写 | 标注员完整撰写 user 和 assistant 双方对话 | 20% | 直接进入质检 |
| 公开数据集改写 | 基于 ShareGPT、BELLE 等开源数据二次改写 | 10% | 去重 + 风格改写 |
2.3 数据格式（JSON Schema）
标注员在平台中收到草稿对话后，需按以下 JSON 格式完成并提交。每条数据必须包含完整的多轮对话链。
"id": "CHAT-20260318-00001"
"scene": "customer_service" ← 场景标签
"intent": "refund_query" ← 意图标签
"conversations": [
{ "role": "system", "content": "你是一名专业的电商客服助手..." },
{ "role": "user", "content": "我的订单已经7天没到了" },
{ "role": "assistant", "content": "您好，请提供一下订单号，我来帮您查询..." },
{ "role": "user", "content": "订单号是123456789" },
{ "role": "assistant", "content": "已查询到您的订单，目前状态为..." }
],
"turn_count": 4 ← user+assistant 各算1轮
"quality_score": 4 ← 1~5 分
"annotator_id": "ANT-072" ← 标注员工号
"flags": [] ← 异常标记，如 format_error
| 字段 | 含义 | 示例 |
|---|---|---|
| id | 数据唯一标识 | CHAT-20260318-00001 |
| scene | 场景标签 | customer_service |
| intent | 意图标签 | refund_query |
| conversations | 对话列表，按顺序排列 | 见左侧结构 |
| turn_count | 对话轮数（不含 system） | 4 |
| quality_score | 综合质量评分 | 1~5 |
| annotator_id | 标注员工号 | ANT-072 |
| flags | 异常标记数组 | [] 或 ["format_error"] |
格式核心红线：
- role 字段必须严格交替：user → assistant → user → assistant，不得出现连续两个相同角色
- 对话必须以 assistant 结尾：最后一轮必须是 assistant 的回复
- turn_count 需与实际轮数一致：user+assistant 各算 1 轮，system 不计入
- 最少 4 轮：不足 4 轮的对话需人工扩充到最低要求
3
人力配置与人效
3.1 人员构成（共 28 人）
标注员
20
分 2 组，每组 10 人
质检员
4
含 1 名资深质检
组长
2
各带 1 组，负责日常答疑
项目周期
6 周
标注 4 周 + 质检修复 2 周
| 角色 | 每小时产出 | 每日产出（有效 6.5h） | 备注 |
|---|---|---|---|
| 标注员 加权平均耗时约 16.8 分钟/条 |
约 3.6 条 / 小时 | 约 23 条 / 人 / 天 | 简单任务（2~4轮）约 10 min；中等（4~6轮）约 18 min；复杂（6~8轮）约 28 min；比例 4:4:2 |
| 质检员 复查已标注数据 |
约 8 条 / 小时 | 约 50 条 / 人 / 天 | 含填写质检日志与反馈意见；安全类数据需全检，速度约降低 30% |
3.2 里程碑计划
| 周次 | 阶段 | 主要任务 | 交付物 |
|---|---|---|---|
| Week 1 | 准备与培训 | 规则宣讲、试标 200 条、一致性校准 | 试标报告、校准会议纪要 |
| Week 2 | 正式标注（第一批） | 完成 4,000 条，质检同步启动 | 第一批数据包 + 质检报告 |
| Week 3 | 正式标注（第二批） | 完成 4,000 条，处理第一批返工 | 第二批数据包 |
| Week 4 | 正式标注（第三批） | 完成 4,000 条，覆盖长轮次场景 | 第三批数据包 |
| Week 5 | 收尾标注 + 全量质检 | 完成剩余 8,000 条，全量质检启动 | 质检日志、问题汇总 |
| Week 6 | 修复 + 交付 | 返工修复、数据去重去敏、最终打包 | 最终数据集 + 完整质检报告 |
从第 2 周起，每周输出个人产能 + 质量双维报告。连续 3 天产能低于目标 70% 的标注员，PM 将进行辅导。质量优先于数量，但两者均须达标。
4
多轮标注规则体系
4.0 规则维度概览
多轮对话标注规则 = 单轮四维规则（安全 → 指令遵循 → 内容准确性 → 语言质量）+ 多轮三项专项维度（指代省略 · 重复摘抄 · 上下文一致性）。
安全维度为一票否决项：任何轮次中发现安全违规，无需继续评估其他维度，整条数据直接判定「不通过」。安全类数据进入质检全检队列。
| 维度类别 | 维度名称 | 权重 | 适用范围 |
|---|---|---|---|
| 最高优先级 | 安全维度 | 一票否决 | 全轮次，任一轮违规即整条打回 |
| 次高优先级 | 指令遵循 | 20% | 检查每轮 assistant 是否准确响应当前用户意图 |
| 中优先级 | 内容准确性 | 20% | 事实正确性、推理链路、幻觉检测 |
| 基础 | 语言质量 | 5% | 语法、标点、格式规范性 |
| 多轮专项 | 指代省略 | 20% | 核查每轮中指代词的还原是否准确 |
| 重复摘抄 | 10% | 后续轮与前轮文字重复比例不超过 30% | |
| 上下文一致性 | 25% | 各轮内容/逻辑/语义连贯统一 |
4.1 【多轮专项】指代省略
定义：理解多轮对话中的指代词（"它""这个""那个""上面提到的"）在上下文中的指代对象；识别多轮中被省略的实体或信息，结合前文正确理解当轮 prompt 的完整含义。
4.1.1 常见指代词类型
人称代词
它、他、她、他们、您
→ 需还原指代的具体实体
→ 需还原指代的具体实体
指示代词
这个、那个、这种、上面的、刚才的
→ 需还原指代的具体对象
→ 需还原指代的具体对象
省略成分
"那退款吗？"（省略了订单主语）
→ 需从前文补全省略内容
→ 需从前文补全省略内容
4.1.2 评分标准与判断方式
| 错误子类型 | 判断标准 | 错误标签 |
|---|---|---|
| 指代目标回答错误 | assistant 的回答针对了错误的指代对象。例如用户说"那个呢？"指代第 1 轮提到的产品 A，但 assistant 理解为产品 B | 【指代省略】指代目标回答错误 |
| 指代内容不明确 | assistant 感知到了有指代词，但未明确还原就给出模糊回答；或主动追问代词含义属于合理行为，但追问方式使对话停滞 | 【指代省略】指代内容不明确 |
4.1.3 标注技巧
- 通读全文后，在草稿区列出对话中出现过的所有实体清单（人名、产品、订单号、地点等）
- 每遇到一个代词，停下来问自己："这个代词指的是实体清单中的哪一个？"
- 再对照 assistant 的实际回答，检查是否回答了正确的那个实体
- 指代不明确时，assistant 主动澄清（"您说的'它'是指……吗？"）是正确行为，不扣分
✔ 正确示例（指代还原准确）
第1轮 User：我想了解一下你们的旗舰手机和入门款第1轮 Assistant：旗舰款是 Pro X，入门款是 Mini S，……
第3轮 User：那个贵的支持 5G 吗？
第3轮 Assistant：Pro X 支持全频段 5G，……
✓ 正确将"那个贵的"还原为 Pro X
✘ 错误示例（指代对象错误）
第1轮 User：我想了解一下你们的旗舰手机和入门款第3轮 User：那个贵的支持 5G 吗？
第3轮 Assistant：Mini S 的网络支持方面……
✗ 将"贵的"错误还原为 Mini S（入门款），指代目标错误
4.2 【多轮专项】重复摘抄
定义：后续轮次的 assistant 回答中，与前面轮次回答存在大量相同或高度相似文字的情况。重复比例超过 30% 即判定为违规。
4.2.1 如何判断重复比例
- 操作方法：复制需检查的两轮回答到文本编辑器，对比相同语句 / 段落，估算重叠文字占当前轮次总字数的比例
- 若相同文字 / 语句占当前轮回答字数 > 30%，标注
【重复摘抄】 - 完全相同的例句、定义性引用（如精确引用某政策原文）不算重复，需在问题备注中说明
4.2.2 典型触发场景
| 场景 | 说明 |
|---|---|
| 用户追问细节，模型复述前轮全文 | 用户第 3 轮追问某个子点，模型将第 1 轮的完整回答原文复制粘贴，仅增加一两句话 |
| 用户要求"简单总结"，模型原文摘抄 | "简单总结"应是提炼核心要点，而非重复前轮的全部内容 |
| 追问同类信息，结构套路完全相同 | 第 2 轮和第 4 轮都是介绍产品，模板框架逐字相同，仅替换了产品名 |
✔ 正确示例（提炼而非摘抄）
第1轮 Assistant（详细回答，约 300 字）：多肉植物养殖要注意：1.土壤 2.光照 3.浇水 4.温度……（完整展开）第3轮 User：简单总结下。
第3轮 Assistant（约 80 字）：核心记住四点：透气土、散射光、干透浇透、15~28℃。
✓ 高度提炼，重叠率 < 10%
✘ 错误示例（摘抄超过 30%）
第1轮 Assistant：多肉植物养殖：1.土壤选疏松排水良好的 2.光照需充足但避免直射……（8 条，约 300 字）第3轮 User：简单总结下。
第3轮 Assistant：当然！1.土壤选疏松排水良好的 2.光照需充足但避免直射……（原文逐条复制，仅删了"当然！"）
✗ 重叠率 > 80%，严重违反重复摘抄规则
4.3 【多轮专项】上下文一致性
定义：各轮次在内容、主题、逻辑和语义上保持连贯性和统一性；能够对照历史对话的 query 和 response 的逻辑继续产出内容，不出现前后矛盾或背离已确认事实的情况。
4.3.1 评分标准
| 问题类型 | 说明 | 典型案例 |
|---|---|---|
| 事实矛盾 | 不同轮次中 assistant 提供了互相矛盾的事实信息 | 第1轮说"明天到货"，第3轮说"需要3天" |
| 忽略已确认信息 | 用户在前轮明确提供了信息，assistant 在后轮中视若无睹，重新询问或给出与之矛盾的内容 | 第1轮用户说"我用的是Python"，第3轮 assistant 提供了 Java 示例 |
| 主题偏离 | 对话主线被无端打断，assistant 跑偏到与上文无关的话题 | 用户一直在问退货，assistant 突然开始推荐新产品 |
| 逻辑断层 | 当前轮次的推论建立在一个与前文矛盾的前提上 | 前文刚确认"用户是会员"，后文又按非会员逻辑计算价格 |
4.3.2 标注技巧
- 建立"已确认事实"清单：通读对话后，提炼出对话中已经确定的所有事实（如：用户名称、订单状态、选择的编程语言、用户身份等）
- 逐轮检查：每一轮 assistant 的回答是否与清单中的已确认事实相符
- 重点检查第 3、5、7 轮（奇数轮）——这些轮次最容易出现上下文丢失
- 话题切换是正常的（用户可以主动换话题），但 assistant 不能无端漂移；若用户换了话题，assistant 应顺势响应
✔ 正确示例（上下文连贯）
第1轮 User：我叫张伟，查一下3月25日的眼镜订单第1轮 Assistant：好的张伟先生，3月25日眼镜订单……
第3轮 User：那个订单能退款吗？
第3轮 Assistant：您的3月25日眼镜订单目前符合无理由退款条件……
✓ 每轮均正确延续姓名、日期、商品品类
✘ 错误示例（上下文断裂）
第1轮 User：我叫张伟，查一下3月25日的眼镜订单第3轮 User：那个订单能退款吗？
第3轮 Assistant：您好，请问您的订单号是多少？
✗ 完全遗忘前文，要求用户重复提供已知信息
5
错误类型完整列表
标注时从以下标准错误类型中选取，可多选，用「/」分隔填写在「错误类型」列。多轮专项维度（绿色行）是本项目在单轮基础上新增的。
| 错误大类 | 错误子类（标准名称） | 说明 | 多轮特别注意 |
|---|---|---|---|
【指令遵循】 | 部分遵循指令 | 回答大致方向正确但遗漏了指令中的某些要求 | 多轮中需检查每轮是否继承了 system 及前轮的约束 |
| 完全不遵循指令 | 回答与指令完全无关，或拒绝了合理请求 | 角色扮演场景尤其关注是否维持了设定角色 | |
【准确性】 | 事实性回答错误 | 回答中包含错误的事实、数据、定义等 | 多轮追问时注意前后事实是否自洽 |
| 提问有误回答未纠错直接使用 | 用户提问存在错误前提，模型未指出直接顺着回答 | — | |
| 推理过程有误 | 回答的推理链条中存在逻辑跳跃或谬误 | — | |
【丰富性】 | 多维度 | 只覆盖了问题的某一角度，应多角度展开 | 后续轮次追问细节时需补充前轮未覆盖的维度 |
| 有效信息拓展 | 回答信息量不足，未提供有价值的延伸信息 | — | |
| 回答内容全面 | 回答遗漏了关键要点，不够全面 | — | |
【结构性】 | 分点未总分/总分总/其他格式问题 | 有分点但缺少总起句或总结句 | — |
【信息表达性】 | 内容是否完整/语句是否通顺/内容是否冗余/开头/结尾话术 | 语言表达存在问题：截断、啰嗦、套话、冗余 | 多轮中冗余话术尤为明显（重复前轮内容开头） |
【信息结构性】 | 逻辑表达 | 回答的逻辑层次混乱，论证不清晰 | — |
| 内容分点/段描述/格式内容符合 | 格式不符合场景要求 | — | |
| 格式内容符合 | 格式与指令或场景不匹配 | — | |
【指代省略】 | 指代目标回答错误 | 模型对指代词的还原出现偏差，回答了错误的对象 | 重点检查"它""这个""上面提到的"等词 |
| 指代内容不明确 | 模型未能明确指代对象，回答含糊 | 应主动澄清而非模糊作答 | |
【上下文一致】 | （直接使用此标签） | 各轮次内容/逻辑/语义不连贯，前后矛盾 | 逐轮核对"已确认事实"清单 |
【重复摘抄】 | （直接使用此标签） | 后续轮次与前轮重复比例超过 30% | 估算重叠字数占比 |
【安全性】 | （直接使用此标签） | 回答含有不安全、有害、违规内容 | 一票否决，整条数据打回 |
【帮助性】 | （直接使用此标签） | 回答对用户无实质帮助 | — |
【其他】 | 字数限制 | 不符合字数相关约束 | — |
| 内容是否本土化 | 内容未针对中国市场/语境进行适配 | — | |
| （其他） | 不属于以上任何分类，在备注中详细说明 | — |
多选填写示例：一条多轮数据若第 3 轮存在"指代词还原错误"且回答"重复了第 1 轮大量内容"，错误类型填写为：
【指代省略】指代目标回答错误/【重复摘抄】
6
标注执行 SOP
6.1 单条任务操作步骤
1
通读全文（约 1 分钟）
从 system → 第1轮 → 最后一轮，完整阅读一遍，建立整体印象。
- 记录：用户的核心目标是什么？对话最终是否达成了目标？
- 在草稿区列出所有出现的关键实体（姓名、产品、订单号、语言等）
2
逐轮精读与问题识别（约 10~25 分钟）
按时间顺序逐轮检查，每轮聚焦以下核查清单：
- 安全：本轮是否含有任何违规内容？（一旦发现立即标记，不再继续）
- 指令：本轮 user 意图是什么？assistant 是否准确响应？
- 内容：回复有无事实错误或幻觉？
- 指代：本轮是否有代词？是否正确还原了指代对象？
- 上下文：本轮是否与前文已确认事实一致？
- 重复：本轮与前面轮次文字重叠是否超过 30%？
3
修改 assistant 回复（如有问题）
发现问题后，优先直接修改 assistant 回复；不要修改 user 的发言（仅可修正明显拼写错误，不能改变用户意图）。
- 改写原则：最小化改动，保持对话自然流畅，不改变对话走向
- 修改处在填写「正确改写」列时标绿色文字
4
轮次完整性检查
- 确认对话 ≥ 4 轮（user+assistant 各算 1 轮），不足需人工扩充
- 确认 role 字段严格交替，以 assistant 结尾
- 扩充时模拟自然追问行为："能再详细一点吗""如果想……该怎么做"
5
决策：判断处理路径
路径 A
直接通过
全轮次无明显问题 → 「审核结果」填「通过」
路径 B
修改后通过
有问题已修复 → 填「修改通过」+ 错误类型 + 改写内容
路径 C
不通过 / 打回
含安全问题或改写成本过高 → 填「不通过」+ 详细原因
6
填写字段并提交
- 「审核结果」：通过 / 修改通过 / 不通过
- 「错误类型」：从第 5 节标准名称中选取，可多选，用「/」分隔
- 「不通过详细原因」：具体说明问题所在（哪一轮，什么问题），不可模糊
- 「正确改写」：填写完整的正确文本，改动处标绿色文字，删除部分可不标
- 「标注人」：填写本人工号（如 ANT-072）
6.2 特殊场景处理规则
| 特殊情况 | 处理方式 |
|---|---|
| 用户在中途切换话题 | 认定为新意图，assistant 应顺势跟随，不要强行拉回原话题；标注时按新意图评估指令遵循维度 |
| 对话中包含代码块 | 代码本身的正确性不作为主要评分标准（除非功能严重错误），重点评估解释文字的质量和上下文一致性 |
| 遇到英文对话 | 按同等标准处理，语言质量按英文语法规范评估；指代省略规则同样适用于英文代词 |
| system prompt 为空 | 按通用助手风格评估角色一致性，不强制要求特定人设，但要求全轮次风格统一 |
| 最后一轮被截断 | 标注 flags: ["format_error"] 并人工补全 assistant 最后一轮的完整回复 |
| 用户发言含个人信息 | 立即进行脱敏处理（姓名打码：张** / 电话：138****1234），严重情况整条打回 |
| 规则文档没有明确说明的情形 | 截图 + 描述 → @组长 / PM → 等待官方解释，不擅自决策，此条数据暂时标注 flags: ["review_needed"] |
7
填写规范与样本示例
7.1 颜色标注约定
颜色标注约定：
- 红色高亮：prompt / response 列中，具体的错误片段区域
- 绿色高亮：「正确改写」列中，相比原 response 新增或修改的内容片段
- 未改动部分保持默认白色背景，无需特殊标注
7.2 标注样本示例（多轮专项规则演示）
以下为本项目实际标注样本，重点展示多轮三项专项规则的规范填写方式（从原始 Excel 数据中选取）：
示例 1：上下文一致性问题 + 指令遵循问题
| 轮次 | prompt | response（错误区域标红） | 审核结果 | 错误类型 | 不通过详细原因 | 正确改写（改写标绿） |
|---|---|---|---|---|---|---|
| 第1轮 | 你是一位花艺师，我现在需要养殖多肉植物，请告诉我这种植物的养殖方法，注意事项 | 多肉植物是一类非常受欢迎的观赏植物，它们具有抗旱、耐寒、生长速度快等特点。…… （全程未以花艺师身份表达） |
不通过 | 【指令遵循】部分遵循指令【准确性】事实性回答错误 |
①prompt 明确设定"花艺师"角色，但 response 全程未以花艺师身份表达，未遵循角色指令；②"耐寒"表述有误，大多数多肉原产于热带干旱地区，不耐严寒，低于5℃即可能受冻 | 作为一名花艺师，多肉植物是我们花艺设计中常用的素材……（4.温度要求：适宜15~28℃。大多数多肉不耐严寒，冬季低于5℃需移至室内……） |
| 第2轮 | 简单总结下。 | 当然，以下是多肉植物养殖的简单总结：1.土壤：选择疏松、排水良好的土壤……（以下 8 条与第1轮完全相同，逐字摘抄） | 不通过 | 【重复摘抄】【信息表达性】内容是否完整/语句是否通顺/内容是否冗余/开头/结尾话术 |
①本轮与第1轮 response 内容重叠超过 80%，严重违反重复摘抄规则（上限 30%）；②"当然，"为冗余开头话术；③结尾"掌握这些……就能顺利养护"与第1轮结尾原文重复 | 作为花艺师，简单总结多肉养殖要点：1.土壤：颗粒透气土。2.光照：散射光为主，每天4~6小时。3.浇水：干透浇透。4.温度：15~28℃，低于5℃移至室内。5.繁殖：叶插为主。6.施肥：生长期每月一次缓释肥。7.病虫害：保持通风，发现介壳虫及时处理。8.修剪：工具消毒后适度修剪。 |
示例 2：指代省略问题
| 轮次 | prompt | response（错误区域标红） | 审核结果 | 错误类型 | 不通过详细原因 | 正确改写（改写标绿） |
|---|---|---|---|---|---|---|
| 第1轮 | chatgpt在编程中有什么应用? | …1.代码生成 2.代码审查 3.问题解答 4.文档生成 5.教学辅助 6.代码优化 7.自动化测试 8.项目管理… | 通过 | — | — | — |
| 第2轮 | 第二点和倒数第二点解释下吧。 | 当然，我来详细解释一下： 1. 代码审查：……（✓正确） 2. 自动化测试：……（✓正确） 总体来说，这两个方面都体现了ChatGPT在提高编程质量和效率方面的潜力。代码审查帮助开发者优化和改进他们的代码，而自动化测试则是确保软件质量的重要工具。 |
修改通过 | 【指代省略】指代目标回答错误【信息表达性】内容是否完整/语句是否通顺/内容是否冗余/开头/结尾话术 |
①"第二点和倒数第二点"指代正确（代码审查+自动化测试），但 response 重新标注为"1.""2."与原文第2、7条编号脱节，用户会产生困惑，属指代还原后表达方式有误；②结尾总结段为对正文内容的重复，冗余；③"当然，我来详细解释一下："为冗余开头话术 | **第2点 · 代码审查** ChatGPT能分析代码识别潜在错误、不规范实践及性能瓶颈，并给出改进建议，有助于提升代码可读性和可维护性。 **第7点 · 自动化测试** ChatGPT可根据软件功能和需求生成测试脚本与场景，提高测试效率，有助于确保软件稳定性和可靠性。 |
核心填写红线：
- 「不通过详细原因」必须注明具体是哪一轮出了什么问题，不可模糊填写"回答有问题"
- 「错误类型」与「不通过详细原因」必须对应，不可出现填了错误类型但原因为空的情况
- 「正确改写」是最终进入训练集的内容，改写质量直接影响模型效果，请认真对待
- 禁止修改 user 的发言内容（可修正拼写错误，但不能改变用户的意图表达）
- 禁止代填他人「标注人」字段，一经发现取消当日数据计入
8
质检标准
8.1 三层质检体系
| 层次 | 执行者 | 方式 | 频率 | 目标通过率 |
|---|---|---|---|---|
| L1 自检 | 标注员本人 | 提交前逐项核对自检清单（见 8.4 节） | 每条提交前 | ≥ 98%（自检漏项 < 2%） |
| L2 抽检 | 质检员 | 每批次随机抽取 10% 全量质检 | 每日 | ≥ 90%（低于此线全批打回） |
| L3 全量复检 | 质检员 + 组长 | 最终交付前对全数据集全量扫描 | 项目结束前 | ≥ 95%（最终交付标准） |
8.2 抽检比例
常规抽检率
10%
每批次随机抽取
安全类全检
100%
所有含安全问题数据
新人加强抽检
50%
上岗第 1 周
单批打回触发线
<90%
单批次通过率低于此值全批打回
8.3 质检判定结论
| 质检结论 | 触发条件 | 处理动作 |
|---|---|---|
| 通过 | 全维度达标，上下文无明显断裂，格式字段完整 | 数据进入训练集 |
| 退回修改 | 漏标问题类型，或改写内容有瑕疵但可补救；轻微重复摘抄或指代模糊 | 退回标注员，备注修改意见，24 小时内重新提交 |
| 质检直接丢弃 | 安全问题漏标；改写引入新错误；上下文一致性严重失效；改写内容仍不达标 | 质检员直接丢弃，计入标注员错误统计 |
| 升级仲裁 | 标注员与质检员意见严重分歧，涉及多轮指代边界案例或复杂安全判断 | PM 或数据负责人介入，裁定结果同步更新规则文档 |
8.4 标注员提交前自检清单
每条提交前请对照以下清单逐项确认，平台提供勾选框，全部勾选后方可提交。
| 序号 | 检查项 | 检查方式 |
|---|---|---|
| □ 1 | 对话轮次 ≥ 4 轮，最后一轮由 assistant 结尾 | 数对话条数 |
| □ 2 | user / assistant role 字段严格交替，无连续同角色 | 逐行确认 role 字段 |
| □ 3 | 【上下文一致性】全轮次已核查，无前后矛盾 | 对照首轮确认的"已确认事实"清单 |
| □ 4 | 【指代省略】含代词的轮次已确认还原正确 | 逐个代词核查 |
| □ 5 | 【重复摘抄】后续各轮与前轮重叠比例 < 30% | 估算重叠字数占比 |
| □ 6 | 【安全性】全轮次无任何违规内容 | 重新扫描一遍全文 |
| □ 7 | 个人隐私信息已脱敏（如有） | 检查姓名、手机、地址字段 |
| □ 8 | 所有字段填写完整（审核结果/错误类型/原因/改写/标注人） | 平台必填校验 |
| □ 9 | JSON 格式无误（引号、逗号、括号匹配，turn_count 正确） | 平台格式自动校验 |
8.5 个人质量监控与一致性校准
质量指标阈值
- 标注员错误率（质检驳回率）目标：≤ 5%
- 连续 3 天错误率 ≥ 10% → PM 约谈
- 单月错误率 ≥ 15% → 重新培训或调岗
- 安全类漏标一次 → 立即约谈
- 改写引入新知识错误 → 计 2 倍错误权重
一致性校准机制
- 黄金数据集比对（每周）：每人标注同一批 50 条，计算 Kappa ≥ 0.70，低于则追加培训
- 每日 Case Review：组长选取 3 条前日有争议案例集体讨论
- 规则迭代会议（每两周）：PM + 质检组长 + 甲方，裁定边界案例并更新本文档版本
- 个人准确率周报：质检员每周汇总每人通过率和主要差错类型并反馈
奖励机制：连续 2 周个人错误率 ≤ 2% 且日均产能达标的标注员，将获得优质标注员认证，优先参与后续项目，并有机会晋升为质检员。
规则争议处理：遇到规则文档未覆盖的情形，禁止自行判断后直接提交。正确流程：对该条数据打
flags: ["review_needed"] → 在项目沟通群 @组长/PM 并描述疑问 → PM 24 小时内给出官方解释 → 若涉及规则修订，同步更新本文档并全员通知。
通用大模型 SFT 多轮对话项目 · 标注规则文档 v1.0
最后更新：2026-03-18 · 如有疑问请联系项目 PM 或数据质量中心
最后更新：2026-03-18 · 如有疑问请联系项目 PM 或数据质量中心