智能体评估新范式：TED框架如何实现用户感知的自动化诊断

1. 从“打分”到“对话”为什么我们需要用户感知的智能体评估在智能体Agent开发领域我们正面临一个日益凸显的评估困境。传统的评估方法无论是基于静态数据集的自动化测试还是依赖人工标注的众包打分都越来越难以跟上智能体复杂度的增长。一个能通过所有预设测试用例的智能体可能在真实用户面前表现得像个“书呆子”——它或许能准确回答“北京的天气如何”却无法理解用户说“明天出门穿什么”背后隐含的查询意图。更常见的情况是我们拿到一份评估报告上面写着“准确率85%”但我们却不知道那丢失的15%究竟错在哪里是知识盲区、逻辑混乱还是单纯没听懂用户的言外之意这正是“Talk, Evaluate, Diagnose: User-aware Agent Evaluation with Automated Error Analysis”简称TED框架试图解决的问题。它不是一个全新的打分算法而是一套评估范式的转变。其核心在于三个关键词的递进Talk对话、Evaluate评估、Diagnose诊断。它主张评估必须始于与用户或模拟用户的真实对话交互而非孤立的问答对评估过程需要是用户感知的即能理解用户意图、上下文和潜在需求最终评估的输出不应只是一个冷冰冰的分数而应是一份自动化的错误诊断报告明确指出智能体在哪些环节、因为什么原因失败。近年来随着大语言模型LLM能力的提升“LLM-as-a-judge”使用大语言模型作为评判官的模式变得流行。我们经常用另一个强大的LLM如GPT-4来给智能体的回答打分。这确实提升了评估的效率和可扩展性。但TED框架提醒我们如果这个“法官”本身对用户场景缺乏感知只是机械地对比“标准答案”那么评估仍然是片面的。真正的“用户感知”要求评估系统能模拟或理解用户的多样性、任务的模糊性以及对话的动态性。因此TED框架的价值在于它将评估从一个“质量检验”环节提升为一个“研发诊断”工具。它回答的不仅是“智能体好不好”更是“它为什么不好”以及“如何让它更好”。对于一线的AI工程师和产品经理来说这种从宏观分数到微观根因的洞察能力才是加速迭代、提升产品体验的关键。2. TED框架的三支柱对话、评估与诊断的闭环设计TED框架不是一个单点工具而是一个由三个核心环节紧密耦合形成的系统化流程。理解这个闭环是将其付诸实践的第一步。2.1 支柱一Talk - 构建贴近真实的对话流“对话”是评估的土壤。这里的“对话”不是指随意的闲聊而是指在特定场景和目标下智能体与用户或用户模拟器进行的一系列有意义的交互序列。构建高质量的评估对话流需要避免两个极端一是过于简单的单轮问答缺乏上下文挑战二是完全天马行空的开放对话难以评估和归因。一个实用的方法是场景化对话剧本生成。我们可以基于产品真实的使用日志抽象出高频、核心的用户任务。例如对于一个订餐智能体核心任务可能包括“查询餐厅”、“修改订单”、“处理投诉”。针对每个任务我们可以设计多个对话剧本每个剧本包含用户画像例如“忙碌的上班族”、“对价格敏感的学生”、“有特殊饮食要求的顾客”。对话起点用户的第一句话可能明确也可能模糊。潜在的用户目标用户可能没有直接说出来的深层需求。可能的对话路径包括用户的追问、信息的更正、意图的转变等。这些剧本可以通过领域专家编写也可以利用LLM基于少量种子示例进行批量生成。关键是要注入“用户感知”元素比如使用口语化表达、包含指代歧义“那家店”、“刚才说的那个”、或者情绪化表达“我都等了半小时了”。这为后续评估智能体的上下文理解、意图澄清和情绪应对能力奠定了基础。2.2 支柱二Evaluate - 实施多维度的用户感知评估在生成的对话流上运行智能体得到交互记录后就进入评估环节。传统的评估可能只问一个问题“最终答案正确吗”而用户感知评估则需要回答一系列更细致的问题任务完成度用户的核心目标是否被满足这是最终结果对话效率智能体用了多少轮对话才完成任务有没有不必要的确认或冗余信息交互自然度智能体的回应是否连贯、合乎逻辑是否主动进行了必要的澄清用户满意度模拟如果用户是“忙碌的上班族”智能体是否提供了最快捷的选项如果用户“情绪焦躁”智能体的回应是否起到了安抚作用“LLM-as-a-judge”在这里可以发挥巨大作用但提示词Prompt的设计至关重要。我们不能简单地问“请给这个回答打分”。一个有效的评估提示词应该包含完整的对话上下文。明确的用户画像和任务目标。结构化的评估维度即上述几点。每个维度的具体评分标准或判断规则。 例如“假设你是一位[用户画像]的顾客你的目标是[任务目标]。回顾以下与订餐助理的完整对话请分别评估1. 你的订餐需求最终是否被正确满足是/否并说明理由2. 助理的沟通是否高效有无让你感到重复或困惑高效/一般/低效3. 助理的回应是否礼貌且有助于解决问题是/否”通过这种方式LLM法官不再是机械的评分器而是一个“代入式”的评估者其评判标准更贴近真实用户的感受。2.3 支柱三Diagnose - 实现自动化的错误根因分析评估给出了分数而诊断要揭示分数背后的故事。这是TED框架最具价值的一环。自动化错误分析的目标是将一次失败的交互归类到一个具体的、可操作的错误类别中并尽可能定位到对话中的具体轮次或语句。一个常见的错误分类体系可能包括知识缺失智能体缺乏完成任务所需的事实性知识或领域知识。推理错误智能体拥有相关知识但在逻辑推理、计算或规划步骤上出错。指令遵循失败智能体未能正确理解或执行用户在当前轮次给出的明确指令。上下文理解失误智能体未能正确维护对话历史出现指代错误或遗忘关键信息。安全/合规问题智能体给出了有害、偏见或不符合规定的回应。交互策略不当例如在不该确认的时候过度确认该主动询问时却沉默。自动化诊断同样可以借助LLM。我们可以设计一个“诊断官”LLM输入失败的对话记录和任务描述要求其分析“导致本次任务失败的最主要原因是什么请从以上类别中选择并引用对话中的具体片段作为证据。”更进一步的可以要求诊断官生成一个简短的“诊断报告”甚至提出修复建议如“需要在知识库中补充关于XX餐厅节假日营业时间的信息”或“当用户表达不满时回复模板应首先包含道歉语句”。通过将评估Evaluate和诊断Diagnose分离我们实现了关注点的分离评估告诉我们“有没有病”诊断告诉我们“病在哪里、是什么病”。这为后续的针对性优化提供了清晰的路线图。3. 搭建你自己的TED评估系统从理论到实践理解了TED框架的理念后如何将其落地到一个具体的智能体项目上以下是一个可操作的步骤指南涵盖了工具选型、流程搭建和关键实现细节。3.1 第一步定义评估场景与收集对话数据一切始于对智能体核心使命的清晰定义。你需要回答我的智能体主要解决哪几类用户问题每类问题的典型对话模式是什么内部数据利用如果你有线上产品最宝贵的资源就是真实的用户对话日志需脱敏处理。从中抽取成功和失败的对话案例进行人工分析和标注形成最初的“种子数据集”。这些数据最能反映真实世界的复杂性和用户的真实表达习惯。模拟数据生成当真实数据不足或需要覆盖边缘场景时可以使用LLM进行对话模拟。具体操作上你可以使用如下的提示词结构来引导LLM生成高质量的评估对话# 示例提示词用于GPT-4等模型 prompt f 你是一位专业的对话场景设计师。请为“[智能体名称]”生成一段用于评估其能力的多轮对话。 - 智能体功能描述[详细描述智能体的能力和边界] - 用户场景[例如用户想预订一周后周末的餐厅但预算有限且同行者有素食者] - 用户画像[例如25-35岁年轻白领注重效率习惯使用手机] - 任务目标[用户需要成功预订到符合所有条件的餐厅并收到确认信息] - 请生成一段6-10轮的对话要求 1. 对话开头由用户发起且意图可以相对模糊。 2. 对话中应包含至少一次用户意图的转变或信息的更正。 3. 对话中应包含至少一处需要智能体进行澄清的模糊点。 4. 最终智能体应能成功完成任务。 请直接输出对话内容格式为 用户: [说话内容] 助理: [说话内容] ... 通过批量运行此类提示词并加入不同的场景和用户画像变量你可以快速构建一个丰富多样的评估对话库。3.2 第二步构建评估与诊断流水线有了对话数据下一步是建立一个自动化的流水线依次执行“运行智能体 - 评估 - 诊断”。对话执行器这是一个封装模块负责加载你的智能体将预设的对话剧本用户说的话逐一喂给智能体并记录智能体的每一轮回应形成完整的对话记录。这里的关键是确保测试环境与生产环境尽可能一致包括智能体的版本、依赖的知识库、调用的外部API等。LLM评估官选择一款性能稳定的LLM作为法官如GPT-4、Claude 3或开源的Qwen2.5-72B-Instruct。为其设计结构化的评估提示词模板。为了提高评估的一致性和可重复性可以考虑采用思维链Chain-of-Thought提示技术要求LLM先逐步推理再给出评分和理由。将评估结果各维度分数、总体结论、简短评语结构化地保存下来例如存入JSON文件或数据库。注意LLM评估存在成本和不稳定性。一个实用的技巧是对于关键测试用例可以采用“多法官投票”机制即用相同的提示词让同一个模型多次生成评估或使用多个不同模型评估取多数意见作为最终结果以提高信度。LLM诊断官对于被评估为“失败”或“部分失败”的对话将其送入诊断环节。诊断官的提示词需要包含详细的错误分类定义并要求其进行归类。一个进阶的做法是实施分层诊断先让一个诊断官判断大类如“知识缺失”再根据大类调用更专业的诊断子模块进行深挖如对于“知识缺失”再调用一个模块具体分析缺失的是“实体知识”、“属性知识”还是“关系知识”。3.3 第三步结果可视化与洞察挖掘原始的评价和诊断数据是散乱的珍珠需要用仪表盘将其串成项链。一个基本的TED评估仪表盘应包含总体概览展示本次评估的对话总数、任务完成率、平均对话轮数、各维度平均分等核心指标。错误光谱图一个柱状图或饼图清晰展示所有失败案例中各类错误知识缺失、推理错误等的分布情况。一眼就能看出当前智能体的“最大短板”是什么。典型案例库点击某个错误类型可以下钻查看被归为此类的所有具体对话记录。这是最有价值的部分允许研发人员直接阅读失败的交互过程结合诊断报告形成直观感受。趋势对比如果你定期如每周运行TED评估可以将核心指标的历史趋势绘制成折线图清晰展示智能体在历次迭代后的进步或退步情况。这些可视化图表不仅服务于工程师更是产品经理、项目经理乃至管理层理解项目进展、确定优化优先级的重要依据。它让评估从一份藏在技术团队电脑里的报告变成了一个团队共享的、数据驱动的决策看板。4. 超越基准测试TED框架在模型迭代与产品优化中的实战应用TED框架的价值不仅在单次评估更在于融入持续的开发迭代循环成为驱动智能体进化的“导航仪”。4.1 应用一精准定位瓶颈指导模型微调与提示工程假设你的智能体在TED评估中“推理错误”类别的失败率异常高。你点开几个案例发现智能体经常在需要多步骤计算或条件筛选的任务上出错。这个洞察直接指明了优化方向。如果问题是出在基础能力上例如智能体总是算错折扣价格。这可能意味着底层LLM的数学推理能力不足。解决方案可以是1在提示词中明确要求“逐步计算”2为智能体配备一个计算器工具Tool3或者如果问题普遍且严重考虑收集一批类似的“推理错误”案例对模型进行针对性的指令微调Instruction Tuning强化其多步推理能力。如果问题是出在任务规划上例如在订餐场景中智能体总是忘记先确认人数再推荐餐厅。这更可能是一个流程逻辑问题。你可以优化智能体的系统提示词System Prompt在其中明确加入任务规划步骤例如“当用户提出订餐需求时你必须按顺序确认以下信息1.用餐人数2.预算范围3.饮食禁忌4.偏好口味...”。 TED的诊断报告为你提供了具体的、带有上下文的坏例子Bad Cases这些是优化提示词或构造微调数据时最宝贵的素材远比凭空想象要有效得多。4.2 应用二驱动知识库与工具集的动态增强“知识缺失”是另一个常见错误类型。TED诊断不仅能告诉你“缺知识”还能通过分析对话上下文大致推断出“缺什么知识”。知识库补全当诊断报告频繁指出智能体无法回答关于“某家餐厅是否提供儿童座椅”或“某个产品的保修政策”时这就是一个明确的知识库更新信号。你可以建立一条从TED诊断系统到知识库管理后台的反馈链路定期将“高频缺失知识条目”自动生成工单提醒运营人员补充。工具调用优化有时智能体并非不知道知识而是不知道或不会调用获取该知识的工具。例如用户问“明天从上海飞北京的航班最便宜的是哪趟”智能体可能回答“我无法查询实时航班信息”而正确的做法是调用“航班查询API”。如果TED诊断将此类错误归类为“工具使用不当”那么你就需要1检查工具的描述Tool Description是否清晰易懂2优化智能体进行工具调用的决策逻辑例如通过Few-shot示例在提示词中示范3甚至考虑增加新的工具来覆盖能力缺口。4.3 应用三量化用户体验支撑产品决策与A/B测试TED评估中“交互自然度”和“对话效率”等维度是衡量用户体验UX的早期代理指标。在产品功能设计阶段你可以利用TED框架进行“概念验证”。例如你们在讨论一个新的功能当用户查询订单时智能体是否应该主动询问“是否需要为您推荐类似商品”。传统的做法可能是团队内部争论或者上线后看数据。而利用TED你可以快速生成两套对话剧本一套包含主动推荐一套不包含。然后用TED系统评估这两个版本的智能体在“任务完成度”用户是否觉得被打扰和“交互自然度”上的表现。这种小规模的、受控的模拟测试能以极低的成本为产品决策提供数据参考。同样在对智能体进行较大规模更新如更换底层LLM、重构系统提示词后你可以将新版本A版和旧版本B版在同一个TED评估对话库上跑一遍对比两者的各项指标。这种A/B测试能系统性地告诉你新版本是全面领先还是在某些特定场景下存在退化从而避免将带有隐性缺陷的版本推送给全部用户。5. 实践中的挑战与应对策略让TED评估更可靠、更高效任何框架在落地时都会遇到挑战TED也不例外。以下是几个常见的坑以及我的应对经验。5.1 挑战一LLM评估官的“主观性”与不稳定问题LLM作为法官其评估结果可能存在波动同一问题多次询问得分不同并且其评判标准可能带有模型自身的“偏见”。例如一个偏好简洁风格的法官可能会给一个虽然准确但略显啰嗦的回答打低分。策略标准化与校准制定详细的评分规则不要只问“请打分”。为每个评估维度制定尽可能客观、可操作的规则。例如对于“任务完成度”规则可以是“仅当智能体在对话中提供了[具体信息A]和[具体信息B]并且用户最终表达了满意或无需进一步帮助时才可判为‘完全成功’。”使用少量样本进行校准随机选取50-100个对话由人类专家进行标注。然后用这些“黄金标准”数据去测试你的LLM法官提示词计算其与人类判断的一致性如Kappa系数。根据不一致的案例反复迭代优化你的评估提示词直到LLM法官的判断与人类专家高度对齐。引入集成评估对于关键或存疑的案例可以采用多个LLM模型或同一模型不同温度参数下的多次生成进行评估取众数或平均分作为最终结果这能在一定程度上平滑单次评估的随机性。5.2 挑战二自动化诊断的准确性与颗粒度平衡让LLM自动诊断错误根因有时会像让医生自己写病历——可能抓不到重点或表述模糊。诊断结果可能出现“套话”如总是归为“理解错误”或者给出的修复建议过于空泛如“需要改进模型能力”。策略分层诊断与证据绑定设计层级化的诊断分类体系不要一开始就用几十个细分类别。可以先设一级大类如知识、推理、交互、安全再在每个大类下设二级子类。诊断时先进行一级分类再对分入某大类的案例进行二级细分。这降低了单次诊断的复杂度。强制要求提供证据在诊断提示词中严格要求模型必须引用对话中的具体文本作为诊断依据。例如“请指出导致问题的具体对话轮次。例如在第3轮用户说‘A’但助理理解为‘B’这属于上下文理解失误。”这迫使诊断官进行更细致的分析也方便人类复核。人机协同复核完全自动化的诊断在初期很难做到100%准确。可以建立一个流程让系统自动筛选出“高置信度”的诊断结果例如多个诊断步骤结论一致而对于低置信度或涉及重大问题的案例则自动打上标签交由人工进行最终审核和确认。人工审核的结果又可以反馈回去用于优化诊断提示词。5.3 挑战三评估成本与迭代速度的权衡运行大规模的对话模拟、调用高性能LLM进行评估和诊断尤其是在使用GPT-4等商用API时会产生显著的成本。同时如果一次完整的TED评估需要数小时甚至数天就无法支持快速的日常迭代。策略建立分层评估体系与缓存机制核心场景每日评估识别出智能体最核心、最高频的10-20个对话场景构建一个“核心回归测试集”。这个集合规模较小如200个对话但覆盖了基本功能。每天或每次代码提交后都自动运行这个核心集的评估确保基本盘稳定。成本可控速度也快。全场景每周/每版本评估每周或每个主要版本发布前运行一次覆盖所有场景的完整TED评估可能包含数千个对话。这次评估的目的是发现边缘案例、监测长期趋势。利用开源模型与缓存对于评估环节可以探索使用性能较好的开源模型如Qwen、Llama等作为法官以降低API成本。同时对于不变的对话剧本和智能体版本其评估结果是确定的可以建立缓存数据库。只有当对话剧本或智能体代码发生变更时才重新触发对该剧本的评估避免重复计算。从我个人的项目经验来看TED框架最大的价值在于它提供了一种“数据驱动的调试”思维。过去我们优化智能体很大程度上依赖直觉和零散的用户反馈。而现在我们可以像软件工程师查看程序崩溃的日志堆栈一样查看智能体“对话崩溃”的完整过程和诊断报告。这种从黑盒到灰盒的转变极大地提升了研发的确定性和效率。开始实施时可能会觉得流程繁琐但一旦跑通并融入CI/CD持续集成/持续部署流水线它就会成为团队不可或缺的质量守护和效率引擎。