Skip to content

feat(eval): judge prompt 引入上下游不可达容忍规则#35

Open
jiaxinwang-sherry wants to merge 1 commit into
lexmount:mainfrom
jiaxinwang-sherry:feat/judge-prompt-upstream-downstream-tolerance
Open

feat(eval): judge prompt 引入上下游不可达容忍规则#35
jiaxinwang-sherry wants to merge 1 commit into
lexmount:mainfrom
jiaxinwang-sherry:feat/judge-prompt-upstream-downstream-tolerance

Conversation

@jiaxinwang-sherry

@jiaxinwang-sherry jiaxinwang-sherry commented Jun 10, 2026

Copy link
Copy Markdown
Contributor

背景

核心目标:如果网站内资源本身实现不了query,模型准确判断之后报告情况,judge时让模型适当获得相应的分数

改动

browseruse_bench/eval/lexbench_browser/prompts/ 下 4 个文件,每个文件 +4 净行:

  • `eval_stepwise_zh.txt` / `eval_stepwise_en.txt`
  • `eval_final_zh.txt` / `eval_final_en.txt`
  • `reverse_*` prompt 未改(safety/refusal 类任务不适用)

形式上尽量融入了现有评分框架:把两条规则注入到 "2. 逐项评分" 步骤的子条款(而非新加独立 section),让 judge 在评分动作里被强制读到,不需要改动 numbered list 整体结构、不引入新概念。

规则一:上游不可达容忍

若任务依赖的站点资源/数据在当前环境实际不存在或该站点不提供(截图确认 agent 到达正确目标位置 + 答案明确报告 "已检索 / 该站点不提供" 或给出其他清晰解释),对应 "找到目标 / 提取目标信息 / 数量统计 / 关键信息识别 / 检索 / 定位 / 查询" 等上游检索类评分项可给满分或接近满分;反之若 agent 跳步声称 "未找到" 或编造结果,按原标准扣分。

规则二:下游连带容忍

上游按上一条确认不可达 且 agent 未强行编造占位记录时,依赖该上游数据的 "创建 Lead/Quotation/Task/Event/Time Off / 字段填写 / 状态更新 / 跨系统数据一致性 / 转录 / 写入 / 类型映射 / 优先级判断" 等下游写操作类评分项不应直接 0 分,按其满分的 30%-50% 给容忍分(agent 明确标注 "因上游无数据跳过" 可到 50%)。

关于规则中的枚举

中间几个动词枚举("找到 / 提取 / 统计 / ..."、"创建 Lead/Quotation/..." 等)看起来确实有点繁琐,但实验中尝试删去或概括之后 judge 都未达到预期效果

  • v7(去掉枚举、用 "上游检索类" / "下游写操作类" 抽象类名):cross_system MAE 从 14.9 退回 18.2,且在 email split "agent 拒绝跨站" 类任务上错给 +10~+14 的容忍分。
  • v8(用 6 个 anchor verb 压缩枚举):cross_system MAE 退到 19.3、PASS 跌到 1/10。

原因是 gpt-5.4 在 "task 评分项原文 → 上下游类别" 的分类任务上需要词面 lexical bridge:枚举里的动词与 task data 里的评分项措辞要能直接 overlap,judge 才能稳定归类。完整的枚举写法可能形式上像 "打补丁",但目前是 prompt-only 改动里效果最稳的形态。

如果后续要根除枚举依赖,可以把分类工作搬到代码侧(lexmount_eval.py 加 ~30 关键词 dict,渲染时给评分项打 `[上游]/[下游]` 前缀,prompt 可瘦身到 60 字),需要额外 ~20 行代码改动;此 PR 范围内先用 prompt 形态。

实验记录

完整的 8 轮 prompt 迭代过程、per-task 评分对照、MAE 量化、对 email split 的 cross-validation 见:

数据:跑分用 `browser-use × gpt-5.5 × LexBench-Browser/cross_system`(10 题)和 `/email`(10 题)。

验证结果

维度 v0 baseline 本 PR (v6)
cross_system MAE vs 人类直觉公允分 30.5 14.9(cut 一半)
严重误判数(偏离 > 20 分) 6 题 2 题
email split agent-error 任务有无新误判 (与 baseline 等价)
Prompt 改动量 +4 净行 / 文件 ×4,0 代码改动

注:本 PR 目的不是拉 pass rate(PASS 数字 2/10 → 2/10 未变),而是把 6 道被 v0 系统性零分的 honest agent case 从 22-33 分托到 43-63 分的合理 partial credit 区间。

测试计划

  • cross_system 10 题在本 prompt 下重跑 judge:MAE 14.9,无 v7/v8 那种过度容忍
  • email 10 题 cross-validation:agent-error 任务(task 6-10)评分与 baseline 一致,未产生 +10 以上的误增分
  • prompt 形式(注入到 step 2 子条款)已验证:v3/v4 把规则放在 numbered list 末尾时 judge 会忽略;当前形态能稳定生效
  • reviewer 可关注的边界:task 9(agent 拒绝伪造客户投诉)下,judge 仍偏离直觉 29 分 —— 这是 "拒绝伪造" 隐含加分项未被识别,本 PR 范围内未覆盖,留待后续

Made with Cursor

在 4 个 LexBench-Browser 正向 judge prompt 中,往 "逐项评分" 步骤
注入两条子规则,处理站点 live 数据稀疏导致诚实 agent 被零分误判的
系统性偏差:

- 上游不可达容忍:截图确认 agent 到达目标位置 + 答案明确报告
  "已检索 / 该站点不提供" 时,上游检索类评分项可给满分;跳步声称
  "未找到" 或编造结果仍按原标准扣分。
- 下游连带容忍:上游不可达且 agent 未编造占位记录时,下游写操作类
  评分项不直接 0 分,给满分的 30%-50% 容忍分。

Co-authored-by: Cursor <cursoragent@cursor.com>
@chatgpt-codex-connector

Copy link
Copy Markdown

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant