做客服系统做到第四篇我的体感是单轮问答跑通只是把零件装好了多轮对话才是真正把客服系统拼成人的那一步。用户不会按你设计的流程问问题他们会说这个呢、那怎么退、我刚说的那个订单甚至一句话里夹着三个意图。如果没有一套可靠的会话状态管理没有把知识库检索结果正确地揉进对话上下文整个系统就是空中楼阁。这篇我重点讲四个事多轮会话的记忆怎么维护、Chroma 知识库怎么真正接入对话流、Ollama 本地模型服务化躲不开的坑以及客服 Prompt 模板的实战设计。参考对象就是那些刚开始做本地知识库客服机器人、想把 LangChain Ollama Chroma 这条链路用到真实业务场景的开发者尤其是已经跑通基础问答、但一进入多轮就发现上下文混乱、答案飘忽的朋友。1. 多轮对话的记忆系统会话状态到底该怎么维护1.1 历史消息为什么不能无脑拼进 Prompt我知道很多人一开始的做法很简单把用户和助手的对话记录按时间顺序拼成一个超长字符串直接塞进 Prompt。这在 demo 里确实能用但一旦到了客服场景马上暴露三个问题。第一个是 token 膨胀。客服对话动辄几十轮每轮用户和助理的消息算下来很快就突破本地模型的上下文窗口。Ollama 跑 7B 模型通常只有 4K 到 8K 上下文你拼了 30 轮对话进去模型还没开始理解用户当前的问题先把自己的注意力消耗光了。实测中表现就是越往后回答越敷衍甚至开始重复用户的话。第二个是信息稀释。模型不是越多的历史信息越好而是要相关的历史才好。客服场景里用户在第 8 轮提到黑色那双鞋到第 15 轮只说那双鞋我要退如果没有在第 8 轮建立实体关联模型根本不知道那双指什么。但如果你把全部原始记录都丢给它它又要从一堆无关信息里把关键实体捞出来漏检率很高。第三个是注入问题。历史对话里如果夹了用户输入的恶意内容或格式混乱的文本直接拼接会让模型被带偏。客服系统接的是真实用户什么话都可能有必须在拼装上下文之前做好过滤和结构化。所以多轮对话记忆的第一步不是存更多而是精选后结构化。要让系统只保留跟当前问题相关的关键事实、用户意图、已确认的订单号或商品信息然后按固定格式组织后交给模型。1.2 LangChain 记忆组件的选型从 Buffer 到 SummaryLangChain 早期提供的记忆组件很多人应该都见过ConversationBufferMemory、ConversationBufferWindowMemory、ConversationSummaryMemory、ConversationSummaryBufferMemory。我自己的使用经验简单说一下它们的取舍。ConversationBufferMemory是全量缓冲适合短会话、模型上下文很宽的场景。但碰了上面说的 token 膨胀问题。ConversationBufferWindowMemory只保留最近 K 轮。这个思路在客服场景里挺实用——大多数客服问题的核心答案只依赖最近几轮的信息。K 设成 6 到 8 轮是个比较稳的起步值既能覆盖刚才那个问题的指代又不至于撑爆上下文。ConversationSummaryMemory会把历史对话浓缩成摘要适合长期会话。但有个坑摘要本身是模型生成的每次更新摘要都会调一次模型这种场景在低配机器上响应很慢而且摘要有损信息订单号这类精确信息经常被概括丢。ConversationSummaryBufferMemory是窗口和摘要的混合体近几轮保留原文更早的转成摘要。理论上很优雅但实现复杂度高需要自己维护触发阈值客服系统里如果没把精确信息订单号、手机号单独做变量存储摘要丢失会引发严重错误。到了 2024 年之后LangChain 社区的共识是老式 Memory 类逐渐被 LangGraph 的 checkpointer 方案替代。核心变化是把记忆拆成两部分——对话历史存在外部存储比如 SQLite、Redis每个会话节点通过checkpointer恢复状态。这样多轮对话的本质变成了从存储中读回历史消息数组再交给模型而不是依赖一个隐形的 Memory 对象。我的建议是如果你的工程是以 LangChain 为核心、不想引入额外框架那就用ConversationBufferWindowMemory 外部会话存储的组合简单可靠。如果愿意接受新架构LangGraph 的MemorySaver或SqliteSaver是目前最值得投入的方向它把会话状态的存储、恢复、分支都规范化了后续扩展成带人工接管功能的事项中心非常方便。1.3 会话隔离session_id 与用户级状态管理多轮对话系统做出来不是给一个人用的客服场景尤其如此。你面对的是几十上百个用户同时提问如果会话状态互相串了那基本是事故。所以从第一天开始我建议给每个会话一个唯一的session_id用 UUID 生成每次用户进入新会话就重新分配。这个 ID 既用来在 Redis 或数据库里存储历史消息也用来区分不同会话的向量检索范围。还有一个层级要注意用户级信息与会话级信息。用户姓名、会员等级、经常购买的商品类别这些属于用户级信息应该独立存储不需要每次会话重新问而当前要退的订单号、刚才提到的问题描述则属于会话级信息会话结束就该清掉。把这两层分开Prompt 拼装的时候就能做到用户画像信息常驻会话信息按轮次滑动后者过期自动淘汰。我在实际项目中看到很多新手犯一个错把所有信息都塞进 messages 数组结果用户第二次咨询时上一单的信息还在记忆里模型很容易把两个订单搞混。我的做法是在拼装历史上下文之前先跑一层简单的实体抽取把订单号、商品名、联系方式这类关键实体提取出来存成结构化变量历史消息里只保留语义脉络关键值以当前变量的形式强化传递给模型。2. 客服知识库接入对话流Chroma 检索的切分、召回与拼装2.1 文档切分粒度与 embedding 模型选择多轮对话客服系统有一个常见误区以为把知识库接上 RAG 就万事大吉但检索质量直接取决于你切文档的方式。Chroma 本身不关心你怎么切文本它只管把切好的 chunk 向量化后存起来。但 chunk 的粒度决定了召回结果的可用性。我做过对比把一份客服 FAQ 文档按 200 字切块和按 1000 字切块检索出来的结果差别非常大。切太小单个 chunk 信息不完整模型拿到的是半句话切太大一个 chunk 里混了多个主题检索命中率被稀释而且超出 embedding 模型的默认最大长度常见是 512 token超出部分在向量化时会被截断等于白扔信息。我比较推荐的做法是按语义段落切分段落过长的再二次切分同时保留 50 到 100 字的重叠区间。Chroma 的add_documents接RecursiveCharacterTextSplitter设置chunk_size300、chunk_overlap50是个比较通用的起点。中文场景还要注意切分器最好按中文标点句号、问号、感叹号优先断开否则很容易在词中间硬切造成语义断裂。embedding 模型的选择同样关键。如果你用 Ollama 跑大模型但 embedding 还用一个在线 API那整个系统就失去了离线化的意义。本地跑 embedding 模型中文场景我实测比较稳的是bge-m3和m3e这类中文优化模型用Ollama拉下来之后通过/api/embed接口调用Chroma 里通过自定义 embedding function 接入。这一步的好处是整个链路完全本地化没有外网依赖速度也稳定单次 embedding 调用大概几十毫秒。2.2 检索策略Top-K 与相似度阈值Chroma 的query方法默认返回n_results个结果但这里有个很实际的问题到底返回几个才对我的经验是不要一上来就设 4 或 5而是先设一个稍大的候选池比如 8然后结合相似度分数过滤。Chroma 默认用的是 L2 距离余弦距离我们可以显式指定collection client.create_collection(..., metadata{hnsw:space: cosine})分数本身不是绝对的正确率它会随文本长度、主题分布浮动。所以更稳的做法是定义最低接受分数和最佳命中分数两个阈值低于最低阈值直接视为检索不到这时走兜底话术在两者之间时把检索结果标为可能相关Prompt 里要求模型谨慎引用。Top-K 的大小还要结合 chunk 长度来调。如果你切的是 300 字的 chunk返回 3 到 4 块就够了拼出来的上下文大概 1000 到 1200 字模型处理起来不费力。如果切的是 500 字大块那 Top-K 建议调到 2 到 3否则上下文太长。2.3 单轮 RAG 与多轮 RAG 的上下文差异这是多轮客服系统最容易翻车的地方。单轮 RAG 的逻辑是用户问题 - 检索知识库 - 拼装参考材料 - 生成回答。但到了多轮对话里用户第 5 轮的问题是那退货运费算谁的这句话单独拿去向 Chroma 检索几乎什么都检索不到因为缺少主语。解决办法是在检索之前加一步对话改写把当前问题 最近几轮历史一起丢给本地模型让它输出一个检索友好的查询语句。比如历史里用户说我要退那双黑色运动鞋当前问那退货运费算谁的改写后的检索词应该是黑色运动鞋退货运费由谁承担。我见过有的团队直接拿一个大模型做多轮纠错但客服场景其实用不着那么重的模型用 Ollama 跑的 7B 模型做 query rewrite 完全够用耗时大约一两秒换来的是检索命中率的明显提升。另外多轮对话的检索结果不用每次都把所有历史都带上。更好的方案是复用前几轮检索出的已回答过的知识点把新检索结果和旧知识点一起作为上下文而不是让模型重新理解历史。这个做法的好处是连贯性更强用户感觉机器人记得住而且不会因为新检索结果和旧回答冲突而让模型自相矛盾。3. Ollama 服务化的真实使用经验模型选型、500 错误与下载困局3.1 客服场景到底选什么模型Ollama 能跑的模型很多但客服系统不是越大越好。我先说结论中文客服场景7B 到 14B 量级、对中文支持好的模型是首选。我长期用的是 Qwen 系列qwen2.5:7b在语义理解、指令跟随和多轮一致性上表现都不错显存占用大概 6 到 8 GB普通 16 GB 内存 中端显卡的机器就能跑。如果你只有 CPU那建议降到 3B 或 4B 量级响应速度能维持在可接受范围但回答质量会明显下降。选模型时注意几个关键点一是上下文长度优先选支持 8K 以上的这样多轮对话不容易把上下文撑爆二是看模型对中文长文本的遵从度有些英文模型翻译腔严重客服话术会显得很机械三是一定要先在本地用小样本测试不要只看榜单分数。我踩过一个坑某模型单轮问答得分很高但多轮对话时经常把前几轮的内容遗忘甚至编造用户没说过的话这比单轮不准更致命。3.2 500 internal server error排查笔记很多人在ollama run或通过 API 调用时遇到500 internal server error: llama-server process这类错误我也被折磨过好几天。这里分享一下完整的排查链路。第一步看 Ollama 服务端日志。如果 Ollama 是通过ollama serve启动的日志直接打在终端如果是 systemd 服务用journalctl -u ollama -f查看。日志里通常会写明是内存不足、模型加载失败还是端口冲突。第二步查资源。llama-server 进程崩掉最常见的元凶就是内存不够。7B 模型量化后大约需要 6 GB 内存但加载时需要额外的临时内存跑起来还有 KV cache实际占用可能是模型文件的两到三倍。如果你的机器内存紧张模型加载到一半就会 OOM进程被杀API 返回 500。可以盯着free -h看内存走势确认是物理内存还是 swap 的问题。第三步验证模型文件完整性。长时间下载中断会留下损坏的模型文件加载时会在解析阶段崩溃。在 Ollama 里跑一下ollama list看模型是否正常显示然后删掉模型重新拉取或者手动从镜像站点下载模型文件再导入通常能解决。第四步检查端口和并发配置。你同时起了多个 Ollama 服务、端口被占用或者请求并发太高导致连接池被打满都会表现为 500。Ollama 暴露了几个环境变量OLLAMA_NUM_PARALLEL控制并发处理的请求数默认 1 或 4看版本而定OLLAMA_MAX_LOADED_MODELS控制同时加载的模型数。客服系统会有并发请求建议显式设置合理值比如OLLAMA_NUM_PARALLEL4。3.3 模型下载慢的解决思路镜像与离线导入模型下载慢是本地化部署绕不开的痛点尤其在国内网络环境下。Ollama 默认从官方仓库拉模型速度时常让人崩溃。我的解决思路有三条。第一条是设置OLLAMA_MODELS环境变量把模型目录指到空间充足的磁盘这样不用担心系统盘被几个 5 GB 的模型撑满。第二条是利用国内镜像源下载。Ollama 支持配置镜像地址可通过设置OLLAMA_BASE_URL或修改 registry 配置来实现具体要看版本的官方文档实测能拉高不少。第三是离线导入如果你有一台网络好的机器或者通过其他渠道拿到 GGUF 格式的模型文件就可以在本地写一个Modelfile通过ollama create 模型名 -f Modelfile导入完全不依赖在线下载。离线导入是生产环境最稳的方案。我实际的操作是拿到 GGUF 文件后写一个三行的 Modelfile 指定FROM路径和必要的参数然后执行ollama create等几秒钟就完成了。这样整个部署流程不碰网络可随时上线。3.4 LangChain 对接 Ollama 的两种方式LangChain 对接 Ollama 有两种常见方式。第一种是直接用langchain_ollama包里的ChatOllama它把 Ollama 的/api/chat接口封装成了 LangChain 的 chat model代码写起来非常顺。第二种是对接 Ollama 的 OpenAI 兼容端点。Ollama 本身就暴露了一个/v1的 OpenAI 兼容服务你可以把一个标准 OpenAI 客户端里的base_url改成http://localhost:11434/v1模型名写成你本地拉取的模型名像调用 OpenAI 一样调用本地模型。两种方式怎么选如果你整个项目都是用 LangChain 框架搭建那用ChatOllama最方便chain、memory、retriever 能无缝拼接。如果你还兼着接其他厂商的模型或者想用 OpenAI 生态的工具链比如某些只认 OpenAI 协议的监控、测试框架那/v1方式更通用。我自己做客服系统时是两套都留了切换模型只需要改配置不用动业务代码。4. 客服 Prompt 模板意图识别、兜底话术与检索引用规范4.1 系统提示词的分层设计客服系统的 Prompt 不是一段话就完事的我习惯把系统提示词分成四层。第一层是角色设定。明确告诉模型它是XX 品牌客服助手语气礼貌、简洁、不绕弯。这一层决定了整个回答的调性。第二层是业务规则。比如不提供与售后无关的推荐、涉及价格以官网为准、不承诺无法核实的时效。这些规则必须写死不能指望模型自己悟出来。第三层是当前可用的信息。包括检索到的知识库片段、用户当前问题、系统相关的历史摘要、用户画像变量。这一层是动态拼装的我用模板变量插入。第四层是输出格式约束。客服系统的回复应该是干净的一句话或几句话不要 markdown 语法、不要列表编号、不要根据以上信息这类废话。把这些约束写成一个独立段落模型遵循率会显著提高。层的顺序也有讲究。规则层放在角色层之后、信息层之前模型对前置指令的记忆权重更高能减少检索内容里的表述盖过系统规则的问题。4.2 检索不到答案时的兜底策略多轮客服最怕的不是答错而是编造答案。RAG 检索不到相关内容时模型为了完成回答常常会自由发挥这在客服场景就是合规事故。我的兜底策略分三步。第一步检索时设置相似度阈值低于阈值的检索结果直接丢弃不让模型看到低质量上下文。第二步Prompt 里强制加一条如果参考材料中没有相关信息必须明确回答该问题暂时无法确认建议转人工客服禁止推测或编造。 第三步当一个会话连续两轮都无法从知识库找到答案时系统自动生成转人工工单把用户信息和问题上下文打包递给人工客服。这里有个细节兜底话术不要写死成一句而是根据场景给两三个变体随机选择避免机器人每次都说一模一样的套话被用户反感。同时兜底分支不要只对用户说不知道可以引导用户换一种问法比如您可以试试告诉我商品名称或订单号。4.3 多轮对话中的指令重复与稳定输出多轮对话时长之后模型容易忘记系统指令尤其是上下文被压缩成摘要的时候。我的解决办法是在每次请求的系统提示词里永远带着角色设定和核心规则而不是只依赖会话历史。也就是说系统提示词是每轮都重新拼入的不存储在历史消息里。另一个稳定输出的技巧是消息角色分离。在传给 LangChain 的 messages 里知识库引用的内容不要混在 system 或 user 消息里而是单独用一个固定段落包裹比如用[知识库参考开始]... [知识库参考结束]这样的标记。模型对这种边界标记的遵从度比自然语言高哪些是资料、哪些是用户说的、哪些是可以直接回复的界限清晰后答非所问的概率会大幅下降。我还会在 Prompt 里要求模型如果用户在上一轮已经得到答案而当前问题重复应该提示用户是否还需要其他帮助——这一点能直接改善用户体验避免机器人反复回答同一个问题而不自知。5. 联调测试与性能调优从能跑到敢上线5.1 多轮对话的评测指标体系很多团队把系统做到能回答就宣布完成但客服系统上线之前必须有一套可量化的评测方法。我自己的做法是准备三组测试集第一组是单轮问答覆盖知识库各章节的典型问题第二组是多轮场景比如咨询-追问-改主意-再确认这类真实对话链第三组是恶意和边界输入包括重复提问、乱码、多个意图混合、敏感词试探。评测指标不要只看回答正确率要看四个维度知识命中率回答是否依据检索材料、多轮指代正确率刚才那个能否正确解析、兜底触发准确率该说不知道时说不知道不该说时不说、以及响应延时。这四个维度分开记录能快速定位问题出在检索还是生成还是状态管理。有个实用技巧把测试脚本跑完后的所有对话记录落库定期抽检。你会在真实对话里发现很多预料之外的表达方式这些是优化 Prompt 和知识库切分的第一手素材。5.2 并发与响应速度的实际表现本地模型的并发能力远没有 API 厂商那么轻轻松松。Ollama 默认的并发处理模型是这样的请求进来后如果有空闲的模型实例就直接处理没有就排队。OLLAMA_NUM_PARALLEL调成 4 意味着最多同时处理 4 个请求超出的部分排队。实测下来7B 量级模型在单张入门显卡上单轮生成 200 字左右的回复大约需要 3 到 6 秒。并发 4 路时每一路都会变慢整体吞吐没有线性提升因为 GPU 算力是共享的。如果客服系统要支撑更大的并发单纯调OLLAMA_NUM_PARALLEL不可行更合理的方向是降低生成长度、用流式输出让用户先看到文字在动、或者在前面加一层缓存。5.3 三个提升体验的小改动最后分享三个我实战中验证过的小改动不改架构但体验提升明显。第一个是流式输出。LangChain 的ChatOllama支持streamingTrue响应逐字返回。客服场景里用户对沉默等待最敏感流式返回能把感知延迟从 5 秒降到 1 秒以内效果立竿见影。要做的只是把 API 层改成 SSE 或 WebSocket 转发。第二个是回复缓存。对于高频问题比如退货地址是什么、发货要多久相同问题可以直接命中缓存完全不调模型。可以把用户问题的向量和回答一起存在 Chroma 里或者用一个独立的 KV 缓存。实测高频问题的缓存命中率能有 20% 到 30%相当于免费扩容。第三个是温和降级。当 Ollama 服务过载或掉线时客服系统至少要有一个软失败的着陆点提示系统繁忙请联系客服热线。这个降级逻辑要在网关层写死不能让用户看到堆栈错误。很多项目栽在这上面——模型一挂整个客服入口跟着挂这在生产环境是不能接受的。我个人的体会是本地客服系统的调优是一个持续的过程不可能一次到位。每个版本的 Prompt、切分参数、阈值都要留好版本记录改完参数就跑一遍测试集对比。尤其是多轮对话的逻辑链路测试覆盖再多也不嫌多因为用户在对话里的自由度远超你的预期。希望这篇能帮你把 Ollama Chroma LangChain 这条链路真正用起来有什么更好的做法也欢迎交流。