最近这半年我明显感觉到圈子里聊智能体的热度一直没降但聊来聊去大家最头疼的其实不是“怎么做出来”而是“怎么知道它做得好不好”。你辛辛苦苦搭了个智能体看起来能跑通几条链路可真要拿到业务里去用它到底靠不靠谱用户问一句偏离预设的话它是能机智地拉回来还是直接崩给你看这些问题光靠肉眼点几条 case 根本回答不了。这也是我写这篇东西的初衷。我自己在做智能体评测方案落地的时候踩过不少坑也把市面上主流的方法论和工具都过了一遍。今天想跟你系统聊聊智能体评测这件事——从最核心的评估维度设计到怎么用 DeepEval 这个开源框架把评测变成一条可重复执行的流水线。不管你是刚入门想给自己的 Agent 搭一套评测体系还是已经在做智能体开发、想完善评估流程这篇文章应该都能给你一些能直接上手的参考。1. 为什么智能体评测这么难先别急着聊工具我们得先把“难”这件事掰扯清楚。很多人一开始不理解觉得评测不就是拿一堆问题去问智能体然后看看回答对不对吗如果你也是这么想的那后面十有八九会被现实教育。1.1 从“单点回答”到“多步决策”的质变传统的大语言模型评测本质上是“一问一答”的单轮任务。你丢进去一个问题模型吐出来一段文本你把这段文本和标准答案做个对比或者让人打个分这事儿就完了。问题再难也是静态的、一次性的。但智能体不一样。它不是一个单纯输出文字的模型而是一个“能调用工具、能规划步骤、能根据中间结果动态调整”的系统。我用一个生活化的类比来解释传统模型评测像考学生做选择题答案对了就得分而智能体评测像看一个人独立完成一个复杂的工程项目——他中间要查资料、要写代码、要试错、要根据临时出现的问题改变策略你光看他“最后交出来一份报告”是根本不知道这报告是怎么来的也不知道他在中间有没有绕远路、有没有撞墙。这就引出智能体评测的核心难点——你需要评估的不只是“结果质量”还有“过程质量”。比如一个智能体被要求“帮我查一下某家公司的财报然后总结关键风险”。它如果第一步就把公司名字理解错了后面再怎么努力最后的结果大概率也是错的它如果中间调用工具时参数传错了或者在一个错误的方向上反复重试了十次即便最后侥幸蒙对了答案这种智能体你敢放到生产环境里吗显然不敢。1.2 标准答案缺位你拿什么当“正确”的参照物第二个让我头疼的问题是智能体的任务大多数时候压根没有标准答案。你说“帮我订一家适合团建的餐厅”什么叫“适合”有人在乎环境有人在乎人均价格还有人在乎有没有包间。这种主观性极强的任务你让三个不同的评测人员来打分得出三个不同的分数都很正常。传统评测可以用“字符串匹配”或者“BLEU 分数”来机械地比对答案但智能体的回答是生成的、开放的、多样化的。同一个任务你让它跑三次它可能给出三个都正确但表达方式完全不同的回答。如果你拿着一个死板的标准答案去做匹配那评测结果会惨不忍睹——不是智能体不行是你的评测方案不行。这也是为什么现在大家都在研究“模型即评委”这条路——让大模型去当打分员用语义理解能力来判断回答是否满足需求而不是靠文本层面的硬比对。稍后我会讲到 DeepEval 里面具体是怎么实现的。1.3 环境依赖跑一次一个样评测结果不确定如果你实际跑过智能体你一定遇到过这种让人崩溃的情况同一个测试用例上午跑是成功的下午跑就失败了本地跑好好的部署到服务器上就出问题了。这是因为智能体依赖的外部环境太复杂了。它要调用的 API 可能会限流、会超时它访问的外部网页可能有反爬机制它依赖的数据库数据可能随时在更新。还有一个更隐蔽的坑——大模型本身就有随机性你设置了 temperature 0 也不能保证每次输出完全一致。这种不确定性给评测带来的最大挑战是你很难判断一次失败到底是智能体的问题还是外部环境的偶发问题。我见过太多团队辛辛苦苦写了 20 个评测用例跑完发现 5 个没过第一反应是“智能体有 bug”结果一排查发现是第三方接口当天升级了返回格式根本跟智能体本身没关系。所以评测体系里如果没有“环境控制”和“多次运行取稳定性”的意识你的评测结果一定是失真的。2. 落地前先想清楚评测维度怎么定很多评测报告写得像流水账列了一堆通过率、成功率但老板看了根本不知道这智能体到底能不能用。我后来总结出一个教训评测维度设计一定要从“业务关心什么”出发而不是从“指标容易算”出发。你自己都不清楚要测什么后面一切都是白搭。2.1 五维度模型任务、鲁棒、工具、效率、安全在帮好几个项目设计评测方案之后我逐渐收敛出一套比较通用的五维度模型分享给你参考。第一个维度是任务完成度这是最核心的就是智能体有没有把用户交代的活儿干完、干对。但这个维度千万别简单理解成“成功或失败”的二元判断它需要拆得更细。比如整个任务涉及 5 个步骤智能体只做对了前 3 步就停下来向用户交差了这算成功吗所以任务完成度可以是分级的完全完成、部分完成、未完成甚至可以为每个子步骤单独打分最后加权算总分。第二个维度是鲁棒性。智能体最怕什么怕用户说一些模糊的、有歧义的、甚至带错别字的指令。一个“傻白甜”的智能体用户说“帮我查一下明天的天气”它能处理好但如果用户说“明天那个活动要下雨吗要不要带伞”它就懵了。评测鲁棒性就是要专门准备一批这种“刁钻”输入看智能体能不能在输入不完美的条件下依然保持稳定。第三个维度是工具调用准确率。智能体跟普通聊天机器人最大的区别就是它会调用工具——搜索引擎、计算器、数据库查询接口、第三方 API 等等。有一次我测一个销售助手智能体它在调用 CRM 系统查询客户信息时把客户 ID 和订单号搞混了查出来的数据牛头不对马嘴但它的回答看起来还特别自信。这种“一本正经地给错结果”是最危险的。评测工具调用维度要关注三件事工具选得对不对、参数传得准不准、调用时机合不合理。第四个维度是效率与成本。说白了就是智能体完成一个任务要多少步、要调多少次模型、总共花了多少 token、耗时多久。我见过一个智能体为了回答“今天星期几”这种问题绕了一大圈去调搜索引擎最后总共耗时 12 秒消耗了 4000 多个 token。这种智能体能力上可能没问题但真放到生产环境里成本会让你肉疼。评测中一定要加这个维度别让智能体成为“昂贵的玩具”。第五个维度是安全与合规。这个维度我觉得怎么强调都不过分。智能体如果被恶意用户诱导输出有害内容、泄露系统 Prompt、执行危险操作那后果非常严重。评测时要专门设计一些“攻击性”用例比如越狱提示、提示注入、恶意指令看看智能体能不能守住底线。2.2 怎么把业务目标翻译成可测的指标光有维度还不够你还需要一套“翻译机制”把模糊的业务目标变成可量化的指标。这里我分享一个我自己常用的思路先问自己三个问题——这个智能体最核心的价值是什么如果它犯了错最不能接受的错误类型是什么这个错误能不能用某个可观测的信号来识别举个例子。假设你要评测一个客服智能体业务目标是“提升用户咨询效率”。那核心价值就是“快速准确地解决用户问题”。最不能接受的错误是什么是“让用户的问题没被解决就结束了会话”。那这个错误怎么识别我们可以定义一个指标会话是否以用户明确表达满意比如“谢谢”“明白了”或问题得到应答为正常结束反之如果用户重复提问同一问题超过两次或者会话在无明确结论的情况下中断标记为“未解决率”。如果你能做这一步翻译后面评测其实就顺了。你不需要追求一个能衡量所有东西的“万能指标”你需要的是针对这个智能体的核心业务价值找到几个能反映它做得好不好的关键信号。为了帮你更直观地理解我把上面提到的维度整理成了一个对照表方便你直接参考使用。评估维度业务关注点可量化指标示例常见评测方法任务完成度活有没有干完、干对任务成功率、子步骤完成率人工打分、LLM 评判鲁棒性输入不完美时是否稳定干扰输入下的成功率构造对抗样本、变形测试工具调用准确率工具选择、参数是否正确工具选择准确率、参数准确率日志分析、规则比对效率与成本耗时、token 消耗是否合理平均耗时、平均 token 数日志统计安全与合规是否输出有害内容、泄露信息违规率、拒绝攻击成功率红队测试、敏感内容过滤2.3 维度选型要看场景别搞“一刀切”上面讲的五维模型是一个通用底座但不同场景的智能体侧重点完全不一样。这一点我在实践中体会特别深。比如你做的是一个销售智能体核心场景是帮销售自动找线索、写邮件、跟进客户。这种智能体最关键的维度不是“全能”而是“专业性”——它说出去的话必须对客户有吸引力、不能有事实错误、不能踩合规红线。这种场景下任务完成度里“生成内容质量”的权重就应该提高甚至要专门设计一个“话术合规性”的子维度。但如果你做的是一个数据分析智能体用来帮业务团队写 SQL 查数、生成报表。那最关键的维度就变成了“准确性”和“逻辑严谨性”——SQL 查出来的数据必须对做出来的图表不能误导人。这种场景下你需要重点评测“查询结果正确率”和“数据解读逻辑性”对鲁棒性的要求反而没有那么高因为输入通常都是结构化的查询需求。所以我的建议是五维模型是一个起点但你要根据业务场景调整每个维度的权重或者增加自己独有的子维度。评测方案没有最好只有最合适这个思路一定要带着。3. DeepEval把评测从“玄学”变成工程前面说了这么多理论和理念如果没有一个好用的工具帮你落地那都是空中楼阁。我第一次尝试自己写评测脚本时真的是一把辛酸泪——要自己写模型调用、自己写相似度算法、自己拼提示词让大模型打分还要处理各种 JSON 格式错误和解析失败写了整整两天才跑通一条最简单的评测用例。后来我接触到 DeepEval才算是真正从“手工作坊”走进了“标准化生产”。3.1 DeepEval 是什么它凭什么能帮你DeepEval 是一个开源的 LLM 评测框架它最吸引我的一点是它把评测变成了像 pytest 一样简单的事情。你写过单元测试吗在 Python 里用 pytest 写一个 test 函数然后加个断言就能自动化跑测试。DeepEval 把这种体验带到了智能体评测领域。它内置了各种成熟的评测指标比如 G-Eval一种基于大模型的评分指标、Answer Relevancy回答相关性、Faithfulness忠实性等等你不需要自己造轮子。更关键的是它内置了“LLM 作为评委”的能力——也就是说它会提供一个专门用于打分的“裁判模型”自动对智能体的回答进行多维度的评估。这个设计非常聪明它把最难的“语义理解”和“主观打分”抽象成了一个标准的 API 调用。使用 DeepEval 有三大明显的优势。第一是测试驱动它和 pytest 无缝集成这意味着你可以把评测用例直接纳入 CI/CD 流程每次代码更新都自动跑一遍评测回归测试成本极低。第二是指标丰富内置了几十个评估指标从基础的文本相似度到复杂的语义忠实度都有覆盖了大部分场景。第三是可扩展如果内置的指标不够用你可以很方便地定义自己的自定义指标自由度和灵活性都很好。3.2 概念扫盲TestCase、Metric 与 Dataset深度使用之前有几个核心概念你必须先搞清楚否则看文档会一脸懵。第一个概念是TestCase即测试用例。想象一下你做传统功能测试时一个用例长什么样——包含输入、期望输出、实际输出。DeepEval 中的 LLMTestCase 与此类似但内容更丰富。对于一个智能体的测试用例通常要包含这些字段input用户给智能体的输入也就是用户问题、actual_output智能体实际生成并返回给用户的内容、expected_output期望的标准回答这一步是可以选的、retrieval_context检索上下文如果智能体基于 RAG 做问答这里放检索到的文档片段、tools_called智能体调用的工具列表用于工具调用评测。当你把一次完整的会话录进去这个 TestCase 就定义好了。第二个概念是Metric即度量指标。之前我们聊了评测维度Metric 就是把一个维度具体化之后的算法实现。DeepEval 里每一个 Metric 都是一个类比如AnswerRelevancyMetric回答相关性、FaithfulnessMetric忠实性、ToolCorrectnessMetric工具调用正确性等等。你可以选择用哪个指标然后它会自己内部去算分、去判断通过不通过。每个 Metric 还有一个阈值参数默认是 0.5意思是得分超过 0.5 就算通过但这个值你可以自己调。第三个概念是Dataset即数据集。在实际使用中你的测试用例不可能只有一个会有几十上百个。DeepEval 提供了 Dataset 和 Pytest 集成的方式你可以把几十个 LLMTestCase 放进一个数据集里然后用pytest批量跑。跑完之后还可以集成为一个整体的测试报告方便你查看哪些用例过了、哪些挂了。下面是一个简单的结构示意方便你对照着理解评估场景Dataset里包含多个测试用例LLMTestCase每个用例基于一个或多个指标Metric来打分最后通过断言assert_test来判断是否通过。3.3 安装与初始化环境准备要点DeepEval 的安装非常友好正常流程是pip install deepeval这个命令会帮你把核心框架和它依赖的常用库都装好。但这里我要特别提醒一个关键准备步骤DeepEval 的很多内置指标依赖大模型来判断。因此你需要配置模型访问的 API Key以及指定使用哪个模型作为“评委模型”。我记得自己在配置这块踩过一次坑。当时我想用某个特定的模型但没设对环境变量DeepEval 一直用的默认模型跑出来的结果让我觉得很不准。后来才发现需要在配置里显式地指定judge_model。正确的操作是在你的 Python 代码里实例化指标时这样传入模型配置from deepeval.metrics import AnswerRelevancyMetric from deepeval.models import DeepEvalBaseLLM # 这里假设你已经定义了自己的自定义模型封装类 MyModel model MyModel() metric AnswerRelevancyMetric(modelmodel)也就是说你有两个选择要么把模型 API 地址和密钥配置在环境变量里让框架自动发现要么在代码里显式地传入一个模型实例。如果你自己有特定的偏好模型比如你公司内部基于开源模型微调的私有模型你就可以自己封装一个类把访问逻辑写进去DeepEval 就会用你的模型来当裁判。同样的道理如果你的 OPENAI_API_KEY 已经设置好了大部分情况下开箱即用。但如果你是在内网环境部署或者想用别的模型服务那一开始就要认真看看自定义模型的文档把模型配置搞定再进入下一步。4. 实操用 DeepEval 跑通第一个智能体评测好了理论铺垫了这么多接下来我们直接进入实操环节。我会以一个实际的智能体评测项目为例带你从零开始走一遍完整的流程。为了保证可复现性我举的例子会尽量简单——一个用于“产品推荐”的 RAG 型智能体。4.1 准备一个“可测”的智能体在写评测代码之前你得先有一个已经能够跑通的智能体。我这边用一个简化版的产品推荐智能体来示范它的大致工作流程是接收用户的自然语言问题比如“有什么适合油性皮肤的洗面奶”从知识库中检索相关产品信息模拟 RAG 流程。根据检索结果生成一段推荐回答。为了让评测过程更真实我为它准备了一个简单的知识库里面包含了几条化妆品产品数据格式是这样的{ name: 清透控油洁面乳, skin_type: 油性, features: [控油, 清爽, 不紧绷], price: 99 }在实际项目中智能体可以是你基于任何框架做的关键是它有一个统一的输入输出接口方便你评测。比如你可以把你的 Agent 封装成一个函数输入是用户问题字符串输出是最终的回答字符串再额外返回一个包含工具调用和检索上下文的字典。DeepEval 只关心“输入是什么、输出是什么、上下文是什么”至于你的智能体内部是怎么实现推理的它并不需要知道。这种“黑盒”评测思路好处是能真实反映系统的最终表现。4.2 安装配置与第一个指标测试假设你已经在虚拟环境里装好了 DeepEval并且已经配置好模型相关环境变量。我们来写第一个评测脚本。先从一个最简单的指标——回答相关性开始。回答相关性评测的是智能体生成的内容和用户所问的问题之间相关性有多高。打个比方用户问“适合油皮的面霜有哪些”如果智能体回答的是“我们家的雨伞质量很好”那相关性得分就会非常低反之如果回答的是“这款控油面霜很适合你”相关性得分就会很高。下面是一个完整的测试代码示例import pytest from deepeval import assert_test from deepeval.metrics import AnswerRelevancyMetric from deepeval.test_case import LLMTestCase def query_product_recommendation(query: str) - str: # 这里调用你的智能体 # 伪代码 response your_agent.run(query) # 为演示我们写死一个返回结果 return 这款清透控油洁面乳含有控油成分洗后清爽不紧绷价格99元很适合油性皮肤使用。 def test_product_recommendation_relevancy(): test_case LLMTestCase( input有什么适合油性皮肤的洗面奶, actual_outputquery_product_recommendation(有什么适合油性皮肤的洗面奶) ) metric AnswerRelevancyMetric(threshold0.7) assert_test(test_case, [metric])这段代码的逻辑很简单先定义一个测试用例输入是用户的问题期望输出由你的智能体实际生成。然后定义一个相关性指标阈值设为 0.7。最后用assert_test来断言。如果实际输出与问题的相关性得分超过 0.7测试通过否则失败。当你运行pytest test_recommendation.py时DeepEval 的测试报告会清晰显示每个用例的得分、是否通过以及详细解释。如果你第一次跑出的分数不理想不要慌张对照报告去调整智能体的 Prompt 或检索逻辑这是正常的迭代过程。4.3 用 G-Eval 做更复杂的效果评估如果说相关性还能靠语义匹配糊弄过去那对“回答有没有事实依据”这种偏主观的评估就需要更高级的指标了。G-Eval 是我在实战中用得特别多的一个指标它几乎是目前 LLM-as-a-Judge 的主流实现方案。G-Eval 的思路其实不复杂把评估标准写成一段提示词然后让大模型根据这段标准对智能体的回答进行打分并给出打分理由。它跟直接调 ChatGPT 打分最大的区别是——G-Eval 把评分标准标准化、可配置化了并且它支持 CoT思维链模式能让裁判模型先分析、再打分这样得到的分数更稳定。在 DeepEval 中使用 G-Eval 非常简单你可以直接指定from deepeval.metrics import GEval from deepeval.test_case import LLMTestCaseParams metric GEval( name专业性, criteria评估回答是否专业、准确是否能清楚解释产品特点并给出购买建议。, evaluation_params[LLMTestCaseParams.INPUT, LLMTestCaseParams.ACTUAL_OUTPUT], threshold0.8, )这里有几个地方值得关注。evaluation_params告诉 G-Eval哪些字段是它评估时可以参考的比如这里指定了“输入”和“实际输出”裁判模型就会结合用户的问题和智能体的回答来综合打分。如果你还想让裁判同时参考检索上下文只需要把LLMTestCaseParams.RETRIEVAL_CONTEXT加进去。我第一次用 G-Eval 时犯过一个错误设置的评价标准太笼统。当时我写的是“回答质量要高”结果裁判模型每次给的分数都差不多根本拉不开差距。后来我学乖了把标准写得更具体比如“回答必须包含具体产品名称、价格、适用肤质信息并且语气自然不生硬”。标准越清晰评测结果与人工感受的匹配度就越高。这一点强烈建议你实践的时候多下功夫打磨。4.4 评测工具调用与 RAG 上下文前面几个指标都在关注“回答文本”但在智能体场景里工具调用准确率往往比回答措辞更重要。DeepEval 也提供了专门的指标来处理这个问题。假设你的智能体在回答用户问题时需要调用一个search_products工具来检索数据库。评测时你需要把“实际调用的工具”记录下来。DeepEval 的ToolCorrectnessMetric可以用来评估工具调用是否准确。它的用法也比较直接from deepeval.metrics import ToolCorrectnessMetric test_case LLMTestCase( input找一款适合油性皮肤的洗面奶, actual_output推荐用清透控油洁面乳。, tools_called[search_products(skin_type油性)] ) metric ToolCorrectnessMetric()它会把你实际记录到的工具调用与预期的最佳工具调用做比对评估工具选择是否正确、参数是否合理。对于基于 RAG 的智能体还有一个评测点容易被忽视——检索上下文的相关性。也就是说从知识库里检索出来的那些片段到底切没切中要害。如果你的检索模块返回了一堆不相关的文档那不管生成模块多厉害最终的回答都可能跑偏。你可以用ContextualPrecisionMetric和ContextualRecallMetric这类指标来分别评测检索精度和召回率确保整个系统的输入端是可靠的。4.5 构建数据集并批量运行单个用例跑通之后下一步就是把用例规模扩大。我再强调一遍评测一定要批量化、自动化不能停留在“手动点几个问题看看效果”的阶段。DeepEval 提供了DeepEvalDataset来管理多个测试用例并与 pytest 深度集成。下面是一个批量评测的示例from deepeval import assert_test from deepeval.dataset import DeepEvalDataset from deepeval.metrics import AnswerRelevancyMetric, FaithfulnessMetric dataset DeepEvalDataset([ LLMTestCase( input有什么适合干性皮肤的面霜, actual_output这款深层滋润面霜含有玻尿酸成分适合干性皮肤。, retrieval_context[深层滋润面霜适合干性皮肤含玻尿酸。] ), LLMTestCase( input推荐一款修复敏感肌的精华, actual_output这款舒缓修护精华含神经酰胺适合敏感肌。, retrieval_context[舒缓修护精华含神经酰胺修复皮肤屏障。] ), ]) for test_case in dataset.test_cases: answer_relevancy AnswerRelevancyMetric(threshold0.7) faithfulness FaithfulnessMetric(threshold0.8) assert_test(test_case, [answer_relevancy, faithfulness])这样的好处是当你有新的代码提交时可以直接跑一遍评测看看有没有引入回归问题。如果你用的是pytest配合 DeepEval 的 Pytest 插件你还能直接在命令行看到哪些用例过了、哪些挂了以及每个指标的评分明细。我建议你从项目一开始就养成“每次修改 Prompt 或 Agent 逻辑都跑一遍评测”的习惯。这跟你写代码跑单元测试是一个道理养成习惯之后你对智能体的每一次改动心里都会特别有底。5. 真实的坑与我的解决办法工具用的多了各种幺蛾子见得也就多了。这一部分我把自己踩过的一些比较典型的坑写出来希望能帮你少走弯路。如果你是刚接触 DeepEval 的用户这部分尤其值得认真看一下。5.1 评测结果不稳定今天过了明天挂了这个问题我在前面的理论部分已经提过但这里要讲得更具体一点。用 LLM 当裁判的一个天然问题就是裁判本身有随机性。你跑同一个用例两次的分数可能差 0.2甚至可能一次过、一次挂。如果你要拿这个结果去做发布决策那心里确实很慌。我的解决思路有两层。第一层是降低模型的随机性。在调用裁判模型时把温度参数尽可能调低。因为 DeepEval 在底层调用模型 API你可以在自定义模型的封装里显式设置温度比如temperature0。第二层是多次运行取平均值。对于一些关键用例我会配置对同一个用例重复跑 3~5 次然后取平均分作为最终结果。这跟做实验要三次重复是一个道理能有效规避单次采样带来的偶发偏差。提示评测结果的稳定性本身就是一个可以纳入考核的指标。如果一个用例在多次运行中分数忽高忽低那说明这个用例本身或者系统的某个环节存在不稳定的因素值得进一步排查。5.2 裁判模型的选择与成本平衡DeepEval 支持多种模型作为裁判你可以用 OpenAI 的模型也可以用自己的私有模型。裁判模型选得不同评测结果可能差异很大。我自己的实测感受是裁判模型的能力越强评测结果越接近于人工评分的水平。用 Claude 或 GPT-4 级别的模型做裁判比用小型开源模型打分要靠谱得多。但这里就有一个成本的矛盾评测用的 token 消耗可能比你想想的要多。假设你有 100 个测试用例每个用例跑 3 个指标每个指标可能要做 3 次模型调用那总共就是 900 次模型调用一次评测下来费用其实不低。所以我的建议是开发阶段小规模用例集用较强的模型做裁判确保结果质量。回归阶段大规模用例集可以用相对便宜且速度快的模型先把明显的回归 filter 出来。所有评测结果要做好缓存一旦某个用例跑过且没改动就不需要重复评测。5.3 阈值设置不能拍脑袋现在很多使用者在设置指标阈值时都特别随意直接把代码里的threshold0.5当作默认值用。但阈值实际上是整个评测体系里很关键的参数它直接决定了你的测试会不会通过。我的经验是阈值应该基于“样本校准”来设置。具体来说就是你先把评测系统搭好然后用几十条你已经知道“应该通过”的用例跑一遍统计它们的得分分布把阈值设在得分的下沿位置。然后再用几十条你已经判定为“应该失败”的用例跑一遍确认它们大部分都低于这个阈值。经过这样正反两方向的校准你设置的阈值才有实际意义。如果你直接把阈值拍脑袋定一个 0.7那最后只能是自欺欺人——分数刚好卡在边缘的用例过与不过完全看运气。5.4 别忽略“强制失败”用例最后我要特别提醒一个实操中的细节确保评测集里有“预期失败”的用例。很多人在写评测集时习惯性地只放那些“智能体应该能答对”的问题然后评测报告一片绿看着很爽。但这种全绿的报告没有任何价值。一个健康的评测集应该包含一部分故意刁难智能体的用例——比如用户的问题包含错误信息、用户的指令无法执行、用户试图诱导智能体越权操作。如果你发现这些用例也全绿了那恭喜你你的智能体能力是真的强但更常见的情况是你发现这些用例偶尔会挂几个这恰恰暴露了系统在边界情况下的薄弱点。评测的意义不是证明智能体有多好而是让你知道它什么时候会挂、以及为什么会挂。6. 从评测到迭代把反馈变成改进的闭环写到这里你可能已经能跑通一套评测流程了。但我担心你把它当成一个“终点”——评测完出个报告归档完事儿。如果你是这样用的那评测的作用就大打折扣了。真正有价值的是评测必须反哺到智能体的迭代优化过程中。6.1 失败用例是改进的金矿每次跑完评测我都会第一时间去看失败用例。这些失败一般来说能反映出几个典型问题第一类是由于先决条件缺失导致的失败。比如智能体需要访问数据库权限但评测时没有配置好对应权限。这一类问题属于环境问题修正环境即可并不代表智能体本身能力不行。第二类是工具调用逻辑缺陷。例如智能体在某些场景下选择了错误的工具或者工具的调用顺序不合理。这一类问题需要回到 Agent 的开发逻辑里去找原因往往要调整 Prompt 或者重新设计工具的调度策略。第三类是指令遵循能力不足。用户指令明明很清晰但智能体就是没有执行到位。这时候需要检查你的 System Prompt 是否足够清晰、有没有给到足够的约束。我有时候只是把 Prompt 里的“你应该...”改成“你务必...”评测分数就能有明显的提升。你可以为每次失败的用例打上标签定期统计这些标签的分布。如果“工具调用缺陷”标签占比特别高说明你的工具层设计有比较大的问题如果“指令遵循薄弱”占比较高那就是 Prompt 工程需要加强。这种数据驱动的改进思路比你坐在那里瞎想“智能体哪里有问题”要高效得多。6.2 评测报告要有“可操作性”我见过太多评测报告洋洋洒洒几十页最后领导问一句“所以到底哪里需要改”立刻哑口无言。一份好的评测报告不应该只是罗列分数而是要有明确的分析和结论。我自己的报告格式会是每个失败用例后面标注出“失败原因推测”和“改进建议”每个指标的得分趋势用最近几次迭代的曲线展示出来。这样不管是开发人员还是产品经理拿到报告都能直接知道下一步该干什么。DeepEval 本身也支持导入到它的在线平台在那里你可以把多个历史测试结果对比起来看观察指标的趋势变化。这种趋势甚至比单次结果更重要——如果你的智能体在不断的迭代中各项指标稳步上升那说明方向是对的如果某项指标突然下跌那就需要立刻警惕最近的改动是否引入了问题。6.3 评测体系本身也要迭代最后说一句可能不太中听但很重要的话你的评测体系本身也需要被修正和升级。因为智能体是在不断进化的它的能力边界在扩展它的应用场景在增多。你今天设计的 50 个测试用例可能三个月以后就没法覆盖智能体的新功能了。所以每隔一段时间你需要回过头来审视你的评测集”——旧的用例还合适吗要不要删掉一些已经完全没有区分度的用例要不要补充一些覆盖新能力的用例我从一开始的手动点几个问题到后来的几十条用例再到现在的几百条自动化评测中间经历了无数次对评测体系的调优。这个过程中最大的体会是评测不是一个一劳永逸的工作它应该跟智能体开发本身一样是一个持续迭代、持续完善的过程。如果你刚开始计划给自己的智能体搭评测体系我建议你先从一个小而精的评测集开始也许就 10 到 20 个用例重点覆盖最核心的业务场景。把流程跑顺再逐步扩充。别一上来就想搞一个覆盖所有场景的庞然大物那样大概率会因为维护成本过高而半途而废。还有一个小技巧是每次线上用户反馈了问题别光顾着修 bug记得把出问题的用户对话转化为一条评测用例加进去。这样你的评测集就会像一个不断充实的案例库越到后面对智能体的守护就越严密。 智能体评测实战：用DeepEval构建自动化评估流水线
最近这半年我明显感觉到圈子里聊智能体的热度一直没降但聊来聊去大家最头疼的其实不是“怎么做出来”而是“怎么知道它做得好不好”。你辛辛苦苦搭了个智能体看起来能跑通几条链路可真要拿到业务里去用它到底靠不靠谱用户问一句偏离预设的话它是能机智地拉回来还是直接崩给你看这些问题光靠肉眼点几条 case 根本回答不了。这也是我写这篇东西的初衷。我自己在做智能体评测方案落地的时候踩过不少坑也把市面上主流的方法论和工具都过了一遍。今天想跟你系统聊聊智能体评测这件事——从最核心的评估维度设计到怎么用 DeepEval 这个开源框架把评测变成一条可重复执行的流水线。不管你是刚入门想给自己的 Agent 搭一套评测体系还是已经在做智能体开发、想完善评估流程这篇文章应该都能给你一些能直接上手的参考。1. 为什么智能体评测这么难先别急着聊工具我们得先把“难”这件事掰扯清楚。很多人一开始不理解觉得评测不就是拿一堆问题去问智能体然后看看回答对不对吗如果你也是这么想的那后面十有八九会被现实教育。1.1 从“单点回答”到“多步决策”的质变传统的大语言模型评测本质上是“一问一答”的单轮任务。你丢进去一个问题模型吐出来一段文本你把这段文本和标准答案做个对比或者让人打个分这事儿就完了。问题再难也是静态的、一次性的。但智能体不一样。它不是一个单纯输出文字的模型而是一个“能调用工具、能规划步骤、能根据中间结果动态调整”的系统。我用一个生活化的类比来解释传统模型评测像考学生做选择题答案对了就得分而智能体评测像看一个人独立完成一个复杂的工程项目——他中间要查资料、要写代码、要试错、要根据临时出现的问题改变策略你光看他“最后交出来一份报告”是根本不知道这报告是怎么来的也不知道他在中间有没有绕远路、有没有撞墙。这就引出智能体评测的核心难点——你需要评估的不只是“结果质量”还有“过程质量”。比如一个智能体被要求“帮我查一下某家公司的财报然后总结关键风险”。它如果第一步就把公司名字理解错了后面再怎么努力最后的结果大概率也是错的它如果中间调用工具时参数传错了或者在一个错误的方向上反复重试了十次即便最后侥幸蒙对了答案这种智能体你敢放到生产环境里吗显然不敢。1.2 标准答案缺位你拿什么当“正确”的参照物第二个让我头疼的问题是智能体的任务大多数时候压根没有标准答案。你说“帮我订一家适合团建的餐厅”什么叫“适合”有人在乎环境有人在乎人均价格还有人在乎有没有包间。这种主观性极强的任务你让三个不同的评测人员来打分得出三个不同的分数都很正常。传统评测可以用“字符串匹配”或者“BLEU 分数”来机械地比对答案但智能体的回答是生成的、开放的、多样化的。同一个任务你让它跑三次它可能给出三个都正确但表达方式完全不同的回答。如果你拿着一个死板的标准答案去做匹配那评测结果会惨不忍睹——不是智能体不行是你的评测方案不行。这也是为什么现在大家都在研究“模型即评委”这条路——让大模型去当打分员用语义理解能力来判断回答是否满足需求而不是靠文本层面的硬比对。稍后我会讲到 DeepEval 里面具体是怎么实现的。1.3 环境依赖跑一次一个样评测结果不确定如果你实际跑过智能体你一定遇到过这种让人崩溃的情况同一个测试用例上午跑是成功的下午跑就失败了本地跑好好的部署到服务器上就出问题了。这是因为智能体依赖的外部环境太复杂了。它要调用的 API 可能会限流、会超时它访问的外部网页可能有反爬机制它依赖的数据库数据可能随时在更新。还有一个更隐蔽的坑——大模型本身就有随机性你设置了 temperature 0 也不能保证每次输出完全一致。这种不确定性给评测带来的最大挑战是你很难判断一次失败到底是智能体的问题还是外部环境的偶发问题。我见过太多团队辛辛苦苦写了 20 个评测用例跑完发现 5 个没过第一反应是“智能体有 bug”结果一排查发现是第三方接口当天升级了返回格式根本跟智能体本身没关系。所以评测体系里如果没有“环境控制”和“多次运行取稳定性”的意识你的评测结果一定是失真的。2. 落地前先想清楚评测维度怎么定很多评测报告写得像流水账列了一堆通过率、成功率但老板看了根本不知道这智能体到底能不能用。我后来总结出一个教训评测维度设计一定要从“业务关心什么”出发而不是从“指标容易算”出发。你自己都不清楚要测什么后面一切都是白搭。2.1 五维度模型任务、鲁棒、工具、效率、安全在帮好几个项目设计评测方案之后我逐渐收敛出一套比较通用的五维度模型分享给你参考。第一个维度是任务完成度这是最核心的就是智能体有没有把用户交代的活儿干完、干对。但这个维度千万别简单理解成“成功或失败”的二元判断它需要拆得更细。比如整个任务涉及 5 个步骤智能体只做对了前 3 步就停下来向用户交差了这算成功吗所以任务完成度可以是分级的完全完成、部分完成、未完成甚至可以为每个子步骤单独打分最后加权算总分。第二个维度是鲁棒性。智能体最怕什么怕用户说一些模糊的、有歧义的、甚至带错别字的指令。一个“傻白甜”的智能体用户说“帮我查一下明天的天气”它能处理好但如果用户说“明天那个活动要下雨吗要不要带伞”它就懵了。评测鲁棒性就是要专门准备一批这种“刁钻”输入看智能体能不能在输入不完美的条件下依然保持稳定。第三个维度是工具调用准确率。智能体跟普通聊天机器人最大的区别就是它会调用工具——搜索引擎、计算器、数据库查询接口、第三方 API 等等。有一次我测一个销售助手智能体它在调用 CRM 系统查询客户信息时把客户 ID 和订单号搞混了查出来的数据牛头不对马嘴但它的回答看起来还特别自信。这种“一本正经地给错结果”是最危险的。评测工具调用维度要关注三件事工具选得对不对、参数传得准不准、调用时机合不合理。第四个维度是效率与成本。说白了就是智能体完成一个任务要多少步、要调多少次模型、总共花了多少 token、耗时多久。我见过一个智能体为了回答“今天星期几”这种问题绕了一大圈去调搜索引擎最后总共耗时 12 秒消耗了 4000 多个 token。这种智能体能力上可能没问题但真放到生产环境里成本会让你肉疼。评测中一定要加这个维度别让智能体成为“昂贵的玩具”。第五个维度是安全与合规。这个维度我觉得怎么强调都不过分。智能体如果被恶意用户诱导输出有害内容、泄露系统 Prompt、执行危险操作那后果非常严重。评测时要专门设计一些“攻击性”用例比如越狱提示、提示注入、恶意指令看看智能体能不能守住底线。2.2 怎么把业务目标翻译成可测的指标光有维度还不够你还需要一套“翻译机制”把模糊的业务目标变成可量化的指标。这里我分享一个我自己常用的思路先问自己三个问题——这个智能体最核心的价值是什么如果它犯了错最不能接受的错误类型是什么这个错误能不能用某个可观测的信号来识别举个例子。假设你要评测一个客服智能体业务目标是“提升用户咨询效率”。那核心价值就是“快速准确地解决用户问题”。最不能接受的错误是什么是“让用户的问题没被解决就结束了会话”。那这个错误怎么识别我们可以定义一个指标会话是否以用户明确表达满意比如“谢谢”“明白了”或问题得到应答为正常结束反之如果用户重复提问同一问题超过两次或者会话在无明确结论的情况下中断标记为“未解决率”。如果你能做这一步翻译后面评测其实就顺了。你不需要追求一个能衡量所有东西的“万能指标”你需要的是针对这个智能体的核心业务价值找到几个能反映它做得好不好的关键信号。为了帮你更直观地理解我把上面提到的维度整理成了一个对照表方便你直接参考使用。评估维度业务关注点可量化指标示例常见评测方法任务完成度活有没有干完、干对任务成功率、子步骤完成率人工打分、LLM 评判鲁棒性输入不完美时是否稳定干扰输入下的成功率构造对抗样本、变形测试工具调用准确率工具选择、参数是否正确工具选择准确率、参数准确率日志分析、规则比对效率与成本耗时、token 消耗是否合理平均耗时、平均 token 数日志统计安全与合规是否输出有害内容、泄露信息违规率、拒绝攻击成功率红队测试、敏感内容过滤2.3 维度选型要看场景别搞“一刀切”上面讲的五维模型是一个通用底座但不同场景的智能体侧重点完全不一样。这一点我在实践中体会特别深。比如你做的是一个销售智能体核心场景是帮销售自动找线索、写邮件、跟进客户。这种智能体最关键的维度不是“全能”而是“专业性”——它说出去的话必须对客户有吸引力、不能有事实错误、不能踩合规红线。这种场景下任务完成度里“生成内容质量”的权重就应该提高甚至要专门设计一个“话术合规性”的子维度。但如果你做的是一个数据分析智能体用来帮业务团队写 SQL 查数、生成报表。那最关键的维度就变成了“准确性”和“逻辑严谨性”——SQL 查出来的数据必须对做出来的图表不能误导人。这种场景下你需要重点评测“查询结果正确率”和“数据解读逻辑性”对鲁棒性的要求反而没有那么高因为输入通常都是结构化的查询需求。所以我的建议是五维模型是一个起点但你要根据业务场景调整每个维度的权重或者增加自己独有的子维度。评测方案没有最好只有最合适这个思路一定要带着。3. DeepEval把评测从“玄学”变成工程前面说了这么多理论和理念如果没有一个好用的工具帮你落地那都是空中楼阁。我第一次尝试自己写评测脚本时真的是一把辛酸泪——要自己写模型调用、自己写相似度算法、自己拼提示词让大模型打分还要处理各种 JSON 格式错误和解析失败写了整整两天才跑通一条最简单的评测用例。后来我接触到 DeepEval才算是真正从“手工作坊”走进了“标准化生产”。3.1 DeepEval 是什么它凭什么能帮你DeepEval 是一个开源的 LLM 评测框架它最吸引我的一点是它把评测变成了像 pytest 一样简单的事情。你写过单元测试吗在 Python 里用 pytest 写一个 test 函数然后加个断言就能自动化跑测试。DeepEval 把这种体验带到了智能体评测领域。它内置了各种成熟的评测指标比如 G-Eval一种基于大模型的评分指标、Answer Relevancy回答相关性、Faithfulness忠实性等等你不需要自己造轮子。更关键的是它内置了“LLM 作为评委”的能力——也就是说它会提供一个专门用于打分的“裁判模型”自动对智能体的回答进行多维度的评估。这个设计非常聪明它把最难的“语义理解”和“主观打分”抽象成了一个标准的 API 调用。使用 DeepEval 有三大明显的优势。第一是测试驱动它和 pytest 无缝集成这意味着你可以把评测用例直接纳入 CI/CD 流程每次代码更新都自动跑一遍评测回归测试成本极低。第二是指标丰富内置了几十个评估指标从基础的文本相似度到复杂的语义忠实度都有覆盖了大部分场景。第三是可扩展如果内置的指标不够用你可以很方便地定义自己的自定义指标自由度和灵活性都很好。3.2 概念扫盲TestCase、Metric 与 Dataset深度使用之前有几个核心概念你必须先搞清楚否则看文档会一脸懵。第一个概念是TestCase即测试用例。想象一下你做传统功能测试时一个用例长什么样——包含输入、期望输出、实际输出。DeepEval 中的 LLMTestCase 与此类似但内容更丰富。对于一个智能体的测试用例通常要包含这些字段input用户给智能体的输入也就是用户问题、actual_output智能体实际生成并返回给用户的内容、expected_output期望的标准回答这一步是可以选的、retrieval_context检索上下文如果智能体基于 RAG 做问答这里放检索到的文档片段、tools_called智能体调用的工具列表用于工具调用评测。当你把一次完整的会话录进去这个 TestCase 就定义好了。第二个概念是Metric即度量指标。之前我们聊了评测维度Metric 就是把一个维度具体化之后的算法实现。DeepEval 里每一个 Metric 都是一个类比如AnswerRelevancyMetric回答相关性、FaithfulnessMetric忠实性、ToolCorrectnessMetric工具调用正确性等等。你可以选择用哪个指标然后它会自己内部去算分、去判断通过不通过。每个 Metric 还有一个阈值参数默认是 0.5意思是得分超过 0.5 就算通过但这个值你可以自己调。第三个概念是Dataset即数据集。在实际使用中你的测试用例不可能只有一个会有几十上百个。DeepEval 提供了 Dataset 和 Pytest 集成的方式你可以把几十个 LLMTestCase 放进一个数据集里然后用pytest批量跑。跑完之后还可以集成为一个整体的测试报告方便你查看哪些用例过了、哪些挂了。下面是一个简单的结构示意方便你对照着理解评估场景Dataset里包含多个测试用例LLMTestCase每个用例基于一个或多个指标Metric来打分最后通过断言assert_test来判断是否通过。3.3 安装与初始化环境准备要点DeepEval 的安装非常友好正常流程是pip install deepeval这个命令会帮你把核心框架和它依赖的常用库都装好。但这里我要特别提醒一个关键准备步骤DeepEval 的很多内置指标依赖大模型来判断。因此你需要配置模型访问的 API Key以及指定使用哪个模型作为“评委模型”。我记得自己在配置这块踩过一次坑。当时我想用某个特定的模型但没设对环境变量DeepEval 一直用的默认模型跑出来的结果让我觉得很不准。后来才发现需要在配置里显式地指定judge_model。正确的操作是在你的 Python 代码里实例化指标时这样传入模型配置from deepeval.metrics import AnswerRelevancyMetric from deepeval.models import DeepEvalBaseLLM # 这里假设你已经定义了自己的自定义模型封装类 MyModel model MyModel() metric AnswerRelevancyMetric(modelmodel)也就是说你有两个选择要么把模型 API 地址和密钥配置在环境变量里让框架自动发现要么在代码里显式地传入一个模型实例。如果你自己有特定的偏好模型比如你公司内部基于开源模型微调的私有模型你就可以自己封装一个类把访问逻辑写进去DeepEval 就会用你的模型来当裁判。同样的道理如果你的 OPENAI_API_KEY 已经设置好了大部分情况下开箱即用。但如果你是在内网环境部署或者想用别的模型服务那一开始就要认真看看自定义模型的文档把模型配置搞定再进入下一步。4. 实操用 DeepEval 跑通第一个智能体评测好了理论铺垫了这么多接下来我们直接进入实操环节。我会以一个实际的智能体评测项目为例带你从零开始走一遍完整的流程。为了保证可复现性我举的例子会尽量简单——一个用于“产品推荐”的 RAG 型智能体。4.1 准备一个“可测”的智能体在写评测代码之前你得先有一个已经能够跑通的智能体。我这边用一个简化版的产品推荐智能体来示范它的大致工作流程是接收用户的自然语言问题比如“有什么适合油性皮肤的洗面奶”从知识库中检索相关产品信息模拟 RAG 流程。根据检索结果生成一段推荐回答。为了让评测过程更真实我为它准备了一个简单的知识库里面包含了几条化妆品产品数据格式是这样的{ name: 清透控油洁面乳, skin_type: 油性, features: [控油, 清爽, 不紧绷], price: 99 }在实际项目中智能体可以是你基于任何框架做的关键是它有一个统一的输入输出接口方便你评测。比如你可以把你的 Agent 封装成一个函数输入是用户问题字符串输出是最终的回答字符串再额外返回一个包含工具调用和检索上下文的字典。DeepEval 只关心“输入是什么、输出是什么、上下文是什么”至于你的智能体内部是怎么实现推理的它并不需要知道。这种“黑盒”评测思路好处是能真实反映系统的最终表现。4.2 安装配置与第一个指标测试假设你已经在虚拟环境里装好了 DeepEval并且已经配置好模型相关环境变量。我们来写第一个评测脚本。先从一个最简单的指标——回答相关性开始。回答相关性评测的是智能体生成的内容和用户所问的问题之间相关性有多高。打个比方用户问“适合油皮的面霜有哪些”如果智能体回答的是“我们家的雨伞质量很好”那相关性得分就会非常低反之如果回答的是“这款控油面霜很适合你”相关性得分就会很高。下面是一个完整的测试代码示例import pytest from deepeval import assert_test from deepeval.metrics import AnswerRelevancyMetric from deepeval.test_case import LLMTestCase def query_product_recommendation(query: str) - str: # 这里调用你的智能体 # 伪代码 response your_agent.run(query) # 为演示我们写死一个返回结果 return 这款清透控油洁面乳含有控油成分洗后清爽不紧绷价格99元很适合油性皮肤使用。 def test_product_recommendation_relevancy(): test_case LLMTestCase( input有什么适合油性皮肤的洗面奶, actual_outputquery_product_recommendation(有什么适合油性皮肤的洗面奶) ) metric AnswerRelevancyMetric(threshold0.7) assert_test(test_case, [metric])这段代码的逻辑很简单先定义一个测试用例输入是用户的问题期望输出由你的智能体实际生成。然后定义一个相关性指标阈值设为 0.7。最后用assert_test来断言。如果实际输出与问题的相关性得分超过 0.7测试通过否则失败。当你运行pytest test_recommendation.py时DeepEval 的测试报告会清晰显示每个用例的得分、是否通过以及详细解释。如果你第一次跑出的分数不理想不要慌张对照报告去调整智能体的 Prompt 或检索逻辑这是正常的迭代过程。4.3 用 G-Eval 做更复杂的效果评估如果说相关性还能靠语义匹配糊弄过去那对“回答有没有事实依据”这种偏主观的评估就需要更高级的指标了。G-Eval 是我在实战中用得特别多的一个指标它几乎是目前 LLM-as-a-Judge 的主流实现方案。G-Eval 的思路其实不复杂把评估标准写成一段提示词然后让大模型根据这段标准对智能体的回答进行打分并给出打分理由。它跟直接调 ChatGPT 打分最大的区别是——G-Eval 把评分标准标准化、可配置化了并且它支持 CoT思维链模式能让裁判模型先分析、再打分这样得到的分数更稳定。在 DeepEval 中使用 G-Eval 非常简单你可以直接指定from deepeval.metrics import GEval from deepeval.test_case import LLMTestCaseParams metric GEval( name专业性, criteria评估回答是否专业、准确是否能清楚解释产品特点并给出购买建议。, evaluation_params[LLMTestCaseParams.INPUT, LLMTestCaseParams.ACTUAL_OUTPUT], threshold0.8, )这里有几个地方值得关注。evaluation_params告诉 G-Eval哪些字段是它评估时可以参考的比如这里指定了“输入”和“实际输出”裁判模型就会结合用户的问题和智能体的回答来综合打分。如果你还想让裁判同时参考检索上下文只需要把LLMTestCaseParams.RETRIEVAL_CONTEXT加进去。我第一次用 G-Eval 时犯过一个错误设置的评价标准太笼统。当时我写的是“回答质量要高”结果裁判模型每次给的分数都差不多根本拉不开差距。后来我学乖了把标准写得更具体比如“回答必须包含具体产品名称、价格、适用肤质信息并且语气自然不生硬”。标准越清晰评测结果与人工感受的匹配度就越高。这一点强烈建议你实践的时候多下功夫打磨。4.4 评测工具调用与 RAG 上下文前面几个指标都在关注“回答文本”但在智能体场景里工具调用准确率往往比回答措辞更重要。DeepEval 也提供了专门的指标来处理这个问题。假设你的智能体在回答用户问题时需要调用一个search_products工具来检索数据库。评测时你需要把“实际调用的工具”记录下来。DeepEval 的ToolCorrectnessMetric可以用来评估工具调用是否准确。它的用法也比较直接from deepeval.metrics import ToolCorrectnessMetric test_case LLMTestCase( input找一款适合油性皮肤的洗面奶, actual_output推荐用清透控油洁面乳。, tools_called[search_products(skin_type油性)] ) metric ToolCorrectnessMetric()它会把你实际记录到的工具调用与预期的最佳工具调用做比对评估工具选择是否正确、参数是否合理。对于基于 RAG 的智能体还有一个评测点容易被忽视——检索上下文的相关性。也就是说从知识库里检索出来的那些片段到底切没切中要害。如果你的检索模块返回了一堆不相关的文档那不管生成模块多厉害最终的回答都可能跑偏。你可以用ContextualPrecisionMetric和ContextualRecallMetric这类指标来分别评测检索精度和召回率确保整个系统的输入端是可靠的。4.5 构建数据集并批量运行单个用例跑通之后下一步就是把用例规模扩大。我再强调一遍评测一定要批量化、自动化不能停留在“手动点几个问题看看效果”的阶段。DeepEval 提供了DeepEvalDataset来管理多个测试用例并与 pytest 深度集成。下面是一个批量评测的示例from deepeval import assert_test from deepeval.dataset import DeepEvalDataset from deepeval.metrics import AnswerRelevancyMetric, FaithfulnessMetric dataset DeepEvalDataset([ LLMTestCase( input有什么适合干性皮肤的面霜, actual_output这款深层滋润面霜含有玻尿酸成分适合干性皮肤。, retrieval_context[深层滋润面霜适合干性皮肤含玻尿酸。] ), LLMTestCase( input推荐一款修复敏感肌的精华, actual_output这款舒缓修护精华含神经酰胺适合敏感肌。, retrieval_context[舒缓修护精华含神经酰胺修复皮肤屏障。] ), ]) for test_case in dataset.test_cases: answer_relevancy AnswerRelevancyMetric(threshold0.7) faithfulness FaithfulnessMetric(threshold0.8) assert_test(test_case, [answer_relevancy, faithfulness])这样的好处是当你有新的代码提交时可以直接跑一遍评测看看有没有引入回归问题。如果你用的是pytest配合 DeepEval 的 Pytest 插件你还能直接在命令行看到哪些用例过了、哪些挂了以及每个指标的评分明细。我建议你从项目一开始就养成“每次修改 Prompt 或 Agent 逻辑都跑一遍评测”的习惯。这跟你写代码跑单元测试是一个道理养成习惯之后你对智能体的每一次改动心里都会特别有底。5. 真实的坑与我的解决办法工具用的多了各种幺蛾子见得也就多了。这一部分我把自己踩过的一些比较典型的坑写出来希望能帮你少走弯路。如果你是刚接触 DeepEval 的用户这部分尤其值得认真看一下。5.1 评测结果不稳定今天过了明天挂了这个问题我在前面的理论部分已经提过但这里要讲得更具体一点。用 LLM 当裁判的一个天然问题就是裁判本身有随机性。你跑同一个用例两次的分数可能差 0.2甚至可能一次过、一次挂。如果你要拿这个结果去做发布决策那心里确实很慌。我的解决思路有两层。第一层是降低模型的随机性。在调用裁判模型时把温度参数尽可能调低。因为 DeepEval 在底层调用模型 API你可以在自定义模型的封装里显式设置温度比如temperature0。第二层是多次运行取平均值。对于一些关键用例我会配置对同一个用例重复跑 3~5 次然后取平均分作为最终结果。这跟做实验要三次重复是一个道理能有效规避单次采样带来的偶发偏差。提示评测结果的稳定性本身就是一个可以纳入考核的指标。如果一个用例在多次运行中分数忽高忽低那说明这个用例本身或者系统的某个环节存在不稳定的因素值得进一步排查。5.2 裁判模型的选择与成本平衡DeepEval 支持多种模型作为裁判你可以用 OpenAI 的模型也可以用自己的私有模型。裁判模型选得不同评测结果可能差异很大。我自己的实测感受是裁判模型的能力越强评测结果越接近于人工评分的水平。用 Claude 或 GPT-4 级别的模型做裁判比用小型开源模型打分要靠谱得多。但这里就有一个成本的矛盾评测用的 token 消耗可能比你想想的要多。假设你有 100 个测试用例每个用例跑 3 个指标每个指标可能要做 3 次模型调用那总共就是 900 次模型调用一次评测下来费用其实不低。所以我的建议是开发阶段小规模用例集用较强的模型做裁判确保结果质量。回归阶段大规模用例集可以用相对便宜且速度快的模型先把明显的回归 filter 出来。所有评测结果要做好缓存一旦某个用例跑过且没改动就不需要重复评测。5.3 阈值设置不能拍脑袋现在很多使用者在设置指标阈值时都特别随意直接把代码里的threshold0.5当作默认值用。但阈值实际上是整个评测体系里很关键的参数它直接决定了你的测试会不会通过。我的经验是阈值应该基于“样本校准”来设置。具体来说就是你先把评测系统搭好然后用几十条你已经知道“应该通过”的用例跑一遍统计它们的得分分布把阈值设在得分的下沿位置。然后再用几十条你已经判定为“应该失败”的用例跑一遍确认它们大部分都低于这个阈值。经过这样正反两方向的校准你设置的阈值才有实际意义。如果你直接把阈值拍脑袋定一个 0.7那最后只能是自欺欺人——分数刚好卡在边缘的用例过与不过完全看运气。5.4 别忽略“强制失败”用例最后我要特别提醒一个实操中的细节确保评测集里有“预期失败”的用例。很多人在写评测集时习惯性地只放那些“智能体应该能答对”的问题然后评测报告一片绿看着很爽。但这种全绿的报告没有任何价值。一个健康的评测集应该包含一部分故意刁难智能体的用例——比如用户的问题包含错误信息、用户的指令无法执行、用户试图诱导智能体越权操作。如果你发现这些用例也全绿了那恭喜你你的智能体能力是真的强但更常见的情况是你发现这些用例偶尔会挂几个这恰恰暴露了系统在边界情况下的薄弱点。评测的意义不是证明智能体有多好而是让你知道它什么时候会挂、以及为什么会挂。6. 从评测到迭代把反馈变成改进的闭环写到这里你可能已经能跑通一套评测流程了。但我担心你把它当成一个“终点”——评测完出个报告归档完事儿。如果你是这样用的那评测的作用就大打折扣了。真正有价值的是评测必须反哺到智能体的迭代优化过程中。6.1 失败用例是改进的金矿每次跑完评测我都会第一时间去看失败用例。这些失败一般来说能反映出几个典型问题第一类是由于先决条件缺失导致的失败。比如智能体需要访问数据库权限但评测时没有配置好对应权限。这一类问题属于环境问题修正环境即可并不代表智能体本身能力不行。第二类是工具调用逻辑缺陷。例如智能体在某些场景下选择了错误的工具或者工具的调用顺序不合理。这一类问题需要回到 Agent 的开发逻辑里去找原因往往要调整 Prompt 或者重新设计工具的调度策略。第三类是指令遵循能力不足。用户指令明明很清晰但智能体就是没有执行到位。这时候需要检查你的 System Prompt 是否足够清晰、有没有给到足够的约束。我有时候只是把 Prompt 里的“你应该...”改成“你务必...”评测分数就能有明显的提升。你可以为每次失败的用例打上标签定期统计这些标签的分布。如果“工具调用缺陷”标签占比特别高说明你的工具层设计有比较大的问题如果“指令遵循薄弱”占比较高那就是 Prompt 工程需要加强。这种数据驱动的改进思路比你坐在那里瞎想“智能体哪里有问题”要高效得多。6.2 评测报告要有“可操作性”我见过太多评测报告洋洋洒洒几十页最后领导问一句“所以到底哪里需要改”立刻哑口无言。一份好的评测报告不应该只是罗列分数而是要有明确的分析和结论。我自己的报告格式会是每个失败用例后面标注出“失败原因推测”和“改进建议”每个指标的得分趋势用最近几次迭代的曲线展示出来。这样不管是开发人员还是产品经理拿到报告都能直接知道下一步该干什么。DeepEval 本身也支持导入到它的在线平台在那里你可以把多个历史测试结果对比起来看观察指标的趋势变化。这种趋势甚至比单次结果更重要——如果你的智能体在不断的迭代中各项指标稳步上升那说明方向是对的如果某项指标突然下跌那就需要立刻警惕最近的改动是否引入了问题。6.3 评测体系本身也要迭代最后说一句可能不太中听但很重要的话你的评测体系本身也需要被修正和升级。因为智能体是在不断进化的它的能力边界在扩展它的应用场景在增多。你今天设计的 50 个测试用例可能三个月以后就没法覆盖智能体的新功能了。所以每隔一段时间你需要回过头来审视你的评测集”——旧的用例还合适吗要不要删掉一些已经完全没有区分度的用例要不要补充一些覆盖新能力的用例我从一开始的手动点几个问题到后来的几十条用例再到现在的几百条自动化评测中间经历了无数次对评测体系的调优。这个过程中最大的体会是评测不是一个一劳永逸的工作它应该跟智能体开发本身一样是一个持续迭代、持续完善的过程。如果你刚开始计划给自己的智能体搭评测体系我建议你先从一个小而精的评测集开始也许就 10 到 20 个用例重点覆盖最核心的业务场景。把流程跑顺再逐步扩充。别一上来就想搞一个覆盖所有场景的庞然大物那样大概率会因为维护成本过高而半途而废。还有一个小技巧是每次线上用户反馈了问题别光顾着修 bug记得把出问题的用户对话转化为一条评测用例加进去。这样你的评测集就会像一个不断充实的案例库越到后面对智能体的守护就越严密。