【Agent智能体18 | 构建AI工作流的技巧-评估】
声明：本篇博客是以吴恩达的【Agent智能体】教程为基础，并对其中的内容做了笔记整理以及个人收获的总结。
从这篇开始，将会分享一些构建agentic AI workflows的使用技巧。这一篇主要是讲解评估系统的方法。
在开发系统的时候，我们很难提前判断系统在哪些地方能正常运行，哪些地方表现不佳。因此很难决定该将精力重点放在哪里
花太长时间空想如何构建系统其实并没有什么用的，常见的做法是这样的：先快速构建出一个粗糙的系统，然后就可以实际测试，并观察系统在哪些方面还未达到你的预期效果，从而针对性的投入精力，推动后续开发，进一步完善系统。
例子1“发票处理工作流” (The Invoice Processing Workflow)
目标：系统需要从发票中准确提取出4个必填字段：
- Biller（账单方/开票方）、Biller address（账单方地址）、Amount due（应付金额）、Due date（到期日期）。
工作流设计 (Workflow)：
将收到的发票PDF转化为文本（PDF to text）。
将文本交给大语言模型（LLM）。
LLM提取出信息后，调用“更新数据库”的工具（Tools: update database），最终生成一条记录（Record created!）。
测试与暴露出的问题：
- 左侧的红框：这是一张真实的测试发票，上面同时印着
Due Date: August 20, 2025和Invoice Date: August 6, 2025。 - 右下角的测试表格：开发者拿了10-20张发票跑了这个原型系统，结果发现了一个高频错误——Mixed up dates（日期混淆）。
- 因为发票上有两个日期，LLM在实际运行中经常把“开票日”误认作“到期日”。
- 左侧的红框：这是一张真实的测试发票，上面同时印着
这个例子说明的核心观点如下：
要让真实的输出指导你的优化方向：
- 快速搭建一个原型系统并查看输出结果非常有帮助。就像图里那样，只有当你真拿了十几张发票跑了一遍系统后，你才会发现原来地址提取没出错，是两个日期离得太近让AI犯了迷糊！然后就可以思考：”如何改进系统，使其能更好的提取到期日期？“
把精力花在构建针对性的评测（Evaluation）：
- 当你发现了具体错误之后，可以写一个评测，用于衡量系统提取到期日期的准确率（见下图）
总结：先快速搭个简易版（Prototype） -> 喂入真实数据观察它在哪出错（Error Analysis） -> 针对出错最严重的地方建立专项测试股（Evaluation） -> 迭代优化系统直到考试及格。问题在哪里，你的评测和优化重点就应该在哪里。
这个例子中，我们可以发现日期是当前痛点，既然日期提取是现在的最大痛点，那我们接下来的工作重心，就是专门针对“到期日期”写一个评测系统，用来量化我们的改进效果，具体如下。
写一个评测方法来衡量系统提取到期日期的准确率
现在假设你决定要修改系统，提高其提取发票到期日期的准确率，那么为了跟踪进展，你可与考虑创建一个评测方法，用来衡量日期提取的准确率，实现这一目标方法可能有多种选择，如图：
这个图展示了如何一步一步地构建这个自动化评测系统。整个评测过程为4个标准步骤：
Manually extract due dates from 10-20 invoices (从10-20张发票中手动提取到期日期)。
- 需要人类先看这十几张发票，把正确的到期日期找出来。比如把发票上的
"August 20, 2025"转换成标准格式"2025/08/20"
- 需要人类先看这十几张发票，把正确的到期日期找出来。比如把发票上的
Specify output format of data in prompt (在提示词中指定数据的输出格式)。
- 在给大模型（LLM）发指令时，要明确加上一句：
Format the due date as YYYY/MM/DD（请将到期日期格式化为 年/月/日）。统一输出格式是为了方便后续用代码进行自动化比对
- 在给大模型（LLM）发指令时，要明确加上一句：
Extract date from the LLM response using code(使用代码从LLM的响应中提取日期)。
- 图中展示了一段简单的Python代码。使用了正则表达式 (Regular Expression)
r'\d{4}/\d{2}/\d{2}' - 像筛子一样，只把符合
4个数字/2个数字/2个数字这种特定格式的文本抓取出来，忽略掉前后的废话
- 图中展示了一段简单的Python代码。使用了正则表达式 (Regular Expression)
Compare LLM result to ground truth (将LLM结果与基准真实值比较)。
- 用代码写一个简单的判断语句：
if (extracted_date == actual_date): num_correct += 1（如果AI提取的日期完全等于人工整理的标准答案，答对数量就加1）。
- 用代码写一个简单的判断语句：
这就是一个LLM自动化评测流水线 (Evaluation Pipeline)的标准做法，有了这个脚本，以后你无论怎么修改Prompt（提示词），或者换用更高级的模型，只要运行一下这个代码，就能瞬间知道准确率是提升了还是下降了。
总结：用评测来驱动开发过程 (Driving your development process with evals)
发现问题 (Discovery)
- Build a system and look at outputs to discover where it is behaving in an unsatisfactory way (E.g. incorrect due dates in invoice data extract).
- 第一步，不要追求完美，先快速搭建一个系统原型，然后直接看它的输出结果，找出表现糟糕的地方。
- 这正是第一张图做的事情——我们跑了发票提取原型，发现了“到期日期提取错误”这个致命伤。
- Build a system and look at outputs to discover where it is behaving in an unsatisfactory way (E.g. incorrect due dates in invoice data extract).
量化基准 (Measurement)
- Drive improvement by putting in place a small eval with ~20 examples to help you track progress.
- 第二步，为了解决发现的问题，不要盲目去改代码，而是先建一个小型的“评测集”（大概挑20个典型的例子就好）。有了这个评测集，你就能清晰地追踪你的改进进度。
- 这正是第二张图做的事情——针对日期错误，我们手工标了标准答案，写了代码，做成了一个包含几十张发票的测试集
- Drive improvement by putting in place a small eval with ~20 examples to help you track progress.
迭代优化 (Iteration & Optimization)
- Monitor as you make changes to workflow (e.g. new prompts, new algorithms) and see if the metric improves.
第三步，开始动刀子修改你的工作流（比如尝试写一个更复杂的提示词，或者引入新的算法逻辑）。每改一次，就拿第二步建好的评测集跑一遍，看看“准确率”这个指标是不是真的上升了。
不要靠“感觉”去猜提示词有没有变好，要靠数据和指标 (metric)说话。
- Monitor as you make changes to workflow (e.g. new prompts, new algorithms) and see if the metric improves.
当你工作一段时间发现最初的样本不够好，可以随时不断扩充评估集，确保能够更好的反映的你个人的判断标准。
这也是目前构建AI应用最主流的“评测驱动开发”（Eval-driven development）模式。
例子2：创建一个营销文案助手
- 业务：这是一个多模态的营销文案助手原型。输入产品图片（如墨镜、咖啡机）和用户的指令，让LLM生成对应的营销文案。
- 硬性约束 (Length guidelines)：业务要求生成的Instagram文案最多不能超过10个单词(10 words max)。
- 测试暴露问题：拿着原型跑了几个产品测试（右侧表格），发现了一个高频错误——大模型很难严格遵守字数限制。给墨镜写的文案有17个词，衬衫14个词，搅拌机11个词，统统超标（Fail），只有咖啡机和帽子勉强过关。
既然你发现了他在遵循长度规范方面有困难，后续就可以构建一个评估方法来跟踪这个问题，以便改进并确保模型在这方面变得更好
针对文本生成程度创建一个评测方法
这个图展示了如何用代码写一个专门针对“字数限制”的自动化评测脚本。相比于之前的发票日期评测，这个流程更加精简，分为3步：
- 准备考题 (Create test tasks)： 挑10到20个产品图片，配上标准的提示词（比如：“创建一篇Instagram帖子”），组成你的基础测试集。
- 用代码测量输出 (Measure word count)： 这里用了一行极简的Python代码：
word_count = len(text.split())。它的逻辑是拿到大模型生成的文案后，直接按空格切分并计算单词总数，代替人工去数数。 - 自动化判卷打分 (Compare to limit)： 判分逻辑更加简单粗暴：
if (word_count <= 10): num_correct += 1。只要生成的字数小于等于10，就算答对；否则算错。
把这个“文案助手”案例和上一个“发票提取”案例放在一起看，会发现一个非常巧妙的工程学差异：
- 发票提取 Eval：需要人类先辛辛苦苦找出日期的“标准答案 (Ground Truth)”，然后才能让代码去比对。
- 文案长度 Eval：根本不需要人工准备“标准答案”。它的评测标准是一个绝对的数学规则（<=10）。
这揭示了大模型应用开发中一个非常实用的技巧：用传统、确定性的代码逻辑（如字数统计、格式校验），去自动化约束和评测非确定性的AI大模型。
有了这个自动判卷脚本，你接下来就可以放心地去疯狂修改Prompt（比如加上“严格限制10词以内，否则扣钱”之类的强硬提示），然后一键运行脚本，看准确率是否飙升。
这种评估方法也可以用于更复杂的生成流程，例子如下。
例子： "研究助手 (Research Agent) "
场景：评估一个多步执行的“智能体 (Agent)”写出的长篇内容的好坏。
这不是一个简单的“一问一答”聊天机器人，而是一个Agent（智能体）工作流。当你抛给它一个研究主题时，它会按顺序做这几件事：
- 搜索 (web search)：调用搜索引擎查找相关资料。
- 抓取与阅读 (web fetch & PDF to text)：挑选出排名前5的优质信息源，把网页和PDF下载下来并读取内容。
- 撰写 (Write essay draft)：LLM综合这5篇资料，为你写出一篇研究报告的初稿。
测试暴露出了什么问题？（看下方的表格）
开发者拿了几个不同领域的话题去测试这个 Agent，结果发现了一个非常主观且致命的问题：它写的东西看着挺像模像样，但总是漏掉关键信息。
- 让它写“最近的黑洞科学”，它漏掉了近期新闻里铺天盖地的重大发现。
- 让它写“果园采摘机器人”，它竟然没提到该领域最头部的设备公司。
- 核心痛点（右侧文字）：“Sometimes misses points a human would have made”（有时会漏掉人类专家肯定会提到的关键点）。
引入高级评测法 —— “让 LLM 当裁判 (LLM-as-a-judge)”
针对上述的“遗漏症”，该怎么写评测呢？这里不能再用写代码数单词，或者用正则表达式提取了，因为长篇幅的文章千变万化。
终极绝招：LLM-as-a-judge（让大语言模型来做评测法官）。图里拆解了 3 个步骤：
1: 提炼“黄金知识点” (Choose gold standard discussion points)既然我们嫌它“漏掉关键点”，那我们在考它之前，人工先写出这道题必须包含的 3-5 个核心关键词。
- 比如针对你要测试的题目（比如写一篇关于“黑洞”的文章），人类只需要写下 3-5 个必须包含的“黄金知识点（Gold-standard talking points）”。比如黑洞文章必须提到“事件视界 (Event horizon)”和“射电望远镜 (radio telescope)”。这就叫“Ground truth annotations”（基准事实标注）。相当于老师阅卷时的“踩分点”。
2: 用另一个 LLM 来当阅卷老师 (Use LLM-as-a-judge)图右侧灰色的框，是一个专为评测而写的 Prompt（提示词）。你把 Agent 刚写完的报告，连同你第一步准备的“黄金知识点”，一起喂给一个专门当裁判的 LLM，让它帮你阅卷。
任务指令：判断提供的文章中包含了多少个黄金标准知识点。
输入变量：
{original_prompt}：当初考学生的题目。{essay_text}：学生（你的 Agent 系统）交上来的文章。{gold_standard_points}：你刚才在动作 1 里写的“踩分点”。
强制输出格式 (Output Format)：要求 LLM 必须输出一个 JSON 格式。包含
score（0-5 的纯数字得分）和explanation（给出打分的理由）。- 为什么必须用 LLM 当裁判？因为文章中可能没有出现一模一样的词（比如它写了“捕捉电波的设备”，而你的标准答案是“射电望远镜”）。只有 LLM 能理解语义，判断这两个东西是一回事。
3: 得出总分 (Get score)因为你在动作 2 里强制要求了输出
{ "score": 3, "explanation": "..." }这样的 JSON 格式，你的 Python 代码就可以轻松提取出所有的分数，遍历你的评测集，裁判 LLM 会给每一篇报告打分，最后算出你的系统平均得分
评测方法的进化
看完了这三个案例，你会发现吴恩达展示了 AI 评测方法论的一个清晰的进化阶梯：
- 发票提取：精确匹配（正则代码对比）
- 文案长度：规则校验（计算单词总数）
- 研究报告：LLM-as-a-judge（利用强大模型的语义理解能力，来评估复杂、主观的输出质量）。
当你掌握了 “LLM-as-a-judge”，你就拥有了优化复杂 Agent 系统的终极武器。你可以开始调整 Agent 搜索关键词的策略，然后让“裁判 LLM”看看分数是不是涨了。
评估的两个“维度”
为了思考如何为你的应用构建评估体系，你构建的评估体系通常需要反映你在应用中关注或担心出错的地方，结果发现评估大致分为两个主要维度。
这些有时也被称为端到端评估
如图建立了一个2x2 的矩阵模型，把大模型应用开发中千奇百怪的“评估（Eval）”方法，高度抽象成了两个核心维度（Two “axes”）。只要你做 AI 评测，你的方法一定落在这个四个格子里的某一个。
详细拆解这个矩阵的两个维度和四个象限：
维度一：横轴 —— “裁判”是谁？ (Objective vs. Subjective)
横轴决定了你用什么工具来打分：
左列 - 用代码评估 (Evaluate with code - objective)：代表客观、死板、确定性。答案非黑即白，用 Python 的
if/else、正则表达式或者算术逻辑就能直接判断对错。右列 - 让 LLM 当裁判 (LLM-as-judge - subjective)：代表主观、灵活、语义化。答案没有绝对的唯一解，需要大模型像人类考官一样，去阅读、理解并给出评分。
维度二：纵轴 —— 有没有“标准答案”？ (Ground Truth)
纵轴决定了你需不需要提前准备答案：
上行 - 每个样本都有标准答案 (Per example ground truth)：你必须人工为每一道测试题写下绝对正确的“参考答案”。
下行 - 不需要标准答案 (No per example ground truth)：你不提供参考答案，而是提供一种“通用规则”或“评分标准”。
四个象限：对号入座（结合我们之前的案例）
左上角：用代码评 + 有标准答案
案例回顾：检查发票日期提取。
逻辑：你有一张发票，你人工写下标准答案
2025/08/20。然后用代码if (extracted == actual)去死磕匹配。错一个字符都不行。
左下角：用代码评 + 无标准答案
案例回顾：检查营销文案字数。
逻辑：你不需要事先写一篇满分文案（因为文案可以有无数种写法）。你只给代码定一个死规矩：
if len(text) <= 10。只要不超字数，就算过关。
右上角：LLM当裁判 + 有标准答案
- 案例回顾：计算研究报告中的黄金知识点。
- 逻辑：你事先写下几个必须提及的词（如“射电望远镜”）。因为文章很长、表述千变万化，代码死板匹配不了，所以你要派“LLM 裁判”出场，让它去判断生成的长文中是否包含了你要求的这些语义点。
右下角：LLM当裁判 + 无标准答案
- 案例：根据评分量表 (rubric) 给图表打分。
- 逻辑：假设你让 AI 生成一个数据图表。你不需要画一个标准图表让它对比，你只需要给“LLM 裁判”一段详细的打分规则（Rubric）：“请根据以下标准给这张图表打分：(i) 是否有清晰的坐标轴标签？(ii) 颜色对比度是否明显？…” 让 LLM 完全基于规则进行主观阅卷。
总结：如何设计端到端评测 (end-to-end evals)
1. 先跑起来系统
- Quick and dirty is ok to start! (一开始“简单粗暴”一点完全没问题！)
- 解析：很多开发者在刚开始做评测时容易陷入“分析陷阱”，觉得必须找几千条完美标注的数据才能开始。吴恩达告诉你：大可不必。就像我们在发票案例里看到的，起手只需要手动标 10 到 20 个例子就足够了。你的第一版评测可以很粗糙（dirty），但必须得快（quick），因为只有先让这个“评估-反馈”的飞轮转起来，你才知道下一步该往哪里发力。
2. 评测系统本身也需要不断迭代
- As you find places where your evals fail to capture human judgement as to what system is better, use that as an opportunity to improve the metric.
- 解析：这句话非常核心。它指出了一种常见情况：有时候你的 AI 生成了一篇人类觉得很烂的文章，但是你的自动化评测程序（比如 LLM-as-a-judge）却给了满分。这时候怎么办？
- 不要觉得气馁，这是一个改进你“评测指标 (metric)”绝佳机会。
- 你的评测系统和人类的主观判断出现了“对齐偏差”。这时你应该去修改那个评测标准（比如细化裁判 LLM 的打分规则 Prompt），直到你的评测系统打出的分数，能和人类专家的直觉完全吻合为止。评测工具本身，也是一个需要优化的产品。
3. 寻找那些系统表现不如人类的地方
- Look for places where performance is worse than humans.
- 解析：在一条复杂的 AI 工作流中（比如之前的研究助手 Agent），你该优先对哪个环节建立评测？
- 答案是：挑那些 AI 明显做得比人类差的地方。
- 例如，人类一眼就能分辨发票上的“开票日”和“到期日”，但 AI 却常常混淆。这种“人类觉得很容易，但 AI 疯狂翻车”的痛点，就是你最需要立刻建立评测 (Eval)、并集中精力去优化的优先级最高的事项。
以上就是评估方法的详细介绍。
如果这篇文章对你有帮助，欢迎点赞、评论、关注、收藏。你们的支持是我前进的动力！