一文讲透 RAG:从文档分片、向量检索到企业级知识库的完整工作流程

RAG（Retrieval-Augmented Generation，检索增强生成）已经成为 AI 知识库、企业 Copilot、智能客服和 Agent 系统最重要的基础架构之一。
但很多开发者对 RAG 的理解仍停留在"Embedding + 向量数据库"这一层，而真正影响知识库效果的文档解析、Chunk、Recall、Rerank、Prompt 等关键环节，却往往被忽略。
一个真正可用于生产环境的 RAG，并不是几个组件的简单组合，而是一条完整的知识处理流水线。
本文将从企业级 RAG 的完整工作流程出发，系统拆解Document Parser、Chunk、Embedding、Vector Database、Recall、Rerank、Prompt等核心组件，并结合实际工程经验，带你完整理解高质量知识库背后的技术原理。

为什么很多企业知识库效果不好？

如果你做过 AI 知识库、企业客服或者内部知识助手，很可能遇到过这些问题：

文档里明明有答案，模型却回答"不知道"？
上传了几百份 PDF，回答仍然经常答非所问？
相同的问题，却得到完全不同的答案？
知识库越来越大，回答速度越来越慢？
接入向量数据库以后，效果却没有明显提升？

很多团队第一次接触 RAG 时都会认为：

"只要把 PDF 放进向量数据库，就拥有了 AI 知识库。"

真正上线之后才发现，实际情况远没有这么简单。

知识片段可能没有被正确切分；
Embedding 模型可能无法准确表达业务语义；
检索没有找到真正相关的内容；
重排没有过滤掉噪声；
Prompt 没有约束模型生成。

最终导致的结果就是：

检索出来的内容并不准确；
大模型引用了错误的知识片段；
回答仍然存在大量幻觉；
Token 成本越来越高；
用户体验远低于预期。

事实上，这些问题大多数都不是大模型本身造成的。

一个企业级知识库的回答质量，很大程度上取决于：

文档解析是否正确；
Chunk 是否合理；
Embedding 是否适合当前业务；
Recall 是否能够找到真正相关的数据；
Rerank 是否能够筛掉噪声；
Prompt 是否限制了模型自由发挥。

换句话说，一个优秀的 RAG 系统，本质上并不是"一个模型"，而是一条完整的数据处理流水线。

而大模型，只是这条流水线中的最后一个环节。

从整体来看，一个企业级 RAG 会经历下面几个关键阶段：

文档解析 → 文档分片 → 向量化 → 向量存储 → 检索召回 → 重排排序 → Prompt 组装 → 大模型生成答案

整个过程并不是让大模型"记住所有知识"，而是让模型在回答之前，先找到正确的资料，再依据资料完成回答。

理解了这一点，也就理解了 RAG 的真正价值。

下面，我们就从整个工作流程开始，逐步拆解一个企业级 RAG 系统的完整技术链路。

第一章：RAG 的整体工作流程

理解了 RAG 的作用之后，我们来看它究竟是如何工作的。

很多文章介绍 RAG 时，会直接从 Embedding 开始讲。

实际上，一个完整的企业级 RAG 远不止如此。

它通常包含两条完整的数据链路：

第一条，是离线知识构建流程。

负责把企业文档加工成可检索的数据。

第二条，是在线问答流程。

负责根据用户问题快速找到相关资料，并交给大模型生成答案。

整个过程可以概括为下面这张架构图。

企业文档PDF / Word / Markdown / Excel │ ▼Document Parser（文档解析） ▼Chunk（文档分片） ▼Embedding（向量化） ▼Vector Database（向量数据库）══════════════════════════════用户问题 ▼Embedding ▼Recall（召回） ▼Rerank（重排） ▼Prompt Construction ▼LLM ▼Answer

从整体来看，这条链路可以拆成五个核心阶段：

文档分片（Chunk）
向量化（Embedding）
检索召回（Recall）
重排（Rerank）
大模型生成（Generation）

其中，前三步更多属于数据准备阶段。

后两步属于在线推理阶段。

很多人认为：

RAG = Embedding + 向量数据库。

实际上，这只是整个系统的一小部分。

真正影响企业知识库效果的，是整条流水线是否协同工作。

例如：

Chunk 是否切分合理？
Embedding 是否适合中文？
Recall 是否能够召回真正相关的内容？
Rerank 是否过滤掉噪声？
Prompt 是否限制模型胡编？

这些都会直接影响最终回答质量。

因此，我们可以把 RAG 理解成：

Document → Retrieval → LLM

也就是：

先加工知识，再精准检索，最后交给模型理解和生成。

第二章：第一步——Chunk，把大文档拆成可检索的知识单元

理解了 RAG 的整体流程之后，我们先来看第一步，也是最容易被忽略的一步：

Chunk（文档分片）。

很多开发者第一次接触 RAG 时，都会把注意力放在 Embedding 或向量数据库上，而认为分片只是"把文档切一下"这么简单。

实际上，Chunk 策略往往决定了整个知识库的上限。

很多知识库效果不好，并不是 Embedding 模型不够优秀，而是文档一开始就没有切好。

为什么一定要分片？

假设企业有一本产品使用手册，共 300 页。

用户提出一个问题：

某功能如何开启日志采集？

真正能够回答这个问题的，可能只有其中两页内容。

如果系统把整本手册一次性交给大模型，就会带来三个问题：

第一，上下文窗口有限。

即使是支持数十万 Token 的模型，也不适合每次重新阅读整本文档。

第二，Token 成本过高。

每次回答问题都输入几万甚至几十万 Token，不仅昂贵，而且毫无必要。

第三，相关信息容易被淹没。

资料越长，无关内容越多，大模型反而更难关注真正有价值的信息。

因此，一个成熟的 RAG 系统，并不是让模型阅读整本文档，而是：

提前把文档拆成许多个可以独立检索的小知识单元。

这就是 Chunk 的意义。

Chunk 是什么？

Chunk（文档分片），就是把一篇完整文档拆分成多个较小的文本片段。

例如：

产品手册（100 页）↓Chunk 1产品介绍↓Chunk 2安装部署↓Chunk 3数据库配置↓Chunk 4日志采集↓Chunk 5权限管理

这样，当用户询问：

如何配置日志采集？

系统只需要找到 Chunk4，而不需要重新处理整个产品手册。

常见的 Chunk 方式

实际项目中，并不存在一种万能的 Chunk 策略。

不同类型的数据，适合不同的切分方式。

常见方式包括：

① 固定长度切分

例如：

每 500 字
每 1000 Token

优点：

实现简单；
数据量均衡。

缺点：

容易截断完整语义；
标题与正文可能被拆开。

② 按段落切分

一个自然段作为一个 Chunk。

优点：

保持语义完整；
阅读体验较好。

缺点：

长度差异较大；
某些段落可能过长。

③ 按标题切分（推荐）

例如：

第3章数据库配置↓Chunk数据库配置全部内容

优点：

保留文档结构；
非常适合企业文档。

也是目前很多生产系统最常采用的方法。

④ 按业务结构切分

例如：

FAQ：

Q：......A：......

一组问答就是一个 Chunk。

或者：

合同制度API 文档

按照天然业务边界切分。

为什么还需要 Overlap？

很多人发现：

如果一句话正好被切断怎么办？

例如：

Chunk1......安装完成后---------Chunk2请执行 restart

真正答案其实跨越两个 Chunk。

怎么办？

工程实践通常采用：Overlap（重叠窗口）

例如：

Chunk11~500Chunk2450~950

中间：50 Token 重复。

这样即使语义跨越边界，也不会丢失。

第三章：第二步——Embedding，把文本转换成语义向量

完成文档分片之后，系统仍然无法进行语义检索。

因为计算机并不能直接理解："数据库配置"、"日志采集" 这些文字。

它真正能够计算的是：数字。

因此，下一步就是：Embedding。

Embedding 是什么？

Embedding 可以理解成：

把文本映射到高维向量空间。

例如：

数据库配置↓Embedding↓[0.23-0.650.88......]

最终得到的是几百维甚至几千维的数字。

这些数字就是：向量（Vector）。

为什么要转换成向量？

Embedding 的核心目标不是压缩文本。

而是：表达语义。

例如：

苹果香蕉水果

经过 Embedding 后，它们在向量空间中的距离会比较近。而：

汽车数据库天气

距离则更远。

也就是说：

语义越接近，向量越接近。

这也是语义检索能够成立的根本原因。

Embedding 与 Tokenizer 有什么区别？

很多人容易把两者混淆。

实际上：Tokenizer：负责：

文字↓Token

Embedding：负责：

Token↓Vector

Tokenizer是：切分文本。

Embedding 是：表达语义。

两者属于完全不同的阶段。

Embedding 模型如何选择？

企业项目中，Embedding 模型不能随便更换。

需要考虑：

中文效果
英文效果
多语言支持
向量维度
推理速度
成本

不同模型得到的向量空间也不同。因此：

文档向量和问题向量必须来自同一种（或兼容）Embedding 模型。

否则：相似度计算将失去意义。

第四章：第三步——Vector Database，让语义检索成为可能

完成 Embedding 后，每一个 Chunk 都拥有了对应的向量。

下一步，就是把这些向量保存起来。

这里使用的，不是 MySQL，也不是 Elasticsearch。

而是：Vector Database（向量数据库）。

为什么不能直接存数据库？

假设：

企业已经拥有：

100 万个 Chunk。

每次用户提问，都需要计算：

问题向量VS100万个向量

如果逐个计算，效率将非常低。因此，需要一种专门针对：

高维向量相似度搜索设计的数据库。这就是：Vector Database。

向量数据库保存什么？

很多人误认为：

向量数据库只保存：向量。

实际上，一个 Chunk 往往包含：

Chunk↓原始文本↓Embedding Vector↓标题↓来源↓页码↓权限标签↓更新时间

因此：向量数据库不仅保存：Vector。还保存：各种 Metadata。

常见的向量数据库

目前企业最常见的包括：

Milvus
Qdrant
Weaviate
Pinecone
Chroma（开发测试）
FAISS（本地检索库）

不同数据库：索引算法、扩展能力、过滤能力、性能特点，都略有不同。

但目标一致：

快速找到最相似的向量。

为什么向量数据库这么快？

因为它不会遍历全部数据。而是采用：ANN（Approximate Nearest Neighbor）近似最近邻搜索。

例如：HNSW、IVF、PQ等索引算法。能够把：百万、千万、甚至上亿向量，都保持较快检索速度。

第五章：第四步——Recall，从海量知识中快速找到候选答案

经过 Chunk、Embedding 和向量化存储之后，一个企业知识库已经拥有了成千上万个甚至数百万个知识片段。

那么，当用户提出问题时，系统究竟是如何在如此庞大的知识库中快速找到相关内容的？

这一步，就是：Recall（召回）。

Recall 是什么？

Recall 可以理解成：

从整个知识库中，快速找出"可能相关"的一批知识片段。

例如，用户提出：

如何配置日志采集？

系统首先会把这个问题送入与文档相同的 Embedding 模型。

用户问题↓Embedding↓Question Vector

随后，系统会拿这个问题向量，与向量数据库中的所有 Chunk 向量进行相似度计算。

最终得到：

Top50 Candidate↓Chunk12Chunk38Chunk102Chunk265......

这就是 Recall。

为什么不是直接取 Top3？

很多初学者都会产生一个疑问：

既然最终只需要几个片段，为什么不直接检索：Top3？

原因很简单：

向量检索属于近似匹配。

它擅长：快

但并不一定：最准

例如：用户：

如何配置日志采集？

Recall 结果：

① 日志采集② 日志存储③ 日志查询④ 数据采集⑤ 系统监控......

其中真正答案可能排在：第6名。

如果直接：Top3，真正答案就丢失了。

因此，生产环境通常采用：

RecallTop30Top50Top100

先尽可能保证：召回率。

Recall 更关注"找全"

Recall 阶段最重要的指标不是准确率。

而是：

Recall Rate（召回率）。

也就是说：真正相关的数据，最好都能够进入候选集合。即使混入一些噪声，问题也不大。因为后面还有：Rerank。

Recall 常见实现方式

目前主要包括：

① Vector Search

完全依赖：Embedding。

优点：

理解语义；
能处理同义词；
不依赖关键词。

② Keyword Search

例如：BM25。完全依赖：关键词匹配。

优点：

精准；
对专有名词效果好。

缺点：

不能理解语义。

③ Hybrid Search（推荐）

企业项目目前最常见：

Vector Search+BM25↓Hybrid Recall

这样既能理解语义。又能保证关键词命中。

因此，大部分生产级知识库都会采用混合检索，而不是单纯依赖向量搜索。

第六章：第五步——Rerank，从候选内容中精挑细选

Recall 已经帮助系统找到了一批候选知识。

但是：它们真的都适合作为最终答案吗？

答案是：不一定。

因此，还需要下一步：Rerank（重排）。

为什么需要 Rerank？

Recall 更像：初筛。

例如：

Top50↓真正相关Top5↓部分噪声Top45

虽然真正答案已经进入候选集合，但是排序可能并不理想。

例如：

Top1日志存储Top2日志查询Top3监控配置Top4日志采集（真正答案）

如果直接交给大模型，很可能受到前几个无关 Chunk 的干扰。

因此：需要重新排序。

Rerank 是什么？

Rerank 可以理解成：

重新判断问题与候选片段之间真正的相关程度。

Recall：比较的是

Question VectorVSChunk Vector

Rerank：比较的是：

Question+Chunk↓Cross Encoder

也就是说，模型真正阅读问题和文本。因此准确率更高。

Recall 与 Rerank 的区别

可以简单理解成：

Recall 快 找全↓Rerank 慢 找准

或者招聘流程。

Recall：筛简历。

Rerank：面试。

最终录用。

为什么不直接使用 Rerank？

原因同样是：成本。假设知识库100 万 Chunk。如果每次问题都让 Cross Encoder计算100 万次。几乎不可接受。

因此必须：

Recall↓Top50↓Rerank↓Top5↓LLM

这种两阶段架构，也是目前企业最主流的方案。

第七章：第六步——Prompt Construction，让大模型依据资料回答问题

经过 Recall 与 Rerank 之后，系统终于拿到了真正相关的几个知识片段。最后一步就是：把这些资料交给大模型。

Prompt 是如何组成的？

很多人认为RAG 已经完成了。其实，还差最后一步。系统需要把：用户问题、知识片段、回答规则。组织成：一个完整 Prompt。

例如：

System Prompt+Question+Reference Chunks+Answer Rules↓LLM

例如：

请根据下面提供的资料回答问题。如果资料中没有答案，请明确说明：”当前资料无法确认。”不要编造内容。================知识片段：......================用户问题：......

随后一起发送给LLM。

为什么 Prompt 很重要？

很多人觉得只要检索正确，模型一定能回答正确。实际上不是。如果 Prompt 写得不好，模型仍然可能：

忽略资料；
编造答案；
混入训练知识；
引用错误 Chunk。

因此，生产环境通常会增加：

来源引用；
回答格式；
不允许胡编；
没找到答案必须拒答；
输出引用出处。

这样才能保证：答案更加可信。

一个完整的 RAG Prompt

通常包括：

System Prompt↓用户问题↓Recall + Rerank得到的知识片段↓回答规则↓LLM

最终生成答案。

到这里，整个 RAG 才真正完成

从最开始的一份 PDF，到最终回答用户，整个过程可以总结为：

Document↓Chunk↓Embedding↓Vector Database══════════════════Question↓Embedding↓Recall↓Rerank↓Prompt↓LLM↓Answer

这一条链路就是一个企业级 RAG 的完整工作流程。

第八章：为什么很多 RAG 项目效果不好？

完成前面的流程之后，很多开发者会认为：

文档已经切分了，向量也建立了，检索和重排也做了，RAG 应该就能稳定工作了。

然而，在真实项目中，大多数 RAG 项目真正上线之后，仍然会遇到各种各样的问题。

例如：

文档里明明有答案，却始终检索不到；
相同的问题，每次回答都不一样；
回答引用了错误的知识片段；
回答中仍然出现幻觉；
知识库越来越大，效果却越来越差。

这些问题，并不是某一个组件造成的，而是整条 RAG 链路共同作用的结果。

通常来说，一个 RAG 系统效果不好，主要集中在下面几个环节。

问题一：Chunk 切分不合理

Chunk 是整个 RAG 的基础。

如果 Chunk 切得不好，后面的 Recall、Rerank 再优秀，也无法弥补。

例如：

Chunk A安装完成后……------------Chunk B……请执行 restart 服务

真正的答案被拆到了两个 Chunk 中。

Recall 即使找到了 Chunk A，也无法得到完整答案。

反过来，如果 Chunk 太大，例如把一个章节全部作为一个 Chunk：

安装部署（4000 Token）

虽然保证了语义完整，但又会引入大量无关信息，降低检索精度，同时增加 Token 消耗。

因此，Chunk 的目标不是越大越好，也不是越小越好，而是在语义完整性和检索效率之间取得平衡。

问题二：Embedding 模型选择不合适

Embedding 模型决定了语义表达能力。

如果模型不适合当前业务领域，就容易出现：

问题：如何配置日志采集？↓召回：日志查询日志导出日志删除……

真正相关的 Chunk 根本没有进入候选集合。

因此：

中文知识库应优先选择中文效果较好的 Embedding 模型；
垂直行业知识库应尽量选择领域模型；
文档向量与问题向量必须使用同一套 Embedding 模型。

问题三：Recall 不全

Recall 更强调"找全"。如果 Recall TopK 设置过小，例如：

Recall Top3

真正答案可能排在第 5 位。因此很多企业都会采用：

Recall Top30↓Rerank Top5

这样能够明显提升最终准确率。

问题四：Prompt 缺乏约束

很多人认为：检索出来之后，直接把内容交给 LLM 即可。

事实上，如果 Prompt 没有限制，大模型仍可能：

使用训练知识补充答案；
忽略知识片段；
编造不存在的信息；
混合多个 Chunk。

因此，生产环境一般都会增加如下约束：

仅依据提供资料回答。如果资料不足，请明确说明：”无法确认”。不得补充推测内容。

这样能够有效降低幻觉。

问题五：忽略数据质量

很多项目上线效果不好，根本原因并不是模型，而是数据。

例如：

PDF 排版混乱；
OCR 识别错误；
表格丢失；
图片说明没有解析；
标题层级错误；
Markdown 转换失败。

如果进入知识库的数据本身就是错误的，那么检索效果自然也不会理想。

第九章：企业级 RAG 的最佳实践

很多 RAG Demo 看起来都可以运行。

但真正进入企业生产环境后，通常还会增加很多能力。

例如：

① 文档解析（Document Parser）

生产环境不会直接读取 PDF通常需要：

OCR
表格识别
图片解析
标题识别
页眉页脚清理
Markdown 转换

保证进入 Chunk 的文本尽可能干净。

② Metadata 管理

除了文本外，每一个 Chunk 通常还保存：

来源文档
页码
更新时间
标签
权限
文档类型

这样Recall 后不仅能够返回正文，还能返回：

来源：《员工手册》第 32 页

增强答案可信度。

③ Hybrid Search

目前越来越多企业采用：

BM25+Vector Search↓Hybrid Recall

原因很简单。关键词擅长专有名词。向量擅长语义。两者结合，通常优于单独使用。

④ 权限控制

企业知识库并不是所有人都能查看全部内容。

例如：

销售只能看销售文档研发只能看研发资料财务只能看财务制度

因此Recall 前通常会增加：Permission Filter。

⑤ 引用来源

越来越多企业要求答案必须包含出处。

例如：

来源：《部署手册》第 23 页

这样用户能够快速验证答案真实性。

⑥ 增量更新

企业知识每天都在变化因此通常不会重新构建全部向量。而是：

新增文档↓Chunk↓Embedding↓写入 Vector DB

实现增量更新。

第十章：RAG 与 Agent、MCP 的关系

很多开发者学习到这里都会提出一个问题：

RAG、Agent、MCP 到底是什么关系？

其实，它们解决的是三个完全不同的问题。

RAG负责：找到知识。

例如：

知识库↓Recall↓相关资料

MCP负责：连接系统。

例如：

数据库
GitHub
Jira
文件系统
企业 API

MCP 解决的是：Agent 如何访问外部世界。

Agent负责：组织整个任务。

例如：

用户：生成本周销售报告。↓Agent↓RAG查制度↓MCP查数据库↓LLM生成报告

因此三者关系可以总结为：

RAG 提供知识，MCP 提供能力，Agent 负责组织整个流程。

总结：RAG 是企业 AI 的知识底座

很多人把 RAG 理解成"Embedding + 向量数据库。"，实际上，它远比这复杂。一个真正可用于生产环境的 RAG，更像是一条完整的数据处理流水线。从文档进入系统开始，到最终生成答案，需要依次经历：

Document Parser↓Chunk↓Embedding↓Vector Database↓Recall↓Rerank↓Prompt↓LLM↓Answer

每一个环节，都可能影响最终回答质量。因此，企业真正需要优化的，从来不是某一个组件，而是整条链路。未来，随着 Agent、Skill、MCP 等技术的发展，RAG 也将逐渐从一个独立能力，演变为 Agent 获取企业知识的重要基础设施。可以说：

如果说大模型决定了 AI 的思考能力，那么 RAG 决定了 AI 是否拥有企业真正需要的知识。

理解 RAG，并不仅仅是理解一种检索技术，更是在理解企业 AI 应用落地过程中最重要的一块基础设施。