Ai-study-chapter6

📘 第 6 章：Agent 的评估 — 通俗讲解

🎯 一句话总结

前 5 章讲"怎么造 Agent"，第 6 章讲"怎么判断造得好不好"——评估是你跟上模型迭代速度的关键武器。

1️⃣ 为什么要评估？

没有评估的团队        有评估的团队
─────────────────    ─────────────────
新模型发布了..        新模型发布了..
等社区反馈..          跑一遍评估集..
看别人怎么说..        1 小时内出结果..
两周后决定换不换..    数据驱动，立刻决策

评估体系的首要价值不是给当前系统打分，而是让你能快速、可靠地跟上模型的演进。

2️⃣ 评估三层次

第一层：在哪测？
┌──────────────────────────────┐
│ 评估环境                     │
│ - 工具调用型（自动化验证）    │
│ - 人机交互型（用户模拟）      │
└──────────────────────────────┘
        ↓
第二层：怎么判？
┌──────────────────────────────┐
│ 评估方法                     │
│ - Rubric 评分标准             │
│ - LLM-as-a-Judge             │
│ - 统计显著性                 │
└──────────────────────────────┘
        ↓
第三层：测了干什么？
┌──────────────────────────────┐
│ 评估驱动的决策               │
│ - 换模型？优化 Harness？     │
│ - 这个改进是真提升还是波动？  │
└──────────────────────────────┘

3️⃣ 一个具体评估示例

测试：用户要退 3 天前的订单，公司政策 7 天内可退款

Agent 的轨迹：
① 调用 query_order → 查到订单，3 天前，¥299
② 判断：3 天 < 7 天，符合退款政策
③ 调用 process_refund → 退款处理中
④ 回复用户："已发起退款，3-5 个工作日到账"

Rubric 评分（4 维度，每维度 1-4 分）：

维度             得分   理由
─────────────────────────────────
操作正确性        4    正确查询并发起退款
政策合规性        4    3 天在 7 天退款期内
信息完整性        4    告知金额、到账时间、退款编号
幻觉检测（否决项） ✅    所有信息来自工具返回

注意：幻觉是"否决项"——只要出现虚假信息，不管其他维度多好，直接否决。

4️⃣ 关键指标：Pass@k vs Pass^k

假设 Agent 单次成功率是 60%（Pass@1 = 0.6）

Pass@5（5 次中至少成功一次）：
  = 1 - 0.4⁵ ≈ 99%
  → 回答"Agent 能不能做到"

Pass^5（5 次全部成功）：
  = 0.6⁵ ≈ 7.8%
  → 回答"Agent 是否稳定可靠"

同一个人，不同指标，结论天差地别！

评估目的	用什么	误用后果
验证稳定性	Pass^k	用 Pass@k 会掩盖不稳定
评估能力上限	Pass@k	用 Pass^k 会误报失败

5️⃣ LLM-as-a-Judge：用 LLM 当评委

为什么需要？ 开放式任务（客服对话、报告撰写）没有标准答案，人工评估太贵太慢。

做法： 给 LLM 一份 Rubric（评分标准），让它自动打分。

LLM 评委收到：
  - 任务描述
  - Agent 的完整轨迹
  - Rubric（评分标准）

LLM 评委输出：
  - 每个维度的得分（1-4）
  - 评分理由

Rubric 四准则：

① 基于专家指导（反映领域知识）
② 全面覆盖（事实、逻辑、安全 + 陷阱）
③ 权重分级（必要项、重要项、否决项）
④ 自包含（不依赖评委的领域知识）

6️⃣ 模型替换实验：区分瓶颈在哪

Agent 表现不好 → 换模型 vs 优化 Harness？

模型替换实验：
  固定 Harness，换更强模型 → 分数大涨？
    ✅ 是 → 瓶颈在模型
    ❌ 否 → 瓶颈在 Harness

消融实验：
  固定模型，关闭 Harness 某组件 → 分数大跌？
    ✅ 是 → 该组件很重要
    ❌ 否 → 该组件价值有限

这两者配合，精准定位问题。

7️⃣ 进度追踪 vs 最终结果

Agent 说了≠Agent 做了：

轨迹（过程）：Agent 说"订票已完成"
结果（事实）：数据库里确实有订单记录

两者都要检查！
只看轨迹 → 漏掉"说了但没做到"
只看结果 → 看不出中间步骤走歪了

📝 快速总结

知识点	一句话
评估三层次	在哪测 → 怎么判 → 测了干什么
Pass@k vs Pass^k	前者测能力上限，后者测稳定性
LLM-as-a-Judge	用 LLM 按 Rubric 自动打分
模型替换	换模型看分数涨不涨，定位瓶颈
Rubric 四准则	专家指导、全面覆盖、权重分级、自包含

🎯 LLM-as-a-Judge：深入拆解

一句话

让 LLM 当裁判，按 Rubric（评分标准）自动给 Agent 的回答打分——解决开放式任务没有标准答案的难题。

为什么需要 LLM-as-a-Judge？

数学题          客服对话         创意写作
──────────      ──────────       ──────────
标准答案可以比对   →   ✅ 自动验证    →   ❌ 没有标准答案！
                    （代码执行）     （怎么说都对/都不对）

LLM-as-a-Judge = 给 LLM 一份评分标准，让它自己当评委。

Rubric 四准则（核心！）

准则 1：基于专家指导

❌ 差的 Rubric: "回答要展示深刻理解"
  → "深刻理解"是什么？谁说了算？

✅ 好的 Rubric: "引用至少两个权威理论并准确解释如何支持结论"
  → 可操作、可验证、不依赖主观判断

准则 2：全面覆盖 + 陷阱识别

维度包括：
- 事实准确性
- 逻辑连贯性
- 完整性
- 安全性
- **陷阱（Pitfall）** ← 重要！高风险的常见错误
  例如：医疗建议中推荐未经验证的疗法

准则 3：权重分级 + 一票否决

权重分级：
  - essential（必要项）→ 必须做对
  - important（重要项）→ 做好加分
  - optional（可选项）→ 有更好，没有也行
  - veto（否决项）→ 一票否决！

幻觉检测 = 否决项
只要出现虚假信息 → 总分归零，不管其他维度多好

准则 4：自包含评估

每个评分档要有客观标准：

4 分（优秀）："准确回答 Dr. Chen，且关联到女儿 Lily"
3 分（良好）："准确回答 Dr. Chen，但未提及是 Lily 的医生"
2 分（及格）："给出了正确医生但附带不确定的额外信息"
1 分（不及格）："给出错误医生名，或回答不知道"

不要写："展示了对记忆的深刻理解" ← 不可操作

完整 Rubric 示例

问题："我女儿的儿科医生是谁？"
（需要跨两次对话关联：第一次"女儿叫 Lily"，第二次"带 Lily 去看 Dr. Chen"）

rubric:
  dimensions:
    # 必要项：如果这个错了，整体失败
    - name: 事实正确性
      weight: essential
      scoring:
        4_优秀：准确回答 Dr. Chen，且关联到女儿 Lily
        3_良好：准确回答 Dr. Chen，但未提及是 Lily 的医生
        2_及格：给出了正确医生但附带不确定的额外信息
        1_不及格：给出错误医生名，或回答不知道
    
    # 重要项：做好加分，不做不扣分
    - name: 信息完整性
      weight: important
      scoring:
        4_优秀：主动补充相关信息（如就诊时间、诊断结果）
        3_良好：回答了核心问题，无遗漏
        2_及格：回答了核心问题，但遗漏可用信息
        1_不及格：关键信息缺失
    
    # 否决项：一旦触发，总分归零
    - name: 幻觉检测
      weight: veto
      scoring:
        pass: "所有信息均可溯源到历史对话记录"
        fail: "编造了对话中不存在的信息"
    
    edge_cases:  # 边界案例
      - "如果用户有多个女儿且分别看不同的医生，应追问是哪个女儿"
      - "如果记忆中同时存在'Dr. Chen'和'陈医生'，应识别为同一人"

评测流程

① 定义测试用例
├─ "我女儿的儿科医生是谁？"
└─ 准备记忆库："女儿叫 Lily""带 Lily 看了 Dr. Chen"

② Agent 运行
Agent → 推理 → "用户的名字叫 Lily，她的儿科医生是 Dr. Chen"

③ LLM-as-a-Judge 评判
输入：
  - 问题：我女儿的儿科医生是谁？
  - Agent 回复：...
  - Rubric（上面那个）

输出：
  - 事实正确性：4 分 ✓（准确回答且关联正确）
  - 信息完整性：3 分 ⚠️（没补充就诊信息）
  - 思考正确性：4 分 ✓（正确跨会话关联）
  - 幻觉检测：pass ✓（所有信息都可追溯）
  
  最终判定：通过（总分 15/20，无否决项）

三大陷阱与防范

陷阱 1：长度偏差

问题： LLM 评委倾向于给更长、更详尽的回复打高分，哪怕内容不正确。

防范手段：

在 Rubric 里显式惩罚冗长
配对比较时先把两个候选的长度控制到相近再评
定期审计评分与回答长度的相关性

陷阱 2：同源模型偏见

问题： Agent 用 Claude，评委也用 Claude → Agent 学会钻空子。

这就是古德哈特定律： 当一个度量指标变成优化目标时，它就不再是好的度量指标。

防范：多源异构评判

Agent 用 Claude → 评委用 GPT-5 和 Gemini
不同家族的偏见往往是正交的，很难同时欺骗
加权平均或一致性检查聚合结果

陷阱 3：奖励作弊

问题： Agent 找到获取高分的捷径，但没有真正完成任务。

例子： 堆砌关键词讨好用户、回避棘手问题

防范： 在 Rubric 里明确惩罚这些行为！

多模态 LLM-as-a-Judge

把 LLM 评委的能力扩展到语音、图像、视频：

方向	评测什么	例子
🎙️ TTS	准确性、自然度、情感表达	"今天天气" vs "今天天气啊"
👂 ASR	语义影响	"转账一千" vs "转账一万"
🖼️ UI	文字溢出、颜色对比度	按钮太小点不到
🎬 视频	关键帧验证	剪辑起止点对不对

提议者-审核者机制： 一个模型生成，另一个模型审查。

Pass@k 与统计显著性

之前讲过 Pass@k（k 次中至少成功一次），现在加上统计显著性检验：

改进 A 版本：Pass@5 = 85% (95% CI [80%, 90%])
改进 B 版本：Pass@5 = 87% (95% CI [82%, 92%])

两者的置信区间有重叠 → p > 0.05 → 差异不显著

结论：B 比 A 高了 2%，但这可能是随机波动，不是真实提升

有了这个，就知道哪些改进是真有效，哪些只是噪音。

一句话记住

LLM-as-a-Judge 就是给 LLM 评委一份 Rubric（评分标准），让它按标准自动打分。Rubric 四准则：专家指导、全面覆盖、权重分级、自包含。防范三大陷阱：长度偏差、同源偏见、奖励作弊。

🏆 Elo 评分与配对比较

一句话总结

让两个 Agent 直接 PK，输赢决定谁加分谁扣分——用"淘汰赛"的方式给所有 Agent 排名，比打分更客观。

为什么要用 Elo？

绝对评分的问题

问："这个回答得几分？"
→ LLM 评委偏好长回答
→ 同源偏见（都是某个家族的）  
→ 每次评判可能有波动

Elo 的优势

问："A 和 B 哪个更好？"
→ 不需要绝对标准
→ 人类或 LLM 更容易判断相对优劣
→ 大规模统计收敛到真实水平

Elo 工作原理

基本机制

初始：所有模型都 1000 分

第一局：模型 A(1200) vs 模型 B(1000)
  Elo 预测：A 胜率 ≈ 76% (基于分数差)

结果 1：A 赢了（符合预期）
  A 加：+5 分 (小幅度调整)
  B 减：-5 分

结果 2：B 赢了 ← 爆冷！
  A 减：-15 分 (大幅度惩罚)
  B 加：+15 分 (大幅度奖励)

核心：预期胜率越接近实际结果 → 分数调整越小
      越接近爆冷 → 调整越大

Bradley-Terry 模型：背后的数学

Elo 的统计基础是 Bradley-Terry 模型：

P(A 胜 B) = exp(Score_A) / (exp(Score_A) + exp(Score_B))
         = 1 / (1 + exp(Score_B - Score_A))

Score_X 是模型的"实力值"
分数差越大，胜率差距越明显
Elo 是这个模型的在线实现版本（逐个处理比赛）

Chatbot Arena：最著名的应用

用户提问 → 匿名给出 A 和 B 的回答 → 用户选"哪个更好" → 记录投票
     ↓
数百万次盲选投票 → 用 Bradley-Terry 极大似然估计计算排名
     ↓
公开榜单（按月更新）→ 识别技术突破时刻

特点：

✅ 匿名随机对决 → 消除品牌偏见
✅ 无需定义"绝对标准"
❌ 但受用户提问分布影响

三大陷阱与防范

陷阱 1：位置偏差

问题： LLM 评委倾向于选择"先出现"的那个候选。

实验：
第一次：候选 A 在前 → LLM 评 A 好 (70%)
第二次：把 A、B 互换 → LLM 还是评先出现的好 (70%)

结论：70% 的选择基于位置，而非内容质量！

防范手段：

交换顺序各评一次 → 取平均
严格模式：只有两次判决一致时才计入

陷阱 2：样本偏差

测试集不能代表真实世界。如果多数人问编程题，擅长编程的模型排名会偏高。

防范： 分层设计测试集，覆盖不同类型任务

陷阱 3：训练数据污染

评估数据集出现在训练数据中 → Agent "作弊"

防范：

定期更新评估数据集
隔离生产/验证/测试集
监控过拟合迹象

Elo 实战代码

class EloRatings:
    def __init__(self, initial_rating=1000, k_factor=32):
        self.ratings = {}
        self.k_factor = k_factor
        
    def update(self, winner, loser, actual_result=1):
        rating_w = self.ratings[winner]
        rating_l = self.ratings[loser]
        
        # 计算期望胜率
        expected_w = 1 / (1 + 10 ** ((rating_l - rating_w) / 400))
        
        # 更新分数
        delta = self.k_factor * (actual_result - expected_w)
        
        self.ratings[winner] += delta
        self.ratings[loser] -= delta
        
        return {
            'winner': winner,
            'delta': delta,
            'new_score': self.ratings[winner]
        }

# 使用示例
elo = EloRatings()
result = elo.update("Model_A", "Model_B", 1)  # A 赢了
print(f"A 的新分数：{result['new_score']}")

从评估到训练：GRPO 算法

Elo 不仅是评估工具，也是训练信号！

GRPO (Group Relative Policy Optimization)：

同一问题采样多个候选答案：

答案 A: 得分 80
答案 B: 得分 60
答案 C: 得分 70

传统 PPO：需要一个价值网络 (critic) 来估计基线 ← 复杂！

GRPO：直接用组内相对优劣：

Advantage_A = 80 - 70 = +10
Advantage_B = 60 - 70 = -10
Advantage_C = 70 - 70 = 0

不用额外价值网络，只靠组内对比！（第七章展开）

💰 模型选型与成本分析：深入拆解

一句话总结

选模型不是选最强的，而是权衡性价比——考虑吞吐量、延迟、成本、性能四个维度的综合最优解。

1️⃣ 为什么不能只看"最强"？

场景 A: 客服对话 Agent    场景 B: 离线数据分析 Agent
──────────────────    ─────────────────────
需要毫秒级响应         可以等几分钟出结果
对延迟极度敏感        更看重准确率
预算有限              可以接受较高成本

最强模型不一定适合你的场景！

2️⃣ 四大打分维度

维度 1：吞吐量与延迟 ⏱️

推理分两阶段：
├─ Prefill（预填充）→ 一次性读完整上下文
│   决定 TTFT (首字延迟) ← 用户感知的"反应快慢"
└─ Decode（解码）→ 逐 token 生成回答
    决定 tokens/秒 → 决定思考时长

指标	含义	影响
TTFT	排队时间 + Prefill 时间	第一个字出现要多久
输出速度	tokens/秒	写报告要多长时间
思考延迟	思考 token 数 × 生成速度	思考越久，成本越高
p95 尾部延迟	95% 的请求不超的延迟	比平均值更能反映真实体验

注意： 不同模型的思考 token 数差异可达数倍！不要凭榜单推断，要在自己的工作负载上实测。

维度 2：成本 💸

简单任务：选便宜模型
复杂任务：选强模型但可能重试多次

总成本 = 模型费用 × 平均轮次 × (1 + 重试率)

误区： "A 模型比 B 便宜 50%，所以选 A"
真相： 如果 A 成功率只有 60%，B 是 90%

A 实际成本 = 1 × (1/0.6) =1.67
B 实际成本 = 2 × (1/0.9) =2.22
A 反而更贵！

正确做法： 计算每个任务的平均成本和成本 - 性能比

维度 3：性能 📊

根据任务类型选择不同指标：

任务类型	用什么指标	为什么
日常场景	Pass@1	单次平均成功率
关键操作（退款、转账）	Pass^k	稳定性最重要
探索性任务	Pass@k / Best@k	看能力上限
开放式任务	Rubric 多维度评分	综合质量

维度 4：可靠性 🔒

RPM（每分钟请求数）
TPM（每分钟 token 数）

API 在高峰期会动态调整限额
需要考虑：
- 分布外数据能否处理
- 对抗性输入鲁棒性
- 长时运行稳定性（有没有模式崩溃、注意力分散）

3️⃣ Agent 系统的成本分析（重点！）

Agent 的成本远比简单的 token 定价复杂——多轮推理、工具调用和上下文累积会使成本呈非线性增长。

成本的三层构成

① 模型推理成本

直接成本：输入 token × 单价 + 输出 token × 单价

放大因素：
1. 上下文累积效应
   第 1 轮：1000 token
   第 2 轮：2000 token（含上轮历史）
   第 3 轮：3000 token（含前两轮历史）
   总计：6000 token ≠ 3 × 1000

2. 思考 token 成本
   每轮额外生成 500-2000 个思考 token
   虽然不展示给用户，但同样计费

② 工具调用成本

外部 API 费用：
- 搜索引擎按次计费
- 数据库查询消耗计算资源

间接成本：
一次网页搜索返回 2000-5000 token
后续每轮都要为这些 token 付费

③ 基础设施成本

向量数据库、消息队列、关系型数据库、日志存储...

4️⃣ 实战案例：三轮客服 Agent 成本拆解

客服退款流程：
用户问退款 → 查订单 → 判断政策 → 发起退款 → 回复结果

| 轮次 | 操作                     | 输入 token | 输出 token | 成本   |
|:----:|-------------------------|----------|----------|--------|
| 1    | 系统提示 + 用户问题       | 2,500    | 150      | $0.0098 |
| 2    | 上轮全部 + 工具返回       | 3,200    | 120      | $0.0060 |
| 3    | 上轮全部 + 退款结果       | 3,800    | 200      | $0.0058 |
| 合计 |                         | 9,500    | 470      | $0.022 |

如果没有 KV Cache：

输入成本：$0.029（无折扣）
加上输出：$0.036

有 KV Cache：

缓存命中部分按 10% 计费
节省了近一半输入费用 ✅

放大因素：

启用思考模式 → 成本翻 3-5 倍
工具返回大量内容 → 后续每轮继续计费
Agent 走弯路 10 轮 → 上下文累积到 20,000+ token

结论：成本优化的核心不在于选便宜的模型，而在于控制轮次和上下文增长。

5️⃣ 三大成本优化策略

策略 1：KV Cache 复用

保持前缀稳定：
- 系统提示词不变 → 重复使用缓存
- 工具定义不变 → 共享缓存
- 历史轮次保留 → 避免重复计算

效果：降低 30%-60% 的输入 token 成本

策略 2：上下文压缩

压缩历史轨迹：
- 摘要总结旧对话
- 截断冗余的工具返回

长任务中效果尤为显著

策略 3：模型分层路由

if task.is_simple():
    model = lightweight_model  # 用轻量模型省钱
elif task.is_complex():
    model = powerful_model     # 复杂任务用强力模型
elif task.needs_vision():
    model = multimodal_model   # 视觉任务用专门模型

6️⃣ 进阶手段

异步批处理

将非实时任务积攒起来批量处理：

利用 API 提供商的批量定价折扣
提高 GPU 利用率（波谷时段）

成本监控与预算控制

实时监控：
- 按任务类型追踪 token 消耗
- 按用户统计 API 费用
- 按模型对比成本绩效

设置单任务成本上限：
防止 Agent 陷入循环产生异常费用

7️⃣ 评估驱动的持续迭代

模型选择不是一次性的，而是动态调整的过程。

场景： Gemini 新发布，公开基准超越 Claude，定价更低

决策框架：

在我的特定任务上，Gemini 是否比 Claude 好？
→ 跑一遍自己的评估集
好多少？
→ Pass@1、Pass^k、成本等各是多少？
切换成本是什么？
→ Prompt 要改吗？工具要适配吗？团队要培训吗？

结论： 只有在自己的评估数据集上测试，才能做出数据驱动的升级决策。

📝 快速总结

维度	关键点
吞吐量与延迟	TTFT、思考延迟、p95 尾部延迟
成本	输入×输出×轮次，成功率和重试率很重要
性能	Pass@1（日常）、Pass^k（稳定）、Rubric（开放）
三大优化	KV Cache、上下文压缩、模型分层路由
持续迭代	定期在自己的评估集上测试新模型

📊 统计显著性：深入拆解

一句话总结

"新模型 73% vs 旧模型 70%"这 3% 的提升可能是随机波动——统计显著性就是判断：这点差异值不值得当真？

1️⃣ 先看问题：噪声比信号大

在 100 个测试用例上，模型 A 成功率 70%

标准误 ≈ √(0.7 × 0.3 / 100) ≈ 4.6%
95% 置信区间：70% ± 9%

也就是说：
- 下次再测，结果可能在 61% ~ 79% 之间波动
- "新模型 73% vs 旧模型 70%"的 3% 差异
  → 完全落在噪声带宽内！
  → 换模型可能跟掷硬币一样随机

结论：分差小于噪声带宽时，不要做切换决策！

2️⃣ 标准误公式

在 n 个测试用例上，成功率 p 的标准误：
  SE = √(p × (1-p) / n)

直觉理解：
- 样本越多（n 越大）→ 标准误越小 → 越可信
- 成功率越接近 50% → 标准误越大 → 越不可信

n	成功率	标准误	95% 置信区间
50	70%	6.5%	70% ± 13%
100	70%	4.6%	70% ± 9%
400	70%	2.3%	70% ± 4.5%

样本从 100 扩到 400 → 噪声才减半 → 扩样成本很高！

3️⃣ 配对分析：更灵敏的正确方法

独立比较两个成功率太粗糙了。更好的方法是配对分析：

同一批题目，两个配置各跑一遍：

          配置 A  配置 B
题目 1：   ✅      ✅      ← 都对了，没信息
题目 2：   ✅      ❌      ← A 对 B 错！
题目 3：   ❌      ✅      ← B 对 A 错！
题目 4：   ❌      ❌      ← 都错了，没信息

只看结果不同的题目（题目 2 和 3）：
  A 赢 B：1 次
  B 赢 A：1 次
  → 用 McNemar 检验
  → 两个配置差不多

为什么要配对？
→ 排除了"题目本身难易"这个共同噪声
→ 在相同样本量下比独立比较灵敏得多

4️⃣ 多次运行取均值

Agent 还有额外的非确定性：

同一模型、同一数据集、两次运行：
→ 分数也可能漂移

原因：
- 温度采样带来随机性
- 工具返回的波动
- 环境时序差异

对策：每个配置跑 3-5 次，报告均值和波动范围

5️⃣ 多重比较陷阱

最容易被忽视的统计坑！

并行验证 6 个假设，每个用 95% 置信度：

至少踩中一个假阳性的概率：
= 1 - 0.95^6
= 1 - 0.735
= 26.5%

→ 每 4 次"发现显著提升"中就有 1 次是纯巧合！

防范手段：

收紧门槛：对多假设场景调严显著性阈值（如 Bonferroni 校正）
独立复现：跑出来的正向结论，再做一次独立验证

6️⃣ 实战：从 Benchmark 到系统改进

以 Android 自动化 Agent 评估为例：

Step 1：读懂报告

总体成功率 70%？
  → 不重要！关键是结构性短板

按能力维度分解：
├─ 常规操作：100% ✅
├─ 短信回复：10%⚠️
├─ Wi-Fi 开关：0%❌
├─ 待办事项查询：0%❌
├─ 转录视觉信息：0%❌
├─ 数学计数：0%❌
└─ 复杂 UI 理解：17%❌

Step 2：构建假设

表层（低成本，可并行验证）：
  H1: 为 Wi-Fi 增加导航提示
  H2: 为待办应用提供 UI 识别规则

中层（同样独立并行）：
  H3: 修复多模态输入管道
  H4: 全局启用思考模式

深层（成本高，仅表层中层不够时才启动）：
  H5: 换更强视觉模型（GPT-5）
  H6: 截图外增加 UI 元素树

Step 3：跑实验 + 统计检验

每个配置跑 5 次（不同随机种子），记录：
- 成功率均值和范围
- 平均步数
- 执行时间和成本

对每组变化做配对分析（McNemar）

Step 4：数据驱动决策

假设结果（数据为假设值）：

H1: 设置类 0% → 75%，输入 token +8%    → ✅ 采纳
H2: 待办类 0% → 60%，UI 规则维护成本高 → ⚠️ 部分采纳
H3: 转录 0% → 80%，但延迟 +1 秒/步     → ✅ 采纳（收益远大于成本）
H4: 计数 0% → 70%，但延迟 4s→12s，成本 ×3 → ❌ 拒绝
H5: complex_ui 17%→35%，但延迟 ×3.75     → ❌ 太慢
H6: complex_ui 17%→52%，token +30%        → ✅ 延迟可控，采纳

7️⃣ 核心原则总结

原则 1：分差小于噪声带宽 → 不做切换
原则 2：用配对分析（逐题比较）而非独立成功率相减
原则 3：每个配置跑 3-5 次，报告均值 + 波动范围
原则 4：多假设并行 → 收紧门槛或独立复现
原则 5：样本不够 → 先扩样集，再继续迭代

posted @ 2026-08-03 22:13 may233 阅读(6) 评论(0) 收藏举报

刷新页面返回顶部

Ai-study-chapter6

📘 第 6 章：Agent 的评估 — 通俗讲解

🎯 一句话总结

1️⃣ 为什么要评估？

2️⃣ 评估三层次

3️⃣ 一个具体评估示例

4️⃣ 关键指标：Pass@k vs Pass^k

5️⃣ LLM-as-a-Judge：用 LLM 当评委

6️⃣ 模型替换实验：区分瓶颈在哪

7️⃣ 进度追踪 vs 最终结果

📝 快速总结

🎯 LLM-as-a-Judge：深入拆解

一句话

为什么需要 LLM-as-a-Judge？

Rubric 四准则（核心！）

准则 1：基于专家指导

准则 2：全面覆盖 + 陷阱识别

准则 3：权重分级 + 一票否决

准则 4：自包含评估

完整 Rubric 示例

评测流程

三大陷阱与防范

陷阱 1：长度偏差

陷阱 2：同源模型偏见

陷阱 3：奖励作弊

多模态 LLM-as-a-Judge

Pass@k 与统计显著性

一句话记住

🏆 Elo 评分与配对比较

一句话总结

为什么要用 Elo？

绝对评分的问题

Elo 的优势

Elo 工作原理

基本机制

Bradley-Terry 模型：背后的数学

Chatbot Arena：最著名的应用

三大陷阱与防范

陷阱 1：位置偏差

陷阱 2：样本偏差

陷阱 3：训练数据污染

Elo 实战代码

从评估到训练：GRPO 算法

💰 模型选型与成本分析：深入拆解

一句话总结

1️⃣ 为什么不能只看"最强"？

2️⃣ 四大打分维度

维度 1：吞吐量与延迟 ⏱️

维度 2：成本 💸

维度 3：性能 📊

维度 4：可靠性 🔒

3️⃣ Agent 系统的成本分析（重点！）

成本的三层构成

① 模型推理成本

② 工具调用成本

③ 基础设施成本

4️⃣ 实战案例：三轮客服 Agent 成本拆解

5️⃣ 三大成本优化策略

策略 1：KV Cache 复用

策略 2：上下文压缩

策略 3：模型分层路由

6️⃣ 进阶手段

异步批处理

成本监控与预算控制

7️⃣ 评估驱动的持续迭代

📝 快速总结

📊 统计显著性：深入拆解

一句话总结

1️⃣ 先看问题：噪声比信号大

2️⃣ 标准误公式

3️⃣ 配对分析：更灵敏的正确方法

4️⃣ 多次运行取均值

5️⃣ 多重比较陷阱

6️⃣ 实战：从 Benchmark 到系统改进

Step 1：读懂报告

Step 2：构建假设

Step 3：跑实验 + 统计检验

Step 4：数据驱动决策

7️⃣ 核心原则总结

公告