同一个RAG教程跑出来的东西有人做出来的像答疑机器人有人做出来的像智障。我见过太多人用同一套流程、同一个向量库、同一个模型最后效果天差地别。原因只有一个那条“加载文档→切分→向量化→存库→检索→拼接→让LLM回答”的流水线确实已经是烂大街的标准动作了。但流水线跑通只是起点真正把RAG项目做出分水岭的是下面这六个环节。这篇文章我不打算再重复一遍“如何用LangChain搭RAG”的教程而是把精力放在那些真正让项目变好、也真正让人掉坑的细节上。这些内容来自我自己的项目实战也参考了大量公开社区里值得反复看的实践总结希望能让正在做RAG或者正准备做RAG的人少走点弯路。1. 文档进库前的“垃圾处理”解析与清洗决定RAG上限我最早做RAG的时候犯过一个典型错误拿到一批PDF用现成的loader一把梭全丢进向量库然后信心满满地去问问题。结果用户问“第三季度营收是多少”系统给我返回一段把页眉页脚和正文混在一起的乱码。这不是检索的问题也不是模型的问题是进库之前就没把文档收拾干净。很多RAG项目做到后面效果上不去回头看根子都埋在第一步。1.1 你以为读进来的是文字其实是版式残骸PDF看起来是“文字”但它本质上是版式文件。文字在PDF里是一堆带坐标的绘制指令不是像TXT或Markdown那样天然的流式文本。所以用普通的PDF解析库直接抽取文本你会拿到一堆被物理位置打乱的东西双栏论文的左右栏会交错、表格的行列会散架、页眉页脚会插进正文中间连脚注都可能飞到句子的腰部。举个例子一篇经典的双栏学术论文你直接抽文本出来的顺序很可能是“左栏上半段→右栏上半段→左栏中间→右栏中间”。如果你不做处理就切块每个chunk里装的都是两个栏的碎片向量化之后语义被搅成一锅粥检索当然一塌糊涂。所以第一步不是“切块”是“解析”。你需要根据文档类型选择正确的解析策略PDF文字版用带版面分析的解析工具而不是纯文本抽取PDF扫描版先做OCR再做版面还原Word/HTML/Markdown解析出标题层级、表格结构、列表关系表格密集型文档财报、病历、合同要用能还原表格结构的解析器而不是把表格拍平成一行我现在对在线文档基本用Fitz或通用加载器做粗取再用规则清洗对扫描件会用本地OCR工具先过一遍。我见过不少团队为了省事直接拿免费在线API去解析内部资料这个风险很大数据安全先不提文档解析出来的质量也基本不可控。本地能跑的RAG文本拆解工具其实不少完全可以在内网搭一条解析链路。1.2 表格、双栏、扫描件的实战处理顺序处理顺序很重要我的习惯是先结构后内容先判文档类型PDF文字/扫描、Word、HTML、纯文本分别走不同管道再做版面还原双栏变单栏、识别标题层级、识别表格行列然后做文本清洗去掉页眉页脚、页码、重复的导航文字、乱码字符最后才是结构化输出把结果转成Markdown或JSON保留标题层级和表格语义清洗这一步很多人会忽略但页眉页脚和页码对检索质量的毒害很大。试想一个20页的PDF如果每一页的chunk都带着“某某公司内部资料”和页码那你检索“内部资料”这个关键词时所有chunk都会被召回相关性和精确度瞬间崩掉。用规则把这些固定噪声去掉是成本最低、收益最明显的优化。1.3 图片到底能不能进知识库这是个真问题热搜里那个问题“RAG知识库能存储图片嘛”我印象很深。答案是如果你用的还是传统文本embedding那存了图片也没用因为图片内容根本没法向量化成有意义的文本语义但如果你的知识库里图片本身承载了信息比如产品图、流程图、截图那就不能只存文本得把图片转换成能被检索的内容。目前比较可靠的落地方式有两种一是用带视觉能力的模型把图片转成文字描述再入库成本低适合流程图海报这类二是直接用多模态embedding模型做图文统一向量化效果好但资源消耗翻倍。我目前在本地知识库里跑的是“截图转文字描述”方案也就是把一张架构图翻译成“系统包含A模块、B模块A通过HTTP调用B……”这样的文本再入库这样用户检索“模块之间怎么通信”的时候就能命中这张图对应的段落。纯图片文档我不建议硬上多模态除非你的检索场景有强依赖。2. 切分不是“按字数切一切”chunking策略的工程平衡文档洗干净了接下来就是切分。切分这件事看起来是人人都能做实际上特别容易埋雷。切分的本质是在“检索精度”和“上下文完整性”之间找一个平衡点。切小了单个chunk语义太窄检索容易漏切大了chunk里面塞太多无关内容向量化后语义被稀释召回一堆错的东西。2.1 固定窗口切分为什么人人都在用又人人都在骂固定窗口切分比如每500字一刀overlap设50之所以流行是因为它实现简单、处理速度快、任何文本都能切。LangChain里的RecursiveCharacterTextSplitter就是这个思路它先把文本按段落粗切再按字符数细切尽量让切分点落在换行符或句号附近。但固定窗口有个天然缺陷它不理解语义边界。一句话说到一半被切开、一个列表项被拆到两个chunk、一个表格被腰斩这些都是固定窗口的日常。你别指望overlap能救回来overlap只是给了上下文一点重叠根本解决不了“语义被切碎”的问题。我见过一个案例用户问“这个功能支持哪些语言”答案其实写在一个5行列表里但列表被切成两个chunk检索只召回了一半LLM拿到残缺的列表就开始编这已经不能用“知识库效果差”来解释了纯粹是切分把答案切没了。2.2 父子分块用两层结构同时保住召回和上下文后来我在项目里改用父子分块Parent-Child Chunking召回质量上了一个台阶。思路很简单建两个层级索引小的“子块”用于匹配覆盖到更大范围的“父块”用于给LLM提供上下文。具体操作是把文档先按语义边界标题、段落、列表切成“父块”比如一个二级标题下的一整节然后在每个父块内部再切成小的“子块”比如256字左右为每个子块做向量化。检索时先拿query去匹配子块向量命中后把整个父块作为上下文送给LLM。这样匹配的粒度足够细上下文又足够完整。这个模式在我做企业内部的规章制度问答时效果显著因为规章制度里的答案经常分布在一个条目的多条细则里只取一个细则是答不全的。2.3 不同文档类型对应的切分参数参考传参数这东西不能照抄别人的因为文本密度和句子长度不一样。下面这张表是我在几个不同项目里实测过的初始参数适合大多数中文场景你可以拿去做起点再调文档类型切分策略子块长度重叠备注通用办公文档Word/Markdown按标题结构切分500字符50字符保留Markdown的#层级做父块边界学术论文/技术文档先按二级标题切父块子块256256字符32字符双栏PDF务必先做版面还原表格密集型文档表格整行/整列为一个块不按字数无千万别把表格拍平成文本再切代码仓库文档按函数/类定义切块以代码块为单位无用AST解析比按行切科学得多对话记录/FAQ一问一答为一个块不按字数无保证问答对不拆散还有个容易被忽略的点切分粒度要和你的embedding模型能力匹配。如果你的embedding模型本身对长文本支持不好比如最大token只有512那你切800字符一个块后面一半字符根本参与不了向量化等于白切。切分前务必先查你用的模型的max input tokens。3. 检索不能只靠余弦相似度召回链路的“组合拳”RAG的R检索是整个系统里最值得花时间打磨的一环。很多人用向量检索一把梭效果不好就怪模型其实问题往往出在“只用了一种检索方式”上。向量相似度没有你想象的那么万能。3.1 向量检索的两大暗坑主题漂移与token级噪声第一个暗坑是主题漂移。一个长query里包含多个主题时向量检索往往会集中召回其中某一个主题的内容把其他主题全丢了。比如用户问“公司对销售人员的差旅报销和提成比例有什么规定”embedding可能把重心落在“差旅报销”上召回结果里全是报销制度“提成比例”的相关文档一条都没有。第二个暗坑是token级噪声。embedding是对整个句子做语义压缩的句子里的数字、型号、专业缩写这些关键细节在向量空间里经常被淹没。你问“支持iPhone 15还是iPhone 14”向量检索可能会因为在语义上更接近“手机系统更新”而把完全不相干的文档召回回来反而忽略了精确型号匹配。这两个坑单靠向量检索很难填平所以现在做RAG检索增强的团队基本都在用“组合拳”。3.2 混合检索和query改写先让问题变清楚再去找答案组合拳的第一路是混合检索Hybrid Search典型做法是“BM25关键词检索 稠密向量检索 RRF结果融合”。BM25能精准匹配那些对“精确词”敏感的查询比如型号、编号、人名向量检索擅长处理“语义相似但字面不同”的查询比如“如何申请报销”和“报销的流程是什么”。两条路各自召回top-K再用RRF算法把两个列表融合成一个按排名倒数的加权和排序。这套组合在几乎所有我经手的RAG项目里都有明显提升尤其是涉及数字和专有名词的场景提升幅度大到没法忽视。组合拳的第二路是query改写。很多用户的提问非常简短比如“它的优缺点”“对比一下”这种query直接丢进检索系统谁来了都救不了。我现在的做法是在检索前面加一个轻量改写步骤用一个小的LLM把用户query扩写成“更完整、更适合检索”的问题。比如“它的优缺点”改写为“LangChain框架在构建RAG应用时的优缺点”再去检索命中率立刻不一样。更进一步的做法是做多query检索让LLM把一个问题拆成几个子问题分别检索再合并结果这已经是智能体式RAG的雏形了。成本会高一点但对复杂问题的效果提升非常明显。3.3 重排不是可选项而是免检项检索召回top-20之后直接用top-5喂给LLM这个做法在效果要求高的项目里是不够的。召回列表前几名里经常混着一眼就能看出不相关的内容。这时候就需要重排器reranker上场。常见做法是上一层cross-encoder模型对query和每个召回chunk做细粒度的相关性打分再把分数重新排序。说到底普通embedding模型的向量相似度是“粗匹配”cross-encoder是“精匹配”两者精度差距很大代价是重排阶段会慢一些。工程上一般让向量检索召回top-30到top-50重排之后只留top-5速度和效果都能兼顾。我自己踩过的一次坑是图省事把rerank环节去掉上线后用户反馈“系统老答非所问”。排查了半天不是embedding问题是top-5里前3条都是一篇长文档的不同段落主题相同但是和提问无关。加上rerank之后相关段落被顶上来了问题立刻消失。重排器的成本不高收益却非常直接除非你的场景是纯实时、毫秒级响应刃否则我不建议省这一步。4. 嵌入模型与本地部署embedding选型的隐性账embedding模型是整个RAG系统里最容易被低估的部分。很多人选模型就盯着公开榜单的分数忽略了三个更实际的指标对领域术语的覆盖能力、对中文长文本的支持能力、以及部署和调优成本。这几个指标才是真正决定项目好不好用的东西。4.1 开源/国产/闭源模型选型实录我试过的几类模型先说结论没有绝对最好的模型只有最适合你场景的模型。OpenAI的text-embedding-3-small系列开箱即用英文效果很好但对中文的支持不如专门的中文模型精细且数据要出网很多企业内部场景过不了合规BGE系列BAAI/bge-m3中文效果扎实支持8192长度而且能输出稀疏向量做混合检索特别方便是目前中文RAG项目里口碑很稳的选择GTE系列中文长文本表现不错在学术和技术文档上的表现尤其稳各类国产商用API好处是省心、中文理解好坏处是供应商绑定后面想换模型迁移成本高另外一个容易被忽略的问题Java技术栈的团队做RAG时很多人不知道LangChain4j这个框架的存在以为只能硬写一堆Python服务来拼RAG链路。其实LangChain4j对embedding模型、向量库、重排器都有封装和Spring Boot集成很顺JVM团队完全可以省掉“用Python写一个RAG中间层”这种额外负担。4.2 本地知识库的硬件估算和模型取舍因为合规或成本原因不少团队最后都会落到“ollama 本地embedding 本地向量库”这条路上。之前那个热搜“ollama 简易本地rag知识库【零基础可复制教程】”能被搜到说明这套组合确实有大量需求。本地部署embedding模型的硬件门槛远低于LLM这是它的一大优势。模型向量维度推荐配置适用场景bge-small-zh5122核CPU 4G内存即可轻量场景单机演示bge-m31024建议4核 16G内存可上GPU中大规模知识库gte-large768建议8G以上显存长文本密集型知识库text-embedding-3-smallAPI1536无本地部署成本允许数据出网的中小项目一个小细节用ollama跑embedding时很多人仍然沿用跑LLM的量化方式结果把embedding模型也量化了导致检索效果肉眼可见地变差。embedding模型我强烈建议保持原始精度不要量化这一点点资源节省根本不值得用效果来换。4.3 召回效果怎么快速评测而不是靠“感觉”很多人换embedding模型全靠“感觉”这很不科学。我自己搭了一个极简但有效的评测集从知识库里挑20个典型问题和对应的正确答案文档ID然后写一段脚本分别用不同模型跑召回算出top-5命中率。整个脚本几十行就能写完但从此每次换模型、调参数都有了客观依据。你会发现很多模型在榜单上分数差零点几个点实际跑你的领域文档时差距能拉到十个百分点所以永远不要拿公开榜单当唯一参考用你的文档实测才是正道。5. 知识库长期主义增量更新、失效检测与ontology组织我见过太多RAG项目Demo演示的时候惊艳四座跑一个月之后开始胡言乱语。原因不是模型变笨了而是知识库没有跟上现实的变化。文档更新了旧版本还躺在向量库里某份制度已经废止系统还在引用它新增的几十篇资料没有入库用户问什么都说不知道。如果说前四处分水岭决定了RAG“能不能用”这一处就决定了它“能活多久”。5.1 增量入库和内容失效RAG最容易被忽视的运维债向量库的“更新”和关系型数据库完全不同。你不能直接改一行数据就完事因为文档切分后是一个个chunk新增一篇文档要重新切分、重新向量化、再写入删除一篇文档要按文档ID把它的所有chunk都捞出来删掉。很多团队图省事每次更新都全量重建文档少还好文档上千份之后每次全量重建要花几十分钟甚至更久根本没法定时做。我现在的做法是每篇文档入库时打上唯一的document_id和版本号增量采集时用hash比对新文档和旧文档是否变化变了就把旧的document_id对应chunk全部删除重新切分写入定期做一次失效检测把长期没有被检索命中、且文档源已经标记“废止”的chunk清理掉这一步的工程工作量不大但很多团队在项目初期完全没做设计后面运维起来特别痛苦。知识库维护这件事前期设计得好就是例行公事前期偷懒后面就得天天救火。5.2 为什么有人开始用ontology RAG检索系统的召回质量不只是embedding决定的知识组织方式也在起作用。传统RAG把所有文本切碎后平等地丢进向量库本质上是“扁平化”的知识组织它缺少对概念层级、实体关系的表达。这也是为什么越来越多人在探索ontology RAG本体RAG的原因。说白了ontology就是给你的领域做一张“概念地图”定义出“项目”包含“任务”“任务”指派给“人员”“人员”属于“部门”。有了这层关系检索和推理就不再是纯粹的“找相似文本”而是能沿着关系路径去找答案。比如用户问“某个项目现在卡在谁那里”纯向量检索只能找到提到“项目”和“阻塞”的片段但本体RAG能沿着“项目→任务→负责人”的路径把答案关联出来。不过我不建议一上来就搞大而全的本体工程维护成本极高。比较务实的路线是先用传统RAG解决80%的问题然后针对那些高频的、涉及多实体关系的业务问题只建一个小scoop的本体层慢慢迭代。ontology RAG在知识图谱和问答结合的方向上确实有潜力但它不是银弹更不是替代传统RAG的“下一代方案”。5.3 知识库里的“wiki效应”和更新节奏这里我想顺带说一个和“wiki和rag”有关的观察。很多团队喜欢把wiki作为RAG的语料来源是有道理的wiki页面天然有稳定的标题层级和条目结构非常适合做切分和检索。但wiki类的知识库有个毛病条目之间互相引用频繁读者看着看着就需要跳到另一个条目如果RAG系统把“条目A内容引用条目B观点”这种情况处理不好检索时就会拿到断章取义的内容。所以基于wiki建RAG时我会建议把引用关系显式保留下来别让切分把“根据XX文档”这种指路牌给删掉。更新节奏上我倾向于给知识库分等级核心文档周级更新普通资料月级更新归档数据只在检索命中但文档源被标记失效时才清理。全量重建只在embedding模型更换或者向量库结构升级时做平时别碰。这样知识库能一直保持“半新鲜”状态既不烧钱也不会让用户觉得你家的系统永远停留在上个月的认知水平。6. 没有评测的RAG都是盲调用eval体系让优化可量化最后一处分水岭也是我觉得整个RAG工程里最重要却被最少人做的一环评测。RAG的链路环节太多了文档解析、切分、embedding、检索、rerank、prompt任何一个环节动了整体效果都可能变可很多人优化完全靠“跑几个问题看看结果对不对”。这种“凭感觉”的评测模式在小规模Demo阶段没问题一旦知识库上千篇、问题类型一多它就像在没有仪表盘的飞机上盲飞。6.1 RAGAS基础指标忠实度、答案相关性、上下文精度/召回目前最常用的RAG评测框架是RAGAS它提出了一组量化指标核心四个指标衡量什么我常用的判断方式Faithfulness忠实度答案是否基于检索到的上下文有没有幻觉逐条断言答案里的每个事实点是否在上下文中Answer Relevancy答案相关性答案是否切题有没有答非所问生成答案后反问“这个答案和问题的相关程度”Context Precision上下文精确率检索回来的chunk里有多少是真正相关的看相关chunk在返回列表里的排名位置Context Recall上下文召回率真正相关的chunk有没有漏掉看标准答案里的信息点是否都能在返回chunk里找到这四个指标每个都能自动化计算不用人工一条条打分。你改一个chunk_size、换一个embedding、加一个rerank跑一遍评测集看四个指标的变化优化方向立刻清晰了。6.2 如何快速搭一套评测集而不是靠运气要建评测集得先有“标准答案”。最省力的做法是拿wiki这类结构化公开文档来构建选一个你熟悉的wiki板块问它几个你已经知道答案的问题。每次改动完系统跑这30个问题看答案质量和指标变化你就能定量地知道改动是正向还是负向。如果你的知识库本身就是wiki类文档这个方法几乎零成本。搭评测集的步骤我建议这样从真实用户问题里挑30~50条高频问题覆盖不同类型事实型“XX的价格是多少”、对比型“A和B有什么区别”、流程型“如何申请XX”对每个问题写好期望的答案要点不一定是一个标准答案而是要点的列表用RAGAS指标做自动化评估每次改动记录指标得分有了这套评测集你换模型前后、改切片参数前后的得分差异一目了然。不少团队嫌麻烦跳过这一步然后每次升级模型都像开盲盒升完用户开始抱怨“最近怎么变笨了”还找不出原因。评测这件事真的不是可选项。6.3 我在一次评测中发现chunk_size影响的实测记录这里放一个我自己的实测数据很能说明问题。某个文档集上我把chunk_size从256调到512再调到1024其他条件不变chunk_sizeContext PrecisionContext RecallAnswer Relevancy备注2560.620.480.71召回太碎上下文不完整5120.710.820.85综合最好10240.660.900.73召回全但噪声多精确率下降答案开始冗余从这个数据能明显看出chunk_size不是越大越好也不是越小越好而是存在一个拐点。没做评测前我一直觉得512以上信息更全肯定更好结果实测下来1024虽然召回率提高了但精确率和答案相关性反而下降了因为每个chunk里的噪声太多。这类参数调优靠肉眼观察三五个问题根本总结不出来评测集配指标才是最靠谱的路径。我个人的体会是六处分水岭里前两处解析清洗、切分策略决定了RAG的下限产出的是“准不准”的问题中间两处检索链路、embedding选型决定了RAG的上限产出的是“灵不灵”的问题最后两处知识库运维、评测体系决定了RAG能不能长期可靠运行。很多项目做不好不是模型不够强而是这些真正花功夫的环节被省掉了。如果你正在优化自己的RAG项目建议从评测集搭起用一个客观的标尺去量一量自己到底在哪个环节掉链子再去对症下药地调那几处真正的分水岭。