1. 为什么“技能检索”成了 LLM 智能体落地绕不开的老大难这两年做大模型应用有个特别直观的变化大家不再满足于让模型“会聊天”而是想让模型“会干活”。所谓干活就是让 LLM 在收到用户需求之后自己决定调用哪个工具、访问哪个知识库、执行哪条工作流。这个链路里面模型本身当然重要但真正决定体验上限的往往是夹在中间的那个环节——技能检索。技能检索要做的事情说穿了就是从一堆工具描述、API 文档、业务流程模板里找到当前用户请求最需要的那一个。听起来跟传统 RAG 差不多但实际跑起来完全是另一回事。传统 RAG 检索的是知识片段内容相对独立答案对不对可以直接比照原文。技能检索呢它检索出来的是一个可执行的“动作入口”这个东西一旦选错就算大模型再聪明也只能拿着一个错误的工具做错误的推理最后给用户一个“看起来很有逻辑、实际上完全没用”的结果。我自己在做智能体项目的时候最开始用的方案特别朴素。把所有工具的描述存进向量库用户一来Embedding 算一下相似度Top-K 丢给大模型。结果上线之后发现用户问“帮我查一下昨天订单”的时候模型有时候会去调天气接口有时候会去调客户信息接口看起来每个接口都沾点边但就是不对。后来排查半天发现根子不在模型推理而在技能召回阶段就已经偏了。这个问题在行业里其实已经成了一个共识性的痛点。国内外的智能体平台从 Dify、Coze 到各类企业级 Agent 框架几乎都在花大力气优化工具调用和技能路由。但是有一个环节一直被忽视大家嘴上都说“我们的技能检索效果好”可到底怎么衡量靠人工看几个案例靠模型自己给自己打分还是靠用户点赞率这些方式要么样本太小要么太主观要么信号太滞后都撑不起一个严谨的评估结论。我关注到一篇论文提出的 RAE 方法就是专门来补这个缺口的。它把“评估技能检索的真实效果”这件事本身变成一个可执行的、自动化的流程目标不是看检索结果长得像不像而是看这个检索结果放到真实任务环境里能不能真的帮用户把事办成。这篇文章我想把 RAE 的来龙去脉、设计逻辑、实操步骤和踩坑经验一次性讲透给正在做智能体技能库、工具调用路由、以及 Agent 质量评估的同学一个可以直接参考的路线。1.1 智能体不是模型而是一套路由系统很多人误解智能体以为 Agent 就是“一个更强的模型”。但实际做工程的人会告诉你智能体的本质是一套路由系统。模型只是大脑而技能库、检索器、工具执行器、记忆模块这些外围设施才是让大脑真正“动手”的手脚。技能检索在这个路由系统里处在最前端。它决定了后续所有行为的上限。检索阶段如果出了错后面模型推理再厉害也只是在错误的地基上盖楼。所以评估智能体的整体表现第一步必须先盯住技能检索这个环节。这也是 RAE 方法最有价值的地方——它把评估的颗粒度沉降到了“技能能否被正确找到并执行”这个底层动作上。1.2 传统 RAG 的评估经验不能直接搬到技能检索上很多团队最初做智能体功能评估时都是把传统 RAG 的评测套路拿过来用准备一批问答对算召回率、准确率、命中率。但技能检索和文档检索有一个本质区别文档检索的目标是“找到包含答案的文本”而技能检索的目标是“找到能够完成任务的工具”。两者看上去都叫检索可是评价标准完全不同。文档检索里检索结果和标准答案有字面重合就能算对技能检索里检索结果和真实需求是否匹配只有把工具真正执行一遍才知道。举个特别典型的例子用户说“把这份文件转成 PDF”技能库里有一个“文档格式转换”工具描述里写的是“支持 docx、xlsx、ppt 转 pdf”按向量相似度它是命中的但执行时发现该工具只支持 10MB 以内的文件而这个文件是 50MB。文档检索视角下这已经算满分命中但真实效果呢任务没完成。RAE 做评估时这类情况会被明确地计为失败。这也是我觉得 RAE 方法最值得学习的地方它把评估的终点从“检索器找得准不准”拉长到了“任务完没完成”。把评估范围放大的同时反而让评估结果更真实了。2. RAE 方法到底做了什么把“检索效果”放进真实的任务环境里称重RAE 的全称是 Retrieval-Augmented Evaluation也就是“检索增强的评估方法”。名字听起来有点绕但思路其实很直白你不用一堆静态的、文档式的指标去衡量检索好坏而是搭建一个和真实使用场景一致的测试环境让技能检索的结果真正流向大模型和执行器最终看端到端的任务完成情况。它评估的是“整个技能调用链路的效果”而不仅仅是“检索器这一步的效果”。为什么要这么做因为企业做智能体最终追求的一定是“用户的任务能不能被可靠地完成”而不是“检索器在离线集合上的 F1 分数有多高”。离线指标和端到端效果之间的相关性在实际项目中低得惊人。我见过太多检索器在离线评测上漂漂亮亮一上真实流量就露馅的例子。RAE 的思路就是为了堵住这个漏洞。RAE 的整体流程可以拆成四个部分构造技能库、生成任务查询、执行技能调用、判定任务结果。每一个环节都有讲究下面我把我实际理解和复现时的一些想法说一下。2.1 RAE 的四段式评估链路第一段技能库构造。这一步需要一套与目标系统一致的技能清单。每个技能不仅要有名称、描述、参数、接口地址还要有对应的模拟执行环境。没有模拟环境任务就没法真正跑起来。第二段任务查询构造。RAE 构建了一批贴近真实用户表达的查询请求可以是人工编写的也可以由 LLM 辅助扩充。重点是这些查询要和技能库中的技能形成多对多的映射关系既有一对一的简单场景也有一对多、多对一的复杂场景。第三段技能调用执行。检索器根据查询返回技能列表然后送给大模型做进一步选择和调用最终调用动作会在模拟环境里真实执行。这一步是 RAE 和普通离线评测拉开差距的关键检索结果不是停在候选列表而是被真实地消耗掉。第四段任务完成判定。调用完成之后RAE 会基于“预期结果模板”或“自动判定器”检查执行结果是否满足用户意图。满足算成功不满足哪怕是技能本身很好也算失败。这套链路说出来没什么玄乎的但它把评估视角真正统一到了一个核心问题上用户的需求到底被满足了没有。2.2 为什么端到端判定比传统的“检索命中”更公平传统技能检索评估看的是检索结果里包不包含目标技能。听起来很合理但实际操作中有个致命的问题——标注人员很难保证自己的标注是完整且唯一的。举个例子用户需求是“提醒我明天早上九点开会”。技能库里有一个“日程提醒”技能还有一个“语音播报”技能还有一个“定时任务”技能。从人工标注的视角看也许只有“日程提醒”是正确结果。但从系统实现的角度看“定时任务”配合“语音播报”同样能完成用户需求。这种情况下离线标注就会产生偏差。而 RAE 绕开了这个标注问题它不看“你召回了哪个技能”它只看“用户的任务最终成没成”。只要最终闹钟响了、提醒弹出来了就算成功。这在设计上是非常聪明的取舍。2.3 RAE 的核心指标设计不是所有“成功”都等价RAE 里对任务完成度的判定也不是简单的是/否二分而是分成了好几个层次这部分我觉得特别有工程参考价值。完全成功用户意图的所有关键要素都实现结果可直接交付。部分成功核心动作完成但有次要信息遗漏或格式不对。功能成功但体验失败工具调用成功、接口返回正常但结果不符合用户的隐性预期。完全失败检索错误、工具报错、或执行结果和用户需求完全无关。这个分层的价值在于它能帮团队定位问题到底出在哪个环节。如果系统中“完全失败”占比高多半是检索器召回质量不行如果“功能成功但体验失败”占比高那问题可能出在提示词或模型推理上而不是检索。这个分层做出来之后团队开会时就不会再笼统地说“智能体效果不好”而是能精确地说“检索环节的误召回导致 30% 的请求走到了错误的工具上”。3. 从论文到落地RAE 评估流程的可复现实操理论说得再漂亮落不了地也是白搭。我根据论文思路结合自己在项目里跑智能体技能评估的经验整理了一套可以直接照着做的实操流程。这套流程不需要太多基础设施只要能跑通大模型 API、有一个向量数据库、有一份技能清单就可以开始。3.1 第一步构造一份“有陷阱”的技能库很多人做评估时有个习惯就是技能库越干净越好。但我建议反着来评估用的技能库一定要“有陷阱”。这里的陷阱包括描述相似的技能、功能重叠的技能、名称和功能容易混淆的技能。只有把这些真实世界中存在的“脏”情况放进去评估才有意义。我在构造技能库时一般会准备三批技能第一批是核心技能跟测试任务直接相关数量和描述都合理这批技能是保证系统能跑通的基础。第二批是干扰技能和核心技能在描述上有一定重合例如“发送邮件”和“发送消息”让检索器不能靠表面相似度取胜。第三批是边界技能比如权限受限的、仅限内部使用的、需要额外参数的。用来测试智能体在技能可用性判断上的能力。每份技能描述我一般控制在 50 到 150 字之间包含功能概述、适用场景、输入输出关键参数、使用限制。特别要注意的是技能描述里的措辞要尽量做到“功能和场景分离”。什么意思比如“发送定时消息”这个技能描述里需要明确说“适用于需要延后发送的场景”而不是笼统地只说“消息发送”。否则检索器很容易把所有和消息相关的 query 都召回这个技能。3.2 第二步准备任务查询集重点覆盖“易混淆场景”任务查询集是评估的输入。理论上应该直接从真实用户日志里抽样但在没有日志积累的早期阶段可以靠人工LLM 辅助生成。查询集会分成几个类别简单直给型用户需求和技能描述高度匹配例如“发一封邮件给张三”。复合任务型用户需求需要多个技能协作完成例如“把昨天销售数据汇总后发给李四”。易混淆型用户表述含糊需要结合上下文或常识才能判断正确技能例如“帮我把上次讨论的内容发到群里”如果团队里没有“会议纪要发送”技能就只有“消息发送”技能那么应该记作失败还是成功这类边界情况建议在评估设计阶段就定好规则。无对应技能型用户需求当前技能库无法满足例如技能库里没有“预订机票”技能用户却提出了预订需求。理想的系统应该明确表示“无可用技能”而不是强行调用一个不相关的工具。任务查询集的规模不一定要很大但覆盖面要足够宽。我的经验是每个技能至少覆盖 5 个查询每个易混淆场景至少覆盖 3 个变体这样跑一轮下来既有统计意义又能定位问题。3.3 第三步实现评估闭环中最关键的“执行与判定”环节这是 RAE 和普通评测差异最大的地方。技能调用不能只停留在“检索到了”这一层要让检索结果真正走到执行层。如果你是在做业务系统可以裁剪成策略模式读接口返回数据达成一个可控的验证环境。如果没有真实接入条件就需要做一个执行模拟器。执行模拟器的核心逻辑是一个函数接收技能 ID 和参数判断参数是否满足技能的前置条件然后返回一个带状态的执行结果。例如def execute_skill(skill_id, params): skill skill_registry[skill_id] # 前置条件检查 for condition in skill.preconditions: if condition not in params: return {status: failed, reason: fmissing param: {condition}} # 模拟执行 if skill.require_network and not network_mock_up: return {status: failed, reason: network error} # 按技能真实业务规则模拟核心动作 return {status: success, result: skill.mock_output(params)}模拟器不需要覆盖每个技能的内部业务细节但它至少要能区分出“参数缺失”“权限不足”“条件不满足”“执行成功”这几种状态。这些状态会直接影响最终的判定逻辑。判定器方面我建议用“规则模板 LLM 二次判断”的双通道设计。规则模板先做硬性检查比如参数是否完整、返回值是否包含必需字段LLM 再做软性判断比如“用户说要发给团队所有人实际只发给了 leader这算不算成功”。两边结果不一致的时候记录为人工复核样本。3.4 第四步跑完一轮评估之后看什么指标RAE 跑完一轮之后会输出几个关键指标。我建议重点关注下面这几个它们分别对应了技能检索链路的不同环节。指标计算方式暴露的问题检索召回率任务成功的查询中目标技能出现在 Top-K 的比例检索器是否把正确技能排在了足够靠前的位置端到端任务成功率判定为“完全成功”的查询任务数 ÷ 总任务数智能体整体完成需求的能力误召回率被检索召回到且被模型执行后导致最终失败的次数 ÷ 总执行次数检索结果里有害的“类技能”干扰无可执行技能识别率无对应技能任务中系统正确回绝或转人工的比例系统是否过度自信强行调用错误技能这些指标单独看意义有限组合在一起就能讲出完整的故事。比如某轮评估端到端成功率只有 40%再看检索召回率有 90%说明问题大概率不在检索而在模型选择或参数填充。如果检索召回率本身只有 60%那就要回到技能描述和 Embedding 层面去优化。4. 我在实际运行 RAE 时踩过的坑给你提前排掉思路说完说点更实际的。我在复现这套评估流程的时候踩过不少坑有些是设计上的有些是执行细节上的。挑几个典型的说能帮你省好几个星期的时间。4.1 技能描述与实际行为不一致导致评估结果虚高最典型的坑技能描述里写着“支持批量发送邮件”但实际接口实现时一次只能发一封。检索器一看 query 里有“批量发送”字样匹配得很准执行器在模拟环境里也跑得通因为模拟环境没实现批量逻辑一次传一个参数也返回 success。最后评估结果虚高一到真环境就崩。这个问题的解法是技能库里的描述必须和真实行为严格对齐评估前最好做一次一致性审查。你可以把每个技能描述给到开发同学让他们逐条确认描述里的能力项是否真实存在。这一步虽然耗时但是评估结果可信度的基础。4.2 判定器会被“包装过的失败”带偏还有一个我也没想到的坑LLM 判定器经常会给出有偏差的判断。现象是执行器返回了一个错误码但错误信息被包装成“请稍后重试”LLM 判定器看到“请稍后”就认为任务成功。或者执行器返回了一段使用说明LLM 判定器以为这是真的结果数据。后来我的办法是在判定提示词里明确约束凡是执行结果中包含 error、exception、failed、denied 等关键词一律进入人工复核通道不再让 LLM 自行判断。如果调用结果是一个使用说明而不是业务数据也要视为未成功。这个经验不大但是很管用。4.3 查询集合里的数据污染会让你误判检索能力这里的污染不是指脏数据而是“无意中泄露了答案”。我在生成任务查询集时有一轮直接用 LLM 辅助扩充查询结果 LLM 自动把技能名称也写进了查询里。比如原查询是“帮我把周报发给老板”扩充出来的变成“用周报发送功能帮我把周报发给老板”。检索器在这种查询上当然百发百中但真实用户根本不会这么说。解决这个问题有两种方式。第一种是建立“查询不得包含技能名称或技能描述关键词”的约束生成后再人工抽检。第二种是拿真实线上日志做替换。我现在更推荐后者哪怕样本少一些、乱一些也远比看似整齐的模拟数据可靠。4.4 干扰技能不是越多越好有一个时期的评估集我把干扰技能堆到了三十几个结果所有技能的召回率一起下降。研究后发现过去的数量增加了检索器的不确定性同时也让大模型在选择工具时出现更多犹豫和误判。这个现象提醒了一个道理评估集要和实际环境一致。如果你真实线上环境里就十几个技能评估集放十几个就足够了。非要增加干扰技能会增加系统性问题也会增加很多与真实环境无关的问题。4.5 参数填充错误的场景必须单独统计还有一个容易被忽略的维度是参数填充。检索器找对了技能模型也选对了工具但在生成参数时把字段传错了。比如“查昨天订单”传成了“查今天订单”“发给张总”传成了“发给张工”。这类问题在端到端成功率里会体现为失败但如果只看检索指标完全看不出来。所以我现在会把“检索成功、执行失败——参数错误”单独拉出来做一个类别方便定位是模型参数生成能力的问题还是接口设计复杂度过高的问题。部分接口参数之间关系太反直觉完全靠模型推理确实容易错这时需要在技能描述里补充参数示例。参数示例给得好不好直接决定模型生成的准确率。5. 后续扩展把 RAE 的评估思路变成线上监控的一种变形RAE 一开始是针对离线评估场景设计的方法但是我在实际使用中发现把它的核心逻辑变形之后完全可以做成一个轻量级的线上巡检工具。具体做法是每天从线上日志里抽一小部分真实用户请求放到 RAE 环境里重新跑一遍评估流程。这里不需要真实执行业务操作只需要用模拟器复现执行链路然后对比线上系统的返回结果和模拟环境的执行结果。如果两者不一致说明线上技能库或者检索配置可能发生了漂移。这个方法特别适合技能库更新频繁的团队。技能描述改了几个字、向量索引重建了一次、 Embedding 模型升级了版本这些改动在形态上都很小但造成的效果波动却很大。通过 RAE 的每日巡检能在用户大规模感知之前提前发现异常。我自己的体会是做技能检索评估这件事最忌讳的就是闭门造车。你用再多的离线指标都不如让一个真实的用户请求走到真实的执行链路里看看任务到底有没有完成。RAE 的方法本质上就是在帮团队建立这样一个“效果校验器”。它不能替代产品直觉也不能替代用户体验反馈但它能给团队提供一个稳定、可复现、可持续迭代的质量基线。先把基线立住再谈优化和升级这是我在多次迭代之后最信奉的一句话。对这种评估方法有兴趣的团队我建议先不要急着搭建复杂的平台拿一个最小可用的脚本把三五个技能、几十条查询先跑通评估闭环看看输出的报告能不能帮团队定位实际问题。跑通之后再根据实际需要逐步扩展技能库、查询集和自动化能力。踩过一次坑之后再回来读论文里那些设计细节你会有完全不一样的理解。
LLM智能体技能检索效果评估：RAE方法从原理到实战
1. 为什么“技能检索”成了 LLM 智能体落地绕不开的老大难这两年做大模型应用有个特别直观的变化大家不再满足于让模型“会聊天”而是想让模型“会干活”。所谓干活就是让 LLM 在收到用户需求之后自己决定调用哪个工具、访问哪个知识库、执行哪条工作流。这个链路里面模型本身当然重要但真正决定体验上限的往往是夹在中间的那个环节——技能检索。技能检索要做的事情说穿了就是从一堆工具描述、API 文档、业务流程模板里找到当前用户请求最需要的那一个。听起来跟传统 RAG 差不多但实际跑起来完全是另一回事。传统 RAG 检索的是知识片段内容相对独立答案对不对可以直接比照原文。技能检索呢它检索出来的是一个可执行的“动作入口”这个东西一旦选错就算大模型再聪明也只能拿着一个错误的工具做错误的推理最后给用户一个“看起来很有逻辑、实际上完全没用”的结果。我自己在做智能体项目的时候最开始用的方案特别朴素。把所有工具的描述存进向量库用户一来Embedding 算一下相似度Top-K 丢给大模型。结果上线之后发现用户问“帮我查一下昨天订单”的时候模型有时候会去调天气接口有时候会去调客户信息接口看起来每个接口都沾点边但就是不对。后来排查半天发现根子不在模型推理而在技能召回阶段就已经偏了。这个问题在行业里其实已经成了一个共识性的痛点。国内外的智能体平台从 Dify、Coze 到各类企业级 Agent 框架几乎都在花大力气优化工具调用和技能路由。但是有一个环节一直被忽视大家嘴上都说“我们的技能检索效果好”可到底怎么衡量靠人工看几个案例靠模型自己给自己打分还是靠用户点赞率这些方式要么样本太小要么太主观要么信号太滞后都撑不起一个严谨的评估结论。我关注到一篇论文提出的 RAE 方法就是专门来补这个缺口的。它把“评估技能检索的真实效果”这件事本身变成一个可执行的、自动化的流程目标不是看检索结果长得像不像而是看这个检索结果放到真实任务环境里能不能真的帮用户把事办成。这篇文章我想把 RAE 的来龙去脉、设计逻辑、实操步骤和踩坑经验一次性讲透给正在做智能体技能库、工具调用路由、以及 Agent 质量评估的同学一个可以直接参考的路线。1.1 智能体不是模型而是一套路由系统很多人误解智能体以为 Agent 就是“一个更强的模型”。但实际做工程的人会告诉你智能体的本质是一套路由系统。模型只是大脑而技能库、检索器、工具执行器、记忆模块这些外围设施才是让大脑真正“动手”的手脚。技能检索在这个路由系统里处在最前端。它决定了后续所有行为的上限。检索阶段如果出了错后面模型推理再厉害也只是在错误的地基上盖楼。所以评估智能体的整体表现第一步必须先盯住技能检索这个环节。这也是 RAE 方法最有价值的地方——它把评估的颗粒度沉降到了“技能能否被正确找到并执行”这个底层动作上。1.2 传统 RAG 的评估经验不能直接搬到技能检索上很多团队最初做智能体功能评估时都是把传统 RAG 的评测套路拿过来用准备一批问答对算召回率、准确率、命中率。但技能检索和文档检索有一个本质区别文档检索的目标是“找到包含答案的文本”而技能检索的目标是“找到能够完成任务的工具”。两者看上去都叫检索可是评价标准完全不同。文档检索里检索结果和标准答案有字面重合就能算对技能检索里检索结果和真实需求是否匹配只有把工具真正执行一遍才知道。举个特别典型的例子用户说“把这份文件转成 PDF”技能库里有一个“文档格式转换”工具描述里写的是“支持 docx、xlsx、ppt 转 pdf”按向量相似度它是命中的但执行时发现该工具只支持 10MB 以内的文件而这个文件是 50MB。文档检索视角下这已经算满分命中但真实效果呢任务没完成。RAE 做评估时这类情况会被明确地计为失败。这也是我觉得 RAE 方法最值得学习的地方它把评估的终点从“检索器找得准不准”拉长到了“任务完没完成”。把评估范围放大的同时反而让评估结果更真实了。2. RAE 方法到底做了什么把“检索效果”放进真实的任务环境里称重RAE 的全称是 Retrieval-Augmented Evaluation也就是“检索增强的评估方法”。名字听起来有点绕但思路其实很直白你不用一堆静态的、文档式的指标去衡量检索好坏而是搭建一个和真实使用场景一致的测试环境让技能检索的结果真正流向大模型和执行器最终看端到端的任务完成情况。它评估的是“整个技能调用链路的效果”而不仅仅是“检索器这一步的效果”。为什么要这么做因为企业做智能体最终追求的一定是“用户的任务能不能被可靠地完成”而不是“检索器在离线集合上的 F1 分数有多高”。离线指标和端到端效果之间的相关性在实际项目中低得惊人。我见过太多检索器在离线评测上漂漂亮亮一上真实流量就露馅的例子。RAE 的思路就是为了堵住这个漏洞。RAE 的整体流程可以拆成四个部分构造技能库、生成任务查询、执行技能调用、判定任务结果。每一个环节都有讲究下面我把我实际理解和复现时的一些想法说一下。2.1 RAE 的四段式评估链路第一段技能库构造。这一步需要一套与目标系统一致的技能清单。每个技能不仅要有名称、描述、参数、接口地址还要有对应的模拟执行环境。没有模拟环境任务就没法真正跑起来。第二段任务查询构造。RAE 构建了一批贴近真实用户表达的查询请求可以是人工编写的也可以由 LLM 辅助扩充。重点是这些查询要和技能库中的技能形成多对多的映射关系既有一对一的简单场景也有一对多、多对一的复杂场景。第三段技能调用执行。检索器根据查询返回技能列表然后送给大模型做进一步选择和调用最终调用动作会在模拟环境里真实执行。这一步是 RAE 和普通离线评测拉开差距的关键检索结果不是停在候选列表而是被真实地消耗掉。第四段任务完成判定。调用完成之后RAE 会基于“预期结果模板”或“自动判定器”检查执行结果是否满足用户意图。满足算成功不满足哪怕是技能本身很好也算失败。这套链路说出来没什么玄乎的但它把评估视角真正统一到了一个核心问题上用户的需求到底被满足了没有。2.2 为什么端到端判定比传统的“检索命中”更公平传统技能检索评估看的是检索结果里包不包含目标技能。听起来很合理但实际操作中有个致命的问题——标注人员很难保证自己的标注是完整且唯一的。举个例子用户需求是“提醒我明天早上九点开会”。技能库里有一个“日程提醒”技能还有一个“语音播报”技能还有一个“定时任务”技能。从人工标注的视角看也许只有“日程提醒”是正确结果。但从系统实现的角度看“定时任务”配合“语音播报”同样能完成用户需求。这种情况下离线标注就会产生偏差。而 RAE 绕开了这个标注问题它不看“你召回了哪个技能”它只看“用户的任务最终成没成”。只要最终闹钟响了、提醒弹出来了就算成功。这在设计上是非常聪明的取舍。2.3 RAE 的核心指标设计不是所有“成功”都等价RAE 里对任务完成度的判定也不是简单的是/否二分而是分成了好几个层次这部分我觉得特别有工程参考价值。完全成功用户意图的所有关键要素都实现结果可直接交付。部分成功核心动作完成但有次要信息遗漏或格式不对。功能成功但体验失败工具调用成功、接口返回正常但结果不符合用户的隐性预期。完全失败检索错误、工具报错、或执行结果和用户需求完全无关。这个分层的价值在于它能帮团队定位问题到底出在哪个环节。如果系统中“完全失败”占比高多半是检索器召回质量不行如果“功能成功但体验失败”占比高那问题可能出在提示词或模型推理上而不是检索。这个分层做出来之后团队开会时就不会再笼统地说“智能体效果不好”而是能精确地说“检索环节的误召回导致 30% 的请求走到了错误的工具上”。3. 从论文到落地RAE 评估流程的可复现实操理论说得再漂亮落不了地也是白搭。我根据论文思路结合自己在项目里跑智能体技能评估的经验整理了一套可以直接照着做的实操流程。这套流程不需要太多基础设施只要能跑通大模型 API、有一个向量数据库、有一份技能清单就可以开始。3.1 第一步构造一份“有陷阱”的技能库很多人做评估时有个习惯就是技能库越干净越好。但我建议反着来评估用的技能库一定要“有陷阱”。这里的陷阱包括描述相似的技能、功能重叠的技能、名称和功能容易混淆的技能。只有把这些真实世界中存在的“脏”情况放进去评估才有意义。我在构造技能库时一般会准备三批技能第一批是核心技能跟测试任务直接相关数量和描述都合理这批技能是保证系统能跑通的基础。第二批是干扰技能和核心技能在描述上有一定重合例如“发送邮件”和“发送消息”让检索器不能靠表面相似度取胜。第三批是边界技能比如权限受限的、仅限内部使用的、需要额外参数的。用来测试智能体在技能可用性判断上的能力。每份技能描述我一般控制在 50 到 150 字之间包含功能概述、适用场景、输入输出关键参数、使用限制。特别要注意的是技能描述里的措辞要尽量做到“功能和场景分离”。什么意思比如“发送定时消息”这个技能描述里需要明确说“适用于需要延后发送的场景”而不是笼统地只说“消息发送”。否则检索器很容易把所有和消息相关的 query 都召回这个技能。3.2 第二步准备任务查询集重点覆盖“易混淆场景”任务查询集是评估的输入。理论上应该直接从真实用户日志里抽样但在没有日志积累的早期阶段可以靠人工LLM 辅助生成。查询集会分成几个类别简单直给型用户需求和技能描述高度匹配例如“发一封邮件给张三”。复合任务型用户需求需要多个技能协作完成例如“把昨天销售数据汇总后发给李四”。易混淆型用户表述含糊需要结合上下文或常识才能判断正确技能例如“帮我把上次讨论的内容发到群里”如果团队里没有“会议纪要发送”技能就只有“消息发送”技能那么应该记作失败还是成功这类边界情况建议在评估设计阶段就定好规则。无对应技能型用户需求当前技能库无法满足例如技能库里没有“预订机票”技能用户却提出了预订需求。理想的系统应该明确表示“无可用技能”而不是强行调用一个不相关的工具。任务查询集的规模不一定要很大但覆盖面要足够宽。我的经验是每个技能至少覆盖 5 个查询每个易混淆场景至少覆盖 3 个变体这样跑一轮下来既有统计意义又能定位问题。3.3 第三步实现评估闭环中最关键的“执行与判定”环节这是 RAE 和普通评测差异最大的地方。技能调用不能只停留在“检索到了”这一层要让检索结果真正走到执行层。如果你是在做业务系统可以裁剪成策略模式读接口返回数据达成一个可控的验证环境。如果没有真实接入条件就需要做一个执行模拟器。执行模拟器的核心逻辑是一个函数接收技能 ID 和参数判断参数是否满足技能的前置条件然后返回一个带状态的执行结果。例如def execute_skill(skill_id, params): skill skill_registry[skill_id] # 前置条件检查 for condition in skill.preconditions: if condition not in params: return {status: failed, reason: fmissing param: {condition}} # 模拟执行 if skill.require_network and not network_mock_up: return {status: failed, reason: network error} # 按技能真实业务规则模拟核心动作 return {status: success, result: skill.mock_output(params)}模拟器不需要覆盖每个技能的内部业务细节但它至少要能区分出“参数缺失”“权限不足”“条件不满足”“执行成功”这几种状态。这些状态会直接影响最终的判定逻辑。判定器方面我建议用“规则模板 LLM 二次判断”的双通道设计。规则模板先做硬性检查比如参数是否完整、返回值是否包含必需字段LLM 再做软性判断比如“用户说要发给团队所有人实际只发给了 leader这算不算成功”。两边结果不一致的时候记录为人工复核样本。3.4 第四步跑完一轮评估之后看什么指标RAE 跑完一轮之后会输出几个关键指标。我建议重点关注下面这几个它们分别对应了技能检索链路的不同环节。指标计算方式暴露的问题检索召回率任务成功的查询中目标技能出现在 Top-K 的比例检索器是否把正确技能排在了足够靠前的位置端到端任务成功率判定为“完全成功”的查询任务数 ÷ 总任务数智能体整体完成需求的能力误召回率被检索召回到且被模型执行后导致最终失败的次数 ÷ 总执行次数检索结果里有害的“类技能”干扰无可执行技能识别率无对应技能任务中系统正确回绝或转人工的比例系统是否过度自信强行调用错误技能这些指标单独看意义有限组合在一起就能讲出完整的故事。比如某轮评估端到端成功率只有 40%再看检索召回率有 90%说明问题大概率不在检索而在模型选择或参数填充。如果检索召回率本身只有 60%那就要回到技能描述和 Embedding 层面去优化。4. 我在实际运行 RAE 时踩过的坑给你提前排掉思路说完说点更实际的。我在复现这套评估流程的时候踩过不少坑有些是设计上的有些是执行细节上的。挑几个典型的说能帮你省好几个星期的时间。4.1 技能描述与实际行为不一致导致评估结果虚高最典型的坑技能描述里写着“支持批量发送邮件”但实际接口实现时一次只能发一封。检索器一看 query 里有“批量发送”字样匹配得很准执行器在模拟环境里也跑得通因为模拟环境没实现批量逻辑一次传一个参数也返回 success。最后评估结果虚高一到真环境就崩。这个问题的解法是技能库里的描述必须和真实行为严格对齐评估前最好做一次一致性审查。你可以把每个技能描述给到开发同学让他们逐条确认描述里的能力项是否真实存在。这一步虽然耗时但是评估结果可信度的基础。4.2 判定器会被“包装过的失败”带偏还有一个我也没想到的坑LLM 判定器经常会给出有偏差的判断。现象是执行器返回了一个错误码但错误信息被包装成“请稍后重试”LLM 判定器看到“请稍后”就认为任务成功。或者执行器返回了一段使用说明LLM 判定器以为这是真的结果数据。后来我的办法是在判定提示词里明确约束凡是执行结果中包含 error、exception、failed、denied 等关键词一律进入人工复核通道不再让 LLM 自行判断。如果调用结果是一个使用说明而不是业务数据也要视为未成功。这个经验不大但是很管用。4.3 查询集合里的数据污染会让你误判检索能力这里的污染不是指脏数据而是“无意中泄露了答案”。我在生成任务查询集时有一轮直接用 LLM 辅助扩充查询结果 LLM 自动把技能名称也写进了查询里。比如原查询是“帮我把周报发给老板”扩充出来的变成“用周报发送功能帮我把周报发给老板”。检索器在这种查询上当然百发百中但真实用户根本不会这么说。解决这个问题有两种方式。第一种是建立“查询不得包含技能名称或技能描述关键词”的约束生成后再人工抽检。第二种是拿真实线上日志做替换。我现在更推荐后者哪怕样本少一些、乱一些也远比看似整齐的模拟数据可靠。4.4 干扰技能不是越多越好有一个时期的评估集我把干扰技能堆到了三十几个结果所有技能的召回率一起下降。研究后发现过去的数量增加了检索器的不确定性同时也让大模型在选择工具时出现更多犹豫和误判。这个现象提醒了一个道理评估集要和实际环境一致。如果你真实线上环境里就十几个技能评估集放十几个就足够了。非要增加干扰技能会增加系统性问题也会增加很多与真实环境无关的问题。4.5 参数填充错误的场景必须单独统计还有一个容易被忽略的维度是参数填充。检索器找对了技能模型也选对了工具但在生成参数时把字段传错了。比如“查昨天订单”传成了“查今天订单”“发给张总”传成了“发给张工”。这类问题在端到端成功率里会体现为失败但如果只看检索指标完全看不出来。所以我现在会把“检索成功、执行失败——参数错误”单独拉出来做一个类别方便定位是模型参数生成能力的问题还是接口设计复杂度过高的问题。部分接口参数之间关系太反直觉完全靠模型推理确实容易错这时需要在技能描述里补充参数示例。参数示例给得好不好直接决定模型生成的准确率。5. 后续扩展把 RAE 的评估思路变成线上监控的一种变形RAE 一开始是针对离线评估场景设计的方法但是我在实际使用中发现把它的核心逻辑变形之后完全可以做成一个轻量级的线上巡检工具。具体做法是每天从线上日志里抽一小部分真实用户请求放到 RAE 环境里重新跑一遍评估流程。这里不需要真实执行业务操作只需要用模拟器复现执行链路然后对比线上系统的返回结果和模拟环境的执行结果。如果两者不一致说明线上技能库或者检索配置可能发生了漂移。这个方法特别适合技能库更新频繁的团队。技能描述改了几个字、向量索引重建了一次、 Embedding 模型升级了版本这些改动在形态上都很小但造成的效果波动却很大。通过 RAE 的每日巡检能在用户大规模感知之前提前发现异常。我自己的体会是做技能检索评估这件事最忌讳的就是闭门造车。你用再多的离线指标都不如让一个真实的用户请求走到真实的执行链路里看看任务到底有没有完成。RAE 的方法本质上就是在帮团队建立这样一个“效果校验器”。它不能替代产品直觉也不能替代用户体验反馈但它能给团队提供一个稳定、可复现、可持续迭代的质量基线。先把基线立住再谈优化和升级这是我在多次迭代之后最信奉的一句话。对这种评估方法有兴趣的团队我建议先不要急着搭建复杂的平台拿一个最小可用的脚本把三五个技能、几十条查询先跑通评估闭环看看输出的报告能不能帮团队定位实际问题。跑通之后再根据实际需要逐步扩展技能库、查询集和自动化能力。踩过一次坑之后再回来读论文里那些设计细节你会有完全不一样的理解。