声明本篇博客是以吴恩达的【Agent智能体】教程为基础并对其中的内容做了笔记整理以及个人收获的总结。前面讲解了反思设计模式的应用我们能看到反思是可以提升大模型的输出质量的。但是我们只知道反思有用是不够的在实际开发中一定会遇到这样一个痛点我修改了反思提示词AI 的表现到底是变好了还是变差了反思真的起作用了吗这就引出了我们接下来要探讨的核心必须为 AI 系统引入一套科学的评估基准Eval利用测试集与量化评分标准Rubric来判断反思是否真的起作用了例子将自然语言转化为数据库查询Text-to-SQL上半部分带有“反思”机制的工作流程用户输入提示词 (Prompt)用户提出问题“Which color of product has the highest total sales?”哪个颜色的产品总销量最高。初次生成 SQL (Generate SQL query)第一个 LLM 接收到问题后生成一个初始版本的 SQL 查询语句V1 版本。反思与修正 (Reflect on V1 SQL, write V2 query)这是图中红色虚线框标出的核心创新步骤。系统并没有直接运行 V1 版本的代码而是让 LLM 对刚刚生成的 V1 代码进行“自我反思”和检查找出潜在的语法错误或逻辑漏洞然后重写并生成改进后的 V2 版本查询语句。执行查询 (Execute V2 query)在数据库中实际执行经过优化后的 V2 SQL 语句。获取查询结果 (V2 query results)得到数据库返回的原始数据结果。回答问题 (Answer question)最后一个 LLM 接收到数据库结果将其转化为人类容易理解的自然语言文本作为最终答案输出。问题第二个语言模型反思并优化SQL查询真的能提升最终输出结果吗这个就是我们探讨的核心我们怎么评估反思是否真的作用了答案是做对比。下半部分的图就是效果的对比与评估。表格列Prompts (提示词)测试用的各种问题。Ground truth answer (真实答案)标准正确答案。No reflection (无反思)LLM 生成第一版 SQL 后直接运行得出的结果。With reflection (有反思)LLM 经过自我纠错后运行得出的结果。整体准确率 (Accuracy)底部红字显示在没有反思的情况下系统的准确率为87%。在加入反思机制后准确率跃升至95%。通过表格做对比我们发现当前例子的反思机制是非常有用的。这样就相当于我们建立了一个“评测流程”。正如图片右侧的提示“Run each time you change reflection prompt”每次更改反射提示时都要运行一下“Run each time you change reflection prompt”每次更改反射提示时都要运行一下。这句话就是在提示开发者这是一种迭代开发的方法。后续我们可以快速尝试不同的提示词思路并通过重写反思词来测试新的提示词是否能进一步提高准确率从而筛选出最适合当前应用场景的策略。但是这个例子说明你可与用客观评测因为有明确答案。下面看一个主观评估的例子例子主观性任务中的“反思”应用 (What about subjective tasks?)这个展示了“反思机制”如何应用于像“数据可视化画图表”这样没有绝对唯一标准答案的主观任务中。工作流演示用户要求用 Python 根据数据画一个对比 2024 和 2025 年 Q1 咖啡销量的图表。初次生成 (Before reflection)LLM 生成了第一版代码并运行画出了图一堆叠柱状图。这种图很难直观对比这两年的销量。反思与修改 (Critique image, update code)将第一版的图和代码交给 LLM 进行反思。LLM 发现堆叠图不便于横向对比于是修改代码生成了第二版图表。最终结果 (After reflection)第二版图表变成了“分组柱状图”各咖啡品类的销量对比一目了然质量显著提升。问题“你能否通过某种评估方法eval来衡量哪张图更好”因为“好坏”是主观的我们需要一种方法来量化这种进步下面展示几个方法方法1直接让 LLM 当裁判的弊端 (Using an LLM as a judge)最直观的想法是直接把两张图发给另一个强大的 LLM问它“哪张图更好” 这张图指出了这种简单粗暴做法的致命缺陷。已知问题 (Known issues)回答质量通常不高 (Answers often not very good)因为“更好”这个词太模糊了LLM 缺乏具体的评判依据给出的理由往往站不住脚。位置偏差 (Position bias)这是一个在 LLM 评测中非常著名的现象。当给出选项 A 和 B 时LLM 会存在“偏袒第一个选项”的倾向图中红框圈出了 A仅仅因为它排在前面而不是因为它真的更好。更好的思路尝试给LLM一些评判标准方法2使用量化评分标准才是正解 (Grading with a rubric gives more consistent results)直接问“哪个更好”行不通这张图给出了行业内通用的终极解决方案引入评分标准Rubric。评分标准 (Rubric) 的作用不再问笼统的问题而是给 LLM 提供一个像老师批改试卷一样的“打分表”。图中提示词明确要求“根据以下质量标准评估这张图表每一项为真得1分为假得0分并返回 JSON 格式”。具体的客观标准包括1. 是否有清晰的标题2. 坐标轴是否有标签3. 图表类型是否合适4. 坐标轴数值范围是否合理等。量化成果通过这种拆解成客观小项的方法LLM 就能给出稳定、一致的评估结果有效消除了图二中的“位置偏差”。底部表格展示了评估结果对于多个用户查询“没有反思 (No reflection)”生成的图表得分普遍较低例如 4分、5分而“经过反思 (With reflection)”生成的图表得分显著提高例如 6分、8分、7分。积累了这样一套评测之后也可以通过不断修改初始提示词、反思提示词重新测评找出最合适的从而提升性能。评估方式的总结客观评估 (Objective evals)这适用于那些有绝对标准答案、对错分明的任务例如前面的 Text-to-SQL 查销量。基于代码的评估更容易 (Code-based evals are easier)评估代码或 SQL 语句非常直接。代码要么能跑通要么报错SQL 查出来的数据要么和标准答案一致要么不一致。这种非黑即白的特性使得自动化测试非常容易。建立包含真实答案的数据集 (Build a dataset of ground truth examples)为了系统地评估你需要准备一个测试题库Dataset里面不仅有用户的各种提问还要有对应的人工确认过的“绝对正确答案Ground truth”。每次修改反思的提示词就在这个数据集上跑一遍看准确率是上升了还是下降了。主观评估 (Subjective evals)这适用于没有唯一标准答案、好坏取决于人类主观感受的任务例如前面画咖啡销量对比图。让大语言模型充当裁判 (Use LLM as a judge)既然人工去评判成千上万张图表太耗时我们只能依靠另一个强大的大语言模型LLM来当裁判替我们评估生成结果的好坏。基于评分标准的打分效果更好 (Rubric-based grading is better)这是最重要的一条结论。正如上一组图所演示的直接让 LLM 评判“哪个更好”会导致随机性高和位置偏差。正确的做法是给 LLM 提供一份详细的量化评分细则Rubric让它像老师批改主观题一样根据诸如“是否有标题”、“坐标轴是否清晰”等具体条目逐项打分。总结AI 智能体工作流反思Reflection与评估Eval核心理念AI 应用开发正在从“靠感觉写提示词”走向“以评测驱动的系统工程Eval-driven Engineering”。先建好评测这套基础设施然后通过不断打磨“反思提示词”就能低成本地持续压榨出大模型更高的性能。三个核心大语言模型LLM往往无法一次性完美解决复杂任务。相较于花费巨大成本去训练或微调一个更强的模型在系统设计中引入“反思机制生成初版 - 自我批判 - 修正输出”是一种极具性价比的方法。能显著提升最终输出的准确率和质量。反思的效果好不好很大程度上取决于“反思提示词Reflection prompt”怎么写。为了不断优化这个提示词开发者必须建立一套系统化的评估流程。每次修改提示词后都要在测试集上重新跑一遍用数据分数/准确率来验证修改是否有效而不是凭感觉盲目迭代。根据“任务属性”选择正确的评估策略对于客观任务对错分明如写 SQL、解数学题应该建立包含“绝对正确答案Ground truth”的数据集。评估标准极其明确代码能跑通、结果能对上就是好对于主观任务没有绝对标准如画图表、写文章必须使用另一个 LLM 来充当“裁判”但绝不能简单粗暴地让 LLM 凭感觉选“哪个好”这会导致严重的评判偏见和随机性。唯一的解法是提供“量化评分标准Rubric”。把主观感觉拆解成一个个客观的打分项如是否有标题、刻度是否准确让 LLM 像老师批改量表一样逐项打分从而将主观的优化转化为可追踪的客观分数。如果这篇文章对你有帮助欢迎点赞、评论、关注、收藏。你们的支持是我前进的动力