1. 为什么“智能体好不好用”不能靠感觉判断做智能体开发的人都有一个共同的尴尬时刻演示的时候行云流水客户一用就翻车。你问它“帮我查一下上个月的销售数据”它给你编了一个看起来很像真的数字你让它“把这份合同里的风险条款标出来”它把无关的付款方式标红了。更麻烦的是你改了一版提示词感觉“好像好了一点”但到底好了多少、有没有引入新的问题完全说不清楚。这就是评测体系要解决的核心问题。智能体和传统软件最大的区别在于它的输出不是确定性的。传统软件你输入11永远得到2测试用例写死了跑就行。智能体面对的是开放域的自然语言输入同一个问题换一种问法输出可能天差地别。你没法用“断言等于某个值”的方式来测它。所以我们需要一套科学的评测体系。这套体系要能回答三个问题第一智能体在哪些场景下表现好哪些场景下表现差第二改动提示词、换模型、加工具之后效果是提升了还是退步了第三不同智能体之间到底谁更强强在哪个维度。我见过太多团队在这个环节偷懒。要么是老板让几个员工“随便试试”试完说“感觉还行”就上线了要么是写了几十条测试用例跑完发现全过了但线上还是出问题。根本原因在于评测用例的设计、评测指标的选取、评测流程的自动化每一个环节都有坑。这篇文章就把我踩过的坑和总结出来的方法从头到尾讲清楚。2. 评测体系到底该测什么从能力维度到场景维度2.1 智能体评测和传统模型评测的本质区别传统的大模型评测比如MMLU、GSM8K这些基准测的是模型本身的知识和推理能力。你给它一道数学题它给出答案对就是对错就是错。但智能体不一样智能体是一个系统它包含了大模型、提示词、工具调用、记忆管理、任务规划等多个组件。你测智能体实际上是在测整个系统的协同效果。举个例子一个客服智能体它需要理解用户意图、查询知识库、生成回复、必要时转人工。这里面任何一个环节出问题最终的用户体验都会崩。你可能模型选得很好但知识库检索的召回率太低导致回答总是答非所问。这种情况下你光测模型能力是没有意义的。所以智能体评测的第一个原则是以端到端的任务完成效果为核心同时拆解各环节的贡献度。你不能只看最终结果还要能定位到是哪个环节拖了后腿。2.2 能力维度的拆解从理解到执行到反思一个智能体的核心能力可以拆成几个层次。最底层是意图理解用户说“帮我订明天去北京的机票”智能体得知道这是订票任务需要提取时间、目的地、出发地等槽位。往上一层是任务规划复杂任务需要拆解成子步骤比如“先查航班再比价再选座最后下单”。再往上是工具调用智能体要能正确选择工具、构造参数、解析返回结果。最高层是反思与纠错当工具返回错误或者结果不符合预期时智能体要能调整策略重试。每一层都需要单独的评测。我通常会用一组“单元测试”来分别测这些能力。比如测意图理解就用一批标注好意图和槽位的句子看智能体提取的准确率和召回率。测工具调用就模拟各种工具返回正常、超时、报错、空结果看智能体能不能正确处理。2.3 场景维度的划分从简单问答到多轮复杂任务能力维度是纵向拆解场景维度是横向划分。不同场景对智能体的要求完全不同。我一般把场景分成四类单轮问答用户问一个问题智能体直接回答。比如“你们公司的退货政策是什么”。这类场景主要测知识准确性和回答相关性。单轮工具调用用户提一个需要查外部数据的请求智能体调用一次工具返回结果。比如“帮我查一下订单12345的物流状态”。这类场景测工具选择和参数构造的准确性。多轮对话用户和智能体来回多轮逐步明确需求。比如订机票的过程中用户不断修改时间、舱位。这类场景测上下文理解和状态跟踪。复杂任务规划用户给一个模糊的高层目标智能体需要自己拆解并执行。比如“帮我策划一个团建活动”。这类场景测规划能力和多工具协同。这四类场景的评测方法和指标都不一样不能混在一起测。我见过有人拿单轮问答的准确率来代表整个智能体的能力这就像用百米冲刺的成绩来评价一个足球运动员完全不靠谱。3. 基准构建的核心方法论从用例设计到指标定义3.1 评测用例的设计原则覆盖度、区分度、可复现设计评测用例是整个评测体系里最费功夫的环节。我总结下来有三个原则必须遵守。覆盖度是指用例要覆盖智能体实际会遇到的各种情况。不能只挑简单的、常见的场景那些边缘情况、异常输入、对抗性提问才是真正暴露问题的地方。比如一个订票智能体你不仅要测“订明天去北京的机票”还要测“订下个月32号的机票”无效日期、“帮我订一张去火星的票”超出范围、“算了不订了”意图反转。区分度是指用例要能区分出不同智能体的水平。如果一组用例所有智能体都能拿满分那这组用例就没有价值。好的用例应该让强模型和弱模型拉开差距。我通常会用“难度分层”的方式把用例分成简单、中等、困难三档分别看通过率。可复现是指同一个用例在不同时间、不同环境下跑结果应该是一致的。这就要求用例的输入必须完全确定不能有随机性。同时评测的环境比如工具返回的数据也要固定下来不能每次跑都变。3.2 从人工标注到LLM-as-Judge评测方法的演进早期做评测全靠人工打分。找几个标注员让他们看智能体的输出然后打分。这种方法的问题是成本高、速度慢、主观性强。不同标注员对同一个输出的评分可能差很多而且标注员会疲劳上午打的分和下午打的分标准就不一样了。后来大家开始用LLM-as-Judge就是让一个强模型来当裁判给智能体的输出打分。这个方法的好处是成本低、速度快、一致性高。但坑也很多。最大的坑是裁判模型会有偏见。比如它倾向于给更长的回答打高分倾向于给格式更漂亮的回答打高分甚至倾向于给自己的输出打高分。我解决这个问题的办法是用多个裁判模型交叉验证并且给裁判模型提供详细的评分标准。评分标准不能是“好、中、差”这种模糊的描述而要拆成具体的维度每个维度给出明确的打分规则。比如“事实准确性”这一项可以定义完全正确得5分部分正确得3分有事实错误得1分完全编造得0分。3.3 验证器的角色规则校验与模型校验的配合LLM-as-Judge虽然好用但不能全指望它。有些东西是可以用规则精确校验的。比如工具调用的参数格式对不对、JSON能不能解析、必填字段有没有缺失这些用代码就能判断不需要模型来打分。我的做法是规则校验优先模型校验兜底。能用规则判断的绝对不用模型。比如一个查天气的智能体输出里必须包含温度、湿度、风力三个字段这个用正则表达式就能校验。只有那些规则没法判断的比如“回答是否自然流畅”、“语气是否友好”才交给模型来打分。这种混合验证的方式既保证了准确性又控制了成本。我实测下来规则校验能覆盖60%以上的评测点剩下的40%才需要模型介入。4. 实操从零搭建一套可运行的智能体评测流水线4.1 环境准备与工具选型搭建评测流水线第一步是选工具。市面上的评测框架不少但我建议不要一上来就用重型框架。先用最轻量的方式跑通流程再根据需求逐步引入工具。我的最小化技术栈是这样的Python pytestpytest是写测试用例的标准工具用它来组织评测用例非常方便。每个评测用例就是一个测试函数断言就是评分逻辑。JSON/YAML用来存储评测数据集。每条数据包含输入、期望输出、评分标准等字段。OpenAI兼容的API用来调用裁判模型。任何支持OpenAI接口的模型都可以。Pandas用来做结果分析和报表生成。这套组合的好处是零依赖、易上手、可扩展。你不需要学任何新框架用Python基础就能跑起来。4.2 评测数据集的构建流程数据集是评测的基石。我构建数据集的流程分四步第一步收集真实用户输入。从线上日志、客服记录、用户反馈里捞真实的问题。这些数据最有价值因为它们代表了真实分布。我通常会收集500到1000条原始输入。第二步清洗和分类。把收集到的输入去重、脱敏然后按照前面说的四类场景单轮问答、单轮工具调用、多轮对话、复杂任务分类。分类之后你就能看到哪些场景的数据多哪些场景的数据少需要补充。第三步标注期望输出和评分标准。这一步最费时间。对于简单场景期望输出可以是一个标准答案。对于复杂场景期望输出可能是一个范围或者一组关键点。评分标准要写清楚每个维度的打分规则。第四步划分训练集和测试集。如果你要用评测数据来优化提示词那必须留出一部分作为测试集不能用来调优。我一般按7:3划分70%用来迭代30%用来最终验收。4.3 自动化评测脚本的编写下面是一个评测脚本的核心结构。我用伪代码展示你可以根据自己的需求调整。import json import pytest from judge import LLMJudge # 加载评测数据集 with open(eval_dataset.json, r) as f: dataset json.load(f) # 初始化裁判模型 judge LLMJudge(modelgpt-4) # 定义评分维度 SCORING_DIMENSIONS { factual_accuracy: 事实准确性0-5分, completeness: 信息完整性0-5分, tool_usage: 工具调用正确性0-5分, format_compliance: 格式合规性0-5分 } pytest.mark.parametrize(case, dataset) def test_agent_case(case): # 调用智能体 agent_output call_agent(case[input]) # 规则校验 rule_score rule_based_check(agent_output, case[expected]) # 模型校验 model_score judge.evaluate( inputcase[input], outputagent_output, expectedcase[expected], dimensionsSCORING_DIMENSIONS ) # 综合评分 final_score 0.4 * rule_score 0.6 * model_score # 断言 assert final_score case[pass_threshold], \ fCase failed: {case[id]}, score: {final_score}这个脚本的核心逻辑是对每条评测数据先跑智能体拿到输出然后用规则和模型双重校验最后加权得到综合分。pytest会自动收集所有测试结果生成报告。4.4 结果分析与可视化跑完评测只是第一步更重要的是分析结果。我通常会看几个东西整体通过率所有用例中达到及格线的比例。这个数字反映智能体的整体水平。分场景通过率按场景分类统计通过率。如果某个场景通过率特别低说明智能体在这个场景下有系统性问题。分维度得分按评分维度统计平均分。比如事实准确性平均4.2分但工具调用只有2.8分那优化重点就很明确了。失败用例聚类把失败的用例拿出来人工看一遍找出共性。我经常发现失败用例集中在某几个特定的输入模式上比如包含否定词的句子、包含多个意图的句子。可视化方面我一般用Pandas直接生成表格或者用Matplotlib画柱状图。不需要花哨的仪表盘能看清数据就行。5. 常见坑与排查技巧那些只有踩过才知道的事5.1 评测用例的“过拟合”问题这是最隐蔽的坑。你设计了一组评测用例然后根据评测结果不断优化提示词。优化了几轮之后评测分数上去了但线上效果没变好甚至变差了。原因就是你的提示词过拟合到了评测用例上。怎么判断是不是过拟合我的方法是留出一组“从未用于优化”的测试集只在最终验收时跑一次。如果测试集分数远低于优化集分数那就是过拟合了。另外我会定期用新收集的真实数据替换一部分评测用例保持评测集的“新鲜度”。5.2 裁判模型的偏见与校准前面提到LLM-as-Judge会有偏见具体表现有几种长度偏见倾向于给更长的回答打高分。解决办法是在评分标准里明确写“简洁性也是评分维度冗长回答扣分”。位置偏见在对比两个回答时倾向于给第一个回答打高分。解决办法是交换顺序跑两次取平均。自我偏见裁判模型倾向于给自己的输出打高分。解决办法是不要用被评测的模型来当裁判。格式偏见倾向于给Markdown格式的回答打高分。解决办法是在评分标准里明确“格式不影响内容评分”。校准的方法是准备一组人工标注好分数的“校准集”让裁判模型也打一遍分然后计算裁判分数和人工分数的相关性。如果相关性低于0.8说明裁判模型需要调整评分标准或者换模型。5.3 工具调用的“假成功”陷阱工具调用评测里有一个很隐蔽的坑智能体调用了工具工具也返回了结果但智能体没有正确使用这个结果。比如智能体查到了天气是“晴25度”但回答用户时说“今天下雨记得带伞”。这种情况下工具调用本身是成功的但最终回答是错的。我的解决办法是在评测里增加一个“工具结果利用率”的检查。具体做法是把工具返回的结果和智能体的最终回答都拿出来让裁判模型判断“最终回答是否正确地基于工具结果”。这个检查能抓住很多“假成功”的情况。5.4 多轮对话的状态跟踪评测多轮对话的评测比单轮难得多。难点在于你不仅要看每一轮的回复质量还要看智能体有没有正确跟踪对话状态。比如用户第一轮说“订明天去北京的机票”第二轮说“改成后天”智能体得知道“后天”指的是出发日期而不是其他信息。我评测多轮对话的方法是构造一个“状态检查点”。在对话的每一轮之后检查智能体内部的状态变量比如槽位填充情况是否正确。如果智能体没有暴露内部状态那就通过提问来间接检查。比如在第三轮问“你帮我订的是哪天的票”看智能体的回答是否和预期一致。5.5 评测成本的控制评测是要花钱的。调用裁判模型、调用智能体本身都是成本。如果评测集有1000条每条要调用3次模型那就是3000次调用。按GPT-4的价格算一次调用几分钱到几毛钱总成本可能几百到几千块。控制成本的方法有几个分层抽样不要每次评测都跑全量数据集。日常迭代跑一个200条的子集最终验收跑全量。缓存结果对于确定性强的评测点比如工具调用参数格式结果可以缓存不用每次都重新跑。规则优先能用规则判断的绝对不用模型。我前面说过规则能覆盖60%的评测点这部分成本是零。小模型裁判对于简单的评分任务可以用小模型当裁判。比如判断“回答是否包含某个关键词”用7B的模型就够了不需要GPT-4。6. 从评测到迭代让评测结果真正驱动优化6.1 建立“评测-分析-优化”的闭环评测本身不产生价值评测驱动的优化才产生价值。我建议把评测嵌入到开发流程里形成一个闭环开发新功能或修改提示词跑评测流水线分析失败用例定位问题针对性优化重新跑评测验证优化效果如果通过合并代码如果不通过回到第3步这个闭环的关键是快速反馈。评测跑得越快迭代速度就越快。所以我建议日常迭代用小子集200条以内几分钟出结果。只有最终验收才跑全量。6.2 版本对比与回归检测每次优化之后你不仅要看分数有没有提升还要看有没有引入新的问题。这就是回归检测。具体做法是保留上一个版本的评测结果和新版本的结果做对比。如果新版本在某个维度上分数下降了那就是回归了。我通常会维护一个“版本对比表”记录每个版本的各项得分。这样一眼就能看出趋势。版本整体通过率事实准确性工具调用格式合规多轮对话v1.072%4.13.24.53.8v1.178%4.33.54.64.0v1.281%4.44.14.54.2v1.379%4.44.24.53.9从这张表就能看出v1.3虽然工具调用提升了但多轮对话退步了整体通过率也下降了。这时候就需要回滚或者针对性修复。6.3 评测驱动的提示词优化实例举个实际例子。我之前做一个合同审查智能体评测发现“风险条款识别”的召回率只有65%。分析失败用例后发现智能体对“隐含风险”的识别很差。比如合同里写“乙方应在合理时间内完成交付”智能体没有识别出“合理时间”是一个模糊条款存在风险。针对这个问题我在提示词里加了一段“注意识别模糊性表述如‘合理时间’、‘适当方式’、‘必要时’等这些表述缺乏明确标准属于潜在风险点。”加了这段话之后召回率提升到了82%。然后我又跑了一遍全量评测发现“误报率”上升了。智能体把一些正常的表述也标成了风险。于是我又加了一段“但要注意区分正常商业表述和真正的风险条款不要过度标注。”最终召回率稳定在80%误报率控制在10%以内。这个例子说明评测不是一次性的而是一个持续迭代的过程。每次优化都可能引入新问题必须通过评测来验证。6.4 面向未来的评测体系扩展智能体技术在快速演进评测体系也要跟着演进。我认为未来有几个方向值得关注多智能体协同的评测现在越来越多的系统由多个智能体协同工作。怎么评测协同效果怎么定位是哪个智能体拖了后腿这需要新的评测方法。长周期任务的评测有些智能体任务需要运行几天甚至几周。怎么评测这种长周期任务怎么在任务执行过程中及时发现偏差这也是一个开放问题。安全性和合规性评测智能体可能会被诱导执行危险操作或者输出不合规的内容。怎么系统性地评测安全性OWASP最近发布的智能体安全风险清单ASI01-ASI10给了一个很好的框架值得参考。评测的标准化现在每个团队都在自己造轮子评测方法和指标都不统一。未来可能会出现行业标准的评测基准就像NLP领域的GLUE和SuperGLUE一样。我个人在实际操作中的体会是评测体系不是越复杂越好而是越实用越好。一个能快速跑起来、能定位问题、能驱动优化的简单评测体系远比一个设计精美但跑不起来的复杂体系有价值。先跑通最小闭环再逐步完善这是我一直坚持的原则。最后分享一个小技巧每次评测跑完不要只看分数一定要人工看几条失败用例。数据告诉你“哪里有问题”但只有人工看用例才能告诉你“为什么有问题”。这个习惯帮我发现了无数个自动化指标看不出来的问题。