最近的RAG圈子里，最不缺的就是各种“半小时搭好知识库”的教程。从LangChain到LlamaIndex，再到各平台的低代码工作流，把文档一拖、向量库一点、模型一连，一条检索增强生成流水线就算通了。我给你说，这一套我现在能闭着眼睛搭出来，你也行，教程里的步骤就那么多：加载、切分、向量化、检索、拼上下文、调大模型。但问题恰恰就在这里——流水线烂大街了，什么才不烂大街？

我前前后后做了三个RAG项目，第一个是拿开源demo改的演示站，跑得很欢；第二个是接真实业务数据，被老板一句“你搜出来的压根不是我要的东西”怼得哑口无言；第三个才算摸到点门道。折腾一路，我最大的感受是：大家拼的压根不是那套流水线，而是流水线之外的六个分水岭。谁把这六处想明白了，谁才能把RAG从“demo级”做到“能上线、能扛骂”的“生产力级”。

这篇文章我就把这六处掰开揉碎讲清楚，不贴那种复制就能跑的完整教程，重点讲清楚为什么你的RAG跟别人的RAG差距那么大，以及你接下来该往哪个方向使劲。

1. 烂大街的流水线到底是什么

1.1 标准流水线的长相

先给不熟悉的朋友画个像。所谓RAG流水线，标准流程就是：文档加载，文本切成一段一段，用Embedding模型转成向量，存入向量数据库；用户提问时，把问题也转成向量，在库里做相似度检索，取回topk片段，拼接到Prompt里，最后让大模型基于这些片段生成答案。

这一套流程的实现方式千篇一律，用一个简单的Python伪代码就能说清楚：

from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.vectorstores import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings loader = TextLoader("manual.md") docs = loader.load() splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) chunks = splitter.split_documents(docs) vectorstore = Chroma.from_documents( documents=chunks, embedding=HuggingFaceEmbeddings(model_name="BAAI/bge-large-zh-v1.5"), persist_directory="./chroma_db" ) # 检索时 retrieved = vectorstore.similarity_search("退款流程是什么", k=4)

这套代码你放到哪个项目里都能跑。切分参数调一调，Embedding换一换，向量库从Chroma换成Milvus、Qdrant、pgvector，本质都一样。正因为它的门槛极低，所以“会搭流水线”这个技能已经彻底通货膨胀了。

1.2 为什么一条流水线打不赢真实业务

只看流程，demo当然没问题，文档里搜一句“退款流程”，Top-4片段基本能出来，模型照着念一段，看起来就像那么回事。但凡是真实业务，问题一个接一个往外冒：

• 用户问的是“上个月华东区的退货单怎么走了那么久”，文档里根本没有“退货单走多久”这种原话，向量检索召回的片段驴唇不对马嘴；
• 用户给一个合同编号“HT-2025-0718”，Embedding对它几乎没有感知，精确匹配反而被语义检索冲得七零八落；
• 文档里新旧版本规则并存，模型上一句引用新标准，下一句引用旧标准，答案自我矛盾；
• 知识库每周更新，索引里的老数据却永远停留在建库那天，用户问的全是最新政策，系统答的全是上季度的事。

这些问题有一个共同点：它们都发生在流水线的上游决策环节和下游治理环节，而不是发生在“加载-切分-向量化-检索”这个大众熟悉的管道里。也就是说，真正决定一个RAG系统是鸡肋还是利器的地方，根本不在这条流水线上。

我总结下来，真正的分水岭集中在六个地方：切分策略、Embedding与检索机制、多模态知识处理、Agent化检索架构、知识冲突与更新治理、评测体系。下面我一个个说。

2. 分水岭一：切分策略——索引质量的上限由它决定

2.1 固定切分到底切断了什么

很多教程的切分参数写的是chunk_size=500, chunk_overlap=50，然后告诉你“这样挺好”。我一开始也是这么干的，后来认真去看向量库里存的都是些什么东西，才发现固定步长切分有个致命伤：它切出来的是字数的块，不是语义的块。常见的后果是，一个完整的条款被拦腰截断，前半段讲适用范围，后半段讲豁免条件，检索的时候命中了前半段，模型却答不完整。

更隐蔽的问题是，固定切分会把表格、列表标题和正文硬生生拆开。比如一个Markdown文档里，“退款规则”标题下紧接着一个编号列表，固定切分会把标题留在上一个chunk里，列表内容分到下一个chunk，等到检索阶段，模型拿到的是没有标题的孤儿列表，根本不知道这段文字在说什么。

我在一个合同问答项目里反复验证过：同样的文档、同一个问题，只是改掉切分策略，检索命中率就能差出两成以上。这不是Embedding模型的锅，是切分把文档的语义结构破坏了。

2.2 按结构切分、父子块切分和语义切分

真正能打的切分方案，一般要结合文档本身的结构。以Markdown为例，优先按标题层级切分，把标题、列表、表格作为一个整体保留。下面这段思路是我常用的：

def split_markdown_by_structure(markdown_text): # 按「# 一级标题」切割，再把二级标题以下的正文合并到同一个chunk # 保留标题信息，让每个chunk自带语境 sections = [] current_heading = "" current_content = [] for line in markdown_text.splitlines(): if line.startswith("#") and not line.startswith("##"): if current_content: sections.append({"heading": current_heading, "content": "\n".join(current_content)}) current_heading = line.lstrip("#").strip() current_content = [line] else: current_content.append(line) if current_content: sections.append({"heading": current_heading, "content": "\n".join(current_content)}) return sections

更进阶的做法是父子块切分。父块定得比较大，比如按章、按节，作为检索时召回的对象；父块内部再切出比较小的子块，作为最终拼进Prompt的内容。这样做的妙处在于：检索命中句子的层面，模型读到的却是整节的完整上下文。我见过不少RAG框架在文档里宣传这种parent-child方案，它解决的就是“大上下文”和“精准命中”之间的矛盾。

如果你手里的文档是PDF或者网页，还要注意先用解析工具提取结构。目前市面上有不少本地化的拆分工具，比如unstructured库、chunking工具、markdown解析管线，都能把PDF或HTML抽成带结构的内容，再交给切分逻辑处理。选工具的标准很粗暴：能不能保留标题层级、能不能保留表格、能不能识别列表。三步都不行的工具，再火也别用。

3. 分水岭二：Embedding选型和检索召回策略

3.1 语义相似度不是万能的

流水线里最常见的一个想当然就是：“反正我用的是语义检索，只要意思差不多都能搜到。”这想法坑过我不止一次。Embedding模型擅长捕捉语义相近的表达，但遇到精确数字、产品型号、合同编号、生僻专有名词时，它的表现远不如最简单的字符串匹配。

举个实际例子：业务方问的是“协议编号A-2024-086的违约金比例是多少”，你拿这段问句去做向量检索，库里明明有这个编号，但因为周围句子包含大量干扰词，这个片段的向量排序会被挤压到Top-10以外，最终模型根本没看到原文档。这种问题用纯向量检索很难根治。

另外，Embedding模型本身也有很强的领域偏见。通用中文模型在医疗、法律、金融等垂直领域的表现，与在新闻、百科上的表现完全是两回事。我踩过的一个坑是：项目初期图省事用了一个通用Embedding跑金融文档，检索精度惨不忍睹，后来换成在金融语料上微调过的模型，同样的切分和检索代码，效果直接提升一个档。选Embedding模型时，别只看榜单分数，尽量在你自己数据上抽200对问答做次快速验证，比什么纸面指标都靠谱。

3.2 混合检索 + 重排序，效果立竿见影

既然纯语义检索对精确词不敏感，那就把关键词检索请回来。行业里最稳的组合拳是混合检索：同时跑BM25稀疏检索和Dense向量检索，再用某种融合算法把两个结果整合在一起。实践中可以用RRF（倒数排名融合），简单有效：

def rrf_fusion(sparse_results, dense_results, k=60): scores = {} for rank, doc_id in enumerate(sparse_results): scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1) for rank, doc_id in enumerate(dense_results): scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1) return sorted(scores.items(), key=lambda x: x[1], reverse=True)

混合检索解决了“召回谁”的问题，但“谁排在最前”还得交给重排序解决。双塔Embedding算出的是向量间的大致相似度，交叉编码器（Cross-Encoder）才能让问题和文档真正做逐token交互，把相关度分数排得更准。标准做法是先用混合检索召回几百条候选，再扔给重排模型选出Top-5，精度和响应速度两头都兼顾。我实测下来，引入重排后，答案的引用准确率能提升不少，这已经不是什么偏方，而是成熟RAG系统的标配了。

4. 分水岭三：多模态知识库——把图片和表格也变成“知识”

4.1 热搜背后的真实需求：RAG知识库能存储图片吗

很多人问“RAG知识库能存储图片吗”，我理解大家真正想问的是：“我有一堆带截图的PDF、带图表的报表，系统能不能根据图片里的内容回答我的问题？”直接存图片进向量库是没用的，因为常规Embedding模型根本看不懂图片内容，你存进去一张图，模型检索它和瞎子摸象没区别。

真正的路径有两条。第一条是图文混排走视觉语言模型，用图片、文字混合的Embedding把图片和文字映射到同一向量空间，用户问“图上那条折线对应的峰值出现在哪个月”，系统能用图像语义匹配合适的图片。第二条是把图片内容“翻译”成文本再入库，这条路目前更成熟、更可控：PDF扫描件先做OCR，用版面分析识别出标题、段落、图片位置；图表用结构化抽取转成Markdown表格；正文截图用视觉模型生成文字描述。转化之后再走常规文本切分和向量化流程，知识库自然就“具备图片能力”了。

我实际做过一个包含大量产品规格图的问答项目，方案就是把每张图喂给视觉模型生成一段Structed Caption，比如“图1：左部分为产品正面，标注了端口名称；右部分为背面，标注了电源接口位置”，这段文字进入向量库后，用户搜索“背面电源接口”时就能准确召回。这比把图存进去有意义得多。

4.2 扫描件、表格、报表的统一处理思路

处理这类多模态文档，核心是“先转换，再入库”，不要指望检索时现场看图。扫描件文档我一般走这种链路：

PDF页面 -> OCR（版面分析+文字识别） -> 按阅读顺序重组文本 -> 表格区域转Markdown -> 图片区域生成Caption -> 统一走文本流水线

表格是最值得花心思的部分。直接对表格做纯文本切分，等于把每一行拆得支离破碎。我常用的方案是让表格保留行列结构，转成Markdown语法后再作为一个整体chunk入库：

| 条款 | 说明 | 生效时间 | |------|------|----------| | A1 | 首年免管理费 | 2025-01-01 | | A2 | 次年按季度收取 | 2025-04-01 |

模型在回答“A2条款生效时间”时，能拿到完整的表格上下文，精确度远超逐行切分的做法。这个“把视觉信息转成语言信息”的思路，远比纠结向量库存不存图片更重要。

5. 分水岭四：Agent化RAG——从“一次检索”升级为“多轮求解”

5.1 单次检索解决不了复杂问题

基础流水线的检索和生成是一次性的：用户问一句话，系统检索一次，模型作答一次。这在简单FAQ场景里够用，但业务问答根本不是单回合的事。拿一个真实场景举例：“对比我们上半年和下半年的退款率变化，分析可能原因，并给出两条改进建议”。这条问题需要查退款数据、查流程文档、查客户反馈工单，涉及多个数据源和多轮思考，单次Top-4的chunk拼接根本喂不饱。

还有一类问题是用户提问过于模糊，第一次检索的结果只能作为“探索”，需要根据初步结果判断下一步搜什么。比如“我们最新退款政策会不会影响老客户”，系统先要找到“最新退款政策”的定义，再找“老客户”的界定，再找两者之间的关系规则。整个过程像查案，不像查字典。

5.2 路由、改写、多步检索与工具调用

解决复杂问题，就要把RAG从“管道”升级为带有决策能力的智能体。我在实际项目里分了三层来改造：

第一层是意图路由。用户问题进来，先做一次分类，决定是走向量库、走SQL数据库、走文档目录，还是需要先调API获取实时数据。这一步能用极小的模型做意图分类，不用每次把所有检索链路都跑一遍。

第二层是查询改写。多轮对话里尤其关键，用户说“那如果换成企业客户呢”，这句话独立看毫无信息量，必须结合上文把它改写成完整问题：“如果把我们店铺的退款对象从个人客户换成企业客户，政策有何不同？”改写后再去检索，召回质量完全不同。这是RAG智能体和普通流水线最明显的能力分界。

第三层是循环检索。围绕一个复杂问题，系统可以执行“检索->阅读理解->判断信息是否充足->不足则再检索/查工具->继续阅读理解”的循环，直到信息足够再生成最终答案。这种结构用LangGraph这类图编排框架落地很顺手，每个节点负责一个小任务，状态里维护着已收集的证据，最终回答时还能给出证据链。

有一点我得特别说明：Agent化不是让模型自由发挥，它每一步都产出可解释的中间结果，检索过的片段、积攒的证据都要记录在案。这样出了问题，你能看到系统是“漏搜了一个文件”，还是“搜到了但判断错了”，而不是面对一个黑盒答案发呆。

6. 分水岭五：知识冲突与更新——流水线的定时炸弹

6.1 新旧文档打架，模型左右为难

很多人搭完RAG就以为万事大吉，直到用户拿新旧两版制度来问，发现模型一会儿答旧规，一会儿答新规，引用还振振有词。这就是典型的“知识库内部冲突”问题：同一主题存在多个版本的说明，内容相互矛盾，模型自己也不知道该信谁。

我在知识库治理上吃过亏，后来才总结出一套优先处理规则。每个文档进入向量库前，先打上元数据标签，至少要包含：文档版本号、生效日期、发布部门、适用业务线。检索阶段不只是比相似度，还要把元数据里的时效条件加进去，比如只搜生效日期在今天的文档。

冲突检测可以做成半自动流程：用聚类算法把高相似文本片段聚在一起，凡是同一主题下有多个说法不一致的片段，就拎出来人工复核或者交给LLM做汇总判断。我见过比较高效的团队，会在知识库建一个“冲突收敛表”，把每个争议主题的最终口径、权威出处、生效时间统一维护进去，检索时优先命中这个口径表。这一套做下来，RAG的答案稳定性会大幅提升。

6.2 增量更新和删除：最容易被忽略的坑

知识库更新不是一个“把新文档导进去”就算完的工程。增量更新时，同一个文档被反复切分入库，旧chunk还留在向量索引里，检索时新旧内容一并召回，答案就会产生混乱。很多向量数据库删除孤立chunk的能力都很弱，尤其是变更embedding模型或者做文档重切时，老数据就像幽灵一样潜在地干扰检索结果。

我自己的经验是两条：一是所有chunk必须带文档ID，更新时先按文档ID删掉旧chunk再写新chunk，不依赖向量库自动覆盖；二是定期做一次全量重建，因为增量入库会积累出碎片化的索引，全量重建虽然耗时，但能保证索引质量和文档现状一致。上线前要给自己建一条“知识更新演练表”，每个更新动作都跑一遍回归问答，别信“更新一下就好”的鬼话。

7. 分水岭六：评测体系——没有度量就没有优化空间

7.1 “感觉还行”是最贵的评价

做RAG项目最怕听到的一句话是“感觉还行”。行到什么程度？哪些问题答得好？哪些问题答得烂？哪次改动之后效果真的变好了，还是只是心理作用？没有评测体系，这些问题永远说不清楚。

我踩过的一个典型坑是：换了一个更贵的Embedding模型，离线跑了一轮检索，样例里看到几条结果变准了，就兴冲冲上了线。结果线上负面反馈率反而上升，原因是新模型对代码类术语的检索变好了，但对业务黑话的检索能力却下降了，我看到的几个样例刚好全落在前者。没有批量评测的支撑，任何“感觉有效”都是幻觉。

7.2 关键指标与评测集怎么建

RAG评测常用的指标有这么几个：检索阶段的上下文召回率和上下文精确率，生成阶段的忠实度和答案相关性。其中忠实度最值得关注，它衡量的是模型生成的答案到底有没有忠实于检索回来的上下文，如果模型在上下文之外自己编内容，忠实度就会爆红灯。这是RAG系统幻觉控制的头号指标。

现在有现成的评测框架可以引入，比如RAGAS，它用LLM作为评测器，对答案做批量打分。但它也有限制：LLM评判的本质是用一个模型去评价另一个模型的输出，指标只能作为初筛。真正可靠的评测，需要加上人工抽检和规则校验。我推荐的评测集构造方法是：

这套评测集不需要很多，先积累两百个真实业务问题，覆盖高频场景、边界场景、易错场景，然后再每次改动之后跑回归。评测集是你的护城河，因为业务会变、文档会变、模型会变，只有评测集始终告诉你“当前系统到底几斤几两”。我建议每天抽空收集几个“答得差的case”加进评测集，两周之后，你就能用真实数据证明下一步该优化哪个环节，而不是拍脑袋选方向。

8. 常见问题与排错实录

8.1 检索结果看起来对，生成答案却总是错

这类问题十有八九出在生成阶段的提示词设计或模型参数上。模型拿到了正确的上下文，但温度设置太高，它在上下文的“启发”下自由发挥，写出了上下文里没有的细节。解决办法是给Prompt加明确约束，比如“只能依据提供的上下文回答，且每一步结论都要在上下文中找到对应依据”，同时把温度调到0.1以下。还有一个容易忽略的点：Top-p或频率惩罚参数太激进也会压出语义漂移，参数越保守，忠实度越高。

8.2 明明不该搜到的，怎么总排在前面

先检查是不是切分粒度太小，导致一个完整的逻辑单元被拆成多个片段，检索时片段之间的重复噪音干扰了排序。更常见的可能是Embedding的域不匹配。如果是在专用领域（比如法律条款、设备维修）里，通用Embedding会把很多专有名词当作“无关词汇”忽略掉，噪声自然排到了前面。解决办法就是换一个领域微调过的Embedding，或者把关键词检索的权重调高。

8.3 本地跑RAG，文档越来越多，检索越来越慢

Vetor数据库的召回效率和索引规模直接相关。如果做的是本地RAG，数据量到了几万条chunk以后，暴力检索的耗时就会明显上涨。我自己的处理是分层：先做标题/目录级别的粗筛，缩小候选范围，再在候选子集里做细粒度向量检索。此外，Embedding模型换成量化版、向量库开启GPU支持的加速索引，都能明显降低延迟。别一上来就为慢而焦虑，先量化数据规模，再决定投入多少成本。

8.4 多轮对话里第二问就找不到北

用户的第二问往往缺少主语，比如“那电子发票呢”，没有历史信息的检索系统根本不知道“那”指代的是什么。解决这个问题要加一层“对话改写”模块，把最近几轮对话压缩成一句完整查询，再送入检索链路。这一步比在检索后加多少重排序都更管用，因为问题本身的指向性准了，后面的所有环节都会跟着受益。

踩坑踩得多了之后，我现在最深的体会是：RAG不是一门“调包”的手艺，而是一门“诊断”的手艺。流水线只是把文档和模型连起来的那根管子，真正决定它能流出多少“有用知识”的，是你在切分、检索、多模态、智能体、知识治理和评测这六个截面上投入了多少思考。这个行当里，能被教程批量复制的东西已经彻底烂大街，剩下来拼的，全是教程写不清、demo跑不出、只有到真实业务里才能逼你想明白的细节。今天这六个分水岭，就是我在这些细节上真金白银换来的清单，希望能帮你少走几步弯路。