智能体定制评估清单：七个维度避开‘演示很美、上线就废‘的坑

做智能体定制这行我见过太多项目死在最后一公里。演示的时候业务方拍手叫好上线跑不到一个月就蔫了用户不买账、准确性拉胯、兜底全靠人工。前阵子和几个同行聊天大家最头疼的都是同一件事智能体定制怎么避免“演示很美、上线就废”。今天不聊模型选型那套虚的直接给一份我自己项目里沉淀下来的评估清单照着走查能筛掉大部分上线即翻车的隐患。这篇东西适合正在做智能体交付的项目组、准备引入智能体定制的业务负责人也适合那些被乙方Demo忽悠得心痒痒、但还没想清楚怎么验收的甲方。1. 先搞明白演示很美的智能体为什么一上线就露馅1.1 演示环境是“无菌实验室”生产环境是“真实路面”任何一个智能体定制项目演示时都在一个高度理想化的环境里跑数据是挑过的、用户问题是预埋的、系统是稳定的、网络是通畅的。可生产环境完全是另一回事。真实业务里用户提问的表达千奇百怪“帮我查一下那个订单”这种指代不明的输入每天能收到几百条业务系统偶尔超时接口偶尔返回乱格式知识库里的文档更新不及时甚至存在新旧两版矛盾的条款。我举个例子。我们之前给一家物流公司做智能客服演示时用的是标准的运单查询流程用户输单号、查状态、反馈异常非常顺滑。上线后第三天就出问题用户说“我的快递怎么还没到”系统没有单号应该追问结果模型直接默认了一个错误逻辑回复“您的包裹已签收”。用户当场炸了。这就是典型的演示环境不会暴露的问题——现实业务里用户不会按系统设计者的思路提问。1.2 干净样例掩盖了“数据质量”这个真短板演示时用的测试数据基本是人工整理过的理想样本。字段完整、格式规范、语义清晰喂给模型当然漂亮。但真实业务数据有多脏我这边举三个最常见的例子用户输入夹杂口语、错别字和方言“这个退了不要了再下一单”图片类输入经常是歪的、反光的、模糊的OCR解析直接降级数据库里的历史工单充斥着空值、错录、重复订单。所以做智能体定制首先要有一个清醒认知模型再强喂进去的数据不行效果一定拉胯。这不是调参能解决的问题需要从数据治理层面做功课而不是指望换个更贵的模型就万事大吉。1.3 演示者熟悉系统真实用户有“一万种奇怪操作”演示走查时操作者大概率是项目的开发或产品他们对系统的边界、问答逻辑、后台配置都了然于心。但真实用户不会看操作手册也不会按照预设路径走。他们可能第一句不说单号先说一长段抱怨对话进行到一半突然换话题要求智能体做超出权限范围的操作把客服机器人当成人工客服输入“转人工”得不到响应就开骂。说白了真实用户的行为是不可预测的。评估一套智能体定制方案能不能上线不能只看“设计好的问题能不能答好”更要看“没设计过的问题会不会把系统带崩”。2. 智能体定制评估第一关模型能力别只看演示时的那几个问题2.1 指令遵循与工具调用连续跑50次看成功率很多智能体定制项目号称“能调用工具”演示时只是调一个接口查个订单。真实业务里一个任务往往需要连续调用多个工具查订单、查物流、查库存、计算退款金额、再写一条售后工单。中间任何一步工具的入参解析错了、调用顺序乱了整个流程就断了。评估方法很直接准备一份覆盖核心流程的测试集端到端连续跑50次统计整体成功率。我见过的合格项目50次里至少要有48次全流程跑通换算下来95%。低于这个数上线后用户体感会非常糟糕因为哪怕10次里失败1次对用户来说就是“这个客服不行”。2.2 多轮记忆与主动澄清真实对话不会一轮结束演示时大多是一问一答但真实用户经常连续说好几句话、会在对话中途追加条件。我建议在评估时专门设计几组“高难度多轮场景”核心考察三件事对话超过10轮之后模型还能不能记得最开始用户报的关键信息用户引入一个新的指代对象时模型能不能正确关联上下文信息不足时模型是主动追问澄清还是硬着头皮瞎猜乱答。我之前测过一个项目用户报了个订单号要求改地址客服小二改完地址后用户又补了一句“顺便把那个赠品也换个颜色”模型直接把上一个订单的赠品给改了完全没确认是哪个订单。这种错误演示时根本不会发生因为演示脚本里不会有这种模糊指代。2.3 幻觉与拒答的平衡宁可说不知道也不要硬编做智能体定制最怕的不是模型能力不足而是模型“太自信”——明明知识库里没有它也能给你编一个答案出来而且语气还很笃定。这种幻觉在演示时往往被忽略了因为演示问题都在知识库覆盖范围内。真实上线后用户会问各种奇奇怪怪的问题模型遇到没见过的内容能不能明确说“不知道”并引导转人工这比什么都重要。评估时建议做一组“知识库外问题”专项测试数量不少于50条逐条看模型的拒答率和编造率。合格线是编造率不能超过2%拒答时必须有引导话术推荐人工客服或标准求助路径。说实话一个敢于承认“我不知道”的智能体比一个硬撑着胡说的智能体可靠得多。3. 智能体定制评估第二关知识库和数据才是RAG效果的真短板3.1 用三个月的历史真实语料做一次“脏数据走查”所谓“RAG效果好不好”多数人以为是检索算法或模型能力的问题实际上80%的瓶颈在数据本身。做智能体定制的验收我强烈建议拉出近三个月的历史真实对话记录或工单数据抽样200条左右作为走查样本。抽样时不要挑好的要尽量覆盖那些当初被判定为“难处理”“需人工介入”的记录。把这两百条样本逐一喂给智能体人工标注三类结果完全解决、部分解决、没解决。最后算一个“真实解决率”。这个数字往往比演示时PPT里写的准确率低20到30个百分点也正是这个差值决定了上线后的用户口碑。3.2 文档解析与检索粒度PDF里的表格是重灾区现在很多知识库还是以PDF、Word、扫描件为主解析的时候问题特别多。尤其是PDF里的表格转成文本后经常排版错乱检索的时候根本匹配不到正确内容。更麻烦的是扫描件OCR识别出来一堆乱码再强的embedding模型也救不回来。所以数据评估有一个笨办法拿知识库里的原始文档随机抽20份做解析测试统计“解析后可检索质量”的比例。我自己的标准是至少90%的文档解析后能保持语义完整低于这个数先别急着调检索先把解析流程修好。3.3 知识冲突、时效性与更新机制业务文档经常存在新旧版本并存的情况比如产品下市了但旧说明文档还挂在知识库里。智能体检索时可能调出新版规则也可能调到旧版规则回复就无法保持一致。更头疼的是时效性问题知识库里没有更新时间戳模型永远拿旧信息回答用户用户一看就是答非所问。我之前评估过一个企业内部的HR智能体员工问年假天数知识库里同时存在旧员工手册和新年假制度智能体有时答旧政策5天有时答新政策10天。这种知识冲突靠调模型参数根本解决不了必须在知识入库环节建立版本管理与时效标记。评估时务必问清楚知识库有没有负责人有没有更新SOP有没有冲突裁决机制。3.4 权限与安全智能体不能知道的坚决隔离智能体定制接入企业系统之后往往会面临权限边界问题。用户直接问“帮我查一下某个同事的薪资”或者试图让它执行未授权操作智能体必须守得住红线。这个话题经常被忽略但一旦上线它就是合规和数据安全的重大风险点。评估方法不复杂列出敏感信息清单和越权操作场景逐条测试智能体是否能够正确拒绝。更重要是的接入企业内部系统时接口层面要做权限管控而不是单纯依赖模型的“自觉”。智能体意味着企业多了一个数据交互入口这个入口该有的权限管控、操作审计、访问日志一个都不能少。4. 直接可抄的智能体定制评估清单七个维度一次走查4.1 七个维度的权重与设计逻辑这份清单的核心思路很简单把智能体当成一个“新入职员工”来验收。面试成绩好不能说明能力行真正要看的是试用期表现、异常处理、对业务规则的熟悉程度以及离开了老员工人工客服能不能独立干活。我这边一般按七个维度来打分每个维度满分5分按权重加权计算总分。总评分4.5分以上才建议上线3.5到4.5分建议整改后再上线低于3.5分基本要回炉重做。评估维度权重核心关注点场景覆盖度15%真实业务输入是否全面覆盖长尾场景占比模型基础能力10%指令遵循、工具调用、多轮记忆、拒答能力知识库与数据质量25%文档解析、检索命中、知识冲突、更新机制任务完成质量20%端到端解决率、转人工率、平均交互轮数异常处理与兜底10%无法回答时的兜底话术、转人工路径、纠错机制可观测性与运维10%链路追踪、指标监控、对话回放、版本回滚成本与维护模型10%单次交互成本、内容维护人时、业务量增长模型4.2 每个维度的具体评估问法这七个维度如果只是“看报告”基本等于没评估。我习惯把它转成一张“问问题清单”走查时逐条过每个问题都要有证据支撑场景覆盖度有没有抽样跑过三个月真实数据Top10高频场景是否都有对应测试用例超出设计范围的输入占比是多少模型基础能力连续调用工具50次的成功率是多少10轮以上多轮对话的关键信息定位准确率是多少模糊输入下主动追问的行为占比是多少知识库与数据质量随机抽20份文档的解析通过率是多少检索Top10命中率是多少新旧知识冲突共有多少条是否有明确的更新责任人与更新周期任务完成质量端到端完全解决率是多少转人工率是多少平均解决一个问题需要几轮对话异常处理与兜底知识库外问题测试50条的拒答率是多少编造率是多少转人工入口是否在任何界面都可达可观测性与运维有没有对话链路追踪有没有token消耗监控有没有失败对话回放功能模型和知识库的版本是否可回滚成本与维护模型单次交互成本是否算清楚知识库每次更新需要投入多少人力业务量翻倍时成本是否线性增长这套问题每一个都对应着上线后真实会遇到的情况而不是验收PPT上的漂亮指标。4.3 一次完整的清单走查最少需要五天走查这七个维度不是半天能完事的。我的经验是最少留出五整天第一天准备数据。拉历史语料、抽真实样本、整理测试集、配对预期答案第二天基础能力测试。跑指令遵循、工具调用、多轮对话、拒答测试记录数据第三天知识库走查。做解析测试、检索测试、知识冲突排查第四天端到端任务测试。把完整业务场景从头到尾跑一遍观察转人工率和解决率第五天汇总打分、组织评审会、输出整改清单。另外一个建议走查时一定要让“没参与过项目的人”当验收员最好是了解业务但不了解技术细节的真实用户代表。原因很简单项目组自己测自己的东西会下意识地绕过那些容易失败的场景陌生人提的问题才是用户真实会问的问题。5. 上线不是终点把评估清单变成持续运营的一环5.1 别直接全量上线灰度跑两周再说智能体定制的上线方式我极其不推荐“一次性全量切换”。不管前期评估做得多充分真实环境总有想不到的边角情况。稳妥的做法是灰度发布先切5%左右的真实流量跑一到两周密切观察三个关键指标的变化——转人工率、平均交互轮数、用户满意度评分。如果灰度期间转人工率没有明显上升、平均交互轮数没有明显变长、满意度没有下滑再逐步扩大到30%、50%最后全量。这个过程听起来保守但能避免“一上线用户就骂运营团队连夜救火”的尴尬。5.2 用户反馈闭环把“不满意的答案”变成优化弹药很多智能体定制项目有个通病上线之后没有反馈收集机制用户遇到错误答案只能默默关掉页面或者转人工开发团队完全不知道自己做的东西在真实环境里表现如何。这等于盲人开车。我强烈建议在界面上保留“有帮助/没帮助”按钮在后台记录所有负面反馈对应的对话链路每周安排专人抽看把高频失败场景录入优化池形成“反馈—标注—优化—回归”的闭环。智能体不是上线就完事的项目它会随着用户使用慢慢进化。5.3 回归测试集防止修一个 bug 再造一个新问题智能体定制上线后知识库会更新、提示词会调整、模型版本也会升级。每次改动都有可能引入新的回归问题——之前答对的开始答错了之前不幻觉的开始幻觉了。所以搭建一套固定的回归测试集非常关键。这套回归集建议包含四类样本核心业务场景100条、高频用户问答100条、知识库外问题50条、多轮复杂对话30条。每次改动后先跑一遍回归集只要发现通过率下降立刻定位原因必要时回滚版本。这也是为什么在评估维度里强调“版本可回滚”没有版本管理出了问题是没法追溯的。5.4 别忘了评估清单本身的版本迭代我自己的习惯是每做完一个智能体定制项目都会把评估清单更新一版把这次项目中新踩到的坑补进去。比如之前有一次做工业设备故障诊断发现用户经常上传模糊的照片后来就在“知识库数据质量”维度里增加了“图片类输入质量”的专项评估项。再比如做金融领域定制时发现用户对智能体的用词严谨性极其敏感一种说法稍有问题就投诉于是“回答合规性”也单独成了评估维度。这份清单不是死的它应该跟着行业的实践一起长。这也是做智能体定制这件事最有意思的地方——没有一套标准答案能适配所有业务但有问题清单和评估方法能保证你前进的方向不会偏。最后说一点我的真实体会我做过这么多智能体定制项目最容易被跳过、但损失最大的评估项其实是“多轮追问测试”。演示的时候大家都习惯把用户问题写得清清楚楚可真实用户说话从来都是缺胳膊少腿的。你在评估清单里加一条“信息不足时智能体是否主动追问”能帮你避免上线后至少三成以上的答非所问。这份清单建议每个智能体定制项目从立项第一天就挂在墙上别等演示完、上线前才想起来用。