onPanda：找到第一个错 token 点一下，对齐数据标注时间砍半
做过后训练数据标注的人应该都有这个体会：模型的 rollout 拿过来，90% 的内容是好的，就卡在中间某句话开始跑偏。你怎么办？要么整段重写（off-policy 了，而且累），要么多采样几条让标注员排序（贵，而且经常四条全不能用）。
这篇来自 StepFun 和厦门大学的论文（arXiv: 2609.24983）给了一个我觉得相当顺手的答案：别重写，也别排序，找到第一个出错的 token，点掉它，让模型从那里重新续写。他们把这个交互做成了工具 onPanda，受控实验里标注中位耗时比人工后编辑减少 52 个百分点，而产出数据的困惑度偏差只有 0.86 个百分点——几乎贴着模型自己的采样分布。
核心摘要
RLHF/SFT 的数据标注一直有个两难：人工后编辑质量高但慢，而且会破坏数据的 on-policy 特性；多候选排序快但覆盖率差。onPanda 把标注粒度从"整段文本"压到"单个 token"：标注员读响应时定位第一个不合适的 token，从模型自己的 top-k 候选里选一个替换（候选不行就手动输入），系统截断后续内容重新生成，循环直到满意。由于最终响应里 97.0% 的 token 仍由模型生成，数据天然 on-policy；而每次纠错自动记录了"错误位置 + 被拒 token + 被选 token"的三元组，白送了细粒度的偏好监督信号。受控研究显示它比后编辑快一半，认知负荷（NASA-TLX 3.1 vs 6.8）也更低。我的判断：这不是底层算法突破，但把"token 级纠错"这个交互抽象做得很扎实，工程价值大于学术价值，做数据团队的值得细看。
📖 论文信息
- 标题：onPanda: Efficient Annotation of On-Policy Alignment Data for LLMs and Agents via Token-Level Correction
- 作者：Lei Yang, Mengyin Liu, Jia Wang, Hangyu Guo, Liang Zhao, Zheng Ge, Kang An, Binxing Jiao, Qi Han, Daxin Jiang, Siqi Shen, Xiangyu Zhang
- 机构：StepFun、厦门大学
- 链接：https://arxiv.org/abs/2609.24983 ｜ 项目页：https://on-panda.github.io/research/
- 发布日期：2026 年 9 月 21 日
🎯 问题：对齐数据标注的"不可能三角"
标注一条对齐数据，你其实同时在要三样东西：
| 诉求 | 后编辑（如 POTATO） | 候选排序（如 Argilla） |
|---|---|---|
| 效率 | 差，逐字改很慢 | 快，读四条排序 |
| on-policy 保真度 | 差，人写的部分脱离模型分布 | 好，全是模型生成的 |
| 覆盖率 / 细粒度监督 | 高但无位置信息 | 低（4 条全废就没数据） |
这三样传统范式最多给你两样。后编辑的问题我之前在项目里实际踩过：人一旦上手改，就忍不住按自己的语言习惯重写，最后训出来的 SFT 数据风格跟模型采样分布脱节，PPL 一测吓一跳——论文里这个数是 36.31 个百分点的偏差，相当夸张。
排序法的问题是另一个极端：覆盖率看天吃饭，4 个候选都不合格，这个 prompt 就白跑了。实验里 Argilla 的 SFT 覆盖率只有 52 个百分点（21 个 prompt 只出了 11 条）。
onPanda 的思路说穿了就一句话：既然错误是稀疏的，那就只在出错的位置介入，其余全交给模型。
🏗️ 方法核心：locate–correct–continue 循环
交互流程看这张图最直观：
图 1：onPanda 主界面。(a) 标注员阅读响应，token 下方的颜色条编码生成概率（绿高红低），一眼定位低置信度区域；(b) 点击问题 token 弹出模型自己的 top-20 候选及概率，"shapes" 只有 9.1% 而 "triangles" 有 46.2%——但结合图片内容，标注员知道该选哪个；(c) 选中后系统截断后续内容、从修正前缀续写；(d) 候选都不够好时双击自由输入（"parallelogram" 改成 "trapezoid"）；(e) 得到最终合格响应；(f) 标注面板标记 is_good=Y 完成。
这个例子本身挑得很妙：模型说 "V" 由两个三角形组成，其实右边是个梯形。概率最高的候选 "triangles"（46.2%）恰恰是错的——所以纯靠概率自动纠错会翻车，必须有人在回路里。但人也不需要重写整段，点掉两个 token 就够了。
这个设计带来四个特性，我觉得最值得说的是后两个：
一是效率。大部分纠错是鼠标点击，只有候选不够才短暂打字。"边读边改"的线性流程避免了反复通读全文。
二是 on-policy 保真度。干预只落在少数错误位置，而且替换优先从模型自己的高概率候选里选，对采样分布扰动极小。
三是白送的细粒度监督。每次纠错自动记录三元组——负样本、被拒 token 及其位置、被选 token。位置精确、正负样本在同一位置天然配对、信号天然平衡。这个数据可以直接转成 response-level 偏好对（喂给 RM/DPO），也可以当过程奖励的原材料。说实话我觉得这才是 onPanda 最值钱的副产品：标注行为本身变成了数据采集。
四是表达能力不受限。top-k 候选不够用？双击自由输入。哪怕模型自己永远采样不出正确答案，也能注入。
系统层面的两个工程细节
工具只是交互层，背后有几个设计决定了它能不能落地。
纠错引擎。生成请求流式携带 logprobs，记录每个 token 的采样概率和 top-k（默认 20）候选。有个细节挺贴心：tokenizer 会把一个汉字或 emoji 拆成多个 token，UI 按字素边界把 token 流聚合成最小可读单元，标注员操作的是"字"而不是残缺的字节。自由编辑引入的文本没有概率信息，系统会通过一次 prompt_logprobs 请求重算整个响应的概率——顺手还把这个"刷新"功能做成了模型检查工具。
标注树与数据协议。每次纠错分叉出一个新节点，整个会话组织成一棵树：负样本通常是正样本的祖先，两者共享纠错点前缀、恰好在分叉点分离。一场会话的全部产物序列化为一个 .panda.json，配套的 onpanda Python 库直接导出 SFT 样本和偏好对。这个数据协议设计得干净，接入训练管线的成本很低。
Agent 轨迹标注
纯文本之外，onPanda 还能标注 agent 轨迹，靠的是"响应模板"机制：在结构化消息（reasoning、content、tool_calls）和模型原生 token 流之间双向转换。关键是特殊 token（</think>、<|tool_call_begin|> 这类）对标注员直接可见、可纠错——token 级纠错统一覆盖推理链、正文和工具调用参数。
图 2：agent 标注场景。左侧是渲染了特殊 token 的原生 token 流（<|tool_call_begin|> 等直接可见可改），右侧是结构化视图：reasoning 可编辑、tool call 参数可编辑、工具通过 MCP 接入（browser-agent、claude-code 等），工具执行前标注员可批准/修正/拒绝（Run / Reject / Retry），被拒轨迹自动保留为负样本。
外部工具通过 MCP 连接，他们写了个 harness_to_mcp 适配器把 Claude Code、Codex 这类 harness 包装成 MCP server。图像、音频、视频输入也支持。
🧪 实验：52% 的时间节省是真的吗
受控对比实验
设置：3 名标注员 × 21 个图像描述 prompt，拉丁方设计轮换方法顺序，三种方法共享同一初始 rollout（Qwen3.5-35B-A3B 生成，temperature 0.7、top-p 0.8）。基线是 POTATO（后编辑）和 Argilla（4 候选排序）。
| 工具 | 范式 | 中位时间 (s)↓ | Win rate↑ | PPL | ΔPPL | SFT 覆盖率↑ | 偏好对↑ | NASA-TLX↓ |
|---|---|---|---|---|---|---|---|---|
| Argilla | 4 候选排序 | 336 | 28.6% | 1.161 | −0.83% | 52% | 6.00 | 5.4 |
| POTATO | 后编辑 | 681 | 54.8% | 1.596 | +36.31% | 100% | 0.95 | 6.8 |
| onPanda | token 级纠错 | 330 | 66.7 | 1.181 | +0.86% | 100% | 7.43 | 3.1 |
表 1：三种标注范式对比。PPL 基线（重采样均值）为 1.171。
几个数字值得停下来看。
时间：onPanda 中位 330 秒/题，比 POTATO 的 681 秒少了 51.5 个百分点，和 Argilla 的 336 秒持平——也就是说它用排序法的速度，拿到了编辑法的覆盖率。均值上也分别低 27.5% 和 24.7%。
PPL 是最狠的证据。onPanda 偏差只有 0.86 个百分点，和 Argilla（−0.83%）一样落在重采样噪声范围内（每 prompt 跨 rollout 波动约 ±2.8%）；而 POTATO 偏了 36.31 个百分点。一句话：onPanda 产出的数据，模型自己几乎认不出来有人动过手脚。
认知负荷：NASA-TLX 得分 3.1 vs POTATO 6.8，差距很大。标注员的反馈也印证——"排序工作流逼着我把很长的上下文记在脑子里，非常耗神"；而概率着色"加快了定位，低概率 token 往往对应模型不自信、更容易出错的位置，先查它们标注更快"。
说实话有一点我想吐槽：win rate 是用 GPT-5.5 当裁判评的，LLM-as-a-judge 天然可能偏好某种风格。作者倒也坦诚，在 limitations 里自己点了这个问题，还补了一轮匿名人工对比（54.8% 的对子偏好 onPanda 胜过 POTATO），算是把短板摆在了明面上。
还有一个效率来源值得点破：模型幻觉往往在一个响应里反复出现，后编辑必须逐处修复，而 onPanda 只需纠正首次出现处，续写内容自然与修正保持一致。省下的不只是打字时间，是"反复找同一类错"的时间。
生产部署数据
论文附录给了三个真实生产部署的统计，这个比受控实验更能说明问题：
| 指标 | Vision | Audio | Agentic |
|---|---|---|---|
| 标注会话数 | 25,596 | 105,143 | 1,257 |
| 中位标注时长 (min) | 1.65 | 1.93 | 31.31 |
| 每会话 SFT 样本 | 1.001 | 1.318 | 6.018 |
| 每会话 token 级纠错 | 2.256 | 3.034 | 8.566 |
| 零纠错率 | 49.1% | 23.9% | 53.5% |
表 2（节选）：三类生产部署的标注统计。
三类部署累计产出约 388K 次 token 级纠错。最惊人的是这个构成：所有合格响应中，97.0% 的 token 由模型生成，2.1% 选自候选，仅 0.9% 为人工输入。生产规模下人工干预稀疏到这个程度，on-policy 保真度不是口号，是数据。
agent 场景的中位标注时长 31 分钟，看着吓人，但想想 agent 轨迹动辄几百上千 token、还涉及真实工具执行，这个数字其实合理。
📊 Panda-CVL：顺手放出的数据集和 benchmark
作者还发布了 Panda-CVL：中文为主的视觉-语言数据集，7,491 个标注会话（训练 6,839 / 测试 652），辅助 rollout 由 step-1o-turbo（32B 稠密 VLM）生成。
更有意思的是配套的 token 级纠错 benchmark。把一次人工纠错拆成三个子任务：判断是否达标、定位第一个错 token、纠正为合适 token。测试集 652 个会话扩展成 2,126 个评估实例，指标包括 Format、GoodAcc（正确判好的比例）、Loc.-NG（正确定位）、Corr.-NG（定位+替换全对）和 F1。
| 模型 | Format | GoodAcc | Loc.-NG | Corr.-NG | F1 |
|---|---|---|---|---|---|
| GPT-5.5 (xhigh) | 93.96 | 53.37 | 15.26 | 10.18 | 17.09 |
| GPT-6 (xhigh) | 99.65 | 17.38 | 24.46 | 15.83 | 16.57 |
| GPT-5.6-sol (xhigh) | 99.98 | 16.56 | 19.95 | 13.09 | 14.63 |
| Step-5-Preview | 95.63 | 32.21 | 16.42 | 9.77 | 14.99 |
| Qwen3.5-397B-A17B (推理) | 93.77 | 20.40 | 17.37 | 10.99 | 14.28 |
| Doubao-Seed-2.1-pro | 99.01 | 9.66 | 21.64 | 13.70 | 11.33 |
| Qwen3.5-397B-A17B (instruct) | 38.83 | 4.45 | 1.63 | 0.81 | 1.38 |
表 3（节选）：Panda-CVL 测试集得分（%），按 F1 降序，仅列代表性模型。
看到这个结果我愣了一下：最强的模型 F1 也只有 17.09 个百分点。9 个推理模型里 7 个 Format 超过 90%，但所有模型 Corr.-NG 都不到 16%——格式合规和真正会纠错完全是两回事。
这反过来论证了 onPanda 存在的必要性：如果模型自己能做好 token 级纠错，这个工具就没必要存在了。恰恰因为它们做不好，人在回路的标注才值钱。另外 GoodAcc 的巨大差异（53.37% vs 9.66%）暴露了各模型"接受 vs 修改"的倾向差异——这个 benchmark 说不定能变成一个挺有用的元能力评测。
附录还有个标注一致性分析（Panda-MultiRef-21）：对同一响应做 4 次独立标注，人类两两位置一致率精确匹配 30.95%（随机基线 0.20%），容忍 4 个 token 偏差时 44.44%。一致但不完全一致——定位相同的情况下替换 token 一致率 69.44%。这个分布特性给单参考评估的得分提供了合理的解释背景。
💡 我的判断
这篇论文值不值得花时间？我的看法是：做数据基础设施的人必读，做算法的人扫一眼即可。
亮点很清楚。token 级纠错这个交互抽象找到了一个漂亮的平衡点：比排序法覆盖率高，比后编辑快且 on-policy。标注树 + .panda.json 的数据协议、MCP 接入 agent 环境、特殊 token 可纠错——这些工程细节说明作者真的在生产环境里用过这个系统（Table 2 的十万级会话数就是证据）。白送的 token 级偏好三元组是最有想象力的副产品，作者也在 future work 里点了两个方向：token-level correcting model（奖励模型的 token 级对应物）和 token-level correction optimization（DPO 的 token 级对应物）。这两个方向如果做出来，onPanda 的历史地位会不一样。
问题也得说。最核心的软肋作者自己承认了：token 级纠错信号的下游训练收益没有验证。效率、质量、分布特性都测了，但"用这种数据训出来的模型到底好不好"——没答。在训练实验补上之前，on-policy 保真度的价值还停留在理论层面。另外整个方法建立在"错误稀疏"的前提上，模型离任务差距大、纠错变密集时优势就衰减了；on-policy 也是相对标注时的 rollout 模型而言，权重一更新收益就打折。受控实验规模也偏小（3 人 × 21 prompt），agent 场景干脆没做受控实验。
还有一个现实约束：核心交互依赖推理 API 支持前缀续写和 top-k logprobs。好在作者盘点了现状——vLLM、SGLang 原生全支持，Doubao、DeepSeek、Kimi、StepFun 官方 API 都齐活，实际约束比想象中温和。
跟最接近的 Reptile 比，onPanda 的差异化在于替换来自模型候选 token（保 on-policy）以及支持结构化推理/工具调用格式。不算颠覆，但把这条路线推到了生产可用的成熟度。
🤔 收尾
如果你团队正在搭对齐数据标注管线，onPanda 值得认真评估——尤其是它的数据协议和纠错三元组的采集方式，哪怕不用它的前端，这个"标注即数据采集"的思路也可以抄。真正的悬念留给后续工作：token 级纠错信号喂进训练，能不能跑赢 response 级 DPO？我等这篇的 follow-up。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我