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

RAGRetrieval-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 数据库配置全部内容优点保留文档结构非常适合企业文档。也是目前很多生产系统最常采用的方法。④ 按业务结构切分例如FAQQ ...... A ......一组问答就是一个 Chunk。或者合同 制度 API 文档按照天然业务边界切分。为什么还需要 Overlap很多人发现如果一句话正好被切断怎么办例如Chunk1 ...... 安装完成后 --------- Chunk2 请执行 restart真正答案其实跨越两个 Chunk。怎么办工程实践通常采用Overlap重叠窗口例如Chunk1 1~500 Chunk2 450~950中间50 Token 重复。这样即使语义跨越边界也不会丢失。第三章第二步——Embedding把文本转换成语义向量完成文档分片之后系统仍然无法进行语义检索。因为计算机并不能直接理解“数据库配置”、“日志采集” 这些文字。它真正能够计算的是数字。因此下一步就是Embedding。Embedding 是什么Embedding 可以理解成把文本映射到高维向量空间。例如数据库配置 ↓ Embedding ↓ [0.23 -0.65 0.88 ...... ]最终得到的是几百维甚至几千维的数字。这些数字就是向量Vector。为什么要转换成向量Embedding 的核心目标不是压缩文本。而是表达语义。例如苹果 香蕉 水果经过 Embedding 后它们在向量空间中的距离会比较近。而汽车 数据库 天气距离则更远。也就是说语义越接近向量越接近。这也是语义检索能够成立的根本原因。Embedding 与 Tokenizer 有什么区别很多人容易把两者混淆。实际上Tokenizer负责文字 ↓ TokenEmbedding负责Token ↓ VectorTokenizer 是切分文本。Embedding 是表达语义。两者属于完全不同的阶段。Embedding 模型如何选择企业项目中Embedding 模型不能随便更换。需要考虑中文效果英文效果多语言支持向量维度推理速度成本不同模型得到的向量空间也不同。因此文档向量和问题向量必须来自同一种或兼容Embedding 模型。否则相似度计算将失去意义。第四章第三步——Vector Database让语义检索成为可能完成 Embedding 后每一个 Chunk 都拥有了对应的向量。下一步就是把这些向量保存起来。这里使用的不是 MySQL也不是 Elasticsearch。而是Vector Database向量数据库。为什么不能直接存数据库假设企业已经拥有100 万个 Chunk。每次用户提问都需要计算问题向量 VS 100万个向量如果逐个计算效率将非常低。因此需要一种专门针对高维向量相似度搜索设计的数据库。这就是Vector Database。向量数据库保存什么很多人误认为向量数据库只保存向量。实际上一个 Chunk 往往包含Chunk ↓ 原始文本 ↓ Embedding Vector ↓ 标题 ↓ 来源 ↓ 页码 ↓ 权限标签 ↓ 更新时间因此向量数据库不仅保存Vector。还保存各种 Metadata。常见的向量数据库目前企业最常见的包括MilvusQdrantWeaviatePineconeChroma开发测试FAISS本地检索库不同数据库索引算法、扩展能力、过滤能力、性能特点都略有不同。但目标一致快速找到最相似的向量。为什么向量数据库这么快因为它不会遍历全部数据。而是采用ANNApproximate Nearest Neighbor近似最近邻搜索。例如HNSW、IVF、PQ等索引算法。能够把百万、千万、甚至上亿向量都保持较快检索速度。第五章第四步——Recall从海量知识中快速找到候选答案经过 Chunk、Embedding 和向量化存储之后一个企业知识库已经拥有了成千上万个甚至数百万个知识片段。那么当用户提出问题时系统究竟是如何在如此庞大的知识库中快速找到相关内容的这一步就是Recall召回。Recall 是什么Recall 可以理解成从整个知识库中快速找出可能相关的一批知识片段。例如用户提出如何配置日志采集系统首先会把这个问题送入与文档相同的 Embedding 模型。用户问题 ↓ Embedding ↓ Question Vector随后系统会拿这个问题向量与向量数据库中的所有 Chunk 向量进行相似度计算。最终得到Top50 Candidate ↓ Chunk12 Chunk38 Chunk102 Chunk265 ......这就是 Recall。为什么不是直接取 Top3很多初学者都会产生一个疑问既然最终只需要几个片段为什么不直接检索Top3原因很简单向量检索属于近似匹配。它擅长快但并不一定最准例如用户如何配置日志采集Recall 结果① 日志采集 ② 日志存储 ③ 日志查询 ④ 数据采集 ⑤ 系统监控 ......其中真正答案可能排在第6名。如果直接Top3真正答案就丢失了。因此生产环境通常采用Recall Top30 Top50 Top100先尽可能保证召回率。Recall 更关注找全Recall 阶段最重要的指标不是准确率。而是Recall Rate召回率。也就是说真正相关的数据最好都能够进入候选集合。即使混入一些噪声问题也不大。因为后面还有Rerank。Recall 常见实现方式目前主要包括① Vector Search完全依赖Embedding。优点理解语义能处理同义词不依赖关键词。② Keyword Search例如BM25。完全依赖关键词匹配。优点精准对专有名词效果好。缺点不能理解语义。③ Hybrid Search推荐企业项目目前最常见Vector Search BM25 ↓ Hybrid Recall这样既能理解语义。又能保证关键词命中。因此大部分生产级知识库都会采用混合检索而不是单纯依赖向量搜索。第六章第五步——Rerank从候选内容中精挑细选Recall 已经帮助系统找到了一批候选知识。但是它们真的都适合作为最终答案吗答案是不一定。因此还需要下一步Rerank重排。为什么需要 RerankRecall 更像初筛。例如Top50 ↓ 真正相关 Top5 ↓ 部分噪声 Top45虽然真正答案已经进入候选集合但是排序可能并不理想。例如Top1 日志存储 Top2 日志查询 Top3 监控配置 Top4 日志采集真正答案如果直接交给大模型很可能受到前几个无关 Chunk 的干扰。因此需要重新排序。Rerank 是什么Rerank 可以理解成重新判断问题与候选片段之间真正的相关程度。Recall比较的是Question Vector VS Chunk VectorRerank比较的是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负责连接系统。例如数据库GitHubJira文件系统企业 APIMCP 解决的是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 应用落地过程中最重要的一块基础设施。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】