数据源头治理：Prompt设计规范与数据采集策略

大家好，我是你们的老朋友。今天咱们聊聊RLHF管线里最容易被忽视、但代价最高的一环——数据源头治理。

说白了，就是怎么在数据还没进标注管线之前，就把那些「脏数据」、「坏数据」挡在门外。我见过太多团队，标注费花了几十万，结果模型训出来效果还不如基座模型。为什么？因为数据源头就烂了。

你想想看，标注工人再认真，也架不住Prompt本身就有歧义。所以今天，我把自己踩过的坑、总结的规范，全盘托出。

一、Prompt设计规范：从源头掐断歧义

1.1 为什么Prompt设计是源头治理的第一道防线？

我刚开始做RLHF时，犯过一个低级错误。当时设计了一个Prompt：「请评价这段文本的质量」。结果标注员A理解为「语法正确性」，标注员B理解为「信息丰富度」，标注员C理解为「是否有趣」。同一个Prompt，三个人三种理解。你说这数据能用吗？

所以，Prompt设计的核心目标只有一个：消除歧义，让不同标注员对同一任务的理解高度一致。

1.2 Prompt设计五原则

我在项目中总结了一套「Prompt设计五原则」，分享给大家：

原则	说明	反面案例	正面案例
1. 任务明确	标注员一看就知道要做什么	「评价这段文本」	「请判断这段文本是否包含事实性错误，并指出具体错误位置」
2. 标准可量化	评价维度要有具体标尺	「这段文本质量高吗？」	「请从准确性(1-5)、流畅性(1-5)、信息密度(1-5)三个维度打分」
3. 示例引导	给出正反示例	无示例	「好的例子：...；差的例子：...」
4. 边界清晰	明确什么情况算、什么不算	「标注所有错误」	「只标注事实性错误，不标注语法错误」
5. 避免诱导	不要暗示「正确答案」	「这段文本明显有问题，请指出」	「请客观评价这段文本」

1.3 实战：一个Prompt的迭代过程

我记得有一次做「对话质量评估」任务。第一版Prompt是这样的：

请评估以下对话的质量。

结果可想而知，标注一致性只有0.3。后来我改成了这样：

任务：评估客服对话的解决率
标准：
- 1分：问题未解决，客户不满意
- 2分：问题部分解决，客户仍有疑问
- 3分：问题完全解决，客户明确表示满意

示例：
好的对话（3分）：
客服：您好，请问有什么可以帮您？
客户：我的订单还没到。
客服：我帮您查一下物流信息...您的订单预计明天到达。
客户：好的，谢谢！

差的对话（1分）：
客服：您好，请问有什么可以帮您？
客户：我的订单还没到。
客服：请稍等...（长时间无回复）
客户：喂？还在吗？

改完之后，标注一致性直接提升到0.75。你看，差别就这么大。

二、数据采集策略：别让垃圾数据进门

2.1 数据采集的「三不原则」

我经常跟团队讲，数据采集要守好「三不原则」：

• 不采来源不明的数据：爬虫数据、二手数据，质量不可控，慎用
• 不采分布失衡的数据：比如90%都是正面评价，模型学不到「拒绝」能力
• 不采超出任务范围的数据：做客服对话，别采闲聊数据

2.2 数据质量预检流程

数据进入标注管线之前，我建议做三轮预检：

1. 格式预检：检查字段完整性、编码格式、特殊字符
2. 内容预检：随机抽检5%-10%的数据，看是否有明显错误
3. 分布预检：统计标签分布、长度分布、主题分布

这里给一个简单的预检脚本示例：

import pandas as pd

def data_precheck(df):
    # 1. 格式预检
    print(f"总样本数：{len(df)}")
    print(f"缺失值：{df.isnull().sum().to_dict()}")
    
    # 2. 内容预检
    sample = df.sample(frac=0.05)
    # 人工检查这5%的样本
    
    # 3. 分布预检
    print(f"标签分布：{df['label'].value_counts().to_dict()}")
    print(f"文本长度分布：\n{df['text'].str.len().describe()}")
    
    return True if len(df) > 1000 else False

2.3 数据采集的「黄金比例」

我个人的经验是，数据采集要遵循一个「黄金比例」：

数据类型	占比	说明
核心场景数据	60%	直接对应业务场景的高质量数据
边缘场景数据	25%	覆盖边界情况、异常情况
对抗样本数据	15%	故意构造的、容易让模型出错的数据

为什么要留15%给对抗样本？因为模型在真实场景中遇到的「坏情况」，往往比我们想象的要多。提前在训练数据里加入对抗样本，能显著提升模型的鲁棒性。

三、知识体系总览

下面这张图，是我对本章知识体系的总结。你可以把它当作一个「检查清单」，每次做数据采集时对照着看：

四、避坑指南：我踩过的那些坑

五、总结

数据源头治理，说白了就是一句话：别让坏数据进门。与其花大量精力在标注后清洗数据，不如在数据进入管线之前就把好关。

我个人习惯，每次启动一个新项目，都会花至少一周时间做「数据源头治理」：设计Prompt、做预检、调整采集策略。这一周看起来是「浪费」的，但后面节省的时间是十倍百倍。

嗯，今天就聊到这里。记住：数据质量不是标注出来的，是设计出来的。

---