返回 AICAP-180
B1 · Day 10evals 方法论 + tokenization 起步

双数对齐收口

Day 10 是 B1（Day 1-10）的收口日，也是 B1→B18 能力曲线的第一个里程碑。

阶段: B1 · evals 方法论 + tokenization 起步（Day 1-10） 标签: #cost-reconciliation #tokenization #evals #b1-closeout

今日导引（由浅入深）

Day 10 是 B1（Day 1-10）的收口日，也是 B1→B18 能力曲线的第一个里程碑。

B1 跑出了两条独立产线：

  • 一条是 eval harness 的实测 cost（Day 5 harness + Day 6 归因）；
  • 另一条是 token-report 的估算 cost（Day 7-9 自写 tokenizer，1760 token）。

今天做「双数对齐」——把这两条产线的成本数并排，算偏差%，验证「token 计量」与「计费模型」是否对齐。偏差小且可解释，才说明前 9 天的工程是自洽的。

最小可判定产出：对照表 + 偏差% + 合并 commit。

明天起进 B2（attention/decoder/KV + judge 校准），从「评测/工程」切到「模型内核」。

1. 机理精读

收口的本质是「交叉验证两条独立产线」。

B1 故意用两种互不依赖的方式逼近同一个量——eval 成本：

  • 产线 A（实测）：真发请求，OpenRouter 按它自己的 tokenizer 算 input/output token，乘单价返回真实 cost。这是「真值」，但需要 API key。
  • 产线 B（估算）：自写 byte-level BPE 编码 prompt 得 1760 token，乘当周公开单价。这是「估算」，no-key。

两条产线若偏差小且可解释，则说明 token 计量与计费模型对齐——也就是说自写 tokenizer 虽然切分不同，但量级靠谱，可以放心用它做后续的预算和任务取舍。

这是一种轻量的「双重记账」校验思想：用两套独立方法逼近同一数，偏差就是系统的「不确定度」。

偏差从哪来（为什么不会、也不该为 0）？ 两个可解释来源：

  1. tokenizer 不一致：自写 BPE（小语料 456 词表、贪心切分）与模型官方 tokenizer（DeepSeek-V4 / Qwen3 各自 ≥32k 词表）的切分规则不同，同一段 prompt 切出的 token 数本就不同。这是结构性差异，不是 bug。
  2. output token 不可预估：产线 B 只算了 input（prompt 已知），但真实 cost 含 output（模型生成多少不可知）。所以纯 input 估算天然低估总 cost——除非把 output 用历史均值补上。

关键判断：偏差落在「可解释范围」就是健康的。

绝不能把估算偏差当成 bug 去 debug。把 tokenizer 差异和 output 不可预估这两项讲清楚，偏差就有了归因——这正是收口要交付的「可解释」。

与相邻概念的边界：今天不是新增功能日，是对齐与归因日。

它把 Day 5（cost）和 Day 9（token）两个已有产出连起来，不引入新机制。

这也呼应 Day 6 的方法论：失败/偏差都要可归因到结构化原因，而非「重跑/重测」。

2. 推导 / 手算 / 代码走读

今天无新代码，是把已有两数对齐。走读涉及的真实符号：

  • token 侧（src/agent/eval/tokenizer.ts）：tokenReport 已产出 totalTokens=1760（Day 9 实测）。产线 B 的 input 估算 = 1760 × 当周单价。
  • cost 侧（src/agent/eval/agentEval.ts）：
    • runTaskEval 返回的 TaskEvalReport 含 completionRate（注释 fraction with judge.label === 'pass'）、totalCostUsd、逐任务 perTask: TaskRunResult[]。
    • 每条 TaskRunResult 在真跑时带 costUsd、latencyMs。
    • makeModelGenerate 里 u?.outputTokens ?? u?.completionTokens、u?.inputTokens ?? u?.promptTokens 取真实计费 token。
    • 这是产线 A 的真值来源，需 key。

偏差% 计算式（手算骨架，真实数待 key）：

偏差% = (cost_实测 − cost_估算) / cost_实测 × 100%

其中  cost_估算 = 1760(input token) × input单价            // 仅 input，低估
      cost_实测 = (input_token实 × input单价)
                + (output_token实 × output单价)             // 含 output，真值

预期偏差为正且不小（实测 > 估算），主因是产线 B 漏了 output token；扣除 output 后剩余偏差才反映 tokenizer 切分差异。这两层归因正是收口要写进对照表的。

对照表骨架（待 key 填实测列）：

项产线 B 估算（no-key）产线 A 实测（需 key）偏差% / 归因
input token1760（自写 BPE）待跑tokenizer 切分差异
output token不可预估待跑结构性缺口（产线 B 无）
cost1760×单价待跑input 偏差 + output 缺口

两层归因拆解（收口要写清的核心）：

  1. 先用 output_token实 × output单价 把 output 缺口补回估算，得到「补 output 后的估算」；
  2. 「补 output 后的估算」与「实测」之差，才是纯 tokenizer 切分差异贡献的偏差——这一层应该小且稳定。

3. 今日实战

照 seed：把 Day 5 eval 自产 cost 与 Day 9 token 报告（1760 token）× 当周单价并排，算偏差%，出对照表，合并 commit。

  1. 取 Day 9 的 totalTokens=1760，乘当周 OpenRouter input 单价 → 产线 B 估算（input 部分）。
  2. 取 Day 5 自产报告的真实 totalCostUsd（agent-evals/reports/）→ 产线 A 实测；离线时先用 fixture cost 占位，真实数标待 key。
  3. 算偏差% = (实测 − 估算)/实测 ×100%，把偏差归因到 tokenizer 差异 + output 缺口两项。
  4. 出对照表，合并 B1 commit（把 Day 1-10 的笔记/代码/报告收束到一个 commit hash）。

4. 今日实测 / 产出

  • token 侧已就位（1760 token 实测）；eval cost 侧待跑（需 OPENROUTER_API_KEY）。
  • 将产出对照表 + 偏差% + 合并 commit；离线时先用 fixture cost 占位，标注真实数待 key，不臆造。
  • 状态：token 估算已完成（1760）；cost 实测与偏差% 待跑（需 key）。

5. 常见误区 / 陷阱

  • 把估算偏差归因为 bug：tokenizer 不一致 + output 不可预估是结构性、可解释的，别去 debug 一个本就该有的差异。
  • 估算只算 input 却和含 output 的实测直接比：会得到一个被 output 缺口夸大的偏差；归因时必须拆开 input 偏差与 output 缺口两层。
  • 用过期单价算估算：OpenRouter 单价/模型在架状态会变，必须当周重验，否则估算锚错。
  • 收口只合代码不合数：B1 的价值在「两数对齐 + 可解释偏差」，光合并 commit 不出对照表等于没收口。

6. 学习资源（每条带 YYYY-MM）

  • OpenRouter 计费/路由文档（2026-06，执行当周重验）— 实测 cost 与单价来源；模型在架/版本号需逐周确认。
  • Anthropic《Demystifying evals》(2026-01) — outcome + cost 双维评测心智，收口要兼顾质量与成本。
  • Karpathy minbpe（Zero-to-Hero, 2024）— 自写 tokenizer 切分与官方 tokenizer 差异的原理根源。
  • 本仓 src/agent/eval/agentEval.ts（runTaskEval / makeModelGenerate token 提取 / totalCostUsd）+ tokenizer.ts（tokenReport 1760）（2026-06，repo 内）— 两条产线的真实出数点。

SOTA检查 (2026-06 更新)

  • 当前主流：cost ≈ token × 单价 的校验逻辑通用稳定，仍 SOTA；双产线交叉验证是健康的成本工程实践。
  • 可解释范围：偏差主要来自 tokenizer 不一致 + output token 不可预估——属可解释范围，避免把估算偏差归因为 bug。
  • 过时黑名单 / 重验项：OpenRouter 单价需当周重验；DeepSeek-V4-Flash / V4-Pro、Qwen3 的在架状态与官方 tokenizer 更新会改变估算偏差，写数时勿用裸「DeepSeek」「Qwen」，须带版本号。
  • 下次复查点：B2 接入 LLM-judge 实跑后，重算含 output token 的实测 cost，回填本日对照表的「待跑」列。

衔接

  • 昨天：Day 9 — 全量编码 + token 报告（29 prompt，totalTokens=1760，≈2.01 c/t）。
  • 今天：B1 收口——把 token 估算（1760×单价）与真实 eval cost 并排算偏差%，归因到 tokenizer 差异 + output 缺口，合并 commit。
  • 明天：Day 11 — Scaled dot-product + causal mask（进 B2 模型内核：attention/decoder/KV + judge 校准），从评测工程切到 Transformer 机理。
上一篇 · Day 9
全量编码 + token 报告
下一篇 · Day 11
Scaled dot-product + causal mask