Open-Assistant 排名任务指南如何高质量完成 Assistant 回复排序Rank Assistant Replies【免费下载链接】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 数据收集体系中的核心环节之一。本文基于仓库中 排名任务说明文档 展开结合后端源码、数据模型、评价准则与后处理脚本完整讲解Assistant 回复排名任务的评判标准、操作步骤、数据提交格式及其在整个模型训练数据流水线中的作用。读者读完后将掌握该任务的排序原则、界面操作要点、后端校验逻辑以及排名数据如何被写入数据库并用于后续的偏好学习。任务概览给一段对话的多个 Assistant 回复排出优劣次序在该任务中页面会展示一段用户与助手的对话conversation并在下方给出至少 2 条 Assistant 回复——这些回复并非来自真实模型而是由扮演助手角色的人写出的候选消息。参与者的工作就是依据 Open-Assistant 的写作与标注准则guidelines把候选回复从最好到最差排出次序第一条为最优最后一条为最差。这一任务直接服务于RLHF人类反馈强化学习中的人类偏好数据收集模型的回答质量没有绝对分数但哪条回复更好这种相对偏好却可以被可靠地标注进而转化为训练排序/奖励模型所需的数据。在任务体系中它属于rank_assistant_replies类型。从 共享协议定义 可以看出它与rank_prompter_replies对用户回复排序同继承自RankConversationRepliesTask二者共享conversation、replies、reply_messages、message_tree_id、ranking_parent_id、reveal_synthetic等字段class RankConversationRepliesTask(Task): A task to rank a set of replies to a conversation. type: Literal[rank_conversation_replies] rank_conversation_replies conversation: Conversation # the conversation so far replies: list[str] # deprecated, use reply_messages reply_messages: list[ConversationMessage] message_tree_id: UUID ranking_parent_id: UUID reveal_synthetic: bool class RankAssistantRepliesTask(RankConversationRepliesTask): A task to rank a set of assistant replies to a conversation. type: Literal[rank_assistant_replies] rank_assistant_replies在后端持久化层db_payload.py 中的RankAssistantRepliesPayload同样继承自RankConversationRepliesPayload将上述任务负载以 JSON 形式存入 Task 表并保留ranking_parent_id本次排序所针对的那条上一条消息与message_tree_id对话树标识用于将排序结果挂回正确的树节点。排序的核心准则先满足请求再比细节排名并非凭个人喜好而是有明确优先级。原文档明确指出首要标准是回复必须满足前一条提示prompt提出的请求并且不包含事实性错误除非用户明确要求。在此基础之上再依据准则中的其他方面决定回复的先后顺序。这与 标注准则文档 中第 6 节 Ranking assistant replies 的条目完全对应应该做Do务必读完全部候选回复不要只看开头思考哪条回复最能满足用户的请求以对准则的贴合程度排序事实准确性与有用性永远排在第一位对**缺乏必要的警告或提示warnings/caveats**的回复给予降级例如涉及安全、健康、法律等场景时未给出风险提示对因缺乏排版、大小写错误等原因而难以阅读的回复给予降级对大量冗余细节淹没关键信息的回复给予降级如果冗长内容占据了消息的很大一部分反而干扰用户获取请求的信息坦诚承认自己不知道答案的回复排在事实错误之上、事实正确之下即承认无知 胡说八道但 正确回答。不要做Dont不要依据个人信念评判回复质量——只要该观点是被用户请求所允许的、满足了用户请求且不违反准则就不应影响排序不要依据回复长短来排序——应当判断哪条回复真正回答了用户的问题而不是哪条写得更长或更短。提示在正式开始标注前请完整阅读 标注准则尤其是第 6 节并参考 任务总览 了解整个任务家族。界面操作要点展开完整回复两两比较在排序界面上每条候选回复旁边会有一个...符号。原文档特别提醒如果回复内容超出了初始显示区域点击每条回复右侧的...即可展开查看完整消息。很多回复的优劣差异往往体现在后半部分只凭开头排序很容易出错。不要只排出最好与最差的两端就提交需要把每一条回复都与其他回复逐一比较最终确定一个完整、有序的排列。候选数量至少为 2通常更多排序结果必须覆盖全部候选。这一交互在 Discord 机器人中也有对应实现任务模板 task_rank_conversation_replies.msg 会按顺序列出对话与候选回复并要求用户以由好到差、逗号分隔的序号回复例如4,1,3,2Here is the conversation so far: :robot: Assistant: ... :person_red_hair: User: ... Rank the following replies: 1: ... 2: ... :scroll: Reply with the numbers of best to worst prompts separated by commas (example: 4,1,3,2).数据提交格式与后端校验每个下标必须恰好出现一次排名结果以最好在前、最差在后的索引列表提交索引对应候选回复的展示顺序0 起。后端在 prompt_repository.py 中对该提交做了严格的合法性校验case db_payload.RankPrompterRepliesPayload | db_payload.RankAssistantRepliesPayload: # validate ranking if sorted(ranking.ranking) ! list(range(num_replies : len(task_payload.reply_messages))): raise OasstError( fInvalid ranking submitted. Each reply index must appear exactly once ({num_replies})., OasstErrorCode.INVALID_RANKING_VALUE, )即排序列表必须恰好包含 0..N-1 每个下标一次N 为候选回复数量不允许重复、遗漏或越界否则会抛出INVALID_RANKING_VALUE错误。随后后端会取对话最后一条消息作为排序的父节点parent_msg将ranking.ranking映射为ranked_message_ids[task_payload.reply_messages[i].id for i in ranking.ranking]逐一校验每个被排序消息的parent_id必须等于父节点 ID否则抛出CORRUPT_RANKING_RESULT为每个被排序消息的ranking_count自增 1该计数用于后续统计与筛选构造 RankingReactionPayload 写入 Reaction 表其中包含ranking排序下标、ranked_message_ids对应的消息 UUID 列表、ranking_parent_id、message_tree_id以及可选的not_rankable标记当所有候选都有缺陷、事实错误或不可接受时使用。该反应数据即为人类偏好的原始证据同一父消息下的多次message_ranking反应构成了后续计算共识排序与标注员质量评估的输入。排名数据的用途从人类偏好到共识排序排名数据不只会被存储还会被后处理脚本进一步利用。scripts/postprocessing/rankings.py 实现了经典的两两对决head-to-head投票聚合对同一条父消息下的多条候选回复统计候选 A 排在候选 B 之前的次数形成胜出矩阵再通过ranked_pairs方法Tideman 方法合成一个满足一致性的总体排序。而 ranking_disagreement.py 则进一步做质量分析对每个父节点拥有 ≥2 个子消息的节点汇总所有标注员的排名结果用ranked_pairs计算共识排序consensus将每个标注员的个人排序与共识排序计算Kendall Tau 相关系数从而衡量标注员之间的分歧程度并定位偏离共识的标注员脚本注释同时提醒候选数较少的排名更可能出错这在解读统计结果时需要留意。从源码结构看这类共识排序可用于筛选高质量子树、检测标注一致性并支撑后续的奖励模型RM训练数据整理结合 模型训练 中的trainer_rm.py与rank_datasets.py可以推断排名反应最终会进入偏好数据集的构建流程。常见误区与质量自检清单综合原文档与准则提交前请自检检查项说明已读完全部回复使用...展开长回复避免只看摘要满足用户请求回复是否完整回应了提示中的诉求事实准确性优先事实错误应排在最后承认未知优于编造已做两两比较排序覆盖所有候选而非只定首尾安全与警示涉及风险场景时缺少警告/caveats 的回复应降级可读性排版混乱、大小写错误、冗余淹没重点的回复应降级不代入个人信念只要观点合理且满足请求就不应因立场降级不按长短排序长 ≠ 好短 ≠ 差看是否切中问题要害格式合法提交的序号列表恰好包含每个候选下标一次总结Rank assistant replies 是 Open-Assistant 构建高质量偏好数据的关键任务。它要求标注者在通读完整对话与全部候选回复后以满足用户请求 事实准确为第一准则、结合可读性/警示/冗余等次要维度给出全序排列后端以RankAssistantRepliesTask→RankAssistantRepliesPayload→RankingReactionPayload的链路完成任务的派发与结果的严格校验最终这些message_ranking反应经 rankings.py 与 ranking_disagreement.py 聚合为共识排序成为 RLHF 训练数据的重要组成部分。对每一位参与数据贡献的标注者而言认真、一致地完成每一次排序就是在为更可靠、更有用的开源对话助手模型提供最直接的反馈信号。【免费下载链接】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），仅供参考