做智能客服这几年我最大的感受就是用户根本不在乎你底层是规则引擎还是大模型他们在乎的是“同一件事换个说法你还能不能听懂”“上次刚说过的情况这次还要不要再重复一遍”。这也是我们点控云团队下决心把整个客服技术底座推翻重来的原因。传统的意图识别加检索问答在固定场景下够用但一旦对话拐个弯或者用户带着历史诉求回来追问系统就彻底失忆。所以从去年开始我们围绕自研大模型和双层记忆重构了整套智能客服架构今天就把这套技术底座的完整复盘写出来包括为什么选这个方案、记忆层怎么设计、落地时踩了哪些坑希望给正在做同类系统的团队一些参考。1. 整体设计思路为什么必须自研大模型加双层记忆1.1 传统智能客服到底差在哪先说传统方案的三个硬伤。第一是规则引擎和按键菜单的交互方式太僵化用户说“我要退货”和“我不想要了怎么弄”得配置完全不同的两条规则漏一条就漏一片。第二是检索式问答只能做单轮匹配用户说“那运费呢”系统根本不知道“那”指的是刚才那笔退货订单的运费。第三也是最致命的就是完全没有跨会话的记忆能力——用户两周前刚提交过售后工单这次再来追问进度客服机器人面对这个熟悉的老客户表现得跟第一次见面一样。这些问题的根源在于传统架构把一次对话当成一个孤立事件来处理既没有语义理解能力也没有状态保持能力。我们统计过自己平台上的客服对话数据大约三成以上的用户咨询是涉及历史信息的比如查订单、跟踪进度、追问处理方案。这部分需求用规则和检索根本覆盖不了必须从底层换思路。1.2 为什么选择自研大模型而非直接调API这里可能有人会问现在开源大模型那么多直接接API不就行了吗为什么要自研我们当时的判断有三个方面。第一个是数据安全与合规问题客服场景里全是用户手机号、订单详情、售后记录这些数据出域去调第三方API无论从合规角度还是从品牌声誉风险角度都不可接受私有化部署是硬要求。第二个是定制化问题业务方希望模型在售前导购、售后处理、投诉安抚这些细分场景上有稳定表现通用大模型做不到这种深度适配必须自己做领域微调。第三个是长期成本问题按调用量计费的API在峰值期费用非常不可控而自研模型在充分优化后单次推理的边际成本是可以压到很低的。也补充一句我们并不是说自研就一定比其他方式高级。如果团队刚起步、数据量不大、对延迟和数据出境没有严格要求直接调用成熟API快速验证需求完全合理。但如果你做的是企业级客服底座并且打算长期在这个方向深耕那自研大模型配合领域微调的路线迟早要走。1.3 双层记忆到底是什么解决什么问题记忆是智能客服从“能用”走向“好用”的分水岭。我们最终落地的方案是把记忆分成短期记忆和长期记忆两层各司其职。短期记忆负责当前会话之内的上下文保持比如用户刚才提过订单号、刚才确认过退货方案在下一轮回答的时候都要用得上。实现上主要是会话级的状态管理包括原始对话内容、关键信息槽位、当前意图栈。长期记忆则负责跨会话的用户画像与业务信息沉淀比如这个用户的会员等级、历史偏好、之前的投诉记录、上次没解决完的问题。有了这一层系统才能做到老客户一开口就知道他是谁、他过去发生过什么、他大概率需要什么。我用一个生活化的类比来帮助理解短期记忆就像饭店服务员手里那张点菜单客人这桌点了什么、有什么忌口都在上面但这桌客人吃完走了这张菜单也就作废了。长期记忆则像餐厅的客户档案本哪个熟客口味偏咸、哪桌客人上次投诉过上菜慢翻一翻档案就心里有数。一个合格的智能客服既不能丢掉眼前的点菜单也不能把客户档案本当成废纸扔了。2. 自研大模型的选型、微调与部署实践2.1 模型基座选择与中文能力评估自研大模型的起点是选基座。我们在选型时主要看四个维度中文语义理解能力、上下文长度、推理资源消耗、社区生态成熟度。当时测试对比了好几款主流开源基座从7B到13B到更大的规模都跑了一遍。测试方法也很朴素就是拿真实脱敏客服语料构造了一批意图分类和多轮对话样本看模型在相同参数下的准确率和响应质量。最终我们选择的是基于13B量级的基座继续走。原因很直接7B模型部署成本低、速度快但在处理复杂意图和多轮指代消解的时候明显吃力13B模型的理解能力上了一个台阶配合量化部署后单卡也能跑起来综合性价比最合适。如果你们的业务涉及很多垂直术语建议基座选型时就专门测一下领域文本的困惑度和抽取准确率别只看通用榜单的成绩。这里也提醒一点很多人选基座只盯着参数量忽略了tokenizer词表对中文的支持程度。有些模型英文很强但中文词表覆盖差会导致中文场景下token切得很碎推理开销增大且语义受损。我们当时的测试标准里专门有一项用相同长度的一批中文句子对比token消耗量差距能到百分之二三十这个必须提前摸清楚。2.2 领域微调的数据准备与训练配置选好基座之后就是微调。客服领域微调的数据主要来自三类历史优质会话记录、业务方整理的标准问答对、人工标注的意图和情绪标签。我们把这些数据整理成指令微调格式每个样本包含角色信息、当前问题、上下文和标准回答。数据清洗这一步最花时间。原始客服会话里有很多口语化表达、错别字、敏感信息还有一半以上的对话是无效寒暄。我们写了一套预处理流水线先做敏感信息脱敏再做相似会话去重最后靠人工质检保证数据质量。说实话微调的效果好不好七分看数据三分看参数宁可把数据准备好再训练也不要急着跑实验。训练配置上我们用的经验值是学习率设置在2e-5到5e-5之间用余弦衰减训练轮数不要贪多3到5个epoch就足够了太多反而会过拟合到训练集上导致在真实对话里泛化能力下降。LoRA这类参数高效微调技术我们也测过它确实能大幅降低显存门槛但初期微调还是建议先做全量微调等业务稳定了再用LoRA做增量更新。2.3 推理部署与性能优化方案微调完成后的部署环节核心是把成本和延迟控制在可接受范围。我们用vLLM作为推理服务框架它有几个特性对客服场景特别有价值其中最有用的就是Prefix Caching——对所有用户都共享系统提示词、知识库公共前缀这些重复内容做缓存实际测试中这部分内容占比非常高开启后首token延迟明显下降GPU利用率也上来了。量化方案我们选了INT8起步因为客服场景对回答质量要求很高INT4在部分复杂回答上会出现可感知的质量下降。如果你们后续模型规模继续增大可以用AWQ或GPTQ做更激进的量化但上线前一定拿真实对话样本做AB对比测试不能只看Perplexity指标。部署拓扑方面我们做过两套方案单机多卡部署一套大模型多机多卡部署多套模型副本。实际跑下来对于日均几十万次对话的规模三台双卡机器做成推理集群前面架一层负载均衡和请求排队已经完全够用。模型副本之间没有状态天然支持水平扩容。这里建议流量入口处一定要做超时控制和降级开关万一模型推理出现抖动或者队列积压可以直接降级到检索式问答兜底保证用户至少能拿到基础回复而不是转圈圈或报错。3. 双层记忆机制的设计与工程实现3.1 短期记忆会话上下文的分层管理短期记忆这块没有用特别复杂的技术核心解决的问题是“什么该留、什么该丢”。原始的对话内容如果全部塞进大模型上下文一方面token消耗大另一方面超过窗口长度后模型会对早期信息失焦。我们的做法是把短期记忆拆成三级原始对话buffer、结构化信息槽位、会话摘要。原始对话buffer保留最近几轮完整的用户输入和系统输出用于处理指代和省略。结构化信息槽位则实时抽取并维护当前会话中的关键实体比如订单号、退款金额、商品型号——这几个字段是业务查询的高频维度抽到就放进槽位后续轮次直接读取不依赖模型重新理解。会话摘要是当轮次过多时由模型自动压缩出来的把早期对话浓缩成几十字的摘要释放上下文空间。做一个简短的计算示例如果每轮平均消耗400个token20轮就是8000个token在8K窗口的模型上已经快顶到上限了。引入三级管理后原始buffer只保留最近8轮约3200个token加上压缩后的摘要和槽位信息整个上下文控制在5000个token左右既能保住关键历史信息又给当前轮次留出充足的推理空间。3.2 长期记忆用户画像与业务知识如何沉淀为可检索记忆长期记忆层的建设是这个项目里工程量最大的部分。简单说它的职责是把一个用户在所有历史会话中产生的高价值信息沉淀成结构化档案和向量化记忆两种形态。结构化档案主要存那些字段明确、稳定变化的数据比如用户ID、会员等级、常用收货地址、历史订单数、最近一次投诉类别。这类数据的写入逻辑很简单对接业务系统就能同步。真正需要花心思的是非结构化信息的沉淀比如用户上次反馈“对物流速度非常不满”、用户偏好“客服回复尽量简洁直接”这些信息藏在对话文本里需要抽取和向量化之后存到向量数据库中。信息抽取我们参考了OneKE这类知识抽取框架的思路先识别实体再抽取实体间的关系最后落成三元组结构。比如用户说“我去年买的那个吹风机坏了”系统会抽取出“用户-购买-吹风机”“吹风机-购买时间-去年”“吹风机-状态-损坏”这几组事实。然后再将整段用户描述和抽取结果同时向量化写入向量库查询的时候用用户当前的输入做相似度检索把最相关的历史记忆召回。长期记忆还有一个关键设计是写入策略和遗忘策略。写入策略分两种一种是会话结束后异步批量写入把本次对话里的高价值信息更新到用户档案另一种是当用户明确表达某些长期偏好时触发即时写入比如“以后发货前请先电话确认”。遗忘策略则对应数据合规要求用户注销或要求删除时要能把对应的结构化数据和向量条目一并清除这个功能在设计阶段就预留了接口千万不能等上线后再补。3.3 两层记忆如何协同工作短期记忆和长期记忆不是两个独立模块它们需要在一个完整的请求链路里配合。我以真实场景走一遍全流程大家感受一下协同方式。假设一个用户之前买过产品并投诉过物流慢今天再次进线说“上次那个东西怎么还没到”。请求进来后系统先用用户ID从长期记忆层拉取画像和历史档案发现这个用户存在“物流慢投诉”记录。然后短期记忆层初始化把本次会话的上下文结构建好。模型在生成回答时系统提示词里会注入两份信息长期记忆里的用户画像摘要、短期记忆里的当前会话上下文。于是模型结合“老投诉客户”和“当前订单查询”两层信息生成的回复会主动带上道歉语气和物流补偿方案而不是干巴巴丢一个物流单号。会话结束后系统再异步把本次交互中新增的有效信息回写进长期记忆比如用户当前的订单状态更新。这样一个完整的记忆闭环就跑起来了。协同的关键在于长期记忆负责“让系统知道你是谁”短期记忆负责“让系统记得我们刚刚聊到哪”两者缺一不可。4. 智能客服业务链路的落地实操4.1 核心流程梳理从意图识别到工单闭环有了模型底座和记忆层整个智能客服的业务链路还需要重新编排。我们最终线上运行的流程分五个环节请求接入、意图识别、策略分发、推理生成、服务闭环。请求接入层先做渠道归一不管是网页、小程序还是APP都统一转成内部消息协议。意图识别是整个流程的闸门我们直接复用自研大模型来做而不是单独训练一个意图分类小模型——因为大模型在理解模糊表达和生僻说法上明显更强。模型先判断这个用户进来是咨询、是投诉、是查询还是闲聊再结合长期记忆里的用户档案决定走哪条处理路径。策略分发这个环节是规则与大模型的结合点。比如检测到用户情绪是愤怒且历史有投诉记录就走优先转人工流程如果只是普通售前咨询则进入纯模型对话如果涉及订单等结构化查询先通过槽位信息调业务API拿最新数据再让模型基于实时数据生成回答。最后服务闭环负责把会话结果沉淀回业务系统包括生成服务摘要、更新工单状态、触发满意度回访。4.2 提示词工程与知识库问答的落地细节纯靠模型记忆解决不了企业私有知识的问题所以RAG检索增强生成是智能客服落地逃不掉的一环。我们在知识库建设上踩过不少坑这里分享两个关键经验。第一个是知识库分块策略。早期我们按固定长度切分知识文档结果经常把一块完整内容从中间切断导致检索召回的是半截话模型回答自然就歪了。后来改成熟知的做法先按篇章结构切分再对每个段落做语义完整性校验如果段落过长再做二次切分并保留标题上下文。文档标题和层级信息在向量化时需要拼进块内容里这样检索匹配度提升非常明显。第二个是提示词里知识引用的格式。我们要求模型在使用检索到的知识时输出内容必须带有来源编号同时我们自己写了一个知识引用一致性校验模块在模型回答后检查回答内容与引用知识之间是否存在明显矛盾。这个模块用规则加模型打分混合实现规则负责抓硬伤模型打分处理语义层面的偏差虽然增加了一点推理延迟但换来的准确率提升非常值。4.3 与业务系统的对接方式客服系统不可能脱离订单、售后、物流体系独立存在。我们做对接时采用了一个轻量级的工具调用层设计每个业务系统能力封装成独立的Function通过统一的协议暴露给大模型。模型根据当前对话场景决定是否调用以及传递哪些参数。比如用户问“帮我改一下收货地址”模型识别到这是个地址修改意图就调用地址修改接口必要参数从短期记忆槽位里取缺失参数生成反问句向用户追问。接口返回值不会直接拼进回答里而是经过一层格式化加工。系统提示词中定义了统一的数据展示规范比如日期统一成“X月X日”、金额保留两位小数、地址做脱敏展示。这一步看着不起眼但线上回答的专业感全靠这些细节撑起来。另外所有通过工具调用支撑业务操作都需要二次确认再补一个用户撤回机制万一模型理解错误执行了错误的修改操作用户能自己撤销避免纠纷。5. 常见问题与排查技巧实录5.1 模型幻觉怎么控制大模型客服最怕一本正经胡说八道尤其涉及订单状态、退款金额这种具体数据。我们的治理思路是“结构化数据禁止模型编造文本润色才放给模型发挥”。所有跟业务强相关的数据一律通过工具调用从业务系统获取真实数据然后要求模型只做信息的重组和表达不允许修改任何关键数值。在提示词里我们加了一条硬性约束“如果你无法从提供的资料或上下文中找到答案必须明确表示不知道并提供转人工选项。”这套约束加上之后虚构回答的比例下降非常明显。但如果你们的场景必须让模型做数值推断可以另外接入一套规则校验对金额、日期、单号等敏感字段做格式和合法性检查不合法就触发重写或转人工。5.2 上下文截断导致答非所问上线初期我们遇到过一类典型的bad case用户聊到十几轮后突然问“那第二个方案呢”模型完全不知道“第二个方案”指的是什么。定位后发现是原始对话buffer只保留最近8轮而“第二个方案”是在第10轮提到的已经被提出去了。会话摘要也没有记录这个信息因为摘要本身是每5轮生成一次跨度太大丢了很多中间细节。这个问题的根治方案是给短期记忆增加关键信息追踪。现在我们的对话buffer里除了原始轮次还会实时维护一个“方案列表”类型的槽位每当模型给出方案性内容时自动编号存入槽位后续用户提到“第二个”或“刚才说的那个”就能直接命中。记忆设计不能只看轮次窗口还要考虑业务语义信息的连续性。5.3 检索召回率低怎么办知识库问答召回不准这个事我们从三个方向同时优化。首先在向量模型选型上直接从通用向量模型换成了在中文语料上表现更好的bge-m3换完直观感觉是召回质量提升了一个档次。其次在查询侧做了改写用户的原始问题比较口语化先用大模型把问题改写为更规范的知识检索语句再去query向量库实测top5准确率提升约十几个百分点。最后是混合检索利用数据库里的BM25全文索引和向量检索做加权融合尤其针对那些包含精确型号、编号的查询关键词命中的价值甚至超过语义匹配。5.4 高并发下的性能瓶颈大模型推理是高并发场景下的最大瓶颈。我们的优化手段分三层。第一层是推理引擎层前面提到的vLLM连续批处理和Prefix Caching在这里发挥主要作用能把GPU利用率提上去。第二层是业务层给不同渠道的请求设置不同的优先级队列比如投诉渠道优先处理普通闲聊排队防止低价值请求把推理资源占满。第三层是容量规划我们做了一个非常朴素但有效的压测方法把历史真实流量录制下来按不同倍速回放找到系统在每秒多少个并发请求下才出现超时率飙升然后用这个数值的60%作为日常容量水位线留足冗余应对突发流量。5.5 成本控制实用技巧最后说说大家都很关心的token成本。长期跑下来最大的消耗点不在推理本身而在于冗余的上下文。我们持续在做上下文瘦身短期记忆字段能精确到槽位就用槽位不要堆积大段历史文本系统提示词也定期迭代去掉效果不明显的长篇描述模型回答部分开启流式输出后用户可以提前终止还能省掉后续token生成的开销。另一个容易被忽略的省钱点是日志存储完整对话记录必须保留但向量化副本不需要存全量只保留抽取出来的记忆条目能省下不少向量库的存储费用。根据我们实际跑下来的数据这套自研大模型加双层记忆的架构上线后多轮对话的任务完成率比之前提升了接近一倍转人工率降了四成左右用户满意度也明显回升。当然技术底座只是把地基夯实了真正的服务体验还要靠业务策略持续迭代。用几张图把架构画出来给团队看容易让每一个模块在线上稳定跑起来、遇到问题能快速定位才是真功夫。至少对我们来说这个方向走对了后续还会沿着“更精准的记忆写入”和“更自然的引导式对话”继续打磨。