接手AI客服项目第三个月我对着后台的日志面板发了好久的呆。控制台上每一轮请求都是200 OK每一次大模型调用都返回了normally自动打标系统给76%的会话贴上了“满意”可真实的业务数据却指向另一个方向退单率在涨投诉量在涨人工客服的转接排队越来越长。我当时跟同事开玩笑说这套系统像一个演技很好的实习生表面功夫全部到位但活是一点没干成。后来花了整整两周把日志全部拆开重看才发现问题比我想象的严重得多——所谓的78%失败不是系统报错的那种失败而是对话本身已经死在“礼貌的废话”里但日志按技术口径判定为成功。这个标题里如果有读者想找的答案大概就是这个AI客服项目里为什么你的服务看起来一切正常业务却在持续失血而日志完全没法告诉你真相。这篇文章我会把当时踩过的坑、排查链路、最后落地的检测方案和评估标准全部拆开来讲适合正在做AI客服、智能导购、私域机器人这类项目的同学参考也适合所有被“日志全绿”迷惑过的从业者。1. 当控制台全是200 OK时问题才刚刚开始先说当时那个让我脊背发凉的统计结果。系统上线两个月按日志里的“任务完成标记”去看会话完成率大概是90%左右按大模型返回的文本长度和调用耗时去看一切都很健康按用户对机器人的点踩数量去看负面反馈率不到5%。我用这些数据写了周报向上汇报“系统运行平稳”然后继续去优化响应速度。直到有一天我随手点开一条被自动评估为“满意”的对话记录才发现自己一直在被日志口径欺骗。那条对话是这样的用户我的订单显示已签收但我根本没收到货怎么办 AI非常抱歉给您带来不便我理解您的心情。您可以先查看一下订单详情页的物流信息也可以联系快递公司进行确认。 用户我查过了快递说不是他们送的让我找商家。 AI非常抱歉给您带来困扰建议您稍后再次查看订单状态或者通过售后服务入口提交工单我们会尽快为您处理。 用户行吧。自动评估模型给这轮对话打出的分数是0.85分理由是“语气礼貌、共情充分、给用户提供了解决方向”。但从业务视角看这轮对话完全是零产出用户的问题没有闭环快递、商家、平台三方踢皮球机器人帮不上忙用户最后一句“行吧”不是满意是放弃。我翻了十几个类似的会话发现规律惊人地一致AI把一个需要真正介入的问题用标准的道歉话术和一串无效引导糊弄过去了用户不骂人、不点踩、不投诉只是安静地流失。1.1 日志里没有谎言只有观测盲区那段时间我反复琢磨一个问题为什么日志会集体失明答案其实是经典的“观测指标错位”。系统记录的是技术成功而不是业务成功大模型被调用了、返回了文本、整个过程没有异常这就叫“成功”。至于这段文本有没有解决用户的问题系统不知道也没有任何机制去探测。日志擅长回答“服务有没有发生”但完全不回答“服务有没有生效”。理解这一点之后我把问题重新定义了一下我们要找的不是“系统报错的失败”而是“业务交付上的失败”。前者是宕机、超时、接口报错后者是用户带着问题进来带着问题离开。这个区分是整个项目翻盘的分水岭。1.2 78%这个数字是怎么来的标题里说“78%的失败”这个数字不是系统直接给出的而是我们事后用人工标注和策略规则估算出来的。做法是把一周内所有会话抽样500条让三个客服主管按业务结果打分问题解决、部分解决、未解决、无法判断四档。结果28%是明确解决22%是部分解决接近40%是未解决剩下10%无法判断。如果按“未解决部分解决中无明显进展的会话”来估算差不多就是78%这个水平。换句话说每100个用户进来约78个人没有得到真正想要的答案。这里要澄清的是不是78%的会话都让用户愤怒——大部分用户只是平静地离开但平静地离开对业务来说才是最危险的。骂你的人至少还给了你一个修复的机会。2. 终于复现了“日志里的成功”是怎么骗过我的找到了“日志口径错误”这个大方向之后接下来要做的就是精确地拆解那些被判为成功的会话到底是怎么一路“成功”到用户放弃为止的这一节我尽量把排查链路完整写出来方便大家在自己的项目里按同样的思路走一遍。2.1 第一层排查把“用户说的话”和“AI说的话”分开统计最开始的日志面板把所有消息混在一起机器人的输出和用户的输入摞在同一个列表里看不出任何趋势。我做的第一个改动是分别统计两类消息的数量分布同时也统计每一轮用户消息的长度。结果很有意思正常解决的对话里用户消息的平均长度会越来越短且最后一条消息通常是“谢谢”“好的”“明白了”这类确认词而未解决的对话里用户消息的长度要么不减反增要么在第三四轮突然变成短暂的“嗯”“哦”“行吧”然后会话结束。这背后的原理不复杂当用户觉得AI帮上了忙他的注意力会从“描述问题”转移到“确认结果”所以消息变短且伴随正向词当用户觉得AI帮不上忙他往往在第三四轮进入“敷衍模式”用一个没有信息量的词结束对话。我用这个特征做了一把初筛把“最后一条用户消息是短字数且无实质内容”的会话全部拎出来准确率意外地高。2.2 第二层排查找到那些“礼貌且无用”的回复模式初筛出问题会话后我把AI的回复文本做了聚类。最常出现的失败模式大概有四类失败模式典型话术特征日志表现自嗨式感谢道歉理解用户心情无实质方案回复长度正常语气分高自我放弃式FAQ让用户自己去页面查、自己去联系客服命中标准答案库但没命中意图错误重复把两种处理方式混在一起反复输出轮次多但信息增量极低幻觉式编造给出不存在的政策、金额、时间节点文本通顺与知识库无关当时最打击我的是第四类。知识库里根本没有的内容大模型也能一本正经地答出来而且因为语句流畅自动评估模型还会给它打高分。有一条会话里用户问“保价费能不能退”AI直接回复“根据平台最新政策2024年6月1日之后下单的保价费可以在订单完成后退还”实际上平台压根没有这个政策——后面用户拿着截图来投诉人工客服花了一个小时才解释清楚。2.3 还需要问一句失败是从哪里开始的把失败会话按节点拆开看我又发现大部分问题在更早就埋下了。大概有这么几个来源入口处意图识别错了方向。用户问的是“退款到账时间”意图分类器给打成了“退款流程”于是AI回答了一堆“如何申请退款”用户想听的“款项什么时候到”完全没被回应。检索召回不足。知识库里虽然有一篇介绍保价政策的文档但向量化之后跟用户口语化提问的相似度过低导致召回阶段就把正确答案排除了。系统提示词里“不得编造”的约束在局部失灵。原因往往是上下文太长系统指令被后面的信息冲淡了。这一层排查下来我对“日志里全是成功”这件事算是彻底免疫了。从那以后我再也不看技术的成功与否只看业务上有没有进展。3. 三级检测体系把“看起来成功”变成“测得出来的成功”发现问题之后必须拿出可落地的方案。我们最后沉淀了一套三级检测体系不算复杂但每一层都解决了前面挖出来的一个具体问题。这里详细拆一下方便大家按需求裁剪。3.1 词汇与边界检测先把最明显的“假成功”拦住第一级是最简单的规则层但千万别小看它。很多“假成功”其实有非常固定的语言模式根本不需要动用大模型正则加词典就能覆盖。我们对两类内容做了拦截用户侧出现“算了、行吧、我自己、不用了、随便吧”这类放弃词时把会话标记为“疑似流失”不再计入“满意”口径。机器人侧出现“请稍后再次查看、建议您自行在页面操作、您可以咨询其他客服”这类“无责任回复”时把回复标记为“低价值回复”如果一轮对话里低价值回复占比超过50%整条会话被降级。另外我们还做了一个比较笨但有效的检查把AI回复里出现的所有“方案”和知识库原文比对计算重合度。如果回复内容在知识库里完全找不到来源就可能是幻觉需要走人工复核流程。这套规则层上线第一天就把自动评估的“满意率”从76%打到了50%以下——不是业务变差了是终于开始看到真实数据了。3.2 语义级检测分析AI到底“接没接住话”规则层只能拦住明确的模式但很多失败是语义层面的。还是前面那个例子用户说“我查过了快递说不是他们送的”AI回“建议您再查看订单状态”——从字面上没有任何违规词但语义上完全回避了用户的真实诉求。这一层我用了两步来检测第一步是“用户诉求判定”把每轮用户输入先用一个轻量模型分成几个基础诉求类型查信息、办业务、投诉、询问进度、表达情绪等。第二步是“回复对应性判定”看AI的回复是否正面回应了诉求。判断标准不是看文本像不像而是看回复里有没有用户问的那个实体的处理结果。我当时用了一个很土但有效的办法把用户的诉求关键词抽出来比如“退款”“什么时候”“保价费”然后看AI回复里是否出现了对应的实体词和动作词。如果用户问的是时间回复里必须有明确的时长或窗口如果用户问的是钱回复里必须有金额或路径如果用户问的是进度回复里必须有当前状态或下一步动作。任何一个都没有就标记为“未接住”。这一段跑下来我发现未接住的对话里有相当一部分是模型“绕着问题走”它宁可输出三句道歉也不肯直接给一个不确定但有用的答案。这就牵出了提示词层面的问题我们当时把“不能随意承诺”写得太重模型为了不出错选择了不回答。后来把提示词改成“不确定时请正确引导用户并给出可验证的路径”情况立刻好转。3.3 业务闭环检测从“说对了”到“办成了”规则层和语义层解决的是对话质量问题但最终要回答的问题是用户的问题到底有没有被解决这一层需要把业务系统的数据接进来。我们做了三类闭环检测查单类用户问订单状态AI回复之后系统查询是否真的调用了订单接口是否返回了当前状态。如果AI只是说“您可以去订单页查看”但系统没有做任何查询动作视为未闭环。售后类用户要退款/退货/换货AI引导用户提交申请后判断售后单是否真的创建了。知识类用户问政策/规则AI给出答复后跟踪用户是否继续追问。如果用户连续两轮围绕同一实体追问说明之前的信息没有解决他的疑问。这套检测需要业务系统在埋点层面做配合但效果是显而易见的。上线之后我们发现一个扎心的事实大概有15%的会话AI其实已经说出了正确答案但用户依然不满意。原因在于回答的方式让用户觉得“不可信”——比如直接甩一条政策链接而不给简要结论或者话术太像机器翻译。这一点靠检测是解不了的只能靠话术模板迭代来解决。4. 重构评估标准从“LLM把话说了”到“用户把事办了”三级检测体系上线后我们手里终于有了相对可信的失败数据。但这个项目给我最大的教训是如果评估标准不重构再好的检测体系也只是让数字变得更难看没法引导系统变好。所以这一节我想重点聊聊评估体系的改造。4.1 北极星指标48小时召回率与72小时复购率我们彻底放弃了过去那套“准确率、召回率、对话轮次”为核心的技术指标换成了两个业务指标作为北极星48小时召回率会话结束后的48小时内用户是否通过其他渠道再次发起相同问题。这个指标专门用来抓“用户没得到答案但懒得当场骂人”的假性解决。72小时复购率/成单率电商场景里用户咨询后72小时内是否完成了实际下单。这个指标用来衡量AI客服对业务转化的真实贡献。选这两个指标的逻辑很简单自然语言理解做得对不对、检索做得好不好这些都是过程指标用户愿不愿意继续留下来和你对话、愿不愿意掏钱才是结果指标。“准确率95%”不能当饭吃但“每100个咨询用户里多出了3个新订单”能当饭吃——后者才是老板和业务方真正关心的。4.2 副指标一次解决率、截留率与上下文连贯率北极星指标之外我们还保留了三组副指标用于定位问题出在哪个环节。一次解决率FSR单一会话内用户诉求被闭环的比例。这个数字做不高没关系但要持续观察趋势。人工转接率与截留率用户主动要求转人工的比例以及AI在转人工前额外解决了多少问题。这一对指标能告诉你人机协同的边界设在哪里最合理。上下文连贯率同一用户二次进线时AI能不能回忆起上次的对话背景。这个指标对售后场景尤其重要用户最烦的一件事是“每次进来都要从头讲一遍”。4.3 部署策略与监控预警让团队为“真实失败”反应起来指标定了还得有人看、有动作。我们做了三件事第一把“未解决类会话”的样本按周推送给客服和产品团队每周五开一次复盘会只看失败样本不看成功样本。别小看这个动作——成功样本只会让你觉得系统很完美失败样本才是优化的弹药库。第二在日志里为每个失败标记建立索引支持快速检索。我们给每条会话加上了一个business_status字段取值是resolved、partial_resolved、unresolved、escalated。只靠这个字段就能把每天的失败会话自动汇总成趋势图。第三设置了一个“熔断阈值”。如果某个时段内未解决率超过60%或者AI连续返回三次相同无效答复系统会自动把该场景的用户转入人工队列不再让机器人硬扛。这个动作相当于给AI客服戴了一个紧箍咒防的不是用户而是我们自己过度自信。5. 日志体系改造把“详细信息”补回日志里让问题能被查走到这一步我们才终于回头去改造日志体系本身。前面说日志全是成功其实不止是统计口径的问题也有日志内容的问题——很多关键线索根本没记录进去事后想追溯都无从下手。5.1 日志里必须出现哪些字段现在我们的AI客服日志每条会话至少要包含以下几组字段分组字段项说明请求上下文session_id,user_id,entry_channel从哪个入口进来、是新用户还是老用户判题信息intent_id,intent_conf,retrieved_docs意图识别结果、置信度、命中了哪些知识库文档模型行为model_output,token_usage,latency完整回复文本、消耗、耗时业务结果business_status,closed_loop_type,escalation_reason闭环类型、最终状态、转人工原因人工标注human_label,human_comment客服/质控人员的事后标注有了这些字段再做分析就顺手多了。比如想知道“为什么某些意图的未解决率特别高”可以直接按intent_id分组看哪一类意图下retrieved_docs的命中率最低、model_output的重复率最高。5.2 一个说多了都是泪的经验别把大模型输出截断迭代中我们踩了一个特别蠢的坑为了省存储日志里只保留了大模型输出的前500字。结果问题来了很多失败恰恰发生在回复的末尾部分——模型在前面铺垫了一大段废话最后一句才是真正有用的方案而我们没存到。后来哪怕再心疼存储也把完整输出整个存下来了。别在这个地方省省掉的不是钱是你未来排查问题的时间。存储便宜时间贵。6. 从“AI客服”到“AI打杂客服”人机协同的边界探索检测体系、评估体系、日志体系都改造完之后项目进入了下半场人机协同的边界到底怎么划。这块没有标准答案但我们可以分享一下摸索出来的原则。6.1 AI负责高确定性任务人负责高价值低确定性任务我们把所有用户诉求按“确定性”分了两档。高确定性任务——查物流、查订单状态、查门店营业时间、查优惠券有效期——这类问题答案明确、操作有标准路径AI完全可以搞定。低确定性任务——投诉纠纷、价格争议、涉及赔偿、政策边界模糊——这类问题AI很容易触碰风险哪怕能生成答案也建议转人工。划分标准很简单如果一条规则能100%确定对错就交给AI如果答案需要做价值判断就让给人。别让模型去替公司决定“这个客户该不该赔偿”AI可以给建议但决定权必须留给人。6.2 “30秒无进展判定”机制我们还做了一个简单粗暴的机制AI在同一轮对话中连续给出两次相同的方向性建议后如果用户还在追问就自动弹人工转接提示。机制的名称叫“30秒无进展判定”不一定是30秒具体阈值看产品形态。核心逻辑是AI已经尽力说了两遍用户还是不满意说明卡在了AI能力边界之外再拖只会增加用户怨气。有一组数据值得参考上线这个机制之前用户平均要跟机器人聊6到8轮才会被转接人工而且这期间用户情绪已经明显恶化上线之后转接平均提前到4轮以内人工客服接手的会话里用户的负面情绪明显变少。多花一点转接成本换来的是用户体验止损这笔账算得过来。6.3 沉淀客服SOP反哺AI能力最后一个建议是别把人工客服和AI客服当成两条平行线。人工客服每天都在处理AI解决不了的问题这些问题就是AI能力的增长点。团队每周把人工客服的典型会话拿出来提炼成新的SOP和话术模板再回流到知识库和提示词里。这个闭环跑起来之后AI的未解决率才真正开始持续下降。我们的路径是从一开始的76%失败降到稳定期的大概35%到40%其中有一部分是天然需要人工介入的复杂场景AI硬做会亏。认清哪些必须放手给人工是AI客服项目里最成熟也最务实的判断。我自己做这个项目最大的体会是AI客服最大的坑不是模型不够强而是我们用技术指标欺骗了自己。日志不会说谎但日志背后的人会选错指标模型不会抱怨但模型会被错误的目标牵着走。每一次“看起来成功”的对话背后都可能站着一个正在安静流失的用户。先把衡量的尺子做对再去调模型顺序不能反。