1. 从“跑分”到“判卷”智能体评测的终局思维做智能体开发这两年我最大的感受就是评测这件事正在从“技术活”变成“治理活”。早期我们评测一个智能体无非是跑几个benchmark看看准确率、召回率、响应时间这些硬指标。但到了2026年当智能体开始大规模进入企业生产环境评测的维度就完全变了——它不再只是回答“这个智能体行不行”而是要回答“这个智能体在什么条件下会出问题、出了问题谁来兜底、怎么保证它持续不出问题”。这就是“评测即治理”的核心逻辑。评测不再是一个独立的测试环节而是贯穿智能体全生命周期的治理手段。你设计评测集的过程本质上是在定义智能体的行为边界你选择评测指标的过程本质上是在设定智能体的价值取向你执行评测的频次和方式本质上是在建立智能体的运维规范。我见过太多团队把评测当成“上线前的最后一道关卡”结果上线后各种边界case层出不穷最后不得不返工重做。真正有效的做法是把评测前置到需求阶段把评测嵌入到开发流程把评测固化为运营机制。这篇文章我就把这套“评测即治理”的完整思路拆开来讲从评测体系设计、核心指标拆解、实操落地步骤到常见坑点排查全部基于我实际项目中的经验能直接抄作业的那种。2. 评测体系设计从“单点测试”到“治理框架”2.1 为什么传统评测方法在智能体时代失效了传统软件测试的核心假设是输入确定输出可预期。你给一个函数传参数它返回什么结果是确定的所以你可以写断言、跑用例、算通过率。但智能体完全不是这个逻辑——同一个问题你问十遍它可能给你十个不同的回答而且每个回答都“看起来有道理”。我刚开始做智能体评测的时候踩过一个大坑用传统测试用例的方式去测一个客服智能体写了200条用例跑完发现通过率只有60%。当时第一反应是“这智能体不行”但仔细一看失败案例发现很多是“回答风格不符合预期”而不是“回答内容错误”。比如用户问“你们家产品多少钱”智能体回答“我们的产品价格根据配置不同有所差异建议您联系销售获取详细报价”——这个回答在业务上是完全正确的但测试用例里写的是“应该直接给出价格区间”所以被判为失败。这个坑让我意识到智能体的评测不能只看“对不对”还要看“好不好”、“稳不稳”、“该不该”。这三个维度分别对应功能正确性、体验质量和安全合规缺一不可。2.2 三层评测框架功能层、体验层、治理层基于上面的教训我总结了一套三层评测框架从下到上分别是功能层这是最基础的测的是智能体“能不能完成任务”。比如问答智能体能不能准确回答用户问题代码智能体能不能生成可运行的代码销售智能体能不能正确识别客户意图。这一层的评测方法相对成熟核心是构建高质量的评测集覆盖典型场景和边界场景。体验层这一层测的是智能体“完成任务的过程好不好”。包括响应速度、回答风格、多轮对话的连贯性、对模糊问题的澄清能力等。这一层最容易被忽视但恰恰是用户感知最强的部分。我见过一个智能体功能测试通过率95%但上线后用户满意度只有60%原因就是回答太生硬、不会追问、遇到不确定的问题就瞎编。治理层这是最高层测的是智能体“该不该这么做”。包括安全合规、价值观对齐、数据隐私保护、对抗攻击的鲁棒性等。这一层在2026年变得尤其重要因为智能体开始有了“行动能力”——它不只是回答问题还能调用API、操作数据库、发送邮件。一旦行为失控后果比“回答错误”严重得多。这三层不是孤立的而是层层递进的关系。功能层不过关体验层和治理层无从谈起但功能层过关了体验层和治理层不过关智能体照样不能上线。2.3 评测集构建从“拍脑袋”到“数据驱动”评测集的质量直接决定了评测结果的可信度。我见过太多团队在评测集上偷懒——随便找几个人写几十条用例跑完就完事。这种做法在早期探索阶段可以但到了生产环境必须用数据驱动的方式构建评测集。我的做法是从真实用户日志中挖掘评测用例。具体来说分三步走第一步收集线上真实对话数据按意图分类。比如客服智能体的对话可以分成“产品咨询”、“售后问题”、“投诉建议”、“闲聊”等类别。每个类别下统计高频问题和长尾问题。第二步对每个类别的问题标注“标准答案”和“可接受答案范围”。标准答案是理想情况下的最优回答可接受答案范围是允许智能体发挥的空间。比如“产品多少钱”这个问题标准答案可能是“我们的产品分为基础版199元/月、专业版499元/月、企业版定制报价”可接受答案范围包括“价格根据版本不同有所差异基础版199元起”这类回答。第三步定期更新评测集。智能体的能力在进化用户的问题也在变化评测集如果一成不变很快就会失效。我一般建议每两周更新一次评测集每次更新比例控制在10%-20%之间既能反映最新情况又能保持评测结果的连续性。注意评测集不是越大越好。我见过一个团队搞了上万条评测用例跑一次要几个小时结果没人愿意跑。评测集规模控制在200-500条比较合适关键是要覆盖全面、标注准确。3. 核心指标拆解每个数字背后的治理含义3.1 准确率不只是“答对了多少”准确率是最直观的指标但也是最容易被误读的指标。很多人把准确率简单理解为“答对的题数除以总题数”但在智能体场景下这个定义太粗糙了。我一般会把准确率拆成三个子指标严格准确率智能体的回答与标准答案完全一致的比例。这个指标最严格但实际意义有限因为智能体的回答往往有多种正确表达方式。宽松准确率智能体的回答在可接受答案范围内的比例。这个指标更实用能反映智能体在真实场景下的可用性。关键准确率在关键场景如涉及金额、安全、合规的问题下智能体回答正确的比例。这个指标最重要因为关键场景一旦出错后果可能很严重。举个例子一个金融智能体宽松准确率90%但关键准确率只有70%那这个智能体绝对不能上线。因为那30%的关键错误可能意味着错误的投资建议、错误的费率计算直接导致用户损失。3.2 召回率被忽视的“另一半”召回率在智能体评测中经常被忽视但它其实和准确率一样重要。准确率衡量的是“智能体给出的回答中有多少是正确的”召回率衡量的是“所有应该被回答的问题中智能体实际回答了多少”。我见过一个智能体准确率很高但召回率很低——它只回答那些它“确信”的问题遇到不确定的问题就转移话题或者直接说“我不知道”。这种策略在准确率上很好看但用户体验很差因为用户真正需要帮助的问题往往就是那些“不确定”的问题。召回率的评测方法相对复杂需要构建一个“问题全集”然后看智能体实际回答了多少。我的做法是从真实用户日志中抽取1000个问题人工标注哪些是“应该被回答的”然后看智能体实际回答了多少个。召回率低于80%的智能体我一般不建议上线。3.3 响应时间用户体验的“生死线”响应时间这个指标看起来很简单但实际评测中有很多坑。首先响应时间的定义要明确——是从用户发送消息到收到第一个字符还是到收到完整回答这两个指标差异很大。我一般建议用“首字响应时间”和“完整响应时间”两个指标。其次响应时间的阈值要根据场景设定。闲聊场景下用户对响应时间的容忍度较高3-5秒都能接受但客服场景下用户期望的是即时响应超过2秒就会明显感到不耐烦。最后响应时间的评测要分位数统计不能只看平均值。平均值1秒但P99是10秒那意味着1%的用户要等10秒这个体验是很差的。我一般关注P50、P90、P99三个分位数分别对应“典型体验”、“较差体验”和“最差体验”。3.4 安全合规指标治理层的“红线”安全合规指标是治理层的核心也是最难量化的部分。我一般从四个维度来评测内容安全智能体的回答是否包含违规内容。这个可以通过关键词过滤人工抽检的方式评测。行为安全智能体调用外部工具时是否超出授权范围。比如一个查询天气的智能体不应该有权限访问用户通讯录。数据隐私智能体在处理用户数据时是否遵守隐私保护规范。比如不应该在回答中泄露其他用户的个人信息。对抗鲁棒性智能体在面对恶意输入时是否能保持稳定。比如面对提示词注入攻击是否能拒绝执行恶意指令。这四个维度的评测我一般建议用“红队测试”的方式——组织专门的测试人员模拟恶意用户尝试各种攻击手段记录智能体的表现。4. 实操落地从评测方案到治理闭环4.1 评测流程设计四个阶段缺一不可一个完整的智能体评测流程应该包含四个阶段阶段一离线评测。在智能体上线前用构建好的评测集进行批量测试。这个阶段的目标是发现明显的问题比如功能缺失、回答错误、响应超时等。离线评测一般跑全量评测集输出详细的评测报告。阶段二灰度评测。智能体上线后先面向小比例用户开放收集真实反馈。这个阶段的目标是发现离线评测覆盖不到的问题比如真实用户的表达方式差异、多轮对话中的上下文丢失等。灰度评测一般持续1-2周根据反馈调整后再扩大范围。阶段三在线评测。智能体全量上线后持续监控核心指标。这个阶段的目标是发现指标异常比如准确率突然下降、响应时间突然变长等。在线评测一般用自动化监控人工抽检的方式。阶段四定期复评。每隔一段时间如一个月用最新的评测集对智能体进行全面复评。这个阶段的目标是发现智能体的能力退化比如因为模型更新导致的回答风格变化、因为数据漂移导致的准确率下降等。这四个阶段不是一次性的而是循环往复的。每次复评发现的问题都要反馈到下一轮的离线评测和灰度评测中形成闭环。4.2 评测工具选型自建还是采购评测工具的选择取决于团队的规模和需求。我一般建议分三种情况小团队1-3人直接用开源工具脚本。比如用Python写评测脚本用pandas做数据分析用matplotlib做可视化。这种方式成本低、灵活度高但需要一定的开发能力。中型团队5-10人用开源评测框架自建平台。比如用RAGAS做检索增强生成的评测用LangSmith做链路追踪然后自建一个简单的评测管理平台。这种方式兼顾了灵活性和效率。大型团队10人以上采购商业评测平台自建核心能力。商业平台提供标准化的评测流程和报告自建部分负责定制化的评测需求。这种方式成本高但能保证评测的专业性和一致性。我个人的经验是评测工具的核心不是功能多强大而是能不能融入现有的开发流程。如果评测工具需要开发人员手动触发、手动分析结果那再好的工具也会被弃用。最好的评测工具是能自动触发、自动分析、自动告警的工具。4.3 评测结果分析从“看数字”到“找原因”评测结果分析最忌讳的就是只看数字不看原因。准确率下降了5%为什么下降是哪些类型的问题下降了是模型更新导致的还是数据漂移导致的这些问题不搞清楚评测就白做了。我的分析方法是先看整体再看分组最后看个案。先看整体指标判断是否有异常。如果整体指标正常那就不需要深入分析。如果整体指标异常进入下一步。再看分组指标定位问题范围。比如按意图分类看准确率发现“售后问题”类别的准确率下降了20%那问题就定位到了这个类别。最后看个案找到具体原因。从“售后问题”类别中抽取失败案例人工分析失败原因。是模型不理解问题还是知识库缺失还是回答模板有问题找到原因后才能针对性修复。4.4 治理闭环评测结果如何驱动智能体迭代评测的最终目的是驱动智能体迭代。如果评测结果只是写个报告、开个会然后就没有然后了那评测就失去了意义。我一般建议建立这样的治理闭环评测发现问题 → 分类归因 → 制定修复方案 → 实施修复 → 回归评测 → 上线验证。这个闭环中最关键的是“分类归因”和“回归评测”。分类归因决定了修复方案的方向回归评测决定了修复是否有效。我见过太多团队跳过回归评测直接上线修复版本结果引入新的问题。提示回归评测的评测集应该包含两部分一部分是历史失败案例验证修复是否有效另一部分是历史成功案例验证修复是否引入新的问题。两部分都通过才能上线。5. 常见问题与排查技巧实录5.1 评测结果波动大怎么办评测结果波动大是智能体评测中最常见的问题。同一个智能体今天跑准确率90%明天跑可能只有85%。这种波动可能来自三个原因模型本身的随机性。智能体背后的模型通常是概率模型同样的输入可能产生不同的输出。这种波动是正常的但如果波动范围超过5%就需要关注。评测集的问题。评测集中的问题如果表述模糊、标注不一致会导致评测结果不稳定。我一般建议对评测集做一致性检查确保每个问题的标注是明确的、无歧义的。评测环境的问题。评测环境的网络延迟、API限流、并发数等因素都可能影响评测结果。我一般建议在固定的环境下评测每次评测前检查环境是否正常。排查方法先固定评测集和环境跑三次评测看结果波动范围。如果波动范围在3%以内属于正常如果超过5%需要检查评测集标注和环境配置。5.2 评测通过但上线出问题怎么排查这种情况我遇到过好几次最典型的一次是离线评测准确率95%上线后用户投诉不断。排查后发现离线评测用的是“标准问题”而上线后用户用的是“口语化问题”。比如离线评测问“如何修改密码”上线后用户问“密码忘了咋整”智能体就懵了。排查思路对比离线评测和线上真实对话的差异重点看三个方面——问题的表达方式、问题的长度、问题的上下文。如果差异较大说明评测集不够真实需要补充真实用户日志中的问题。5.3 多轮对话评测怎么做多轮对话评测是智能体评测中的难点。单轮对话评测你只需要看当前问题的回答多轮对话评测你还要看上下文是否连贯、指代是否清晰、状态是否保持。我的做法是构建“对话场景”而不是“单个问题”。比如一个订票场景包含“查询航班→选择航班→填写乘客信息→确认订单→支付”五个步骤每个步骤都有对应的用户输入和期望的智能体输出。评测时按顺序执行这五个步骤看智能体是否能正确完成整个流程。多轮对话评测的关键指标是“任务完成率”和“对话轮次”。任务完成率衡量智能体是否能完成整个任务对话轮次衡量智能体是否高效。一个智能体如果任务完成率100%但平均需要20轮对话才能完成那体验也是很差的。5.4 评测成本太高怎么优化评测成本主要包括三部分人力成本、计算成本、时间成本。优化评测成本我一般从三个方面入手自动化。能自动化的评测绝不人工。比如内容安全评测可以用关键词过滤模型分类的方式自动化响应时间评测可以用脚本自动化。抽样。不是所有评测都需要全量跑。日常监控可以抽样跑比如每天抽100条定期复评可以全量跑比如每月一次。分层。不同阶段的评测用不同的评测集。离线评测用全量评测集灰度评测用核心评测集在线评测用抽样评测集。5.5 常见问题速查表问题现象可能原因排查方法解决方案准确率突然下降模型更新、数据漂移、评测集变化对比历史评测结果定位变化点回滚模型、更新知识库、校准评测集响应时间变长并发增加、API限流、模型推理变慢监控系统指标定位瓶颈扩容、优化调用链路、模型量化多轮对话丢失上下文上下文窗口不足、状态管理bug复现对话流程检查上下文传递扩大上下文窗口、修复状态管理逻辑安全合规评测不通过提示词注入、越权调用、数据泄露红队测试模拟攻击加强输入过滤、权限控制、数据脱敏评测结果不可复现评测环境不一致、模型随机性固定环境多次评测统一评测环境、设置随机种子6. 评测即治理从项目实践到组织能力6.1 评测治理的组织保障评测即治理不只是技术问题更是组织问题。如果团队里没有人对评测负责评测就永远做不好。我一般建议设立三个角色评测负责人负责评测体系的整体设计包括评测集构建、指标定义、流程设计。这个角色需要既懂技术又懂业务能协调各方资源。评测执行人负责日常评测的执行包括跑评测、分析结果、写报告。这个角色需要细心、耐心能发现细节问题。评测审核人负责评测结果的审核包括确认评测方法是否合理、结果是否可信、修复方案是否有效。这个角色需要有一定的权威性能推动问题修复。这三个角色可以是兼职的但必须有明确的责任人。我见过太多团队评测工作“人人有责”但“人人不负责”最后评测流于形式。6.2 评测文化的建设评测文化是比评测工具和流程更底层的东西。一个团队如果有良好的评测文化即使工具简陋、流程简单评测也能做好反之如果团队不重视评测再好的工具和流程也是摆设。建设评测文化我一般从三个方面入手让评测可见。把评测结果放在团队看板上让每个人都能看到智能体的表现。好的结果要表扬差的结果要分析。让评测有趣。把评测变成一种“游戏”比如设立“找bug奖”鼓励大家发现智能体的问题。我见过一个团队每周评选“最佳找茬奖”大家的积极性很高。让评测有用。评测结果要真正驱动迭代而不是写完报告就结束。每次评测发现的问题都要有明确的修复计划和验证结果。6.3 从单点评测到持续治理最后我想强调的是评测不是一次性的项目而是持续的过程。智能体在上线后会面临不断变化的环境——用户需求在变、数据分布在变、竞争对手在变。如果评测停留在“上线前跑一次”的阶段智能体很快就会落后。持续治理的核心是建立“评测-反馈-迭代”的闭环。这个闭环的运转速度决定了智能体的进化速度。我见过一个团队每周跑一次评测每周迭代一次智能体三个月后智能体的准确率从70%提升到了90%。另一个团队一个月才跑一次评测智能体半年都没什么进步。评测即治理治理即进化。把评测做好智能体才能越用越聪明越用越可靠。这个系列到这里就收官了但智能体的评测和治理才刚刚开始。
1. 从“跑分”到“判卷”智能体评测的终局思维做智能体开发这两年我最大的感受就是评测这件事正在从“技术活”变成“治理活”。早期我们评测一个智能体无非是跑几个benchmark看看准确率、召回率、响应时间这些硬指标。但到了2026年当智能体开始大规模进入企业生产环境评测的维度就完全变了——它不再只是回答“这个智能体行不行”而是要回答“这个智能体在什么条件下会出问题、出了问题谁来兜底、怎么保证它持续不出问题”。这就是“评测即治理”的核心逻辑。评测不再是一个独立的测试环节而是贯穿智能体全生命周期的治理手段。你设计评测集的过程本质上是在定义智能体的行为边界你选择评测指标的过程本质上是在设定智能体的价值取向你执行评测的频次和方式本质上是在建立智能体的运维规范。我见过太多团队把评测当成“上线前的最后一道关卡”结果上线后各种边界case层出不穷最后不得不返工重做。真正有效的做法是把评测前置到需求阶段把评测嵌入到开发流程把评测固化为运营机制。这篇文章我就把这套“评测即治理”的完整思路拆开来讲从评测体系设计、核心指标拆解、实操落地步骤到常见坑点排查全部基于我实际项目中的经验能直接抄作业的那种。2. 评测体系设计从“单点测试”到“治理框架”2.1 为什么传统评测方法在智能体时代失效了传统软件测试的核心假设是输入确定输出可预期。你给一个函数传参数它返回什么结果是确定的所以你可以写断言、跑用例、算通过率。但智能体完全不是这个逻辑——同一个问题你问十遍它可能给你十个不同的回答而且每个回答都“看起来有道理”。我刚开始做智能体评测的时候踩过一个大坑用传统测试用例的方式去测一个客服智能体写了200条用例跑完发现通过率只有60%。当时第一反应是“这智能体不行”但仔细一看失败案例发现很多是“回答风格不符合预期”而不是“回答内容错误”。比如用户问“你们家产品多少钱”智能体回答“我们的产品价格根据配置不同有所差异建议您联系销售获取详细报价”——这个回答在业务上是完全正确的但测试用例里写的是“应该直接给出价格区间”所以被判为失败。这个坑让我意识到智能体的评测不能只看“对不对”还要看“好不好”、“稳不稳”、“该不该”。这三个维度分别对应功能正确性、体验质量和安全合规缺一不可。2.2 三层评测框架功能层、体验层、治理层基于上面的教训我总结了一套三层评测框架从下到上分别是功能层这是最基础的测的是智能体“能不能完成任务”。比如问答智能体能不能准确回答用户问题代码智能体能不能生成可运行的代码销售智能体能不能正确识别客户意图。这一层的评测方法相对成熟核心是构建高质量的评测集覆盖典型场景和边界场景。体验层这一层测的是智能体“完成任务的过程好不好”。包括响应速度、回答风格、多轮对话的连贯性、对模糊问题的澄清能力等。这一层最容易被忽视但恰恰是用户感知最强的部分。我见过一个智能体功能测试通过率95%但上线后用户满意度只有60%原因就是回答太生硬、不会追问、遇到不确定的问题就瞎编。治理层这是最高层测的是智能体“该不该这么做”。包括安全合规、价值观对齐、数据隐私保护、对抗攻击的鲁棒性等。这一层在2026年变得尤其重要因为智能体开始有了“行动能力”——它不只是回答问题还能调用API、操作数据库、发送邮件。一旦行为失控后果比“回答错误”严重得多。这三层不是孤立的而是层层递进的关系。功能层不过关体验层和治理层无从谈起但功能层过关了体验层和治理层不过关智能体照样不能上线。2.3 评测集构建从“拍脑袋”到“数据驱动”评测集的质量直接决定了评测结果的可信度。我见过太多团队在评测集上偷懒——随便找几个人写几十条用例跑完就完事。这种做法在早期探索阶段可以但到了生产环境必须用数据驱动的方式构建评测集。我的做法是从真实用户日志中挖掘评测用例。具体来说分三步走第一步收集线上真实对话数据按意图分类。比如客服智能体的对话可以分成“产品咨询”、“售后问题”、“投诉建议”、“闲聊”等类别。每个类别下统计高频问题和长尾问题。第二步对每个类别的问题标注“标准答案”和“可接受答案范围”。标准答案是理想情况下的最优回答可接受答案范围是允许智能体发挥的空间。比如“产品多少钱”这个问题标准答案可能是“我们的产品分为基础版199元/月、专业版499元/月、企业版定制报价”可接受答案范围包括“价格根据版本不同有所差异基础版199元起”这类回答。第三步定期更新评测集。智能体的能力在进化用户的问题也在变化评测集如果一成不变很快就会失效。我一般建议每两周更新一次评测集每次更新比例控制在10%-20%之间既能反映最新情况又能保持评测结果的连续性。注意评测集不是越大越好。我见过一个团队搞了上万条评测用例跑一次要几个小时结果没人愿意跑。评测集规模控制在200-500条比较合适关键是要覆盖全面、标注准确。3. 核心指标拆解每个数字背后的治理含义3.1 准确率不只是“答对了多少”准确率是最直观的指标但也是最容易被误读的指标。很多人把准确率简单理解为“答对的题数除以总题数”但在智能体场景下这个定义太粗糙了。我一般会把准确率拆成三个子指标严格准确率智能体的回答与标准答案完全一致的比例。这个指标最严格但实际意义有限因为智能体的回答往往有多种正确表达方式。宽松准确率智能体的回答在可接受答案范围内的比例。这个指标更实用能反映智能体在真实场景下的可用性。关键准确率在关键场景如涉及金额、安全、合规的问题下智能体回答正确的比例。这个指标最重要因为关键场景一旦出错后果可能很严重。举个例子一个金融智能体宽松准确率90%但关键准确率只有70%那这个智能体绝对不能上线。因为那30%的关键错误可能意味着错误的投资建议、错误的费率计算直接导致用户损失。3.2 召回率被忽视的“另一半”召回率在智能体评测中经常被忽视但它其实和准确率一样重要。准确率衡量的是“智能体给出的回答中有多少是正确的”召回率衡量的是“所有应该被回答的问题中智能体实际回答了多少”。我见过一个智能体准确率很高但召回率很低——它只回答那些它“确信”的问题遇到不确定的问题就转移话题或者直接说“我不知道”。这种策略在准确率上很好看但用户体验很差因为用户真正需要帮助的问题往往就是那些“不确定”的问题。召回率的评测方法相对复杂需要构建一个“问题全集”然后看智能体实际回答了多少。我的做法是从真实用户日志中抽取1000个问题人工标注哪些是“应该被回答的”然后看智能体实际回答了多少个。召回率低于80%的智能体我一般不建议上线。3.3 响应时间用户体验的“生死线”响应时间这个指标看起来很简单但实际评测中有很多坑。首先响应时间的定义要明确——是从用户发送消息到收到第一个字符还是到收到完整回答这两个指标差异很大。我一般建议用“首字响应时间”和“完整响应时间”两个指标。其次响应时间的阈值要根据场景设定。闲聊场景下用户对响应时间的容忍度较高3-5秒都能接受但客服场景下用户期望的是即时响应超过2秒就会明显感到不耐烦。最后响应时间的评测要分位数统计不能只看平均值。平均值1秒但P99是10秒那意味着1%的用户要等10秒这个体验是很差的。我一般关注P50、P90、P99三个分位数分别对应“典型体验”、“较差体验”和“最差体验”。3.4 安全合规指标治理层的“红线”安全合规指标是治理层的核心也是最难量化的部分。我一般从四个维度来评测内容安全智能体的回答是否包含违规内容。这个可以通过关键词过滤人工抽检的方式评测。行为安全智能体调用外部工具时是否超出授权范围。比如一个查询天气的智能体不应该有权限访问用户通讯录。数据隐私智能体在处理用户数据时是否遵守隐私保护规范。比如不应该在回答中泄露其他用户的个人信息。对抗鲁棒性智能体在面对恶意输入时是否能保持稳定。比如面对提示词注入攻击是否能拒绝执行恶意指令。这四个维度的评测我一般建议用“红队测试”的方式——组织专门的测试人员模拟恶意用户尝试各种攻击手段记录智能体的表现。4. 实操落地从评测方案到治理闭环4.1 评测流程设计四个阶段缺一不可一个完整的智能体评测流程应该包含四个阶段阶段一离线评测。在智能体上线前用构建好的评测集进行批量测试。这个阶段的目标是发现明显的问题比如功能缺失、回答错误、响应超时等。离线评测一般跑全量评测集输出详细的评测报告。阶段二灰度评测。智能体上线后先面向小比例用户开放收集真实反馈。这个阶段的目标是发现离线评测覆盖不到的问题比如真实用户的表达方式差异、多轮对话中的上下文丢失等。灰度评测一般持续1-2周根据反馈调整后再扩大范围。阶段三在线评测。智能体全量上线后持续监控核心指标。这个阶段的目标是发现指标异常比如准确率突然下降、响应时间突然变长等。在线评测一般用自动化监控人工抽检的方式。阶段四定期复评。每隔一段时间如一个月用最新的评测集对智能体进行全面复评。这个阶段的目标是发现智能体的能力退化比如因为模型更新导致的回答风格变化、因为数据漂移导致的准确率下降等。这四个阶段不是一次性的而是循环往复的。每次复评发现的问题都要反馈到下一轮的离线评测和灰度评测中形成闭环。4.2 评测工具选型自建还是采购评测工具的选择取决于团队的规模和需求。我一般建议分三种情况小团队1-3人直接用开源工具脚本。比如用Python写评测脚本用pandas做数据分析用matplotlib做可视化。这种方式成本低、灵活度高但需要一定的开发能力。中型团队5-10人用开源评测框架自建平台。比如用RAGAS做检索增强生成的评测用LangSmith做链路追踪然后自建一个简单的评测管理平台。这种方式兼顾了灵活性和效率。大型团队10人以上采购商业评测平台自建核心能力。商业平台提供标准化的评测流程和报告自建部分负责定制化的评测需求。这种方式成本高但能保证评测的专业性和一致性。我个人的经验是评测工具的核心不是功能多强大而是能不能融入现有的开发流程。如果评测工具需要开发人员手动触发、手动分析结果那再好的工具也会被弃用。最好的评测工具是能自动触发、自动分析、自动告警的工具。4.3 评测结果分析从“看数字”到“找原因”评测结果分析最忌讳的就是只看数字不看原因。准确率下降了5%为什么下降是哪些类型的问题下降了是模型更新导致的还是数据漂移导致的这些问题不搞清楚评测就白做了。我的分析方法是先看整体再看分组最后看个案。先看整体指标判断是否有异常。如果整体指标正常那就不需要深入分析。如果整体指标异常进入下一步。再看分组指标定位问题范围。比如按意图分类看准确率发现“售后问题”类别的准确率下降了20%那问题就定位到了这个类别。最后看个案找到具体原因。从“售后问题”类别中抽取失败案例人工分析失败原因。是模型不理解问题还是知识库缺失还是回答模板有问题找到原因后才能针对性修复。4.4 治理闭环评测结果如何驱动智能体迭代评测的最终目的是驱动智能体迭代。如果评测结果只是写个报告、开个会然后就没有然后了那评测就失去了意义。我一般建议建立这样的治理闭环评测发现问题 → 分类归因 → 制定修复方案 → 实施修复 → 回归评测 → 上线验证。这个闭环中最关键的是“分类归因”和“回归评测”。分类归因决定了修复方案的方向回归评测决定了修复是否有效。我见过太多团队跳过回归评测直接上线修复版本结果引入新的问题。提示回归评测的评测集应该包含两部分一部分是历史失败案例验证修复是否有效另一部分是历史成功案例验证修复是否引入新的问题。两部分都通过才能上线。5. 常见问题与排查技巧实录5.1 评测结果波动大怎么办评测结果波动大是智能体评测中最常见的问题。同一个智能体今天跑准确率90%明天跑可能只有85%。这种波动可能来自三个原因模型本身的随机性。智能体背后的模型通常是概率模型同样的输入可能产生不同的输出。这种波动是正常的但如果波动范围超过5%就需要关注。评测集的问题。评测集中的问题如果表述模糊、标注不一致会导致评测结果不稳定。我一般建议对评测集做一致性检查确保每个问题的标注是明确的、无歧义的。评测环境的问题。评测环境的网络延迟、API限流、并发数等因素都可能影响评测结果。我一般建议在固定的环境下评测每次评测前检查环境是否正常。排查方法先固定评测集和环境跑三次评测看结果波动范围。如果波动范围在3%以内属于正常如果超过5%需要检查评测集标注和环境配置。5.2 评测通过但上线出问题怎么排查这种情况我遇到过好几次最典型的一次是离线评测准确率95%上线后用户投诉不断。排查后发现离线评测用的是“标准问题”而上线后用户用的是“口语化问题”。比如离线评测问“如何修改密码”上线后用户问“密码忘了咋整”智能体就懵了。排查思路对比离线评测和线上真实对话的差异重点看三个方面——问题的表达方式、问题的长度、问题的上下文。如果差异较大说明评测集不够真实需要补充真实用户日志中的问题。5.3 多轮对话评测怎么做多轮对话评测是智能体评测中的难点。单轮对话评测你只需要看当前问题的回答多轮对话评测你还要看上下文是否连贯、指代是否清晰、状态是否保持。我的做法是构建“对话场景”而不是“单个问题”。比如一个订票场景包含“查询航班→选择航班→填写乘客信息→确认订单→支付”五个步骤每个步骤都有对应的用户输入和期望的智能体输出。评测时按顺序执行这五个步骤看智能体是否能正确完成整个流程。多轮对话评测的关键指标是“任务完成率”和“对话轮次”。任务完成率衡量智能体是否能完成整个任务对话轮次衡量智能体是否高效。一个智能体如果任务完成率100%但平均需要20轮对话才能完成那体验也是很差的。5.4 评测成本太高怎么优化评测成本主要包括三部分人力成本、计算成本、时间成本。优化评测成本我一般从三个方面入手自动化。能自动化的评测绝不人工。比如内容安全评测可以用关键词过滤模型分类的方式自动化响应时间评测可以用脚本自动化。抽样。不是所有评测都需要全量跑。日常监控可以抽样跑比如每天抽100条定期复评可以全量跑比如每月一次。分层。不同阶段的评测用不同的评测集。离线评测用全量评测集灰度评测用核心评测集在线评测用抽样评测集。5.5 常见问题速查表问题现象可能原因排查方法解决方案准确率突然下降模型更新、数据漂移、评测集变化对比历史评测结果定位变化点回滚模型、更新知识库、校准评测集响应时间变长并发增加、API限流、模型推理变慢监控系统指标定位瓶颈扩容、优化调用链路、模型量化多轮对话丢失上下文上下文窗口不足、状态管理bug复现对话流程检查上下文传递扩大上下文窗口、修复状态管理逻辑安全合规评测不通过提示词注入、越权调用、数据泄露红队测试模拟攻击加强输入过滤、权限控制、数据脱敏评测结果不可复现评测环境不一致、模型随机性固定环境多次评测统一评测环境、设置随机种子6. 评测即治理从项目实践到组织能力6.1 评测治理的组织保障评测即治理不只是技术问题更是组织问题。如果团队里没有人对评测负责评测就永远做不好。我一般建议设立三个角色评测负责人负责评测体系的整体设计包括评测集构建、指标定义、流程设计。这个角色需要既懂技术又懂业务能协调各方资源。评测执行人负责日常评测的执行包括跑评测、分析结果、写报告。这个角色需要细心、耐心能发现细节问题。评测审核人负责评测结果的审核包括确认评测方法是否合理、结果是否可信、修复方案是否有效。这个角色需要有一定的权威性能推动问题修复。这三个角色可以是兼职的但必须有明确的责任人。我见过太多团队评测工作“人人有责”但“人人不负责”最后评测流于形式。6.2 评测文化的建设评测文化是比评测工具和流程更底层的东西。一个团队如果有良好的评测文化即使工具简陋、流程简单评测也能做好反之如果团队不重视评测再好的工具和流程也是摆设。建设评测文化我一般从三个方面入手让评测可见。把评测结果放在团队看板上让每个人都能看到智能体的表现。好的结果要表扬差的结果要分析。让评测有趣。把评测变成一种“游戏”比如设立“找bug奖”鼓励大家发现智能体的问题。我见过一个团队每周评选“最佳找茬奖”大家的积极性很高。让评测有用。评测结果要真正驱动迭代而不是写完报告就结束。每次评测发现的问题都要有明确的修复计划和验证结果。6.3 从单点评测到持续治理最后我想强调的是评测不是一次性的项目而是持续的过程。智能体在上线后会面临不断变化的环境——用户需求在变、数据分布在变、竞争对手在变。如果评测停留在“上线前跑一次”的阶段智能体很快就会落后。持续治理的核心是建立“评测-反馈-迭代”的闭环。这个闭环的运转速度决定了智能体的进化速度。我见过一个团队每周跑一次评测每周迭代一次智能体三个月后智能体的准确率从70%提升到了90%。另一个团队一个月才跑一次评测智能体半年都没什么进步。评测即治理治理即进化。把评测做好智能体才能越用越聪明越用越可靠。这个系列到这里就收官了但智能体的评测和治理才刚刚开始。
