企业官网建设流程全解析

本章关键词：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解决的问题。

二、什么是RAG？

RAG全称：

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 ↓ 文字 表格 图片 标题 页码

Word：

Word ↓ 标题 正文 表格 列表 图片

Excel：

Excel ↓ 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

完全拆散。

表格

则应该尽量保持：

表头 + 数据行

的完整关系。

十三、Overlap：Chunk之间为什么要重叠？

实际切分时经常使用：

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 └── Nginx

FDE不需要同时掌握所有技术。

建议：

先理解原理 ↓ 再完成最小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 Agent

• Agent与普通Chatbot的区别

• Function Calling

• Tool Calling

• Tool设计

• Agent执行循环

• Agent状态管理

• 多工具调用

• Agent + RAG

• Agent + WMS

• Agent + ERP

• Agent权限控制

• Agent安全机制

• Agent项目实战

从这一篇开始，FDE将真正从“AI知识应用”进入“AI业务执行”。