做智能客服这行最常被问的一句话是你们整天说大模型跟直接调个API有啥区别说实话早期我也答不上来。直到某次给客户做POC对方拿一连串真实客服会话过来第一轮就露怯了——用户问上次那个订单为什么还没发货我们的大模型愣是没想起来上次是哪次更不知道这个用户上次到底买了什么。那一刻我就明白客服场景要的从来不是会聊天的模型而是记得住的模型。这背后牵扯的正是我们今天要聊透的东西自研大模型如何为点控云智能客服筑牢技术底座以及这套底座里最核心的双层记忆架构是怎么设计、怎么落地、怎么扛住生产环境真实流量的。1. 为什么客服系统必须走自研大模型这条路1.1 通用大模型接客服差在记得住而不只是答得出很多团队一开始都会想我直接调ChatGLM、通义千问或者国外那些开源模型的API把客服话术丢进去不就能做智能客服了吗表面看确实能跑通Demo一到生产环境就原形毕露。最典型的是多轮对话的连贯性。通用大模型的上下文窗口再长本质上记得的也只是当前这段对话里出现过的东西。真实客服场景里用户经常在前面聊了5轮之后突然问一句那退款走哪个流程这个大模型其实根本分不清那指的是哪个流程、订单状态是什么、用户身份有没有特殊权限。更麻烦的是跨会话记忆——用户昨天问过运费问题今天又来问退货地址如果系统不记得昨天的对话今天就得把昨天的信息重新问一遍这在真人客服眼里是失职在大模型眼里却是常态。另一个痛点是知识时效性。客服要回答的是具体商品的退换货政策、当前优惠活动、物流时效变化这些信息不是大模型预训练时固化下来的百科知识而是企业自己的私域知识且三天两头在变。通用模型的训练数据截止时间摆在那你总不能每次业务调整都重新训练一次大模型。1.2 自研路线的真实代价与收益账说到自研大家第一反应是成本高、周期长、要养算法团队。这个我并不否认但要把账算全。先算成本。用开源基座模型做微调和私有化部署一次性的训练成本和持续的推理成本加起来在日活几万到几十万的客服场景里确实低于长期按调用量付费的云端API方案。尤其是客服这种高频交互场景消息量上来之后按Token计费的开销会非常夸张。再算数据安全账。客服数据天然包含用户手机号、订单详情、地址等敏感信息很多企业根本不允许这些数据流向外部API。自研加私有化部署意味着模型推理全部发生在自己的机房或者私有云环境里数据不出域合规压力瞬间小很多。最后算效果可控性。通用模型回答风格是中性、官方、百科全书式的但客服需要的是礼貌、亲切、符合品牌调性、严格按业务边界走的话术。别小看这个业务边界——通用模型可能会帮用户算怎么薅羊毛薅得最狠自研模型经过针对性微调知道什么能答、什么不该答、什么时候得转人工。所以我的结论是智能客服这种场景自研不是炫技是刚需。这个研字的核心不在模型参数有多大而在记忆系统有多聪明。2. 双层记忆架构的设计思路一次用户提问两块数据同时响应2.1 第一层记忆会话级短期记忆管住上下文不丢先看短期记忆。它的职责很纯粹保证同一场会话内部的上下文连贯。用户问一句还没发货吗模型得知道问的是哪个订单、这个订单之前经历过什么状态变更。工程上短期记忆最常见的实现是滑动窗口。我们给每次会话维护一个消息队列按时间顺序存储最近N轮问答每次请求把窗口内的消息全部拼进Prompt送给模型。这个方案简单、直接、效果好但有个绕不开的限制Token预算。上下文窗口再大也不可能无限塞对话历史而且塞得越多模型响应延迟越高、单次调用成本越高。所以点控云在滑动窗口之上加了一层摘要压缩机制。当会话轮数超过预设阈值比如对话内容超过上下文窗口的一半时系统先把前面的对话丢给模型做一轮摘要生成一段精炼的会话要点之后的新一轮对话就基于这段摘要加最新的几轮原文继续。相当于给记忆做了一次增量存档既保住了关键信息又没让Token无限膨胀。这里有个细节值得展开摘要压缩的触发时机不是看轮数而是看Token占用量。因为不同用户每句话长度差异很大按轮数触发容易出现还没到阈值上下文就爆了或用户就说了两个嗯也触发摘要的尴尬情况。我们在每个会话节点都做累积Token统计超过窗口的55%到60%才触发压缩这样更稳。2.2 第二层记忆用户级长期记忆解决跨会话个性化短期记忆解决的是同一场对话记得住但真正的客户服务经常是跨会话的。用户昨天问过的东西今天不应该再问一遍用户是会员推荐话术和普通用户应该不同用户上个月投诉过某个问题这次如果又遇到系统应该主动规避雷区。这就是长期记忆的用武之地。点控云的长期记忆层做了两大块一块是结构化画像数据。用户ID、会员等级、历史订单、最近一次咨询时间、售后进度、偏好标签这些半结构化信息从业务数据库同步过来以用户ID为主键存成一张宽表。每次对话开始时系统先根据用户ID把这部分画像信息拉取出来拼进System Prompt告诉模型你现在服务的是谁。另一块是向量化的历史交互记忆。用户以前问过的问题、客服给过的答复、工单处理结果经过Embedding模型转成向量存入向量数据库。每次新对话进来系统先做一次相似度检索找出和当前问题最相关的那几条历史交互记录随Prompt一起提交给模型。举个直观的例子用户今天问我想退了那个蓝色的外套短期记忆知道他是从购物车点过来的长期记忆的向量检索发现他上周问过这件外套的尺码问题画像数据则显示这个用户是银卡会员、之前有过一次退货纠纷。糅合这些信息模型才能给出亲这件外套您上周咨询过S码的库存本次退货可以享受上门取件服务这类真人客服级别的回应。没有长期记忆再大的模型也做不到这一步。2.3 双层记忆的协同机制先画像再窗口后检索有读者会问两块记忆到底是怎么一起拼进Prompt的这里给出我们实际使用的拼接顺序。第一步用户身份识别。用户进线以后系统先拉取画像宽表确定这个人是谁、什么级别、有什么属性。这是Prompt的第一段用来给整个回答定基调。第二步短期记忆组装。把当前会话的滑动窗口、摘要压缩结果拼进Prompt让模型知道这场对话进行到哪里了。第三步长期记忆检索。用当前用户问题做Embedding去向量库里检索相关历史交互。这里有个技巧不是每轮用户发言都触发检索而是先做一轮意图分类只有涉及到订单、售后、投诉、物流这些强上下文意图时才触发既省了检索延迟也避免了不相关内容对模型产生干扰。最后知识库兜底。把企业知识库里与该问题高相关的内容块也检索进来作为模型回答事实依据。这个拼接顺序是有讲究的画像信息决定语气和身份设定短期记忆决定当前话题脉络长期记忆提供过往线索知识库提供事实依据。四层信息各管一段又相互印证最终组成的Prompt才接近一个真人客服脑子里同时运转的东西。3. 模型选型、微调与点控云部署落地的关键细节3.1 基座模型怎么选不是参数越大越好自研的第一步是选基座。我们的经验是三个维度平衡可商用许可、社区活跃度、显存友好度。开源模型的商用授权差别很大有的协议只允许研究用途有的明确可商用。客服系统是纯商业场景这一步踩坑的话后面全是法律风险。国内能用的几家主流开源大模型以及国外那批开放权重且带宽松商用许可的模型基本都是把可商用写明白的择优即可。显存友好度容易被忽视。7B和14B的模型在客服这种短文本、快响应场景里效果差距没有想象中那么大但推理显存差距非常明显。7B模型用INT4量化后可以压在6G到8G显存内单张消费级显卡就能跑14B就要翻倍32B以上基本告别单卡部署。考虑到生产环境要抗并发我们最终选了14B级别作为主力重度场景用量化版快速验证用7B版本。这里多说一句参数越大越好的迷思。客服场景的回答长度通常很短几十个字到一两百个字不涉及复杂推理和长文生成14B级别的能力调用完全够用。大模型在客服领域的真正瓶颈不是智力而是记忆和对齐而这两块恰恰靠架构设计和微调来解决靠堆参数解决不了。3.2 微调到底调什么三种路线按需组合选完基座再决定要不要微调。客服场景的微调我分三条路线来讲。第一条是SFT全参微调。适合数据量充足、业务复杂度高的情况比如有大量历史工单语料需要模型整体学习某种问答风格和边界话术。全参微调效果最明显成本也最高需要多卡训练迭代周期长。我们在做大版本升级时用这条路日常迭代不太动它。第二条是LoRA/QLoRA低秩微调。这应该是绝大多数客服团队的主力方案。用几张显卡对基座模型做LoRA微调训练参数量只有全参的千分之几成本可控迭代速度很快。比如针对售后场景单独训练一个LoRA适配器针对售前推荐场景训练另一个上线时按意图路由加载不同的适配器互不干扰。第三条是RAG检索增强严格说这不是模型微调但与业务知识时效性直接相关。企业知识库更新频繁每次更新都微调不现实正确做法是把知识库切片、Embedding、存向量库推理时检索出来拼进Prompt。RAG和微调不是二选一的关系而是配合使用微调让模型学会怎么回答RAG让模型知道回答什么。我们生产环境里还有一层反幻觉拦截。模型生成完回答后会做一次命名实体和关键事实的抽取校验与RAG检索到的知识块做一致性比对。比对不过就进入兜底流程不硬答而是转人工或回复这个问题我需要帮您核实一下。3.3 部署与推理优化让模型在真实并发下扛得住模型训练完不是终点能稳定服务才是开始。点控云的部署架构经历过好几轮演进沉淀下来几套稳定组合。快速验证阶段用Ollama这个不做多说它是本地跑模型最省事的工具一条命令就能把模型拉起来跑对话适合开发联调和效果验证。但如果直接把Ollama架到生产环境扛线上流量很快会被打爆因为它的并发吞吐和批处理优化相对有限。生产环境我们主力用的是vLLM做推理服务。vLLM带来的最大收益是吞吐量提升因为它实现了Continuous Batching把多个并发请求动态拼成批次送进GPU计算GPU利用率远高于逐条处理方式。另外它支持PagedAttention把KV Cache按页管理显存利用率高了很多同样是14B模型用vLLM服务比用普通方案能扛的并发高出一大截。部署形态上我们走的是多实例横向扩展加负载均衡的路线。多台推理节点挂到负载均衡后面每台节点负责一部分请求节点之间无状态。为什么强调无状态因为会话记忆都在Redis这种人共享状态里不像传统单体式客服系统那样每台机器绑定一堆会话内存状态这样任意节点宕机都不会导致会话丢失其他节点能无缝接管。GPU资源规划方面给一个保守参考单张24G显存用于14B量化模型推理差不多能支撑几十路并发对话具体数字取决于输入输出长度和硬件性能。我们的建议是上线前一定做压测以对话平均响应时间在2秒内、P95在4秒内作为达标线再反推需要多少台推理节点。4. 客服生产环境那些文档里不会写的稳定性问题4.1 温度参数调不好就是客服翻车现场翻车案例比想象中多得多。某次压测时我们发现大模型在回答退换货政策时用词越来越活泼甚至出现您放心跨店退货肯定没问题这种明显越界的话术。排查了半天原因居然是温度参数被设成0.9了。温度参数控制的是模型生成文本的随机性。客服场景追求的是稳定、准确、同一句话在不同时间问结果一致。温度接近0时输出基本确定好的一面是事实型问题稳定不飘坏的一面是语言会略显呆板缺一点人味。我们实测下来的最优区间是0.2到0.4之间既能保证业务边界清晰又能让话术带一点自然的语感。这个参数强烈建议按服务场景分开配置。售前推荐可以稍微放开一点让营销话术有点温度售后政策解释必须收紧一个字都不能差。4.2 上下文管理长对话的断点续传策略带记忆的客服系统最怕一种情况用户聊了半小时消息几百条上下文已经压缩过好几轮了这时候新来一个坐席要接管会话。如果记忆系统拿不到完整的历史全貌转述坐席接手后就一头雾水。我们的做法是在会话过程中持续维护一份会话memo每次都随摘要压缩同步更新。这个memo是一段高度结构化的文本包含用户诉求、处理进度、关键承诺、下一步计划。它既是喂给模型的Prompt素材也是人工坐席接管的交接文档。等于说双层记忆不只是给大模型用的也是给人用的人机协同的场景下一份记忆两边共享。4.3 离线评测集与线上兜底让每一次模型上线都心里有底最后讲上线流程。每次新模型版本要上线我们都会跑一遍固定的离线评测集。这个评测集从历史真实会话里抽样构建覆盖高频问题、边界问题、危险问题比如用户问自杀、违法、孩子乱答等情况三大类每类几百条统一跑完看答好率和安全率。答好率好理解回答是否符合预期是否解决了用户问题。安全率则更重要对于法律法规边缘、涉政、暴力、隐私等敏感输入模型要么安全拒答要么走转人工流程绝对不能一本正经乱发挥。这块建议自己构造一批诱导性测试用例专门看看模型会不会被绕进去。就算离线评测全过线上仍要布兜底。转录自定义的兜底逻辑当模型对问题的置信度偏低时触发转人工。模型本身能输出概率值我们以此为信号做兜底决策。指标上我们给到运营团队两个核心观察指标一个是会话解决率一个是人工转接率。记忆系统上线后前者从62%提到了79%后者从38%降到了21%这个数据比任何技术指标都有说服力。写在最后回头再看自研大模型加双层记忆这套组合我的体会是智能客服的竞争壁垒从来不在模型的智商上而在模型的记忆力和边界感上。大模型负责当大脑双层记忆负责当海马体企业知识库负责当外挂硬盘三者缺一不可。我们能跑到今天的可用状态靠的不是某一次惊天动地的技术创新而是把记忆的写入时机、Token的压缩策略、检索的触发条件、部署的扩展方式这些看似琐碎的细节一点点打磨到位。这个方向远没有走到尽头后面还有更多可做的事多模态客服、主动服务、语音与文本双通道融合记忆。如果你也在这条路上折腾希望这篇笔记能让你少踩几个坑。