Agent 评估入门：离线 eval、SWE-bench/τ-bench、LLM-as-judge 偏差

Q: 关于 agent 的「离线 eval」和「在线监控」，下面哪种说法对？

两者互补：离线可复现、适合上线前把关；在线看真实表现，但问题常已触达用户。离线 eval 上线前 / CI 跑、可复现、零影响；在线监控看真实 ground truth、能发现漂移但被动。互补，缺一不可。

Q: SWE-bench、τ-bench 这类基准的「执行式评判」核心是什么？

看结果对不对（跑单测 / 多轮完成任务），而非文本相似度。执行式评判看真实结果（SWE-bench 跑单测、τ-bench 看多轮任务完成），比文本匹配可靠得多。

Q: 判断对错：「用 GPT-4 当裁判给 agent 打分，因为和人类一致率高，就可以直接当成绝对正确的 ground truth。」

错误。LLM-as-judge 系统带位置 / 冗长 / 自我增强偏差，只能当可规模化的近似，要用交换顺序 + 人工抽审校准，不能当 ground truth。

demo 能跑 ≠ 生产能用：第一件事是能「测」

Agent 在 demo 里跑通一次，不代表它在真实流量下稳定。要上生产，第一件事是建立评估，而且是两条腿：离线 eval（上线前 / CI 里跑，完全可复现、对用户零影响）+ 在线监控（上线后看真实表现，能发现分布漂移，但问题往往已经触达用户才暴露）。两者互补，缺一不可。

eval 集不用一上来就大。Anthropic 的建议：从真实失败案例里挑 20–50 个任务起步就够——开发早期效应量大，小样本就能看出问题。每个任务要清晰到「两位领域专家独立判定会得到同一个 pass / fail」，并带参考解，正反都覆盖。

⚠️最大的误区：只盯一个「准确率」。HELM 早就指出整体评估要多指标并行（准确率 / 鲁棒性 / 校准 / 安全…）。单看准确率，会漏掉最致命的安全和可靠问题。

怎么打分：执行式评判 + LLM 当裁判（但它有偏）

给 agent 打分有两条硬路子。一是执行式评判：别比文本相似度，直接看结果对不对。SWE-bench 让模型改真实 GitHub 仓库的 issue，跑单元测试判定是否真解决（发布时最强模型才过约 2%）；τ-bench 模拟「工具-agent-用户」多轮对话，用 pass^k（同一任务重复跑 k 次都对）衡量可靠性——能做对一次不算本事，次次做对才算。

二是用强 LLM 当裁判（LLM-as-judge）：GPT-4 当裁判和人类的一致率能超 80%，可规模化替代部分人工评分。但它系统性带偏差：位置偏差（偏向靠前的答案）、冗长偏差（偏向长答案）、自我增强偏差（偏向裁判模型自己生成的那条回答）。所以别把裁判当 ground truth，要用交换顺序、人工抽审来校准。

💡可观测性配套：用 OpenTelemetry GenAI 语义约定统一记录每次调用的 token / 模型 / 延迟 / 成本（标准 span 属性），一次插桩跨厂商通用，线上才看得见 agent 在干嘛。

自测 · 学完检查一下

想真正动手做题、记进度、攒连胜？到互动课里练。

关于 agent 的「离线 eval」和「在线监控」，下面哪种说法对？

答案：两者互补：离线可复现、适合上线前把关；在线看真实表现，但问题常已触达用户

离线 eval 上线前 / CI 跑、可复现、零影响；在线监控看真实 ground truth、能发现漂移但被动。互补，缺一不可。

SWE-bench、τ-bench 这类基准的「执行式评判」核心是什么？

答案：看结果对不对（跑单测 / 多轮完成任务），而非文本相似度

执行式评判看真实结果（SWE-bench 跑单测、τ-bench 看多轮任务完成），比文本匹配可靠得多。

判断对错：「用 GPT-4 当裁判给 agent 打分，因为和人类一致率高，就可以直接当成绝对正确的 ground truth。」

答案：错误

LLM-as-judge 系统带位置 / 冗长 / 自我增强偏差，只能当可规模化的近似，要用交换顺序 + 人工抽审校准，不能当 ground truth。