这两天我花了不少时间，把RAG相关的技术栈从头到尾梳理了一遍。坦白说刚开始我以为这事儿挺简单的，不就是文档切个块、转成向量、存进数据库，Zui后让大模型去搜吗？但当你真正沉下心来试图构建一个Neng够落地的企业级系统时你会发现事情远没有那么线性。那种“文档切片 + 向量检索 + 大模型回答”的标准流程，geng多只是教科书式的入门演示，离真实世界的工程落地还有hen长的路要走。

hen多人第一次接触RAG，脑子里蹦出来的关键词往往离不开这几个：Embedding、向量数据库、检索、Rerank、Chunk。这些概念当然重要，但Ru果只盯着这些技术点kan，hen容易陷入“只见树木，不见森林”的误区。我们得把视野拉高一点，去kankan这套系统背后的逻辑。

大模型Yi经这么强了为什么还需要RAG？

先聊个Zui根本的问题。现在的GPT-4、Claude这些模型，kan起来无所不知，为什么企业还要费劲去搞RAG？原因hen简单：大模型再强，也不天然知道你的私有知识。它训练数据截止到某个时间点，它没kan过你公司内部的报销制度，也不知道你昨天刚geng新的产品手册。

这时候，RAG的价值就体现出来了。它解决的不是如何理解文本，而是如何高效地存和如何快速地找。它让大模型在生成答案之前，不是直接依赖参数记忆去“猜”，而是先从外部知识库中检索证据，再基于这些证据生成回答。对于企业知识库、私有数据问答、以及需要持续geng新知识的系统来说这件事的意义非常明确。

所以RAG不是单点Neng力，而是一整套知识如何流向答案的系统设计。企业真正需要的，往往不是一个会聊天的模型，而是一个Neng基于内部资料准确回答问题的系统。

数据的起点：被忽视的文档处理

既然要检索， 得有数据。但现实往往hen骨感，RAG的起点不是模型，而是数据。而在所有数据源中，Zui常见、也Zui让人头疼的，通常是PDF。

为什么？因为PDFgeng接近排版结果，而不是天然结构化文本。它抽取出来之后经常会出现标题层级丢失、段落断裂、页眉页脚混入正文等乱象。Ru果直接把这种“脏数据”拿去切片，后面的模型再强也是白搭。

在正式切片前，往往还要Zuo一层清洗。比如去掉无效空行、去掉重复页眉页脚、清理乱码和特殊符号。这一步kan起来像基础工作，但其实非常重要。后面Zuo过滤检索、结果溯源、答案引用时hen多Neng力dou依赖这些结构和元数据。所以一句话来说就是：知识库效果好不好，第一步常常不是模型决定的，而是文档处理决定的。

切片的艺术：怎么切决定了Neng检索到什么

文档清洗完了下一步就是切片。原因hen简单：文档太长，不Neng整篇直接拿去检索，也不可Neng完整塞进模型上下文。所以必须把它拆成一个个chunk。

Zui基础的方式，就是按固定长度切。比如每500字、1000字，或者每128 token切一块。这种方法实现简单，适合快速搭原型。但问题也明显：hen容易把完整的语义从中间截断。

为了减少边界信息丢失，通常会在相邻chunk之间加入overlap，也就是重叠区域。这样Zuo的好处是：即使关键信息刚好落在边界上，也不容易被切丢。

但真正Zuo下来会发现，切片往往才是Zui影响效果的环节之一。说得geng直接一点：你怎么切，决定了后面模型Neng检索到什么。geng进一步的方式，是按语义边界切片。它的思路不是按固定长度硬切，而是先判断一段文本内部，语义究竟是在哪里发生变化的。

比如一段文本被拆成A、B、C、D、E、F六个句子。接着，把每个窗口送进embedding模型，得到对应的语义向量，再比较相邻窗口之间的差异。Ru果窗口大小设为3，就Ke以得到A-B-C、B-C-D、C-D-E、D-E-F这些滑动窗口。Ru果某个位置前后的差异突然变大，就说明主题可Neng在这里发生了变化，这个变化Zui大的点就Ke以作为候选切分点。

这种方式geng符合人类阅读习惯，也geng容易保留完整语义。但它对文档质量要求geng高，实现复杂度也geng高。本质上，它不是按长度切，而是沿着语义变化Zui明显的地方切。

向量化与存储：语义坐标的映射

切完片之后下一步就是把文本变成可计算的语义表示，这就是Embedding。Zuo完Embedding之后还需要把这些向量和原始文本一起存起来这就是向量数据库的工作。

向量知识库是一种基于向量化表示来存储和检索数据的形式。它的核心是将文本或其他数据转化为向量，并通过计算相似度来高效检索与查询相关的内容。

实际工程里这一类模型常见的代表有BGE和GTE系列，比如bge-large-zh、bge-m3，或者gte-large等。它们本质上Zuo的dou是同一件事：尽量让语义相近的文本，在向量空间里离得geng近。

降维理解一下：实际向量可Neng是数百维，但语义关系可通过数学计算映射到低维空间呈现。你Ke以把它理解成，模型先读一句话，理解它大概在说什么然后再给这句话分配一个语义坐标。以后系统Zuo检索时就不再只是比关键词，而是去比较这些语义坐标之间的距离。距离越近，通常说明语义越接近；距离越远，通常说明语义差别越大。

向量数据库一般包括以下几个部分：索引、查询、过滤。它使用HNSW等算法对向量进行索引，此步骤将向量映射到数据结构，以实现geng快的搜索。在这一类系统里Milvus是一个hen典型的代表，也是业界比较常用的向量数据库之一。

真正进入向量数据库的，通常不只是一个向量，还会包括对应的chunk原文、来源文档、页码、标签、时间、业务字段等信息。因为Zui终系统返回给用户的，不是一个抽象向量，而是一段可读、可追踪、可用的知识。

检索策略：混合检索的必要性

有了数据，接下来就是检索。hen多人学RAG，第一反应会把重点放在Embedding或向量数据库上。初学RAG时hen容易把它理解成一句话：把问题转成向量，然后去向量数据库里搜。

这当然没错，但只说对了一半。真实场景里的检索，通常是多种方式的组合。有些场景下系统并不是只有一路召回，而是会同时结合向量检索、全文检索、关键词检索等多种方式。

Zui常见的一类是密集嵌入，也就是Dense Embedding。它会把文本表示成一个稠密向量，比较擅长处理表达不同，但意思相近的情况。比如“怎么报销差旅费”和“出差费用报销流程是什么”，虽然字面不一样，但语义其实hen接近，Dense Embedding通常Neng把它们映射到比较近的位置，所以特别适合Zuo语义检索。

另一类是稀疏嵌入，也就是Sparse Embedding。这里一个非常经典的代表就是BM25。它虽然不是大模型时代才出现的方法，但在检索系统里一直非常实用，尤其适合Zuo关键词召回。BM25Ke以理解成一种基于关键词相关性的排序算法。它会根据查询词有没有出现、出现了多少次、这个词在整个语料里是否稀有，以及文本长度是否合适，来判断一段文本和问题的匹配程度。

它不擅长理解深层语义，但对术语、编号、错误码、专有名词这类关键词非常敏感。所以在hen多实际系统里Dense和BM25并不是互相替代，而是一起使用，形成混合检索。

现实里hen多问题并不只是语义理解问题，而是我就要找这个词。比如用户搜的是产品型号、法条编号、报错代码、专有名词，这时候单靠Dense不一定Zui稳，因为语义模型有时候Neng理解大意，但未必Neng稳稳抓住关键词。Sparse或全文检索往往geng有效。

单一路径，hen难兼顾两边。所以在hen多实际项目里Zui稳定的Zuo法往往是混合检索，也就是把向量检索和全文检索结合起来。

重排：用计算成本换取质量

检索完了就完了吗？还没。hen多时候，同样是RAG，前面的检索结果kan起来差不多，但Zui终回答效果还是会有明显差异。因为召回到了不代表排得Zui好。

系统可Neng一次召回了50条dou相关的内容，但真正Zui适合回答当前问题的那条，未必排在Zui前面。Ru果不再Zuo一次排序优化，Zui终交给模型的上下文就可Neng不是Zui优的。

所以从工程角度kan，Cross-Encoder类精排模型本质上是在用geng高的计算成本，换取geng高质量的排序结果。Ru果想进一步判断哪段内容Zui适合当前问题，通常还会引入专门的精排模型，比如Cross-Encoder类的reranker。

向量检索通常属于双塔结构，也就是先把问题和文本分别编码成两个向量，再通过向量相似度判断它们是否接近；而Cross-Encoder则是把问题和候选文本作为一对输入，一起送进模型，让模型直接输出一个匹配分数。

这样Zuo的好处是模型kan到的不再是两个彼此独立的向量，而是问题和文本之间geng细粒度的交互信息，所以通常geng适合ZuoZui终排序。也正因为如此，Cross-Encoder类方法往往比普通向量相似度geng准，尤其适合用来判断这段内容到底是不是Zui适合回答当前问题。

不过它的代价也geng高。因为每一个候选文本，dou要和当前问题单独配对，再跑一遍模型，所以计算成本会明显高于普通向量检索。也因此，在实际工程里它一般不会用来Zuo大规模召回，而是放在召回之后对前几十条候选结果再Zuo一次精排。

Rerank的意义Ke以概括成一句话：不是把相关内容再找一遍，而是把可Neng相关进一步筛成Zui适合当前问题的内容。

生成阶段：上下文编排与幻觉控制

检索和重排Zuo完之后下一步才是真正把信息交给大模型，也就是生成阶段。hen多文章讲RAG，讲到检索和重排就差不多结束了。但真正决定回答质量的，往往还包括Zui后一步：检索到的内容，究竟怎么交给模型。

生成阶段Zui常见的Zuo法，是把检索到的若干chunk拼进Prompt，再连同用户问题一起发给模型。但这一步并不是简单拼接，而geng像是在Zuo上下文编排。

比如取几个chunk，按什么顺序放，要不要去重，要不要带来源，内容会不会超出上下文长度，这些dou会直接影响Zui终回答质量。因为上下文不是塞得越多越好。塞太多，模型可Neng抓不住重点；塞太少，信息又可Neng不足。

所以从工程上kan，生成阶段真正影响的是：模型Neng不Neng把检索到的信息稳定转化成可用的答案。Ru果约束不清楚，模型即使kan到了证据，也可Neng继续自由发挥。

生成阶段另一个核心目标，是尽量降低幻觉。RAG不Neng彻底消灭幻觉，但Ke以明显降低它出现的概率。前提通常有两个：一是检索结果本身足够相关，二是Prompt约束足够明确。

所以这一层真正要解决的问题，不是怎么把内容放进去，而是怎么把Zui合适的内容，用Zui适合模型理解的方式放进去。

进阶RAG：从流水线到工作流

Ru果说前面讲的，geng多还是标准RAG的主链路，那么再往后走，hen多优化Yi经不只是检索得geng准一点这么简单了。因为继续往后优化，优化的往往Yi经不只是检索效果，而是整套系统Neng不NengZuo出geng合适的决策。

因为不是所有问题，dou值得走同样一套固定流程。有些问题一句话就Neng召回，有些问题需要多跳检索，有些问题甚至根本不该走知识库，而应该直接回答，或者先Zuo路由判断。

Adaptive RAGgeng强调按问题类型动态调整策略。它不默认第一次检索结果一定靠谱，而是会进一步判断：当前证据是不是不足，检索结果之间有没有冲突，Ru果这次检索不理想，是否需要补检索、 查询，或者调整后续流程。

Corrective RAGKe以理解成一种带纠偏Neng力的RAG。它优化的，Yi经不只是检索，而是当检索结果不够好时系统怎么自我修正。

所以到了这一步，RAG就不再只是固定流水线，而geng像是一套带决策Neng力的工作流。这也是为什么现在hen多人会把RAG和Agent、工作流编排放在一起讨论。从这里大家也Ke以kan出来了粉丝疑惑的Langchain其实与RAG没撒必然的联系，Agent平台/框架确实会涉及到知识库，他们也会用到RAG...

RAG是系统设计，不是单点技术

回过头kan，RAG的价值并不在于引入了多少新概念，而在于它提供了一种geng可控的知识接入方式。RAG的本质Ke以概括成一句话：不是让模型凭记忆回答，而是让模型基于证据回答。

kan起来不复杂，但真正难的是：这条链路里每一步dou会影响Zui终回答质量。它Zui终效果，取决于整条链路的质量，包括文档解析、切片策略、召回方式、重排机制，以及上下文组织方式。

这也是我这次梳理之后Zui明确的一个RAG的关键，不在于有没有搭起来而在于每一个环节是否真正为Zui终回答质量服务。hen多时候，RAG效果不好，不是模型太弱，而是检索策略太单一。

所以从工程视角kan，RAGgeng像一套系统设计问题，而不是单一模型Neng力问题。因为真实用户的问题，往往既有语义理解需求，也有精确匹配需求。有些时候，仅靠语义相似还不够。

Ru果你也在学习RAG、Agent架构，或者正在ZuoAI应用落地相关的事情，希望这篇梳理Neng帮你把RAG真正串起来。不要只盯着向量数据库，要去思考整条数据链路。毕竟文档是怎么进入系统的？为什么一定要切片？检索为什么不只是向量搜索？为什么召回之后还要重排？RAG真正难的地方到底在哪？这些问题想清楚了系统才Neng真正落地。

---