开头
客服机器人翻车名场面你一定见过：用户问“你们的退款政策是什么”，它一本正经地编了一个“7天无理由退全款，运费自理”，结果工单爆掉，售后骂娘。更离谱的是，你问它“你们公司成立几年了”，它能给你算出“137年”。这不能全怪大模型——GPT 这类模型本质是“接龙大师”，它只负责生成“听起来像人话”的内容，并不负责“内容真实”。想要一个不胡说八道的客服机器人，目前最靠谱的方案就是 RAG（Retrieval-Augmented Generation，检索增强生成）。
RAG 这个技术名字听着唬人，拆开说就一句话：先查资料，再写答案。把企业自己的知识库（产品手册、FAQ、售后政策）拆成小块，建好索引，用户提问时先按语义把最相关的几个片段捞出来，再把这些片段连同问题一起丢给大模型，让它“照着资料作答”。这样模型就不再凭记忆瞎编，而是有据可依。本文适合三类人：想给公司搭内部问答机器人的后端工程师、正在做智能客服产品但被幻觉问题折磨的产品/算法同学、以及刚接触 RAG 想快速落地的个人开发者。我会把原理讲透，再给一套可以直接复制的本地部署实操方案，最后聊几个热搜词背后大家最关心的坑——比如知识库能不能存图片、RAG 的瓶颈到底在哪。
1. 核心思路：RAG 为什么能治“胡说八道”
1.1 先理解大模型为什么会“编”
大模型（LLM）的训练目标是“根据前文预测下一个词”，它学的是语料里的统计规律，不是一个结构化的“事实数据库”。你问它一个它没记住的细节，它不会说“不知道”，而是会基于概率硬生成一个最像样的回答。这就像一个人被临时拉去考试，题目完全没复习过，但他不能交白卷，于是开始编——编出来的东西语法通顺、语气自信，但内容纯属虚构。业界管这叫“幻觉（Hallucination）”，这是所有 LLM 应用的第一个拦路虎。
解决幻觉有三条路线：一是微调（Fine-tuning），把正确答案灌进模型参数里，成本高、更新慢，适合“模型需要学会某种表达风格”的场景，不适合“知识要实时更新”的场景——你不可能每次改一个运费政策就重新训练一次模型。二是提示词约束（Prompt Engineering），在 prompt 里写“请只依据以下资料回答，不知道就说不知道”，但模型往往还是会“忍不住”用训练时学到的常识来补全。第三条就是 RAG，在生成之前先完成一次“开卷考试”——把相关资料放进 prompt，让模型对着资料回答。
RAG 的聪明之处在于它不改变模型本身的“接龙”天性，而是改变它“参考什么来接龙”。这相当于给一个爱自由发挥的员工配了一份标准作业手册，告诉他：答案只能从手册里找，找不到就直说。实测下来，RAG 方案能显著降低幻觉率，配合设计良好的校验逻辑，很多场景下能把“胡说八道”变成“有依据的谨慎回答”。
1.2 RAG 的整体架构不会一次讲完
完整的 RAG 系统可以拆成两条链路：写入链路（Indexing）和读取链路（Inference/Querying）。
写入链路负责把知识库变成可检索的索引，主要步骤有四个：加载文档（Loader）、把长文切成小块（Chunking）、把每个小块转成向量（Embedding）、把向量和原文存进向量数据库（Vector DB）。读取链路负责处理用户问题，也分四步：把用户问题转成向量（Query Embedding）、在向量库里做相似度检索（Retrieval）、把检索到的片段和问题组装成 prompt（Augmentation）、交给 LLM 生成最终回答（Generation）。
第一次搭建的时候，最容易忽略的是“写入”和“读取”之间的质量一致性。很多人把精力全放在检索上，结果发现效果差，回头排查才发现是切块粒度太粗、向量模型不匹配、或者知识库里的原始文档本身格式混乱。记住一个硬道理：RAG 的天花板由“切块质量 + 检索质量”决定，LLM 只是把答案说得好听一点的下游组件。
1.3 检索、增强、生成的三段式设计逻辑
RAG 这个名字里的 A（Augmented，增强）是最容易被轻视的一环。检索回来的片段不是拼在一起塞给大模型就完事了——片段之间可能互相矛盾，片段可能跟问题只有部分相关，片段里还带着噪声。增强这一阶段要做的其实是“整理现场”：把检索结果按相关性排序，去掉跟历史对话冲突的冗余内容，必要时做一次重排序（Rerank）来精挑细选。
生成阶段也不只是“写答案”，还可以接一批约束规则：比如要求模型只使用检索片段中的信息，禁止引用片段外内容；如果检索片段的综合置信度低，直接让模型回答“暂时无法回答”。这种“三段式”设计的好处是每一环可以独立优化：检索不准就换检索策略，片段质量差就调切块，生成效果不满意就换 prompt 甚至换模型。但注意整个系统链路变长了，任何一个环节出问题最终都表现为“回答变烂”，所以排查时要按链路分段定位。
2. 工程实现：切块、向量化与检索链路的落地细节
2.1 信息切块（Chunking）的粒度决策
切块是 RAG 工程里性价比最高的调参点。切块太大，比如把整篇产品手册作为一条，向量化后语义被“平均化”了——用户问“退货运费谁出”，命中一个包含几十个主题的段落，检索分虽然高，但答案淹没在无关信息里，大模型提取不到关键句；切块太小，比如一句话一块，检索倒是精确了，但上下文信息缺失——如果知识库某段话依赖前文定义的术语，单拎出来大模型根本看不懂。常见的经验做法是“按语义边界切”，优先用 markdown 标题、段落、列表等结构标记作为切分依据，而不是硬按字数切。没有结构标记的纯文本，可以按 300–500 字左右一块，每一块之间重叠 50–100 字，确保关键句子不会正好被切成两半。
我在实际项目里一般会先做一个“检索抽样检测”：随便问 20 个真实客服问题，把检索出来的 top-5 片段打印出来人工看一眼，如果片段里明显包含了关键答案，但答案又带着大量无关内容，就说明切块太大；如果片段里只有零碎的半句话，则说明太小。这个工作必须在调 prompt 之前做，否则你后面所有优化都是在“用糟糕的弹药打准仗”。另外要提醒一点，别把 PDF 转换后的文本直接拿来切——很多 PDF 的文本顺序是乱的（尤其多栏排版），需要先做版面清洗，否则切出来的块就是“语无伦次”，检索分数再高也白搭。
2.2 向量化模型的选型逻辑
Embedding 模型负责把文本变成一串数字向量，让语义接近的文本在向量空间里距离更近。选型时注意三个维度：是不是领域匹配、支持的语言、向量维度与存储开销。中文场景下直接拿英文的 OpenAI embedding 来用的效果不会太差，但专业领域（比如医疗、法律、软件报错信息）最好用领域语料微调过的 embedding 模型。本地部署优先考虑 BGE、M3E、GTE 这些开源中文 embedding 模型，它们对中文长文本的支持已经比较成熟。有一个细节：同一个系统里，写入库和查询必须用同一个 embedding 模型，哪怕两个模型的排名指标只差 0.5 个点，换模型后你之前建好的索引全部失效，检索结果会变得一团糟。
向量维度也是一个要提前定好的参数。常见的有 256/384/768/1024 维，维度越高表达力越强，但存储和计算成本也线性上升。个人项目 10 万条以下的知识库，384 维完全够用，没必要为了“追求高端”选 1024 维。另外注意：向量检索默认给的是“字面语义相似”，它分不清“苹果手机”和“苹果水果”这种多义词场景，所以后续要配关键词过滤或重排序来兜底。
2.3 混合检索与重排序（Rerank）
纯靠向量检索在客服场景里会翻车。原因很直接：用户问的问题往往包含产品型号、订单号这类“强标识信息”——比如“订单 A12345 为什么还没发货”，向量检索会优先返回语义上接近“发货延迟”的常见问题，而不是精确命中订单号所在的那条记录。更好的做法是混合检索：用 BM25（经典的词频-逆文档频率关键词检索）跑一遍精确匹配，再用向量检索跑一遍语义匹配，最后把两路结果合并。BM25 对精确编号的把控力很强，向量检索对“话痨式提问”的包容性很强，两个互补之后，召回率能提升一个台阶。
合并之后同样不能直接丢给 LLM，需要重排序。最轻量级的重排序方案是“基于规则的分数融合”：把 BM25 分数和向量相似度分数各自归一化，然后按权重相加，比如 BM25 占 0.4、向量占 0.6，再按总分取 top-k。想要更高质量，可以用专门的重排序模型（比如 Cohere Rerank 或开源的 BGE-reranker），它会逐条判断“这条片段是否真的回答了当前问题”，效果比加权融合好，但多一次模型推理，延迟会高几十到几百毫秒。客服场景对实时性要求高，我个人建议是“先规则融合保证速度，线上效果不达标再上 rerank 模型”，不要一上来就把链路堆得太重。
2.4 提示词（Prompt）组装原则
检索得再好，prompt 组装不到位照样白费。客服问答提示词我总结过几个关键原则：第一，明确角色边界——写“你是某电商平台的客服助手，你的回答必须严格基于以下提供的资料，禁止使用资料之外的信息”；第二，给出“不知道”的出口——写“如果资料中没有明确答案，请直接回答‘抱歉，我暂时无法回答这个问题’，不要尝试猜测”；第三，把资料编号并在回答中引用——比如“【资料1】中提到……”，这既方便用户溯源，也方便你排查是哪条资料导致的错误回答；第四，设置冲突处理规则——如果多条资料内容不一致，优选最新的资料，并在回答中说明“信息存在不一致，以供参考”。
有一种有效的小技巧：把“资料不可用时怎么办”直接写进 prompt 的末尾。很多模型对 prompt 结尾的注意力集中，把关键的“行为约束”放在结尾往往比放在中间更有效。另外，prompt 里的资料块之间要用明显的分隔符隔开（比如三个横线），否则多个片段首尾相连之后，模型可能分不清边界，导致它把两条资料拼在一起生成一个不存在的答案。
3. 零基础可复制的本地 RAG 方案：Ollama + 本地知识库
3.1 为什么推荐 Ollama 作为首发方案
很多人一接触 RAG 就想上云服务，但本地部署有个无可替代的优势：数据不出内网。客服知识库经常包含订单话术、售后政策等敏感信息，丢给第三方 API 本身就构成数据合规风险。Ollama 是一个特别适合本地 RAG 的推理服务，它把模型下载、运行、API 暴露这几个环节都封装得很简单，一条命令就能拉起一个本地大模型。配合开源的向量库（比如 Chroma），可以做到完全离线的 RAG 闭环，成本也就是一台有 8GB 以上显存显卡的电脑（没有显卡，纯 CPU 也能跑，就是慢一些，后续可以优化）。
要不要本地部署，先想清楚两件事：一是隐私和成本，二是你手里有没有一个还不错的 GPU。如果只是个人学习，用云 API 快速验证完全可以；如果是公司内部项目，我强烈建议至少把知识库检索放在内网。Ollama 对显存的要求算是本地部署里比较亲民的，7B 级别的量化模型，8GB 显存就能流畅跑；13B 级别则需要 16GB 左右。没有独显的话，用 CPU 跑 7B 量化模型也能出结果，只是单个回答可能要等 10 秒以上。
3.2 从零开始搭建的完整步骤
先列一下需要准备的组件清单：Ollama（模型推理）、Embedding 模型（负责把文本变向量）、Chroma（向量数据库）、FastAPI（可选，做后端服务）。这里我给出一个最简可行的四步流程。
第一步，安装 Ollama。到官网下载对应系统的安装包，安装后在终端执行ollama pull qwen2.5:7b拉取中文问答主力模型。如果机器性能一般，可以拉qwen2.5:3b或者tinyllama，先跑通流程再升级模型。同时拉一个 embedding 模型：ollama pull nomic-embed-text或ollama pull bge-m3。执行ollama list能看到模型列表，说明环境就绪。
第二步，准备知识库并完成切块与向量化。建议先用几个纯文本文件（.txt 或 .md）练手，比如把常见的 20 条客服问答整理成一个文件。Python 里用现成的库去切块和向量化，示例代码大概是：读取文件，用langchain_text_splitters的RecursiveCharacterTextSplitter按 500 字切块；然后用ollama的 embed 接口给每个块生成向量；把向量连同原文和元数据存进 Chroma。这里提醒一个坑：embedding 接口的参数名叫prompt或input，不同模型不太一样，如果报错先看接口文档，别死磕代码。
第三步，启动本地 LLM 并实现检索问答。写一个 Python 脚本，接收用户问题，先调用 embedding 模型生成向量，在 Chroma 里similarity_search_with_score检索 top-k 片段，然后把“问题 + 片段”组装进 prompt，发给 Ollama 的 chat 接口生成回答。示例代码如下：
import ollama import chromadb chroma_client = chromadb.PersistentClient(path="./kb_chroma") collection = chroma_client.get_or_create_collection(name="cs_faq") def search_knowledge_base(query, top_k=5): query_embedding = ollama.embed(model="bge-m3", input=query)["embeddings"][0] results = collection.query(query_embeddings=[query_embedding], n_results=top_k) return results["documents"][0] def generate_answer(query, docs): context = "\n---\n".join([f"【资料{i+1}】{doc}" for i, doc in enumerate(docs)]) prompt = f"""你是客服助手，请严格基于资料回答问题。 资料： {context} 问题：{query} 如果资料没有答案，请直接说“抱歉，我暂时无法回答”。 """ response = ollama.chat(model="qwen2.5:7b", messages=[{"role": "user", "content": prompt}]) return response["message"]["content"] query = "退货的运费谁出？" docs = search_knowledge_base(query) print(generate_answer(query, docs))第四步，接一个最简单的 Web 界面或 API。不想写前端的话，用 Gradio 两行代码就能起一个聊天界面，把上面的generate_answer包装进去即可。这一步不是必须，但有了交互界面，你才能把真实用户问题扔进去测试检索效果。
3.3 检索效果验证与调参方法
搭完第一个版本，不要急着“上线”，先做一轮效果体检。我习惯从三个维度打分：相关性（返回的片段是不是真的回答了问题）、完整性（关键信息有没有被切块切丢）、准确性（最终回答是否与知识库原意一致）。用 20 个真实客服问题跑一遍，把每个问题的检索片段和最终回答记录下来，按“好/中/差”人工打分，找出系统性的失败模式。
最常见的失败模式是“切块边界把答案劈开”。比如某条政策在原文里分散在不同段落，切块后检索只召回一半，模型就开始编另一半。解决办法有三个方向：加大 chunk 之间的重叠量、把片段 top-k 从 3 调到 5、或者在切块前做一档“段落合并”——如果两个小块在原始文档里相邻且都命中了同一个问题，就把它们合并成一个更大的上下文块给模型。这个“合并”操作在 LangChain 里有现成的ParentDocumentRetriever，但在手写方案里自己实现也就十几行代码，效果立竿见影。
另外强烈建议在本地测试时打印“检索到的片段原文”，不要只看最终回答。因为很多时候模型回答得很漂亮，但答案的依据根本不在片段里——这时候你以为 RAG 成功了，其实是模型又“自由发挥”了，你的系统会在上线后给你惊喜。打印片段这个习惯，几乎能解决你一半的排查时间。
4. 常见问题与排查技巧实录
4.1 RAG 知识库能存图片吗
这是最近问得很多的问题。直接回答：文本检索为主，图片为辅。传统 RAG 的流程是先对文本做 embedding，生成的是文本向量，图片本身没法直接塞进向量库。但客服场景里确实有大量图片资料——产品图、故障截图、流程图，怎么处理？常见方案有两种：一是“图转文”，用 OCR 把图片里的文字提取出来，把文字存进知识库，原图作为附件链接挂在回答里；二是“图文识别模型”，比如用视觉模型（VLM）先给每张图生成一段精确的文字描述，再把这个描述文本当作索引内容。方案二更接近“看图说话”，但推理成本高、延迟大，不适合高并发客服场景。
我自己的建议是：客服知识库里的图片，90% 以上是为了“给人看的附件”，而不是“给模型看的答案”。模型需要的是图片承载的结构化信息——比如“安装步骤图里的顺序说明”，把这些信息用文字整理出来，图片单独存放并在回答时给一个可点击的链接，效果远好于硬让模型去“看图”。如果你真想支持“多模态 RAG”，可以关注较新的多模态 embedding 模型，但目前的工程成熟度和成本控制都还在早期，没有充足理由不建议贸然上。
4.2 切块工具与服务化落地
热搜里“有没有本地的 RAG 文本拆解工具”这个关键词爆出来，说明大家都被“文档解析”这个环节卡住了。推荐工具从简到繁排列：Unstructured 库（支持 PDF/Word/HTML 解析）、MinerU（优秀的开源 PDF 解析工具，对多栏和表格支持很好）、Docling（IBM 开源，能把扫描件走 OCR 流程）。注意一点：解析出来的表格内容，在切块之后往往丢失“行列关系”——如果知识库里的退换货政策是一张表格，你直接按文本切块检索，模型可能答非所问。更稳的做法是“表格单独处理”：识别表格区域，把表头和每行数据拼接成一条结构化文本，再作为一个独立 chunk 索引。
服务化落地也值得多说一句。个人项目可以整条链路写在一个 Python 进程里，但一个正经客服系统要分开组件：文档解析服务、索引构建任务、检索服务、LLM 推理服务。至少要把“索引构建”和“在线检索”分离，否则每更新一次知识库就要重启整个服务，线上体验会很差。索引更新的频率也很有讲究——不要做成每次改一个 FAQ 就全量重建，用“增量更新”只处理变更的文档批次，可以节省大量时间和算力。
4.3 RAG 的瓶颈不在模型，在“隐性上下文”
搜“rag瓶颈”能看到很多抱怨，说“换了更大的模型效果还是稀烂”。以我的经验，RAG 的瓶颈大部分不在 LLM 推理，而在知识库侧，准确说在“上下文重建”这一步。知识库里的原始文本是建立在完整上下文里的，但用户的问题往往只看得到一段孤立文本。举一个具体例子：某知识库原文写“如果遇到货损，请在 48 小时内提交凭证”，用户问“货损怎么处理”，检索可以命中这句话，但原文里没有说明“凭证具体指什么”，于是模型只能泛泛而谈。这不是模型笨，而是知识切片丢失了“定义型上下文”。
应对办法是给知识库“补上下文”。在切块阶段，对每条切片自动生成一个“概况行”，比如“适用范围：生鲜订单；相关定义：货损指运输途中造成的破损或腐烂”，然后把这个概况行作为切片的元数据、一并参与检索或直接附加在切片前。这种做法工程上叫“上下文增强”，它比换更大的模型、调更复杂的 prompt 都管用。另一个角度是“问题改写”：用户的第一轮问题往往很模糊，比如“怎么退款”，系统可以先做意图识别，把它细化成“退款条件、退款流程、退款时间”，再分别检索——很多模糊问题的检索质量，是靠“先把问题变清楚”解决的。
4.4 客服场景里“更新策略”与“归属感”的实操参考
RAG 系统上线后最容易被吐槽的是“知识更新滞后”。客服政策一个月改三次是常态，如果你的索引是每周全量重建一次，那用户的答案就是和现实脱节的。这里给你一个参考策略：高优知识（如售后政策、价格表）按“小时级”增量更新，低优知识（如产品说明书）按“周级”全量重建，更新要有版本号记录。同时建议在回答页面上标注“信息更新时间”，让用户自己有判断力——这个标注动作看起来不起眼，但在实际客服工单里，它能减少至少三成“回答过时”的投诉。
还有一个小细节：每个知识片段可以绑一个“归口负责人”字段，比如“售后政策”这条的负责人是客服主管，“物流说明”这条的负责人是运营组长。当模型反馈“某片段被频繁检索但未被采纳”时，系统可以自动给负责人发一个通知——这其实是在圈出“知识质量差的源头”。客服机器人的胡说八道，很多时候不是模型的锅，而是知识库里原文本身就含混不清。让知识的主人去改原文，而不是让工程师去调 prompt，才是可持续的优化路径。
5. 从“能用”到“好用”的几个进阶方向
RAG 做到“能答对”只是及格线，客服机器人真正的价值在“会解决问题”。进阶方向可以从三个角度展开：第一，把 RAG 从“单轮问答”升级为“多轮对话管理”——用户说“我想退货”，你需要追问“订单号是多少”“哪个商品有问题”，每一轮追问的结果要回填到下一轮检索里。第二，加上“拒答 + 转人工”的双重机制——当检索置信度低于阈值时，不硬答，而是给用户一个转人工的按钮，这比瞎猜更能保护用户体验。第三，做“答案的可解释性”——客服回答附上“依据条目”已经是标配，更进一步可以把依据原文以折叠面板的形式展示给用户，减少“机器人骗我”的观感。
还有一个容易被忽略的方向是“反馈闭环”。在回答下方加一个“这个回答是否有帮助”的按钮，把“否”的样本存下来，定期分析。你可以发现两类问题：一是检索没抓到正确片段，二是正确片段被模型答偏了。两类问题的处理方式完全不同：前者查切块和索引，后者调 prompt 和模型。没有反馈数据的 RAG 系统就像没有仪表盘的汽车，你能开，但不知道什么时候会抛锚。
最后再分享一个我踩过的坑：上线之后，一定要把“用户的原始问法”记录成单独的数据集，而不要只记“模型最终回答”。因为大模型会把问法抽象化——用户明明问的是“你们发什么快递”，记录的却是“物流方式是什么”。如果你拿抽象后的数据去训练检索，检索模型会变得越来越迟钝。我现在的习惯是每次上线都保留一份原始问询日志，每个月挑出高频的真实问法跑一遍检索测试，用它来校验知识库的切块策略是否需要调整。这个做法帮我挡掉了至少三次“看似正常实则在退化”的风险。
RAG 不是什么高深莫测的魔法，它的本质其实是“把数据库查询和自然语言生成接在一起”。工程上多花一点心思在知识处理上，比堆模型参数量有用得多。如果你正打算搭一个客服问答系统，我的建议很简单：先用最轻量级的本地方案跑通全链路，把打印检索片段变成习惯，再用三个月时间沉淀真实问询数据，到时候再谈优化也不迟。
