Argilla 标注分歧：多人独立评分与仲裁结果怎么保留

草稿与核验材料准备

本题解决的是：两位编辑对同一篇 AI 草稿意见不同，怎样既留下各自的理由，又整理出可用于评测的最终判断。建议把数据分为草稿、独立响应、仲裁记录三层，最终标签只作为派生结果，不覆盖前两层。

资料边界：Hugging Face 官方博客索引列有 2024 年 11 月 4 日的 Argilla 2.4 数据集建设条目，以及 2024 年 3 月 4 日的社区协作数据集条目。现有材料只有索引，不能据此确认当前版本、按钮位置、多人响应权限、分歧筛选或导出行为。下文量表、阈值和字段均为本文建议的业务原型，不是官方默认规范。

1. 选一小批经过授权的草稿，移除姓名、联系方式、客户标识及其他不必要的敏感内容。可按写作资料提交前的隐私清理流程整理脱敏副本。
2. 为每篇分配稳定的 sample_id，并记录 draft_version、任务要求、脱敏正文、证据包编号和证据版本。正文一旦修改，应新建版本，不让旧评分自动对应新稿。
3. 指定独立评审者和仲裁负责人。评审者使用不同账号或独立记录入口，不共用一个身份提交。
4. 为评分规则登记 rubric_version。先用校准样例讨论标准，再对正式样本独立评分；校准讨论记录不混入正式独立响应。

事实表达与发布判断

不要用“整体不错”代替各维度评价。下面采用三档量表作为起点，分数越高表示该维度越符合要求。事实性以同一证据包为依据；无法核验时另记状态，不把未知强行折算为低分或高分。

示例锚点：假设材料写“部分试点计划下月开放”，草稿却写“全部用户已经可以使用”。按本文规则，事实性应判为 1，因为对象范围与时间状态都改变了；即使句子流畅，也不能据此判为可发布。相反，事实全部对应材料但同一段反复解释同一概念，可以给事实性 3、表达 2，并选择修改后重新审核。

Argilla任务能力核对

以下 JSON 是开发者自定义的任务规格，用于与当前部署的 Argilla 配置逐项映射，不是 SDK 请求体，也不能直接导入。字段名、题型、条件必填、响应读取和权限实现必须在当前版本文档中另行确认。

{"task_name":"editorial_review_v1","rubric_version":"r1","input_fields":["sample_id","draft_version","task_requirements","draft_text","evidence_bundle_id","evidence_version"],"questions":[{"name":"fact_status","choices":["assessable","insufficient","not_applicable"]},{"name":"factuality","choices":[1,2,3],"required_when":"fact_status=assessable"},{"name":"expression","choices":[1,2,3]},{"name":"publish_decision","choices":["publish","revise","reject","hold"]},{"name":"review_reason","required":true}],"workflow_requirements":{"independent_reviewers":2,"hide_peer_answers":true,"preserve_original_responses":true}}

1. 记录实际服务端与客户端版本，从索引中的相关条目继续定位正文及对应版本文档。不要把历史文章中的 2.4 当成当前部署版本。
2. 核对输入文本字段、评分或单选问题、理由文本题的实际配置方法，并建立业务字段到实际字段的映射表。
3. 核对两人能否对同一记录分别响应、提交前能否看到他人答案，以及所用权限下谁能读取全部响应。未确认隔离能力前，不开始正式独立评审。
4. 核对响应是否能带回评审者标识、问题值、状态和时间信息，导出是否保留多人的原始响应，而非只返回聚合标签。
5. 用非敏感样例完成导入、双人提交、读取、导出和重新解析的往返验证。条件必填或隔离能力无法满足时，先在受控表格或业务层实现对应约束，并记录未接入项。

目前可以先完成评分表和数据结构；只有上述版本映射及往返验证完成后，才能称为已接通的 Argilla 人工评测任务。

独立响应与仲裁记录

1. 收集双方独立答案，确认身份、必填理由和版本一致后冻结本轮快照。少一份有效响应应进入待补评，不算双方一致。
2. 按预先约定的规则筛出争议。本文建议：任一可比较维度分数不同、发布决定不同、事实可判断状态不同，均进入复核；分差达到 2 可排在队列前部。规则应由团队确认并版本化。
3. 仲裁者先读任务、原稿和材料，再查看双方的争议原句与理由，区分材料不足、规则歧义、漏读证据和表达偏好。
4. 材料不足就记 pending_evidence；规则不清就先补充锚点，并按新规则开新轮次复评。不要用多数票把未知事实变成已确认事实。
5. 材料与标准足够时，按维度给出最终判断，注明采用或否定双方理由的依据。保留原始异议，并把有代表性的边界样例加入后续校准材料。

标注一致性应从仲裁前的独立响应计算。最小报告可列出各维度完全一致的样本数、可比较样本数、待补评数和材料不足数；不要把仲裁后的相同标签用于宣称独立评分一致。

虚构样本关联检查

下面是业务结构示例，不是平台输出或执行记录。假设草稿 s001 的 v1 版本就是前述把“部分试点计划开放”改成“全部用户已可使用”的句子，材料版本为 e1，规则版本为 r1。

{"sample_id":"s001","draft_version":"v1","evidence_version":"e1","rubric_version":"r1","round_id":"round1","independent_responses":[{"response_id":"r001","reviewer_id":"editor_a","fact_status":"assessable","factuality":1,"expression":3,"publish_decision":"revise","review_reason":"材料只说明部分试点计划开放，草稿扩大范围并改变时间状态。"},{"response_id":"r002","reviewer_id":"editor_b","fact_status":"assessable","factuality":2,"expression":3,"publish_decision":"revise","review_reason":"注意到时间偏差，但把范围变化视为局部问题。"}],"adjudication":{"adjudication_id":"a001","adjudicator_id":"editor_c","response_refs":["r001","r002"],"status":"resolved","final_scores":{"factuality":1,"expression":3},"final_decision":"revise","evidence_refs":["bundle_demo:item1"],"adjudication_reason":"范围与时间均属于关键事实，按 r1 的冲突锚点判为 1。"}}

这里发布决定相同，但事实性仍存在分歧，不能只筛选“是否可发布”。导出后应能同时找到 r001、r002 和 a001，而不是只剩最终的事实性 1。后续修稿生成 v2 时，应另开评审，不把 v1 的仲裁当成 v2 的通过记录。

流程故障排查

评测集发布验收

建议业务层交付三张关联表或等价的嵌套结构：samples 保存输入快照，responses 保存全部独立响应，adjudications 保存仲裁历史。JSONL 或拆表 CSV 是交付格式建议，不代表平台已确认支持的原生导出选项。

• 发布前确认授权、脱敏和访问范围；评审者使用化名标识，身份映射另行受限保存。
• 逐项核对样本数、不同评审者数、有效响应数、待补评数、争议数、已裁定数和未决数，不能只核对最终标签行数。
• 确认每条响应能回到同一草稿、材料、规则和轮次；缺失值、无法判断与最低分保持不同含义。
• 确认所有仲裁保留响应引用、证据定位、理由、负责人和实际裁定时间；示例不冒充生产记录。
• 确认未裁定样本不进入确定标签子集。保留一致样本与争议样本的来源标记，避免把只含难例的子集当成整体质量代表。
• 重新解析导出文件，抽查一条一致样本、一条分歧样本和一条材料不足样本，确认中文、数组、多人的答案及状态没有丢失。
• 需要划分训练和评测数据时，按原始稿件或来源组划分，使同稿不同版本不跨集合；评测标签和仲裁理由不进入待评模型的输入。
• 归档导出时间、实际工具版本、字段映射、筛选规则和数据版本。任何检查未通过，先交付问题清单，不标记为可发布评测集。

下一步先用非敏感样例核对当前版本的问卷、响应读取和导出接口，再做小批往返验证。验收目标不是把所有编辑变成同一个分数，而是让每次独立判断、分歧处理与最终标签都能追溯到同一份输入和明确依据。