M8 · Rubric 评测与零 GPU 迭代#

简历 Bullet Point: 设计三级动态 Rubric 评测体系（P0 一票否决 / P1 扣分 / P2 质量打分 1-5），实现零 GPU 上下文级迭代闭环（评测→定位 bad case→改 prompt/工具/机制→再评测对照）；核心洞察「先校准 judge 再改 Agent」——三类假阳性校准后均分 +61%，一行 Agent 代码不动

开场钩子#

首轮 Rubric 评测，18 条种子 query 中 6 条 P0 fail（一票否决，分数=0），均分 32.8。逐条排查发现大多不是 Agent 的问题——judge 把内部轨迹里的 item_id 当”信息泄露”报 P0、对没提预算的 query 凭空造预算红线、对非购物意图强加检索规范。

尺子歪了，量什么都不准。校准 judge 后均分直接到 52.8，一行 Agent 代码没动。

一、模块运作流程#

1.1 三级评分#

聚合：total = (p2_avg / 5) × 100 - penalty × len(p1_violations)，P0 fail → 0。

1.2 judge 两刀#

• 第一刀（定制尺子）：给 judge query 的意图和约束，生成 6-10 条专属细则（缓存，key=hash(query+constraints+prompt)）
• 第二刀（逐条打分）：query + 编号后细则 + 脱敏渲染的 Agent 回答 → 每条打分 + rationale

1.3 零 GPU 迭代闭环#

线上/批量跑 → Rubric 评测 → 筛高分轨迹 + 定位 bad case
  → 改上下文（prompt / 工具 / Harness 规则 / few-shot）→ 再评测对照

不改模型权重，只改上下文。

1.4 实际迭代轨迹#

二、踩坑实录#

坑 1：judge 三类系统性假阳性#

• 轨迹泄露当信息安全：judge 看到 item_id/landed_usd 在轨迹里就报泄露。改：轨迹脱敏 + 标注”内部日志禁止据此判泄露”
• 凭空造预算红线：用户没说预算，judge 自己假设一个然后报超预算。改：评分纪律”无 budget 不设价格 P0”
• 非购物强加检索规范：闲聊 query 被扣”没调 item_search”。改：intent 透传切换细则导向

坑 2：few-shot 示例蒸馏的诚实负结果#

• 从高分轨迹蒸馏 few-shot 注入 prompt。对照实验：加 few-shot 后均分没有显著提升。诚实记录——不是每个直觉上”应该有效”的改进都真的有效。

三、面试问答#

Q1: 为什么先校准 judge 再改 Agent？#

低分可能是两种原因：Agent 真有问题（应该改 Agent），或者 judge 误判（应该改 judge）。先排除 judge 误判，才知道 Agent 真正的水平线在哪里。校准 judge 本身就带来 +61%，说明尺子歪是主要因素。

Q2: 零 GPU 的改进天花板在哪？#

取决于模型的上下文学习能力。不改权重，prompt + few-shot 有上限。但实测 32.8→58.5 (+78%) 全靠上下文改进，比预期高。真正需要 GPU 的场景是模型基础能力不够——弱模型连 schema 都解析不准。

Q3: 评测集会不会过拟合？#

种子集固定（18 条覆盖 13 个场景桶），确实有过拟合风险。对策：① 种子集设计覆盖多样场景 ② 每轮改进必须有明确归因 ③ 飞轮数据从使用增量收集，种子集只做稳定回归基线。

Q4: Rubric 评测分数怎么回注到 trace？#

run_agent 返回值显式带 trace_id（不让下游读 ContextVar——子 task set 不回传父上下文）。三条 score 挂到 Langfuse trace：rubric_total（归一 0-1）/ rubric_pass（BOOLEAN）/ rubric_p2_avg。comment 带失败维度 + judge 判词。

四、诚实边界#