GAIA LLM-verifier 的 Avg tokens 漏算落选候选与 judge 的 token，成本对比可能误导

[Rememorio]

背景

#10 给 GAIA 引入了 LLM-verifier（best-of-N + judge）：gaia/trpc-agent-go-impl/llmverifier.go 通过 bestofn 并行跑 Attempts 个 candidate，再用一个独立的 judge runner 做 pairwise 比较选出 winner。

问题

GAIA 报告里的 Avg tokens（以及单题 tokens_used）只统计了最终 winner 的 token，落选 candidate 与 judge 的 token 都没有计入。

原因

• 主仓库 trpc-group/trpc-agent-go 的 best-of-N 在选出 winner 后，只把 winner 的事件转发给下游（runner/candidate_selector.go 的 forwardWinner 只遍历 winner.Events）；落选 candidate 的事件、judge runner 的调用都不在转发的事件流里。
• gaia/trpc-agent-go-impl/gaia.go 统计 token 时从这个"只剩 winner"的事件流取数：
  • result.TokensUsed = evtPtr.Response.Usage.TotalTokens（约 gaia.go:1723）
  • summary.AvgTokens = float64(totalTokens) / n（约 gaia.go:2204）

因此 Attempts=N + judge 实际消耗约为 N×candidate + judge，但报告只体现约 1×（winner）。

影响

LLM-verifier 配置下的 token / 成本被严重低估，与 baseline 等单次配置做成本对比时会产生误导。

建议（二选一）

1. 统计端到端 token：把所有 candidate attempts 的 token + judge 的 token 都计入（需要让 best-of-N 把各 attempt / judge 的 usage 暴露给 benchmark，或在 benchmark 侧单独累计）。
2. 维持现状但改标注：把该列明确标为 selected-answer tokens，并在报告/文档里说明不含落选候选与 judge，避免误导。

备注（次要、独立）

gaia.go:1723 用的是 = 而非 +=，因此即使只看 winner，多步任务的 TokensUsed 也只取最后一个带 usage 的 step，而非整轮求和；baseline 路径同样如此。可一并评估是否需要改为累加。

关联

• 引入 PR：gaia: add llm verifier test #10
• 关联讨论：benchmark: update submodule to latest main trpc-agent-go#2035（WineChord 在该 PR 的 review 中指出）