今天要学习的是一篇题为[利用大模型进行自动化数据标注](链接：https://mp.weixin.qq.com/s/TG5isq_pvZt9RxtSh9FoaA?scene=1&click_id=2)的公众号文章。

学习要点：利用大模型完成繁重的初标和复标工作，再以人工复核进行质量把关和流程调优，从而在保证质量的前提下大幅提升标注效率。

整体流程

这个流程可概括为以下七个关键步骤：

步骤	核心目标	关键操作与细节
1. 类目体系梳理	建立无歧义的标注标准	为每个类目提供清晰的概念解释，并给出典型的正例和反例。
2. 预标注	利用大模型进行初步自动化标注	构造合适的提示词（Prompt），并选择“比较靠谱的大模型”（如14B参数规模以上模型，文中提及Qwen3系列）进行零样本/少样本标注。
3. 大模型复核	通过模型自检或交叉校验提升可靠性	使用大模型对预标注结果进行正确性判断，并给出可能更准确的修正结果。（这里最好用更大的模型）
4. 人工复核与迭代优化	质量把关与流程调优的核心环节	对前两步结果进行抽样检查，评估实际准确率。若未达标，则回溯优化提示词设计（例如，将标注错误的Bad Case作为反例加入Prompt），反复迭代步骤2-4直至质量达标。
5. 数据集构造	为模型训练准备格式化数据	将达标的高质量标注数据整理为训练所需的格式。
6. 大模型训练	训练定制化模型	使用构造好的数据集对基座模型进行有监督微调（SFT）。
7. 推理与评估	验证模型效果	使用标注数据或人工对训练后的模型进行效果评估。

        我的实习内容也是利用大模型进行标注，虽然总结起来只有几点，但是实际操作起来是一个漫长的过程。

        和博客中说得一样，先是用大模型进行预标注，我使用的是qwen-max或者qwen-turbo，选择的时候只是选择大的，但是没有关注模型架构之类的。

       “构造合适的prompt，然后找一个比较靠谱的大模型，建议最好14B以上的模型，一般而言是越大越好，我自己的经验是比较喜欢用“Qwen3-235B-A22B-Instruct-2507”，当然小一些的类似“Qwen3-30B-A3B-Instruct-2507”也是不错的。很建议用这种MoE的模式，性价比还挺高的。”

        “然后是预标注，这个就比较简单了，把前面的内容梳理完，配合输入信息，都交给大模型就好了。这里一个细节是对大模型的选型，这里一定要选比较靠谱，效果稳定的大模型，资源充足的话最好能大一些，下限高一些的，这里的标注好坏很大程度就靠这个大模型了，所以，嗯，对自己好点。”

        这里引出一个疑问，关于模型的选型，不同架构的模型，对于不同任务的执行（相同prompt、参数大小）会有什么领域局限吗？（后续我查了些资料，做了一个小的总结，感兴趣的朋友可以看看：https://ai.feishu.cn/wiki/PmVkwBqIfishGDkq1otcPoaFnp6?from=from_copylink）

        博客中博主给了他的经验供学习参考：

“有关标注大模型的选型上，有这几个建议。

• 建议用更大的模型，效果真的会更好，标注这个任务对准确程度要求高。

• 我这里推荐的都MoE模型，主要是因为MoE模型的效果相比非MoE模型效果差距小，然而推理性能又比非MoE强，所以很适合。

• 我这里选的都是Instruct模型，并非thinking，主要原因是前者更快，没有别的原因了。这里还有个选择的参考思路，Instruct模型的实际召回率会偏高，而thinking的准确率会偏高，这个是经验值，大家可以根据自己的实际情况进行选择。

• 如果担心效果不好，可以多选几个大模型，分别跑比对着看。”

        虽然给了具体的类目体系，但是仍然会出现标注错误的情况，而且因为模型生成的不稳定性，多跑几遍就会发现，可能出现这样的情况：对于某些事件，模型多次标注的类目不同。所以这就需要复核，这里我实习的时候是人工复核，排查是否是prompt写的不规范、模糊，又或是类目定义的问题。

博客中说：

        “这里，有大模型复核和人工复核，前者是给后者减轻压力的，虽说标注和复核都是大模型，但是复核和标注在大模型视角看是割裂的，所以相对而言还比较中立，因此质量一般不会太低。”

        这么看来，如果选择一个较大的模型来复核是可行的，但博客后续也强调了，尽管是可行的，但是不能完全信任大模型，大模型的复核只是减轻压力的，而且既然是大模型复核，难免会出现偏差和不可控，一旦出错，就会是一大片一大片的出现，因此人工复核是必不可少的。

        “需要自己拿100-200个case再看看，弄一个人工标注的预标注准确率，留意有没有很统一的错误，确认预标注质量，只有达到够高的标准（例如文本分类大概是90%+），才能说这个标注数据集是可靠的（注意，这里哪怕全都是人工标，达到90%都是不简单的）。”

        我在实习的时候，只是一遍遍的复核、修改prompt、跑数据，并没有弄这个人工标注的预标注准确率，但也确实关注的是统一的错误，也就是大模型标注在某一类出现较多错误的时候，会集中排查是数据本身的问题，还是prompt的问题，当然一般都是prompt的问题。而对于一些数量少的标注错误，一般归为大模型标注的不稳定。

大模型标注的缺点

        这里博主明确做了点列：

        “标注要足够质量，基本避不开足够大的模型，成本肯定高，要用更大的模型，那成本就更高。  

        留意召回率相关的指标。前文虽有提到Instruct模型的实际召回率会偏高，但这个偏高是相对thinking而言的，实际召回率仍旧偏低，建议大家多检查召回率，这个指标平时很容易忽略。

        人工标注量少了以后，大家对数据和实际任务的理解会大幅降低，后续的调优会出现一些隐性的困难，所以我仍旧建议大家还是要做人工复核，借此机会减少这种情况的出现。”

        召回率确实是我实习的时候没有关注到的，常常只检查准确性。对于标注任务的召回率和准确率，如果有不太熟悉的朋友可以看看：https://ai.feishu.cn/wiki/AR4WwsaksiRAhUkj3MdcUGponue?from=from_copylink

        对于第三点，非常赞同，只有在数据标注复核的过程中，才能更了解数据，同时更有效修改prompt。

从流程到经典实践

我在网上找了一些典型的“利用大模型进行标注”的案例来辅助学习：

案例一：教育领域作文智能批改

传统痛点：人工批改英语作文平均需3分钟/篇，且评分标准不一。

标注流程实践：

        构建标注库：预先对100篇高分范文进行精细标注，定义“字母大小一致性”、“间距均匀度”、“语法准确性”等10个具体维度。

        AI自动比对：学生作文上传后，系统自动与标注库标准比对，生成结构化评分报告（比如：“字母间距-8/10分，建议增加0.5字符间距”）。

        人机协同审核：教师只需重点复核AI结果，处理复杂争议。

案例二：医疗领域智能导诊优化

传统痛点：患者症状描述模糊（如“肚子疼”），导致智能导诊科室推荐错误率高达30%。

标注流程实践：

        构建专业知识库：标注5000例真实病历，建立精细化的“症状-科室”映射标注库。

        交互式引导标注：通过设计好的交互流程，主动引导患者补充关键信息（如疼痛部位、持续时间）。

        动态权重调整：根据症状严重程度与特异性动态调整标注权重。

案例三：对话系统数据标注

承接大模型标注的通用七步闭环，对话系统的数据标注有其独特的复杂性。

它不再是简单的文本分类，而是涉及对动态交互过程的理解与结构化。

意图识别标注

        标注任务通常从线上日志、线下导入、黄金测评集三种来源创建。可基于时间、用户满意度（点赞/点踩）、机器人回复类型等条件筛选数据。

        AI辅助与人工复核：利用大模型进行预标注，人工再进行复核。

核心难点：

意图边界模糊：用户问法常包含多个子意图（如“查询订单并修改地址”），需制定规则明确是标注为复合意图还是拆分。

问法多样性：覆盖同一意图的海量不同表达，对数据收集的广度和持续性要求高。

情感标签标注

        通常采用正面、负面、中性的三级体系。需明确定义每类情感在业务语境下的具体标准，例如包含正负两面评价的文本通常标为“中性”。

核心难点：

        上下文依赖与讽刺识别：情感高度依赖语境，识别反讽等复杂现象对标注员能力和标注指南的细致度挑战大。

        标注者间一致性：情感的主观性导致不同标注员判断可能不同，实现高水平的标注者间一致性（如通过Cohen‘s Kappa系数衡量）是关键难点。

        多标签与强度标注：细粒度分析中，一段文本可能蕴含多种情感或需标注强度，这大大增加了复杂度和成本。

为了更清楚大模型是怎么根据指令来进行标注，以下是一个用于对话意图与槽位联合标注的Few-shot Prompt示例，它包含了角色定义、分类体系、槽位说明、输出格式和具体示例：

你是一个智能客服对话数据标注助手。你的任务是对用户的单轮查询进行细粒度意图分类，并提取关键信息（槽位）。

【分类体系定义】
- 查询物流状态：用户询问订单的配送进度、当前位置、预计送达时间等。
- 申请售后服务：用户发起退货、换货、退款、维修等请求。
- 咨询商品信息：用户询问商品的价格、规格、库存、功能等属性。
- 其他：不属于以上任何一类。

【槽位定义】
- 订单号：一串由数字和字母组成的唯一标识符。
- 商品名称：用户提及的具体商品。
- 问题描述：用户对商品或服务问题的具体叙述。
- 联系电话：用户的手机号码。

【输出格式要求】
你必须严格按照以下JSON格式输出，且只输出此JSON对象：
{
  "intent": "意图类别",
  "slots": {
    "order_id": "提取到的订单号，若无则留空字符串",
    "product_name": "提取到的商品名称，若无则留空字符串",
    "issue_desc": "提取到的问题描述，若无则留空字符串",
    "phone_number": "提取到的联系电话，若无则留空字符串"
  }
}

【示例】
输入：我的订单SF123456789到哪了？今天能送到吗？
输出：{"intent": "查询物流状态", "slots": {"order_id": "SF123456789", "product_name": "", "issue_desc": "", "phone_number": ""}}

输入：刚买的手机屏幕碎了，想申请维修。
输出：{"intent": "申请售后服务", "slots": {"order_id": "", "product_name": "手机", "issue_desc": "屏幕碎了", "phone_number": ""}}

输入：这个冰箱的耗电量是多少？
输出：{"intent": "咨询商品信息", "slots": {"order_id": "", "product_name": "冰箱", "issue_desc": "耗电量是多少", "phone_number": ""}}

现在，请对以下用户查询进行标注：
输入：{user_query}
输出：