本章关键词RAG、Document Loader、Parser、Chunking、Embedding、Vector Database、Retriever、Reranker、Context、LLM、企业知识库一、为什么FDE必须掌握RAG在上一章中我们介绍了 AI Engineering 的完整技术体系其中RAG是企业AI应用中非常重要的一层。原因很简单大语言模型本身并不知道企业内部的大量信息。例如企业员工手册产品说明书SOP操作规范WMS操作手册MES生产规范ERP业务流程CRM客户管理制度财务制度售后政策IT运维文档项目实施方案API接口文档数据字典这些内容通常属于企业自己的知识资产。如果直接问LLM“我们公司的库存盘点异常应该怎么处理”模型可能会根据通用知识生成一个看起来合理的答案。但企业真正需要的是根据公司自己的制度 公司自己的业务流程 公司自己的操作规范 当前企业知识库生成答案。这就是RAG解决的问题。二、什么是RAGRAG全称Retrieval-Augmented Generation中文通常称为检索增强生成它的核心思想非常简单先找到相关知识再让LLM根据这些知识生成答案。传统LLM用户问题 ↓ LLM ↓ 答案RAG用户问题 ↓ Query Embedding ↓ 知识库检索 ↓ 相关知识 ↓ LLM ↓ 答案因此可以把RAG理解成给大模型外挂一个企业知识库。三、企业知识库到底是什么很多人第一次做RAG会把“知识库”简单理解成一个向量数据库。实际上这是不准确的。一个完整的企业知识库至少包含因此Vector Database只是知识库的一部分。完整的知识库系统还应该保存原始文档文档版本文档来源文档分类文档权限文档更新时间Chunk内容Chunk元数据Embedding向量文档与Chunk的关系四、RAG完整技术链路一个比较完整的企业RAG架构可以设计成这就是一个企业RAG的基本骨架。五、第一步企业文档接入FDE进入客户现场以后经常会发现企业文档非常混乱。例如/企业知识库 │ ├── 制度/ │ ├── 仓库管理制度.docx │ ├── 盘点制度.pdf │ └── 出入库管理规定.pdf │ ├── SOP/ │ ├── 收货SOP.pdf │ ├── 上架SOP.pdf │ ├── 拣货SOP.pdf │ └── 发货SOP.pdf │ ├── 产品/ │ ├── 产品手册.pdf │ └── 操作说明.docx │ ├── FAQ/ │ └── 常见问题.xlsx │ └── API/ ├── WMS接口文档.md └── ERP接口文档.md因此第一项工作并不是直接调用Embedding。而是先把企业现有知识资产整理出来。六、Document Loader文档加载Document Loader负责把不同格式的文件加载进系统。例如PDF Word Excel PPT TXT Markdown HTML 数据库 网页 API统一进入Document Loader ↓ 统一Document对象可以抽象成Document( content库存盘点是指......, metadata{ source: 盘点管理制度.pdf, department: 仓储部, version: v2.1, updated_at: 2026-08-01 } )这里有一个非常重要的概念Metadata元数据。不要只保存文本。应该同时保存document_id document_name document_type department category version author created_at updated_at permission source page section因为后面的检索权限控制引用版本管理文档删除数据更新都需要这些信息。七、Parser文档解析加载文件只是第一步。下一步需要解析文件内容。例如PDF ↓ 文字 表格 图片 标题 页码WordWord ↓ 标题 正文 表格 列表 图片ExcelExcel ↓ Sheet ↓ Row ↓ Column ↓ 业务数据因此Parser的任务是把复杂文档转换成AI可以理解和处理的结构化文本。八、为什么PDF解析特别重要企业知识库中PDF往往是最常见的数据来源之一。但PDF存在很多问题。例如PDF页面 │ ├── 页眉 ├── 页脚 ├── 标题 ├── 正文 ├── 表格 ├── 图片 ├── OCR文字 └── 页码如果直接提取文本可能变成仓库管理制度 第1页 XXXX公司 XXXX公司 仓库管理制度 ...... 第2页 XXXX公司 XXXX公司 仓库管理员......大量重复内容会影响检索质量。所以需要进行Parser ↓ Cleaning ↓ 结构化文本九、Cleaning文本清洗文本清洗是RAG中经常被忽略的一步。例如原始文本仓库管理制度 仓库管理员负责库存管理。。。。 XXXX有限公司 第 23 页清洗以后仓库管理制度 仓库管理员负责库存管理。常见清洗操作包括删除重复页眉 删除页脚 删除无意义空白 统一换行 统一特殊字符 修复乱码 删除无意义符号 处理OCR错误 去除重复文本但是需要注意清洗不是越干净越好。不能为了清洗而破坏原始语义。例如安全库存 ≤ 100不能被错误处理成安全库存 100否则业务含义就发生了变化。十、Chunking为什么必须切分企业文档通常非常长。例如仓库管理制度.pdf 300页不可能把整个300页文档一次性发送给LLM。因此需要Chunking也就是把长文档切成适合检索和模型理解的小片段。例如原始文档 300页 ↓ Chunk 1 Chunk 2 Chunk 3 Chunk 4 ... Chunk 500十一、Chunk应该切多大这是RAG工程中非常重要的问题。假设Chunk太小可能导致上下文不完整 语义被切断例如Chunk 1 库存盘点分为......Chunk 2盘点任务创建后......两个Chunk分别检索时可能失去上下文。反过来Chunk太大又会导致无关内容增加 Token消耗增加 检索精度下降所以实际项目中需要根据文档类型调整Chunk策略。十二、不同文档应该采用不同Chunk策略例如普通说明文档可以按照标题 ↓ 段落 ↓ 固定长度进行切分。SOP更适合一级标题 ↓ 二级标题 ↓ 步骤保持完整业务流程。例如3. 收货流程 3.1 扫描ASN 3.2 核对SKU 3.3 核对数量 3.4 完成收货最好不要随意把3.1 3.2 3.3 3.4完全拆散。表格则应该尽量保持表头 数据行的完整关系。十三、OverlapChunk之间为什么要重叠实际切分时经常使用Overlap例如Chunk 1 AAAAAAAAAAAAAAAA BBBBBBBB Chunk 2 BBBBBBBB CCCCCCCCCCCCCCCC中间BBBBBBBB就是重叠部分。这样做的目的减少语义被切断的问题。例如上一段 库存盘点发现差异后应首先核对...... 下一段 差异超过规定范围时需要提交......如果完全切断Chunk 1库存盘点发现差异后应首先核对...... Chunk 2差异超过规定范围时需要提交......可能影响检索。适当Overlap可以提高上下文连续性。十四、Embedding把文字变成向量文本不能直接进行传统意义上的向量相似度检索。因此需要Embedding模型。例如“如何处理库存盘点差异”经过Embedding[ 0.12, -0.35, 0.76, 0.18, ... ]也就是文本 ↓ Embedding Model ↓ Vector十五、Embedding到底解决什么问题假设知识库里面存在库存盘点差异处理流程用户问盘点发现库存不一致怎么办虽然两个问题字面上并不完全相同库存盘点差异vs库存不一致但是语义非常接近。Embedding可以把它们映射到相近的向量空间。于是用户问题 ↓ Query Embedding ↓ 向量 ↓ 相似度搜索 ↓ 库存盘点差异处理流程这就是语义检索。十六、Vector Database向量数据库生成Embedding以后需要把向量存储起来。这就是Vector Database的工作。常见选择包括Milvus Qdrant pgvector Weaviate Elasticsearch对于FDE而言不需要一开始就纠结“哪个最好”。更重要的是理解Chunk ↓ Embedding ↓ Vector ↓ Metadata ↓ Vector Database一个Chunk实际上应该类似{ id: chunk_000123, document_id: doc_001, content: 库存盘点发现差异后应首先核对..., embedding: [0.12, -0.35, 0.76], metadata: { document: 仓库盘点制度.pdf, page: 23, department: 仓储部, version: v2.1 } }十七、Retriever开始检索当用户提出问题库存盘点出现差异应该怎么处理首先用户问题 ↓ Query Embedding ↓ Vector Database然后进行相似度搜索。例如Top-K 5返回1. 库存盘点差异处理流程 0.92 2. 库存调整管理制度 0.88 3. 盘点异常处理规范 0.84 4. 库存冻结操作说明 0.78 5. 仓库作业管理制度 0.72这就是Top-K Retrieval十八、为什么Top-K不是越大越好很多初学者会认为Top-K越大 ↓ 找到的信息越多 ↓ 答案应该越准确实际上不一定。如果Top-K 50可能出现相关内容 半相关内容 无关内容 重复内容全部进入LLM。最终可能导致上下文过长 Token增加 成本增加 模型注意力分散 答案质量下降所以RAG优化的重要工作之一就是让检索结果既足够相关又不要携带太多噪声。十九、Reranker进一步提升检索质量Retriever通常负责快速召回而Reranker负责精确排序可以理解成Vector Search ↓ 召回50条 ↓ Reranker ↓ 重新排序 ↓ 最相关的5条例如Retriever 文档A 0.91 文档B 0.89 文档C 0.87 文档D 0.85 文档E 0.83经过Reranker文档C 0.97 文档A 0.95 文档E 0.91 文档B 0.78 文档D 0.61最终C A E进入Context。因此可以形成Vector Search ↓ 快速召回 ↓ Reranker ↓ 精确排序 ↓ 高质量Context二十、Context给LLM准备上下文检索完成后不能简单把几个Chunk直接扔给模型。需要进行Context Assembly例如用户问题 库存盘点出现差异应该怎么处理检索得到知识1 《库存盘点管理制度》第23页 ...... 知识2 《库存调整制度》第8页 ...... 知识3 《盘点异常处理SOP》第12页 ......组合成System Prompt 你是企业仓储管理AI助手。 请根据提供的企业知识回答问题。 如果知识库中没有相关信息不要自行编造。 Context [知识1] ...... [知识2] ...... [知识3] ...... User 库存盘点出现差异应该怎么处理然后交给LLM。二十一、LLM从知识生成答案此时LLM的角色已经发生变化。传统模式LLM ↓ 自己“想”答案RAG模式LLM ↓ 理解用户问题 理解检索到的企业知识 组织答案所以可以把RAG理解为让LLM从“凭记忆回答”变成“根据企业资料回答”。二十二、Answer最终答案最终返回根据《库存盘点管理制度》 当盘点发现库存差异时应按照以下流程处理 1. 核对盘点记录 2. 检查相关出入库单据 3. 核查库存移动记录 4. 确认差异原因 5. 根据审批流程提交库存调整申请。 参考来源 《库存盘点管理制度》第23页 《盘点异常处理SOP》第12页这里特别建议企业RAG一定要支持来源引用。二十三、为什么企业RAG必须支持引用因为企业用户通常不会满足于“AI说应该这么做。”他们更关心“你这个答案从哪里来的”因此应该做到答案 ↓ 来源 ↓ 文档名称 ↓ 章节 ↓ 页码例如 《仓库盘点管理制度》 第23页 第4.2节 《盘点异常处理SOP》 第12页 第3步这就是可追溯性。二十四、完整RAG架构现在把整个过程串起来二十五、FDE实际项目企业WMS知识助手假设FDE进入一家仓储企业。客户提出“我们的仓库员工经常问一些WMS操作问题能不能做一个AI助手”传统方式员工 ↓ 询问主管 ↓ 查看操作手册 ↓ 搜索PDF ↓ 寻找答案AI方式员工 ↓ AI WMS助手 ↓ RAG ↓ WMS操作手册 ↓ SOP ↓ FAQ ↓ 制度 ↓ 答案例如员工问“收货完成以后系统提示库位不足怎么办”RAG问题 ↓ Embedding ↓ 检索WMS知识库 ↓ 找到 《WMS收货SOP》 《库位管理规范》 《异常处理流程》 ↓ Reranker ↓ Context ↓ LLM ↓ 答案最终根据《WMS收货SOP》 当收货完成后出现推荐库位不足时 1. 检查目标库区是否存在可用库位 2. 检查SKU库位策略 3. 检查库位容量 4. 必要时执行库位调整 5. 重新执行上架任务。 参考 《WMS收货SOP》第5.3节 《库位管理规范》第4章这就已经是一个真正具有业务价值的企业AI应用。二十六、RAG最容易失败的地方很多人第一次做RAG会发现Demo看起来很好 ↓ 真正接入企业数据 ↓ 效果突然下降原因通常不在LLM本身。而在RAG链路。1. 文档解析错误例如PDF表格 ↓ 解析失败 ↓ 文本顺序混乱 ↓ Embedding ↓ 检索错误2. Chunk切分不合理例如一个业务流程 ↓ 被切成5个完全独立的Chunk导致上下文丢失。3. Embedding模型不适合业务如果企业是中文业务场景却没有验证Embedding效果语义相似度 ↓ 可能不准确4. Retriever召回错误用户问库存盘点差异结果检索出库存查询 库存报表 库存冻结 库存盘点真正相关内容排名不够靠前。5. Context太长检索了20个Chunk全部发送给LLM。最终噪声增加 ↓ 模型注意力下降 ↓ 答案质量下降6. 文档版本过期企业制度发生变化旧制度 v1.0 新制度 v2.0如果两份都存在于知识库RAG ↓ 同时检索到 ↓ LLM无法确定哪个是最新版本所以文档版本管理非常重要。7. 权限泄漏这是企业RAG非常重要的问题。假设财务人员可以看到财务制度但普通仓库员工不能。如果所有文档都放在一个知识库里用户 ↓ RAG ↓ 搜索全部知识就可能出现越权检索。因此企业RAG必须考虑用户身份 ↓ 角色 ↓ 部门 ↓ 权限 ↓ 允许检索的知识然后再执行Retriever二十七、企业级RAG需要加入权限过滤推荐架构例如{ department: warehouse, role: operator }检索时department warehouse AND permission operator这样才能避免知识库本身正确 但用户不应该看到的问题。二十八、Hybrid Search不要只依赖向量搜索企业场景中经常存在SKU 料号 订单号 设备编号 客户编号 产品型号 API名称 错误代码例如“SKU-10086”这种内容关键词检索可能比纯向量检索更有效。所以企业RAG经常采用Vector Search Keyword Search ↓ Hybrid Search ↓ Reranker也就是语义搜索 关键词搜索。这是从Demo RAG走向企业RAG的重要一步。二十九、RAG Evaluation如何知道效果好不好不能只凭“我感觉答案挺好的。”判断RAG效果。需要建立Evaluation体系。至少应该关注可以建立测试集问题1 → 标准答案 问题2 → 标准答案 问题3 → 标准答案 ... 问题100 → 标准答案然后持续测试。三十、RAG的核心评价指标可以简单建立其中非常重要的是Retrieval Quality有没有找到正确知识Answer Quality最终答案是否正确Groundedness答案是否真的基于检索到的知识Citation Accuracy引用来源是否真的支持答案三十一、FDE应该如何理解RAG对于FDE而言不需要一开始就成为算法专家。更重要的是理解整个工程链路然后能够判断答案不好到底是哪一层出现了问题。这才是真正的FDE能力。三十二、RAG项目的FDE排障思路例如客户说“AI回答经常不准确。”不要直接换模型。应该逐层排查这个思路非常重要。因为RAG问题 ≠ LLM问题。三十三、一个最小可行RAG项目如果FDE要自己动手做一个Demo可以按照下面的路线最终形成企业文档 ↓ RAG ↓ 企业知识助手三十四、FDE的RAG技术栈一个典型的FDE学习型技术栈可以是文档处理 ├── PDF ├── Word ├── Excel ├── Markdown └── HTML AI ├── LLM ├── Embedding └── Reranker RAG ├── Chunking ├── Retriever ├── Hybrid Search └── Context Vector Database ├── Milvus ├── Qdrant └── pgvector Application ├── Python ├── FastAPI └── LangChain / LlamaIndex Deployment ├── Docker ├── Redis └── NginxFDE不需要同时掌握所有技术。建议先理解原理 ↓ 再完成最小Demo ↓ 再连接企业数据 ↓ 再优化检索 ↓ 最后解决生产环境问题三十五、从RAG走向企业AI Agent到这里我们已经完成企业文档 ↓ 知识库 ↓ RAG ↓ 企业知识问答但这还只是企业AI的第一阶段。例如用户 “帮我查询一下SKU-10086的库存。”RAG只能回答根据库存查询操作手册 查询库存需要进入库存管理模块……但用户真正想要的是直接查询SKU-10086 ↓ 调用WMS API ↓ 获取实时库存 ↓ 返回结果这时候就不能只依赖RAG了。需要Tool Calling / Function Calling。进一步RAG Tools LLM ↓ Agent三十六、从“知识回答”到“业务执行”企业AI的发展可以理解成三个阶段第一阶段回答知识用户 ↓ RAG ↓ 企业知识 ↓ 答案解决“应该怎么做”第二阶段查询业务数据用户 ↓ Agent ↓ Tool Calling ↓ WMS / ERP / CRM ↓ 实时数据解决“现在是什么情况”第三阶段执行业务操作用户 ↓ Agent ↓ 权限校验 ↓ Tool Calling ↓ ERP / WMS / CRM ↓ 执行操作 ↓ 结果反馈解决“帮我做这件事情。”这才是真正意义上的AI Agent企业应用。三十七、本章总结RAG不是简单的PDF ↓ 向量数据库 ↓ LLM一个真正可用的企业RAG应该是对于FDE来说最重要的不是背诵这些组件而是能够回答企业的问题到底应该在哪一层解决如果文档解析错了就优化Parser。如果知识被切坏了就优化Chunking。如果检索不到就优化Embedding、Retriever或Hybrid Search。如果召回太多无关内容就增加Reranker。如果答案没有依据就优化Context和Prompt。如果不同用户看到不该看到的知识就解决权限控制。如果答案无法衡量就建立Evaluation。三十八、FDE的RAG能力进阶路线最终可以形成这样一条学习路线最终目标不是“我会搭一个RAG Demo。”而是我能够把企业真实知识接入AI并把AI应用部署到真实业务现场。这才是FDE真正需要掌握的RAG能力。下一篇预告《FDE前沿部署工程师实战教程》08 - Agent实战让AI从“回答问题”走向“执行任务”下一篇将在RAG的基础上继续向前用户 ↓ LLM ↓ Agent ↓ Tool Calling ├── WMS ├── ERP ├── CRM ├── 数据库 ├── API └── 企业内部系统 ↓ 执行任务 ↓ 返回结果重点学习什么是AI AgentAgent与普通Chatbot的区别Function CallingTool CallingTool设计Agent执行循环Agent状态管理多工具调用Agent RAGAgent WMSAgent ERPAgent权限控制Agent安全机制Agent项目实战从这一篇开始FDE将真正从“AI知识应用”进入“AI业务执行”。