评测与可观测性
本文总结系统有没有变好，要拿可检查的证据说话，版本号和一次漂亮的演示都不算数。
评测要回答的三个问题
- 什么叫对。先把“对”写成能检查的断言，再谈打分。报销助手的“对”包括：结论和现行制度一致，引用确实支持结论，工单恰好一张且字段正确，没有越权。“回答看起来很专业”不在其中。
- 怎么稳定地测。同一批题、同样的环境快照和预算，重复跑，结果能复现。
- 变好了没有。和上一个版本逐题比，别只比两个总分。
第 1 条落到报销案例上，可以写成这样几条断言（示意）：
assert answer.decision == "reimbursable_with_approval"
assert "第 4.2 条" in answer.citations
assert answer.over_limit == 38.5 # 118.5 - 80
assert count(tickets where invoice=INV-102) == 1
assert ticket.employee_id == session.user # 不是模型填的
每一条都能用代码判对错，不需要谁来“感觉一下”。
三个问题缺了哪个，评测都会退化成演示。只有第 1 个，没法重复；只有第 2 个，测的未必是业务关心的事；没有第 3 个，你分不清这次改动带来的是提升还是噪声。比如（示意）新版总分从 82 涨到 84，逐题一看，修好了 5 道、又弄坏了 3 道，坏掉的 3 道里有一道是重复建单。只看总分，这次发布就放出去了。
先记录，再比较
同一组任务要把输入、预期、来源、工具轨迹、耗时和费用口径都存下来，成功和失败的样例都留着。
一条最小记录可以长这样：
case_id / 任务类别 / 初始状态快照
模型版本 / Prompt 版本 / 工具 schema 版本 / 检索快照
断言列表（结果、过程、禁止动作）
每条断言的通过情况 / 失败归因
token / 工具调用次数 / 端到端耗时
判定方式按可靠程度排：确定性检查（状态、数值、schema）最先，其次是规则，再其次是经过人工校准的模型评审，人工评估留给校准和高风险抽检。能用代码判的，就别交给模型判。“超标金额是不是 38.5 元”用一行减法就能判，交给 LLM 裁判反而多了一层随机性。“解释是否让员工看得懂”没法写成等式，才轮到模型评审，而且要先拿几十条人工打过分的样本校准一下。
评测和可观测性是一个回路
离线评测像考试，题目固定，用来决定能不能发布。可观测性像体检，在真实流量里记 trace，用来发现考卷没覆盖到的新问题。两者靠回流连在一起：线上每发现一个 badcase，脱敏后变成一道新题，下次发布前必须通过。
比如线上有员工的发票备注里写了“同时报销招待费”，助手差点照做。这条请求在 trace 里被标记出来，去掉姓名和金额细节后放进对抗集，以后每个版本都得在这道题上拒绝才能发布。
定义成功 → 建题集 → 执行并留痕 → 评分 → 归因 → 修复 → 回归
↑ │
└──────────── 线上 trace 发现的新失败回流 ←──────────┘
这个回路在 Agent 评测：从测试集到发布门槛 里展开成数据格式和发布门槛，在 可观测性：追踪一条任务的代价 里展开成线上指标和告警。
常见误区
- 用演示代替评测：演示只能证明存在一条成功的路径，说明不了成功率。跑通一次不代表一百次里能成九十次。
- 只报平均分：越权、重复副作用这类失败应该一票否决。100 道题里 99 道全对、1 道替别人建了单，平均分 99% 很好看，这个版本却不能上线。
- 先看结果再定标准：评分规则要在执行前定好，不然就是在给结果找理由。
- 把重复运行当新题：同一道题跑五次是为了看随机性，它们不是五个独立样本。
- 对着测试集调 Prompt：留一部分从来不用来调参的题，用它检查有没有过拟合。
对研究 Agent
对 研究 Agent，可以先查三件事：来源能不能追溯，证据不够时结论有没有收窄，实验条件不同时有没有硬排名次。比如两篇论文一篇在英文数据集上测、一篇在中文数据集上测，系统要是直接说“A 比 B 高 3 个点”，就该判不通过。这里的“对”更接近 证据优先 的要求：每个结论都能指回它实际读过的材料。
当前边界
这里只写了评测的方向，项目基准测试还没开始做，没有性能提升数字。以后每次版本变化，都要写清改了什么、在哪些任务上验证过、还有什么没解决。