RAG 这个缩写，这两年快被说烂了。我自己判断一个项目是不是认真在做 RAG，从来不看他有没有跑通"加载文档、文本切分、向量化、存向量库、检索、拼提示词、让大模型生成"这套标准流水线——因为这几步早就被 LangChain、LlamaIndex、LangChain4j 这些框架封装成模板了。ollama 拉起一个 embedding 模型，配个 Chroma，再加一段简单的提示词，一下午能跑出三个看起来一模一样的 demo。真正拉开差距的，是流水线之外的六处细节。这篇文章就是把六处分水岭掰开揉碎讲清楚：它们分别解决什么问题、实战里怎么做、哪里最容易踩坑。适合已经跑通过一次 RAG demo、想把它做成真正能用的产品的人；如果还没跑通过 demo，建议先把标准流程走一遍再回来看。
1. 第一道分水岭：你的文档，到底还原了多少信息？
RAG 的底座是数据。但很多教程里的数据加载，简单到让人误以为文档处理是从"第 2 步"才开始的。实际上，这一层恰恰是绝大多数 RAG 项目夭折的地方——不是 embedding 模型选得不好，而是输入层就把关键信息丢光了。
1.1 文档解析从来不是 read() 一下的事
标准流程告诉你：用 PyPDF2 抽文字，或者用 pdfplumber 逐页提取，然后直接往切分器扔。这套做法在整洁的纯文本 PDF 上没问题，一旦进入真实业务就露馅了。我见过一个项目，把产品手册里的表格用通用 PDF 库提取后，行列顺序完全乱掉，数字和单位散落在不同的文本行里。检索的时候用户问"最大输出功率是多少"，召回回来的 chunk 里只有孤零零的数字"3000"，没有"最大输出功率"这个表头，模型只能瞎猜单位。这就是典型的信息还原率问题——问题不在向量化，而在解析层已经把关键关联性破坏了。
真实场景里至少会遇到这么几类"硬文档"：
- 扫描件和图片型 PDF，必须先 OCR，否则抽出来全是空字符串；
- 带复杂版式的 PDF，有页眉页脚、多栏、图文混排，直接按阅读顺序提文本会把栏目标题和正文错位拼在一起；
- Excel 多子表，每个 sheet 的语义边界容易丢失，整张表塞进一个 chunk 又太大；
- 论文里的公式、图表、算法伪代码，普通文本提取几乎完全失真。
所以认真做 RAG 的第一步不是急着搭流程，而是先做一次"文档体检"：你的源文件到底长什么样？哪些信息是用户真实 query 会触及的？如果答案是表格和图片，那你需要的就不是简单的 PDF 抽取，而是一套版面分析加结构化提取方案。
1.2 图片到底能不能进知识库？——能，但要"翻译"成模型能用的形态
热词里有个问题：rag 知识库能存储图片吗？直接回答：向量库本身不区分你存的是文本向量还是图片向量，你完全可以把图片喂给多模态模型，得到图片向量后一起存进去。但生产实践里我很少直接这么干。原因有二：一是纯图片向量的召回结果没法在答案里向用户展示依据，二是用户问的问题大多以文字表达，图文之间的语义鸿沟比想象中大得多。
更靠谱的做法是"双通道"：对文档里的架构图、截图、图表，先用视觉语言模型生成一段结构化描述（包括这张图是什么、关键元素、结论），把描述作为该图片块的正文放进向量库；同时用 OCR 或版面分析把图里的文字元素抽出来做成辅助文本。检索时，命中图片描述块后，可以把原图路径一起带给生成模型或前端，做到"看图回答"。这样既保留了图片信息，又让文本检索那条链路正常工作。
一个小提醒：图片描述要站在"回答用户问题"的角度写，不要站在"描述画面"的角度。我常用的 prompt 是：请描述这张图片中的关键信息，包括对象、关系、数值、结论，按要点输出；忽略与业务无关的装饰元素。这一句话能明显提升图片块的检索命中率。
1.3 表格和版面：把"视觉结构"还原成"语义结构"
表格类文档是 RAG 的高发事故区。二维表格的语义依赖表头和行索引，一旦被压成一维文本流，对应关系就全乱了。本地方案里我推荐优先尝试 PaddleOCR，它的表格结构识别能力在处理中文扫描件和复杂表头时相当能打，可以直接把表格还原成 HTML 或 Markdown 表格。如果文档本身是数字版式，那就更简单：用 pdfplumber 按坐标区域抽取表格单元格，再按行列重组为 Markdown 表格。检索命中后直接以 Markdown 形式进入上下文，大模型对表格结构的理解会好很多。
版面分析同样重要。我习惯把整页划分成标题、正文、表格、图表区域，把同一逻辑块的内容聚合在一起，再按阅读顺序拼接。做完这一步，你会发现切分质量天然地变好——因为你已经知道哪些文本"本来就应该在一起"了。这一步不是必须上重型模型，不少开源库已经内置了基于深度学习的版面检测能力，本地 CPU 也可以接受。
2. 第二道分水岭：切分是为了检索服务，不是为了满足 token 限制
切分（chunking）是 RAG 里最容易被低估的一步。很多人觉得无非是指定一个 chunk_size，加一点 overlap，事实上切分粒度直接决定了检索的上限——检索永远只能在切好的块里挑，切得不合理，后面再强的重排也救不回来。
2.1 固定长度切片的三个典型问题
固定长度切分（比如每 512 个 token 一刀）会带来三个很常见的问题。
第一是语境断裂。一段讲故障恢复步骤的文字可能在"第 4 步"处被拦腰截断，前一块只有步骤 1-3，后一块只有步骤 4-5。看似有 overlap，但语义链条还是断的。模型收到的上下文缺了中间的过渡，回答自然就缺逻辑。
第二是边界错位。一个完整的表格可能被切开，一半落到前一个 chunk，一半落到后一个 chunk。检索命中的时候只拿到半张表，生成模型拿到一列数字却找不到对应的表头，结果就是一本正经地胡说。
第三是召回碎片化。一个紧密相关的长段落被拆到多个块里，query 只召回其中一块。模型拿到了"局部"却不知道"全局"，回答经常只覆盖问题的一个侧面。
我刚做 RAG 的时候也踩过这个坑。当时图省事，所有文档统一塞进固定窗口切分器，上线后运营反馈"知识库经常答非所问"。后来逐个看 bad case，发现一大半问题出在切分把完整的语义单元切散了。从那以后，我把切分策略放到了和 embedding 模型同一个优先级。
2.2 结构化切分 + 父子分块是我的默认方案
既然很多文档天然有结构（标题、章节、段落、表格、列表），那就顺着结构切，不要逆着结构切。本地方案完全可行：先用版面分析或文档解析器把页面还原成带层级信息的对象（比如 Chapter -> Section -> Block），然后从最小的语义块（一个段落或一个表格）开始，向上聚合到合适的 token 范围。这样每个 chunk 内部在语义上是连续的，边界也尽量落在逻辑断点上。
我目前默认的组合是父子分块（Parent-Child Chunking）：
- 子块（child）：200-400 token 左右，用于精确的向量检索，保证召回粒度小、命中率高；
- 父块（parent）：对应一个较大的逻辑单元（比如一个二级标题下的完整小节），用于最终拼进上下文，保证大模型看到足够完整的背景。
检索时先用子块找最相关的候选，再通过子块里存的 parent_id 元数据批量拉取父块，把完整内容送进生成层。这样既解决了小块语义聚焦的问题，又解决了大块上下文缺失的问题。如果你暂时只用一个固定窗口，我的经验值是 chunk_size 400（token，约合中文 500-600 字）配 10% 的 overlap 作为稳妥起点，但不要迷信这个参数，一定要拿真实 query 做验证再用。
2.3 语义切分和"文本拆解工具"的本地实践
有人问：有没有本地的 RAG 文本拆解工具？其实是有的，而且组合起来完全能离线跑。
轻量做法是用句式边界模型把文章切成句子，再用 embedding 算相邻句子的相似度。相似度跌到阈值以下，就在那里断块。这个做法比固定窗口平滑得多，成本也低。更细的做法可以顺着"转折点检测"的思路，让本地大模型判断文本的语义段落边界在哪里，直接输出切分位置。代价是慢，适合离线建立索引，不适合在线实时处理。
还有一个我比较看好的思路：主题连续检测。文本在讲同一个主题时，相邻句子的相似度会保持在高位；当话题切换时，相似度会出现一个明显的"悬崖"。你只需要滑动窗口算窗口内的平均相似度，把悬崖位置当作候选切分点，再用标题层级做校验。实测下来，这种"规则 + 语义"混合的方式，比单靠固定长度稳健得多，也比纯语义切分快得多。
3. 第三道分水岭：检索，从一次向量查询到多路召回加重排
如果说前两处影响的是"检索的上限"，那么这一处决定的就是"检索的下限"——保证真正相关的内容被召回到候选集里，然后让重排模型把最好的内容挑出来。
3.1 向量检索的瓶颈，你在生产环境迟早会遇到
很多人以为向量检索是万能的，跑通 demo 之后才发现不是。最常见的瓶颈有三类。
一是专有名词和缩写。产品型号、内部代号、英文缩写，embedding 模型没见过几次，向量距离往往是错的，精确字符串搜索却一搜一个准。二是精确数字和 ID。用户问"订单号 20240315 的状态"，向量模型可能把数字编码得模模糊糊，关键词匹配则完全无歧义。三是"语义相近但不相关"的误召回。问"怎么配置缓存"，召回的都是"缓存穿透"的讨论，两个文本向量距离很近，但业务语境完全不同。
这就是我反对把检索简化成"一次向量查询"的原因。真实生产里的检索链路，应该是一套"多路召回 + 统一融合 + 重排"的管线。
3.2 混合检索：向量管语义，BM25 管字面
我默认会做两路召回：一路是向量相似度检索，负责语义泛化；一路是稀疏检索（关键词匹配），负责精确命中。稀疏检索的本地方案并不复杂，开箱可用的是一个基于 BM25 的类库（例如 rank_bm25），对中文要先做分词，jieba 分词器基本够用。
两路召回的结果怎么合并？我推荐 RRF（Reciprocal Rank Fusion）而不是简单分数加权。RRF 的做法是给每条结果按排名打分：分 = 1 / (k + rank)，其中 rank 是这条结果在某一路召回里的位次，k 是一个平滑常数，通常取 60。把两路的排名分加起来，再按总分排序。RRF 的好处是它只依赖排名，不依赖两路分数是否同一量纲——向量余弦相似度是 0-1，BM25 分数可能到几十，直接加权的话 BM25 会把向量分数碾压，RRF 则天然规避了这个问题。召回数量上，每路取 top50 就够，再多会让后面的重排模型吃不消。
3.3 重排模型是性价比最高的一环
多路召回之后，直接把这 50 个候选全部拼进提示词，效果并不会变好——上下文被大量无关候选稀释了。必须有一个"精排"步骤，把模型拿到的上下文限制在 top3-5 个高质量块。
怎么做？用交叉编码器类型的重排模型，把 query 和候选块拼接成一对文本输入，让模型输出相关性分数。这种模型可以精细捕捉 query 与文本之间的交互信号，效果远好于独立编码的向量相似度。本地方案有现成的开源模型（BGE 系列的 rerank 模型），跑一次推理也就是毫秒到几十毫秒的量级。
我自己的经验是，加了重排之后，针对表格类问题和精确表述类问题，答案的完整度提升非常明显——一度从"答非所问"变成"能准确定位到正确的那一行"。如果你只打算对现有 RAG 做一处升级，我强烈建议先加重排，它大概是全链路里投入产出比最高的一环。
4. 第四道分水岭：query 不是拿来就用——改写、扩展与上下文工程
跑通 RAG 之后，你很快会发现下一个瓶颈不在库里，而在用户的那句话上。用户不会按你文档里的措辞提问，更不会按向量检索的偏好说话。query 侧如果不做处理，再好的库也白搭。
4.1 用户的问法，需要系统"翻译"成检索语言
一个很典型的场景：用户问"那个报障系统的超时时间是多少"，而文档里写的是"Request Timeout 配置为 3000ms"。直接拿原始句子去做向量检索，很多时候召回率很一般，因为口语表述和文档书面表述之间的词汇鸿沟太大了。这时候可以先让大模型做一次 query 改写：把用户的问题转换成更接近文档表达方式的检索查询，保留关键实体词和潜在同义词，生成两到三个候选查询，分别检索后合并结果。
改写 prompt 不用太复杂，核心要求就三条：不得虚构原文没有的信息；优先保留专有名词、数字、型号；返回多个检索词变体。注意一点：改写结果只用于检索，不要用它替代原始问题去做生成，否则容易把生成引向改写产生的细节上。
还有一种思路叫 HyDE，想法是先让大模型在无检索的情况下生成一个假设性回答，然后拿这个回答的向量去文档库里找相似内容。它对"开放式、经验型"的问题效果不错，因为模型生成的假设性回答与文档库里的真实段落往往语义更接近。但对强事实型问题，我实测过几次，效果反而变差——模型猜的东西会污染检索方向。所以 HyDE 不是默认选项，要按场景用。
4.2 多跳问答：从"一次检索"到 RAG 智能体
标准 RAG 假设一个问题一次检索就能找到答案，但现实问题是多跳的。比如"我的服务在 K8s 上延迟升高，和去年上云之前相比到底差了多少"——这句话里根本没有一句能同时对应"当前延迟"和"去年基线"。你要拆成至少两个子问题，先定位监控文档里的当前延迟记录，再定位历史基线记录，最后才在生成阶段做对比分析。
这其实就是热词里"rag 智能体"的由来。做法上是给检索加一层"路由和控制"：先用意图识别判断这个问题是否需要拆解、拆成几步；然后让模型按步骤逐一生成子查询，每轮检索后把中间结果带给下一步决策；最后把多路中间结果拼接给生成模型。为了让这个流程可控，中间结果最好带上来源和置信度，让模型能看到"目前找到哪些证据，还缺哪些证据"。
不是所有问题都要上智能体，多跳拆解是有成本的。我建议先用一个简单的规则路由：如果 query 里出现"对比""原因""和之前比""为什么"这类词，就进入多跳分支；其余走标准单跳 RAG。这样既避免所有请求付出多余延迟，又把智能体的能力用在了最需要的地方。
4.3 上下文不是越全越好：过滤、压缩与精排
最后是生成侧的上下文工程。不少人把所有召回结果全塞进提示词，指望模型自己找到重点，结果模型被无关信息带偏。正确的做法是给生成模型一个干净的上下文，而不是一个信息堆。我习惯在把候选送进生成模型前做一轮"上下文选择和压缩"：
- 先按相关性和重排分数过滤，只留 top3-5 个块；
- 再看总 token 数，如果超限，让模型对过长的块做摘要压缩，而不是直接截断；
- 关键块和引用来源原样保留，因为答案的忠实度依赖原始证据。
这里有个容易忽略的点：压缩摘要这件事本身也要交给大模型，并且要明确"压缩后的内容不得新增原文没有的事实"。否则你会在检索层找不到问题，最后发现是上下文压缩阶段把关键数字给"润色"掉了。
5. 第五道分水岭：从向量相似走向知识关联——Ontology RAG 与知识图谱
前四道分水岭解决的是"文档内容好不好找"。但有些问题，答案根本不在某一篇文档里，而是藏在文档与文档之间的关联里。这时候向量库再强也白搭，因为它擅长"看起来像"，不擅长"事实上的关系"。
5.1 向量库的联想局限，怎么也绕不过关系型问题
举一个运维场景。你有很多服务部署和故障复盘文档，文档 A 说"组件 X 依赖组件 Y"，文档 B 说"组件 Y 依赖组件 Z"，用户问"组件 X 为何启动失败"。如果把每份文档切成 chunk 存进向量库，单次向量检索最多命中其中一篇，拼不出"X 依赖 Y、Y 依赖 Z、Z 是根因"这条推理链。这不是 embedding 模型不够好，而是向量库的表示能力的问题——它存的是"语义相似"，不是"关系结构"。
处理这类问题的方向，就是把知识组织成图：实体是节点，关系是边。这也是"ontology rag"被讨论得越来越多的原因。热度不完全是炒概念，而是它真的能补齐纯向量 RAG 的结构短板。
5.2 Ontology RAG 怎么做：本体定义、实体抽取、图检索
这里我不打算讲太多理论，直接给一套可落地的三步框架。
第一步，定义领域本体。也就是明确你的知识库里有哪些类型的实体、实体之间有哪些关系。以运维知识库为例，实体类型可以是服务、组件、配置项、故障类型、根因；关系类型可以是"依赖""配置于""导致""修复方案是"。这一步不需要一步到位，先覆盖最常见的两三种实体和关系，后面边做边补。
第二步，实体抽取与对齐。可以用正则加规则先抽一次（尤其是型号、ID 这类稳定实体），再用大模型做关系抽取：给定一段文档文本，让模型输出"实体 1 - 关系 - 实体 2"的三元组。抽取结果存入轻量图结构，本地没有重型图数据库也可以先用邻接表存起来，检索时做图路径遍历。
第三步，图检索与生成结合。用户 query 进来，除了走向量召回，还走一条"图查询"路线：解析出主实体，沿着关系边做 2-3 跳路径搜索，把路径上的实体和关系描述拼成一条"知识链"，和向量召回的文本块一起送给生成模型。实测下来，这类多跳关系问题的答案质量会有质的提升，而且模型能给出"因为 A 依赖 B，B 依赖 C，所以 A 失败很可能是 C 引起的"这种带推理链的解释。
5.3 别小看"轻量本体"：wiki 方式也值得借鉴
热词里有人提到"wiki 和 rag"，这其实是个很敏锐的观察。维基百科为什么经常能直接回答复杂问题？因为它的内容被超链接、信息框（infobox）、目录这些轻量结构组织起来了——这本质上就是一种本体。你可以在自己的 RAG 里模仿同样的做法：给每篇文档或每个实体生成一个信息框，记录关键属性；文档内部把高频术语链接到对应的解释文档；检索的时候先命中信息框，再顺着链接去找正文。
我之前给一个产品手册知识库做过"信息框 + 正文 + 关联文档"的三层结构，幻觉率下降得非常明显。原因也简单：信息框是高度结构化的，检索它比检索自由文本更精准，生成时看到的关键属性都是"硬数据"，容错空间小很多。成本方面，信息框的生成逻辑只需要一次离线抽取，完全本地方案可做。
6. 第六道分水岭：没有评测系统的 RAG，只是跑通 demo
这第六处最容易被忽略，但我认为它是把 RAG 从"demo"推向"产品"的分水岭。
6.1 为什么你的 RAG 项目"改不动"？
我见过不少团队，RAG 上线后遇到质量问题，第一反应是换 embedding 模型，换完感觉"好像好了一些"，过几天又说不清楚到底好在哪。问题的根源是没有评测集。你改了切分策略，怎么知道是变好还是变坏？你换了检索方式，怎么知道提升了几成？没有量化反馈，每次优化都是赌博，整个项目越改越不敢改。
所以我在项目启动第二天，就会逼自己做一件事：采集 50-100 条真实用户问题，附上标准答案，或者至少标注"答案应出自哪份文档的哪个区域"。不需要多，五十条高质量的坏例和正常例，就能支撑第一轮迭代。
6.2 三个基础指标，能覆盖 80% 的质量问题
RAG 的不同环节对应不同指标，我平时主要盯三个。
- 上下文相关性（Context Relevance）：检索召回的内容和用户问题相关吗？直接反映检索和重排质量。可以人工给召回结果打 0/1，也可以让大模型按 1-5 分评估。
- 答案忠实度（Faithfulness）：生成回答里的每个事实，是否都能在提供的上下文中找到依据？直接反映幻觉程度。
- 答案相关性（Answer Relevance）：回答是否有效回应了用户问题？哪怕完全忠实于原文，答非所问也没用。
这三者一拆，bad case 的定位就清晰了。如果上下文相关性低，问题在检索层，或者切分层把相关内容切散了；如果上下文相关性高但答案忠实度低，问题通常出在生成层，比如上下文压缩时改动事实、提示词约束不够；如果前两项都高但答案相关性低，问题往往在 qa 链路设计上——模型根本没有理解用户意图，只是机械地复述了原文。
6.3 建立迭代闭环和可观测性
有了评测集和指标，优化就可以闭环了。每轮改动跑一遍评测集，对比指标，再人工抽看十几个 bad case。我强烈建议把每个 bad case 打上环节标签（解析、切分、召回、重排、压缩、生成），一个月后你会得到一张分布表，它会告诉你真正值得投入优化的环节在哪里，而不是凭感觉瞎调。
生产环境的可观测性同样重要。我要求线上系统给每一次问答打 trace，至少包含这些字段：原始 query、改写后的 query、召回块和分数、重排后选中的块、压缩结果、最终生成文本、整体耗时。没有这条 trace，线上出了 bad case 只能靠猜；有 trace 的话，五分钟就能定位到是哪个环节出了问题。
6.4 框架选型：LangChain、LlamaIndex 与 LangChain4j 的取舍
最后落到框架。Python 生态里，LangChain 和 LlamaIndex 都是成熟选项：LangChain 生态全、链式能力丰富，LlamaIndex 在数据索引和检索层面的设计更细。如果你在 Java 服务里集成，热度很高的 LangChain4j 是个不错的选择，它的 Easy RAG 模块把文档加载、拆分、embedding、存储、检索、生成的基本流程全都封装好了，几百行代码就能把一个可用的 RAG 服务跑起来，特别适合团队快速验证一个 idea。
但你要始终记住：框架解决的是"能跑起来"，解决不了"跑得好"。Easy RAG 默认的切分策略是固定长度，默认检索不做混合召回、不做重排，它对应的是基础流水线，而不是生产级方案。凡是我们在前五个分水岭里讨论的东西——结构化解析、语义切分、多路召回、重排、query 改写、评测闭环——框架给了接口，但具体实现和调优还是要自己补。我把框架当"脚手架"而不是"答案"，这句话值得每个做 RAG 的人抄下来。
最后说一点我真切的体会。如果项目刚起步，别奢望六处全做。按投入产出比排，我永远是先做文档结构化解构、混合检索加重排、评测闭环这三件，它们能解决我见过的大多数"答非所问"。图谱和智能体是进阶选项，留给真正有关系型和多跳问题的场景；切分和 query 改写的优先级，让评测数据告诉你，而不是让教程告诉你。RAG 的门槛确实被框架拉得越来越低，但分水岭始终在人这一侧：你有多认真地对待进入知识库的每一份文档、每一次检索、每一个 bad case，你的 RAG 就有多能打。
