李乾坤

AI、系统与工程实践

1 分钟阅读

简介(未完成)

Agent评估采用三层金字塔模型，按重要性和实施优先级划分：

  1. 第一层：核心能力，规划、工具使用、推理、记忆
  2. 第二层：应用效果 ，任务完成、输出质量、用户满意度
  3. 第三层：生产就绪度，成本、延迟、安全、稳定性

评估什么

核心能力评估（第一层）

规划与推理能力，Agent能否将复杂任务分解并逐步执行

  1. 任务完成进度 = 已完成步骤/理想步骤数
  2. 正确选择工具比例 = 正确调用/总调用
  3. 遇错误后调整能力 = 成功恢复次数/错误次数

工具使用能力，Agent能否正确调用和组合各种工具：L1: 单工具调用 → L2: 顺序调用 → L3: 并行调用 → L4: 动态发现

  1. 工具名称+参数正确性
  2. 优先使用API而非浏览器
  3. 工具组合效率：最少调用达成目标

记忆管理能力，Agent能否维护和利用长期记忆

  1. 准确检索，从历史中提取正确信息
  2. 在线学习，对话中新增学习
  3. 长程理解，跨多轮维持一致性
  4. 选择遗忘，过滤无关信息

自我反思与改进能力，Agent能否从反馈中学习并改进

  1. 初次尝试 → Agent执行任务（可能失败）
  2. 提供反馈 → 给出错误原因或改进建议
  3. 二次尝试 → Agent根据反馈重新执行
  4. 评估改进 → 计算Reflection Score

应用效果评估（第二层）

Agent是否达成业务目标

  1. 完全成功
  2. 部分成功
  3. 功能完成
  4. 完全失败

Agent输出内容的质量

  1. 准确性
  2. 相关性
  3. 完整性，是否覆盖所有要点，关键点检查清单
  4. 可用性，用户能否直接使用

如何评估

评测的最主要价值是：把产品负责人（以及产品团队）的目标和用户的实际需求进行量化，而量化的手段就是构建评测数据集。目前的AI应用面对的场景如此之复杂，以至于很难写出一个reward的规则方式进行评价。特别是需要考虑的输入数据分布很难通过其他方式描述，最终都只能转化为一个数据集来进行量化表示。

  1. 机评与人评。在实际应用中，能完全量化为单个选项或者数值的任务并不多，不少任务都是给出一种非结构化的文本输出。这种情况下，就很难机械地对其进行自动化评估。一般我们会使用构建一个评估workflow（或单个prompt），来进行评估。
  2. 难点：首先评估的维度经常需要显式的列出并进行定义，但要把产品负责人的产品sense、或者是对用户群对于产品效果的期望精确地转换为评估维度的描述实际上非常难，大多数时候只能把能描述清楚的部分描述清楚，放弃剩下的部分。
  3. 评测方案是会过时的

单轮评估很简单：一个提示、一个响应和评分逻辑。PS: query + Response + 打分逻辑

  1. 任务（也称为问题或测试用例）是具有定义输入和成功标准的单个测试。
  2. 每个任务的尝试是一个试验。由于模型输出在运行之间会有所不同，我们运行多个试验以产生更一致的结果。
  3. 评分器是对智能体某些方面表现进行评分的逻辑。一个任务可以有多个评分器（评估体系从“对错二分”转向“多维度量”），每个评分器包含多个断言（有时称为检查）。对于每个任务，评分可以是加权的（组合评分器分数必须达到阈值）、二进制的（所有评分器必须通过）或混合的。
  4. 基于代码的评分器
  5. 基于模型的评分器
  6. 人类评分器
  7. 记录（也称为跟踪或轨迹）是试验的完整记录，包括输出、工具调用、推理、中间结果和任何其他交互。
  8. 结果是试验结束时环境的最终状态。预订航班的智能体可能在记录结束时说”您的航班已预订”，但结果是在环境的SQL数据库中是否存在预订。 评估框架是端到端运行评估的基础设施。它提供指令和工具，并发运行任务，记录所有步骤，对输出进行评分，并汇总结果。

每个任务都有自己的成功率——一个任务可能是90%，另一个任务可能是50%——而在一次评估运行中通过的任务可能在下次失败。有时，我们想要测量的是智能体多频繁（试验成功的比例）成功完成一个任务。两个指标有助于捕捉这种细微差别：

  1. pass@k衡量智能体在k次尝试中至少获得一个正确解决方案的可能性。
  2. pass^k衡量所有k次试验成功的概率。如果您的智能体每次试验成功率为75%，并且您运行3次试验，通过所有三次的概率是(0.75)³ ≈ 42%。这个指标对于用户期望可靠行为的面向客户智能体尤其重要。 随着试验次数的增加，pass@k和pass^k出现分歧。在k=1时，它们是相同的（都等于每次试验的成功率）。到k=10时，它们讲述了相反的故事：pass@k接近100%，而pass^k下降到0%。两个指标都很有用，使用哪个取决于产品要求：对于工具一次成功重要的用pass@k，对于一致性至关重要的智能体用pass^k。

评估从代码检查升级为真实用户式验收。

Evaluator 不只看代码，还会用类似 Playwright MCP 的方式去点 UI、测 API、看数据库状态，再按产品深度、功能、视觉设计、代码质量打分。这个很像把 QA/产品验收前置进 agent loop。

其它

多轮对话评估

  1. 为了评估模型在第二轮（Turn 2）的表现，你发送给 LLM 的 messages 列表必须包含完整的“对话历史”（多轮同理）。 
      User (Q1)
  Assistant (A1) <-- 模型之前的真实输出
  User (Q2) <-- 新的刁难/追问
  2. 那么问题来了：
  3. 错误传播。如果 A1 输出的质量较差，导致 Q2 与 A1 可以说毫无关系，这样的情况下评估 A2 还有意义吗？对于任务完成度来说，通常没有意义；但对于考察模型的“鲁棒性”和“挽救能力”有一定意义。
  4. 评测模式 (Teacher Forcing vs. Free Generation)。 将 A1 替换为 Ground Truth (标准答案) 再测 Q2，是标准做法之一吗，有什么价值？如果你是在做通用的 Leaderboard 评测（评估真实对话能力），请严格使用模型自己的输出作为历史；如果你是在Debug 模型的某项特定技能（如长文本精炼），请使用 Ground Truth 以隔离。

AI Agent 评估应该怎么做对于评估不是简单的让地让 AI Judge 打个 1-5 分，这样做显然效果会很差，评估体系，评估方法，甚至评估标准都没明确说明， 即使是再牛逼的AI Judge也无法做好整个评估体系。所以我们应该把这个问题拆细了看，开放式任务评估 = 硬规则检查 + 事实检查 + 语义覆盖 + 主观质量评分 + 版本对比 + 人工抽检

  1. 硬性规则评估 deterministic check。输出是否是合法 JSON？是否包含必须字段？是否调用了正确 tool？是否调用了禁止 tool？是否超过 token 限制？是否包含敏感词？是否引用了不存在的 source？是否返回了空答案？
  2. 关键点覆盖 Reference-based。这层用于判断模型有没有覆盖标准答案里的关键点。比如可以给每个测试 case 写一个 reference answer，或者更工程化一点，写成 required facts。例如： 
      {
 "query": "用了 20 天耳机坏了可以退吗？",
 "required_facts": [
   "超过 7 天无理由退货期限",
   "质量问题可申请维修或换货",
   "需要提交售后申请"
 ],
 "forbidden_claims": [
   "可以直接退款",
   "一定可以退货",
   "补偿优惠券"
 ]
  }

    然后评估：required_facts_coverage = 覆盖了几个必要事实; forbidden_claims_count = 出现了几个禁止说法

  3. 事实评估 Groundedness / Faithfulness. 模型说的每一句事实，是否都能被 context 支持？
  4. 主观质量评估 AI judge. 有些维度没法完全用代码判断，比如：是否有帮助？是否解释清楚？是否安抚了用户情绪？是否给了下一步行动？这时候主要靠 AI Judge ，但 judge prompt 必须明确标准。使用 AI judge 时要说明任务、评价标准、评分系统；而且分类式评分通常比连续数值评分更可靠。例如你可以不要让它打 0.73 分，而是让它分类： ``` 请评估回答是否满足“客服可上线标准”。 评价维度：
  5. 是否直接回答用户问题
  6. 是否给出明确下一步
  7. 是否语气专业、不过度承诺
  8. 是否没有多余营销话术

输出：

  • pass / fail
  • failed_dimensions
  • reason

    { “pass”: false, “failed_dimensions”: [“不过度承诺”, “政策准确性”], “reason”: “回答承诺可以退货/退款，但知识库只支持维修或换货。” } ```

    1. 版本对比评估 pairwise comparison

留下评论

猜您还喜欢

Code Agent

2 分钟阅读

简介（未完成）