企业做 AI 应用，通常要经过数据准备、模型训练或配置、测试验证等环节。数据标注贯穿其中，负责把数据整理成模型能够使用、也能够检验的数据。

例如，企业想训练一个售后客服模型，需要整理历史客服对话，判断用户提出了什么问题、客服给出的答案是否正确；如果要训练一个招聘助手，就需要对岗位要求、简历信息和匹配结果进行判断，形成可以用于训练和评测的样本。

这些工作都离不开人工标注。

项目规模较小时，安排几名熟悉业务的人员，按照统一要求完成标注，通常就能启动。但当数据量增加、任务类型变多，团队很快会遇到一些问题：相同内容被标注成不同类别，业务人员和标注人员对结果的理解不一致，模型测试中反复出现同类错误，已经交付的数据还需要重新处理。

这些问题会直接影响数据质量，也会增加项目成本。

尤其在大模型应用中，数据标注涉及的任务已经不局限于简单分类。指令微调需要整理问题与理想回答，偏好数据需要比较不同回答的质量，RAG 应用需要检查知识内容和检索结果，Agent 应用还可能涉及任务执行过程、工具调用和最终结果的判断。

不同任务需要不同的标注方法，但对团队管理有一个共同要求：必须有人负责标准、有人负责质量，也有人根据模型实际表现调整数据工作。

一、先弄清楚，团队到底在标注什么

数据标注不是一种固定的工作。项目目标不同，需要处理的数据和判断标准也不同。

以企业常见的大模型项目为例，大致可以分为几类。

第一类是训练数据标注。

例如，企业希望模型掌握内部业务知识和处理方式，需要整理业务人员的问题、标准回答和处理案例。这些数据经过筛选和处理后，可以用于指令微调。

指令微调，就是通过提供大量符合要求的输入和输出样本，让模型学习特定任务的回答方式。

这类标注需要关注输入信息是否完整、回答是否准确，以及样本是否符合预期的业务要求。

第二类是偏好数据标注。

例如，同一个问题，模型生成了两个回答，一个回答准确但不完整，另一个回答更全面，但包含错误信息。

标注人员需要根据事先确定的评价标准，判断哪个回答更符合要求，并说明判断依据。

这类数据可以用于偏好优化，让模型学习人们更认可哪种回答方式。

第三类是评测数据标注。

模型开发完成后，需要用一批有明确参考答案或评价标准的数据，检查模型在实际任务中的表现。

例如，招聘助手能否准确提取简历中的工作年限，售后助手能否正确理解退换货政策，Agent 能否按照要求完成工单处理。

这批数据需要经过审核，保证评价标准稳定，不能在每次测试时随意改变。

RAG 和 Agent 项目还会涉及知识质量、检索相关性、工具调用和任务执行结果等检查。具体是否需要人工标注，要根据项目的数据和评价方式确定。

这些任务看起来都叫数据标注，实际需要的业务知识和技术能力却不相同。

因此，团队在接到项目时，首先要明确数据用途、标注对象和最终验收标准，再决定需要什么样的人员和工作流程。

二、标注规范需要有人专门负责

确定了标注任务，接下来就要解决判断标准的问题。

以售后工单为例，用户说了一句「你们这个产品老是出问题」，标注人员需要判断这属于产品投诉、故障反馈，还是售后咨询。

如果没有明确的定义，不同人员很可能按照自己的理解进行分类。

解决这个问题，需要建立标注规范。

规范不能只有一份标签名称和简单解释，还需要说明每个标签的适用范围、容易混淆的情况，以及遇到特殊样本时如何处理。

例如：

• 产品质量问题：明确指出产品存在故障或质量缺陷。
• 使用咨询：询问产品功能、操作方法或使用条件。
• 无法判断：现有信息不足以确定具体问题类型。

还要补充实际案例，尤其是容易混淆的正反例。

规范制定过程中，业务人员需要参与。因为很多标签涉及企业自己的业务定义，单靠标注人员或者算法人员，很难准确判断。

规范完成后，建议先选取一批样本进行试标，让不同标注人员独立完成，再对比结果。

如果同一批样本出现较多分歧，就要检查定义是否存在歧义、例子是否充分，以及是否遗漏了特殊情况。

这里可以使用标注一致性指标进行辅助检查。但一致性高不代表业务判断一定正确，还需要由业务专家抽查和确认。

三、团队需要有人处理标注争议

规范再详细，也不可能提前覆盖所有业务情况。

随着标注工作推进，总会出现一些无法直接按照现有规则判断的样本。

例如，一条售后工单同时涉及产品故障和物流延误，究竟应该归入哪个类别？如果允许多标签，又应该如何确定主次？

这时需要有明确的仲裁机制。

仲裁，就是由具备业务判断能力的人，对存在分歧的样本给出最终处理意见。

团队可以设置一个专门的业务负责人，也可以由项目经理协调业务专家处理。具体人员安排取决于项目规模，但必须明确谁有权确定最终结果。

处理完争议之后，还要判断这次问题是否具有普遍性。

如果只是个别特殊样本，可以保留单独的处理记录；如果同类问题反复出现，就应该修改标注规范，补充新的判断规则。

这样，后续标注人员遇到相似情况时，就不需要重复讨论。

这里还有一个管理细节：不能简单要求标注人员把所有有争议的样本都自行判断。对于确实无法确定的内容，应该允许暂缓标注或提交复核，避免为了完成数量指标而产生错误数据。

四、标注质量需要持续检查

规范和仲裁机制解决了判断标准的问题，还需要检查实际交付的数据是否符合要求。

可以从三个方面开展质量检查。

检查标注结果是否符合规范。

从已完成的数据中抽取一部分样本，由有经验的人员重新审核，检查标签是否正确、信息是否完整、是否存在漏标和错标。

对于重要数据，可以安排多人独立标注，再由审核人员处理分歧。

检查不同标注人员的判断是否稳定。

可以定期安排一批相同样本，让不同人员独立标注，比较结果。

如果某个人的标注结果与团队整体差异较大，需要进一步分析原因：可能是培训不到位，也可能是规范本身不够清楚。

检查数据是否符合项目目标。

例如，企业做招聘助手，训练数据中如果只有大量标准、简单的岗位匹配案例，却缺少工作经历相似但实际职责不同的样本，那么模型在真实招聘场景中就可能出现判断偏差。

这种情况即使标注本身没有错误，数据也未必足够支撑模型目标。

所以，质量检查既要看单条数据是否标对，也要看整批数据是否覆盖了项目需要的场景。

五、标注团队还需要关注模型反馈

数据交付之后，工作并不一定结束。

如果项目已经进入模型训练和应用阶段，模型测试结果可以帮助团队发现现有数据的问题。

例如，一个企业知识助手在测试中经常把两项相似的业务政策混淆。排查后发现，原始知识库中存在相似表述，训练和评测数据也没有充分区分两种情况。

这时，团队就需要进一步检查数据，判断是否需要补充区分样本、修正标签，或者重新整理知识内容。

可以建立一个固定的反馈流程：

1. 从模型评测中整理错误样本。
2. 分析错误原因，区分数据问题、模型问题和系统问题。
3. 对确认属于数据问题的样本，形成补充或修正任务。
4. 完成处理后，重新测试模型，检查问题是否得到改善。

需要注意，模型出错不一定是标注数据的问题。例如，RAG 检索到了错误的知识片段，可能需要调整检索策略；Agent 没有正确调用工具，也可能涉及模型规划和系统权限配置。

因此，标注团队需要与算法、产品和业务团队保持协作，不能把所有模型错误都转化成标注任务。

六、数据标注团队应该怎么配置？

明确了工作内容，再来看人员配置。

对于一支承担大模型数据工作的团队，我认为至少需要明确以下几类职责：

职责	主要工作
数据标注执行	按照规范完成数据整理、分类、标记和审核
标注规范管理	制定标签体系、维护标注标准、组织试标
业务质量管理	处理争议样本、组织抽检、确认业务判断
数据与模型评测	建立评测数据、分析模型错误、提出数据改进任务

这不是要求每类职责都单独设立一个岗位。

如果团队规模较小，可以由项目负责人兼任规范管理和质量管理，由业务专家承担争议仲裁，标注人员负责具体执行。随着项目数量和任务复杂度增加，再逐步明确专职人员。

但有一点需要提前考虑：标注执行和质量审核最好保留必要的职责区分。尤其是重要评测数据，不能完全由制作数据的人自行确认质量。

团队考核也要相应调整。

标注数量和人均效率仍然需要统计，但还要结合标注准确率、抽检问题率、返工率、争议样本处理情况，以及数据在模型评测中的实际表现。

不能单纯用模型效果评价标注人员，因为模型效果还受到算法、知识库、检索和系统配置等因素影响。

数据标注团队的建设，最终要落到一件事上：每一批数据都能说清楚标注标准、质量如何确认，以及后续如何根据模型表现进行改进。

这套管理机制建立起来，团队才能从完成标注任务，逐步转向持续管理数据质量。