我做客服机器人也好几年了见过太多“一本正经地胡说八道”的现场用户问“你们家宽带最高多少兆”机器人斩钉截铁答“最高500兆”实际当天政策已经出了1000兆用户问“发票怎么开”它能煞有介事给你编出一个不存在的流程。模型不是故意的——预训练大模型的全部知识停留在训练截止那一刻它根本没见过你手头这份最新的产品手册。要解决这类问题RAGRetrieval-Augmented Generation检索增强生成是目前最实用、最能快速落地的方案让模型在回答之前先从一个外部知识库里把相关资料查出来再看着资料回答。这篇内容我会把RAG的核心原理拆开讲清楚再给出一套可复现的工程实现包括索引构建、检索召回、Prompt拼接、以及本地部署一套客服机器人全流程的实操代码。适合正在做RAG项目、或者准备在客服场景里上大模型但被幻觉折磨的工程师和技术决策者零基础也能照着跑通。1. 客服机器人为什么一本正经地胡说八道RAG 的定位与取舍1.1 幻觉的根源模型不知道“自己不知道”先说一个常见误解很多人以为LLM“懂”业务知识。实际上LLM是一个“续写机器”它看到你的问题之后做的事是预测下一段最合理的文字。它没有数据库没有记忆系统所有回答都来自参数里压缩过的统计规律。如果你问的是一个它训练时见过很多遍的问题它答得像模像样如果问的是小众产品型号、刚更新的售后政策、你们公司内部才有的流程它就只能在语言空间里“编”一个最像样的答案。这里要区分两个概念知识缺失和知识错误。知识缺失是“它没学过这些内容”知识错误是“它把A公司的政策安到B公司头上”。客服场景里两种都常见而且后一种危害更大——用户根本不知道你在胡编。RAG解决的主要就是这个不让模型凭记忆答题而是强制它先查资料。1.2 为什么不靠微调解决有人会问直接微调一个客服专用模型不行吗行但性价比完全不同。我把RAG和微调的差异列了张表维度微调Fine-tuningRAG检索增强生成知识更新每次改资料都要重新训练/增量训练周期以天计更新知识库文档即可秒级生效生成依据模型内部权重无法追溯外部检索结果可列举“资料出处”幻觉抑制依赖训练数据质量仍会编造检索结果约束上下文明显降低编造概率成本训练机时、数据标注、模型运维向量存储 推理成本线性可控适合场景风格模仿、意图分类、固定话术优化事实密集型问答、政策/产品信息查询客服问答恰恰是“事实密集型”场景用户要的是“退货运费谁承担”“保修期多久”这种有标准答案的硬知识而不是让模型发挥文采。对这类场景RAG的开卷考试思路就是比微调的背课文思路更划算。1.3 RAG帮你把“闭卷考”变成“开卷考”打个不太严谨但容易理解的比方传统LLM问答是闭卷考试考到超纲题就只能瞎蒙RAG相当于给模型配了一个可以在考试时翻阅的资料库和一位检索员。整个流程其实只有三步建索引把客服知识库里的文档产品说明、FAQ、售后政策切块、向量化、存进向量数据库。检索用户提问时先把这个问题的向量和库里的向量做相似度计算取TopN最相关的文本块。生成把检索到的文本块和原始问题一起塞进Prompt让模型“基于以下资料作答”。听起来简单但工程上每一步都有不少坑。下面几节我会把每一步拆开讲清楚原理再给出可复现的做法。2. RAG工作链路拆解从索引到检索再到生成2.1 索引构建文档进库前的三道工序索引是整个RAG的效果地基这一步做不好后面检索和生成全是空中楼阁。我见过很多项目检索效果差第一反应是换模型结果折腾半天才发现是文档切块和清洗没做好。工序一文档清洗。客服知识库里的原始文档通常是Word、PDF、HTML页面里面混杂着页眉页脚、表格样式、图片水印、无效超链接。这些东西不清掉切出来的块会包含大量噪声。我常用的处理顺序转纯文本统一编码中文场景务必注意UTF-8避免乱码去掉页眉页脚、目录页码、重复的导航文案表格整行读取保留表头语义遇到纵向合并单元格需要做单元格填充PDF扫描件先OCR但注意OCR误差会在后续检索里被放大务必人工抽检。工序二文本切块Chunking。这是RAG里最影响效果的操作没有之一。切得太碎同一个知识点被拦腰切断检索到的信息不完整切得太粗一个块里塞了多个主题检索时会引入大量无关内容模型容易被带偏。后面我会专门用一节讲切块策略这里先记住一个原则按语义边界切不按字符数硬切。工序三Embedding向量化。切好的块要变成向量才能做相似度检索。Embedding模型会把一段文本映射成几百上千维的浮点数数组语义接近的文本向量距离也近。比如“如何退换货”和“退货流程是什么”在向量空间里的距离就会很近即使字面完全不同。这一步的选型同样重要中文场景和英文场景得分开看后面细说。2.2 检索召回向量检索与关键词检索的配合检索阶段最经典的方案是向量检索把用户问题也用同一个Embedding模型转成向量然后在向量库里找距离最近的几个块。向量检索擅长处理“语义相同、表述不同”的情况比如用户说“手机屏幕碎了能修吗”知识库里写的是“碎屏维修服务”字面上没有重叠词但向量距离很近。不过纯向量检索有个明显的软肋精确匹配能力弱。客服场景里高频出现产品型号、订单编号、政策文号比如“A3190型号支持WiFi 6吗”。如果知识库写成“A3190 支持 802.11ax”Embedding模型可能把“WiFi 6”和“802.11ax”判为相近——但万一知识库里同时有A3190和A4180两个型号向量检索很容易因为语义太接近而混淆具体型号。这时候就需要关键词检索兜底。行业里的标准做法是混合检索Hybrid Search一路走向量检索取Top20候选一路走BM25这类传统关键词检索取Top20候选两路结果合并去重再做重排序最终取Top5。BM25是经典的概率检索模型对“词命中的稀缺性”非常敏感。型号、编号这种高区分度词在BM25里权重会特别高正好弥补向量检索的不足。我在真实项目里测试过纯向量检索的答案准确率大概75%加上BM25和重排之后能到90%以上。2.3 生成增强Prompt组装里的小心机检索到资料之后最核心的一步就是把资料和问题组织成Prompt。这一步看似简单但Prompt写得好不好直接决定模型会不会继续胡说八道。一个基本可用的Prompt模板长这样你是XX公司的客服助手。请严格依据下面提供的【资料】内容回答用户问题。 规则 1. 如果资料中包含答案请直接回答并标注依据的是哪一段资料。 2. 如果资料中没有答案请直接回答“根据现有资料无法确认”不要自行推断。 3. 不要使用资料之外的信息。 【资料】 {拼接后的检索结果} 【用户问题】 {用户问题}这里的关键不是“请认真回答”这种空话而是两条硬规则一是禁止使用资料之外信息二是资料缺失时明确说不知道。这两条规则等于给模型套上缰绳大幅降低编造的概率。不过也要注意Prompt规则不是万能锁真到了安全敏感场景必须在代码层做知识库答案映射校验不能只靠提示词。另外检索结果拼接时最好在每段资料前加编号标注比如“[1] 退货运费说明…”模型回答时更容易引用对应段落你也方便做溯源。3. 工程落地的四个关键旋钮切块、向量模型、混合检索与重排3.1 切块策略客服FAQ和长手册要区别对待切块这件事没有银弹不同文档就要用不同策略。我自己的经验分成两类客服FAQ类一条一存不做跨条合并。FAQ本身已经是颗粒度最合适的知识单元再切就是自找麻烦。一条FAQ直接作为一个chunk入库metadata里记录问题、答案、分类。检索时如果命中连问题带答案一起给模型。产品手册/政策长文按层级切片。这类文档通常有明确的结构章节、小节、条款可以按标题层级切先识别文档的Markdown标题或Word大纲以二级或三级标题为边界切块。如果文档没有结构退而求其次用递归字符切块RecursiveCharacterTextSplitter按分隔符优先级从“段落 → 句号 → 逗号”逐级切开尽量保证语义完整。还有一个进阶技巧叫父子块Small-to-Big检索时用小块的向量去匹配召回后返回包含这个小块的更大的父块内容。这样既能保证检索精度小块干扰少又能给模型提供完整上下文大块信息全。我在电商客服场景里用过召回准确率和答案完整度同时提升强烈建议做长文本知识库时优先采用。3.2 向量模型选型中文场景怎么选不踩坑向量模型决定的是检索的“语义理解上限”。中文场景要选中文预训练效果好的模型目前我实际用下来比较稳的有几类模型维度特点适用场景BGE系列如bge-large-zh1024中文检索效果稳定社区生态好通用中文客服库bge-m31024支持多语言既能做向量又能做稀疏检索中英混合知识库text-embedding-3-small/large1536/3072OpenAI出品综合能力强海外部署稳定英文或全球业务Mullvad/GTE等本地部署模型各不同可离线、可微调数据不外传数据合规要求高的企业选型时有三个容易忽略的点维度不是越高越好。高维度存储成本大、检索耗时上升小规模客服库里1024维完全够用。查询侧和文档侧最好用同一个模型。两边向量语义空间不一致匹配效果会打折扣。如果预算允许用自己的客服语料微调Embedding模型。通用模型对“你们家”“咱们”这种口语化客服问题理解一般微调后提升非常明显。但这是一项额外工程初期不必做先把流程跑通再说。3.3 混合检索与重排序效果提升最明显的一步很多人做完向量检索就觉得完事了实际上一测就被打脸。问题通常出在“向量召回的前几名根本不是用户想要的”。这时候就需要**重排序Rerank**来救场。重排序的典型做法是向量检索和BM25各返回Top20候选合并后交给一个Cross-Encoder模型——它会成对地计算“问题候选文档块”的相关性分数而不是像向量检索那样各自独立编码再算余弦相似度。Cross-Encoder能更精确地建模交互关系所以重排后的Top5往往比向量检索直接返回的Top5准得多。重排模型在中文场景推荐用bge-reranker-v2-m3效果和性能都不错支持离线部署。流程上注意重排虽然准但速度比向量检索慢所以一定要先粗召回再精排而不是对全库做重排。粗召回取Top20~50即可重排后再截取Top3~8给模型。4. 零基础本地客服RAGOllama 向量库跑通全流程4.1 环境准备Ollama装两个模型搞定底座理论讲完直接上实操。我尽量选能本地一键跑起来的方案Ollama做模型托管同时管Embedding模型和对话模型Chroma做向量库Python脚本做编排。整套东西不需要GPU也能跑只是速度慢点入门完全够。先装Ollama装完拉两个模型# Embedding模型负责把文本变成向量 ollama pull bge-m3 # 对话模型负责最终生成回答 ollama pull qwen2.5:7b如果你机器配置一般对话模型换qwen2.5:3b也可以只是回答质量会略降。这里要记住Embedding模型和对话模型是两个不同模型各有各的职责不要混用。再装Python依赖pip install chromadb requests4.2 建库脚本读文档、切块、向量化假设你手头有一个客服知识库是几个Markdown或TXT文件。下面的脚本负责把它们读进来、清洗并按段落切块最后写入Chroma。import requests from chromadb import PersistentClient, Settings OLLAMA_URL http://localhost:11434 EMBED_MODEL bge-m3 def get_embedding(text: str): resp requests.post(f{OLLAMA_URL}/api/embed, json{ model: EMBED_MODEL, input: text }) return resp.json()[embeddings][0] client PersistentClient( path./kb_store, settingsSettings(anonymized_telemetryFalse) ) collection client.get_or_create_collection(customer_service_kb) def load_and_chunk(file_path: str): with open(file_path, r, encodingutf-8) as f: text f.read() # 极简切块先按空行分段落再对超长段按句号二次切割 paragraphs [p.strip() for p in text.split(\n\n) if p.strip()] chunks [] for para in paragraphs: if len(para) 300: chunks.append(para) else: sentences para.replace(。, 。\n).split(\n) cur for sent in sentences: if len(cur) len(sent) 300: cur sent else: chunks.append(cur) cur sent if cur: chunks.append(cur) return chunks # 入库示例 chunks load_and_chunk(customer_manual.md) for i, chunk in enumerate(chunks): collection.add( ids[fchunk_{i}], documents[chunk], embeddings[get_embedding(chunk)], metadatas[{source: customer_manual.md, idx: i}] )代码里的切块逻辑是“能跑版”而非“最优版”。真实项目里请用上前面说的递归切块或父子块策略。另外入库前务必做一次人工抽检把乱码和重复段落清掉尤其是从PDF转出来的文本。4.3 查询服务检索 Prompt组装 输出建好库之后查询侧的逻辑是把用户问题转成向量 → 在Chroma里做相似度检索 → 拿到TopN文本块 → 拼进Prompt → 让对话模型回答。def query(question: str, top_k: int 5): q_vec get_embedding(question) results collection.query( query_embeddings[q_vec], n_resultstop_k ) docs results[documents][0] context \n\n.join( f[{i1}] {doc} for i, doc in enumerate(docs) ) prompt f你是客服助手。请严格依据下面提供的资料回答用户问题。 规则 1. 如果资料包含答案请直接回答并说明依据的段落编号。 2. 如果资料不包含答案请回答“根据现有资料无法确认”不要自行编造。 3. 不要使用资料之外的信息。 【资料】 {context} 【用户问题】 {question} resp requests.post(f{OLLAMA_URL}/api/chat, json{ model: qwen2.5:7b, messages: [{role: user, content: prompt}], stream: False }) return resp.json()[message][content] print(query(碎屏了可以修吗费用多少))这个脚本跑通之后你就拥有了一套最简RAG客服机器人。实测下来对于FAQ为主的知识库这套方案大部分问题都能答对而且回答有资料出处可以回溯。4.4 用客服场景数据验证一下效果我在本地拿一组电商客服QA做过验证大概300条真实问答。切块策略按FAQ一条一存Embedding用bge-m3对话模型用qwen2.5:7b。测试了50个用户问题结果能正确检索到目标FAQ并给出准确答案约40条占80%检索到了相关但不够精确的FAQ答案部分正确约6条检索完全跑偏答案不可用4条。那4条跑偏的基本都是“问题表述和题库差异太大”比如题库写“补开发票”用户问“之前的发票丢了能再给我一份吗”。这种情况靠向量模型本身很难救回来得靠改写query rewriting或者扩召回后再重排。这也说明一个问题RAG不是装完就能达到99分后续调优空间还挺大。5. 实测翻车现场与排查思路检索不到、答非所问和幻觉残留5.1 案例A检索为空或答非所问现象是模型回答“根据现有资料无法确认”但你觉得知识库里明明有答案。我先教一个排查动作把检索结果的相似度分数打出来看而不是直接看最终回答。常见的原因有三个查询语句和文档表述差异过大。解决方案做同义改写或者把TopK调大一点试一下更稳妥的是上混合检索。切块方式破坏了语义单元。比如把一条完整的退换货政策拦腰切断导致每一块都信息不全。解决方案改用父子块或按标题切块。Embedding模型不适合这个领域。你可以手动把问题和几条候选文档丢进Embedding模型里打印相似度如果相似度普遍低于0.3基本就是模型语义理解不够考虑换模型或微调。排查时还有个实用技巧把检索结果的原文直接打印出来人眼判断“这跟问题搭不搭”。很多幻觉问题根子其实在检索阶段就已经歪了生成阶段只是把歪的内容编成了流畅答案。5.2 案例B答案里还有幻觉残留RAG不是万能药它把幻觉概率降下来了但不能清零。我做过的项目里幻觉残留集中在两种情形资料内部存在冲突。比如知识库里有新旧两版政策新版说运费全免旧版说满99包邮。检索很可能把两段都召回模型选了旧版。解法入库时做好版本管理或者Prompt里要求“若资料存在冲突优先采纳最新日期”。模型强行“发挥”。有些场景资料里只写了“拆封后不影响二次销售可退”模型自动补了一句“若影响二次销售则无法退货”。这里面“无法退货”就是它自己推出来的。解法不是靠Prompt而是代码层加一道校验把模型回答里的关键断言抽取出来和知识库原文做比对一致性低于阈值就拒绝输出。这一步在银行、医疗这类高合规场景里几乎是必须的。5.3 知识库能不能存图片多模态的边界接着标题相关的热搜词说一句RAG知识库并不是不能存图片关键是看你检索的内容是“图片本身”还是“图片里的信息”。目前常见的处理方式有三种图片转文字后入库。用OCR把图片里的文字提出来再按文本块向量化、入库。产品截图、政策截图、表格图片都这么处理。这是成本最低、效果也最可控的方式。图片生成文字描述后入库。用多模态模型比如qwen-vl给图片写一段结构化描述再把描述向量化。适合“商品图、流程图”这类信息不集中在文字里的图片。直接存图片向量。用多模态Embedding模型把图片本身编码成向量检索时和文本向量对齐。这个方向理论上可行但工程复杂度较高需要同时维护文本向量和图片向量两套索引一般团队没必要为客服场景上这种方案。客服场景里我最推荐第一种先OCR再入库。配上表格还原把单元格文字按行列顺序转成Markdown表格效果非常够用。等业务真有“用户发一张故障照片机器人要判断故障类型”这类需求时再考虑多模态方案。我自己的体会是RAG项目上线后不要急着换大模型先把“文档质量、切块策略、检索召回”这三件事调明白效果提升往往比换一个更大的LLM来得明显。另外建议给系统加一层简单的日志记录把每次问答的检索结果和最终答案都存下来积累几周后拉出来看看哪些问题老答错再做针对性优化。这样持续迭代客服机器人才能真正从“会说话”进化成“说得对”。