一次实战复盘虚拟零售场景下的智能客服架构我是怎么搭的今年上半年我们团队接了一个比较有意思的活儿给一家虚拟零售平台重构客服系统。所谓虚拟零售说白了就是平台自己不囤货、不发货只做品牌入驻、订单撮合、售后流转这类轻资产运营商品SKU动辄几十万覆盖美妆、数码、家居、服饰好几个类目。这种业态下客服要面对的问题非常杂用户可能问“这款精华适合油皮吗”“这个耳机支持LDAC吗”“我买了两件衣服想退一件换一件怎么操作”还可能同时问库存、比价、优惠券叠加规则。传统的关键词机器人根本扛不住这种开放式的、多轮纠缠式的咨询人工客服的招聘和培训成本又被平台方压缩得越来越紧。所以我们最终锁定的方案是用大模型做语义理解和对话管理叠加一套可配置的推荐中间层来实现既能聊得明白、又能推得精准的智能客服架构。这篇文章不是理论宣讲而是把我从需求拆解、技术选型、对话链路设计、推荐策略落地到上线后的踩坑记录完完整整地复盘一遍。如果你也在做类似的智能客服、问答机器人、或者基于大模型做业务系统改造这篇内容应该能帮你少走不少弯路。1. 需求拆解虚拟零售客服到底难在哪1.1 三组核心矛盾决定了架构方向第一个矛盾是开放式提问 vs 强业务规则。用户说的话千奇百怪但平台的售后政策、物流规则、优惠叠加逻辑必须严格遵守不能模型自由发挥。第二个矛盾是多轮对话的记忆管理。用户可能在第5轮才说“那我刚才问的那个色号还有货吗”系统得记得“刚才问的”是什么。第三个矛盾是推荐精准度 vs 推荐可解释性。运营团队要求每一个推荐结果都要能追溯“为什么推这个”而不是黑盒子吐出一堆看似合理但无法解释的商品。这三组矛盾直接决定了我们不能拿一个大模型裸奔上线而是要做分层架构模型层只管理解和生成业务规则层管约束会话状态层管记忆推荐引擎层管商品匹配。这也是为什么很多团队用大模型做客服做不落地问题不在模型本身而在于没有把模型嵌进一个有约束的业务框架里。1.2 我们最终圈定的功能边界和业务方开了两次需求对齐会之后我们把第一版的功能范围收敛成四个方面商品咨询支持基于商品名、类目、属性词的问答比如“有没有适合干皮的平价面霜”。订单服务查订单状态、催发货、申请售后、修改地址这类操作要能识别意图并调用后端API。售后政策问答退换货规则、运费承担、时效承诺这类必须引用官方政策原文不许自由发挥。个性化推荐根据用户访问记录、当前会话上下文、类目偏好做商品推荐并给出理由。除了这四块我们还有个硬性要求所有对话记录必须入库支持运营后台检索和质检。这意味着架构里从第一天就得考虑会话日志的采集和存储而不是等上线后再补。1.3 技术选型上的取舍模型选型上我们对比了实际效果和成本之后决定这个项目用Qwen系列作为基础模型配合BGE-M3做embedding模型并没有上太大参数的版本。理由很简单客服场景对延迟敏感用户等不起十几秒才出回复参数太大在现有GPU上跑起来也不现实。核心工作其实是两个方向一个是对问题的文本做精细的改写和意图路由另一个是在RAG链路里把检索质量做扎实。后面所有架构组件都是围绕这三个明确的技术基座展开的。2. 整体架构设计分层解耦是落地的前提2.1 五层架构总览我直接给出我们最终落地的分层结构这是和团队反复讨论后定稿的用户接入层小程序 / App / Web统一通过HTTP Gateway接入 对话管理层会话状态管理、多轮上下文维护、对话打断与恢复 意图理解层意图识别、实体抽取、问题改写、路由分发 业务逻辑层商品检索、订单API、政策知识库、推荐策略引擎 模型与数据层大模型推理服务、Embedding模型、向量数据库、会话日志存储分层的核心思想是让大模型只做它擅长的事语义理解、抽象归纳、自然语言生成。而可计算的、可规则化的、需要严格一致性的业务逻辑全部下沉到业务逻辑层。你可能会问为什么不直接让大模型一把梭把检索、推荐、API调用都交给tool calling去做我们的经验是在全开放tool calling模式下模型偶尔会选错工具、填错参数这在售后场景里是不能接受的。因此我们的路由策略采用了“意图概率规则强制校验”的方式模型输出结果只作为候选业务层有最终决定权。2.2 会话状态管理所有多轮体验的根基多轮对话本质上是一个“系统如何记住并正确使用历史信息”的问题。这里最容易被新手忽略的是不是所有历史内容都应该喂给大模型。我们把会话上下文分成三层短期记忆当前会话最近10轮问答用于直接拼装Prompt。业务状态用户当前选中的商品、订单号、售后单号等结构化字段。长期画像用户在平台的历史偏好标签从推荐系统侧同步用于个性化输出。短期记忆直接用Redis存储设置2小时过期所有对话节点共享一份sessionId。业务状态使用独立的字段存储不混在聊天文本里。长期画像则放在另一个服务里由推荐引擎统一维护。为什么这么拆因为如果你把“长期画像短期聊天记录业务状态”全部糊在一个上下文里发给模型第一是token消耗巨大第二是模型容易被历史噪声带偏第三是出了线上故障根本没法排查——你都不知道模型是根据哪一段历史做决策的。分层之后每一类信息都有明确的来源和消费场景问题定位容易得多。2.3 大模型推理服务如何嵌入主流程我们没有把大模型直接做成一个在线API给客服系统调用而是在中间加了一层推理网关服务。这个服务负责统一封装模型调用屏蔽底层部署差异。统一Prompt模板管理和版本控制。做模型输出的结构化解析和校验。控制并发和限流防止流量突刺打垮推理服务。这里其实是在实践一个经典思想缓存和重算相结合。对于相似度极高的重复问题我们会在缓存里保留回复不直接触发模型推理。实测下来节假日大促期间缓存命中率能到20%左右省下的算力可以用来支撑更多长尾问题。3. 大模型在客服场景里的关键实现RAG检索增强与多轮对话3.1 为什么必须用RAG而不是纯靠模型记忆客服场景有大量政策条款、商品属性、物流规则这类信息更新频繁、对准确性要求极高。比如“七天无理由退货”的具体实施细则不同类目、不同店铺可能不一样。如果靠模型参数记忆训练时看到的可能是旧数据上线后也无法及时纠错。你也不希望每一次规则变更都去重新训练模型成本太高。所以必须走RAG。我们的知识库构建流程大概是这样的把商品信息标题、类目、属性、卖点、售后政策、平台规则等文档统一清洗成结构化Markdown。按层级做切片商品一条切一段政策按条款切分物流规则按场景切分。每个切块用BGE-M3模型做Embedding存入向量数据库。用户问题时先用同样的模型Embedding然后检索TopK个相关切块。这里有一个非常重要的实践细节不能只做向量检索必须做混合检索。纯向量检索对同义改写效果好但对精确型号、条款编号这种关键词检索不敏感。我们线上做的是BM25关键词检索和向量检索双路召回再用Rerank模型精排最后把Top 5切块送进Prompt。这一步做完之后检索准确率提升非常明显。3.2 多轮对话里的问题改写让检索不丢上下文在多轮对话中用户的提问往往依赖上文。比如用户这款手机支持无线充电吗 客服支持的而且兼容MagSafe。 用户那它的电池容量呢第二问里“它”指的是前文那款手机。如果直接把“那它的电池容量呢”拿去做向量检索结果肯定不会好。所以在送入RAG之前需要有一个问题改写模块。我们让大模型根据最近几轮会话和当前问题生成一个独立的、包含完整信息的搜索query。改写后的query样例原问题那它的电池容量呢 改写后这款XX手机的电池容量是多少毫安时这个问题改写对检索质量的影响是决定性的。不做改写多轮对话的命中率可能只有五成做完改写能提升到八成以上。而且改写模块本身用大模型实现成本很低只需要清晰的任务描述和少量示例实测效果很稳。需要注意一个细节改写出的query只用于检索不改写用户原文。最终展示给用户的回复还是基于用户原问和上下文生成的避免因为改写引入信息偏差。3.3 推荐策略从“猜你喜欢”到“对话即入口”在虚拟零售的客服场景里推荐不是独立的“猜你喜欢”模块而是嵌在对话流里的。用户问“有没有适合油皮的夏日面霜”系统不只是给答案还会顺带推荐3款符合条件、库存充足、佣金率合适的商品。推荐链路分成四个阶段实体识别从用户问题中抽出品类、肤质、价格区间、使用场景等属性。召回在商品库中用结构化条件过滤加向量相似召回。精排结合用户的长期偏好标签、商品热度和平台运营策略加权排序。生成把排序结果喂给大模型生成自然语言推荐语附带推荐理由。这里有个关键点推荐排序不是模型决定的而是业务策略决定的。大模型只负责把结果组织成用户能接受的语言。这样可以保证推荐目标的稳定性——比如平台某阶段主打高毛利商品运营只需要在排序权重里调参不需要改模型。推荐解释也是必须的。我们用了“原因卖点”的结构化生成方式。比如推荐理由根据你的出差场景这款轻量充电宝25000mAh既能满足两天续航重量也只有390g机场安检可携带。这套解释由大模型结合商品属性生成但“为什么推荐这个”的核心逻辑来自排序阶段的特征权重因此运营可以解释、可以干预。4. 架构落地的关键环节离线评估、Prompt工程与服务化4.1 离线评估没有评测集就是耍流氓我见过太多项目大模型聊起来感觉不错就直接上生产结果一上线面对真实用户就崩了。原因很简单人工感觉不见得可靠。我们从项目一开始就建了一套离线评测集大概两千条真实对话样本每条标注了标准答案、意图标签、是否含商品推荐要求。每次调整Prompt、换模型版本、改知识库切片策略都要先跑一遍评测集。评测指标上我们不只看整体准确率而是分维度看商品咨询答对率、售后政策引用一致率、多轮上下文衔接正确率、推荐项命中率。分维度跑的好处是团队能知道每一次改动到底改好了哪一项而不是一个笼统的数字。这里有一个容易忽略的问题评测集本身也会“过拟合”。如果一直拿同一批数据进行调优模型和Prompt会逐渐“背题”。所以每两周会从线上真实对话中抽样人工标注后扩充进评测集保持覆盖率。4.2 Prompt工程模板化 版本化管理大模型项目里Prompt就是代码这句话真不是玩笑。我们在上线前迭代了十几版Prompt全部放在配置中心做版本管理可以随时回滚。Prompt结构上我们分了五个部分System提示定义角色、语气、禁止事项。业务约束明确售后政策必须引用知识库原文不得编造。会话历史最近轮次的问答内容。检索结果RAG返回的相关文档。输出格式要求返回JSON结构便于解析。一个典型的System Prompt片段长这样你是XX平台的智能客服助手负责解答商品咨询、订单查询和售后政策问题。 回答必须基于给定的资料不得编造信息。如果资料不足请明确表示需要转人工。 推荐商品时必须给出推荐理由且推荐的商品必须来自检索结果列表。注意Prompt不是越长越好。我们的经验是该约束的地方必须写清楚不需要模型发挥的地方一个字都别多绕。建议多实验但上线前锁版本、走评审。4.3 服务化与部署让模型像内部服务一样被调用我们的模型推理服务基于vLLM部署支持高并发和连续批处理整个平台共用一个推理服务实例通过不同的Prompt模板区分业务场景客服、商品描述生成、问题改写。商品库Embedding离线构建每天定时更新向量检索用的是Milvus支持百万级商品规模。网关层有一个超时控制和降级机制模型单次调用超过4秒直接返回兜底话术转人工处理。这么做是为了防止大促流量高峰时模型推理成为瓶颈拖垮整个客服链路。任何大模型应用都必须设置降级预案否则一次推理服务抖动可能导致全站客服不可用。4.4 日志与反馈闭环每一轮对话都会生成一条JSON日志包含用户问题、改写问题、意图识别结果、候选文档、最终回复、推荐商品列表、响应时长和模型版本号。日志进入数据仓库后每日跑一套分析任务意图置信度平均分变化转人工率、用户满意度走势多轮对话平均轮次推荐曝光到点击的转化率这些数据最终会反馈回评测集和知识库运营形成一个闭环。这也是我认为架构设计里最重要的隐藏功能——系统要能持续变好而不是上线那天就是巅峰。5. 常见问题与避坑指南5.1 问题一大模型总是“一本正经地胡说八道”这是客服场景最先遇到的问题。用户问一个知识库没覆盖的问题模型可能自己编一个答案这在售后政策场景里是不可接受的。我们的解法有三板斧检索结果置信度低于阈值时强制回复“该问题需要转人工”不调用模型生成。Prompt里明确要求资料中没有答案时不得推理编造。回复生成后加一个“可回答性校验”检查生成内容是否引用了检索结果中的关键实体如果完全没有拉高转人工倾向。三个措施叠加编造率从最初的6.8%降到了0.5%以下剩余的极少部分主要发生在复杂多跳问题上。5.2 问题二多轮对话跑着跑着就迷失了主要原因是上下文管理不当。我们最初把整段聊天历史全部拼进去效果反而不稳定因为历史噪声太多比如用户发过表情包、中途打断、插入了无关话题。后来我们做了三件事保留最近10轮超过的做摘要压缩。只保留“和当前意图相关”的实体信息比如用户之前提到的商品名。当识别到用户换了新意图时重置对话焦点避免旧上下文污染新问题。5.3 问题三推荐商品不精准用户不买账最开始我们的推荐就是简单的“根据文本相似度推N个商品”结果用户觉得“答非所问”。后来发现问题在于文本相似度不等于购买意愿匹配度。用户问“有没有适合油皮的夏日面霜”如果只做文本相似可能召回一堆标题含“面霜”的商品但没考虑肤质、季节、价格段。改进后的方案是建立了一套结构化属性过滤在向量召回之前先用“油皮”“面霜”“夏季”这些标签做过滤再加入用户的长期偏好排序。做了这个改动之后推荐点击率大概提升了一倍。5.4 问题四模型响应太慢用户等不起大模型的生成速度天生比传统检索慢这是物理限制。我们做了三件事来对冲用流式输出用户能一边看一边等体感速度快很多。设置短期缓存相同问题重复提问时直接命中缓存。控制生成长度客服回复一般不超过150字既不啰嗦也省token。6. 当前的效果与可以继续延伸的方向上线三个月后系统的自动解决率在65%左右人工客服的日均会话量降了三成以上售后政策的回答准确率达到了98.6%商品推荐点击率比传统基于规则的推荐高了将近一倍。当然这里有多方面因素的作用不全是模型的功劳但架构设计踩的坑和摸出的门道却是完全可以复用的。从我的实际体会来看这类虚拟零售智能客服项目的成功关键不在于用了多大的模型而在于怎么让模型在业务规则和安全边界内高效工作。RAG解决知识更新和准确性问题意图路由和会话状态管理解决多轮体验问题结构化推荐策略解决业务目标问题评测闭环解决持续优化问题。这几块组合起来才是一个真正可以上线扛压的智能客服系统。如果你接下来想在这个方向继续深入我建议可以关注几个延伸方向多模态客服用户拍一张商品损坏的照片客服自动识别问题类型并引导售后流程。主动营销式客服在对话中根据用户意图和优惠策略主动推荐可凑单、可领券的商品组合。更精细的情绪识别检测用户不满情绪并自动升级处理优先级。这些方向都是在现有架构上的增强并不需要推翻重来。这也正是分层架构带来的好处每一层独立演进整体保持稳定。架构这东西不是画几张图就完事真正有价值的是在线上反复打磨出来的那一手经验。