PaperBridge 长尾问题
Chain of Draft 真的省 Token 吗？应该怎么评估？
先复现同模型、同题目、同解码设置下的 Chain-of-Thought 基线，再同时报告正确率和每个正确答案消耗的 token。最实用的主指标是 `tokens per correct answer = 总输出 token ÷ 正确答案数`。还要把简单题与困难多步题分开，重复运行，并记录失败、延迟和实际价格。只说“少了 74% token”并不能证明生产成本下降：一次关键失败带来的重试、人工复核或错误动作，可能抵消全部节省。
1. 先让两组实验真正可比
固定模型版本、系统提示词、题目顺序、工具权限、最大输出长度和评分器。唯一应该变化的是推理提示：一组使用 Chain-of-Thought，另一组使用 Chain of Draft。模型或工具链同时变化时，你无法判断 token 差异来自提示还是环境。
温度设为 0 也不应被当成“绝对确定”。至少重复每个条件数次，并保存题目级结果，而不是只保存一行平均值。
2. 用“每个正确答案的 Token”做主指标
原始 token 总量只测量输出长度，不测量有效工作。把总输出 token 除以正确答案数，可以把效率和质量放进同一个分母。若 100 个任务中短推理只完成 80 个，剩下 20 个还需要重试，它可能比更长但稳定的基线更贵。
同时保留正确率与 token 的原始数值，不要只发布一个合成分数。读者需要知道收益来自文本更短、答案更多，还是两者都有。
- 总输出 token 与供应商单独报告的 reasoning token。
- 正确率、失败数、拒答数和需要重试的任务数。
- tokens per correct answer，以及每个成功任务的真实美元成本。
- 中位数与 P95 延迟，避免平均值掩盖慢请求。
3. 按任务难度和任务类型分层
原始 Chain of Draft 论文在其评测上报告了很大的 token 降幅，但软件工程扩展得到的节省更温和。代码修改、开放式分析和需要保持长程状态的任务，往往比小学数学题需要更多中间信息。
最少分成简单单步、困难多步、开放式生成和工具调用四层。某种提示可以只在简单层启用；不需要为了统一配置，把所有请求都压成五词步骤。
4. 把失败后的成本算进去
生产环境的成本包括首次推理、自动重试、第二模型复核、人工检查和错误动作的修复。为每种失败定义处理路径，再计算每 100 个成功任务的总成本。
如果 Chain of Draft 在简单任务上明显更便宜、在困难任务上不稳定，可以先用轻量分类器或规则路由：低风险任务走简洁推理，高风险任务保留更完整的推理与验证。
最小可复现实验
- 准备至少两个难度层级，并锁定独立评分标准。
- 固定模型、版本、题目、提示外条件与工具权限。
- 分别运行 CoT 与 CoD，并为每个条件做多次重复。
- 记录题目级正确率、输出 token、reasoning token、延迟和失败类型。
- 计算 tokens per correct answer 与每 100 个成功任务的总成本。
- 公开失败案例和适用边界，不只展示平均 token 降幅。
- 根据风险与难度决定是否路由，而不是全量替换。
原论文、研究与官方文档
以下来源用于核对事实；流程与比较建议是 PaperBridge 对研究、官方文档和工程实践的综合。