上个月帮一个做客服智能体的团队搭评测体系从评估维度设计到用DeepEval落地前后折腾了两周。过程中最大的感触是很多团队不是不会做智能体而是根本说不清自己的智能体“好不好”。演示时看着挺聪明一上线面对真实用户就各种翻车。这不是模型不行大多是评测缺位导致的——你连“好”的标准都没定义清楚凭什么指望系统稳定输出智能体评测这件事严格来说既不是传统的模型评估也不是普通的软件测试。它介于两者之间既要看模型生成内容的质量又要看任务链条是否跑通、工具调用是否合理、多轮状态下有没有失忆。如果你正在做Agent开发或者团队里没有一个像样的评测机制这篇文章应该能帮你少踩一半的坑。我会从评估维度怎么定、测试数据怎么来讲到DeepEval这个开源评测框架的完整实战流程最后再把我们踩过的问题和排查思路一并交代清楚。1. 先想清楚智能体评测到底在评估什么很多团队上来就急着选工具、跑分数我觉得顺序反了。工具只是执行层真正决定评测有没有用的是评估维度的设计。维度定错了后面全是自嗨。1.1 智能体评测和普通模型评测的差异先说说为什么不能直接拿大模型评测那套东西来套智能体。普通的大模型评测比如给一个问答模型打分本质上是单轮文本输入、单轮文本输出评测者只需要判断生成内容和标准答案的吻合度。但智能体的行为空间要大得多。它可能要先调用检索接口拿资料再决定要不要追问用户还要在多个工具之间做选择甚至需要在多轮对话里记住用户前面提过的偏好。任何一个环节出错最终结果都可能崩。举个例子一个客服智能体处理“我要退货”这个请求正确流程可能是先确认订单号再查订单状态判断是否在退货窗口期最后引导用户走退货流程。如果它第一轮就直接说“好的已为您办理退货”单看这一句回复语言质量很高但放在完整任务里就是个事故——它没核实订单信息就做了承诺。所以评测智能体至少要同时观察两个层面过程层和结果层。过程层看工具调用是否合理、信息收集是否完整、中间决策有没有跑偏结果层看最终回复是否正确、任务目标有没有达成。只测结果不看过程出了问题很难定位只测过程不看结果又容易陷入“步骤都对但客户不满意”的尴尬。1.2 评测维度拆解从任务完成到安全合规具体到维度设计我一般会把候选指标分门别类列出来再根据业务场景做取舍。下面这张表是我常用的维度清单你可以直接拿去当底稿维度核心问题典型例子任务完成率用户的真实诉求有没有被解决退货请求最终是否走到退货流程正确性回复内容本身对不对运费险政策有没有说错相关性回复有没有紧扣问题用户问退款时间别扯到物流速度忠实度生成内容是否基于给定材料有无幻觉引用商品信息时有没有凭空捏造工具调用正确率该调的工具是否调用、参数是否正确查订单时有没有传对订单号多轮一致性与记忆多轮对话中是否记住关键信息用户前面说过“不要电话联系”后面还提不提醒鲁棒性对边界、噪声、对抗输入的承受力用户乱打字、中英混输、同音字是否还能处理效率多少轮完成、响应多快是否绕了三圈才问到订单号安全合规是否输出有害、违法、越权内容是否会泄露其他用户信息成本单次任务消耗多少token一个退款流程是否烧掉几十轮调用这些维度不是都要上。我的判断标准是优先服务于“上线会不会出事”和“用户会不会流失”。打个比方内部工具类智能体工具调用正确率和完成率最关键内容创作类的忠实度和安全红线最重要销售导购类的相关性和多轮记忆就要排前面。1.3 指标怎么定才不虚维度定完之后还要给每个维度选择可量化的指标。这里最容易犯的错是追求“全维度满分”结果摊子铺得太大哪个都测不深。我个人的做法是分级处理。第一级是硬性指标不达标就不能上线比如安全合规、任务完成率通常设硬阈值。第二级是核心体验指标比如正确性、相关性作为回归监控对象。第三级是优化参考指标比如token成本、交互轮次只在优化阶段看趋势不设硬性门槛。还要提醒一点LLM生成内容天然具备概率性任何一个单一分数都不能完全代表系统真实水平。更合理的做法是定义清楚“什么算对”“什么算错”在数据集上给出可复现的判定逻辑而不是拍脑袋定一个90分的及格线。后面讲DeepEval时我会给出一套带置信区间的做法目的就是让分数不那么“虚”。2. 评测数据没有好问题一切的分数都是自嗨评估维度定好之后下一步不是写代码而是攒测试数据集。这个环节最容易被低估。很多团队跑几次评测觉得分数挺高上线却发现实战拉胯原因基本都是测试集和真实用户场景脱节。2.1 数据从哪里来线上日志、人工构造与红队我攒测试集一般走三个渠道比例大概是这样线上真实日志约60%从你已有的对话日志里抽样。注意要覆盖不同意图、不同用户表达习惯别只挑那些回答得好的样本。这是最接近真实分布的数据来源。人工构造的标准场景约30%围绕核心业务流程手工写一批“教科书级”的测试用例。保证主干路径清晰用于验证系统的正常能力。红队对抗用例约10%专门写一些刁钻问题比如含糊表达、错误信息诱导、敏感话题、多轮陷阱。这一类数据是用来找上限的哪怕数量少也多多少少要有。如果你做的是全新的智能体还没有线上日志那就退而求其次用业务方提供的典型用户故事临时构造数据集同时尽早把日志埋点做上后续用线上数据反哺测试集。2.2 最小可用测试集怎么设计关于测试集规模我需要泼一点冷水不要一上来就追求几千条用例。评测集讲究的是结构合理而不是量大管饱。我见过团队花了大力气标了三千条用例结果格式不统一维护成本远高于收益。一个最小可用的测试集约50到100条起步但一定要分层。正常场景占大头边界场景给个二三十条对抗和红队用例给十条左右。如果涉及多轮对话至少要有十到二十条完整的多轮序列。小样本集的好处是迭代快你可以快速跑通整个评测流程发现问题后再逐步扩充。同时要明确规定每条用例的判定依据。这里说的不是简单写个参考答案而是写清楚“这条用例考察什么维度、什么情况算通过”。比如“用户询问退款到账时间”通过标准是“回复中包含预计到账时间且时间范围与退款政策一致”。有了这个标准后面不管是人评、规则评还是LLM评才有据可依。2.3 多轮评测数据怎么组织多轮是智能体评测里最不好搞的部分。早前我踩过一个很深的坑把多轮对话拆成一条条独立的单轮用例去测。结果每个单轮看起来都正常合在一起用户就被气走了。原因很简单拆开之后上下文信息和状态流转全丢了。所以多轮用例应该作为一个完整序列来设计和保存。测试数据里要记录每一轮的完整对话历史、用户当前输入、智能体在这一轮应该采取的动作以及最终是否达成任务目标。另外多轮场景要额外关注状态记忆。比如用户在第三轮提了一句“我是会员”到第八轮询问运费问题时智能体有没有结合会员身份给出正确的优惠说明。这种跨轮信息依赖恰恰是单轮评测永远覆盖不到的盲区。3. 工具选型为什么我选了DeepEval而不是自己写脚本数据和维度都准备得差不多了这时候才轮到工具登场。智能体评测领域现在可选的工具不少有商业的、有开源的也有团队自己撸脚本的。我会先讲讲我对比过的几条路线再说为什么最后选了DeepEval。3.1 通用方案对比自己写脚本、LangSmith、Ragas、DeepEval自己写评测脚本是最常见的起点。思路也不复杂把测试用例喂给智能体拿到回复后调用一个LLM写段prompt让它给你打分最后汇总平均分。这条路在demo阶段完全够用我也这么干过。但用一段时间就会发现问题分数的判定标准写死在prompt里换一个模型评判分就飘了想加一个新指标要改一堆代码评测过程和CI集成也麻烦输出格式全靠自己定义。说白了自己写脚本适合验证想法不适合长期维护。LangSmith自带评测能力跟LangChain生态集成度高如果你的Agent就是基于LangChain搭的用起来确实顺手。但它绑定在LangChain体系里非LangChain项目接入会有额外负担。Ragas在RAG场景的评测上做得比较深指标丰富社区活跃。但它更聚焦检索增强生成对智能体的工具调用链路和任务级完成度评估支持相对有限。如果你主要做RAG应用Ragas值得考虑如果你做的是多步骤、多工具的Agent它就不是最优解。DeepEval让我看中的点有几个它基于pytest天生适合作为自动化测试的一部分跑进CI内置了多套成熟指标比如回答相关性、忠实度、G-Eval等支持自定义评估标准方便对接我们自定义的复杂指标评测结果会自动计算置信区间这点很对我胃口。稍后我会详细展开。3.2 DeepEval的工作原理用LLM评LLMDeepEval这类工具的本质是“用LLM来评测LLM”。它的核心指标比如AnswerRelevancy、Faithfulness底层都是构造一段特殊的prompt把待评测的输入输出、参考信息、评分标准交给一个评判模型由评判模型给出分数和理由。你可能会问用一个模型去评价另一个模型靠谱吗我的理解是这种评测方式追求的本来就不是绝对客观而是“一致性”。人类标注员之间还有分歧呢关键是判定标准是否明确、评判模型是否稳定。DeepEval的做法是尽量把评分标准结构化、步骤化减少模糊空间。比如G-Eval指标里它会引导评判模型按步骤推理先逐条核对事实再给最终分而不是让模型凭感觉打分。DeepEval同时支持“单指标度量”和“多指标组合”还可以定义自定义指标。不同的测试用例可以使用不同的评测指标集合这一点对我们的场景非常实用。比如纯知识问答类用例重点看正确性工具调用类用例重点看工具参数和调用时机各有各的评分方案。3.3 安装与环境准备DeepEval的安装非常轻量。它就是一个Python包支持Python 3.8以上的环境。安装命令很简单但我还是建议你在虚拟环境里装避免污染全局环境。pip install deepeval装完之后需要配置评判模型的API key。DeepEval默认支持多种主流模型提供商包括OpenAI兼容接口的各类模型。假设你用的是OpenAI的模型设置环境变量即可export OPENAI_API_KEY你的key如果你的运行环境只能访问私有化部署的模型服务DeepEval也支持自定义评审判定模型。这个后面我会讲到先按下不表。提示安装之前确认一下你的Python版本如果你还在用Python 3.7或更早版本建议先升级环境。另外建议把deepeval固化到requirements.txt里保证团队其他成员拉下来跑的结果一致。4. DeepEval实战从第一条测试用例到多指标评测工具装好了下面我们进入实战环节。我会从最简单的单条用例开始逐步增加到多指标组合、自定义评判器最后给出一个相对完整的智能体评测套件。4.1 先写一个最小可运行用例先做一个最朴素的评测判断智能体回答的相关性。代码很简短先跑通再谈复杂度。from deepeval import assert_test from deepeval.metrics import AnswerRelevancyMetric from deepeval.test_case import LLMTestCase test_case LLMTestCase( input退货的运费谁承担, actual_output亲因个人原因产生的退货运费需要您自行承担。如果是因为商品质量问题运费由我们承担。, ) metric AnswerRelevancyMetric(threshold0.7) assert_test(test_case, [metric])这段代码干了三件事定义了一条测试用例选择了一个评测指标AnswerRelevancy阈值设为0.7然后执行断言。如果评测分数低于阈值assert_test会直接报错退出这也是它能无缝接入pytest和CI的原因。跑完一次之后DeepEval会在终端输出分数的同时给出置信区间。这个区间很关键——如果评估模型的打分忽高忽低区间的宽度会直接暴露不稳定。我们后面会专门讲怎么处理这个问题。4.2 组合指标打造客服智能体评测用例单条用例跑通了接下来要加码。一条真正有意义的智能体评测通常要同时看多个维度。例如对一个客服问答智能体的回复我一般会同时检查“相关性”和“忠实度”。相关性保证回答切题忠实度保证回答没有胡编乱造。from deepeval import assert_test from deepeval.metrics import AnswerRelevancyMetric, FaithfulnessMetric from deepeval.test_case import LLMTestCase test_case LLMTestCase( input这个手机支持无线充电吗, actual_output支持的这款手机支持15W无线充电。, retrieval_context[ 产品参数支持15W无线充电, 产品包装内含无线充电器, ], ) relevancy_metric AnswerRelevancyMetric(threshold0.7) faithfulness_metric FaithfulnessMetric(threshold0.7) assert_test(test_case, [relevancy_metric, faithfulness_metric])这里重点说下retrieval_context参数。如果智能体背后接了知识库或检索系统把检索到的上下文传进去FaithfulnessMetric就能逐句核对回复内容是否来自给定的上下文从而捕捉幻觉问题。如果智能体根本没有检索环节这个参数可以不传或者传空列表。实际跑下来我发现FaithfulnessMetric对长文本的敏感度比较高回答越长越容易误判。后文常见问题部分我会专门教你怎么规避。4.3 使用G-Eval定义自定义评分标准内置指标覆盖不了所有场景。比如你想评估“客服是否有礼貌地拒绝了不合理请求”这种偏主观的标准内置指标很难直接体现。DeepEval提供了G-Eval自定义指标允许通过自然语言描述评估标准再由评判模型按步骤打分。示例代码如下from deepeval import assert_test from deepeval.metrics import GEval from deepeval.test_case import LLMTestCase politeness_metric GEval( name礼貌性, criteria判断客服回复是否礼貌、尊重用户。如果客服语气傲慢、嘲讽或生硬则分数不应高于0.5。, evaluation_steps[ 检查回复是否使用礼貌用语, 检查回复是否对用户情绪有回应, 检查回复是否包含负面或攻击性表达, 综合以上因素给出0到1之间的分数, ], ) test_case LLMTestCase( input你们客服是机器人吗, actual_output我是智能客服小助手哦有什么可以帮您, ) assert_test(test_case, [politeness_metric])G-Eval的精髓在于evaluation_steps。你给出的步骤越具体评判结果越稳定。我习惯把标准拆到“能直接照着检查”的程度而不是写一句笼统的“要礼貌”。前面也说过降低模糊性就是提升可复现性。4.4 批量执行与测试报告输出单条用例只是验证真正的评测要批量跑。DeepEval天然支持pytest所以可以直接把一条条评测逻辑包装成测试函数。import pytest from deepeval import assert_test from deepeval.metrics import AnswerRelevancyMetric from deepeval.test_case import LLMTestCase def get_answer(input_text): # 这里调用你的智能体返回actual_output return 回复内容 pytest.mark.parametrize( user_input,expected_context, [ (退货的运费谁承担, [运费规则]), (发货后可以改地址吗, [修改地址规则]), (商品有质量问题怎么办, [售后政策]), ], ) def test_customer_service(user_input, expected_context): actual_output get_answer(user_input) test_case LLMTestCase( inputuser_input, actual_outputactual_output, retrieval_contextexpected_context, ) metric AnswerRelevancyMetric(threshold0.7) assert_test(test_case, [metric])跑完之后DeepEval会自动生成一份可视化测试报告并在终端展示。你可以把所有用例的分数、指标结果、每个用例的评判详情一屏看清。报告会给出整体通过率和每条用例的达标情况方便你回查是哪类用例拉低了分数。只要你的智能体实现了一个稳定的接口这批test case就是一套可重复执行的回归测试集。以后每次改动prompt、升级模型或调整工具逻辑都可以快速重跑一遍看分数是涨是跌。5. 搭一套可落地的评测流程从本地到CI评测不是跑一次就完事。想让评测体系真正发挥作用必须把它嵌入到开发和发布流程中去。这一节讲怎么在DeepEval基础上搭建一套可以长期运转的评测流水线。5.1 评测目录结构怎么组织我先给出一套实践过多次的目录结构供你参考agent_eval/ ├── test_cases/ # 测试用例数据json / yaml │ ├── normal_cases.yaml │ ├── boundary_cases.yaml │ └── red_team_cases.yaml ├── custom_metrics/ # 自定义指标和评判器 │ └── politeness_metric.py ├── conftest.py # pytest全局配置 ├── test_agent_basic.py # 基础能力评测 ├── test_agent_multi_turn.py # 多轮对话评测 └── requirements.txt我的习惯是测试数据不要直接硬编码在代码里而是以yaml或json文件维护。这样业务同学也能参与维护用例不用碰代码。比如一个normal_cases.yaml可以长这样- id: case_001 input: 退货的运费谁承担 expected_context: [运费规则] target_metric: answer_relevancy - id: case_002 input: 现在买有优惠吗 expected_context: [促销活动] target_metric: answer_relevancy再用pytest的fixture或参数化方式读入这些数据代码逻辑和测试数据分离维护成本立刻降一半。5.2 接入CI每次提交跑子集定时全量回归对于一个评测流程来说最怕的不是跑得慢而是跑得太慢谁也懒得跑。全量评测集如果上千条用例每跑一次可能要花大量token和时间不适合放在每次提交里。所以我的建议是分两层。第一层是快速冒烟测试每次提交或提PR时运行从全量测试集中抽一小批覆盖核心场景的用例比如五六十条精选用例目标是秒级到分钟级跑完快速暴露明显回归。第二层是深度回归每天定时或每次发版前跑全量测试集目标是把所有边界、对抗用例都过一遍。在CI平台里DeepEval的pytest用例可以直接集成。常见的做法是提供一个独立的job先装依赖、跑评测非零退出码即视为失败。这样任何一次代码改动导致智能体质量下滑CI都会直接拦住。5.3 阈值怎么设别拍脑袋定分数阈值设计是评测体系里一个特别容易被忽略的环节。很多人设0.7这个值只是因为“感觉0.7还行”但实际上阈值应该来源于数据。我的做法是先跑一轮全量评测拿到基线分数观察各指标在“已知正常”情况下的分布再结合业务容忍度设置阈值。比如基线正确性平均0.82标准差0.05那我可能把阈值设到0.75留出约一个标准差的波动空间。如果你用DeepEval生成的多轮报告里看到了置信区间阈值设置时尽量让目标落在置信区间以内这个位置通常更安全。提示如果基线本身就低比如忠实度只有0.55第一优先级不是把阈值降到0.5来自我安慰而是先解决智能体幻觉问题再逐步提高阈值。设置阈值是质量门禁的手段不是掩饰问题的方式。5.4 自定义评判器接入企业私有模型不少企业内部无法直接调用外部API模型或者对评测数据的隐私有严格要求。DeepEval允许自定义评判模型你可以在初始化时指定代理指向私有化部署的模型服务。from deepeval.models import DeepEvalBaseLLM class PrivateJudge(DeepEvalBaseLLM): def __init__(self, model_endpoint): self.model_endpoint model_endpoint def load_model(self): # 加载你的私有模型客户端 return create_client(self.model_endpoint) def generate(self, prompt: str) - str: model self.load_model() return model.invoke(prompt) async def a_generate(self, prompt: str) - str: return self.generate(prompt) judge_model PrivateJudge(model_endpointhttp://your-internal-model:8000/v1) relevancy_metric AnswerRelevancyMetric(modeljudge_model, threshold0.7)这里有个需要注意的地方评判模型的稳定性和能力会直接影响所有分数。如果你私有部署的是一个小参数模型它在执行复杂评判时的效果大概率不如大参数模型评估结果的可信度会下降。我的经验是尽量让评判模型比待测模型强一个档次同时固定版本不要今天用这个明天换那个不然无法对比历史分数。6. 常见问题与排查实录最后这一部分我想把实际使用DeepEval和搭评测体系时踩过的比较有代表性的问题整理一下每个问题都附上排查思路和处理建议。这些问题单看不大但遇到一个就能卡你好几天。6.1 LLM评判器不稳定换模型分数就变这是最常被问到的问题。同一批测试集上周跑0.85这周换了个评判模型直接掉到0.72到底哪个分数可信先明确一点LLM评判器本身就是有“性格”的不同模型对同一段文本的感知差异很大。我的建议是“锁定一个强力的评判模型不轻易更换”。把评判模型视为评测环境的一部分固定版本固定参数甚至固定温度。评测的目标是监控待测系统的变化而不是追着评判模型的波动跑。如果你希望进一步降低随机性可以让同一条用例用同一评判模型跑多次取平均分和方差。DeepEval允许对同一指标重复评测叠加置信区间的报告能帮你区分分数的波动是来自待测系统还是来自评判模型。6.2 Token成本高全量跑一次太贵评测本质上是用钱换质量反馈。全量上千条用例每条可能涉及多次LLM调用一晚上跑掉几百万token很正常。对此我一般采取三个策略分层抽样日常冒烟测试只跑核心子集全量回归放到低频时段。简化上下文不是每个指标都需要完整的retrieval_context能精简就精简。对相似的用例去重很多线上日志用例表达意图相同只是措辞不同。这类用例保留几条有代表性的就够不需要全部保留在评测集里。6.3 Faithfulness在长回答中误判率高我自己的观察是回答越长FaithfulnessMetric越容易把正确内容判为幻觉。原因在于评判模型需要逐句核对长文中的每个事实一旦某个句子表述上有歧义就会被误判。这个问题的缓解办法有两个方向。一是让待测智能体尽量给出结构性更强的回答分点表述明确每个点对应的上下文来源。二是把长回答拆成多个短句分别评测或用摘要先压缩再参与忠实度评估。实际项目中我们通常会在评测入口加一个“按句切分再汇总”的环节误判率能下降不少。6.4 多轮场景测不准拆分后又不真实前面我提过多轮用例不能简单拆成单轮但完整的测试序列往往难以构造和标注。折中的做法是“关键决策点拆解”。也就是说保留多轮上下文但评分目标锁定在某一轮的关键决策上。比如一个五轮对话我只关注智能体在第三轮是否询问了订单号那么这条用例的“断言”就聚焦在第三轮的输出和行为上前两轮作为上下文输入传入后两轮可以忽略。这样做既保留了上下文信息又把评测从“全序列结果校验”简化为“关键行为校验”可行性高很多。6.5 评测结果和线上表现对不上这个问题通常指向评测环境与线上环境不一致。可能是prompt版本不一致、模型版本不一致甚至工具调用逻辑存在分支差异。建议在每次评测时把以下信息记录下来作为评测报告的一部分智能体代码版本、prompt版本、模型名称与版本、评测集版本、评判模型版本。有了这些信息一旦出现分数突变就可以回溯定位。另外还有一个容易被忽略的点线上用户的输入非常脏有错别字、口音梗、无意义符号而评测用例通常都比较“干净”。如果评测集里没有加入脏数据样本评测结果自然无法反映线上真实表现。红队用例和线上日志抽样就是专门用来补齐这个差距的。这套流程跑通之后再回头去看智能体开发会发现评测不是最后一环的动作而是应该贯穿整个迭代周期。每次改prompt、换模型、调工具都顺手跑一遍核心评测集手感完全不一样。我个人在实际操作中还有一个很深的体会评测用例要当bug来管。用例不是写完就完了线上发现一个典型问题就沉淀一条对应的用例评测发现一个漏网的边界场景也补进测试集。这样你的评测体系会越用越厚智能体也会越改越稳。与其迷信某个分数不如把评测当成一套持续生长的质量台账它记录的不只是智能体的水平还有你对这个问题的理解深度。