做电商客服智能化前几年大家普遍习惯把“售后客服机器人”和“导购推荐机器人”分成两个独立项目来做一个负责退换货、查物流、开发票一个负责推商品、发优惠券、做关联推荐。我一度也是这么设计的直到在线上会话记录里反复看到同一类对话——用户上一句还在问“这个还能便宜点吗”下一句就问“有没有价格差不多但更适合我的款”紧接着又来一句“那退货运费谁出”。这段话里同时带着议价诉求、替代推荐诉求和售后权益诉求。如果客服和导购分属两套系统用户就只能被来回踢皮球。这篇文章想聊的就是“电商客服导购智能体”从零设计到落地开发的全过程核心围绕意图识别、商品理解、推荐策略、售后兜底、转人工衔接这几条链路怎么串起来。内容偏工程落地适合正在做电商客服Agent、智能导购或者做售前方案的朋友参考。我不会只给结论会把每个设计决策背后的原因、踩过的坑、以及线上验证的结果一起说清楚。1. 为什么客服和导购必须塞进同一个智能体1.1 “能便宜点吗”这一句话里藏着三种意图我见过太多把意图分类做成单选题的方案系统判断不了就给用户回一句“请问您是咨询售前还是售后”。这种交互放在现在的电商环境里基本等于劝退。真实会话里用户的话往往是一句多义的组合拳拿“能便宜点吗”来拆里面至少有三种理解议价咨询这款还能不能降、有没有隐藏优惠替代寻找如果这款不能便宜有没有同价位更划算的选择售后权益我刚买完就降价能不能申请差价补偿。在独立客服机器人里这句话大概率被路由到“优惠查询”然后搬出一套标准话术在独立导购机器人里它又可能被当成购买信号硬推一个价格档位更高的商品。两边各答三分之一用户自然不满意。用户真正想要的是先知道当前商品有没有活动价如果没有再推荐一个性价比更合适的替代款最后顺便告诉他有没有保价政策。我在设计时把意图识别拆成了两层粗粒度路由决定“当前轮该由客服逻辑、导购逻辑还是售后逻辑主导”细粒度槽位抽取负责把价格预期、规格参数、承诺期限这类信息抽干净。两层共用一份会话状态这样“能便宜点吗”既能触发客服侧的优惠判断又能带出导购侧的替代推荐两者还能共享同一个上下文不会互相覆盖。1.2 对话历史是花钱都买不到的推荐信号导购推荐系统的经典痛点是不知道用户到底想要什么。注册画像冷冰冰标签也不准用户看到推荐第一反应往往是“这跟我有啥关系”。但会话历史里全是高价值信号用户说“孩子三岁要不容易摔碎的”这就是明确的材质偏好用户说“明天就要用”这是时效偏好用户说“之前买过你家另一款”这就是复购跨品类线索。如果客服和导购分开客服系统拿到的对话文本只能服务售后任务导购系统拿到的是另一批被截断的会话记录两边都缺上下文。合体之后同一个会话状态可以在意图路由和推荐策略之间流转。我在项目里做过一次对比实验在注入完整会话历史的情况下推荐被点击的效果比只看当轮query明显更好多轮上下文对转化带来的提升非常直观。这也是我认为“客服导购”不应该分开的根本原因——会话本身是连续的系统没有理由在中间切一刀。1.3 合并之后的成本和收益模型从成本角度看两套机器人意味着两套NLU服务、两套知识库、两套日志链路、两套转人工体系重复建设非常严重。统一成一套智能体后客服和导购共用意图模型和检索链路只是策略层多一张路由表。线上部署时也只需要在会话中间层做一次资源分配运维压力小很多。我当时算过一笔账假设日均会话一万拆成两套系统因为意图误判需要二次转移的会话比例大约在15%到20%。合并之后会话能够在同一套上下文里自然完成跨域处理因为转接导致的用户流失会明显减少。这个数字不同业务会有浮动但方向是一致的对话天然连续系统就不该被人为切割。2. 总体架构不是接一个大模型API就完事2.1 六层职能拆分一个能商用的电商客服导购智能体我习惯把它拆成六层接入层处理多渠道进来的消息统一会话ID、消息格式和时间戳意图路由层粗粒度识别当前场景输出客服、导购、售后、闲聊、转人工五类信号策略仲裁层结合会话历史、用户情绪、业务状态决定这一轮回复怎么走知识检索层对商品库、政策库、文档库做混合召回再重排动作执行层查库存、算优惠、创建售后单这类确定性操作生成与兜底层大模型生成自然语言规则引擎做合法性校验最后兜底回退到人格化话术。这里最容易被忽略的是意图路由层和策略仲裁层的区分。很多方案把意图识别和回复策略合在同一个Prompt里看起来省事实际上把“知道用户要什么”和“决定给它什么”混为一谈。意图分类用轻量模型就能做到低延迟高准确而策略仲裁依赖复杂上下文适合交给大模型综合打分。两者分开之后调试时能分别看出来到底是“没听懂”还是“听懂了但策略错了”这个区分对排障特别关键。2.2 一条消息从进入到回应的全链路用户消息进来后的完整处理路径是这样的先做标准化去掉无意义表情、处理同义词、识别商品链接或型号代码。然后并行跑三个任务意图分类、商品实体识别、情绪标签。这三个结果连同最近的会话摘要一起进入策略仲裁模块。仲裁模块决定的是回答策略而不是直接生成答案。如果仲裁结果是要查库存就走动作执行层调库存接口如果要解释售后政策就走政策知识库检索如果既涉及优惠又涉及推荐就生成一条“服务信息推荐理由”的组合话术。整个链路用工作流引擎编排每层都有可观测日志。我坚持不让大模型裸奔着直接回答所有问题因为在电商这种强业务约束的场景里自由生成的代价太高。2.3 选型判断快慢分流与索引先行模型选型上我推荐两条腿走路。快路径用一个小模型处理高频固定问题比如发票、物流状态、尺码表响应要快、成本要低慢路径用大模型处理复杂对话比如比价、组合推荐、情绪安抚类。我见过只接一个大模型的做法用户就问一句“查一下订单到哪了”都要等两三秒这种延迟放在电商客服里基本不合格。快慢分流之后简单问题的首次响应时长能压到一秒内复杂问题则保留模型的深度能力。检索层最常踩的坑是把商品数据表整张塞给模型当上下文。正确做法是给商品建一个专门的知识索引标题、参数、卖点、优惠规则分开存储召回时按用户实体过滤再交给生成层排序。这样既控制了token消耗也能在商品改价后只更新索引不需要重新部署模型。3. 商品理解与知识库建设导购能力的地基3.1 商品数据的结构化清洗导购智能体答得好不好七分靠数据。电商的商品数据通常是从上游进销存系统同步过来的标题又长又乱比如“夏季新款 女款轻薄休闲运动鞋 白色 36”这种。模型直接读这种原始标题根本分不清卖点是透气、轻量还是百搭。我在项目里加了清洗流程把标题切成品牌、品类、性别、颜色、尺码、卖点词再补上规格参数、库存状态、价格区间、运营配置的关联推荐位。清洗之后每个商品会生成一段标准化的商品摘要我习惯叫它“给模型看的包装卡”。包装卡里除了硬参数还会记录运营人工维护的卖点词和适用人群。没有这张卡让大模型从原始数据表里自由发挥十个回答里至少三四个会出现价格或参数幻觉用户一句“你这不是标价199吗”就能把对话拖进事故现场。3.2 三类知识库的定位差异我强烈建议把知识拆成三个独立索引不要混在同一个向量库里知识库典型内容更新频率召回方式售后政策库退换货规则、保价规则、运费说明、发票问题低版本化修改规则优先向量辅助商品知识库SPU摘要、卖点、库存、价格、优惠高每天变价关键词精确匹配向量排序会话记忆库用户偏好、未完成的订单意图、当前诉求实时写入结构化标签不参与向量检索分开存的好处是召回时能分别设置权重和过滤条件。售后问题只查政策库避免被商品信息干扰推荐场景只查商品库避免模型把售后话术当成卖点来造句。政策库我建议以确定性规则为主大模型只负责把规则翻译成人话绝对不能自己发明政策。3.3 向量检索与关键词检索的配合做知识检索时我一开始只上了向量检索结果发现一个典型问题用户问“这款手机有128G版本吗”向量召回容易命中一堆“存储空间大”的泛泛描述反而把精确参数漏掉。后来改成混合检索关键词命中优先向量相似度排序兜底。具体做法是给商品库维护一个关键词索引针对型号、颜色、容量这类硬参数做精确匹配向量库负责处理语义模糊的表达比如“适合通勤穿的”“送长辈的”。召回之后加一个重排环节按参数匹配度、价格接近度、库存可用性综合打分。这个改动比换更强的大模型更能实际提升导购效果因为问题大多出在召回精度上而不是语言组织上。4. 意图识别与模式仲裁什么时候卖货、什么时候服务4.1 意图分类的层级设计意图分类我采用两级落地。一级意图解决“现在是什么场景”导购、客服、售后、闲聊、转人工。导购场景下再细分商品咨询、比价、优惠计算、尺寸推荐、替代推荐客服场景下细分订单状态、物流、支付、发票售后场景下细分退换货、保修、退款进度、投诉。这里最大的教训是一级意图不要贪多。种类一多模糊表达就会互相抢。用户说“这个有货吗”既像导购也像订单咨询实际是库存查询。把它挂在导购下的“库存咨询”更合理因为核心动作是评估当前商品。类目之间要有明确的互斥规则否则训练数据里满是歧义样本模型越训越糊涂仲裁层也跟着失灵。4.2 模式仲裁不是简单的一刀切仲裁层解决的是多意图叠加时“先说什么、后说什么、用什么语气”。举一个真实场景用户“这个能便宜点吗” 仲裁结果当前商品无优惠先走服务话术表态“暂时没有降价”接着给一个替代推荐“不过同系列有一款正在参加满减我帮您对比一下”再追问是否要看细节。这句回复的本质是“客服式拒绝导购式引流”的组合。如果单纯走导购模式会显得太急着卖货如果纯客服模式对话就直接结束了转化机会也丢了。仲裁层在这里的工作是判断“拒绝了用户期待之后有没有替代方案”——有就给没有就诚恳道歉并准备转人工。我还加了一条强制规则当用户情绪分低于阈值或者对话已经进入售后投诉流程时推荐动作整体关闭。用户正在为质量问题生气智能体还在推新品这种体验不只是差还会严重损害品牌信任。4.3 人设与语气的分场景控制客服和导购的语气必须有区分度。导购人设可以热情一点多给选项多使用“我帮您对比”“这款更适合您”这类表达客服人设要稳先确认再答复少用感叹号必要时给出明确的服务承诺。实现上不靠每轮在Prompt里重复人设而是固定两套系统提示词由仲裁层按场景切换。我们还给生成层配置了风格约束客服模式禁止使用“超级划算”“错过等一年”这类销售话术导购模式则允许适度使用促销词。5. 推荐策略让导购像人而不是像硬广5.1 推荐时机比推荐内容更重要评测一个导购智能体最先看的就是它会不会在不该推荐的时候硬推。我统计过被用户直接怼回去的会话排在第一位的坑就是在售后场景里弹出商品卡片第二位是在用户问物流时推荐换购。所以系统里有一条硬性规则推荐动作必须与“用户表达偏好、用户在比价、用户在找替代、用户在凑单”这几个信号绑定其他情况默认不推。推荐也不是每次都必须抛出一堆商品。在犹豫型会话里给两个精心筛选的选项比给五个让用户选择压力小得多。我给策略里加了一个选项上限约束默认最多展示三款商品除非用户明确说“都看看”。这个约束看起来很傻但实际效果比想象中好用户不会被信息淹没反而更愿意继续聊下去。5.2 三种推荐逻辑与理由生成推荐逻辑我主要做三种同品替代用户问的款缺货或参数不满足推荐同品类中参数最接近、价格差异可控的商品互补搭配用户已选定主商品推荐配件、耗材、组合装价格区间迁移用户表示预算有限推荐价位更低但核心参数还满足需求的商品。但推荐动作之外更重要的是理由。每个推荐结果必须带一句“为什么推荐这个”的解释没有理由的推荐就是垃圾广告。理由的生成要引用商品的客观参数而不是空泛地说“这款也很好”。比如“您之前选的这款没有小号了同系列的另一款有您要的尺码重量还轻了二十克”这句话里有信息量用户才愿意往下看。5.3 会话内个性化的冷启动方案不做注册画像也能做个性化。用户说“孩子三岁”系统就给这个会话打上“母婴”和“安全材质”两个临时标签用户说“明天急用”就打上“时效敏感”。临时标签只在本会话内有效不写库、不过度收集但已经足够支撑一次合理的推荐。历史订单可以作为扩展信号买过咖啡机的人推荐咖啡豆的接受度比无差别推荐高得多。这套做法既落地了会话级个性化又避开了用户隐私过度采集的坑审查角度也过得去。6. 售后对话没有试错空间客服链路的稳定性设计6.1 售后流程要用确定性规则兜底导购说错一句推荐词最多是用户不满意但售后说错退款时效、说错保价规则就可能引发真实纠纷。所以售后链路我坚持“知识检索规则模板大模型润色”的三明治结构。政策本体是规则模板大模型只负责把规则换成人话不参与政策判断。举例来说用户问“七天无理由退货运费谁出”系统先查政策库匹配到“七天无理由退货非质量原因买家承担运费质量原因卖家承担”的规则ID再由生成层改写成流畅的回复必要时附上退换货入口。整个过程中模型不能自己加“我们可以给补贴”这类承诺所有承诺必须来自配置好的政策表。6.2 转人工的四个硬信号客服智能体再聪明也不可能解决所有问题。我设计转人工的判断逻辑时设置了四个硬信号满足任何一条就立即优先转接用户情绪标签为高强度负面且连续两轮对话没有平复涉及赔付金额或争议权限超出政策库覆盖范围用户连续两次要求“找人工”或“投诉”智能体在同一个问题上连续给出不同答案被用户当场指出。转人工不是冷冰冰丢一句“正在转接”就完事。要先做交接摘要把用户当前诉求、已确认的信息、智能体尝试过的方案整理成一段记录让人工客服一接手就能接着聊。交接摘要原本是手工写的换成大模型生成之后人工客服的重复询问率明显下降这个优化虽然不起眼但特别改善一线的使用体验。6.3 承诺类信息的强校验大模型最常见的危险输出是“没问题明天一定能到”这类拍胸脯承诺。我在生成层外层加了一道承诺校验回复文本里如果出现“一定”“保证”“最快”“马上”这类高承诺词系统立即与库存、物流、政策数据逐项比对无法证实的表达直接拦截改写。为了避免模型绕过表层检测我还在拦截后追加了一轮“改写指令”强制生成层补充确定性的时间或条件。如果改写后仍不能通过校验就退到底层话术模板。这套安全网跑了一段时间后自由发挥导致的承诺事故基本归零线上客诉压力小了很多。7. 评测体系如何证明智能体合格7.1 场景化评测集设计不要只用一个泛化模板测准确率我按真实会话分布构建了三类评测用例。客服域覆盖订单、物流、发票、退款、保价等高频场景导购域覆盖比价、替代推荐、优惠计算、组合推荐等转化场景争议域覆盖投诉、情绪化表达、转人工请求。每类用例都带标准答案和可接受的边界答案不只测“答没答对”还要测“表达是否伤人、是否强硬、是否甩锅”。7.2 自动化指标与人工抽测结合自动化部分重点测四组指标意图路由准确率仲裁层把会话正确导向客服、导购或售后的比例知识命中率回复引用的政策或商品信息是否来自知识库承诺合规率回复中的高承诺词是否通过校验转人工质量交接摘要信息完整度与相关度。人工抽测部分则模拟用户连续多轮打断、换话题、情绪化表达。我把这轮抽测叫“醉酒测试”——让一个正常表达能力的人不断丢跑偏的问题给智能体看它能不能接住。跑偏一次记一次连续几轮跑偏就回去调仲裁规则。这个测试听起来土但比任何指标都更早暴露真实体验问题。7.3 线上指标与问题归因上线后重点看五类业务指标首次响应时长、解决率、转人工率、CSAT评分以及导购域特有的推荐点击率、推荐后加购率、推荐GMV。我把解决率作为北极星指标其他指标都围绕它做归因。这里有个陷阱转人工率降低可能是好事也可能是智能体在硬撑不转需要结合解决率和用户侧评分一起判断不能单看一个数字。我在灰度评测里发现过一个典型问题推荐点击率不低但推荐后加购率一直跟不上。复盘下来问题出在推荐理由总是强调“销量高”没有结合用户刚表达的具体需求。改成用用户原话里的需求词生成推荐理由后加购率才明显回升。这就是指标体系真正起作用的地方——数字不会直接告诉你答案但能告诉你去哪儿找答案。8. 落地过程中的几个大坑与绕行方案8.1 对话轮次一长记忆就开始漂移上线初期用户聊到十几轮智能体就开始忘记前面说过的话。用户明明说了“不要白色”后面却在推白色款用户刚说完已付款智能体又反问他是不是还没下单。这是上下文压缩策略没做好的问题。我的做法是引入会话状态摘要每轮只保留最近几条原始消息更早的内容定期压缩成结构化标签比如“用户偏好不要白色”“用户状态已下单未发货”“待办查询物流”。仲裁层优先读取标签而不是整段历史。这个改动之后长会话里的一致性明显改善用户也很少再纠正智能体了。8.2 商品参数幻觉没有彻底消除哪怕有了商品包装卡大模型在复杂对话里还是会把价格说错、把规格说错。后来我干脆把商品关键参数从生成环节剥离涉及价格、颜色、尺码、库存这类信息全部走查询接口拿到的结构化数据填充进回复模板大模型只负责写衔接和推荐理由。这样“说错价”的出现概率直接降到了很低的水平这也是我在项目里最推荐的一项改造。8.3 大促前必须做全链路压测很多客服系统死在高峰期。大促当天对话量可能是平日的十倍以上如果检索服务吞吐跟不上整条链路会雪崩。我当时花了大力气做容量评估按峰值QPS乘以单请求的检索耗时推算出需要部署的实例数并给动作执行层加了降级开关。大促时如果检索返回变慢先走规则兜底回复绝不让用户在等待里流失。这套预案听着基础真要等线上被打挂了再去处理损失就不是加班能补回来的了。8.4 人工反馈闭环要尽早建立智能体不是上线就结束上线之后才开始进化。每个转人工的会话、每个被用户打低分的回复都要回流到训练集和策略规则里。我的习惯是每周做一次失败案例复盘把高频问题条目补进知识库或调整仲裁逻辑。坚持三个月之后同样的会话错误率明显下降转人工率也稳定在可接受区间整个系统才算是真正“跑顺了”。我自己在推进这个项目时最大的感受是电商客服导购智能体难点从来不在“接一个大模型”而在于把意图、知识、策略、承诺、人工衔接这些环节拆得足够清晰并且每一步都有可验证的指标。文章里写的思路不一定适合所有业务但大方向是通用的——对话不是单选题客服和导购也不该是两个机器人。 
长河君 · 2026/10/19 14:01:01 · 阅读 1.2k 电商客服+导购智能体设计：从意图识别到推荐与售后落地
做电商客服智能化前几年大家普遍习惯把“售后客服机器人”和“导购推荐机器人”分成两个独立项目来做一个负责退换货、查物流、开发票一个负责推商品、发优惠券、做关联推荐。我一度也是这么设计的直到在线上会话记录里反复看到同一类对话——用户上一句还在问“这个还能便宜点吗”下一句就问“有没有价格差不多但更适合我的款”紧接着又来一句“那退货运费谁出”。这段话里同时带着议价诉求、替代推荐诉求和售后权益诉求。如果客服和导购分属两套系统用户就只能被来回踢皮球。这篇文章想聊的就是“电商客服导购智能体”从零设计到落地开发的全过程核心围绕意图识别、商品理解、推荐策略、售后兜底、转人工衔接这几条链路怎么串起来。内容偏工程落地适合正在做电商客服Agent、智能导购或者做售前方案的朋友参考。我不会只给结论会把每个设计决策背后的原因、踩过的坑、以及线上验证的结果一起说清楚。1. 为什么客服和导购必须塞进同一个智能体1.1 “能便宜点吗”这一句话里藏着三种意图我见过太多把意图分类做成单选题的方案系统判断不了就给用户回一句“请问您是咨询售前还是售后”。这种交互放在现在的电商环境里基本等于劝退。真实会话里用户的话往往是一句多义的组合拳拿“能便宜点吗”来拆里面至少有三种理解议价咨询这款还能不能降、有没有隐藏优惠替代寻找如果这款不能便宜有没有同价位更划算的选择售后权益我刚买完就降价能不能申请差价补偿。在独立客服机器人里这句话大概率被路由到“优惠查询”然后搬出一套标准话术在独立导购机器人里它又可能被当成购买信号硬推一个价格档位更高的商品。两边各答三分之一用户自然不满意。用户真正想要的是先知道当前商品有没有活动价如果没有再推荐一个性价比更合适的替代款最后顺便告诉他有没有保价政策。我在设计时把意图识别拆成了两层粗粒度路由决定“当前轮该由客服逻辑、导购逻辑还是售后逻辑主导”细粒度槽位抽取负责把价格预期、规格参数、承诺期限这类信息抽干净。两层共用一份会话状态这样“能便宜点吗”既能触发客服侧的优惠判断又能带出导购侧的替代推荐两者还能共享同一个上下文不会互相覆盖。1.2 对话历史是花钱都买不到的推荐信号导购推荐系统的经典痛点是不知道用户到底想要什么。注册画像冷冰冰标签也不准用户看到推荐第一反应往往是“这跟我有啥关系”。但会话历史里全是高价值信号用户说“孩子三岁要不容易摔碎的”这就是明确的材质偏好用户说“明天就要用”这是时效偏好用户说“之前买过你家另一款”这就是复购跨品类线索。如果客服和导购分开客服系统拿到的对话文本只能服务售后任务导购系统拿到的是另一批被截断的会话记录两边都缺上下文。合体之后同一个会话状态可以在意图路由和推荐策略之间流转。我在项目里做过一次对比实验在注入完整会话历史的情况下推荐被点击的效果比只看当轮query明显更好多轮上下文对转化带来的提升非常直观。这也是我认为“客服导购”不应该分开的根本原因——会话本身是连续的系统没有理由在中间切一刀。1.3 合并之后的成本和收益模型从成本角度看两套机器人意味着两套NLU服务、两套知识库、两套日志链路、两套转人工体系重复建设非常严重。统一成一套智能体后客服和导购共用意图模型和检索链路只是策略层多一张路由表。线上部署时也只需要在会话中间层做一次资源分配运维压力小很多。我当时算过一笔账假设日均会话一万拆成两套系统因为意图误判需要二次转移的会话比例大约在15%到20%。合并之后会话能够在同一套上下文里自然完成跨域处理因为转接导致的用户流失会明显减少。这个数字不同业务会有浮动但方向是一致的对话天然连续系统就不该被人为切割。2. 总体架构不是接一个大模型API就完事2.1 六层职能拆分一个能商用的电商客服导购智能体我习惯把它拆成六层接入层处理多渠道进来的消息统一会话ID、消息格式和时间戳意图路由层粗粒度识别当前场景输出客服、导购、售后、闲聊、转人工五类信号策略仲裁层结合会话历史、用户情绪、业务状态决定这一轮回复怎么走知识检索层对商品库、政策库、文档库做混合召回再重排动作执行层查库存、算优惠、创建售后单这类确定性操作生成与兜底层大模型生成自然语言规则引擎做合法性校验最后兜底回退到人格化话术。这里最容易被忽略的是意图路由层和策略仲裁层的区分。很多方案把意图识别和回复策略合在同一个Prompt里看起来省事实际上把“知道用户要什么”和“决定给它什么”混为一谈。意图分类用轻量模型就能做到低延迟高准确而策略仲裁依赖复杂上下文适合交给大模型综合打分。两者分开之后调试时能分别看出来到底是“没听懂”还是“听懂了但策略错了”这个区分对排障特别关键。2.2 一条消息从进入到回应的全链路用户消息进来后的完整处理路径是这样的先做标准化去掉无意义表情、处理同义词、识别商品链接或型号代码。然后并行跑三个任务意图分类、商品实体识别、情绪标签。这三个结果连同最近的会话摘要一起进入策略仲裁模块。仲裁模块决定的是回答策略而不是直接生成答案。如果仲裁结果是要查库存就走动作执行层调库存接口如果要解释售后政策就走政策知识库检索如果既涉及优惠又涉及推荐就生成一条“服务信息推荐理由”的组合话术。整个链路用工作流引擎编排每层都有可观测日志。我坚持不让大模型裸奔着直接回答所有问题因为在电商这种强业务约束的场景里自由生成的代价太高。2.3 选型判断快慢分流与索引先行模型选型上我推荐两条腿走路。快路径用一个小模型处理高频固定问题比如发票、物流状态、尺码表响应要快、成本要低慢路径用大模型处理复杂对话比如比价、组合推荐、情绪安抚类。我见过只接一个大模型的做法用户就问一句“查一下订单到哪了”都要等两三秒这种延迟放在电商客服里基本不合格。快慢分流之后简单问题的首次响应时长能压到一秒内复杂问题则保留模型的深度能力。检索层最常踩的坑是把商品数据表整张塞给模型当上下文。正确做法是给商品建一个专门的知识索引标题、参数、卖点、优惠规则分开存储召回时按用户实体过滤再交给生成层排序。这样既控制了token消耗也能在商品改价后只更新索引不需要重新部署模型。3. 商品理解与知识库建设导购能力的地基3.1 商品数据的结构化清洗导购智能体答得好不好七分靠数据。电商的商品数据通常是从上游进销存系统同步过来的标题又长又乱比如“夏季新款 女款轻薄休闲运动鞋 白色 36”这种。模型直接读这种原始标题根本分不清卖点是透气、轻量还是百搭。我在项目里加了清洗流程把标题切成品牌、品类、性别、颜色、尺码、卖点词再补上规格参数、库存状态、价格区间、运营配置的关联推荐位。清洗之后每个商品会生成一段标准化的商品摘要我习惯叫它“给模型看的包装卡”。包装卡里除了硬参数还会记录运营人工维护的卖点词和适用人群。没有这张卡让大模型从原始数据表里自由发挥十个回答里至少三四个会出现价格或参数幻觉用户一句“你这不是标价199吗”就能把对话拖进事故现场。3.2 三类知识库的定位差异我强烈建议把知识拆成三个独立索引不要混在同一个向量库里知识库典型内容更新频率召回方式售后政策库退换货规则、保价规则、运费说明、发票问题低版本化修改规则优先向量辅助商品知识库SPU摘要、卖点、库存、价格、优惠高每天变价关键词精确匹配向量排序会话记忆库用户偏好、未完成的订单意图、当前诉求实时写入结构化标签不参与向量检索分开存的好处是召回时能分别设置权重和过滤条件。售后问题只查政策库避免被商品信息干扰推荐场景只查商品库避免模型把售后话术当成卖点来造句。政策库我建议以确定性规则为主大模型只负责把规则翻译成人话绝对不能自己发明政策。3.3 向量检索与关键词检索的配合做知识检索时我一开始只上了向量检索结果发现一个典型问题用户问“这款手机有128G版本吗”向量召回容易命中一堆“存储空间大”的泛泛描述反而把精确参数漏掉。后来改成混合检索关键词命中优先向量相似度排序兜底。具体做法是给商品库维护一个关键词索引针对型号、颜色、容量这类硬参数做精确匹配向量库负责处理语义模糊的表达比如“适合通勤穿的”“送长辈的”。召回之后加一个重排环节按参数匹配度、价格接近度、库存可用性综合打分。这个改动比换更强的大模型更能实际提升导购效果因为问题大多出在召回精度上而不是语言组织上。4. 意图识别与模式仲裁什么时候卖货、什么时候服务4.1 意图分类的层级设计意图分类我采用两级落地。一级意图解决“现在是什么场景”导购、客服、售后、闲聊、转人工。导购场景下再细分商品咨询、比价、优惠计算、尺寸推荐、替代推荐客服场景下细分订单状态、物流、支付、发票售后场景下细分退换货、保修、退款进度、投诉。这里最大的教训是一级意图不要贪多。种类一多模糊表达就会互相抢。用户说“这个有货吗”既像导购也像订单咨询实际是库存查询。把它挂在导购下的“库存咨询”更合理因为核心动作是评估当前商品。类目之间要有明确的互斥规则否则训练数据里满是歧义样本模型越训越糊涂仲裁层也跟着失灵。4.2 模式仲裁不是简单的一刀切仲裁层解决的是多意图叠加时“先说什么、后说什么、用什么语气”。举一个真实场景用户“这个能便宜点吗” 仲裁结果当前商品无优惠先走服务话术表态“暂时没有降价”接着给一个替代推荐“不过同系列有一款正在参加满减我帮您对比一下”再追问是否要看细节。这句回复的本质是“客服式拒绝导购式引流”的组合。如果单纯走导购模式会显得太急着卖货如果纯客服模式对话就直接结束了转化机会也丢了。仲裁层在这里的工作是判断“拒绝了用户期待之后有没有替代方案”——有就给没有就诚恳道歉并准备转人工。我还加了一条强制规则当用户情绪分低于阈值或者对话已经进入售后投诉流程时推荐动作整体关闭。用户正在为质量问题生气智能体还在推新品这种体验不只是差还会严重损害品牌信任。4.3 人设与语气的分场景控制客服和导购的语气必须有区分度。导购人设可以热情一点多给选项多使用“我帮您对比”“这款更适合您”这类表达客服人设要稳先确认再答复少用感叹号必要时给出明确的服务承诺。实现上不靠每轮在Prompt里重复人设而是固定两套系统提示词由仲裁层按场景切换。我们还给生成层配置了风格约束客服模式禁止使用“超级划算”“错过等一年”这类销售话术导购模式则允许适度使用促销词。5. 推荐策略让导购像人而不是像硬广5.1 推荐时机比推荐内容更重要评测一个导购智能体最先看的就是它会不会在不该推荐的时候硬推。我统计过被用户直接怼回去的会话排在第一位的坑就是在售后场景里弹出商品卡片第二位是在用户问物流时推荐换购。所以系统里有一条硬性规则推荐动作必须与“用户表达偏好、用户在比价、用户在找替代、用户在凑单”这几个信号绑定其他情况默认不推。推荐也不是每次都必须抛出一堆商品。在犹豫型会话里给两个精心筛选的选项比给五个让用户选择压力小得多。我给策略里加了一个选项上限约束默认最多展示三款商品除非用户明确说“都看看”。这个约束看起来很傻但实际效果比想象中好用户不会被信息淹没反而更愿意继续聊下去。5.2 三种推荐逻辑与理由生成推荐逻辑我主要做三种同品替代用户问的款缺货或参数不满足推荐同品类中参数最接近、价格差异可控的商品互补搭配用户已选定主商品推荐配件、耗材、组合装价格区间迁移用户表示预算有限推荐价位更低但核心参数还满足需求的商品。但推荐动作之外更重要的是理由。每个推荐结果必须带一句“为什么推荐这个”的解释没有理由的推荐就是垃圾广告。理由的生成要引用商品的客观参数而不是空泛地说“这款也很好”。比如“您之前选的这款没有小号了同系列的另一款有您要的尺码重量还轻了二十克”这句话里有信息量用户才愿意往下看。5.3 会话内个性化的冷启动方案不做注册画像也能做个性化。用户说“孩子三岁”系统就给这个会话打上“母婴”和“安全材质”两个临时标签用户说“明天急用”就打上“时效敏感”。临时标签只在本会话内有效不写库、不过度收集但已经足够支撑一次合理的推荐。历史订单可以作为扩展信号买过咖啡机的人推荐咖啡豆的接受度比无差别推荐高得多。这套做法既落地了会话级个性化又避开了用户隐私过度采集的坑审查角度也过得去。6. 售后对话没有试错空间客服链路的稳定性设计6.1 售后流程要用确定性规则兜底导购说错一句推荐词最多是用户不满意但售后说错退款时效、说错保价规则就可能引发真实纠纷。所以售后链路我坚持“知识检索规则模板大模型润色”的三明治结构。政策本体是规则模板大模型只负责把规则换成人话不参与政策判断。举例来说用户问“七天无理由退货运费谁出”系统先查政策库匹配到“七天无理由退货非质量原因买家承担运费质量原因卖家承担”的规则ID再由生成层改写成流畅的回复必要时附上退换货入口。整个过程中模型不能自己加“我们可以给补贴”这类承诺所有承诺必须来自配置好的政策表。6.2 转人工的四个硬信号客服智能体再聪明也不可能解决所有问题。我设计转人工的判断逻辑时设置了四个硬信号满足任何一条就立即优先转接用户情绪标签为高强度负面且连续两轮对话没有平复涉及赔付金额或争议权限超出政策库覆盖范围用户连续两次要求“找人工”或“投诉”智能体在同一个问题上连续给出不同答案被用户当场指出。转人工不是冷冰冰丢一句“正在转接”就完事。要先做交接摘要把用户当前诉求、已确认的信息、智能体尝试过的方案整理成一段记录让人工客服一接手就能接着聊。交接摘要原本是手工写的换成大模型生成之后人工客服的重复询问率明显下降这个优化虽然不起眼但特别改善一线的使用体验。6.3 承诺类信息的强校验大模型最常见的危险输出是“没问题明天一定能到”这类拍胸脯承诺。我在生成层外层加了一道承诺校验回复文本里如果出现“一定”“保证”“最快”“马上”这类高承诺词系统立即与库存、物流、政策数据逐项比对无法证实的表达直接拦截改写。为了避免模型绕过表层检测我还在拦截后追加了一轮“改写指令”强制生成层补充确定性的时间或条件。如果改写后仍不能通过校验就退到底层话术模板。这套安全网跑了一段时间后自由发挥导致的承诺事故基本归零线上客诉压力小了很多。7. 评测体系如何证明智能体合格7.1 场景化评测集设计不要只用一个泛化模板测准确率我按真实会话分布构建了三类评测用例。客服域覆盖订单、物流、发票、退款、保价等高频场景导购域覆盖比价、替代推荐、优惠计算、组合推荐等转化场景争议域覆盖投诉、情绪化表达、转人工请求。每类用例都带标准答案和可接受的边界答案不只测“答没答对”还要测“表达是否伤人、是否强硬、是否甩锅”。7.2 自动化指标与人工抽测结合自动化部分重点测四组指标意图路由准确率仲裁层把会话正确导向客服、导购或售后的比例知识命中率回复引用的政策或商品信息是否来自知识库承诺合规率回复中的高承诺词是否通过校验转人工质量交接摘要信息完整度与相关度。人工抽测部分则模拟用户连续多轮打断、换话题、情绪化表达。我把这轮抽测叫“醉酒测试”——让一个正常表达能力的人不断丢跑偏的问题给智能体看它能不能接住。跑偏一次记一次连续几轮跑偏就回去调仲裁规则。这个测试听起来土但比任何指标都更早暴露真实体验问题。7.3 线上指标与问题归因上线后重点看五类业务指标首次响应时长、解决率、转人工率、CSAT评分以及导购域特有的推荐点击率、推荐后加购率、推荐GMV。我把解决率作为北极星指标其他指标都围绕它做归因。这里有个陷阱转人工率降低可能是好事也可能是智能体在硬撑不转需要结合解决率和用户侧评分一起判断不能单看一个数字。我在灰度评测里发现过一个典型问题推荐点击率不低但推荐后加购率一直跟不上。复盘下来问题出在推荐理由总是强调“销量高”没有结合用户刚表达的具体需求。改成用用户原话里的需求词生成推荐理由后加购率才明显回升。这就是指标体系真正起作用的地方——数字不会直接告诉你答案但能告诉你去哪儿找答案。8. 落地过程中的几个大坑与绕行方案8.1 对话轮次一长记忆就开始漂移上线初期用户聊到十几轮智能体就开始忘记前面说过的话。用户明明说了“不要白色”后面却在推白色款用户刚说完已付款智能体又反问他是不是还没下单。这是上下文压缩策略没做好的问题。我的做法是引入会话状态摘要每轮只保留最近几条原始消息更早的内容定期压缩成结构化标签比如“用户偏好不要白色”“用户状态已下单未发货”“待办查询物流”。仲裁层优先读取标签而不是整段历史。这个改动之后长会话里的一致性明显改善用户也很少再纠正智能体了。8.2 商品参数幻觉没有彻底消除哪怕有了商品包装卡大模型在复杂对话里还是会把价格说错、把规格说错。后来我干脆把商品关键参数从生成环节剥离涉及价格、颜色、尺码、库存这类信息全部走查询接口拿到的结构化数据填充进回复模板大模型只负责写衔接和推荐理由。这样“说错价”的出现概率直接降到了很低的水平这也是我在项目里最推荐的一项改造。8.3 大促前必须做全链路压测很多客服系统死在高峰期。大促当天对话量可能是平日的十倍以上如果检索服务吞吐跟不上整条链路会雪崩。我当时花了大力气做容量评估按峰值QPS乘以单请求的检索耗时推算出需要部署的实例数并给动作执行层加了降级开关。大促时如果检索返回变慢先走规则兜底回复绝不让用户在等待里流失。这套预案听着基础真要等线上被打挂了再去处理损失就不是加班能补回来的了。8.4 人工反馈闭环要尽早建立智能体不是上线就结束上线之后才开始进化。每个转人工的会话、每个被用户打低分的回复都要回流到训练集和策略规则里。我的习惯是每周做一次失败案例复盘把高频问题条目补进知识库或调整仲裁逻辑。坚持三个月之后同样的会话错误率明显下降转人工率也稳定在可接受区间整个系统才算是真正“跑顺了”。我自己在推进这个项目时最大的感受是电商客服导购智能体难点从来不在“接一个大模型”而在于把意图、知识、策略、承诺、人工衔接这些环节拆得足够清晰并且每一步都有可验证的指标。文章里写的思路不一定适合所有业务但大方向是通用的——对话不是单选题客服和导购也不该是两个机器人。