1. 为什么检索增强能管住大模型那张嘴先聊一个很多团队都撞过的墙把通用大模型直接丢到客服场景里前面三句话客客气气第四句话开始一本正经地编政策。用户问退货邮费谁出模型说根据《消费者权益保护法》第二十五条您需要自行承担实际上你们公司的规则是七天无理由退货平台补贴运费险。客户拿着截图来投诉你还没法反驳——因为大模型确实引经据典了只是引的是它自己脑子里编出来的经。这不是模型笨是生成式模型的结构性缺陷它天生是个概率预测器不是事实查询器。GPT也好、其他开源模型也好训练时的目标函数是下一个词最可能是什么不是这句话在事实层面对不对。所以当知识库里根本没有答案时它不会老实说不知道而是会顺着语言惯性编一个最像答案的东西出来。这就是所谓的幻觉hallucination。RAGRetrieval-Augmented Generation检索增强生成的核心思路非常朴素既然模型容易瞎编那就别让它裸奔回答问题。在模型开口之前先从一个可信的知识库里把相关材料捞出来把答案的事实依据喂给模型让模型基于这些材料做概括和重组而不是凭空生成。用一句大白话说RAG就是给大模型开卷考试而不是闭卷考试。这个思路在客服场景里尤其合适。客服问答的特点是高确定性退货政策、物流时效、售后流程这些东西都是白纸黑字的固定内容不需要模型发挥创意只需要模型准确定位并忠实转述。RAG把知识存储从模型的参数里搬到了外部数据库里知识更新不用重新训练模型改一条文档下次提问立刻生效。我见过很多团队在没搞懂这个逻辑之前就急着上RAG结果做出来的东西该胡说还是胡说。根源在于他们把RAG当成一个魔法盒子——文档扔进去答案就对了。实际上RAG是一条完整的工程链路每个环节都可能成为胡说八道的源头。这篇文章把我做客服机器人时踩过的坑、调过的参、验证过的方法完整写下来从原理到工程实现尽量说透。2. 客服机器人RAG的工程骨架从文档入库到答案生成一个能给客服用的RAG系统至少包含五个环节知识入库、文本切块、向量化与存储、检索召回、答案生成。每个环节都有一堆细节但先把整体骨架搭起来后面再逐个优化。2.1 知识库选型向量库、知识图谱库和结构化库到底什么关系很多初次接触RAG的人会困惑知识库到底该用哪种热词里出现的kg知识库结构知识库向量知识库到底有什么区别。我直接说结论都是知识库但管的是不同颗粒度的知识适用场景不同。类型存储形式擅长回答的问题典型工具向量库文本切块后的embedding向量语义相近的片段检索模糊找内容Milvus、Weaviate、pgvector、Qdrant知识图谱库实体和关系的三元组多跳推理A和B什么关系Neo4j搭配LLM做三元组抽取结构化库字段和值精确查值订单号xxx的状态MySQL、PostgreSQL、Doris客服场景中九成以上的问题是这个政策原文是什么属于典型的向量库场景。但如果你做的是复杂业务流转比如用户问退款但退款规则又和会员等级、商品类目、是否超时三个条件相关那纯向量检索很容易漏条件——这种场景建议在向量库之外再叠加一层结构化规则或者知识图谱。工程上没有那么多的非此即彼更多是组合使用。我们的第一版就是从纯向量库起步的后面才逐步加了订单上下文的结构化查询。关于热度很高的ontology RAG本质是在向量检索之外用本体论ontology定义实体、属性、关系让检索时能借助显式的语义约束缩小范围。比如运费险和退货运费是两个强关联实体ontology告诉系统它们之间存在覆盖关系这在处理客服长尾问题时确实有用。但代价是构建和维护ontology的人工成本很高小团队建议先不做等向量检索的瓶颈真实出现时再引入。2.2 文档解析格式杂乱的客服知识怎么变成干净文本客服知识库的源文件通常惨不忍睹有Word里粘贴的公告、PDF扫描件、Excel的价目表、HTML的活动页面截图甚至还有一堆用特殊符号分隔的表格。这一步如果做不好后面全白搭。我建议按格式优先级来规划解析链路PDF/Word优先用具备布局分析能力的解析器把表格、页眉页脚、多栏布局分开处理。表格是最容易出问题的地方——很多解析器会把一个表格拆成一堆不连贯的文本碎片。我踩过这个坑某个售后政策表格被解析成了7天—仅换不修—用户需保证商品完好这样割裂的碎片检索时完全无法召回。后来改用基于视觉的文档解析模型如PP-Structure这类开源方案表格会被整体识别并转成Markdown格式召回率立刻上去一截。Excel不建议整表嵌入建议按行列拆成条目粒度。比如一张运费说明表把它拆成[地区, 运费, 时效, 是否包邮]这样一条条的记录每个记录独立切块。网页/活动页先转成纯文本再人工过一遍目录结构。网页里大量导航、推荐链接、脚本内容直接切块会污染向量空间检索时容易召回一堆无关页面。关于热词里那个有没有本地的rag文本拆解工具——答案是有而且有很多。除开商业的API本地可跑的方案我试过Unstructured、LangChain的文档加载器、以及上面提到的PP-Structure。我的建议是不要迷信单一工具做一个简单的效果对比拿你们自己的50份真实客服文档人工标注该切出多少块看哪个工具丢内容最少、表格还原最好。这一步半小时就能测完比后面上线后反复调效果划算得多。还有RAG知识库能存储图片吗这个问题。能但要分清存储什么。如果图片是纯装饰不用管如果图片里包含关键信息比如流程图、价目表截图两种方案一是用OCR把图片文字提取成文本再入库二是用多模态模型把图片转成视觉描述文本再入库。实测下来OCR对表格类图片效果好多模态描述对流程图和示意图效果好。建议客服场景优先OCR因为客服文档里的图片大多是表格扫描件。2.3 框架选型LangChain、LlamaIndex还是自己拼这是个会被反复问的问题。我的看法LangChain生态最全文档多但抽象层太厚出问题时排查链路长。适合快速原型验证。LlamaIndex对文档到检索这条链路做了深度优化索引机制比LangChain精致适合核心就是做文档问答的项目。Haystack结构化程度高生产部署友好但社区相对小。如果团队有后端开发能力我强烈建议核心检索链路由自己写。不是说我有多大的架子而是客服系统上线后一定会有各种定制需求权限过滤、敏感词拦截、多轮对话改写、日志追溯。框架封装好的流程一旦要打破成本远高于自己维护那几百行代码。最终我们生产环境是自己写管线 用框架的解码工具类切块用LangChain的TextSplitter向量库直接用Milvus的客户端编排逻辑全部自研。这样出了问题能单步调试谁改了逻辑一目了然。3. 切块和向量化召回质量的地基工程如果让我排RAG工程中最容易让人崩溃的环节切块稳稳排第一。切大了检索返回的内容颗粒度过粗混着一堆无关信息切小了语义碎片化单个块没头没尾生成时模型也拼不出来。3.1 切块策略固定大小、语义边界还是父子分块常用的三种策略固定大小切块比如每256个字符切一块相邻块重叠50个字符。实现最简单但对自然语言不友好——一个句子的后半句可能跑到下一个块里。语义边界切块按段落、句子、标题等自然边界切。客服文档里每个问答对或政策条款天然是一个语义单元按段落边界切是最稳妥的。实操中我会先用正则把文档按标题级别h1/h2/h3分割再在每个标题下按段落切。这个策略对客服场景效果最好。父子分块每个切块既保留小块的精确文本又关联一个大块的上下文窗口。比如小块是7天无理由退货父块是包含它的整节政策说明。检索时命中小块但把父块一并交给生成模型。这个策略对回答这句话的前因后果类问题有奇效但会显著增加token消耗。我建议从语义边界切块起步而不是一上来就堆高级技巧。一个实际经验切块大小会直接影响召回率曲线的形状。块越小单块语义越聚焦但被query命中时上下文就越不足块越大上下文充足但噪声也多。我们最终的方案是按标题段落边界切单块控制在200~500个中文字符重叠20~50字。这个参数不是拍脑袋定的是用标注好的测试集以10%步长扫出来再选的。3.2 Embedding模型选型与向量距离不代表语义距离的坑向量检索的本质是把文本embedding成高维向量然后用距离度量相似度。但这个环节有三个容易踩的坑第一Embedding模型的能力直接决定上限。用开源的通用中文Embedding模型和用面向客服领域微调过的模型检索准确率差10个点以上是常态。市面上比较好用的开源中文模型有BGE系列、M3E系列商用的有OpenAI的text-embedding-3、Cohere的embed模型等。实测结论中文场景强烈建议优先测BGE系列和M3E系列它们在金融、政务、客服这些中文语料上的表现基本是第一梯队。第二向量相似度不等于语义正确。余弦相似度高的两个句子可能仅仅是句式相似、用词相近但表达的意思完全相反支持7天无理由和不支持7天无理由只差一个字向量距离却可能很近。这是纯向量检索的硬伤解决方法是后面要在检索阶段做逻辑层面的校验和重排不能只依赖向量距离。第三Embedding是有尺度的。同样的阈值0.7在一个模型上是强相关在另一个模型上可能毫无关联。做相似度过滤时务必先跑一批标注样本画出相似度分数-相关性的分布曲线再去选阈值。我见过最荒唐的排查案例是检索回来的top 5全部是垃圾工程师花了三天调参数最后发现是Embedding模型换过之后旧阈值0.8在新模型下把一切接近的结果都拒之门外了。3.3 文档切块后的清洗与元数据管理切块不是切完就完事。每个块最好带上元数据这是被很多人忽略但对客服场景至关重要的设计。至少包含来源文档ID、标题路径、更新时间、权限级别。有了这些字段你才能做后续的按权限过滤按产品线隔离按文档版本淘汰也才能在出问题时快速追溯到原始文档。另外切块后的清洗也值得说一句。客服文档里大量存在以上内容最终解释权归XX所有、如有疑问请联系客服热线400-xxx这类公共尾巴。我用正则把这类模式统一剥离否则这些公共尾巴会出现在几百个块里检索时疯狂干扰排序。清洗顺序建议是去HTML标签→转码统一→去掉尾部公共信息→按边界切块。4. 检索不只是向量混合召回与重排的实战调优很多初版RAG只做到了用向量检索召回top5扔给模型生成效果不好就怀疑模型不行。实际上检索这步的优化空间极大而且往往是性价比最高的优化点。4.1 为什么要做混合检索向量找相似关键词找精确向量检索擅长找言下之意但对精确数字、商品型号、政策编号这类信息很容易翻车。举个例子用户问MB-2200耳机怎么配对向量检索可能召回到一堆关于耳机配对的通用内容但完全没意识到MB-2200这个型号才是关键限定词。而关键词检索BM25对精确匹配很敏感但理解不了同义表达。所以成熟的做法是向量检索BM25混合召回把两种检索结果按分数融合后排序。融合公式我用过RRFReciprocal Rank Fusion简单说就是取每条结果在两个检索系统中的排名按1/(krank)算融合分。这个公式不需要统一各系统的分数尺度是工程上最省心的做法。k一般取60实测效果好。客服领域的另一个重要技巧是实体词优先把用户query先做一次实体识别提取型号、订单号、地名、人名等关键实体。检索时可以让这些实体在召回命中中拥有一票否决权——只要某个块完全不含这个实体直接降权。这个规则简单但效果惊人我们自建了一个20个正则和关键词组合的实体识别器就够用不需要上复杂的NLP模型。4.2 Rerank重排把相关变成最有用向量检索召回top50后直接让生成模型看50个块不现实token消耗太大且噪声多。这时需要Rerank。Rerank模型会把query和候选块做深度交叉编码输出一个精准的相关性分数。它的计算开销比向量检索大但精度远超。常用方案bge-reranker系列开源模型或者商业的Cohere Rerank。实测bge-reranker-base在客服中文语料上把top5准确率提升约8~10个点。重排策略的实操经验向量检索召回50条 → 粗过滤掉分数过低的 → Rerank取top5 → 生成。不要追求召回100条再RerankRerank是有计算成本的响应延迟会线性上升。客服场景的合理目标是把端到端延迟控制在2~3秒内所以尽可能在召回阶段就把候选压缩到50条以内。4.3 重排后的无答案识别宁可不答不要错答对客服机器人来说不会胡说的第一要义是知道什么时候该闭嘴。重排后如果最高分的块与query的相关性仍然很低应该直接走拒答流程——转人工、或给出抱歉暂未找到相关信息的标准回复而不是硬生成。这个拒答阈值怎么定不要拍脑袋。我用的是双阈值策略Rerank分数高于0.7 → 正常回答分数在0.4~0.7 → 进入二次校验检查是否有明显关键词冲突低于0.4 → 拒答。阈值要从真实的badcase里标定我们当时从一万条真实客服日志里抽出300条问题标注知识库里有答案和没有答案两类跑一遍RAG画出分数分布在两个分布的交叉点附近取阈值。之后每隔两周用新badcase复盘一次持续微调。5. 上下文组装与闭嘴机制让机器人知道什么时候该说不知道检索搞定了答案生成的环节同样是有设计空间的。很多团队直接把用户query检索块拼一块扔给模型模型照样乱说。问题出在哪出在prompt的设计没有给模型立规矩。5.1 Prompt的核心约束基于检索内容作答不自行发挥生成环节的prompt我在客服场景的最终版长这样核心部分你是XX平台的客服助手。请根据下面提供的知识片段回答用户问题。 规则 1. 如果知识片段中能找到明确答案请忠实依据该片段作答可做总结和概括但不得改变原意。 2. 如果知识片段中没有明确答案请直接回答抱歉我暂时无法确认该信息已为您转接人工服务不要尝试猜测。 3. 回答中涉及的具体金额、天数、条件必须与知识片段完全一致逐字核对。 4. 不得引用知识片段之外的任何信息。 [知识片段]... [用户问题]...这里每一条规则都有用。第2条解决胡说第3条解决数字错误——大模型在概括时特别容易把7天说成72小时、满199减30说成满200减30所以必须强制它逐字核对数值。第4条防止模型调用自己内部的预训练知识那是幻觉的主要来源。5.2 引用溯源让每句回答都有出处还有一个很多团队不在意但客服场景刚需的设计回答附带引用来源。比如每条回答输出后让模型同时给出它依据的知识片段ID前端展示为来源售后政策第3.2条。这有双重价值对内方便人工质检对外让用户觉得这个回答有依据不是乱讲。实现上更稳的方式不是让模型自己报ID模型容易编错ID而是先确定用了哪几个知识块再让模型回答。工程实现是检索阶段用Rerank得分筛选知识块靠prompt让模型回答时必须用【引用块1】【引用块2】标注并强制要求每个关键结论后跟一个引用标记。如果模型输出的文字在引用块里找不到对应内容后置校验直接判为无效并拦截。这套引用校验机制是把不胡说从prompt层面的软约束变成工程层面的硬约束。5.3 多轮对话处理的隐藏雷区客服几乎天然是多轮对话用户不会每次都把完整意图讲一遍。用户上一句问现金券怎么用下一句问那可以叠加吗模型如果拿不到前文语境根本不知道它在问现金券可以叠加吗。RAG检索时query必须带入多轮上下文。简单有效的方案是取最近两轮用户消息当前轮拼成query上下文先用一个轻量大模型改写去噪——把口语、指代词补全生成一个独立可检索的query。比如改写后变成平台现金券的使用规则是什么_是否可以与优惠券同时叠加。注意改写后的query和原始query都要过一遍检索可以显著提高召回覆盖。但这里有个bug要防检索用的query和改写后的query不一致时引用来源会错位。我踩过这个坑改写query检到的知识块与用户原始提问根本不相关模型拿着无关材料硬答结果天马行空。后来强制加了校验比较改写前后的query相似度低于阈值时只用原始query宁可少召回也不能错召回。6. 上线前必须踩一遍的坑检索失效、切块错误与评分幻觉这一节把我在实际项目中踩过、且最具代表性的几个坑完整写出来。这些坑的共同点是不是文档里写的标准陷阱而是真实生产环境里才会撞到的。6.1 索引漂移文档还在但检索不到有个版本的客服文档更新后用户问新会员的积分有效期是多久知识库里明明有这条但检索怎么都召回不了。排查链路第一步确认知识块真的在库里。直接查向量库用一条相似query检索发现返回的结果里确实没有这个文档的块。第二步检查该文档切块后的内容——发现这个新会员积分政策被切成了一个超长表格单个块超过1000个字符表头很长关键信息被淹没在表格噪声里。第三步用BM25精确匹配新会员 积分 有效期仍然没召回因为原文用的是尊享会员等级积分规则表达完全不同。这就是典型的文档格式变化导致切块策略失效。解决方案是把该文档单独拆分类表格类文档走专用的行列拆块流程每个单元格组成为一个语义单元并在块标题里手工补上新会员积分有效期这类关键别名。这类问题靠调参数解决不了必须从文档类型入手重新设计切块模板。6.2 Rerank分数虚高相关≠可回答另一个翻车现场某个query的Rerank分数高达0.82但生成答案是一坨垃圾。后来定位到原因召回的知识块文字确实和query相关但知识块本身就是一句话带出三个条件满足A情况退款100%满足B情况退款50%——而用户问的是B情况模型在生成时自行选择了A情况的数据。这是文本相关和逻辑可用的差距。Rerank模型衡量的是语义相近度不负责判断这个块能否完整回答用户的问题。解决手段是在Rerank之后加一个校验层用规则检查知识块中的关键限定词如果、当、但是、不含等是否与query的意图一致在多条件并存的知识块上做条件匹配。这个校验层我们一开始想用另一个大模型做后来发现不少判断逻辑能用规则描述得更可靠、更快最终是一个规则为主模型为辅的混合校验。6.3 知识版本混乱同一个问题三个答案客服场景里知识文档是有生命周期的旧版政策和新版政策同时存在是常事。比如退货时效2024年6月前是7天之后改成15天。如果两个版本的文档都被切块入库RAG对同一个问题会交替返回不同答案用户发现AI在前后乱说。这是知识库治理问题。工程上的处理有几个层级第一入库时给每个文档标注生效版本和时间区间检索时根据当前日期自动过滤已失效版本。第二文档更新时做版本替换用结构化元数据维护同主题文档的父子关系新版本入库时旧版本强制降权。第三最笨也最有效的方法上线前人工审核一次知识库清单把明显的重复和过期文档清理掉。客服知识库的规模通常只有几千到几万条这个审核成本一天就能完成不要迷信全自动。7. 效果怎么算不胡说评测集设计与持续优化不会胡说八道这个目标不能靠感觉衡量。我们做了一个四层评测体系这里完整分享出来。这可能是整篇文章最值得抄作业的部分。第一层是单轮单文档检索评测。准备200个真实客服query每个query标注了知识库中对应的唯一文档ID。跑检索计算top1、top5的精确命中率。这一步衡量的是检索是否找对了原文。当时我们的基线是top5命中率78%优化切块策略和混合检索后提升到92%。第二层是答案忠实度评测。把检索结果交给生成模型得到回答文本后人工判断回答中的每个关键数据点能否在对应文档原文中找到依据。按完全忠实/部分忠实/完全不忠实三档标注。这部分我们统计的幻觉率完全不忠实比例最初是12%加上引用校验和prompt约束后降到3%以内。第三层是整体拒答率评测。准备一批知识库里没有答案的问题观察系统是否会错误作答。一个好的客服机器人应该有合理的拒答率——太低了会乱说话太高了会惹恼用户。我们控制在15%~20%之间。第四层是线上badcase回流。每周从真实对话流水中抽100条用户提问和机器人回答对照知识库人工复盘。凡是用户表达不满或话题被转人工的会话逐一归因是检索失败、生成错误、还是知识库本身没覆盖。归因结果回填到前三个评测集里持续迭代。这是整个优化闭环中最重要的一环——没有这个回流前面三层评测做出来的分数再好也会随用户行为变化而漂移。关于很多人关注的RAG瓶颈问题我个人认为当前最大的瓶颈不在模型能力而在知识处理和评测的工程化程度。RAG的上限由知识库的质量决定而不是由模型的天才程度决定。同样一个强大的GPT-4喂给它一份切得稀烂、版本混乱的知识库它照样会一本正经地胡说。反之把知识库治理做到位用个开源7B模型也能在限定领域里做到极高的准确率。所以与其天天追着新模型换不如把文档解析和评测闭环打磨扎实。最后分享一个值得扩展的方向与智能体Agent结合的RAG。客服场景不是只有问答一个动作更多时候需要查单填表改地址这类操作。把RAG检索到的知识作为Agent的行动手册让模型在知识约束下决定调用哪个工具、按什么流程执行是下一步很自然的演进方向。热词里出现rag智能体说明行业里已经有很多团队在往这个方向走了。这块我也在做有机会单独写一篇。给正在搭RAG客服机器人的团队一个中肯建议先花一周时间把知识文档的结构化梳理清楚再花三天把评测集建好最后再碰模型和参数。顺序反了后面会用更多的时间来还债。