收集偏好标注

两次训练的回答配成偏好对 → Argilla 人工标注 → 拉回来变成 DPO 训练数据

LLM-as-judge 能自动打分，但有些判断只有人做得了。这条链把人的判断变回训练数据。

​

平台做哪一段

标注界面、标注权限、标注进度、多人一致性——全是 Argilla 的事。重造一遍是另一个产品的量级，平台不做。

平台做的是 Argilla 做不了的两端：

1. 出：配对

   「同一批 prompt 上，A 模型和 B 模型分别答了什么」——这个问题只有平台答得出来， 因为两次训练的验证样本都在它手里。

2. （中间：Argilla）

   人在 Argilla 里逐条选「A 更好 / B 更好 / 分不出」。

3. 回：还原成训练数据

   标完的偏好拉回来，变成 prompt / chosen / rejected 的 DPO 数据， 落成平台数据集的一个新版本，下一轮训练直接引用。

​

用起来

sf annotate status                              # 先确认接入配好了
sf annotate push <RUN_A> <RUN_B> --limit 200    # 配对并推去标注
# …人在 Argilla 里标…
sf annotate pull forge-<RUN_A>-vs-<RUN_B> --into qa-preference

最后一步会把偏好数据落成 qa-preference 的一个新版本，走的是和 sf dataset push 完全相同的链路——同一套版本不可变、指纹、质量报告。之后：

# 下一轮 DPO 实验的 config
data:
  train:
    dataset: alice/qa-preference@20260828-120000

​

几个刻意的取舍

必须给两个 run。偏好标注问的是「A 和 B 哪个更好」；单次 run 的样本只能打分，做不了偏好——而 DPO 要的是偏序。

按 prompt 对齐，不按样本序号。两次验证的采样顺序不保证一致，按序号配对会把 A 的第 3 题和 B 的第 3 题当成同一题，标出来的偏好毫无意义。

A/B 的顺序与 run 无关。如果 A 永远来自同一个 run，标注者会很快认出风格并产生系统性偏向。顺序由 prompt 决定——稳定（同一条重开还是同一个顺序）但与 run 无关。

两边答案完全相同的对会被丢掉。让人在两个一模一样的回答之间选，只会消耗标注预算并产生随机噪声。

「分不出 / 都不行」不产出训练数据。DPO 要的是偏序，把持平的对硬塞进去等于给模型一个假信号。跳过了多少条会打出来，免得你以为数据丢了。

​

管理员：接入配置

FORGE_ARGILLA_URL: "http://argilla.internal:6900"
FORGE_ARGILLA_API_KEY: "<argilla 的 API key>"
FORGE_ARGILLA_WORKSPACE: "argilla"     # 默认值，workspace 要先在 Argilla 里建好

Argilla 的地址是部署级设置，与数据库地址、对象存储地址同一信任级别——内网部署里它本来就在私网上。 所以这里不套用 webhook 那套「拒绝私网地址」的规则：那套规则是为用户填的地址准备的， 照搬过来只会让这个集成在内网里根本连不通，而内网正是它唯一会被部署的地方。