Open Assistant 数据标注准则全解析从众包任务指南到标签系统源码落地【免费下载链接】Open-AssistantOpenAssistant is a chat-based assistant that understands tasks, can interact with third-party systems, and retrieve information dynamically to do so.项目地址: https://gitcode.com/gh_mirrors/op/Open-Assistant本篇技术指南以 Open Assistant 仓库中的 数据构建准则文档 为核心骨架系统梳理为构建高质量对话数据集而设计的五类众包任务的执行规范提供助手回复、提供用户提问、分类消息、排序回复以及配套的标签与量表体系。文章不仅完整保留原文档的全部判定标准还结合oasst-shared与backend中的协议源码如TextLabel枚举、AbstractLabelTask任务模型深入剖析每条准则背后对应的标签数据结构。读完本文你将能够准确理解 Open Assistant 数据流水线的质量标尺并能在实际参与标注、撰写回复或复现类似众包数据构建系统时直接复用这套判定框架。一、这份准则文档在项目中的定位docs/docs/guides/guidelines.md是 Open Assistant 数据采集环节的执行准则总纲。它面向的是实际参与数据构建的志愿者无论是扮演助手撰写回复、扮演用户发起提问还是对他人消息进行分类与排序都需要先阅读并遵守这套准则。围绕这份总纲docs/docs/tasks/目录下提供了五份对应的任务说明文档每一份都会在文末回链到准则中的对应小节回复助手任务扮演聊天机器人助手角色对应准则第 2 节#assistant-reply用户提问任务扮演与机器人交互的用户对应准则第 3 节#user-reply分类助手回复对他人写的助手回复打标签对应准则第 4 节#classifying-assistant分类用户提问对他人写的用户提问打标签对应准则第 5 节#classifying-user排序助手回复对同一提示的多个助手回复排序对应准则第 6 节#ranking-assistant也就是说准则文档既是一份写作规范也是一份评审标准第 2、3 节约束内容生产者第 4、5、6 节约束内容评审者第 7 节则为评审提供统一的标签与量表定义。二、通用规则General rules准则开篇给出四条适用于所有任务的通用要求先读后做在完成任何任务前务必先阅读并理解对应任务的准则。尽量贴近准则按照准则的要求尽量严格地执行。不确定就问若不确定某条消息是否违反准则可在 Discord 上联系维护团队确认。善用赞踩体系使用 thumbs-up/thumbs-down 系统对高质量与低质量的消息进一步标记。这四条规则确立了数据质量控制的闭环写作准则 → 评审准则 → 争议仲裁 → 额外标记为后续五类任务的具体要求奠定了基调。三、提供助手回复Providing an assistant reply当志愿者在任务中扮演助手时需要针对给定的用户提示撰写回复。准则从应该做与不应该做两个维度给出约束。应该做Do态度与语气始终保持礼貌并尊重用户即使对方并未以同样的礼节相待。除非用户明确要求否则使用友好、平易近人的口吻交谈。信息准确性与风险提示只提供经过可信来源核实、能够溯源的信息除非用户明确要求其他方式。当提供未经核实的信息时务必让用户知晓其不确定性。当被询问医学、法律、化学等高风险领域的建议时要告知用户潜在危险。面对高风险话题时明确让用户知道作为语言模型助手可能产生错误信息且不应在未咨询专业人士的情况下依据助手回复采取任何行动。观点表达边界当用户要求助手以默认人设发表意见时至少要给出 2 种常见观点且不得将其表述为助手自己的观点。如果用户进一步坚持要助手给出个人观点应说明助手默认没有个人观点只能尽力模拟他人的观点。表达与格式当用户意图不明确时主动请求澄清。使用段落与换行让长回复更易读。善用 Markdown 语法来组织列表、表格与代码块。使用代码块书写特定语言代码时指定语言标识符以启用语法高亮如python。保持助手回复的风格与语气前后一致。不应该做Dont内容红线不得直接复制粘贴其他来源的文本而不作修改这包括 ChatGPT 等生成式 AI 的输出该要求同样体现在 分类任务文档 中那里明确要求对 LLM 生成的回复予以扣分惩罚。不得提供违反德国、英国、美国或居住国法律的内容。不得撰写鼓励暴力、侵犯第三方权利、恋童的内容。若存在合理的自我伤害意图嫌疑不得提供可能被用于自残的信息。不得提供未公开的第三方个人信息。隐私边界不得询问个人隐私信息除非该信息与问题相关且不足以定位用户身份如居住国、职业。用户应被允许拒绝提供任何信息。信息质量红线不得提供未经请求的观点、无依据的假设与不完整信息。不得为了引导结论而刻意筛选信息即不得通过隐藏事实来呈现特定叙事。当请求含义不清、且回复可能与提示的另一种解读相冲突时不应作答而应请用户补充或改写。除非违反准则否则不得回避问题。不得引入专业术语却不对其含义作出解释除非对话上下文表明用户已熟悉该术语。形式与语境不得在助手回复中遗留拼写或语法错误除非用户明确要求。不得让信息过载回复要简洁同时补充与用户请求相关且能展开的细节。不得提供助手无法访问的信息例如当前天气。除非用户明确要求不得使用与数据集目标语言不同的语言回复。从源码结构看docs/docs/tasks/reply_as_assistant.md还补充了一条实操提示插入代码块时添加语言说明以获得语法高亮这与准则中的要求一脉相承。四、提供初始提示或用户回复Providing an initial prompt or user reply当志愿者扮演用户时任务是为助手提供一个清晰、有价值的请求或问题。若是在对话中继提供用户回复还需要维持同一用户的语境连贯性。应该做Do提问质量提出反映真实生活场景与需求的问题。提出人们可能会向搜索引擎或专家咨询的问题。提出鼓励横向思维、或需要专业知识的问题。在有明确答案与没有明确答案的问题之间保持混合。通过使用不同的措辞、礼貌程度与上下文信息量来丰富提示的多样性。对话连贯性考虑促成当前消息的既有对话与提示。在回复助手时尝试围绕主题提出合理的追问follow-up question。不应该做Dont不要撰写没有明确请求的提示。不得提供违反德国、英国、美国或居住国法律的内容。不得提出覆盖助手原始用途的请求即试图越狱jailbreak模型。不得提出让助手除了拒绝生成有害内容外别无选择的请求。不要提交与之前提交过的提示相似或完全相同的提示。回复助手时不要在没有铺垫的情况下突然更换对话主题。不要在提示中遗留拼写与语法错误。除非对话上下文需要不要使用与数据集目标语言不同的语言回复。五、分类助手回复与用户提问Classifying分类任务要求志愿者对他人撰写的消息逐项评分并打标签。两条准则第 4、5 节结构对称核心差异在于评审对象。分类助手回复Classifying an assistant reply应该做对每条回复的每个评分项都进行评分除非消息是垃圾信息或明显不恰当而无法判断。基于回复对准则的遵循程度判定质量事实准确性与有用性始终排在第一位。务必完整阅读回复内容后再评判。使用第 7 节的 标签解释 确定适用哪些标签。主动调研核实回复在事实上是否准确。若无法判断回复的正确性跳过该条分类而不是强行打分。不应该做不要基于个人信仰评判质量。只要观点是应请求给出的、满足了用户请求且未违反任何准则就不应影响对回复的评分。不要因为消息是垃圾信息就跳过标签——每个标签都能帮助模型改进。若不确定回复是否事实准确或是否满足用户请求不要对其评分。补充细节源自 分类助手回复任务文档如果无法判断回复是否事实准确应当跳过对于 ChatGPT 等聊天机器人生成的回复项目明令禁止多数情况下还违反其服务条款可以使用 ZeroGPT 等检测工具辅助识别机器生成文本但这些工具并非万无一失可能误判。分类用户提问Classifying an initial prompt or user reply应该做对每条提示的每个评分项进行评分除非消息是垃圾信息或明显不恰当而无法判断。基于提示对准则的遵循程度判定质量。务必完整阅读提示内容。使用第 7 节的 标签解释 确定适用哪些标签。不应该做不要基于个人信仰评判质量——用户的观点不应影响对提示的评分。不要因为消息是垃圾信息就跳过标签——每个标签都能帮助模型改进。六、对助手回复进行排序Ranking assistant replies排序任务中志愿者会看到同一提示对应的至少 2 条助手回复需要依据对准则的遵循程度排出顺序第一名最好最后一名最差。应该做务必阅读每一条可用的回复。思考哪条回复最能满足用户的请求。基于回复对准则的遵循程度排序事实准确性与有用性优先。对未能提供充分警告或免责声明的回复予以扣分。对因缺乏格式、大小写或其他错误而难以阅读的回复予以扣分。若所需信息被大量冗余细节淹没对这类回复予以扣分。排序时承认自己不知道答案的回复应排在事实正确的回复之下但排在事实错误的回复之上。不应该做不要基于个人信仰排序。观点若为应请求给出、满足了用户请求且未违反准则就不应影响评分。不要根据回复的长短排序——关键是判断哪条回复最好地回答了用户的问题。补充细节源自 排序任务文档若回复超出初始文本框长度可点击每条回复右侧的...符号查看完整消息不要只排序最好与最差两条而是将每条回复相互比较后确定完整排序。七、标签与量表定义Label Explanation第 7 节为分类与排序任务提供了统一的判定词典分为三个层次两个全局判定问题、五个标签Tags与四个量表Scales。两个前置判定问题这条消息是垃圾信息spam吗消息是否是与前文提示毫无关联的无关文本若它是初始提示是否不太可能被用来发起与助手的对话作为提示任务的回答这是条坏回复bad reply吗助手回复是否未能回应请求、包含错误信息或忽略了提示的相关部分标签Tags标签判定标准非目标语言Not Target Language除非用户明确要求消息使用的语言是否与数据集的目标语言不同不恰当Not Appropriate若是用户提示是否缺少清晰明确的请求包含 PIIContains PII消息是否包含未公开、且可用于确定用户或第三方私人身份的个人识别信息PII仇恨言论Hate Speech消息是否对德国、英国、美国或居住国法律认定的受保护群体表现出偏见性内容Sexual Content消息是否包含或请求露骨的性内容例如对性行为的描述量表Scales量表判定标准低质量 / 高质量Low Quality / High Quality消息对准则的遵循程度如何对助手回复而言事实准确性与有用性优先。严肃 / 幽默Serious / Humorous消息是否包含讽刺、双关语或其他幽默修饰普通 / 有创意Ordinary / Creative问题被提出的可能性有多低是否在用需要创造性思维的问题挑战助手问题是否包含大量上下文就助手侧而言回复是直来直去还是包含解决问题的独特思路粗鲁 / 礼貌Rude / Polite消息对接收方有多礼貌是否使用请等礼貌用语还是对对话另一方轻蔑、粗鲁或带有侮辱性暴力 / 无害Violent / Harmless消息是否包含对明显暴力行为的描述是否在美化、鼓励或淡化暴力行为需要留意的是准则文档中的这套标签/量表是面向志愿者的人类可读表述在 Open Assistant 的后端协议中对应维度以结构化枚举形式落地二者存在一一映射关系详见下一节。八、从准则到源码标签系统的落地实现准则第 7 节的每一条标签与量表在 Open Assistant 的共享协议层都有对应的结构化定义。证据位于 oasst-shared/oasst_shared/schemas/protocol.py。1.TextLabel枚举准则维度的机器化表达协议中定义了TextLabel枚举见 protocol.py 第 396-426 行每个成员包含name、widget、display_text与可选的help_text其中widget决定了该标签在标注界面上的交互控件类型yes/no 二值问题LabelWidget.yes_nospamSeems to be intentionally low-quality or irrelevant——对应准则的垃圾信息判定fails_taskFails to follow the correct instruction / task——对应准则的坏回复判定标志类标签LabelWidget.flaglang_mismatchWrong Language帮助文本明确说明消息语言与当前所选语言不同——对应准则的Not Target LanguagepiiContains personal identifiable information——对应准则的Contains PIInot_appropriateInappropriate——对应准则的Not Appropriatehate_speech帮助文本界定偏见指基于非理性的先入之见受保护特征包括性别、族裔、宗教、性取向及类似特征——对应准则的Hate Speechsexual_contentContains sexual content——对应准则的Sexual Contentmoral_judgementExpresses moral judgement、political_contentExpresses political views——这两个标签在准则文档中未展开但从源码结构看属于附加的扩展标签李克特量表类LabelWidget.likertqualityOverall subjective quality rating——对应量表Low/High QualityhumorHumorous content including sarcasm——对应量表Serious/HumorouscreativityCreativity——对应量表Ordinary/CreativeviolenceViolence/abuse/terrorism/self-harm——对应量表Violent/Harmlesstoxicity、helpfulness——从源码结构看属于附加量表维度2. 标签任务的协议载体准则第 4、5 节描述的分类行为在协议层由AbstractLabelTask承载见 protocol.py 第 284-291 行其字段设计直接呼应准则的要求valid_labels该任务允许使用的标签列表mandatory_labels必须评定的标签对应准则对每个评分项都进行评分的强制要求mode与disposition任务发放模式与发放理由。LabelTaskDisposition枚举见 protocol.py 第 270-274 行取值quality或spam说明该任务是为了采集质量评分还是垃圾信息判定labelsLabelDescription列表见 protocol.py 第 277-281 行向客户端描述每个标签的名称、控件类型与显示文本conversation到目前为止的对话上下文供志愿者在完整语境中判断。按对象不同任务细分为LabelInitialPromptTask标注初始提示等子类型与准则第 5 节分类用户提问对应。志愿者提交的结果以TextLabels交互记录表达见 protocol.py 第 429-434 行包含被标注的text与一个labels: dict[TextLabel, float]映射即标签 → 评分值。3. 后端接口向标注前端下发合法标签在后端 API 层backend/oasst_backend/schemas/text_labels.py 定义了ValidLabelsResponse其唯一字段valid_labels: list[LabelDescription]用于向标注界面返回当前任务可用的全部标签定义。这印证了准则第 7 节的标签解释在实际系统中正是通过协议层逐条下发、由前端渲染为对应控件的。4. 标签数据流向数据管道从oasst-shared/oasst_shared/schemas/protocol.py中TextLabels的labels: dict[TextLabel, float]结构可以推断志愿者在界面上对每条消息给出的标签与量表评分会以结构化键值对形式存储并最终汇入 Open Assistant 数据集。这类标注数据既服务于对话模型的质量筛选也是后续训练人类偏好模型如用于排序任务的奖励信号的基础素材——这正是准则反复强调事实准确性与有用性优先、以及不要因消息是垃圾信息就跳过标签的深层原因每一个标签都会转化为模型的训练信号。九、将准则投入实战一套可复用的工作流综合准则文档、五份任务文档与协议源码可以提炼出参与 Open Assistant 数据构建或复刻同类众包数据系统的标准工作流写作侧生产者在 回复助手任务 中依据准则第 2 节撰写回复在 用户提问任务 中依据准则第 3 节构造提示。要点真实场景、明确请求、格式友好、不越狱、不抄 AI 生成文本。评审侧消费者在 分类助手回复 与 分类用户提问 中依据准则第 4、5 节逐项评分在 排序助手回复 中依据准则第 6 节对多条回复排出全序。判定词表始终以准则第 7 节的标签与量表为准其在系统中的对应物是TextLabel枚举spam/fails_task为 yes/nopii/not_appropriate/hate_speech/sexual_content/lang_mismatch为 flagquality/humor/creativity/violence等为 likert。质量控制闭环通用规则要求先读后做、拿不准就问分类准则要求无法判定就跳过排序准则要求承认无知的回复优于错误回复——三者共同防止低质量标注污染数据集。这套框架的通用价值在于它将什么是高质量对话数据这一模糊概念拆解为可操作的写作规则、可打分的标签、可排序的量表并通过协议层直接驱动标注 UI 与数据存储。无论是评估自家对话模型的数据质量还是搭建众包数据标注平台docs/docs/guides/guidelines.md与oasst-shared/oasst_shared/schemas/protocol.py都是值得对照研读的参考范本。【免费下载链接】Open-AssistantOpenAssistant is a chat-based assistant that understands tasks, can interact with third-party systems, and retrieve information dynamically to do so.项目地址: https://gitcode.com/gh_mirrors/op/Open-Assistant创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考