RAG 这个词这两年确实被说烂了。随便一个技术群里都能看到有人甩一个仓库链接说“十分钟搭好你的知识库问答”。打开一看核心逻辑几乎一模一样读文档、切成小段、向量化、塞进向量库、检索、拼 Prompt、丢给大模型。这套流水线GitHub 上一搜一大把跑通一个 demo 真的不难。但你要是真拿它去处理点实际业务比如公司内部几百份制度文档、产品手册、技术规范马上就会发现问题——答非所问、引用张冠李戴、问深一点就胡编。不是 RAG 没用了而是你做的是那条流水线不是真正的 RAG 系统。我自己从最早用 LangChain 搭 demo到自己写检索模块再到给团队做知识库基线折腾了不少轮。回头看真正拉开差距、决定一个 RAG 能不能从“玩具”变成“工具”的从来不是那条流水线而是流水线之外、甚至之内的六个地方。这六个地方我踩过的坑比写过的代码还多今天一条条拆给你看。这篇东西适合两类人一类是已经跑通 demo、但觉得效果“不行”的人照着这几处去排查和改大概率能上一个台阶另一类是准备正经上知识库项目的先看完这六处至少能避开我当年绕了半年才绕出来的坑。1. 文档解析第一道真正的分水岭绝大多数人做 RAG第一步就是从 PDF 或者 Word 里把文本抽出来然后直接切块。我之前也这么干直到有一次被一份带复杂表格的年度报告整到怀疑人生——检索出来的片段表格里的数字全乱了答案自然也是错的。从那时候起我才意识到解析这一步才是 RAG 真正开始分高下的地方。1.1 文本抽取不等于文档理解你用 pypdf 或者 pdfplumber 把 PDF 里每一页的文字抠出来看起来是“抽到了文本”实际上你可能丢掉了很多东西标题的层级、列表的结构、表格的行列关系、图片里的信息、页眉页脚和正文的区分。这些信息对纯阅读来说无所谓但对 RAG 来说至关重要——因为检索是对“语义单元”做匹配而一个语义单元往往不是从第 3 行开始、到第 7 行结束那么机械。举个具体的例子。一份产品说明书里有一张“故障代码对照表”三列故障码、现象、处理建议。用普通抽取方式这张表会变成一长串用空格或者 Tab 分开的字符串。你把它切成 4 个 chunk 之后很可能出现这种情况第一个 chunk 里有“E101、电机过热、检查散热”第二个 chunk 里有“E102、过流保护、检查负载”。用户问“E101 怎么处理”向量检索确实能召回第一个 chunk看起来没问题。但如果用户问的是“电机过热有哪些故障码”系统要去哪里找如果表格结构没有被正确解析跨 chunk 的信息就很难拼起来。我后来的做法是把表格转成 Markdown 格式的文本再入库保留表头和行列关系。这样“故障代码对照表”作为一个整体被索引检索效果立刻不一样。再一个容易被忽略的是扫描件 PDF。你直接抽文本抽出来一片空白因为那是图片不是文字。我见过不少团队把这种 PDF 硬塞进知识库然后抱怨“为什么我的 RAG 什么都答不出来”——不是 RAG 的问题是文档从来没被真正“读懂”过。这种情况必须先做 OCR而且在切块之前做因为 OCR 的输出质量直接决定后续所有环节的天花板。1.2 网页结构怎么提取直接决定 wiki 类知识库能用多久热搜词里有人提到“wiki 和 RAG”这其实是个很经典的应用场景。不少团队拿内部 wiki 或者帮助中心做知识库但 wiki 页面不是纯文本它有导航栏、面包屑、相关推荐、评论区。你要是整页抓下来一个 chunk 里一半内容都是无关的导航和广告检索质量能好才怪。正确做法是拿结构化的抽取工具比如 trafilatura 或者 readability先提取正文主体再根据 HTML 里的标题标签h1、h2、h3来保留文档的目录结构。我之前做过一个帮助文档站点的知识库用 BeautifulSoup 写了一个提取脚本规则很简单去掉 nav、footer、aside 这几个标签里的内容把 main 区域里按 h1/h2/h3 做树形切分h2 作为一级标题h3 作为子节标题然后把标题拼到正文前面。这样一个 chunk 的自包含性会强很多因为用户问“怎么重置密码”那个小节标题“重置密码”本身就出现在 chunk 里检索的时候相似度分数会高不少。关于这段解析代码供参考from bs4 import BeautifulSoup def extract_article(html): soup BeautifulSoup(html, html.parser) # 剔除无关注释区域 for tag in soup([nav, footer, aside, script, style]): tag.decompose() main soup.find(main) or soup.body or soup sections [] current_section None for elem in main.descendants: if getattr(elem, name, None) in (h2, h3): current_section {title: elem.get_text().strip(), content: []} sections.append(current_section) elif elem.name p and current_section is not None: text elem.get_text().strip() if text: current_section[content].append(text) # 后续可以按 section 为单位切 chunk而不是按纯文本长度硬切解析是整个 RAG 的地基地基没打好后面再花哨的检索和重排都救不回来。这句话我在不同场合说过很多遍但真正吃透的人不多。2. 切块策略不是数着字数切是切出语义边界切块chunking是 RAG 里看起来最简单、实际最讲究的一步。很多教程给个固定值比如每 500 个字符切一块、重叠 50 个字符就算完事了。这种“数着字数切”的方式只能应付那些随便测测的场景。真到实际知识库里你会遇到一段代码横跨两个 chunk、一句结论被拦腰切断、表格被从中间劈开这些破事。每个问题都会让召回质量肉眼可见地变差。2.1 固定窗口为什么天然有缺陷固定窗口切块的问题在于它完全不理解内容的语义边界。举个例子你在切一份技术方案突然来了一句“因此我们决定采用方案 B。方案 B 的优势在于……”这句话的前半截在一个 chunk 里后半截在下一个 chunk 里。如果用户的问题是“为什么选方案 B”那么包含“因此我们决定采用方案 B”的那个 chunk它只有结论没有理由包含“方案 B 的优势在于”的下一个 chunk有理由却没提“因此”和“采用”。向量检索的时候两个 chunk 跟这个问题的相关度都被稀释了。你调什么 embedding 模型都救不了这个。后来我学到一个比较实用的技巧用结构信息切分而不是用字数切分。逻辑很简单先按标题层级把文档切成多个部分如果某个部分太长比如超过了模型上下文的一半再在这个部分内部按照段落、句子进一步切并保留小标题前缀。这样每个 chunk 基本对应一个“最小完整主题”而不是一段“刚好 500 字的连续文本”。当时处理一份 30 页的官方白皮书我用了这样的层级切分逻辑解析出文档的所有标题及其层级h1 → h2 → h3每个三级标题下的内容单独作为一个候选 chunk如果这个候选 chunk 过长就在句子边界处切分同时给子 chunk 补上前缀“一级标题 二级标题 三级标题”如果候选 chunk 过短比如只有一句话就与相邻标题下的内容合并这样切出来的 chunk每一块的语义完整性都远好于固定窗口。检索时能召回的往往是一段完整的论述而不是被拦腰斩断的半句话。2.2 重叠窗口和父子 chunk 的取舍重叠overlap是固定切分的补救措施它保证切割线附近的内容不会完全丢失呼应关系。但重叠又不是越多越好——重叠太多一是浪费向量库的存储和检索资源二是同一个信息在多个 chunk 里重复出现容易在检索时召回过多的冗余片段反而干扰大模型组织答案。我常用的参数是默认块大小 8001000 个字符这个范围我用下来在中文和英文混排场景下均衡性比较好重叠 100150 个字符。但这个参数不是抄来的是拿自己的数据试出来的。测试方法也很简单挑 20 个典型问题分别用不同块大小跑一遍检索看召回的片段是否命中标准答案中的关键句。哪个参数组合召回率高就用哪个。没有放之四海而皆准的默认值。另外一个进阶手法是父子 chunk。孙子兵法里有句话叫“知己知彼”在 RAG 里可以反着用做检索的时候用粒度更小的子 chunk 去跟用户 query 算相似度这样召回更精准把命中的子 chunk 映射回它的父 chunk比如完整的小节把父 chunk 整体丢给大模型。这样既能靠小 chunk 提高检索精度又能靠大 chunk 让模型看到足够多的上下文。我之前在做一个合同问答系统时用的就是这套效果比单纯切大块或小块都好。实现起来也不复杂存两个集合子块里记录父块 ID检索时先查子块再根据映射关系把父块内容捞出来拼给 LLM。切块这关过了你手里的知识库才真正“有结构”。这一步做得好后面的检索压力会小很多。3. Embedding 选型与混合检索别只看相似度分数要看成不成立切片切完之后下一步就是把 chunk 向量化、入库、检索。很多人在这一步纠结“用什么 embedding 模型”这个确实重要但还有两件同样重要的事经常被忽略一是人类能在多大程度上相信相似度分数二是一个纯向量的检索方案在真实业务里够不够用。3.1 embedding 模型怎么选中文场景特殊在哪里Embedding 模型的选择是个特别容易被低估的环节。很多人图省事直接套 OpenAI 的 embedding 接口或者用一个通用的开源模型。但对中文场景尤其是垂直领域法律、医疗、金融、制造通用模型的语义理解能力可能不够。我自己踩过的坑是这样的用一个通用英文 embedding 模型去处理中文产品手册查“重启设备”和“重新启动”向量相似度居然不高因为模型对这两个中文表达的语义等价性捕捉得很弱。后来换成了针对中文优化的模型比如当时用的 bge-large-zh效果立刻明显好转。如果在垂直领域还应该用领域数据做微调。微调 embedding 模型不需要特别大的成本有一两千条领域内的query正例段落对就够了。选型的时候还有一个容易踩的坑不同 embedding 模型的向量维度差异很大768 维、1024 维、1536 维都有。维度越高不代表越好但确实影响存储和检索成本。我之前有一个项目因为换了向量库、忘了重新生成向量导致线上查询维度不匹配直接报错。所以记住切换 embedding 模型之后必须全量重新向量化旧的向量数据千万不要和新模型的向量混在一起。3.2 混合检索为什么是生产环境的标配纯向量检索的局限我在不少项目里体会得特别深。核心问题在于向量检索天然擅长语义相近的匹配但不太擅长精确关键词匹配。你问“2024 版安全规范第 3.2 条”如果知识库里的原文确实是“第 3.2 条”向量检索大概率能匹配到但如果用户说“第三章第二节”向量检索可能就废了——它不太理解“3.2”和“第三章第二节”的数学等价关系。解决方式就是混合检索向量检索和关键词检索同时跑然后把结果合并。经典的做法是“BM25 向量检索”的融合。BM25 是传统的词频统计检索它老老实实地按字面匹配对精确数字、专有名词、型号代码之类的检索非常有效。向量检索则擅长“语义相关但字面不重叠”的情况。两个结果合并的时候常用 RRFReciprocal Rank Fusion算法把两个结果集中每个文档的排名倒数相加然后按分数排序。它不需要统一向量分数和 BM25 分数的量纲实现简单、效果稳定。我有一段时间图省事只用向量检索结果知识库里所有“设备型号”相关的问题召回率都不太行。后来加了 BM25 通道就把这类问题救回来了。这个改动不起眼但对实际效果的提升经常比换一个更贵的 embedding 模型还明显。所以如果有人跟你说“RAG 就是向量检索”你可以告诉他生产环境里混合检索才是常态。3.3 Rerank召回之后的最后一道筛选还有一个容易被忽略但非常关键的环节是 rerank重排。向量检索的职责是从几十万甚至上百万 chunk 中快速筛出几百个“可能相关的”但它的准确性有限因为向量相似度和“真实有用性”之间不是完全对等的关系。Rerank 模型做的事情是把召回的候选 chunk 和用户问题拼在一起用更精细的交互匹配模型逐个打分选出真正最相关、最可能回答问题的那 35 个。我在生产环境中的经验是加上一个 rerank 环节回答质量的主观评分提升非常明显而且还能减少幻觉——因为喂给大模型的片段更精准了模型编造的空间就更小了。有人觉得加 rerank 会多一层延迟实测下来增加的时间大概在 50200 毫秒但换来的准确度提升往往值得。4. 检索之后上下文编排和“让模型知道哪些不知道”流水线的最后一段是把检索到的片段拼给大模型让它“基于引用内容回答”。这一步看起来就是拼个 Prompt但同样有讲究。拼得不好再好的检索结果也会被浪费。4.1 上下文拼接不要把检索结果一股脑全倒进去我第一次做 RAG 的时候检索到什么就全给大模型最多按相似度分数排个序。结果经常出现一种“上下文污染”现象用户问的是“A 设备的电池寿命”检索结果里有一条非常相关、其他几条部分相关但包含大量无关细节模型就被无关细节带偏回答里混杂了 B 设备的内容。现在我的做法是检索得到的 Top-K 个 chunk先按顺序拼接给每个 chunk 加一个清晰的来源引用标记比如 [1]、[2]告诉大模型只能根据方括号标注的来源信息回答没有来源支持的内容不得回答如果检索结果里有明显不相关的噪声 chunk宁可少给也不要硬塞。我一般从 Top-8 里人为收窄到 Top-5质量反而更高在 Prompt 里加一句“如果这些内容不足以回答用户的问题请直接说明信息不足。”这句话能大幅减少胡编的可能性这个其实对应一个很火的词RAG 智能体。但我觉得没必要把它说得玄乎。本质就是让检索、记忆、判断这几个步骤在流程里更灵活而不是机械地“检索一次、回答一次”。你可以让模型先判断自己是否需要进一步检索不同来源再决定是否二次检索但前提是第一步的检索质量是可控的。4.2 引用溯源防止“张冠李戴”的最后防线我之前在做企业内部知识库时老板对 RAG 最不满意的一点不是答不出来而是答非所问时找不到是哪份文档出了问题。后来我强制要求生成的答案带引用来源——每个关键结论后面标注 [来源1]、[来源2]下面列出对应的文档名和章节号。这样哪怕答案是错的用户也能快速定位到是哪份文档、哪一段造成了误导而不是对着 AI 一脸懵。实现方式倒简单把引用信息从 chunk 的元数据字段里带上拼接 prompt 时保留来源标记。真正考验人的是要保证这个对应关系足够准确一个 chunk 可能跨了两个章节来源标记就要精细到“文档名 标题 段落号”。这一步做好了RAG 系统才算是一个“可信赖的工具”而不是一个偶尔灵光乍现的玩具。5. 知识库维护RAG 系统的“运维之道”比刚搭起来时更考验人很多人把 RAG 项目当成一次性交付做完就完事。实际情况是知识库里的文档会更新、会删除、会新增而一个不更新的 RAG 系统跑得越久越不准。这块内容在各类教程里很少被认真讲但它恰恰是生产环境里最容易出问题的环节。5.1 更新策略全量重建最容易实现但做多了会出事最简单的知识库更新方式是把所有文档重新解析、重新切块、重新生成向量然后全量替换。好处是逻辑简单、不容易出 bug代价是时间成本和算力成本而且更新窗口内系统还会有一段时间不可用。对一个几千 chunk 的小知识库来说全量重建完全没什么问题但到了十万、百万级 chunk全量重建就不是一个能频繁做的事件了。增量更新才是多数生产系统的常态只有新增或变动的文档需要被重新处理。难点在于“变动的文档怎么找出”。我经历过一个很尴尬的场景某份制度文件修改了几个条款但因为文件名没变增量更新脚本就没发现它变了结果用户问“新休假政策”系统答的还是老版本。后来我在知识库里加了一个校验字段文件哈希或最后修改时间。入库前先对比哈希变了才重新解析和索引。这个逻辑本身不复杂但很多人一开始根本没想到。如果你用的是 Elasticsearch 或 OpenSearch 这类带管道的方案也可以把更新触发挂在对象存储的变更事件上比如 S3 事件通知文件一变管道自动跑一轮。这样整个知识库的“保鲜期”就能无限延长。5.2 多版本冲突一份文档的新旧版本同时存在怎么办增量更新会带来另一个问题旧版本没有及时删除新版本已经入库检索时新旧两个版本可能同时被召回。它们的内容可能完全矛盾。比如旧版说“员工可休 15 天年假”新版说“调整为 10 天”用户问“今年年假几天”一个回答里同时出现两个数字这谁敢用处理办法有两个层面。一是文档层面同一份文档的更新逻辑应该保留“版本号”元数据检索时优先取最新版本。二是检索层面如果出现了不同版本对同一问题的说法差异可以考虑在入库时就删除被替换的旧版本而不是放任它在索引里游荡。我做过的比较简朴的处理是入库前根据文档的唯一标识比如文件名查一下向量库里是否有旧版本有的话先删掉再写新版本。这个逻辑跑起来之后知识库的自相矛盾问题基本绝迹了。如果你用的是支持过滤条件的向量库还可以用“文档 ID 版本号”字段做过滤新版本发布后把旧版本的过滤标签置为不可检索。运维这块是 RAG 真正进入“产品化”之后的分水岭能不能持续可靠地运行时比拼的不只是模型效果而是工程细节。我甚至有一段时间专门去优化更新管线写完的代码量比整个 RAG 检索链路的代码都多。6. 评测没有评测体系的 RAG就是自我感动最后这个地方我放在压轴讲是因为它是几乎所有做 RAG 的人都忽视、但恰恰决定系统能否迭代的关键。很多人给我演示他们的 RAG 系统时都是挑几个问题来试问出好结果就觉得很满意。实际上这种“演示式验证”根本不能说明系统的真实水平因为你挑的那几个问题往往是自己精心挑选过、模型大概率能答对的问题。6.1 没有评测你根本不知道系统在哪些场景会崩我当时真正意识到评测有多重要是在一次团队内部做“红队测试”的时候让其他同事随机提一些知识库里的偏门问题结果系统答对率只有不到一半。这个数字让我非常震惊因为此前我一直以为系统“还行”。后来我总结评测的核心在于构建一个覆盖面足够广、难度分布合理的问题集并给每个问题配上标准答案或至少是答案关键词。具体做法可以分几步从知识库里挑一部分内容人工写成 50100 道问题覆盖不同类型事实问答、总结归纳、对比、流程步骤、数字提取等给每道题标注一个“参考文献范围”chunk ID 或者文档页范围这样评测召回率时可以自动判断“是否命中了相关片段”跑一遍系统分两个指标看召回率命中相关片段的比例和答案准确率答案与标准答案一致的多少这里有个热搜词叫“RAG 瓶颈”我理解的其中一个核心瓶颈就在评测环节很多人知道系统有问题但说不清楚问题在哪。没有评测体系你永远只能靠“感觉”来排查效率低到可怕。6.2 离线评测指标怎么定命中率、忠实度、幻觉率评测指标可以分为三个维度我简化为检索命中率RecallK把评测问题的参考 chunk 跟 Top-K 检索结果比对看多少问题的正确答案片段能被召回生成忠实度Faithfulness生成的答案里有多少信息在参考片段中有支撑。这个可以人工打分也可以借助另一个强力的 LLM 来判可用率Correctness综合考虑答案的正确性和完整性建议直接让真人打 15 分我实际操作中最先盯的永远是检索命中率。因为如果 Top-5 里根本没有正确答案的片段那么大模型再强也回答不对。命中率低了问题基本出在前面几章解析、切块、检索。命中率够了但答案还是错问题多半出在生成环节prompt、上下文编排、rerank。这给排查问题提供了一个很清晰的路径不会像无头苍蝇一样乱调。评测集不是一次性建完就完事的。我自己的经验是每迭代一版知识库就随手补充几条之前系统答错的、新发现的边界问题让评测集跟着知识库一起长大。几个月下来评测集可能从 50 题涨到 200 题系统的任何改动都能快速回测这个反馈闭环越早建立系统迭代越快。说得直白一点评测不是 RAG 的附加题而是 RAG 的分水岭。一个连评测集都没有的 RAG 系统你根本不知道它现在站在哪个水平线上又该如何规划下一步。写在最后关于这些分水岭我的一些实际操作心得做了这么久 RAG我自己的体会是技术框架一直在变但围绕“数据质量、检索质量、生成可信度”这三个方向的打磨逻辑是不变的。现在网上铺天盖地的“五分钟搭建 RAG”能帮你跑通 demo但帮不了你上线生产。真正值得花时间的恰恰是那些看起来不够炫、但决定成败的细节把解析做扎实、把切块做合理、把评测建起来。最后分享一个我自己常用来检查 RAG 系统健康度的小技巧定期随机抽 10 个测试问题人工看一遍系统输出把每个答案和引用来源都检查一遍。如果 10 个问题里有 3 个以上的答案引用错误或者信息张冠李戴那么不管得分多高都说明底层的解析或者检索链路有需要修整的地方。别等用户来给你报 bug自己先做更挑剔的用户系统的水位才能一点点涨上去。
RAG 这个词这两年确实被说烂了。随便一个技术群里都能看到有人甩一个仓库链接说“十分钟搭好你的知识库问答”。打开一看核心逻辑几乎一模一样读文档、切成小段、向量化、塞进向量库、检索、拼 Prompt、丢给大模型。这套流水线GitHub 上一搜一大把跑通一个 demo 真的不难。但你要是真拿它去处理点实际业务比如公司内部几百份制度文档、产品手册、技术规范马上就会发现问题——答非所问、引用张冠李戴、问深一点就胡编。不是 RAG 没用了而是你做的是那条流水线不是真正的 RAG 系统。我自己从最早用 LangChain 搭 demo到自己写检索模块再到给团队做知识库基线折腾了不少轮。回头看真正拉开差距、决定一个 RAG 能不能从“玩具”变成“工具”的从来不是那条流水线而是流水线之外、甚至之内的六个地方。这六个地方我踩过的坑比写过的代码还多今天一条条拆给你看。这篇东西适合两类人一类是已经跑通 demo、但觉得效果“不行”的人照着这几处去排查和改大概率能上一个台阶另一类是准备正经上知识库项目的先看完这六处至少能避开我当年绕了半年才绕出来的坑。1. 文档解析第一道真正的分水岭绝大多数人做 RAG第一步就是从 PDF 或者 Word 里把文本抽出来然后直接切块。我之前也这么干直到有一次被一份带复杂表格的年度报告整到怀疑人生——检索出来的片段表格里的数字全乱了答案自然也是错的。从那时候起我才意识到解析这一步才是 RAG 真正开始分高下的地方。1.1 文本抽取不等于文档理解你用 pypdf 或者 pdfplumber 把 PDF 里每一页的文字抠出来看起来是“抽到了文本”实际上你可能丢掉了很多东西标题的层级、列表的结构、表格的行列关系、图片里的信息、页眉页脚和正文的区分。这些信息对纯阅读来说无所谓但对 RAG 来说至关重要——因为检索是对“语义单元”做匹配而一个语义单元往往不是从第 3 行开始、到第 7 行结束那么机械。举个具体的例子。一份产品说明书里有一张“故障代码对照表”三列故障码、现象、处理建议。用普通抽取方式这张表会变成一长串用空格或者 Tab 分开的字符串。你把它切成 4 个 chunk 之后很可能出现这种情况第一个 chunk 里有“E101、电机过热、检查散热”第二个 chunk 里有“E102、过流保护、检查负载”。用户问“E101 怎么处理”向量检索确实能召回第一个 chunk看起来没问题。但如果用户问的是“电机过热有哪些故障码”系统要去哪里找如果表格结构没有被正确解析跨 chunk 的信息就很难拼起来。我后来的做法是把表格转成 Markdown 格式的文本再入库保留表头和行列关系。这样“故障代码对照表”作为一个整体被索引检索效果立刻不一样。再一个容易被忽略的是扫描件 PDF。你直接抽文本抽出来一片空白因为那是图片不是文字。我见过不少团队把这种 PDF 硬塞进知识库然后抱怨“为什么我的 RAG 什么都答不出来”——不是 RAG 的问题是文档从来没被真正“读懂”过。这种情况必须先做 OCR而且在切块之前做因为 OCR 的输出质量直接决定后续所有环节的天花板。1.2 网页结构怎么提取直接决定 wiki 类知识库能用多久热搜词里有人提到“wiki 和 RAG”这其实是个很经典的应用场景。不少团队拿内部 wiki 或者帮助中心做知识库但 wiki 页面不是纯文本它有导航栏、面包屑、相关推荐、评论区。你要是整页抓下来一个 chunk 里一半内容都是无关的导航和广告检索质量能好才怪。正确做法是拿结构化的抽取工具比如 trafilatura 或者 readability先提取正文主体再根据 HTML 里的标题标签h1、h2、h3来保留文档的目录结构。我之前做过一个帮助文档站点的知识库用 BeautifulSoup 写了一个提取脚本规则很简单去掉 nav、footer、aside 这几个标签里的内容把 main 区域里按 h1/h2/h3 做树形切分h2 作为一级标题h3 作为子节标题然后把标题拼到正文前面。这样一个 chunk 的自包含性会强很多因为用户问“怎么重置密码”那个小节标题“重置密码”本身就出现在 chunk 里检索的时候相似度分数会高不少。关于这段解析代码供参考from bs4 import BeautifulSoup def extract_article(html): soup BeautifulSoup(html, html.parser) # 剔除无关注释区域 for tag in soup([nav, footer, aside, script, style]): tag.decompose() main soup.find(main) or soup.body or soup sections [] current_section None for elem in main.descendants: if getattr(elem, name, None) in (h2, h3): current_section {title: elem.get_text().strip(), content: []} sections.append(current_section) elif elem.name p and current_section is not None: text elem.get_text().strip() if text: current_section[content].append(text) # 后续可以按 section 为单位切 chunk而不是按纯文本长度硬切解析是整个 RAG 的地基地基没打好后面再花哨的检索和重排都救不回来。这句话我在不同场合说过很多遍但真正吃透的人不多。2. 切块策略不是数着字数切是切出语义边界切块chunking是 RAG 里看起来最简单、实际最讲究的一步。很多教程给个固定值比如每 500 个字符切一块、重叠 50 个字符就算完事了。这种“数着字数切”的方式只能应付那些随便测测的场景。真到实际知识库里你会遇到一段代码横跨两个 chunk、一句结论被拦腰切断、表格被从中间劈开这些破事。每个问题都会让召回质量肉眼可见地变差。2.1 固定窗口为什么天然有缺陷固定窗口切块的问题在于它完全不理解内容的语义边界。举个例子你在切一份技术方案突然来了一句“因此我们决定采用方案 B。方案 B 的优势在于……”这句话的前半截在一个 chunk 里后半截在下一个 chunk 里。如果用户的问题是“为什么选方案 B”那么包含“因此我们决定采用方案 B”的那个 chunk它只有结论没有理由包含“方案 B 的优势在于”的下一个 chunk有理由却没提“因此”和“采用”。向量检索的时候两个 chunk 跟这个问题的相关度都被稀释了。你调什么 embedding 模型都救不了这个。后来我学到一个比较实用的技巧用结构信息切分而不是用字数切分。逻辑很简单先按标题层级把文档切成多个部分如果某个部分太长比如超过了模型上下文的一半再在这个部分内部按照段落、句子进一步切并保留小标题前缀。这样每个 chunk 基本对应一个“最小完整主题”而不是一段“刚好 500 字的连续文本”。当时处理一份 30 页的官方白皮书我用了这样的层级切分逻辑解析出文档的所有标题及其层级h1 → h2 → h3每个三级标题下的内容单独作为一个候选 chunk如果这个候选 chunk 过长就在句子边界处切分同时给子 chunk 补上前缀“一级标题 二级标题 三级标题”如果候选 chunk 过短比如只有一句话就与相邻标题下的内容合并这样切出来的 chunk每一块的语义完整性都远好于固定窗口。检索时能召回的往往是一段完整的论述而不是被拦腰斩断的半句话。2.2 重叠窗口和父子 chunk 的取舍重叠overlap是固定切分的补救措施它保证切割线附近的内容不会完全丢失呼应关系。但重叠又不是越多越好——重叠太多一是浪费向量库的存储和检索资源二是同一个信息在多个 chunk 里重复出现容易在检索时召回过多的冗余片段反而干扰大模型组织答案。我常用的参数是默认块大小 8001000 个字符这个范围我用下来在中文和英文混排场景下均衡性比较好重叠 100150 个字符。但这个参数不是抄来的是拿自己的数据试出来的。测试方法也很简单挑 20 个典型问题分别用不同块大小跑一遍检索看召回的片段是否命中标准答案中的关键句。哪个参数组合召回率高就用哪个。没有放之四海而皆准的默认值。另外一个进阶手法是父子 chunk。孙子兵法里有句话叫“知己知彼”在 RAG 里可以反着用做检索的时候用粒度更小的子 chunk 去跟用户 query 算相似度这样召回更精准把命中的子 chunk 映射回它的父 chunk比如完整的小节把父 chunk 整体丢给大模型。这样既能靠小 chunk 提高检索精度又能靠大 chunk 让模型看到足够多的上下文。我之前在做一个合同问答系统时用的就是这套效果比单纯切大块或小块都好。实现起来也不复杂存两个集合子块里记录父块 ID检索时先查子块再根据映射关系把父块内容捞出来拼给 LLM。切块这关过了你手里的知识库才真正“有结构”。这一步做得好后面的检索压力会小很多。3. Embedding 选型与混合检索别只看相似度分数要看成不成立切片切完之后下一步就是把 chunk 向量化、入库、检索。很多人在这一步纠结“用什么 embedding 模型”这个确实重要但还有两件同样重要的事经常被忽略一是人类能在多大程度上相信相似度分数二是一个纯向量的检索方案在真实业务里够不够用。3.1 embedding 模型怎么选中文场景特殊在哪里Embedding 模型的选择是个特别容易被低估的环节。很多人图省事直接套 OpenAI 的 embedding 接口或者用一个通用的开源模型。但对中文场景尤其是垂直领域法律、医疗、金融、制造通用模型的语义理解能力可能不够。我自己踩过的坑是这样的用一个通用英文 embedding 模型去处理中文产品手册查“重启设备”和“重新启动”向量相似度居然不高因为模型对这两个中文表达的语义等价性捕捉得很弱。后来换成了针对中文优化的模型比如当时用的 bge-large-zh效果立刻明显好转。如果在垂直领域还应该用领域数据做微调。微调 embedding 模型不需要特别大的成本有一两千条领域内的query正例段落对就够了。选型的时候还有一个容易踩的坑不同 embedding 模型的向量维度差异很大768 维、1024 维、1536 维都有。维度越高不代表越好但确实影响存储和检索成本。我之前有一个项目因为换了向量库、忘了重新生成向量导致线上查询维度不匹配直接报错。所以记住切换 embedding 模型之后必须全量重新向量化旧的向量数据千万不要和新模型的向量混在一起。3.2 混合检索为什么是生产环境的标配纯向量检索的局限我在不少项目里体会得特别深。核心问题在于向量检索天然擅长语义相近的匹配但不太擅长精确关键词匹配。你问“2024 版安全规范第 3.2 条”如果知识库里的原文确实是“第 3.2 条”向量检索大概率能匹配到但如果用户说“第三章第二节”向量检索可能就废了——它不太理解“3.2”和“第三章第二节”的数学等价关系。解决方式就是混合检索向量检索和关键词检索同时跑然后把结果合并。经典的做法是“BM25 向量检索”的融合。BM25 是传统的词频统计检索它老老实实地按字面匹配对精确数字、专有名词、型号代码之类的检索非常有效。向量检索则擅长“语义相关但字面不重叠”的情况。两个结果合并的时候常用 RRFReciprocal Rank Fusion算法把两个结果集中每个文档的排名倒数相加然后按分数排序。它不需要统一向量分数和 BM25 分数的量纲实现简单、效果稳定。我有一段时间图省事只用向量检索结果知识库里所有“设备型号”相关的问题召回率都不太行。后来加了 BM25 通道就把这类问题救回来了。这个改动不起眼但对实际效果的提升经常比换一个更贵的 embedding 模型还明显。所以如果有人跟你说“RAG 就是向量检索”你可以告诉他生产环境里混合检索才是常态。3.3 Rerank召回之后的最后一道筛选还有一个容易被忽略但非常关键的环节是 rerank重排。向量检索的职责是从几十万甚至上百万 chunk 中快速筛出几百个“可能相关的”但它的准确性有限因为向量相似度和“真实有用性”之间不是完全对等的关系。Rerank 模型做的事情是把召回的候选 chunk 和用户问题拼在一起用更精细的交互匹配模型逐个打分选出真正最相关、最可能回答问题的那 35 个。我在生产环境中的经验是加上一个 rerank 环节回答质量的主观评分提升非常明显而且还能减少幻觉——因为喂给大模型的片段更精准了模型编造的空间就更小了。有人觉得加 rerank 会多一层延迟实测下来增加的时间大概在 50200 毫秒但换来的准确度提升往往值得。4. 检索之后上下文编排和“让模型知道哪些不知道”流水线的最后一段是把检索到的片段拼给大模型让它“基于引用内容回答”。这一步看起来就是拼个 Prompt但同样有讲究。拼得不好再好的检索结果也会被浪费。4.1 上下文拼接不要把检索结果一股脑全倒进去我第一次做 RAG 的时候检索到什么就全给大模型最多按相似度分数排个序。结果经常出现一种“上下文污染”现象用户问的是“A 设备的电池寿命”检索结果里有一条非常相关、其他几条部分相关但包含大量无关细节模型就被无关细节带偏回答里混杂了 B 设备的内容。现在我的做法是检索得到的 Top-K 个 chunk先按顺序拼接给每个 chunk 加一个清晰的来源引用标记比如 [1]、[2]告诉大模型只能根据方括号标注的来源信息回答没有来源支持的内容不得回答如果检索结果里有明显不相关的噪声 chunk宁可少给也不要硬塞。我一般从 Top-8 里人为收窄到 Top-5质量反而更高在 Prompt 里加一句“如果这些内容不足以回答用户的问题请直接说明信息不足。”这句话能大幅减少胡编的可能性这个其实对应一个很火的词RAG 智能体。但我觉得没必要把它说得玄乎。本质就是让检索、记忆、判断这几个步骤在流程里更灵活而不是机械地“检索一次、回答一次”。你可以让模型先判断自己是否需要进一步检索不同来源再决定是否二次检索但前提是第一步的检索质量是可控的。4.2 引用溯源防止“张冠李戴”的最后防线我之前在做企业内部知识库时老板对 RAG 最不满意的一点不是答不出来而是答非所问时找不到是哪份文档出了问题。后来我强制要求生成的答案带引用来源——每个关键结论后面标注 [来源1]、[来源2]下面列出对应的文档名和章节号。这样哪怕答案是错的用户也能快速定位到是哪份文档、哪一段造成了误导而不是对着 AI 一脸懵。实现方式倒简单把引用信息从 chunk 的元数据字段里带上拼接 prompt 时保留来源标记。真正考验人的是要保证这个对应关系足够准确一个 chunk 可能跨了两个章节来源标记就要精细到“文档名 标题 段落号”。这一步做好了RAG 系统才算是一个“可信赖的工具”而不是一个偶尔灵光乍现的玩具。5. 知识库维护RAG 系统的“运维之道”比刚搭起来时更考验人很多人把 RAG 项目当成一次性交付做完就完事。实际情况是知识库里的文档会更新、会删除、会新增而一个不更新的 RAG 系统跑得越久越不准。这块内容在各类教程里很少被认真讲但它恰恰是生产环境里最容易出问题的环节。5.1 更新策略全量重建最容易实现但做多了会出事最简单的知识库更新方式是把所有文档重新解析、重新切块、重新生成向量然后全量替换。好处是逻辑简单、不容易出 bug代价是时间成本和算力成本而且更新窗口内系统还会有一段时间不可用。对一个几千 chunk 的小知识库来说全量重建完全没什么问题但到了十万、百万级 chunk全量重建就不是一个能频繁做的事件了。增量更新才是多数生产系统的常态只有新增或变动的文档需要被重新处理。难点在于“变动的文档怎么找出”。我经历过一个很尴尬的场景某份制度文件修改了几个条款但因为文件名没变增量更新脚本就没发现它变了结果用户问“新休假政策”系统答的还是老版本。后来我在知识库里加了一个校验字段文件哈希或最后修改时间。入库前先对比哈希变了才重新解析和索引。这个逻辑本身不复杂但很多人一开始根本没想到。如果你用的是 Elasticsearch 或 OpenSearch 这类带管道的方案也可以把更新触发挂在对象存储的变更事件上比如 S3 事件通知文件一变管道自动跑一轮。这样整个知识库的“保鲜期”就能无限延长。5.2 多版本冲突一份文档的新旧版本同时存在怎么办增量更新会带来另一个问题旧版本没有及时删除新版本已经入库检索时新旧两个版本可能同时被召回。它们的内容可能完全矛盾。比如旧版说“员工可休 15 天年假”新版说“调整为 10 天”用户问“今年年假几天”一个回答里同时出现两个数字这谁敢用处理办法有两个层面。一是文档层面同一份文档的更新逻辑应该保留“版本号”元数据检索时优先取最新版本。二是检索层面如果出现了不同版本对同一问题的说法差异可以考虑在入库时就删除被替换的旧版本而不是放任它在索引里游荡。我做过的比较简朴的处理是入库前根据文档的唯一标识比如文件名查一下向量库里是否有旧版本有的话先删掉再写新版本。这个逻辑跑起来之后知识库的自相矛盾问题基本绝迹了。如果你用的是支持过滤条件的向量库还可以用“文档 ID 版本号”字段做过滤新版本发布后把旧版本的过滤标签置为不可检索。运维这块是 RAG 真正进入“产品化”之后的分水岭能不能持续可靠地运行时比拼的不只是模型效果而是工程细节。我甚至有一段时间专门去优化更新管线写完的代码量比整个 RAG 检索链路的代码都多。6. 评测没有评测体系的 RAG就是自我感动最后这个地方我放在压轴讲是因为它是几乎所有做 RAG 的人都忽视、但恰恰决定系统能否迭代的关键。很多人给我演示他们的 RAG 系统时都是挑几个问题来试问出好结果就觉得很满意。实际上这种“演示式验证”根本不能说明系统的真实水平因为你挑的那几个问题往往是自己精心挑选过、模型大概率能答对的问题。6.1 没有评测你根本不知道系统在哪些场景会崩我当时真正意识到评测有多重要是在一次团队内部做“红队测试”的时候让其他同事随机提一些知识库里的偏门问题结果系统答对率只有不到一半。这个数字让我非常震惊因为此前我一直以为系统“还行”。后来我总结评测的核心在于构建一个覆盖面足够广、难度分布合理的问题集并给每个问题配上标准答案或至少是答案关键词。具体做法可以分几步从知识库里挑一部分内容人工写成 50100 道问题覆盖不同类型事实问答、总结归纳、对比、流程步骤、数字提取等给每道题标注一个“参考文献范围”chunk ID 或者文档页范围这样评测召回率时可以自动判断“是否命中了相关片段”跑一遍系统分两个指标看召回率命中相关片段的比例和答案准确率答案与标准答案一致的多少这里有个热搜词叫“RAG 瓶颈”我理解的其中一个核心瓶颈就在评测环节很多人知道系统有问题但说不清楚问题在哪。没有评测体系你永远只能靠“感觉”来排查效率低到可怕。6.2 离线评测指标怎么定命中率、忠实度、幻觉率评测指标可以分为三个维度我简化为检索命中率RecallK把评测问题的参考 chunk 跟 Top-K 检索结果比对看多少问题的正确答案片段能被召回生成忠实度Faithfulness生成的答案里有多少信息在参考片段中有支撑。这个可以人工打分也可以借助另一个强力的 LLM 来判可用率Correctness综合考虑答案的正确性和完整性建议直接让真人打 15 分我实际操作中最先盯的永远是检索命中率。因为如果 Top-5 里根本没有正确答案的片段那么大模型再强也回答不对。命中率低了问题基本出在前面几章解析、切块、检索。命中率够了但答案还是错问题多半出在生成环节prompt、上下文编排、rerank。这给排查问题提供了一个很清晰的路径不会像无头苍蝇一样乱调。评测集不是一次性建完就完事的。我自己的经验是每迭代一版知识库就随手补充几条之前系统答错的、新发现的边界问题让评测集跟着知识库一起长大。几个月下来评测集可能从 50 题涨到 200 题系统的任何改动都能快速回测这个反馈闭环越早建立系统迭代越快。说得直白一点评测不是 RAG 的附加题而是 RAG 的分水岭。一个连评测集都没有的 RAG 系统你根本不知道它现在站在哪个水平线上又该如何规划下一步。写在最后关于这些分水岭我的一些实际操作心得做了这么久 RAG我自己的体会是技术框架一直在变但围绕“数据质量、检索质量、生成可信度”这三个方向的打磨逻辑是不变的。现在网上铺天盖地的“五分钟搭建 RAG”能帮你跑通 demo但帮不了你上线生产。真正值得花时间的恰恰是那些看起来不够炫、但决定成败的细节把解析做扎实、把切块做合理、把评测建起来。最后分享一个我自己常用来检查 RAG 系统健康度的小技巧定期随机抽 10 个测试问题人工看一遍系统输出把每个答案和引用来源都检查一遍。如果 10 个问题里有 3 个以上的答案引用错误或者信息张冠李戴那么不管得分多高都说明底层的解析或者检索链路有需要修整的地方。别等用户来给你报 bug自己先做更挑剔的用户系统的水位才能一点点涨上去。
