每天打开技术社区几乎都能刷到一篇新的 RAG 教程。标题长得都差不多——“基于 LangChain 构建本地知识库”“用 Dify 五分钟上线企业问答”“RAG 实战从零搭建文档问答系统”。跟着跑一遍半天时间就能在本地把一条流水线打通文档加载、切分、Embedding、向量库、检索、塞进 LLM 生成答案。Dify 这类低代码工具甚至把这一步压缩成了拖拽连线于是“RAG 烂大街”这句话越来越常听到。我的看法恰恰相反。烂大街的从来都只是那条标准流水线本身真正拉开项目成败的是流水线前后那六处大多数人一笔带过的细节。结合这几年在真实项目里踩过的坑我把它们浓缩成六处分水岭文档解析、切分策略、检索通道、结构知识、上下文组装、评估闭环。每处分好了效果可能是数量级的差别分不好RAG 就永远停留在 Demo 阶段。这篇文章不打算再写一遍完整搭建步骤只讲这六处在哪、为什么重要、以及最后我是怎么处理的。1. 为什么人人都能跑通 RAG 流水线却很少能直接上线1.1 一小时跑通 Demo 的仪式感RAG 的标准流水线拆开来就那么几步Loader 读文档Splitter 切文本Embedding 模型转向量向量库存起来Retriever 去查最后把查到的片段和问题一起丢给大模型出答案。这个链路已经被写进无数教程里原理也不复杂——给大模型配一个外挂记忆体知识不用塞进模型参数随时查随时用。问题在于教程里演示的文档通常是一份干净的 Markdown问题也是精心设计的“美联储加息对 A 股有什么影响”这类通用问题。跟着敲一遍你确实能在 Mac 上把整套东西跑起来还能看到像模像样的回答。于是很多人产生一种错觉RAG 已经简单到没有技术含量了。1.2 从 Demo 到产品的那几道暗沟一旦把同样的代码扔到真实项目面前落差立刻出现。我在企业里做过好些知识库项目几乎每次翻车都翻在同一个地方——不是流水线没跑起来而是跑起来之后答非所问、检索命中率低、答案看着流畅但信息是错的。举几个常见现场文档不是干净的文本而是扫描版 PDF、双栏论文、带复杂表格的 Excel用户问的是“PA-1002 项目的验收材料在哪”“这个型号的备件适配哪个批次”编号和专有名词一检索就丢答案是编的模型把检索到的片段当参考自己脑补出了不存在的结论知识库里几百份文档按部门做了权限隔离但检索时把不该看到的也捞出来了没有评估手段改完切分参数也不知道是变好了还是变坏了。这些问题的共性是流水线本身只负责打通不负责做对。Loader 决定了模型能看到什么Splitter 决定了能不能被检索到Retriever 决定了找得准不准上下文组装决定了答案质量评估决定了你怎么持续改进。每一步都像水管上的阀门任何一个没拧对最终流出来的水都是歪的。Dify 这类平台确实把流程编排的门槛降得很低但低代码不代表低成本——你依然要理解每一步背后的数据形态和处理逻辑。这也是为什么我坚持认为RAG 的分水岭从来不在“能不能搭出流水线”而在“能不能针对真实数据把每个环节调对”。2. 分水岭一文档解析与多模态内容决定 RAG 能学到的上限2.1 真实 PDF、扫描件、双栏排版、表格——文本提取不是 CtrlC很多教程会把文档加载讲成一句“loader.load_text”好像所有文件都自带干净的文字层。真实业务里最常见的痛苦恰恰在这一步。文本型 PDF 和扫描型 PDF 是两种完全不同的东西。文本型 PDF 里有文字层PyMuPDF、pdfplumber 可以近乎无损提取扫描型 PDF 本质是整页图片必须先做 OCR否则提取出来就是一片空白。中文场景我踩过一个坑用 Tesseract 跑扫描件识别率惨不忍睹后来换 PaddleOCR 才勉强能看。不是说 Tesseract 不好而是它对中文排版的支持确实不如 PaddleOCR 顺手。比 OCR 更隐蔽的是双栏论文和复杂表格。双栏 PDF 按页码直接转文本提取结果是左栏第一行、右栏第一行、左栏第二行、右栏第二行交错拼在一起语义链全断。我处理过一份投行研报转完文本之后“公司主营业务”和“财务指标”混成了一坨检索出来的 chunk 前言不搭后语。表格更麻烦按行读取会丢掉行列结构一个三行四列的对比表转成文本后变成三行扁平的句子列对应关系全没了。2.2 图片到底能不能进知识库两类图片、两套处理逻辑“RAG 知识库能存储图片嘛”这个问题经常有人问。答案能但要看你说的是哪种图片处理逻辑完全不同。第一类是图片里带着文字信息截图、扫描件、PPT 翻拍、带文字的图表。这类图的处理方式是把文字“取出来”——OCR 识别或者让多模态模型生成图片描述Caption再把这段文字作为文本内容进向量库。检索时用户问“这张图里的结论是什么”命中的是图片生成的文字描述而不是图片本身。第二类是图片本身就是信息主体UI 设计稿、产品外观图、一张狗的照片。用户问“这张设计稿里按钮的间距是多少”你没法靠 OCR 拿到布局数据。这类内容需要多模态 Embedding 模型来向量化图片或者更朴实的做法——把图片 URL 存进数据库在问答阶段把原始图片直接作为多模态输入丢给支持视觉的大模型。这里有个常见的误解往 Milvus 里塞了图片向量就叫“知识库支持图片了”。实际上向量库只存了向量检索之后你依然要把图片取出来交给能“看图说话”的模型去生成回答。所以更准确的说法是图片知识库 图片的原图/URL 向量索引 多模态 LLM 读取链路三者缺一个都不完整。2.3 一套能扛住真实资料的解析组合我的经验是不要一上来就上重型方案先做文档摸底再选解析路径。具体顺序大概是先用 PyMuPDF 尝试提取文字层能提出来的不走 OCR提出来的文本检查排版双栏的先用版面分析模块处理或者按坐标把左右栏拆开再拼接表格单独抽出来不要混在正文里切分。简单的规则型表格可以用 pdfplumber 抽复杂表直接整块截成图交给多模态模型在问答时读取扫描 PDF 的固定路径是 PaddleOCR识别完要保留坐标信息便于后续版面处理最后做清洗去掉页眉页脚、处理断词连字符、把全角半角统一。这里有个很重要但常被忽略的点解析质量的损失是不可逆的。切分、检索、生成环节都能反复调优唯独如果原始文档没解析好后面再怎么精修都是沙上建塔。我在一个合同审查项目里就因为 PDF 里的表格行错位导致“甲方地址”被切到了“乙方地址”的 chunk 里模型回答直接张冠李戴。花三天优化检索最后发现病根在解析教训相当深刻。3. 分水岭二切分不是“按字数切开”而是“按语义边界切”3.1 固定窗口切分踩过的坑语义断了检索就瞎了切分是 RAG 里看起来最没技术含量、实际上影响最大的环节。默认做法是固定窗口chunk_size 设成 500chunk_overlap 设 50单词表按字符数硬切。这种方案在连续叙述类文档上勉强能用一旦遇到结构化内容立刻原形毕露。两个典型毛病。第一是切断语义一句话刚好卡在句中间或者一个完整的概念被拆到两个 chunk 里。我去过的一个项目里知识库存的是合规制度某条制度的核心定义在 chunk 35 结尾适用范围在 chunk 36 开头用户问“这项制度管不管采购部门”两个 chunk 单独看都答不完整模型只能用词面相关性硬猜。第二个毛病是检索粒度与答案粒度错位。有的文档段落很长一个“条款”可能覆盖上千字但固定窗口把它切成四五段。检索时命中的往往只是其中包含关键词的一小段模型拿到的上下文是残片没有前因后果。这就像你要查“这个产品的保修政策”系统给你的是保修政策里“不包含哪些情况”那半句话而不是完整的政策条款。3.2 三种能打的切分方案结构感知、父子切分、语义断点我后来在实际项目里基本在三类方案里选或者组合用。结构感知切分是最容易上手的升级。Markdown 按标题层级切HTML 按标签切Word 文档先读标题样式再切。核心思路是让切分器尊重文档原有的语义边界。规则很简单一个新的一级/二级标题出现强制开启新 chunk列表、表格整块保留。这样切出来的每个 chunk 都自带上下文模型读起来像是在读原文片段而不是拼接碎片。父子切分解决的是检索粒度和答案粒度打架的问题。做法是维护两套块小的子块用于检索粒度控制在 200-400 字尽可能精准命中命中之后回溯到子块所属的父块——通常 1500-3000 字把完整的上下文喂给模型。这套逻辑很像维基百科的“摘要词条 正文详情”先用摘要定位再展开看细节。LangChain 里叫 ParentDocumentRetriever实现成本不高但对答案完整性的提升非常明显。语义断点切分是最精细也最费钱的一类本质是让模型判断哪里该断句、哪里属于同一主题。低成本的做法是用句子向量算相邻句子的相似度相似度跌破阈值就当断点高级做法是直接让大模型按语义分段。这套方案适合知识管理类的专业文档效果最好但对算力和调用成本都有要求90% 的场景其实用不上。3.3 切分参数和检索策略必须联动设计切分不存在一套万能参数。我给团队定的参考基线是普通叙述文本 chunk 500-800 字、overlap 50-100制度条款类文档优先按条款结构切字数是结果而不是目标表格和图片单独成条不塞进正文 chunk。chunk_size 的选择背后有个矛盾关系块越大语义越完整但检索噪声越大块越小检索越精准但上下文越残缺。父子切分能在一定程度上化解这个矛盾但也不是无脑用父块过大会把不相关内容一起拖进 Prompt稀释有效信息。另一个容易忽略的点是切分策略一旦改变检索结果和后续调整全部推倒重来。所以我一直强调改切分必须带着评估去做——同一套测试问题改前改后各跑一遍用数据说话。4. 分水岭三检索通道向量检索只是默认值不是唯一解4.1 向量检索何时翻车精确词、编号、稀有实体很多人的 RAG 只有一条检索通道把用户问题转成向量到向量库做 TopK 余弦相似度搜索。这在语义宽松的自然语言问答上表现尚可但有几个场景会确定性翻车。第一个场景是精确编号查询。用户问“PA-1002 项目”向量检索对“PA-1002”这种符号组合不敏感因为 Embedding 模型把“PA”“1002”打散到了高维空间里词的精确形式反而被稀释了。你搜“项目编号是多少”向量库捞上来的可能是讲“项目管理流程”的泛化内容而不是编号对应的那一条具体记录。第二个场景是专有名词和缩略语。企业内部术语、产品型号、人名在预训练 Embedding 模型眼里几乎没有语义锚点。模型没见过“XX-A430 型传感器”和“A430”之间的关联词面匹配反而是强信号而向量检索恰恰不擅长词面匹配。第三个场景是短查询。用户上来敲三个字“验收书”向量模型仅凭这么短的输入很难在低维度语义空间里找准方向。BM25 这类稀疏检索方法对短查询和精确词的匹配能力反而更强。4.2 混合检索重排先广撒网再精打细算我现在的标准做法是混合检索最朴素的版本就是 BM25 关键词检索和向量检索并行跑各自召回 Top N再按 RRFReciprocal Rank Fusion或加权分数融合成一个候选集。这一步能同时保底词面匹配和语义匹配工程上几乎不增加多少复杂度收益却很直接。但混合检索只是第一步。融合之后的候选集通常有几十条里面鱼龙混杂直接截断到 Top 5 塞给大模型效果并不稳。于是第二个关键动作是加一层重排器Reranker。重排器是 Cross-Encoder 结构把问题和候选文档逐对拼接后算相关性分数比 Bi-Encoder 的向量相似度精细得多。一般做法是向量和 BM25 各召回 Top 25-50合并后交给重排器重排器筛出最相关的 Top 3-5。这段逻辑用代码表示大概是from elasticsearch import Elasticsearch import requests # 1. BM25 召回 es Elasticsearch(http://localhost:9200) bm25_hits es.search(indexdocs, query{match: {content: question}}, size25) # 2. 向量召回 vec_hits vector_search(embedded_question, top_k25) # 3. RRF 融合 candidates rrf_fusion([bm25_hits, vec_hits], k60) # 4. Rerank 精排 reranker CrossEncoder(BAAI/bge-reranker-base) scores reranker.predict([(question, doc.text) for doc in candidates]) final_top_k [doc for _, doc in sorted(zip(scores, candidates), reverseTrue)[:5]]这套“召回广、精排准”的两段式结构是我认为 RAG 检索配置里最值得优先投入的一环。它在所有知识域都有普适收益不像图谱那类方案挑数据形态。4.3 查询路由与元数据过滤让不同问题走不同通道比混合检索更高阶的一点是学会按问题类型做路由Routing。不是所有问题都适合走文档检索。在公司里“今年一季度的营收是多少”应该走数据库查询“张三汇报给谁”应该走组织架构知识库“报销流程怎么走”才适合走文档检索。查询路由要么用规则做——识别问题里有没有“多少”“哪个部门”“流程”这类信号词要么用一个轻量分类模型把问题分到向量检索、SQL 查询、图谱查询、Web 搜索这几条通道上。Dify 这类工具也支持多知识库路由但真正要理解的是路由逻辑本身不同类型的问题最优答案来源是不同的。元数据过滤同样是检索阶段最容易偷懒、也最致命的一环。知识库文档通常带部门、密级、时间、文档类型等标签。检索时如果不过滤一个普通员工的问题会把另外一个部门的保密合同捞出来不仅答错还涉嫌泄露。这种问题在评估阶段未必暴露上线之后一旦出现就是事故。我建议所有企业级 RAG 在构建向量库时就把元数据字段建全检索时强制带过滤条件宁可少召回也别越权召回。5. 分水岭四从“文本相似”到“结构知识”——知识图谱、Ontology RAG 与结构化知识的边界5.1 为什么文档问答总会卡在“关系型问题”上向量库的底层逻辑是“语义相似”。它能很好地回答“文档里哪段话讲了什么”但在“关系型问题”上天然乏力。这类问题在真实业务里非常常见“A 公司的法定代表人是谁这家公司和我们签过哪些合同”“这条故障报修单对应的设备在哪个机房维保负责人是谁”“这个地区上季度各产品的销量排名变化是怎样的”这些问题有个共同点答案分散在多个文档、多个实体节点、多层关系里而没有任何一段话能直接给出答案。向量检索只能找到“包含 A 公司”或“包含法定代表人”的孤立片段无法把关系链连贯地拼起来。你搜出来的素材足够多但拼不出那条正确的因果链。5.2 图谱 RAG 与 Ontology RAG学的是关系而不是用词这里就要说到知识图谱和 Ontology RAG 的价值了。很多人分不清“RAG 知识库”和“结构知识库图谱/数据库”的区别——简单做个区分就好了向量库存储文本片段检索靠语义相似。适合“模糊找资料”。知识图谱存储实体和关系检索靠遍历关系边。适合“精确找关系”。结构化数据库存储有模式的数据查询靠 SQL/API。适合“计算指标和聚合”。图谱 RAG 的做法是把文档里的实体人、公司、产品、城市和关系签约、生产、位于、负责抽出来构建成图然后在图上做多跳推理或者把图摘要喂给大模型生成回答。微软的 GraphRAG 是这条路的代表性框架先抽实体关系再通过社区检测生成全局概览回答“这堆文档总结起来讲了哪几个主题”这类全局性问题时优势明显。Ontology RAG 则更强调先有“本体层”——也就是一套业务 schema规定好这个领域有哪些概念、属性、关系再按 schema 去抽取实例、建图。比如设备运维领域先定义“设备-位置-维护记录-责任人”这四类节点和它们之间的三类关系再抽取具体数据。这样做的好处是查询时模型能理解图的结构可以直接生成 Cypher 或 SPARQL 查询语句或者按 schema 组装答案。相比纯文本检索它学的是关系图而不是字面相似的段落。5.3 该不该上图谱成本、时机和更轻量的替代方案但我得说句实话绝大部分 RAG 项目根本不需要上图谱。实体抽取的准确率直接决定图的质量而任何抽错的关系都会在推理时传导成错误答案。构建和更新一个领域图谱的成本可能是维护向量库的好几倍。如果知识库只是一堆规章制度、产品说明文档用户问题也都是“某条政策是怎么规定的”这类单点查询向量检索加混合重排已经绰绰有余。判断要不要用图谱我自己的权衡标准是用户问题里“多跳关系”和“指标计算”的比例高不高。比例高再考虑上图谱比例低别给自己找麻烦。还有一个折中方案值得优先尝试先不动图谱把结构化数据数据库表、组织架构、ERP 数据接成大模型可调用的工具函数用 Function Calling 让大模型在需要时自己去查库。这样做不用构建实体图就能解决“张三在哪部门、负责人是谁”这种问题。等高阶需求明确、且抽出来的关系能保证质量再逐步演进出真正的图谱 RAG。6. 分水岭五上下文组装与多模态输入喂给模型的不只是检索 TopK6.1 检索结果不全是答案怎么筛、怎么排许多人的 RAG 代码是拿到检索 TopK 就直接往 Prompt 里塞这是我最想纠正的一点。检索器给出的结果里真正能被模型用上的可能只有一两条其余是沾边但无关的内容。塞得越多模型越容易抓错重点。我在生产环境里的过滤原则是TopK 宁少勿多。3-5 个高质量 chunk 优于 20 个低质量垃圾。设置分数阈值。重排分数低于阈值的即使是 TopK 也不给模型宁可说“不知道”。去重。向量和 BM25 撞车回来的重复内容要先合并不然模型会看到三遍同样的话。权限再过滤。检索阶段过滤过的组装时再确认一遍避免拼接时把不同密级的上下文混在一起。6.2 引文溯源与 token 预算context 的工程化很多系统上线后被质疑“编答案”根源不在模型而在上下文组织没有做溯源。我会要求每个检索片段保留自己的元数据文档名、章节路径、页码。回答生成时强制格式带上来源标注比如“[来源 1设备维护手册 §3.2]”。这样用户能核验开发者也方便定位召回质量的问题。token 预算同样要算清楚。以 8K 上下文的模型为例指令模板占 800-1200 token历史对话占 1000-2000最终留给检索内容的可能只有 3000-4000 token。一个 1500 字的父块翻译成 token 大概 2000所以一次问答其实放不下太多内容。我的习惯是优先放完整父块中的关键部分再补细节子块并且明确告诉模型“如果检索内容不足以回答直接说明不要推测。”上下文组装可以模块化成一段代码核心是把检索结果组织成可读的带引用格式def build_context(docs): context_parts [] for i, doc in enumerate(docs, 1): context_parts.append( f[来源 {i}] {doc.metadata[title]} | {doc.metadata[section]} | 页码 {doc.metadata[page]}\n{doc.page_content} ) return \n\n.join(context_parts) def build_prompt(question, docs): context build_context(docs) return f请基于以下检索资料回答用户问题。如果资料不足请说明信息缺失不要编造。 资料 {context} 问题{question} 这一步看似简单实际上决定了模型的稳定性和可解释性。我见过不少系统检索质量已经做得很好了却在 Prompt 组织上翻车回答失去了引用用户没法验证最后整个系统的信任度崩塌。6.3 图文混合问答图片不是存进向量库就完了承接前面图片能不能进知识库的问题图片如果只被向量化存储问答阶段依然需要一条“取图—读图”的链路。最务实的架构是这样图片先进 OCR 或多模态生成描述文字部分进入向量库做粗召回回答阶段如果发现检索结果里带有图片 ID 或 URL就把原始图片和问题一起发给支持视觉的大模型让它看图补充或验证答案。这样做的好处是兼顾了检索效率和回答质量。文本描述负责“找到这张图”视觉模型负责“看懂这张图”。一旦你把图片的向量化嵌入当作完整答案省略了最后的视觉读取那图片知识库就只剩一个概念实际效果大概率让人失望。7. 分水岭六评估与线上反馈没有闭环的优化都是自嗨7.1 离线评估几十条测试集三个指标先把分数跑出来绝大多数 RAG 项目死在同一个环节从没建立过评估体系。改个切分参数靠肉眼感觉换个 Embedding 模型凭口碑上线效果全看运气。我建议项目一开始就花力气做一个小而精的离线测试集50-100 条真实问题和对应的标准答案、对应文档。不用追求大但一定要覆盖高频业务场景和历史上的困难问题。有了测试集就能用三类指标衡量系统忠实度Faithfulness模型回答是否严格基于检索内容有没有编造。上下文相关性Context Relevance检索到的文档片段和问题到底相不相关是重排器的直接绩效。答案相关性Answer Relevance最终回答在多大程度上满足了用户的问题。RAGAS 这类开源框架把这几个指标自动化了但也不要迷信分数。指标是优化的方向盘最终判断还是结合人工过一遍答案质量。至少有了测试集之后改动任何一个环节都能跑分对比而不是靠“感觉好像变好了”。7.2 线上 badcase 分析日志里的真相离线测试集覆盖的是已知问题线上永远会出现你没预料到的坑。所以生产环境必须埋日志记录每条用户问题的原始 query、检索了什么文档、重排分数、最终答案、用户有没有点赞或点踩。每隔一两周拉一批低评价、低赞、高踩的问答做人工复盘把 badcase 归入几类badcase 类型表象问题环节检索漏了答案里说“没有找到相关信息”切分/召回/重排检索到了但没用上文档里有答案模型没引用上下文组装/指令答案流畅但错误引用来源不存在或张冠李戴忠实度/引文多轮对话串台后一轮答案受前一轮错误影响对话摘要/上下文清理这个表格是我做项目时实际用到的排查模板它的好处是能把“系统不行”这个大问题拆分成可归因的小问题然后知道该去改哪个环节。7.3 一个可持续的迭代节奏每次只动一个变量有了评估闭环优化就变成了一个受控的实验过程。我的迭代节奏是每周挑一个环节动手其他环节锁定不动。这一周调解析规则下一周换重排模型再下一周优化 Prompt 模板。每轮改动跑同一套测试集对比分数和 badcase 数。大多数项目的收益排序通常是从解析和切分开始改收益最大然后是混合检索和重排再往后才是上下文组装。图谱和结构化知识属于按需引入的高投入选项评估体系则是一开始就要铺的底网。没有评估后面所有改动都是盲人摸象有了评估哪怕一次只动一个变量两三个月后系统的可用度会有非常明显的提升。最后说点个人的体会。我做 RAG 项目的头两个月一直在折腾各种炫酷的上游框架效果很一般。后来老老实实搭了评估集、把 badcase 一张张翻出来才发现最大的问题居然是早期 PDF 解析漏了表格、切分把条款拦腰斩断。把这两处修好之后光是回答准确率就提了一大截。那之后我给自己立了条规矩先解决“找不到”和“找不准”再谈“答得好”最后才考虑“关系多跳”这类进阶能力。这六处分水岭不需要一次全部做完。如果你正卡在某个真实项目里我的建议是从“最后那个最简单的评估集”入手先看清自己的系统弱在哪再顺着最疼的那处往下钻。RAG 现在已经不稀罕了稀罕的是把 RAG 做成一个能用、敢上线、出了错能定位的系统。希望这六处踩坑记录能帮你少走点弯路。
每天打开技术社区几乎都能刷到一篇新的 RAG 教程。标题长得都差不多——“基于 LangChain 构建本地知识库”“用 Dify 五分钟上线企业问答”“RAG 实战从零搭建文档问答系统”。跟着跑一遍半天时间就能在本地把一条流水线打通文档加载、切分、Embedding、向量库、检索、塞进 LLM 生成答案。Dify 这类低代码工具甚至把这一步压缩成了拖拽连线于是“RAG 烂大街”这句话越来越常听到。我的看法恰恰相反。烂大街的从来都只是那条标准流水线本身真正拉开项目成败的是流水线前后那六处大多数人一笔带过的细节。结合这几年在真实项目里踩过的坑我把它们浓缩成六处分水岭文档解析、切分策略、检索通道、结构知识、上下文组装、评估闭环。每处分好了效果可能是数量级的差别分不好RAG 就永远停留在 Demo 阶段。这篇文章不打算再写一遍完整搭建步骤只讲这六处在哪、为什么重要、以及最后我是怎么处理的。1. 为什么人人都能跑通 RAG 流水线却很少能直接上线1.1 一小时跑通 Demo 的仪式感RAG 的标准流水线拆开来就那么几步Loader 读文档Splitter 切文本Embedding 模型转向量向量库存起来Retriever 去查最后把查到的片段和问题一起丢给大模型出答案。这个链路已经被写进无数教程里原理也不复杂——给大模型配一个外挂记忆体知识不用塞进模型参数随时查随时用。问题在于教程里演示的文档通常是一份干净的 Markdown问题也是精心设计的“美联储加息对 A 股有什么影响”这类通用问题。跟着敲一遍你确实能在 Mac 上把整套东西跑起来还能看到像模像样的回答。于是很多人产生一种错觉RAG 已经简单到没有技术含量了。1.2 从 Demo 到产品的那几道暗沟一旦把同样的代码扔到真实项目面前落差立刻出现。我在企业里做过好些知识库项目几乎每次翻车都翻在同一个地方——不是流水线没跑起来而是跑起来之后答非所问、检索命中率低、答案看着流畅但信息是错的。举几个常见现场文档不是干净的文本而是扫描版 PDF、双栏论文、带复杂表格的 Excel用户问的是“PA-1002 项目的验收材料在哪”“这个型号的备件适配哪个批次”编号和专有名词一检索就丢答案是编的模型把检索到的片段当参考自己脑补出了不存在的结论知识库里几百份文档按部门做了权限隔离但检索时把不该看到的也捞出来了没有评估手段改完切分参数也不知道是变好了还是变坏了。这些问题的共性是流水线本身只负责打通不负责做对。Loader 决定了模型能看到什么Splitter 决定了能不能被检索到Retriever 决定了找得准不准上下文组装决定了答案质量评估决定了你怎么持续改进。每一步都像水管上的阀门任何一个没拧对最终流出来的水都是歪的。Dify 这类平台确实把流程编排的门槛降得很低但低代码不代表低成本——你依然要理解每一步背后的数据形态和处理逻辑。这也是为什么我坚持认为RAG 的分水岭从来不在“能不能搭出流水线”而在“能不能针对真实数据把每个环节调对”。2. 分水岭一文档解析与多模态内容决定 RAG 能学到的上限2.1 真实 PDF、扫描件、双栏排版、表格——文本提取不是 CtrlC很多教程会把文档加载讲成一句“loader.load_text”好像所有文件都自带干净的文字层。真实业务里最常见的痛苦恰恰在这一步。文本型 PDF 和扫描型 PDF 是两种完全不同的东西。文本型 PDF 里有文字层PyMuPDF、pdfplumber 可以近乎无损提取扫描型 PDF 本质是整页图片必须先做 OCR否则提取出来就是一片空白。中文场景我踩过一个坑用 Tesseract 跑扫描件识别率惨不忍睹后来换 PaddleOCR 才勉强能看。不是说 Tesseract 不好而是它对中文排版的支持确实不如 PaddleOCR 顺手。比 OCR 更隐蔽的是双栏论文和复杂表格。双栏 PDF 按页码直接转文本提取结果是左栏第一行、右栏第一行、左栏第二行、右栏第二行交错拼在一起语义链全断。我处理过一份投行研报转完文本之后“公司主营业务”和“财务指标”混成了一坨检索出来的 chunk 前言不搭后语。表格更麻烦按行读取会丢掉行列结构一个三行四列的对比表转成文本后变成三行扁平的句子列对应关系全没了。2.2 图片到底能不能进知识库两类图片、两套处理逻辑“RAG 知识库能存储图片嘛”这个问题经常有人问。答案能但要看你说的是哪种图片处理逻辑完全不同。第一类是图片里带着文字信息截图、扫描件、PPT 翻拍、带文字的图表。这类图的处理方式是把文字“取出来”——OCR 识别或者让多模态模型生成图片描述Caption再把这段文字作为文本内容进向量库。检索时用户问“这张图里的结论是什么”命中的是图片生成的文字描述而不是图片本身。第二类是图片本身就是信息主体UI 设计稿、产品外观图、一张狗的照片。用户问“这张设计稿里按钮的间距是多少”你没法靠 OCR 拿到布局数据。这类内容需要多模态 Embedding 模型来向量化图片或者更朴实的做法——把图片 URL 存进数据库在问答阶段把原始图片直接作为多模态输入丢给支持视觉的大模型。这里有个常见的误解往 Milvus 里塞了图片向量就叫“知识库支持图片了”。实际上向量库只存了向量检索之后你依然要把图片取出来交给能“看图说话”的模型去生成回答。所以更准确的说法是图片知识库 图片的原图/URL 向量索引 多模态 LLM 读取链路三者缺一个都不完整。2.3 一套能扛住真实资料的解析组合我的经验是不要一上来就上重型方案先做文档摸底再选解析路径。具体顺序大概是先用 PyMuPDF 尝试提取文字层能提出来的不走 OCR提出来的文本检查排版双栏的先用版面分析模块处理或者按坐标把左右栏拆开再拼接表格单独抽出来不要混在正文里切分。简单的规则型表格可以用 pdfplumber 抽复杂表直接整块截成图交给多模态模型在问答时读取扫描 PDF 的固定路径是 PaddleOCR识别完要保留坐标信息便于后续版面处理最后做清洗去掉页眉页脚、处理断词连字符、把全角半角统一。这里有个很重要但常被忽略的点解析质量的损失是不可逆的。切分、检索、生成环节都能反复调优唯独如果原始文档没解析好后面再怎么精修都是沙上建塔。我在一个合同审查项目里就因为 PDF 里的表格行错位导致“甲方地址”被切到了“乙方地址”的 chunk 里模型回答直接张冠李戴。花三天优化检索最后发现病根在解析教训相当深刻。3. 分水岭二切分不是“按字数切开”而是“按语义边界切”3.1 固定窗口切分踩过的坑语义断了检索就瞎了切分是 RAG 里看起来最没技术含量、实际上影响最大的环节。默认做法是固定窗口chunk_size 设成 500chunk_overlap 设 50单词表按字符数硬切。这种方案在连续叙述类文档上勉强能用一旦遇到结构化内容立刻原形毕露。两个典型毛病。第一是切断语义一句话刚好卡在句中间或者一个完整的概念被拆到两个 chunk 里。我去过的一个项目里知识库存的是合规制度某条制度的核心定义在 chunk 35 结尾适用范围在 chunk 36 开头用户问“这项制度管不管采购部门”两个 chunk 单独看都答不完整模型只能用词面相关性硬猜。第二个毛病是检索粒度与答案粒度错位。有的文档段落很长一个“条款”可能覆盖上千字但固定窗口把它切成四五段。检索时命中的往往只是其中包含关键词的一小段模型拿到的上下文是残片没有前因后果。这就像你要查“这个产品的保修政策”系统给你的是保修政策里“不包含哪些情况”那半句话而不是完整的政策条款。3.2 三种能打的切分方案结构感知、父子切分、语义断点我后来在实际项目里基本在三类方案里选或者组合用。结构感知切分是最容易上手的升级。Markdown 按标题层级切HTML 按标签切Word 文档先读标题样式再切。核心思路是让切分器尊重文档原有的语义边界。规则很简单一个新的一级/二级标题出现强制开启新 chunk列表、表格整块保留。这样切出来的每个 chunk 都自带上下文模型读起来像是在读原文片段而不是拼接碎片。父子切分解决的是检索粒度和答案粒度打架的问题。做法是维护两套块小的子块用于检索粒度控制在 200-400 字尽可能精准命中命中之后回溯到子块所属的父块——通常 1500-3000 字把完整的上下文喂给模型。这套逻辑很像维基百科的“摘要词条 正文详情”先用摘要定位再展开看细节。LangChain 里叫 ParentDocumentRetriever实现成本不高但对答案完整性的提升非常明显。语义断点切分是最精细也最费钱的一类本质是让模型判断哪里该断句、哪里属于同一主题。低成本的做法是用句子向量算相邻句子的相似度相似度跌破阈值就当断点高级做法是直接让大模型按语义分段。这套方案适合知识管理类的专业文档效果最好但对算力和调用成本都有要求90% 的场景其实用不上。3.3 切分参数和检索策略必须联动设计切分不存在一套万能参数。我给团队定的参考基线是普通叙述文本 chunk 500-800 字、overlap 50-100制度条款类文档优先按条款结构切字数是结果而不是目标表格和图片单独成条不塞进正文 chunk。chunk_size 的选择背后有个矛盾关系块越大语义越完整但检索噪声越大块越小检索越精准但上下文越残缺。父子切分能在一定程度上化解这个矛盾但也不是无脑用父块过大会把不相关内容一起拖进 Prompt稀释有效信息。另一个容易忽略的点是切分策略一旦改变检索结果和后续调整全部推倒重来。所以我一直强调改切分必须带着评估去做——同一套测试问题改前改后各跑一遍用数据说话。4. 分水岭三检索通道向量检索只是默认值不是唯一解4.1 向量检索何时翻车精确词、编号、稀有实体很多人的 RAG 只有一条检索通道把用户问题转成向量到向量库做 TopK 余弦相似度搜索。这在语义宽松的自然语言问答上表现尚可但有几个场景会确定性翻车。第一个场景是精确编号查询。用户问“PA-1002 项目”向量检索对“PA-1002”这种符号组合不敏感因为 Embedding 模型把“PA”“1002”打散到了高维空间里词的精确形式反而被稀释了。你搜“项目编号是多少”向量库捞上来的可能是讲“项目管理流程”的泛化内容而不是编号对应的那一条具体记录。第二个场景是专有名词和缩略语。企业内部术语、产品型号、人名在预训练 Embedding 模型眼里几乎没有语义锚点。模型没见过“XX-A430 型传感器”和“A430”之间的关联词面匹配反而是强信号而向量检索恰恰不擅长词面匹配。第三个场景是短查询。用户上来敲三个字“验收书”向量模型仅凭这么短的输入很难在低维度语义空间里找准方向。BM25 这类稀疏检索方法对短查询和精确词的匹配能力反而更强。4.2 混合检索重排先广撒网再精打细算我现在的标准做法是混合检索最朴素的版本就是 BM25 关键词检索和向量检索并行跑各自召回 Top N再按 RRFReciprocal Rank Fusion或加权分数融合成一个候选集。这一步能同时保底词面匹配和语义匹配工程上几乎不增加多少复杂度收益却很直接。但混合检索只是第一步。融合之后的候选集通常有几十条里面鱼龙混杂直接截断到 Top 5 塞给大模型效果并不稳。于是第二个关键动作是加一层重排器Reranker。重排器是 Cross-Encoder 结构把问题和候选文档逐对拼接后算相关性分数比 Bi-Encoder 的向量相似度精细得多。一般做法是向量和 BM25 各召回 Top 25-50合并后交给重排器重排器筛出最相关的 Top 3-5。这段逻辑用代码表示大概是from elasticsearch import Elasticsearch import requests # 1. BM25 召回 es Elasticsearch(http://localhost:9200) bm25_hits es.search(indexdocs, query{match: {content: question}}, size25) # 2. 向量召回 vec_hits vector_search(embedded_question, top_k25) # 3. RRF 融合 candidates rrf_fusion([bm25_hits, vec_hits], k60) # 4. Rerank 精排 reranker CrossEncoder(BAAI/bge-reranker-base) scores reranker.predict([(question, doc.text) for doc in candidates]) final_top_k [doc for _, doc in sorted(zip(scores, candidates), reverseTrue)[:5]]这套“召回广、精排准”的两段式结构是我认为 RAG 检索配置里最值得优先投入的一环。它在所有知识域都有普适收益不像图谱那类方案挑数据形态。4.3 查询路由与元数据过滤让不同问题走不同通道比混合检索更高阶的一点是学会按问题类型做路由Routing。不是所有问题都适合走文档检索。在公司里“今年一季度的营收是多少”应该走数据库查询“张三汇报给谁”应该走组织架构知识库“报销流程怎么走”才适合走文档检索。查询路由要么用规则做——识别问题里有没有“多少”“哪个部门”“流程”这类信号词要么用一个轻量分类模型把问题分到向量检索、SQL 查询、图谱查询、Web 搜索这几条通道上。Dify 这类工具也支持多知识库路由但真正要理解的是路由逻辑本身不同类型的问题最优答案来源是不同的。元数据过滤同样是检索阶段最容易偷懒、也最致命的一环。知识库文档通常带部门、密级、时间、文档类型等标签。检索时如果不过滤一个普通员工的问题会把另外一个部门的保密合同捞出来不仅答错还涉嫌泄露。这种问题在评估阶段未必暴露上线之后一旦出现就是事故。我建议所有企业级 RAG 在构建向量库时就把元数据字段建全检索时强制带过滤条件宁可少召回也别越权召回。5. 分水岭四从“文本相似”到“结构知识”——知识图谱、Ontology RAG 与结构化知识的边界5.1 为什么文档问答总会卡在“关系型问题”上向量库的底层逻辑是“语义相似”。它能很好地回答“文档里哪段话讲了什么”但在“关系型问题”上天然乏力。这类问题在真实业务里非常常见“A 公司的法定代表人是谁这家公司和我们签过哪些合同”“这条故障报修单对应的设备在哪个机房维保负责人是谁”“这个地区上季度各产品的销量排名变化是怎样的”这些问题有个共同点答案分散在多个文档、多个实体节点、多层关系里而没有任何一段话能直接给出答案。向量检索只能找到“包含 A 公司”或“包含法定代表人”的孤立片段无法把关系链连贯地拼起来。你搜出来的素材足够多但拼不出那条正确的因果链。5.2 图谱 RAG 与 Ontology RAG学的是关系而不是用词这里就要说到知识图谱和 Ontology RAG 的价值了。很多人分不清“RAG 知识库”和“结构知识库图谱/数据库”的区别——简单做个区分就好了向量库存储文本片段检索靠语义相似。适合“模糊找资料”。知识图谱存储实体和关系检索靠遍历关系边。适合“精确找关系”。结构化数据库存储有模式的数据查询靠 SQL/API。适合“计算指标和聚合”。图谱 RAG 的做法是把文档里的实体人、公司、产品、城市和关系签约、生产、位于、负责抽出来构建成图然后在图上做多跳推理或者把图摘要喂给大模型生成回答。微软的 GraphRAG 是这条路的代表性框架先抽实体关系再通过社区检测生成全局概览回答“这堆文档总结起来讲了哪几个主题”这类全局性问题时优势明显。Ontology RAG 则更强调先有“本体层”——也就是一套业务 schema规定好这个领域有哪些概念、属性、关系再按 schema 去抽取实例、建图。比如设备运维领域先定义“设备-位置-维护记录-责任人”这四类节点和它们之间的三类关系再抽取具体数据。这样做的好处是查询时模型能理解图的结构可以直接生成 Cypher 或 SPARQL 查询语句或者按 schema 组装答案。相比纯文本检索它学的是关系图而不是字面相似的段落。5.3 该不该上图谱成本、时机和更轻量的替代方案但我得说句实话绝大部分 RAG 项目根本不需要上图谱。实体抽取的准确率直接决定图的质量而任何抽错的关系都会在推理时传导成错误答案。构建和更新一个领域图谱的成本可能是维护向量库的好几倍。如果知识库只是一堆规章制度、产品说明文档用户问题也都是“某条政策是怎么规定的”这类单点查询向量检索加混合重排已经绰绰有余。判断要不要用图谱我自己的权衡标准是用户问题里“多跳关系”和“指标计算”的比例高不高。比例高再考虑上图谱比例低别给自己找麻烦。还有一个折中方案值得优先尝试先不动图谱把结构化数据数据库表、组织架构、ERP 数据接成大模型可调用的工具函数用 Function Calling 让大模型在需要时自己去查库。这样做不用构建实体图就能解决“张三在哪部门、负责人是谁”这种问题。等高阶需求明确、且抽出来的关系能保证质量再逐步演进出真正的图谱 RAG。6. 分水岭五上下文组装与多模态输入喂给模型的不只是检索 TopK6.1 检索结果不全是答案怎么筛、怎么排许多人的 RAG 代码是拿到检索 TopK 就直接往 Prompt 里塞这是我最想纠正的一点。检索器给出的结果里真正能被模型用上的可能只有一两条其余是沾边但无关的内容。塞得越多模型越容易抓错重点。我在生产环境里的过滤原则是TopK 宁少勿多。3-5 个高质量 chunk 优于 20 个低质量垃圾。设置分数阈值。重排分数低于阈值的即使是 TopK 也不给模型宁可说“不知道”。去重。向量和 BM25 撞车回来的重复内容要先合并不然模型会看到三遍同样的话。权限再过滤。检索阶段过滤过的组装时再确认一遍避免拼接时把不同密级的上下文混在一起。6.2 引文溯源与 token 预算context 的工程化很多系统上线后被质疑“编答案”根源不在模型而在上下文组织没有做溯源。我会要求每个检索片段保留自己的元数据文档名、章节路径、页码。回答生成时强制格式带上来源标注比如“[来源 1设备维护手册 §3.2]”。这样用户能核验开发者也方便定位召回质量的问题。token 预算同样要算清楚。以 8K 上下文的模型为例指令模板占 800-1200 token历史对话占 1000-2000最终留给检索内容的可能只有 3000-4000 token。一个 1500 字的父块翻译成 token 大概 2000所以一次问答其实放不下太多内容。我的习惯是优先放完整父块中的关键部分再补细节子块并且明确告诉模型“如果检索内容不足以回答直接说明不要推测。”上下文组装可以模块化成一段代码核心是把检索结果组织成可读的带引用格式def build_context(docs): context_parts [] for i, doc in enumerate(docs, 1): context_parts.append( f[来源 {i}] {doc.metadata[title]} | {doc.metadata[section]} | 页码 {doc.metadata[page]}\n{doc.page_content} ) return \n\n.join(context_parts) def build_prompt(question, docs): context build_context(docs) return f请基于以下检索资料回答用户问题。如果资料不足请说明信息缺失不要编造。 资料 {context} 问题{question} 这一步看似简单实际上决定了模型的稳定性和可解释性。我见过不少系统检索质量已经做得很好了却在 Prompt 组织上翻车回答失去了引用用户没法验证最后整个系统的信任度崩塌。6.3 图文混合问答图片不是存进向量库就完了承接前面图片能不能进知识库的问题图片如果只被向量化存储问答阶段依然需要一条“取图—读图”的链路。最务实的架构是这样图片先进 OCR 或多模态生成描述文字部分进入向量库做粗召回回答阶段如果发现检索结果里带有图片 ID 或 URL就把原始图片和问题一起发给支持视觉的大模型让它看图补充或验证答案。这样做的好处是兼顾了检索效率和回答质量。文本描述负责“找到这张图”视觉模型负责“看懂这张图”。一旦你把图片的向量化嵌入当作完整答案省略了最后的视觉读取那图片知识库就只剩一个概念实际效果大概率让人失望。7. 分水岭六评估与线上反馈没有闭环的优化都是自嗨7.1 离线评估几十条测试集三个指标先把分数跑出来绝大多数 RAG 项目死在同一个环节从没建立过评估体系。改个切分参数靠肉眼感觉换个 Embedding 模型凭口碑上线效果全看运气。我建议项目一开始就花力气做一个小而精的离线测试集50-100 条真实问题和对应的标准答案、对应文档。不用追求大但一定要覆盖高频业务场景和历史上的困难问题。有了测试集就能用三类指标衡量系统忠实度Faithfulness模型回答是否严格基于检索内容有没有编造。上下文相关性Context Relevance检索到的文档片段和问题到底相不相关是重排器的直接绩效。答案相关性Answer Relevance最终回答在多大程度上满足了用户的问题。RAGAS 这类开源框架把这几个指标自动化了但也不要迷信分数。指标是优化的方向盘最终判断还是结合人工过一遍答案质量。至少有了测试集之后改动任何一个环节都能跑分对比而不是靠“感觉好像变好了”。7.2 线上 badcase 分析日志里的真相离线测试集覆盖的是已知问题线上永远会出现你没预料到的坑。所以生产环境必须埋日志记录每条用户问题的原始 query、检索了什么文档、重排分数、最终答案、用户有没有点赞或点踩。每隔一两周拉一批低评价、低赞、高踩的问答做人工复盘把 badcase 归入几类badcase 类型表象问题环节检索漏了答案里说“没有找到相关信息”切分/召回/重排检索到了但没用上文档里有答案模型没引用上下文组装/指令答案流畅但错误引用来源不存在或张冠李戴忠实度/引文多轮对话串台后一轮答案受前一轮错误影响对话摘要/上下文清理这个表格是我做项目时实际用到的排查模板它的好处是能把“系统不行”这个大问题拆分成可归因的小问题然后知道该去改哪个环节。7.3 一个可持续的迭代节奏每次只动一个变量有了评估闭环优化就变成了一个受控的实验过程。我的迭代节奏是每周挑一个环节动手其他环节锁定不动。这一周调解析规则下一周换重排模型再下一周优化 Prompt 模板。每轮改动跑同一套测试集对比分数和 badcase 数。大多数项目的收益排序通常是从解析和切分开始改收益最大然后是混合检索和重排再往后才是上下文组装。图谱和结构化知识属于按需引入的高投入选项评估体系则是一开始就要铺的底网。没有评估后面所有改动都是盲人摸象有了评估哪怕一次只动一个变量两三个月后系统的可用度会有非常明显的提升。最后说点个人的体会。我做 RAG 项目的头两个月一直在折腾各种炫酷的上游框架效果很一般。后来老老实实搭了评估集、把 badcase 一张张翻出来才发现最大的问题居然是早期 PDF 解析漏了表格、切分把条款拦腰斩断。把这两处修好之后光是回答准确率就提了一大截。那之后我给自己立了条规矩先解决“找不到”和“找不准”再谈“答得好”最后才考虑“关系多跳”这类进阶能力。这六处分水岭不需要一次全部做完。如果你正卡在某个真实项目里我的建议是从“最后那个最简单的评估集”入手先看清自己的系统弱在哪再顺着最疼的那处往下钻。RAG 现在已经不稀罕了稀罕的是把 RAG 做成一个能用、敢上线、出了错能定位的系统。希望这六处踩坑记录能帮你少走点弯路。
