跑了几个月的电商智能体项目终于稳定上线了整个过程踩了不少坑也攒下了很多值得记录的经验。这个项目的核心目标并不复杂做一个同时承担售前导购和售后客服两个角色的智能体替代原来人工客服70%以上的重复咨询工作同时把只会回答问题的机器人升级成能主动推荐商品、能引导下单的导购助手。市面上大多数电商机器人只解决客服这一件事要么是关键词匹配的FAQ机器人回答生硬还经常答非所问要么是强规则流程的售前机器人用户稍微换个说法就聊不下去了。这次的项目从一开始就把客服导购放在同一个系统里设计而不是简单地在客服机器人旁边再挂一个推荐模块。这里面的关键差异在于客服侧重准确、合规、稳定导购侧重主动、引导、促成转化两者的目标函数是不一样的。我负责的部分包括整体技术选型、核心模块开发以及上线后的效果调优下面的内容完全基于这个项目的真实经验整理适合正在做电商AI应用、智能客服产品、或者想在企业内部落地大模型应用的开发者参考。1. 项目整体设计与需求拆解1.1 客服和导购两个角色为什么要放在一个系统里先看业务背景。电商场景里用户进店后的咨询可以粗略分成三类售前咨询尺码、材质、发货时间、售中决策对比款式、求推荐、犹豫要不要下单、售后问题物流、退换货、发票。传统做法是售前和售后分两个机器人但用户不会按照我们的分类来提问他们经常在问完这件衣服会不会起球之后紧接着问那你还推荐哪款再下一句就是不合适怎么退货。如果两个机器人数据不互通、会话不连续体验就会非常割裂。把客服和导购合并到一个智能体里核心思路是用一套对话系统覆盖用户从进店到下单再到售后的完整生命周期。系统内部依然有角色分工但对外是一个统一的会话入口。我负责整个项目的时候第一步不是写代码而是拉着业务方把所有用户咨询场景列出来按信息查询、商品推荐、交易引导、售后处理四个大类建了一个场景清单同时标注每个场景的预期解决方式、允许的自主程度、需要转人工的触发条件。1.2 功能边界什么时候该推什么时候该答合并设计听起来美好实际落地最大的难点在于控制智能体的主动性。客服场景要求克制、严谨你不能为了促成下单而谎称这个绝对不起球导购场景要求主动、积极不能用户问A款你只答A款完全不提关联商品。我们最终的边界规则是这样的用户明确询问售后政策、物流、退款时系统只做信息查询和流程引导禁止夹带推荐用户询问商品属性、规格参数时可以附带一句同类商品中B款也满足你的需求但不做强推用户表达选择困难、主动征询建议、或者正在对比多个商品时系统进入导购模式主动追问偏好、给出排序清单。这个规则在系统里的体现就是一个全局的行为策略层在每一次回复生成之前根据当前会话的意图和状态动态决定要不要调用推荐模块、推荐内容怎么呈现。一个完整的决策流程示意如下用户输入意图识别结果策略判断系统动作这款支持七天无理由吗售后政策查询禁止推荐只回复政策内容这件毛衣会起球吗商品属性咨询可附带推荐回复材质说明推荐同类商品我160100斤穿什么码导购咨询进入导购模式追问身型偏好推荐尺码哪个颜色卖得好销售信息查询可引导回复销量数据推荐热卖色1.3 技术选型LLM RAG 工作流编排而不是单一大模型确定了业务边界接下来是技术方案。我们评估过三种路线纯规则/关键词匹配、单一大模型直接对话、大模型检索增强工作流编排。纯规则方案排得最早原因很简单电商用户的表达太自由了有点脏了想退掉和我要申请退货完全是同一个意思但关键词能差出十万八千里。单一大模型直接对话我们也试过效果确实惊艳但问题也很致命模型不知道我们店铺的实际库存、不了解最新的售后政策拿私有数据无能为力还容易出现幻觉。最后确定的方案是LLM负责理解和生成RAG负责接入私域数据工作流引擎负责状态流转和外部动作。这三者的关系简单来说LLM是大脑RAG是记忆库工作流是手脚。模型选型上我们采用了一个比较实用的组合策略。一个轻量级的模型3.8B级别负责意图分类和关键信息抽取速度快、成本低主对话模型14B-32B级别负责最终回复生成保证语言质量和逻辑性。分类模型准确率实测能做到96%以上主模型生成质量经过两轮微调也能达到业务预期。组合策略比单一大模型直接跑降低了近60%的token消耗。2. 系统架构与核心模块设计2.1 总体架构接入层、AI层、业务层三层分离系统架构上我坚持三层分离原则这是后续能快速迭代的基础。接入层对接各个渠道包括网页客服窗口、微信小程序、独立App所有渠道统一走同一个消息网关把渠道差异屏蔽在系统之外。我们的消息网关做了两件事消息清洗和会话路由。消息清洗处理图片、语音转文本、表情包过滤会话路由根据用户ID和会话ID把消息分发到对应的会话处理线程。AI层是核心分为四个模块意图识别、实体抽取、状态管理、响应生成。意图识别负责理解用户想干什么实体抽取负责提取商品ID、尺码、颜色、订单号等关键信息状态管理维护整个会话的上下文和用户画像响应生成结合前三个模块的输出以及RAG检索结果组装最终回复。业务层则封装了所有需要调用的外部能力包括商品中心的商品查询接口、库存服务、订单系统、售后退款服务、物流查询API。这一层对AI层屏蔽了底层系统的复杂性AI层只需要声明我需要查库存业务层自动路由到对应的服务并返回结构化结果。2.2 意图识别不再是关键词匹配而是语义分类意图识别是整个系统的地基这一步错了后面做什么都白搭。我们采用的是小模型分类 大模型补充的双通道策略而不是单纯依赖某一个模型。小模型做首轮分类负责意图粗分到12个预定义类别。训练数据来自三个部分历史人工客服会话记录、业务方提供的标准话术、测试阶段收集的脱敏数据。我们用过去12个月的客服会话数据清洗后得到约8万条标注样本覆盖售前咨询、售后维权、闲聊寒暄、导购推荐等各类场景。小模型搞不定的边界情况交给大模型做二次判断。比如用户说你猜我想买什么这类开放性表达小模型很容易分到闲聊但大模型结合历史浏览记录能识别出潜在的导购需求。双通道的判断结果会通过一个置信度阈值合并小模型置信度超过0.9就直接采用否则走大模型补充分析。实际操作中意图识别最关键的技巧是意图分类的粒度要适中不能太粗也不能太细。太粗了比如只分能回答和不能回答两类后续的针对性处理根本无从下手太细了比如区分询问毛衣是否起球和询问卫衣是否起球分类模型需要爆炸级别的数据量收益却很低。我们最终的经验是控制在10-15个意图类别最合适。2.3 商品推荐与导购策略带约束的推荐才是好推荐导购模块的推荐逻辑和传统推荐系统有个很大的区别传统推荐系统优化的是离线点击率、转化率而对话式导购必须考虑对话自然度和用户实时表达的限制条件。用户说推荐一款200以内的卫衣不要太花哨系统需要提取出价格上限和风格两个约束然后到商品库召回符合条件的候选集。我们还接入了商品向量化检索用标题、品类、风格标签构造商品embedding在向量数据库中做相似度查询支持类似的还有哪些有没有其他颜色这类模糊匹配的推荐请求。推荐排序上我们采用了规则基座模型微调的两步走。第一步用强规则过滤把不符合用户明确约束的商品全部剔除这一步宁可漏掉也不能错给第二步用排序模型在候选集里按综合得分排序得分的计算方式是排序分 0.4 * 用户偏好匹配度 0.3 * 商品销量热度 0.2 * 商品相关性 0.1 * 毛利优先级用户偏好匹配度来自会话过程中逐步积累的画像比如用户提到过性价比宽松版型深色系都会作为偏好标签记录下来。这个排序公式不是拍脑袋定的我们上线前用历史会话做了离线回放对比了公式排序和人工推荐的相关性选了相关性最高的权重组合。2.4 售后客服链路转人工不是认输是必要的安全网售后处理是这个项目里最谨慎的部分。退款、维权、投诉这些都是高敏场景答错一句话就可能升级成客诉所以我们在设计售后链路时坚持能查的自动化要判的转人工这条原则。系统能自动处理的是物流状态查询、退换货政策说明、发票申请入口引导、常见售后问题FAQ。这些场景信息明确、流程固定即使系统理解有偏差也不会造成错误操作。系统不能自动处理的是用户明确表达不满、投诉产品质量、要求特殊处理。识别到这些情况系统会自动标记会话情绪指数并触发转人工流程。转人工不是简单的抛给客服而是把整个会话的摘要、用户情绪、已尝试的处理方案一并打包放到人工客服工作台的待办列表里让人工不用重复问一遍用户。情绪识别这块我们用了一个比较轻量的方案在意图识别模型基础上增加一个二分类输出区分正常咨询和负面情绪。训练特征包括文本内容、语气词、标点符号强度、连续追问次数。这个轻量方案的效果足够支持业务需要——我们设置的是只要负面情绪概率超过0.6就触发人工介入宁可多转也不能漏。3. 关键功能实现与实操细节3.1 提示词工程一个Prompt让模型分清客服和导购大模型应用里提示词工程是投入产出比最高的一环这个项目里我深有体会。我们的主对话模型走的是通用大模型API通过精心设计的System Prompt来控制角色行为。核心的提示词结构是这样的你是一个电商平台的客服和导购助手服务对象是进入店铺的用户。 你的基本职责 1. 准确回答用户关于商品、订单、物流、售后的问题 2. 当用户表现出购买意向时主动提供合理的商品推荐 3. 遇到无法解决的问题时礼貌告知用户将转接人工客服。 需要注意的规则 - 售后政策类问题必须基于给定的政策文档回答禁止自行推断 - 商品推荐必须基于给定的商品库信息禁止捏造商品详情 - 用户情绪激动时先安抚情绪再尝试解决问题必要时转人工 - 禁止做出任何超出自身能力的承诺比如保证不会起球 - 禁止编造折扣活动、库存数量等实时数据。 当前可提供的商品信息 {商品库检索结果} 当前会话上下文 {会话历史摘要}这个Prompt看起来简单但细节都在括号变量里。商品信息必须是结构化数据不能直接把整个商品库塞进去我们默认只填充当前对话相关的3-5个商品的摘要信息。关键的调优点是每次只聚焦一个回复动作不要在Prompt里同时放进十几个行为指令否则模型会陷入既要又要还要的混乱状态。我们的经验是系统指令控制在5-8条行为边界每条指令一句话讲清楚。3.2 RAG知识库商品资料和售后政策的私域数据接入通用大模型没有我们店铺的商品资料和售后政策RAG解决的就是这个问题。知识库的构建不是简单的文档导入整个链路包括知识切分、向量化、混合检索、重排序。知识切分是最容易被忽视却最影响效果的环节。商品详情文档我们按单品组织每个SKU一个文档块块内保留完整的商品描述、规格参数和售后说明。政策文档则按主题切分退换货规则发货时效发票说明各成一块避免把多个政策塞在同一段导致检索命中不聚焦。向量化采用的是通用中文Embedding模型向量维度768入库商品8000余件。实际检索时我们采用的是关键词召回 向量召回 重排序三段式混合检索BM25关键词召回保证精确匹配向量召回处理语义相似最后用一个重排序模型将两路结果统一打分取Top3作为最终上下文。重排序这个环节我认为是RAG效果的分水岭。没有重排序之前检索结果经常出现看着相关但实际对不上的问题比如用户问发货时间向量检索返回了发货地址的文档。加了重排序之后Top1准确率从68%提升到89%提升非常明显。3.3 工具调用查库存、下单、查物流的外部API接入智能体的智能很大一部分体现在能调用工具。我们这个系统接入了四个核心工具API商品查询、库存查询、订单查询、物流查询。本质上就是把大模型变成一个决策中枢它需要数据时发起工具调用而不是凭空生成。工具调用的实现方式是Function Calling。系统给模型声明了可用的函数列表包括函数名、描述、入参定义JSON Schema格式。模型根据用户对话内容决定是否需要调用工具、调哪个、传什么参。比如用户说这件T恤有黑色的吗模型先调用商品查询拿到这个商品的SKU列表再调用库存查询确认黑色SKU的实时库存最后结合两个结果生成回答。这里有一个实操上的硬经验外部API返回的数据必须先做结构化整理再喂给模型。我们的商品查询接口返回的是多级嵌套的JSON直接把原始结构塞进上下文会浪费大量token还容易让模型迷失在无用字段里。我们在业务层做了字段抽取只保留商品名、价格、颜色、尺码、库存状态、图片URL压缩成一行文本传入模型。此外超时处理也非常重要。外部接口偶尔会慢模型如果卡在工具调用环节会拖慢整个响应。我们给每个工具调用设置了5秒超时超时后系统自动降级为告诉用户网络繁忙请稍后再试而不是干等着报错。3.4 多轮对话管理与上下文状态跟踪多轮对话是客服系统的刚需用户不会一次说完所有信息。状态管理模块负责维护两类状态会话上下文和业务进度。会话上下文直接控制送入模型的token截断策略。我们采用的是一套摘要窗口的混合管理方案每轮对话结束后系统把当前轮的信息更新到会话摘要里摘要控制在一两百字送入模型时同时携带完整对话窗口最近4-6轮和长期摘要两头兼顾——马上要用的细节在窗口里看得到历史背景信息通过摘要保留。业务进度跟踪体现在更细的粒度上。比如售后退款流程是一个多步骤过程确认订单号、确认退款原因、确认退款金额、提交申请。系统维护了一个状态机当前处于哪个步骤、已经收集了哪些参数都记录在会话状态中。即使过程中模型答非所问业务层也能校验是否推进到了正确的状态。让我补充一个状态管理中容易踩的坑会话和用户维度要分开。我们刚开始把用户画像和会话摘要存在一起结果同一个用户隔了三天再进店系统还带着上次会话的推荐偏好推荐结果完全跑偏。后来改成两套存储会话级状态保留30分钟过期自动清空用户级画像长期保留作为导购推荐的长期依据。4. 效果评估与上线落地4.1 离线评估评测集构建不能只靠感觉差不多了大模型应用的效果评估是最容易糊弄也最不应该糊弄的环节。我们搭了一套离线评测体系用真实对话数据构造评测集每个会话标注标准答案和关键指标每次修改Prompt或调整策略后批量跑评测对比效果。评测集我们从历史客服用例中抽取了600条对话场景覆盖12个意图类别同时标注了每条的答案类型是确定性回答还是开放性推荐。评测指标包括指标含义目标值意图准确率首轮意图分类是否正确 95%关键信息提取准确率商品名、订单号等实体是否正确 92%回答可接受度人工打分1-53分以上为可接受 90%幻觉率回答中是否存在编造事实 3%转人工准确率该转人工时是否触发转人工 99%评测过程还有一个容易忽略的点是回归测试。改一版Prompt可能导购效果提升了但售后政策回答开始出现幻觉。我们的解决方式是每次改动后跑全量评测集对比各指标的变化幅度任何一项指标下降超过2个百分点就不允许上线。4.2 灰度上线与人工兜底机制系统开发完成后并没有直接全量上线而是经过了三轮灰度验证。第一轮是内部测试让业务团队扮演用户对话目的是找明显的流程漏洞第二轮是模拟会话压测用500路并发验证系统稳定性和响应时间第三轮是在真实流量中按5%的比例切流试运行持续观察一周。灰度期间我们执行了一个硬性原则任何一条用户消息如果智能体不能确定自己的回答是正确的就自动转人工。这种宁可转人工也不能误导用户的策略虽然在灰度期让人工压力比较大但换来了极高的用户满意度。总体试运行数据显示智能体的自主解决率达到了72%成功拦截了大部分重复性咨询剩余的28%转人工里用户对转接过程的满意度评分反而比纯人工时代更高因为系统已经在转接前帮用户做了信息预整理。4.3 数据回流与持续优化上线不是终点是样本收集的开始智能体系统的优化是个持续迭代的过程依赖的是线上真实流量的数据回流。我们对每次自动回答都做了两个动作记录答案内容、让用户对答案进行有用/无用的隐式反馈包括用户是否继续追问、是否点击了推荐链接、是否在回答后离开会话。这些信号合在一起能比较准确地判断这轮回答的质量。每积累到一定量级的新数据项目组就做一轮数据分析和场景复盘。复盘的重点是寻找系统应该做好但没做好的case然后针对性地补充训练数据、修改Prompt、增加知识库文档。项目上线三个月后自主解决率从72%提升到78%平均会话轮数从5.8轮降低到4.9轮这两个数据说明用户一次会话解决问题的比例在持续上升。另外一个迭代方向是冷启动期的新商品适配。新品上架时缺少销量数据和用户反馈推荐排序会倾向于旧品。我们的应对策略是给新品一个基础分加成保证至少有曝光机会后续根据点击转化数据逐步恢复正常排序。5. 常见问题与排查技巧实录5.1 意图误判导致答非所问最常见的故障现象是用户在问售后系统一直在做商品推荐用户体验极差。排查思路是这样的第一步看意图识别的原始置信度。打开日志找到该轮对话的分类结果和各类别的概率分布。如果最高概率类别和实际意图不符说明训练数据中该类别的样本覆盖不足。第二步是看用户的语言表达是否过于口语化或存在错别字这会导致小模型分类失败。第三步是看是否出现了前后文干扰用户在上一轮说了导购相关的内容这一轮话题转移到售后状态管理没有正确切换到新意图。解决方案分两种。短期方案是维护一个高频易错话术表在意图识别层面对这些特殊句式做规则兜底比如不要推荐了直接告诉我能不能退这种句子直接强制映射到售后意图。长期方案是定期从误判日志里采样补充训练数据重新训练分类模型。5.2 模型幻觉导致错误商品信息这个问题的严重程度排在所有故障第一位。模型编造商品参数、虚构折扣信息是最危险的。我们处理幻觉问题有四个手段一是知识库强约束引用的商品信息必须在检索结果中可见Prompt中明确禁止回答不在信息列表中的商品详情二是低温度采样把temperature从默认的0.9调低到0.3显著减少了自由发挥的概率三是幻觉检测层用一个独立的小模型对最终答案进行校验检测答案中的数字、属性、政策条款是否能在输入的检索上下文中找到依据四是对售后政策类回答强制使用语义固定的生成方式即从知识库原文中抽取答案再组装而不是让模型自由组织语言。经过这四层手段叠加上线后的幻觉率从初期的8%降到了2%以内达到了业务可接受水平。5.3 响应延迟过大电商场景对响应速度的预期是2秒内超过5秒用户基本就离开了。我们曾经踩过响应时间不稳定的大坑排查后定位到两个核心因素模型推理时间和外部API调用时间。针对推理时间我们做了模型分级策略。简单意图如订单查询、物流查询直接走轻量模型生成速度和成本都远优于大模型只有复杂对话如多轮导购推荐、疑难售后才调用主模型。这轮优化把平均响应时间从3.8秒降到了2.1秒。针对外部API瓶颈我们给商品查询和库存查询加了进程级缓存。热门商品近一小时内被查询超过10次的直接从缓存读取缓存数据每30秒与商品中心同步一次。库存数据相对实时性要求并不高30秒的延迟完全可接受。物流查询则是按订单维度缓存5分钟因为第三方物流接口的响应经常超过3秒频繁调用风险很大。5.4 多轮对话上下文丢失上下文丢失的表现是用户上一轮刚说过我要黑色这一轮问那现在下单多少钱系统竟然不知道用户要的是黑色那款。这个问题的根源基本都在上下文管理模块。我们的排查经验是先在日志里检查这一轮请求拼装给模型的上下文字符串看会话摘要和对话窗口是否按预期包含了前一论的信息。如果摘要里没有关键信息说明摘要生成逻辑漏掉了实体信息抽取的环节——摘要的生成必须突出商品、属性、数量、订单号等业务实体而不是复述用户的完整句式。另一个常见原因是会话超时机制设置有误。我们有个版本的代码把会话级状态的过期时间设置成5分钟用户看了会儿商品详情再回来提问系统已经忘了上一个话题。后来调整策略用户主动进入会话视为会话开启更新状态的时间戳只有超过30分钟没有交互才判定会话结束。5.5 常见问题速查表现象可能原因排查方向解决方案答非所问意图误判查看意图分类置信度补充易错样本增加规则兜底编造价格/库存模型幻觉检查答案来源引入幻觉检测层降低温度响应超时模型推理慢/API瓶颈分级查看各环节耗时模型分级、加缓存上下文丢失摘要遗漏/过期清理检查上下文字符串强化实体抽取调整超时重复推荐同款推荐排序固化检查排序权重加入随机探索策略售后转人工失败情绪识别漏检检查情绪分类结果调整阈值增加触发条件写在最后的一点体会这个项目做下来我最大的感受是做一个能用的电商智能体不难难的是做一个业务方敢放手、用户愿意聊的智能体。技术上无非是模型选型、Prompt工程、RAG、工具调用这些组合拳真正拉开差距的是对业务边界的理解和细节的打磨——什么时候克制不推荐、什么时候主动引导、哪些话术绝对不能碰这些规则沉淀比模型参数本身更值钱。如果让我给后来者一个最务实的建议不要一开始就追求大而全的功能矩阵选一个高频场景比如售前尺码推荐售后物流查询先跑通把质量基线做稳再逐步扩展场景。每一次扩展功能时都要重新审视行为策略边界因为加一个推荐模块可能带来十个新的幻觉风险点。还有个值得分享的扩展方向是多模态客服能力。用户经常发商品截图问这款有吗目前我们只能通过OCR识别图片里的文字无法理解图片中的款式信息。下一期计划引入多模态模型直接理解图片内容并匹配商品库这应该能再解决一批高频用户问题。做智能体就是这样每解决一个问题就会看到新的问题在前面等着这也正是这个方向最有意思的地方。