做客服机器人最怕的不是答不上来而是胡说八道。答不上来用户顶多骂一句“这客服不行”答错了比如把退货政策说成“全场 72 小时极速退款”用户照着操作最后退款被拒那就是实打实的客诉、赔付和口碑翻车。前两年我们把大模型直接接到客服前端热闹了两周就被打回原形——它把“不知道”硬编成“根据规则可以”这就是大家常说的幻觉。后来我把方案改成 RAGRetrieval-Augmented Generation检索增强生成让机器人在开口前先去知识库里查资料、再基于查到的证据作答“胡说八道”的比例才真正被压了下来。这篇文章不聊玄乎的理论只聊我实际落地客服 RAG 时走过的完整流程为什么客服场景必须用 RAG文本拆解、向量化、检索重排这些核心链路里有哪些坑另外给出一套可以用 Ollama 在本地跑起来的零基础教程最后把搜索热词里大家常问的 RAG 瓶颈、图片存储、wiki 对比、ontology RAG 这些问题一并讲清楚。适合正在做客服机器人、知识库问答或者打算在一周内做出第一个可用原型的读者。1. 为什么客服场景离不开 RAG先认清大模型的“失忆”本性1.1 大模型是嘴替不是数据库先说一个很容易被忽略的事实大模型本身不是一个可靠的“数据库”。它训练时候做的事情是反复根据前面几个字预测下一个字把海量文本里的统计规律压进参数里。它确实记住了很多通用知识但一到具体业务就露馅你们公司这版优惠券规则、上周刚更新的退款政策、某个只出现在线下工单文档里的异常处理流程这些内容几乎不会出现在训练数据里。你问它它要么老实说不知道要么为了“体面”从相似话题里胡编一个答案出来。这个为了体面而补脑的毛病就是幻觉。拿人打比方大模型更像一个记忆力惊人但喜欢脑补的同学。你问他圆周率他能背到小数点后几十位你问他“公司食堂今天有什么菜”他没去过食堂却能一本正经告诉你“有红烧肉”。客服场景恰恰处处都是“食堂菜单”——每天都在变而且错了就要赔钱。有人会说那我把业务文档拿去微调fine-tuning不就行了我试过效果不理想。第一业务政策更新太快促销每周都在变微调一次的数据准备、训练、验证、上线周期太长等你训完政策已经又改了一版第二微调后的模型还是给不出证据来源用户追问“哪条政策写了”它回答不了第三微调数据的标注成本不低训不好还容易让模型把旧知识忘掉。所以日常问答我默认不碰微调而是让模型学会“先查资料再回答”。1.2 RAG 基本链路检索、增强、生成RAG 的思路一句话就能讲完别让模型裸答给它配一个可以随时翻阅的资料库。完整链路分两条线离线准备和在线问答。离线取业务文档FAQ、商品手册、政策公告→ 拆成小块文本拆解→ 通过 Embedding 模型把每块转成向量 → 写入向量数据库。在线用户提问 → 同样转成向量 → 在向量库里检索最相似的前 K 块 → 把这几块资料拼进提示词 → 让大模型只根据这些资料生成答案。这么一改相当于从“闭卷默写”变成了“开卷作答”。模型不需要记住每个细节只要检索系统把相关段落找出来它照着提炼就行。更重要的是我们可以在提示词里写死规则如果资料里没有答案就明确说不知道、转人工绝不许编。有了这条规则配合检索阈值机器人才真正具备“知道自己不知道”的能力。选型时可以把三种常见方案放在一起比纯提示词、微调、RAG。方案数据更新结果可溯源工程成本适合场景纯提示词即时写入 prompt但长度有限无最低少量固定规则微调慢要重训无高学习特定说话风格、复杂行为RAG快改文档重索引即可有可返回资料编号中客服问答、企业知识库、实时政策1.3 客服场景的 RAG 不是公版教程能直接抄的网上公开的 RAG 教程大多拿“公司手册”当示例跑通 demo 很容易。但客服场景有三个特殊点直接照抄大概率翻车。多轮对话就是第一个坑。用户说“那能退吗”指的是上一轮聊的商品必须做问题重写把“那”展开成完整描述再去检索否则向量库里根本查不着。第二个坑是知识点变化快。同一个 SKU 在不同渠道、不同时间可能对应不同政策不能只靠全局检索要引入渠道、版本、生效时间这类元数据过滤。第三个坑是后果严重。客服回答是会赔钱的机器人不仅要召回准确还要在没把握的时候敢于拒答、转人工。很多团队把 RAG 当成召回增强器却忘了给它设计“闭嘴规则”这是上线后最容易出事故的地方。2. 核心链路拆解文本拆解、向量化、检索每一步都可能翻车2.1 文本拆解Chunking为什么大家拼命找本地拆解工具为什么非要拆块两个原因。一是 Embedding 模型有输入长度上限超长文档没法直接整体向量化二是检索粒度取决于块大小。块太大向量里混进太多无关信息用户问一句返回的是整本手册匹配精度很惨块太小语义被切断一条完整规则被拆成两半生成端只看到一半照样答错。文本拆解的目标是把长文档切成若干“语义自包含”的小块。对客服文档来说一个理想的块大约是一段完整的规则说明或一个 FAQ 条目而不是半句话。常见策略有三种固定长度 重叠实现最简单适合无结构纯文本但可能在语义中间硬切。结构感知切分按 Markdown 标题、PDF 章节、HTML 标签切并把标题信息保存进块的元数据检索时可以带标题约束。语义切分按句子和段落边界计算相邻句子的语义相似度在语义突变处断开适合长篇幅的手册。“有没有本地的 RAG 文本拆解工具”这是热词里反复出现的问题答案是有而且可以完全离线跑。LangChain 的 RecursiveCharacterTextSplitter、LlamaIndex 的 NodeParser、unstructured 库都是本地开源工具要是文档是扫描件或截图可以先接本地 OCR 把图片转成文字再继续分块。公司内部数据管控严的全程不出内网完全可行。以中文客服 FAQ 为例我常用 chunk_size400中文字符、chunk_overlap60分隔符优先级从段落到句子依次递减。还有一个经验FAQ 如果以 Markdown 表格存在不要按行硬切成碎片最好把整行甚至整张表作为一个块保留“问题—答案”的完整结构检索效果会明显更好。2.2 Embedding 与向量检索选错模型后面全白搭文本拆完块下一步把每块文字变成向量。Embedding 模型做的事情是把一段文字映射到一个高维空间里语义越相近的文本向量距离越近。这就是向量检索能按意思找人的基础。中文场景我优先推荐支持中文的通用向量模型比如 BGE 系列 M3、text2vec 这类硬套英文模型会出现同义词判不出来、分句效果差的问题。选型看两个指标一是输入长度上限二是中文语义评测效果。BGE-M3 的优势是支持长文本和多语言中文客服场景踩坑少。向量数据库的选择也很多我按实际阶段分了三档方案定位适合规模适用阶段FAISS内存式向量索引十万级原型、单机演示Chroma轻量持久化向量库中小规模本地服务Milvus / Qdrant分布式向量库百万级以上生产集群pgvectorPostgreSQL 扩展中大规模已有 PG 的团队检索时除了取 top K必须设相似度阈值。不然知识库里没有相关内容时检索端也会拉出一堆“最不差”的片段模型拿到这些不相干内容反而更容易胡说。我一般先用一批真实问题跑一遍观察命中分数分布再定下限。不同模型打分口径不一样直接照抄网上某个数值很容易踩坑。2.3 “增强”的核心Rerank 重排和元数据过滤向量检索擅长“广撒网”召回但它不是精确匹配偶尔会把意思相近但实际无关的片段排到前面。完善的做法是加一道重排先用向量库快速召回前 20 个候选块再交给专门的 Rerank 模型比如 BGE-Reranker 这类对候选块和问题逐对精算相关性最后只留前 3 到 5 块喂给大模型。这一步投入小、回报大是检索精度再往上一档的关键。另一个容易忽视的环节是元数据过滤。客服知识库里的文档往往带品类、渠道、政策版本、生效时间等标签。检索时先按元数据圈定范围再算向量相似度可以避开“旧版价格串到新版”“A 产品规则串到 B 产品”这类问题。比如用户明确问的是“京东上买的耳机”那就先把渠道字段过滤成京东、品类过滤成耳机再去向量召回速度与准确率都会明显提升。多轮对话方面我通常在检索前加一步问题重写把最近两轮对话压缩成一个完整问题。例如用户说“那能退吗”结合上文重写为“京东购买的入耳式耳机能否七天无理由退货”再进检索。这一步可以用大模型做也可以先用规则和实体词典做后者成本低效果也不差。3. 实操Ollama 本地 RAG 知识库零基础可复制3.1 为什么选 Ollama 本地方案做试点如果你和我一样第一步只是想在一周内跑出能看的客服问答原型我个人最推荐 Ollama 本地方案。理由很朴素不用注册云服务、不用操心业务资料出内网客服数据里那些价格、渠道政策、用户话术放在本地最踏实一台 16G 内存的普通开发机就能跑起来部署链路短出问题好排查。模型层面本地问答我常用 7B 左右量级的模型Embedding 用 bge-m3。如果内存紧张可以换更小的 3B/4B 模型代价主要是长句组织能力下降检索质量不受影响。生产环境再考虑更大 GPU 的模型或接入云端但工程链路完全一致。3.2 完整实现流程可直接照着做第一步安装 Ollama 并拉取模型# 安装 Ollama 后执行 ollama pull qwen2.5:7b-instruct # 问答模型 ollama pull bge-m3 # 中文向量模型第二步文本拆解。我用 LangChain 的切分器优先按段落、再按句子切from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size400, # 中文字符数按文档实测调整 chunk_overlap60, separators[\n\n, \n, 。, , , , , ] ) chunks splitter.split_text(document_text)第三步向量化并写入向量库from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma embeddings OllamaEmbeddings(modelbge-m3) vectorstore Chroma.from_texts( textschunks, embeddingembeddings, persist_directory./kb_chroma )第四步检索并把命中的资料块拼成上下文hits vectorstore.similarity_search_with_score(query, k8) # 过滤掉低于阈值的片段取前 3~5 块作上下文第五步拼提示词并调用模型生成答案。提示词模板我建议直接定死你是一个客服助手。请严格按照以下【背景资料】回答用户问题 1. 只使用资料中出现的信息作答 2. 如果资料中没有答案请直接回复“抱歉我没有查到相关信息已经为你转人工处理”严禁编造 3. 回答时标注资料编号例如资料1。 【背景资料】 {背景资料} 【用户问题】 {用户问题}from langchain_community.llms import Ollama llm Ollama(modelqwen2.5:7b-instruct, temperature0.2) answer llm.invoke(prompt.format(context, question))temperature 不要调高。客服场景的答案必须尽量可预测我常年在 0.1 到 0.3 之间。最后再加一个 FastAPI 接口把 query、命中资料编号、最终答案一起打日志。后面排查线上问题这份日志就是最核心的依据。3.3 验收怎么证明它“不胡说”跑通 demo 不等于能上生产。我上线前先建一个固定评测集至少三类问题知识库里有标准答案的比如 30 条知识库里压根没有答案的比如 10 条用来测试拒答容易诱发幻觉的边界问题比如把两个产品混在一起问、拿已作废的旧政策问。每次改动检索策略都用同一套题跑分对比前后差异。指标含义目标检索命中率标准答案所在块是否出现在 top580% 以上回答准确率人工判断答案正确完整90% 以上幻觉率答案明显无依据或编造越低越好目标小于 5%拒答准确率无答案时是否按规则拒答100%实测下来的基线裸大模型直接上线的幻觉率能到百分之三四十加上 RAG、阈值过滤和重排之后在我的评测集上幻觉率能压到个位数。这说明问题不在模型够不够聪明而在流程够不够严。4. 常见问题、RAG 瓶颈与进阶玩法实录4.1 RAG 的瓶颈到底在哪里大家搜“RAG 瓶颈”说明不止我一个人栽过。我排过原因九成以上的错误答案不是大模型不会编而是检索根本没找对资料。检索端一旦召回不到正确片段生成端拿到残缺甚至无关的上下文胡说就是必然结果。典型的失败场景有三类。一是词面不匹配用户问“运费谁出”文档写“关于退换货运费承担比例的说明”两者没有共同词普通向量检索容易漏需要同义词扩展、问题重写或重排挽救。二是长文本语义稀释用户问“这款耳机防水吗”答案藏在长参数文档的“防护等级 IPX4”那一段光看整体相似度很可能排得太靠后。三是复合问题“我在直播间买的质量有问题找谁”文档把直播间渠道和售后流程分开写单一检索经常顾此失彼需要分治检索再融合答案。针对这类问题进阶做法是 ontology RAG先建一个小型知识图谱列出商品、渠道、政策、售后动作之间的实体关系检索前先做实体识别和关系显式化再带着约束去检索。说白了是让机器先理清对象再去翻资料而不是拿着半句话大海捞针。客服场景的实体关系本来就有限这个方法投入产出比很高。4.2 几个经常把人问住的现实问题“RAG 知识库能存图片吗”分两层看。向量数据库底层存的是向量图片也能用多模态编码模型比如 CLIP 这类转成向量存进去但前提是用户提问也要落在同一个多模态空间里否则两边对不上。更务实的做法是把图片交给 OCR 或图像描述组件转成文本再进普通 RAG表格截图则用表格解析还原成结构化行效果往往比硬塞图片向量更可靠。结论就是能存但对多数客服场景先文本化更划算。“wiki 和 RAG 有什么区别”wiki 是知识内容的组织和承载方式RAG 是问答阶段的检索—生成机制两者不冲突。你可以把 wiki 的每个页面当成 RAG 的数据源也可以把 RAG 变成 wiki 的问答入口。类比一下wiki 是图书馆RAG 是那位先查目录、再翻到对应书页给你答复的管理员。“LangChain4j EasyRAG 好用吗”如果你是 Java/Spring 技术栈不想引入 Python 链路LangChain4j 的 EasyRAG 值得关注。它把嵌入、向量存储、检索、生成封装成可配置的装配管线对已有 Java 服务的企业来说集成成本低。核心原理和上面完全相同只是换了一套语言实现。4.3 一线故障排查速查表症状常见原因处理手段答非所问检索没召回相关块调大 topK、缩小 chunk、加重排、加问题重写有资料但答错检索到错误片段或旧版本加元数据过滤按渠道、品类、版本圈定范围一本正经编造阈值太低无关块混入生成提高相似度阈值prompt 强制无据拒答新政策不生效向量库还是旧索引做增量索引任务文档更新后重建对应块文档之间互相矛盾知识冲突加版本和优先级字段检索结果按优先级排序响应慢检索和生成都耗时热问题缓存、减少 topK、模型量化以上每一条我都实际遇到过印象最深的是“有资料但答错”。当时 FAQ 里明明有正确答案线上却反复答错查日志发现检索到的始终是旧版政策文档。加了版本号和生效日期做元数据过滤之后这个坑才彻底填上。4.4 从客服问答走向客服智能体RAG 结构稳定以后下一步是把它嵌进更大的客服智能体里。常见做法是把知识检索当成一个工具智能体先判断意图——问候、查物流、退换货、转人工查政策走 RAG查订单调内部 API两边都处理不了再转人工。同时把每一次“检索了哪些资料、模型怎么回答、用户有没有投诉”都记录下来每周回头查一次误答率和拒答率持续反哺知识库维护。我个人在实际操作中最大的体会是客服机器人可信度不是“模型大”给的而是“流程严”给的。把检索质量做扎实把“不知道就拒答”的规则焊死再把评测集长期跑起来小模型也能做得非常可靠。最后分享一个小技巧把每个答案命中的资料编号连同回答一起返回给前端坐席同事看到编号就能人工复核。这一步是让业务方信任机器人最有效的动作没有之一。