电商客服这四个字前几年基本等同于“自动回复加工单系统”用户问十句能答上三句就算不错剩下全靠人工兜底。今年我们团队把客服机器人往导购智能体方向重构了一版做了一套能真正参与售前转化的对话系统。这篇文章就围绕这套电商客服导购智能体的设计思路和落地过程把整体方案、关键模块、提示词设计以及实测阶段踩过的坑完整过一遍。它不是什么学术报告是实打实的项目复盘。这套系统能干的事不只是机械回答活动、物流、退换货而是从用户第一句话开始判断购买意图、抽取需求约束、推荐合适商品在用户犹豫时给出对比方案甚至能做最后一步的追单。售前咨询这个环节过去最吃人工经验现在大部分可以由智能体接住人工只处理高价值、高复杂度或高情绪的场景。想了解大模型怎么落地到电商场景的同学或者正在评估“智能客服到底能做到什么程度”的团队都可以对照这篇内容做一次整体设计排查。1. 为什么要把客服机器人升级成导购智能体定位与业务价值1.1 售前咨询被浪费是最常见的隐性损失大多数店铺的客服资源都集中在售后因为售后问题处理不好会有差评、退款、投诉售后团队不敢放松。但售前咨询恰恰是最有价值的一环用户在这个阶段问“这个和那个有什么区别”“我适合哪一种”说明他已经进入决策窗口就差有人帮他确认一下。这个窗口里如果只回一句“亲您的问题我们已记录工号X为您服务”基本等于把订单送给同行。我们之前统计过某店铺的工作量分布售前咨询只占整体会话量的大概两成但这部分用户的下单意愿是最高的晚班期间响应稍慢页面跳出率就会明显往上走。问题的本质是客服系统和商品销售系统长期是割裂的。客服机器人能回答退换货政策但不知道用户想要什么商品商品推荐系统能根据点击和行为猜测偏好但无法理解用户自然语言里那句“有没有轻一点的”。导购智能体要解决的正是这个断层把一个原来属于成本中心的咨询入口变成有销售能力的转化入口。一句话总结就是让机器人不但会接话还会接单。1.2 智能体需要覆盖的三类核心用户需求第一类是知识解答型用户问“这个手机的电池容量多大”“发货到某地要几天”这类问题核心是准确和快答案来自结构化数据和FAQ重点在设计知识检索和快速回复流程。第二类是需求分析型用户说“我想给爸妈买个血压计要操作简单的”系统要从这句话里抽出受赠对象、产品品类、功能偏好然后匹配库存中满足条件的商品最后给出一个主推荐。第三类是决策辅助型用户已经在两个SKU之间纠结“A和B买哪个好”这时要能拿到两个商品的参数差异针对用户的使用场景给出选择建议甚至要能接住“有点贵”“我再看看”这种犹豫话术。三类需求在会话中是会切换的这也是为什么不能做成三个独立机器人而要做状态还能变动的智能体。用户可能先问商品参数再问物流时间然后问“和另一家比哪个好”最后又转到“算了太贵了”。如果系统只能在一个固定场景里工作这种会话流转会让用户反复重述需求体验非常差。我们的做法是不区分独立入口统一走同一个对话模型只是通过内部状态机在客服和导购两种模式之间切换。1.3 能力边界划定哪些场景必须快速转人工再强的模型也有不能碰的场景。我们在系统上线前就明确画了一条线情绪激烈的客诉、涉及退款金额争议、用户明确要求找人工以及涉及身体安全、医疗、使用风险的咨询全部直接转人工。这里宁可转错不可不转。让智能体硬接这类问题的后果是模型可能会给出过度承诺比如“过敏包退”“出问题全赔”这样的话一旦兑现不了客诉会升级到平台层面远比转人工更麻烦。另外一个容易被忽略的边界是客服权限。导购智能体可以推荐商品但不能随意修改订单、不能承诺赠品也不能擅自给优惠券。系统里所有涉及优惠和订单状态的操作都只走标记为“待人工确认”的动作不直接在会话中执行。把边界写进系统提示词还不够必须在工作流层配置硬校验避免模型生成的指令绕过限制。边界划得清楚智能体才敢放手做导购因为你知道最坏的情况不会失控。2. 技术选型与整体架构模型、知识库、工作流怎么搭2.1 大模型选型先用通用底座跑通再按需微调我们这个项目没有上来就微调模型。第一版直接用了国内商用大模型的API配合提示词工程和RAG把整条链路跑通跑了一两个月之后才根据会话日志决定要不要对意图识别做轻量微调。这样做的原因是电商客服的话术迭代速度非常快今天的爆款话术下周就失效微调模型的样本收集和训练发布周期根本追不上运营策略的变化。通用大模型底子够我们对它做的其实是“约束”而不是“训练”。选型主要看四个点中文理解能力、长上下文支持、工具调用的稳定性还有按量计费的价格。中文理解能力决定客服语气的自然度长上下文决定多轮对话能承载多少信息工具调用稳定性能不能可靠触发查询动作。实际跑下来四个选型里最影响体验的其实是工具调用的稳定性模型偶尔会把参数名改成相近但不存在的字段这个问题在代码里要加容错。项目选型考虑备注中文能力客服口语和网络用语较多需要覆盖省略语和常见错别字上下文长度多轮会话平均5到8轮配合裁剪和摘要不必追求最长工具调用需要稳定触发商品查询优先看评测集上的成功率成本按Token计费夜间可切便宜档位2.2 知识库设计结构化商品数据与问答语料分开处理商品数据最大的特点是“静态描述”和“动态状态”混在一起。商品名称、规格、参数、卖点是相对静态的适合做向量化价格、库存、活动折扣是动态的不适合放向量库因为向量检索是近似匹配它有可能把昨天已经过期的价格捞出来然后模型照着一本正经回答用户。我们采用的是分层知识库。结构化层存放SKU主数据、类目、规格参数、实时库存和价格通过确定性查询接口访问。向量层存放商品文案、详情卖点、FAQ、历史高质量客服回答。检索时先根据用户的品类关键词定位候选SKU再对非结构化知识做向量TopK取回最后把两部分内容一起塞给模型。这个顺序很重要如果先模糊检索再结构化过滤容易把相似但不同款的商品混在一起。知识时效性要单独摘出来讲。活动价格改价后旧知识如果还在向量库里极大概率造成报价错误。我们在写入向量库前会对商品文案做一次“时效标记”比如带上了“活动结束时间”的知识每次召回时计算是否过期过期内容直接丢弃。库存也是同理必须实时查绝不能让模型用记忆回答库存相关问题。这个设计看似简单但它拦住了不少让用户暴怒的低级错误。2.3 工作流编排用大模型做路由用确定性代码做执行对话系统的编排我们最开始用过比较重的工作流框架后来发现核心链路并不复杂就改成轻量状态机加函数调用的组合。整体流程是接收用户消息做意图识别更新会话状态根据状态决定调用哪个工具把工具结果拼到上下文再交给大模型生成回复。意图识别和话术生成这两步用模型解决工具调用和数据读取全部走确定性代码。这样设计是为了防止模型在关键操作上“自由发挥”。我们预置了四个核心工具商品检索、库存与价格查询、订单查询、优惠活动查询。每个工具都有明确的输入输出协议。比如商品检索只允许传品类、预算范围、应用场景三个参数模型传来的多余参数会被工作流层忽略。还有一点系统不让模型直接生成SQL也不允许模型自己修改订单状态所有状态变更动作都先变成“待人工执行项”由后台任务统一处理。这样即使模型输出有误也不会造成数据污染。下面给一个简化的工具定义示例{ tool_name: search_products, description: 根据用户的品类、预算、场景关键词检索可售商品, parameters: { category: {type: string, required: true}, budget_min: {type: number, required: false}, budget_max: {type: number, required: false}, scene: {type: string, required: false} }, return_fields: [sku_id, name, price, main_image, params, stock_status] }实际请求时模型按照这个协议返回参数工作流层做参数校验后再去查数据。对不齐的字段直接丢弃并记录一条日志方便后续调整提示词。这里有一个经验宁可让模型少传参数也不能允许它编造参数。3. 核心模块实现意图识别、需求抽取与导购策略3.1 意图识别模块分类标签加置信度门槛意图识别是整条链路的第一道闸门。我们设计了一套比较克制的标签体系一开始只分了七个标签售前咨询、参数询问、比价、售后、退换请求、抱怨、闲聊。标签太少会糊比如“哪个好”和“这个怎么用”如果归成一类后面策略就乱了标签太多模型容易混淆维护成本也高。七个标签在实测里准确率能稳定在九成左右。模型输出格式固定为JSON包含意图标签和置信度。代码解析时做一个硬判断置信度低于0.6不允许进入对应分支而是统一走澄清话术比如“你是想了解这两款的区别还是想知道怎么选更适合你”这样虽然多了一轮但避免了在用户意图不明时乱推荐。另外很重要的一点意图在会话中是可变的用户聊着聊着可能会从“比价”变成“售后”所以每次对话更新状态机时必须重新做意图识别而不是只会第一轮判断一次。{ intent: compare_products, confidence: 0.83, entities: { product_a: 无线耳机A, product_b: 无线耳机B } }3.2 需求抽取与动态追问从对话里拼出结构化条件导购推荐要想做得让用户觉得“这机器人懂我”前提是把用户的话转成结构化条件。用户说“我想买个无线耳机主要跑步用预算三百左右”我们内部会抽成类似这样的对象品类是耳机场景是运动预算是300元区间。抽取不靠正则而是用大模型加提示词约束但从模型拿回来的结果必须再做一次字段校验预算不能落在负数场景必须映射到预置的枚举值里。聊天里不可能一次把条件问齐。如果用户只说品类没说预算和场景系统不会一次性追问三个问题而是按照对推荐结果影响最大的顺序一次只问一个。先问预算还是先问场景我们的经验是优先问“使用场景”因为场景决定功能取舍而预算决定档位。先问场景会显得更自然比如“这款耳机有几种佩戴方式你是主要运动场景还是通勤场景”先问预算相对生硬实际体验中用户对先问场景的接受度明显更高。下面是抽取结果和追问流程的简化示意第一轮用户说“要个蓝牙耳机”抽取结果只有品类耳机场景和预算未知系统追问主要用在哪里运动、通勤还是玩游戏第二轮用户答“跑步和通勤都用”场景运动/通勤预算仍未知系统追问你心里大概的预算档位是多少三百和八百的挑选方向差挺多第三轮用户给出预算后系统才开始推荐候选商品这个流程跑下来比拿到一句话就立刻推荐的效果好很多。因为用户在给出完整约束之前推荐结果大概率是不准的不准一次后面要花三五轮才能拉回来。3.3 导购策略与话术模板克制推荐比全量推销更有效候选商品的选择逻辑不是“把所有相关商品都列出来”而是从符合硬条件的结果里挑三个以内主推其中一个。我们对结果按一个简单的综合分排序分数由三个信号组成商品与用户场景的匹配度、价格在预算区间内的位置以及同类商品的历史咨询转化率。匹配度和价格是实时算的历史转化率来自离线统计每天更新一次。对比话术我们沉淀了一个固定结构先复述用户需求再给两个到三个候选然后说清楚为什么主推其中一个最后留一个“是否进一步对比”的口子。复述需求特别重要它让用户确认系统没有理解偏。比如“按你预算三百左右、跑步通勤两用的需求我比较推荐A它的佩戴稳固性在这个价位里做得比较好如果降噪优先级更高B会更合适。”这样用户接收到的不是参数轰炸而是一个贴近自己场景的判断。犹豫信号也要单独识别。用户说“再看看”“有点贵”“我再想想”这类话不能当作普通闲聊跳过。我们设置的策略是先承认价格敏感再提供一个能降低决策门槛的信息点比如“这款平时价格在四百多现在领券之后是三百出头如果担心不合适有七天无理由可以先买回去试”。追单不是无脑发券而是帮用户把最后的决策负担减掉一点。同时要对推荐次数做抑制同一个会话里最多做两轮商品推荐超过之后就不再主动推新品避免用户产生被轰炸的感觉。4. 提示词工程与多轮对话体验控制4.1 系统提示词模板角色、边界、输出格式一次定清楚提示词在客服系统里不是写一段就完事而是要反复改。我们第一版提示词给得太开放模型经常说出一些漂亮的场面话比如“我们一直在努力为您提供更优质的服务”听起来很官方但在客服场景里非常冗余。后来把系统提示词收敛成了四个部分角色定义、任务清单、知识使用规则、安全与转人工边界。下面给一个简化了的模板这个模板经过多轮迭代后基本定型你是某电商平台的售前客服兼导购助手。 你的任务 1. 回答商品、物流、活动相关问题回答必须基于提供的知识内容。 2. 当检测到用户有购买意向时可引导需求但不要连续推荐超过两次。 3. 对无法确认的内容如实说明需要进一步核实不要编造价格、库存或功效。 知识使用规则 - 只能使用“当前会话知识”字段中的内容回答商品细节。 - 如果知识内容带有时效标记且已过期参考最新的活动查询结果。 - 不要输出知识内容中不存在的承诺。 安全边界 - 涉及退款金额争议、投诉情绪激烈、用户要求人工时回答“我帮你转接人工客服”并触发转人工动作。 - 不要承诺赠品、补偿、包赔等未经确认的权益。 输出要求 - 回答用自然的中文口语不用敬语堆砌。 - 一次回复不超过150字推荐场景可到200字但不超过。 - 不要主动编造用户的购买意图。每个部分都有它的作用。角色定义限定语气任务清单防止模型跑偏到闲聊知识使用规则压住幻觉安全边界处理兜底场景。输出要求里的“一次回复不超过150字”很关键大模型天生话痨不限制字数客服回复会变成小作文用户根本读不完。这个模板看着简单但每一条都是从真实失败案例里反推出来的。4.2 客服人格与导购人格怎么平滑切换同一个系统里其实有两个人格客服人格和导购人格。客服人格偏向准确、克制、中立用户问什么答什么不夹带额外推荐导购人格相对热情会在回答中主动关联用户需求并给出建议。这两个人格不能随机切换否则用户会觉得对面这个人精神分裂。我们用会话状态里的一个字段控制当前人格默认是客服人格只有当意图识别命中“售前咨询”且系统抽到了至少一个硬约束条件时才切换到导购人格。人格切换还要注意过渡话术。突然从“您的问题已记录”跳到“我推荐这款”会非常生硬。我们的做法是在导购动作之前加一句自然的连接比如“这个问题确实很多人问顺便说下如果你的场景是通勤为主最近有一款在促销参数上更贴合你的情况”。这句话既承接了用户的问题又给了推荐一个合理的由头。实测下来用这种过渡的会话比直接推荐的方式用户继续回复的意愿高不少。4.3 上下文管理窗口裁剪加关键信息持久化多轮会话有一个很现实的问题上下文窗口有限又不能无限塞历史消息。会话超过七八轮之后早期的信息容易被挤出去但其中可能正好有用户说过的预算和偏好。我们做了两层处理。第一层是窗口裁剪只保留最近几轮完整消息更早的消息压缩成一段摘要放进上下文的开头。第二层是把结构化信息单独存需求抽取的结果、意图状态、用户已看过的商品列表都放在会话状态对象里每次请求重新组装上下文时优先把结构化状态拼进去而不是依赖模型从原始对话里重新理解。比如用户第六轮问“之前说的那款还有别的颜色吗”如果第五轮已经把推荐商品写进会话状态系统可以直接查状态返回商品信息不需要模型去翻前面的消息。这类结构化持久化对成本和准确率都有帮助既减少模型需要重新推理的内容也防止遗忘。隐私方面会话状态里不存手机号、地址这类敏感字段用户标识用内部脱敏ID行为数据关联基于授权和明文脱敏两层处理这个在合规上不能省。5. 实测中踩过的坑与排查办法5.1 商品参数幻觉模型一本正经胡说八道项目上线两周左右我们遇到一个最典型的幻觉问题用户问某款手机的电池容量模型给出的数据和商品库里差了两百毫安。排查之后发现原因不是模型没有知识而是它根据训练语料里的记忆“发挥”了根本没有调用检索工具。从那之后我们在工作流层加了一个硬约束凡是涉及商品参数、价格、库存的回答必须在格式化输出中带上对应的SKU标识如果没有SKU标识这条回复不允许直接发给用户。这种约束要双层生效。提示词层写“只能基于检索结果回答”工作流层做校验检测到参数类问题但模型输出缺少依据时强制改成兜底话术。兜底话术是“这个参数我需要帮你确认一下稍等”然后转人工或走异步查询。虽然偶尔会让用户觉得机器人不够聪明但相比一本正经说错数据宁可慢一点也不能错。参数类回答的准确性是客服信任的底线错一次这个号基本就丢掉了。5.2 推荐太生硬用户没说要你非推给他灰度期间有一批用户反馈“这个机器人怎么唠唠叨叨一直推东西”原因是早期版本只要识别到商品关键词就进入导购人格每轮回答末尾都加上一句推荐。用户明明只是想查物流系统非要推荐新品体验非常差。后来我们砍掉了这个“逢问必推”的策略把触发条件改成有商品关键词、有明确的购买或比较意图、至少抽到一个决策相关的约束条件三者同时满足才允许进入导购模式。同时加了一个会话级别推荐次数限制每个会话最多推荐两轮且第二轮推荐必须发生在用户主动追问对比之后。这个限制写在提示词里也在工作流层做了计数器。模型输出内容里如果检测到推荐类话术但计数器已超限该句话会被过滤掉改成一句纯客服回复。这个改动上线之后负面反馈明显下降售前咨询的转人工率也降了一点说明用户更愿意继续和机器人聊下去。5.3 成本和性能平衡缓存、裁剪、限流三板斧成本是大模型应用绕不开的问题。我们做了三件比较有用的事。第一是FAQ级别缓存用户问同样的问题如果命中缓存直接返回不再走模型。像“发货到某地要几天”“怎么退换货”这类重复度极高的问题缓存命中率能做到三成左右直接省下了对应的模型调用量。第二是输入裁剪每次请求前动态计算当前上下文长度把不必要的历史日志裁剪掉只保留摘要和结构化状态。第三是输出限制把回复最大tokens尽量往低压客服场景的回复普遍不需要太长这项直接压低了每会话的模型成本。还有一个经验高峰时段和低峰时段的模型档位可以不一样。白天咨询量大用响应更快的模型档位保证体验晚上咨询少时切换到成本更低的模型档位整体成本能降下一截。限流方面我们给每个会话打了预算单次会话模型调用超过一定次数就强制转人工防止个别用户长时间刷对话把成本拖高。这套组合拳跑下来整体模型成本比最初版本降了三分之一左右而且用户侧体感变化不大。5.4 效果评估和灰度上线先看转人工率再看转化率系统上线前我们定了几个核心指标意图识别准确率、知识命中率、售前转人工率、售前咨询转化率、用户满意度。意图识别准确率通过人工抽检会话日志来评估每类意图抽几十条看判断是否符合知识命中率看多少轮回答能从知识库里找到依据售前转人工率反映系统兜不住的比例售前咨询转化率是最终的业务指标用咨询过智能体的用户是否下单来衡量。灰度策略上我们是分两步走的。先放5%流量观察稳定性和转人工率这一步主要看有没有严重问题比如回复格式异常、模型频繁报错。稳定之后再扩大到20%这时候才看转化率等业务指标。看转化率要多留一个心眼活动期间的数据噪音很大不能直接把某周的转化率变化归因于智能体上线最好拉同周期、同品类、同活动力度的对照组做比较。我们当时的做法是同一时间段内随机分配用户到新旧两套系统对比他们的售前转化率这样得出的结论才相对干净。这个项目做下来我最大的体会是技术选型其实没有想象中那么难真正难的是把“业务边界”和“知识质量”这两件事提前想清楚。模型再强商品数据是脏的回答还是会翻车推荐策略再精细用户没有购买意愿时硬推体验也会崩。如果让我重新做一遍我会把更多时间花在数据治理和对话状态设计上而不是一开始就去比较各家大模型参数。最后再分享一个小技巧在灰度阶段把用户不愿意继续对话的会话单独拉出来听一遍比看任何转化率数字都更能发现问题那些沉默的会话往往才是系统真正漏掉的机会。 
长河君 · 2026/10/20 13:43:11 · 阅读 1.2k 电商客服机器人如何升级为导购智能体：方案与落地复盘
电商客服这四个字前几年基本等同于“自动回复加工单系统”用户问十句能答上三句就算不错剩下全靠人工兜底。今年我们团队把客服机器人往导购智能体方向重构了一版做了一套能真正参与售前转化的对话系统。这篇文章就围绕这套电商客服导购智能体的设计思路和落地过程把整体方案、关键模块、提示词设计以及实测阶段踩过的坑完整过一遍。它不是什么学术报告是实打实的项目复盘。这套系统能干的事不只是机械回答活动、物流、退换货而是从用户第一句话开始判断购买意图、抽取需求约束、推荐合适商品在用户犹豫时给出对比方案甚至能做最后一步的追单。售前咨询这个环节过去最吃人工经验现在大部分可以由智能体接住人工只处理高价值、高复杂度或高情绪的场景。想了解大模型怎么落地到电商场景的同学或者正在评估“智能客服到底能做到什么程度”的团队都可以对照这篇内容做一次整体设计排查。1. 为什么要把客服机器人升级成导购智能体定位与业务价值1.1 售前咨询被浪费是最常见的隐性损失大多数店铺的客服资源都集中在售后因为售后问题处理不好会有差评、退款、投诉售后团队不敢放松。但售前咨询恰恰是最有价值的一环用户在这个阶段问“这个和那个有什么区别”“我适合哪一种”说明他已经进入决策窗口就差有人帮他确认一下。这个窗口里如果只回一句“亲您的问题我们已记录工号X为您服务”基本等于把订单送给同行。我们之前统计过某店铺的工作量分布售前咨询只占整体会话量的大概两成但这部分用户的下单意愿是最高的晚班期间响应稍慢页面跳出率就会明显往上走。问题的本质是客服系统和商品销售系统长期是割裂的。客服机器人能回答退换货政策但不知道用户想要什么商品商品推荐系统能根据点击和行为猜测偏好但无法理解用户自然语言里那句“有没有轻一点的”。导购智能体要解决的正是这个断层把一个原来属于成本中心的咨询入口变成有销售能力的转化入口。一句话总结就是让机器人不但会接话还会接单。1.2 智能体需要覆盖的三类核心用户需求第一类是知识解答型用户问“这个手机的电池容量多大”“发货到某地要几天”这类问题核心是准确和快答案来自结构化数据和FAQ重点在设计知识检索和快速回复流程。第二类是需求分析型用户说“我想给爸妈买个血压计要操作简单的”系统要从这句话里抽出受赠对象、产品品类、功能偏好然后匹配库存中满足条件的商品最后给出一个主推荐。第三类是决策辅助型用户已经在两个SKU之间纠结“A和B买哪个好”这时要能拿到两个商品的参数差异针对用户的使用场景给出选择建议甚至要能接住“有点贵”“我再看看”这种犹豫话术。三类需求在会话中是会切换的这也是为什么不能做成三个独立机器人而要做状态还能变动的智能体。用户可能先问商品参数再问物流时间然后问“和另一家比哪个好”最后又转到“算了太贵了”。如果系统只能在一个固定场景里工作这种会话流转会让用户反复重述需求体验非常差。我们的做法是不区分独立入口统一走同一个对话模型只是通过内部状态机在客服和导购两种模式之间切换。1.3 能力边界划定哪些场景必须快速转人工再强的模型也有不能碰的场景。我们在系统上线前就明确画了一条线情绪激烈的客诉、涉及退款金额争议、用户明确要求找人工以及涉及身体安全、医疗、使用风险的咨询全部直接转人工。这里宁可转错不可不转。让智能体硬接这类问题的后果是模型可能会给出过度承诺比如“过敏包退”“出问题全赔”这样的话一旦兑现不了客诉会升级到平台层面远比转人工更麻烦。另外一个容易被忽略的边界是客服权限。导购智能体可以推荐商品但不能随意修改订单、不能承诺赠品也不能擅自给优惠券。系统里所有涉及优惠和订单状态的操作都只走标记为“待人工确认”的动作不直接在会话中执行。把边界写进系统提示词还不够必须在工作流层配置硬校验避免模型生成的指令绕过限制。边界划得清楚智能体才敢放手做导购因为你知道最坏的情况不会失控。2. 技术选型与整体架构模型、知识库、工作流怎么搭2.1 大模型选型先用通用底座跑通再按需微调我们这个项目没有上来就微调模型。第一版直接用了国内商用大模型的API配合提示词工程和RAG把整条链路跑通跑了一两个月之后才根据会话日志决定要不要对意图识别做轻量微调。这样做的原因是电商客服的话术迭代速度非常快今天的爆款话术下周就失效微调模型的样本收集和训练发布周期根本追不上运营策略的变化。通用大模型底子够我们对它做的其实是“约束”而不是“训练”。选型主要看四个点中文理解能力、长上下文支持、工具调用的稳定性还有按量计费的价格。中文理解能力决定客服语气的自然度长上下文决定多轮对话能承载多少信息工具调用稳定性能不能可靠触发查询动作。实际跑下来四个选型里最影响体验的其实是工具调用的稳定性模型偶尔会把参数名改成相近但不存在的字段这个问题在代码里要加容错。项目选型考虑备注中文能力客服口语和网络用语较多需要覆盖省略语和常见错别字上下文长度多轮会话平均5到8轮配合裁剪和摘要不必追求最长工具调用需要稳定触发商品查询优先看评测集上的成功率成本按Token计费夜间可切便宜档位2.2 知识库设计结构化商品数据与问答语料分开处理商品数据最大的特点是“静态描述”和“动态状态”混在一起。商品名称、规格、参数、卖点是相对静态的适合做向量化价格、库存、活动折扣是动态的不适合放向量库因为向量检索是近似匹配它有可能把昨天已经过期的价格捞出来然后模型照着一本正经回答用户。我们采用的是分层知识库。结构化层存放SKU主数据、类目、规格参数、实时库存和价格通过确定性查询接口访问。向量层存放商品文案、详情卖点、FAQ、历史高质量客服回答。检索时先根据用户的品类关键词定位候选SKU再对非结构化知识做向量TopK取回最后把两部分内容一起塞给模型。这个顺序很重要如果先模糊检索再结构化过滤容易把相似但不同款的商品混在一起。知识时效性要单独摘出来讲。活动价格改价后旧知识如果还在向量库里极大概率造成报价错误。我们在写入向量库前会对商品文案做一次“时效标记”比如带上了“活动结束时间”的知识每次召回时计算是否过期过期内容直接丢弃。库存也是同理必须实时查绝不能让模型用记忆回答库存相关问题。这个设计看似简单但它拦住了不少让用户暴怒的低级错误。2.3 工作流编排用大模型做路由用确定性代码做执行对话系统的编排我们最开始用过比较重的工作流框架后来发现核心链路并不复杂就改成轻量状态机加函数调用的组合。整体流程是接收用户消息做意图识别更新会话状态根据状态决定调用哪个工具把工具结果拼到上下文再交给大模型生成回复。意图识别和话术生成这两步用模型解决工具调用和数据读取全部走确定性代码。这样设计是为了防止模型在关键操作上“自由发挥”。我们预置了四个核心工具商品检索、库存与价格查询、订单查询、优惠活动查询。每个工具都有明确的输入输出协议。比如商品检索只允许传品类、预算范围、应用场景三个参数模型传来的多余参数会被工作流层忽略。还有一点系统不让模型直接生成SQL也不允许模型自己修改订单状态所有状态变更动作都先变成“待人工执行项”由后台任务统一处理。这样即使模型输出有误也不会造成数据污染。下面给一个简化的工具定义示例{ tool_name: search_products, description: 根据用户的品类、预算、场景关键词检索可售商品, parameters: { category: {type: string, required: true}, budget_min: {type: number, required: false}, budget_max: {type: number, required: false}, scene: {type: string, required: false} }, return_fields: [sku_id, name, price, main_image, params, stock_status] }实际请求时模型按照这个协议返回参数工作流层做参数校验后再去查数据。对不齐的字段直接丢弃并记录一条日志方便后续调整提示词。这里有一个经验宁可让模型少传参数也不能允许它编造参数。3. 核心模块实现意图识别、需求抽取与导购策略3.1 意图识别模块分类标签加置信度门槛意图识别是整条链路的第一道闸门。我们设计了一套比较克制的标签体系一开始只分了七个标签售前咨询、参数询问、比价、售后、退换请求、抱怨、闲聊。标签太少会糊比如“哪个好”和“这个怎么用”如果归成一类后面策略就乱了标签太多模型容易混淆维护成本也高。七个标签在实测里准确率能稳定在九成左右。模型输出格式固定为JSON包含意图标签和置信度。代码解析时做一个硬判断置信度低于0.6不允许进入对应分支而是统一走澄清话术比如“你是想了解这两款的区别还是想知道怎么选更适合你”这样虽然多了一轮但避免了在用户意图不明时乱推荐。另外很重要的一点意图在会话中是可变的用户聊着聊着可能会从“比价”变成“售后”所以每次对话更新状态机时必须重新做意图识别而不是只会第一轮判断一次。{ intent: compare_products, confidence: 0.83, entities: { product_a: 无线耳机A, product_b: 无线耳机B } }3.2 需求抽取与动态追问从对话里拼出结构化条件导购推荐要想做得让用户觉得“这机器人懂我”前提是把用户的话转成结构化条件。用户说“我想买个无线耳机主要跑步用预算三百左右”我们内部会抽成类似这样的对象品类是耳机场景是运动预算是300元区间。抽取不靠正则而是用大模型加提示词约束但从模型拿回来的结果必须再做一次字段校验预算不能落在负数场景必须映射到预置的枚举值里。聊天里不可能一次把条件问齐。如果用户只说品类没说预算和场景系统不会一次性追问三个问题而是按照对推荐结果影响最大的顺序一次只问一个。先问预算还是先问场景我们的经验是优先问“使用场景”因为场景决定功能取舍而预算决定档位。先问场景会显得更自然比如“这款耳机有几种佩戴方式你是主要运动场景还是通勤场景”先问预算相对生硬实际体验中用户对先问场景的接受度明显更高。下面是抽取结果和追问流程的简化示意第一轮用户说“要个蓝牙耳机”抽取结果只有品类耳机场景和预算未知系统追问主要用在哪里运动、通勤还是玩游戏第二轮用户答“跑步和通勤都用”场景运动/通勤预算仍未知系统追问你心里大概的预算档位是多少三百和八百的挑选方向差挺多第三轮用户给出预算后系统才开始推荐候选商品这个流程跑下来比拿到一句话就立刻推荐的效果好很多。因为用户在给出完整约束之前推荐结果大概率是不准的不准一次后面要花三五轮才能拉回来。3.3 导购策略与话术模板克制推荐比全量推销更有效候选商品的选择逻辑不是“把所有相关商品都列出来”而是从符合硬条件的结果里挑三个以内主推其中一个。我们对结果按一个简单的综合分排序分数由三个信号组成商品与用户场景的匹配度、价格在预算区间内的位置以及同类商品的历史咨询转化率。匹配度和价格是实时算的历史转化率来自离线统计每天更新一次。对比话术我们沉淀了一个固定结构先复述用户需求再给两个到三个候选然后说清楚为什么主推其中一个最后留一个“是否进一步对比”的口子。复述需求特别重要它让用户确认系统没有理解偏。比如“按你预算三百左右、跑步通勤两用的需求我比较推荐A它的佩戴稳固性在这个价位里做得比较好如果降噪优先级更高B会更合适。”这样用户接收到的不是参数轰炸而是一个贴近自己场景的判断。犹豫信号也要单独识别。用户说“再看看”“有点贵”“我再想想”这类话不能当作普通闲聊跳过。我们设置的策略是先承认价格敏感再提供一个能降低决策门槛的信息点比如“这款平时价格在四百多现在领券之后是三百出头如果担心不合适有七天无理由可以先买回去试”。追单不是无脑发券而是帮用户把最后的决策负担减掉一点。同时要对推荐次数做抑制同一个会话里最多做两轮商品推荐超过之后就不再主动推新品避免用户产生被轰炸的感觉。4. 提示词工程与多轮对话体验控制4.1 系统提示词模板角色、边界、输出格式一次定清楚提示词在客服系统里不是写一段就完事而是要反复改。我们第一版提示词给得太开放模型经常说出一些漂亮的场面话比如“我们一直在努力为您提供更优质的服务”听起来很官方但在客服场景里非常冗余。后来把系统提示词收敛成了四个部分角色定义、任务清单、知识使用规则、安全与转人工边界。下面给一个简化了的模板这个模板经过多轮迭代后基本定型你是某电商平台的售前客服兼导购助手。 你的任务 1. 回答商品、物流、活动相关问题回答必须基于提供的知识内容。 2. 当检测到用户有购买意向时可引导需求但不要连续推荐超过两次。 3. 对无法确认的内容如实说明需要进一步核实不要编造价格、库存或功效。 知识使用规则 - 只能使用“当前会话知识”字段中的内容回答商品细节。 - 如果知识内容带有时效标记且已过期参考最新的活动查询结果。 - 不要输出知识内容中不存在的承诺。 安全边界 - 涉及退款金额争议、投诉情绪激烈、用户要求人工时回答“我帮你转接人工客服”并触发转人工动作。 - 不要承诺赠品、补偿、包赔等未经确认的权益。 输出要求 - 回答用自然的中文口语不用敬语堆砌。 - 一次回复不超过150字推荐场景可到200字但不超过。 - 不要主动编造用户的购买意图。每个部分都有它的作用。角色定义限定语气任务清单防止模型跑偏到闲聊知识使用规则压住幻觉安全边界处理兜底场景。输出要求里的“一次回复不超过150字”很关键大模型天生话痨不限制字数客服回复会变成小作文用户根本读不完。这个模板看着简单但每一条都是从真实失败案例里反推出来的。4.2 客服人格与导购人格怎么平滑切换同一个系统里其实有两个人格客服人格和导购人格。客服人格偏向准确、克制、中立用户问什么答什么不夹带额外推荐导购人格相对热情会在回答中主动关联用户需求并给出建议。这两个人格不能随机切换否则用户会觉得对面这个人精神分裂。我们用会话状态里的一个字段控制当前人格默认是客服人格只有当意图识别命中“售前咨询”且系统抽到了至少一个硬约束条件时才切换到导购人格。人格切换还要注意过渡话术。突然从“您的问题已记录”跳到“我推荐这款”会非常生硬。我们的做法是在导购动作之前加一句自然的连接比如“这个问题确实很多人问顺便说下如果你的场景是通勤为主最近有一款在促销参数上更贴合你的情况”。这句话既承接了用户的问题又给了推荐一个合理的由头。实测下来用这种过渡的会话比直接推荐的方式用户继续回复的意愿高不少。4.3 上下文管理窗口裁剪加关键信息持久化多轮会话有一个很现实的问题上下文窗口有限又不能无限塞历史消息。会话超过七八轮之后早期的信息容易被挤出去但其中可能正好有用户说过的预算和偏好。我们做了两层处理。第一层是窗口裁剪只保留最近几轮完整消息更早的消息压缩成一段摘要放进上下文的开头。第二层是把结构化信息单独存需求抽取的结果、意图状态、用户已看过的商品列表都放在会话状态对象里每次请求重新组装上下文时优先把结构化状态拼进去而不是依赖模型从原始对话里重新理解。比如用户第六轮问“之前说的那款还有别的颜色吗”如果第五轮已经把推荐商品写进会话状态系统可以直接查状态返回商品信息不需要模型去翻前面的消息。这类结构化持久化对成本和准确率都有帮助既减少模型需要重新推理的内容也防止遗忘。隐私方面会话状态里不存手机号、地址这类敏感字段用户标识用内部脱敏ID行为数据关联基于授权和明文脱敏两层处理这个在合规上不能省。5. 实测中踩过的坑与排查办法5.1 商品参数幻觉模型一本正经胡说八道项目上线两周左右我们遇到一个最典型的幻觉问题用户问某款手机的电池容量模型给出的数据和商品库里差了两百毫安。排查之后发现原因不是模型没有知识而是它根据训练语料里的记忆“发挥”了根本没有调用检索工具。从那之后我们在工作流层加了一个硬约束凡是涉及商品参数、价格、库存的回答必须在格式化输出中带上对应的SKU标识如果没有SKU标识这条回复不允许直接发给用户。这种约束要双层生效。提示词层写“只能基于检索结果回答”工作流层做校验检测到参数类问题但模型输出缺少依据时强制改成兜底话术。兜底话术是“这个参数我需要帮你确认一下稍等”然后转人工或走异步查询。虽然偶尔会让用户觉得机器人不够聪明但相比一本正经说错数据宁可慢一点也不能错。参数类回答的准确性是客服信任的底线错一次这个号基本就丢掉了。5.2 推荐太生硬用户没说要你非推给他灰度期间有一批用户反馈“这个机器人怎么唠唠叨叨一直推东西”原因是早期版本只要识别到商品关键词就进入导购人格每轮回答末尾都加上一句推荐。用户明明只是想查物流系统非要推荐新品体验非常差。后来我们砍掉了这个“逢问必推”的策略把触发条件改成有商品关键词、有明确的购买或比较意图、至少抽到一个决策相关的约束条件三者同时满足才允许进入导购模式。同时加了一个会话级别推荐次数限制每个会话最多推荐两轮且第二轮推荐必须发生在用户主动追问对比之后。这个限制写在提示词里也在工作流层做了计数器。模型输出内容里如果检测到推荐类话术但计数器已超限该句话会被过滤掉改成一句纯客服回复。这个改动上线之后负面反馈明显下降售前咨询的转人工率也降了一点说明用户更愿意继续和机器人聊下去。5.3 成本和性能平衡缓存、裁剪、限流三板斧成本是大模型应用绕不开的问题。我们做了三件比较有用的事。第一是FAQ级别缓存用户问同样的问题如果命中缓存直接返回不再走模型。像“发货到某地要几天”“怎么退换货”这类重复度极高的问题缓存命中率能做到三成左右直接省下了对应的模型调用量。第二是输入裁剪每次请求前动态计算当前上下文长度把不必要的历史日志裁剪掉只保留摘要和结构化状态。第三是输出限制把回复最大tokens尽量往低压客服场景的回复普遍不需要太长这项直接压低了每会话的模型成本。还有一个经验高峰时段和低峰时段的模型档位可以不一样。白天咨询量大用响应更快的模型档位保证体验晚上咨询少时切换到成本更低的模型档位整体成本能降下一截。限流方面我们给每个会话打了预算单次会话模型调用超过一定次数就强制转人工防止个别用户长时间刷对话把成本拖高。这套组合拳跑下来整体模型成本比最初版本降了三分之一左右而且用户侧体感变化不大。5.4 效果评估和灰度上线先看转人工率再看转化率系统上线前我们定了几个核心指标意图识别准确率、知识命中率、售前转人工率、售前咨询转化率、用户满意度。意图识别准确率通过人工抽检会话日志来评估每类意图抽几十条看判断是否符合知识命中率看多少轮回答能从知识库里找到依据售前转人工率反映系统兜不住的比例售前咨询转化率是最终的业务指标用咨询过智能体的用户是否下单来衡量。灰度策略上我们是分两步走的。先放5%流量观察稳定性和转人工率这一步主要看有没有严重问题比如回复格式异常、模型频繁报错。稳定之后再扩大到20%这时候才看转化率等业务指标。看转化率要多留一个心眼活动期间的数据噪音很大不能直接把某周的转化率变化归因于智能体上线最好拉同周期、同品类、同活动力度的对照组做比较。我们当时的做法是同一时间段内随机分配用户到新旧两套系统对比他们的售前转化率这样得出的结论才相对干净。这个项目做下来我最大的体会是技术选型其实没有想象中那么难真正难的是把“业务边界”和“知识质量”这两件事提前想清楚。模型再强商品数据是脏的回答还是会翻车推荐策略再精细用户没有购买意愿时硬推体验也会崩。如果让我重新做一遍我会把更多时间花在数据治理和对话状态设计上而不是一开始就去比较各家大模型参数。最后再分享一个小技巧在灰度阶段把用户不愿意继续对话的会话单独拉出来听一遍比看任何转化率数字都更能发现问题那些沉默的会话往往才是系统真正漏掉的机会。