“RAG 烂大街”这话我听过太多次了。说实话随便一搜教程、框架、Starter模板铺天盖地GitHub上一天能冒出几十个“企业级RAG”仓库。但真正落地过十几个RAG项目之后我的感受是烂大街的不是RAG是那条“文档加载 → 文本切分 → 向量化 → 检索 → 拼提示词 → 让模型生成”的固定流水线。这条流水线谁都能跑通跑通它不叫会RAG叫会用框架。真正的分水岭藏在这条流水线的六个细节里文档解析、切分策略、检索与重排、上下文组装、评测体系、知识库形态。这篇就聊聊我做这些项目时在这六处踩过的坑和拉开的差距每一处都直接决定最终效果的上限。1. 文档解析读文件不等于读懂文件1.1 为什么解析是RAG的第一道分水岭很多人搭RAG时第一步就用现成的Loader把PDF往里面一丢跑起来一看检索效果差得离谱。然后开始怪模型不行、怪提示词不行、怪向量库不行。实际上问题大概率出在最上游文档压根没被正确读出来。RAG这条链路里解析质量决定了整个系统的信息天花板。如果PDF里的表格被读成一团乱码图片里的文字根本没被提取多栏排版的内容被拼得前后颠倒那后面无论怎么优化切分、怎么调检索都是在一个残缺的信息集上做文章。天花板已经在那里再怎么折腾也突破不了。我见过不少项目文档是扫描件根本没有文本层Loader读出来全是空白但没人检查这一步直到上线后被用户反馈“明明库里有这份文件为什么回答不出来”才发现。这个排查成本比一开始就认真做解析要高出一个数量级。1.2 实操PDF、图片、表格怎么处理先说热词里那个“RAG知识库能存储图片嘛”。答案是可以但得分清楚是什么形式的“存储”。如果你说的是图片原样入库用CLIP这类图文向量模型是可以做的但实际业务里性价比很低。更常见的做法是用多模态模型或OCR先把图片里的文字、表格抽成结构化文本再用文本向量入库。这样下游检索、生成、引用溯源都统一在文本体系里简单可靠。我实际项目中处理各类文档的方案大致是这样的纯文本型PDF、Word直接用pdfplumber、pypdf、python-docx提取文本。这类文件快且准不需要重武器。扫描件/图片型PDF先做OCR。我常用PaddleOCR中文场景比Tesseract好很多印刷体准确率高还能输出位置信息如果整页都是复杂版面配合PP-StructureV2做版面分析。表格类内容pdfplumber能抽表格结构但遇到合并单元格、跨页表格时会乱复杂表格我用Camelot或者直接把表格区域截图交给视觉模型转成Markdown表格。公式类内容Mathpix或Latex-OCR识别公式存LaTeX原文检索时转成纯文本或保留公式结构。核心原则是按文档类型选解析方案而不是一个Loader走到底。每类文档维护一份解析配置解析完成后做抽样检查而不是全量信任工具输出。1.3 解析质量的三个常见坑第一个坑多栏PDF被当成单栏顺序读。技术报告、新闻排版常见的双栏布局不经过版面分析直接读文本会变成左栏一行、右栏一行交错拼接语义完全断裂。解决思路是先做版面分割按栏切分再重组逻辑顺序。Unstructured、Marker、Docling这类工具都能做实测Marker对复杂PDF的容忍度高一些但对格式要求高的场景还是需要人工复核。第二个坑表格被压平成纯文本。一个产品参数表被读成“名称xxx 型号xxx”向量检索时字段边界全丢了。最好在解析阶段就把表格转成结构化形式比如Markdown表格或者“字段名: 值”的键值对文本这样既保留语义又方便后续检索和引用。第三个坑图片里只有图没有字。很多图表、截图里的文字是可提取的OCR问题但真正的图表含义是提取不出来的。比如一个折线图趋势是上升还是下降OCR只能读到坐标轴数字。这种内容要么靠视觉语言模型做“图表描述”要么人工补一段说明文字再入库。我建议在知识库建设规范里明确规定图表必须配有Alt文本或说明字段否则RAG回答这类问题时一定会翻车。注意解析不是一次性工作。文档更新后解析结果要重新生成并且要做diff检查别让旧版残片污染知识库。2. 切分策略你切的不是文本是语义2.1 固定窗口切分的致命伤大部分RAG教程里最常出现的切分方式就是按固定字符数切块比如每500个字一块重叠50个字。这种切分在Demo项目里跑得通一旦遇到真实业务文档问题立刻就出来了一个完整的技术方案可能被拦腰切断结论在上一块理由在下一块一个列表项被劈成两半代码示例从中间断开。检索时命中的只是半个观点LLM拿到的上下文天然残缺回答自然不完整。这里要理解一个底层逻辑向量检索的目标不是“找到包含关键词的字符串”而是“找到能回答问题的最小完整语义单元”。语义单元的大小和边界取决于文档的写作结构和信息的组织方式和固定字符数毫无关系。所以切分策略的本质是在为下游检索划定“答案的证据边界”。有人觉得切小块能提高召回率因为小块向量更聚焦、更容易命中。但代价是每个块携带的上下文太少生成阶段靠模型脑补的信息就越多幻觉风险越高。切大块则语义完整但噪声多embedding的平均池化会稀释关键信息导致“什么都像什么都不像”。这个矛盾没有固定答案只能针对语料测试。2.2 常用的切分方案怎么选我实际项目里会按优先级试这几种结构切分如果文档自带结构比如Markdown标题、HTML标题、Word层级标题、PDF里的章节就按结构切。这是最推荐的方式因为文档作者已经在切分语义了。LangChain的MarkdownHeaderTextSplitter就是干这个的配合RecursiveCharacterTextSplitter做尺寸兜底。递归字符切分没有清晰结构时用RecursiveCharacterTextSplitter从段落 → 句子 → 分词符逐级缩小尽量保证切出来的块是完整句子。这是通用场景保底选择。语义切分按embedding的句向量相似度合并句子语义断裂处分块。这种方式效果好但计算成本高而且对短文档容易过度切碎。可以用semantic-text-splitter或 LangChain的SemanticChunker实验。父子切分子块负责检索父块负责生成。子块小、语义聚焦容易命中命中的子块关联回包含它的完整章节喂给LLM的内容还是上下文完整的。这种方式对“细节精准定位完整上下文理解”的场景非常有效代价是实现复杂度高一点。2.3 切分与检索的联动调整切分参数不是拍脑袋定的要和你的检索策略联动。chunk size定了之后你拿一批真实问题去测检索命中率命中率不理想就调整chunk size或切分方式。重叠度我一般设10%~20%过大反而引入重复信息影响后续去重效率。还有几个容易被忽略的细节。一是嵌入模型的max_seq_length别只看模型文档要实测长文本是否真的有效很多模型对超过训练长度的输入会输出“懒惰向量”二是不同业务文档可以有不同切分策略合同条款适合按条款切、代码库适合按函数切、技术手册适合按主题切把“切分策略”做成可配置项而不是全局一个函数。我踩过的一个比较典型的坑在某项目里所有文档统一用500字固定切分结果把大量表格切碎了检索命中一堆表头碎片回答质量惨不忍睹。后来改成“表格优先整体入库普通文本按标题结构切分”同样的问题立刻缓解。所以做切分前先解析清楚文档里有哪些内容类型再分别定策略。注意切分后的块最好带上元数据比如来源文件、章节路径、页码。这不仅是引用溯源的需要也是后续做父子切分、权限隔离、增量更新的基础。3. 检索与重排向量检索只是半条腿3.1 纯向量检索的瓶颈很多RAG项目检索环节就一个操作问句过一遍embedding在向量库里做相似度搜索TopK捞回来。这套方案看起来没问题但实际使用时瓶颈非常明显。纯向量检索对专有名词、缩写、编号、代码、公式这类“精确匹配”场景天然不友好。你问“iPhone 15 Pro的A17 Pro芯片功耗”向量检索可能把“芯片功耗”关联到一堆关于A17的文章但精确提到“功耗数值”的那段反而排名靠后。还有短查询和长文档的表征错位问题用户的query可能只有十几个字而文档切片是几百个字embedding模型对两种文本的编码方式差异很大相似度分数未必能反映真实相关性。这就是为什么“RAG检索增强”这个热词背后真正要增强的不是“再调一个更牛的embedding模型”而是“检索策略本身的召回能力”。3.2 混合检索的基本组合我的主力方案是混合检索BM25关键词语义检索 向量检索并行召回再做结果融合。BM25擅长精确词匹配向量检索擅长近义和语义匹配两者互补之后专有名词和口语化问法都能覆盖到。融合方式有两种常见选择。一是RRFReciprocal Rank Fusion把两个结果列表按排名倒数的和重新排序不依赖分数尺度简单稳定二是加权线性融合需要把两种检索的相似度分数归一化到同一范围再加权求和。我实测下来RRF更省心尤其当你混用的向量库和全文检索工具分数分布差异很大时。针对热词里反复出现的“RAG瓶颈”我基本都会先检查这一环先看单独跑BM25和单独跑向量各自召回了什么再看融合后是否把两个来源的高相关都包含进来了。很多“答案不准”的问题在这一步就能暴露。3.3 Rerank为什么要单独做混合检索召回的TopK结果仍然只是“粗排”。向量模型的相似度本质上是“语义相近”不是“能回答问题”。这时候需要Rerank模型来精排把query和每个候选片段同时扔给cross-encoder逐对计算相关性分数这个分数才是直接服务于“能不能答这道题”的判断。我用过bge-reranker-base和bge-reranker-large效果差异明显。base版本快但精度有限large版本慢一些但对复杂query的排序提升很大。Rerank的另一个作用是砍掉“低相关但高相似”的噪声。比如检索TopK召回20个片段经过Rerank后只保留Top5~8这些片段才是真正进入提示词的候选。有人觉得Rerank会把速度拖垮实测下来如果只在Top20~50的范围内做精排耗时还是可控的。性价比很高强烈建议上线。3.4 检索参数怎么调几个常用参数的经验值召回TopK我先取20~30给Rerank留足够的选择空间Rerank后再取3~6个片段进入生成太少容易信息不足太多则容易混淆模型。相似度阈值要看你用的embedding模型的分数分布来确定在我常用的一些模型里0.2~0.3之间的相似度片段大概率是噪声低于阈值的直接丢掉。这里有个很容易踩的坑不同向量库返回的相似度分数含义不一样比如有的返回余弦相似度有的返回欧氏距离有的返回归一化分数。如果你用加权融合不先归一化权重设置基本是白调。所以我一开强调用RRF Rerank能绕开这些分数尺度的历史遗留问题。4. 上下文组装与提示词模型不是垃圾桶4.1 检索结果不要直接塞给模型有不少教程会把检索到的TopK片段直接拼成一大段上下文然后问模型“请根据以上内容回答”。这样做的问题在于大语言模型对超长上下文的中间部分存在明显的注意力衰减也就是常说的“lost in the middle”。当上下文里塞了十几个片段模型很可能只盯着开头和结尾看关键信息如果在中间回答就会漏。另外检索回来的片段之间往往有重叠或有重复信息直接拼接会放大模型对重复信息的权重导致回答围绕某个局部细节反复绕整体结构反而失衡。所以上下文组装这一步核心任务是“清洗压缩排序”而不是无脑拼接。4.2 上下文压缩与去重组装上下文的步骤我一般这么处理语义去重把Rerank后的片段两两算一遍相似度去掉重复度高的保留信息增量大的那个。按相关度排序Rerank分数高的片段排在前面让模型优先关注高相关证据。按原文顺序重排如果是多个段落服务于同一个结论按原文的先后顺序排列更符合叙述逻辑模型更容易理顺因果。控制总量根据生成模型的最大上下文长度留出足够的输出余量。比如模型支持32K上下文不要塞到30K给回答留够空间否则长回答会被截断。还有一个重要操作是来源标注每个片段前加上[来源文件A第3章第2节]之类的标题。模型在生成时能引用这些标记用户看到的答案带上引用溯源可信度大幅提升。这一步对ToB知识库几乎是无条件要求。4.3 提示词模板的设计要点提示词写的不是“请回答”而是“角色 任务边界 引用要求 拒答策略”。我常用的模板结构大致是这个思路你是企业知识库的智能助手。请严格基于提供的参考资料回答用户的问题。 要求 1. 只使用参考资料中的信息不得使用模型内部记忆或推测。 2. 如果参考资料不足以回答问题请明确回答“当前知识库中没有相关信息”。 3. 答案需在适当位置标注引用来源格式为[来源文件名]。 4. 回答使用中文保持简洁准确优先列出关键结论。 参考资料 {context} 用户问题{question}这里的关键设计是“如果资料不足就拒答”。不加这一条模型会强行从内部知识里找答案幻觉就出来了。加了这条至少能保证知识库系统的可信边界。还有一点多轮对话场景建议先把历史对话压缩成独立query再检索你可以用“根据对话历史把用户最新问题改写为一个独立、完整的检索query”这样一个前置步骤而不是把聊天记录一起丢给检索器。热词里提到“RAG智能体”我多说一句Agent形态无非是把检索、工具调用、多步思考编排在一起但底层如果单轮检索就不准Agent只会把这些噪声放得更大。先把单轮检索做扎实再谈Agent。5. 评测没有评测就没有优化5.1 评测维度RAG项目上线后最大的问题是你很难说清楚它到底变好了还是变差了。改一个embedding模型、改一下切分参数效果起伏不定但凭感觉觉得“好像变聪明了”这不叫优化叫玄学。我建议从三个核心维度做评测上下文相关性Context Relevance检索到的上下文是否真的覆盖了回答问题所需的信息。这一项衡量的是“召回质量”。答案忠实度Faithfulness生成答案是否严格基于上下文有没有出现上下文里没有支撑的额外信息。这一项衡量的是“幻觉程度”。答案相关性Answer Relevance模型是否真正回答了用户问题有没有答非所问。这一项衡量的是“问答对准度”。这三者其实是递进关系检索拿不到好东西后面再怎么调生成也无济于事检索拿到了好东西但模型没忠实使用照样是幻觉都对了但回答没有针对用户问题用户还是不满意。5.2 评测集怎么构建评测集是评测体系的灵魂。它不需要很大200~500条就够了关键是来源真实。我从真实用户日志里抽一批高频问题再补充业务方提供的FAQ和典型疑难问题一起整理成“标准问题集”。每条评测数据我建议包含几个字段问题、标准答案、支撑文档ID、类型标签比如单跳问答、多跳推理、数值聚合、对比分析。有了类型标签你就能看到系统在哪些类型上强、哪些类型上弱针对性优化。人工为每条写标准答案的工作量确实不小但这是你调参时唯一的“参考答案”值得投入。评测跑起来之后我用它对比不同embedding、不同切分策略、不同TopK数量、Rerank开与关的效果差异。没有测评集的话这些对比都是拍脑袋。5.3 评测跑起来之后的用法我实践下来的流程是先离线评测用测评集跑一遍算三个维度的平均分和分类型得分看哪个环节拖后腿。然后针对短板做实验上下文相关性低就去调检索和切分忠实度低就去调上下文约束和提示词。每次改动后全量回归一次评测集别只看一两个case的表现。有人跟我争论说LLM当裁判会不会有偏差会一定有。所以我在评测集里另划了一批人工标注的抽样子集定期人工核对LLM打分和实际表现的偏差。评测的价值不在于绝对分数而在于“相对比较”你改了A方案和B方案用同一套评测集跑分数谁高谁就大概率更好。这个相对判断已经足够指导绝大多数优化决策了。6. 知识库形态从文档库到结构化知识库6.1 三类知识库的边界热词里有一条“kg知识库、rag知识库和结构知识库区分以及应用场景”这确实是很多人的困惑。我用大白话梳理一下文档库向量知识库存的是非结构化文本切片适合报告、说明书、客服文档、会议纪要。优点是接入快、通用性强缺点是不擅长精确计算、实时数据、多跳关联。结构化知识库存的是数据库里的记录通过API、SQL查询获取答案适合订单、库存、价格、人员信息这类强字段、实时性要求高的数据。准确性极高但不适合开放式问答。知识图谱/本体知识库存的是实体和关系比如“供应商A供应了原材料B原材料B用于产品C”。适合多跳推理比如“哪些原材料影响了产品C的成本”。实际业务里绝大多数知识都是文档形态所以纯RAG用得最多。但纯向量RAG处理聚合和多跳问题时确实很吃力。你问“过去三个月A产品退货率最高的三个原因是哪些”纯向量库很难直接回答因为答案是跨多篇文档、多字段聚合出来的。这时候硬让RAG生成模型就会开始编。6.2 知识图谱与Ontology的想法“Ontology RAG”和GraphRAG本质上就是往RAG链路里加入结构化的实体关系。基本思路是先把文档交给LLM做实体抽取和关系抽取构建成图结构。查询时要么先走图检索拿到相关子图再把子图转成文本作为上下文要么把图结构和文本切片结合做混合检索。这里的关键是“本体Ontology”的设计。本体就是定义“这个领域里有哪些概念、概念之间有哪些关系”的约束。比如医疗知识库里定义“药品-适应症-副作用”三种实体和两种关系抽取时LLM只按这个schema抽输出就是可对齐、可更新的结构化数据而不是一堆散文本。我个人的建议是不要一上来就上GraphRAG它构建成本高、维护复杂。只有当你的高频问题里出现大量多跳和关联分析时再考虑。前期把文档库RAG做扎实性价比要高得多。6.3 什么时候升级知识库形态给你一个判断依据观察用户查询的语义类型。如果大量查询是“某某文件里怎么说的”“某某产品的参数是什么”文档库RAG够用。如果出现“对比A和B的差异”“总结C产品的演进过程”这类跨文档归纳需要更强的检索和生成编排。如果再进一步出现“统计”“聚合”“关系链”一类比如“哪些供应商交付过X物料”基本可以确定纯向量RAG有天花板该上SQL查询或知识图谱了。热词里还有“wiki和rag”顺带说一句。Wiki本质上是带结构和链接的文档库非常适合作为RAG的数据源。多数时候把Wiki的页面层级、交叉链接利用好比重新造图谱更有价值。你可以在切分时把Wiki的目录结构和链接信息保留在元数据里检索时可以顺着链接做一层上下文扩展。7. 常见问题排查速查和你可能踩过的坑7.1 常见问题速查表症状可能原因排查方法解决思路检索不到相关文档解析丢失文本、切分过小/过大、embedding模型与语料领域不匹配抽查解析结果单独测BM25和向量召回换解析方案按结构切分换领域适配的embedding模型答案与原文冲突检索到低相关片段、Rerank缺失、TopK混入噪声查看进入上下文的片段与答案的对照加Rerank降低TopK数量提高相似度阈值幻觉严重上下文缺少约束指令、相关资料缺失检查提示词是否要求严格基于上下文加“资料不足必须拒答”约束补充知识库内容回答断断续续不完整chunk太小、生成上下文被截断检查实际送入模型的上下文长度与生成长度增大chunk压缩上下文预留输出空间更新知识库后旧答案仍在命中缓存、向量索引未重建确认检索链路是否走了旧索引版本化向量索引更新后强制重建图片/表格内容回答乱OCR或表格解析环节没做好检查解析后的文本换PaddleOCR、Camelot或视觉模型补充描述Agent多步检索不稳定查询改写失败、工具说明不清晰查看子查询日志与工具调用记录优化query改写提示词完善工具描述与路由规则7.2 几条实战心得解析和切分是整个RAG系统里性价比最高的两个优化点。我见过不少团队花了大量时间调提示词效果提升很小最后发现是解析环节把表格内容读成了乱码、切分把结论切断了。花一小时修好解析和切分顶得上调三天的提示词。评测集一定要在项目早期就建。等到系统上线后再补你会陷入“凭感觉优化”的泥潭改什么都心里没底。有一个小评测集你就能在做任何改动后跑一遍分数客观知道是变好还是变坏这是工程化RAG和Demo项目最本质的区别。我在实际项目中还有一个小技巧线上系统把检索命中的片段和生成答案都做日志落盘。用户反馈某个问题回答不对时直接查日志看当时模型到底拿到了哪些上下文。很多问题看一眼上下文就知道是检索漏了、还是模型没用好排查速度能快好几倍。我做过的RAG项目里凡是效果翻车的十有八九不是模型不够强而是这六处细节里的某一环在偷工减料。这六处不要求你一次全做到顶尖但至少你要清楚自己的系统卡在哪一环。先补齐短板再谈优化上限。这个内容后续还可以继续扩展的方向很多比如多模态检索、记忆机制、增量更新与权限管理但万变不离其宗——先把基础流水线之外的那几个关键点打磨好你的RAG才算真正立得住。