一份文档上传到知识库后，究竟经历了什么？

从文件解析、OCR、Embedding，到大模型问答的完整链路

引言

我经常遇到这样的问题：

客户已经搭建了知识库，也接入了大模型。上传 Word、TXT 等文字文件后，知识问答似乎能够正常使用；但一旦上传几百页的扫描版 PDF、图片型 PDF、复杂表格或者排版混乱的文档，效果就开始变得不稳定。

有时系统搜索不到明明存在的内容，有时大模型给出的答案与原文不一致，有时文件一直显示“解析中”，还有时同一个问题换一种问法，就完全检索不到结果。

在处理这些问题的过程中，我逐渐发现，自己虽然接触过 OCR、Embedding、向量数据库、RAG、Rerank 等概念，但对整个链路中每一个环节究竟在做什么、彼此之间如何衔接，并没有真正形成一幅完整的图景。

很多时候，我们容易把企业知识库简单理解为：

用户上传文件，大模型读取文件，然后回答问题。

但真实的知识库系统远比这复杂。

一份文件从上传，到最终能够被搜索、被引用、被大模型用于回答问题，中间需要经历文件识别、内容解析、OCR、版面分析、文本清洗、文档切分、向量化、索引构建、权限过滤、检索、重排序和上下文组装等多个环节。

任何一个环节出现问题，最后都可能表现为“大模型回答不好”。

因此，我尝试用这篇文章，把一份文档进入知识库之后所经历的完整流程梳理清楚，也借此建立自己对企业知识库和 RAG 系统的整体认识。

一、企业知识库不是“把文件直接交给大模型”

首先需要明确一个最重要的概念：

大多数企业知识库，并不会把用户上传的所有文件直接塞进大模型，也不会让大模型永久记住这些文件。

原因很简单。

第一，大模型一次能够读取的内容是有限的。

模型可以接收的文字长度通常由“上下文窗口”决定。即使当前一些模型已经支持几十万甚至上百万 Token，一家企业的全部文档依然可能远远超过这个范围。

这里的 Token，可以理解为模型处理文字时使用的最小单位。它不完全等于一个汉字或者一个英文单词，而是模型对文本进行拆分后的基本片段。

第二，每次都把整份文件交给大模型，成本很高。

假设用户上传了一份500页的制度文件，只询问其中一个条款。如果每次提问都把500页内容重新发送给大模型，不仅速度慢，也会产生大量没有必要的模型调用费用。

第三，内容太多反而可能降低回答效果。

大模型并不是读取的内容越多，答案就一定越准确。上下文中如果混入大量无关内容，模型可能找不到重点，甚至把不同章节、不同版本或不同文件的内容混合起来。

因此，企业知识库通常使用一种叫作 RAG 的技术。

RAG 的英文全称是 Retrieval-Augmented Generation，中文一般翻译为“检索增强生成”。

它的核心逻辑是：

先从知识库中检索出与用户问题最相关的少量资料，再把这些资料和问题一起交给大模型，让大模型基于资料生成答案。

也就是说，大模型不是直接管理整个知识库，而是在用户提问时，临时读取检索系统找到的相关内容。

整个系统可以分为两条主要流水线。

第一条是入库流水线：

用户上传文件→ 文件解析→ 提取文字和结构→ 清洗和切分→ 生成向量→ 建立索引

第二条是问答流水线：

用户提出问题→ 理解问题→ 检索相关知识→ 对结果重新排序→ 组装上下文→ 调用大模型→ 返回答案和引用

二、一套完整的知识库通常由哪些部分组成？

很多人提到知识库，第一反应是向量数据库。

但向量数据库只是知识库系统中的一个组件，并不等于整个知识库。

一套完整的企业知识库，通常至少包括以下部分。

1. 原始文件存储

负责保存用户上传的原始文件，例如：

• • Word；
• • PDF；
• • Excel；
• • PPT；
• • 图片；
• • TXT；
• • Markdown；
• • 音频和视频。

常见实现包括 MinIO、Amazon S3 或其他对象存储。

原始文件必须保留，因为后续可能需要：

• • 重新解析；
• • OCR 模型升级后重跑；
• • 用户下载原文；
• • 回答时跳转到原始页面；
• • 审计和追溯。

2. 关系型数据库

通常使用 MySQL 或 PostgreSQL，保存文档的管理信息，例如：

• • 文件名称；
• • 文件ID；
• • 上传者；
• • 所属部门；
• • 所属知识库；
• • 文件版本；
• • 解析状态；
• • 上传时间；
• • 权限；
• • 页数；
• • OCR 状态；
• • 是否已经完成向量化。

这些信息一般称为元数据。

元数据不是文档正文，但它描述了正文的来源、属性和访问条件。

3. 文档解析系统

文档解析系统负责把不同格式的文件转换成机器能够处理的内容。

例如：

• • 从 Word 中提取标题和段落；
• • 从 PDF 中提取文字；
• • 从扫描件中执行 OCR；
• • 从 Excel 中读取工作表和单元格；
• • 从 PPT 中提取每页标题、正文和备注；
• • 从图片中识别文字或生成图片描述。

4. Embedding 模型

Embedding 通常翻译为“嵌入”或“向量化”。

它负责把一段文字转换成一串数字，也就是向量。

例如：

设备应当每季度进行一次维护

经过 Embedding 模型后，可能变成：

[0.018, -0.231, 0.774, 0.126, ...]

这串数字可能有768维、1024维或更高维度。

向量中的每一个数字单独看并没有直观意义，但整串数字共同表示这段文字的语义位置。

语义相似的文字，在向量空间中通常也比较接近。

例如：

设备多久保养一次？

和：

设备应当每季度进行维护。

两句话用词不同，但表达的意思接近，因此它们的向量距离通常也比较近。

5. 向量数据库

向量数据库负责存储这些文字向量，并根据向量距离找到语义相近的内容。

常见产品包括：

• • Milvus；
• • pgvector；
• • Elasticsearch；
• • OpenSearch；
• • Weaviate；
• • Qdrant。

向量数据库解决的是“意思是否相近”的问题，而不只是“文字是否完全一样”。

6. 全文搜索引擎

全文搜索引擎负责传统的关键词搜索。

例如用户搜索：

HT-2026-0082

这是一个合同编号。

向量检索未必能够准确找到它，因为合同编号本身没有丰富的语义。此时 Elasticsearch 等全文搜索引擎更加可靠。

所以成熟的知识库一般不会只使用向量检索，而是把语义检索与关键词检索结合起来。

7. Rerank 模型

Rerank 可以翻译为“重排序”。

检索系统第一次找到的内容只是“可能相关”，排序不一定准确。

Rerank 模型会把用户问题和每个候选片段放在一起，进一步判断哪个片段最能回答问题，然后重新排序。

可以把它理解为：

• • 向量检索负责快速海选；
• • Rerank 负责精细复试。

8. 大语言模型

大语言模型负责：

• • 理解用户问题；
• • 阅读检索到的资料；
• • 综合多个来源；
• • 组织自然语言；
• • 生成最终答案；
• • 添加来源引用；
• • 在资料不足时说明无法确认。

需要强调的是，大模型通常处于链路的最后一段。

它不是文档解析器，也不是数据库，更不是所有知识的永久存储器。

三、第一步：用户上传文件之后，系统先做什么？

用户上传文件后，系统一般不会立即调用大模型。

它首先会创建一条文档记录。

例如：

{  "document_id": "doc_001",  "file_name": "设备维护管理办法.pdf",  "file_type": "pdf",  "size": 38472920,  "uploaded_by": "user_001",  "status": "uploaded"}

随后通常执行以下操作。

1. 校验文件

检查文件是否完整、是否损坏、是否超过大小限制，以及扩展名与实际文件类型是否一致。

文件名叫作 .pdf，并不代表它内部一定是合法 PDF。

2. 计算文件 Hash

Hash 可以理解为文件的数字指纹。

只要文件内容发生变化，它的 Hash 通常也会变化。

通过 Hash 可以判断：

• • 文件是否重复上传；
• • 同一个文件是否已经处理过；
• • 文件传输过程中是否发生损坏；
• • 新旧版本内容是否完全一致。

3. 安全检查

企业环境中还需要检查：

• • 病毒；
• • 恶意脚本；
• • 超大压缩包；
• • 文件解析漏洞；
• • 非法文件类型；
• • 密码保护或加密文件。

4. 保存原始文件

把原始文件保存到对象存储中，并生成唯一访问地址。

5. 创建异步处理任务

几百页 PDF 的 OCR 和向量化可能耗时较长，不能放在普通上传接口中同步执行。

因此，系统通常会立即返回：

文件已上传，正在解析

后台通过 Redis、RabbitMQ、Kafka、Celery 等任务系统继续处理。

这里的“异步”可以理解为：

用户不需要一直保持当前请求连接，后台可以独立完成耗时任务。

四、第二步：识别文件类型和内部内容

文件扩展名只能告诉系统一个大概类型，不能说明文件内部的真实情况。

尤其是 PDF，情况非常复杂。

一份 PDF 可能是：

• • 文字型 PDF；
• • 图片型 PDF；
• • 文字和图片混合型 PDF；
• • 带隐藏 OCR 文字层的扫描 PDF；
• • 文字层乱码的 PDF；
• • 加密 PDF；
• • 双栏论文；
• • 包含复杂表格和公式的 PDF。

因此，系统通常需要进行两层分类。

第一层：文件级分类

判断它属于：

Word、Excel、PPT、PDF、图片、纯文本或其他格式

第二层：内容级分类

判断里面是否存在：

• • 有效文字；
• • 扫描图片；
• • 表格；
• • 公式；
• • 多栏排版；
• • 手写内容；
• • 倾斜页面；
• • 低清晰度图片。

对于 PDF，最好不要只对整份文件判断一次，而应该逐页判断。

因为一份300页的 PDF 完全可能是：

第1—80页：文字型页面第81—160页：扫描页面第161—300页：文字与扫描混合页面

如果整份文件全部执行 OCR，会浪费大量算力，而且 OCR 结果可能还不如原始文字层准确。

五、不同文件是怎样被解析的？

1. Word、TXT、Markdown 和 HTML

这类文件通常可以直接提取文字。

但“提取文字”并不意味着只把所有文字复制出来。

一个好的 Word 解析器还应该识别：

• • 文档标题；
• • 一级、二级和三级标题；
• • 正文段落；
• • 列表；
• • 表格；
• • 图片；
• • 页眉页脚；
• • 批注；
• • 超链接；
• • 脚注。

例如一个 Word 文档可能被转换为：

# 设备维护管理办法## 第一章 总则第一条 为规范设备维护工作……## 第二章 职责### 技术部门职责1. 制定设备维护计划；2. 检查计划执行情况。

转换成 Markdown 的价值在于，它既保留了基本结构，又比 Word 内部复杂的 XML 格式更容易被后续系统处理。

2. 文字型 PDF

文字型 PDF 中包含真正的字符对象。

这意味着系统可以直接读取：

• • 字符内容；
• • 字体；
• • 字号；
• • 坐标；
• • 页面位置。

这种文件一般不需要 OCR。

直接提取通常具有以下优点：

• • 速度快；
• • 准确率高；
• • 成本低；
• • 能够保留文字坐标；
• • 不容易产生错别字。

但 PDF 文字提取也并不总是完美。

PDF 的本质更接近一种“页面绘制格式”，它关心文字画在什么位置，却不一定完整保存人类理解的段落关系。

因此可能出现：

• • 双栏文字顺序混乱；
• • 同一句话被拆成很多行；
• • 表格内容交叉；
• • 页眉页脚混入正文；
• • 字符编码异常；
• • 复制出来的文字顺序错误。

所以，即便是文字型 PDF，也可能需要版面分析。

3. 图片型 PDF

图片型 PDF 看起来是一份文档，但从计算机角度看，每一页只是一张图片。

图片中虽然有人眼可见的文字，但系统无法直接把这些像素当作文字进行 Embedding。

因此必须先执行 OCR。

OCR 的英文全称是 Optical Character Recognition，中文叫作“光学字符识别”。

它的目标是把图片中的文字像素恢复成可编辑、可搜索的字符。

一个典型 OCR 流程通常包含三个步骤。

第一步：文字检测

判断页面上哪些区域包含文字。

模型会输出一个个文字框，例如：

标题框正文框页码框表格单元格框

这一步回答的是：

哪里有文字？

第二步：文字识别

对每个文字框中的图像进行识别，输出具体字符。

这一步回答的是：

这些文字是什么？

第三步：版面分析

仅识别文字还不够。

系统还需要判断：

• • 哪一块是标题；
• • 哪一块是正文；
• • 哪一块是页眉；
• • 哪一块是表格；
• • 阅读顺序是什么；
• • 图片说明属于哪张图片；
• • 双栏页面应该先读左栏还是右栏。

所以，面向企业知识库的文档处理，不应该只做 OCR，还需要进行文档版面理解。

OCR 负责“看清文字”，版面分析负责“理解这些文字在页面中是什么角色”。

4. 混合型 PDF

混合型 PDF 最合理的方式是逐页分流。

例如：

第1页有正常文字层：直接提取第2页没有文字层：执行OCR第3页文字层乱码：执行OCR兜底第4页有正常文字层：直接提取

这种设计可以明显降低计算成本。

它也能减少一种常见问题：

原本 PDF 中的文字完全正确，但系统仍然把整页转成图片重新 OCR，反而把正确文字识别错了。

5. Excel 和 CSV

表格文件不能简单地把每个单元格拼接成一段长文字。

系统应当尽可能保留：

• • 工作表名称；
• • 表头；
• • 行列关系；
• • 合并单元格；
• • 数据类型；
• • 公式；
• • 单元格坐标；
• • 多张表之间的关系。

例如：

可以转换为：

工作表：2026年度预算技术部预算100万元，实际支出82万元。市场部预算150万元，实际支出173万元。

但需要注意，有些表格问题并不适合通过向量检索回答。

例如：

哪个部门超出预算最多？

这类问题需要进行精确计算。

更合理的方式可能是：

大模型理解问题→ 生成SQL或数据查询→ 对表格数据执行计算→ 返回结果

因此，企业知识库通常需要区分：

非结构化文档：使用RAG检索结构化表格：使用SQL或数据分析工具

6. PPT

PPT 解析需要关注：

• • 每页标题；
• • 文本框；
• • 图表；
• • 表格；
• • 图片；
• • 演讲者备注；
• • 页面顺序。

如果图表中包含底层数据，应优先读取图表数据，而不是只截取图表图片做 OCR。

7. 图片

图片也有不同类型。

如果是合同照片、表格截图或扫描件，可以执行 OCR。

如果是设备照片、流程图或现场图片，仅 OCR 不够，还可能需要视觉大模型生成描述。

例如：

图片中是一台编号为A-103的离心泵。铭牌显示额定功率为15kW。设备右侧管道连接位置存在明显锈蚀。

不过，视觉模型生成的描述属于模型推断，不一定完全等于图片中的客观事实。

所以系统必须区分：

• • OCR 直接识别到的文字；
• • 原文件中直接提取的文字；
• • 视觉模型生成的描述。

不能把模型猜测的内容与原始证据混为一谈。

六、为什么需要统一的中间格式？

不同文件使用不同解析器。

Word、PDF、Excel、PPT 和图片的内部结构完全不同。

如果后面的每个模块都分别兼容所有文件格式，系统会非常复杂。

因此，一个常见做法是：

不同文件先通过不同方式解析，再统一转换成内部标准格式。

例如：

{  "document_id": "doc_001",  "title": "设备维护管理办法",  "pages": [    {      "page_number": 1,      "blocks": [        {          "type": "heading",          "level": 1,          "text": "第一章 总则"        },        {          "type": "paragraph",          "text": "第一条 为规范设备维护工作……"        }      ]    }  ]}

一个页面可能包含以下内容块：

• • heading：标题；
• • paragraph：正文段落；
• • list：列表；
• • table：表格；
• • image：图片；
• • caption：图片说明；
• • formula：公式；
• • header：页眉；
• • footer：页脚；
• • footnote：脚注。

一旦转换成统一格式，后面的清洗、切分和向量化模块就不再关心原文件是 Word 还是 PDF。

七、为什么解析完成后还需要文本清洗？

解析得到的文本通常不能直接入库。

尤其是 OCR 文本，可能存在大量噪声。

常见问题包括：

• • 页眉页脚每页重复；
• • 一句话被错误换行；
• • 中文字符之间出现空格；
• • 页码混入正文；
• • OCR 错别字；
• • 表格内容顺序混乱；
• • 多余空格和乱码；
• • 重复页面；
• • 标题层级丢失。

例如原始 OCR 结果可能是：

第三章设 备 管 理第 十 二 条 设备应当定期进行维护。

清洗后应当变为：

第三章 设备管理第十二条 设备应当定期进行维护。

不过，文本清洗也不能过度依赖大模型随意修改。

因为合同编号、金额、设备编号、日期和标准编号等内容，哪怕只改错一个字符，都可能造成严重问题。

对于这些关键字段，系统应当：

• • 保留原始 OCR 结果；
• • 标记 OCR 置信度；
• • 保存页面坐标；
• • 必要时进行人工复核；
• • 避免让生成模型擅自“润色”。

八、Chunk 是什么？为什么文档必须切分？

解析和清洗结束后，系统通常不会把整份文档作为一个整体生成 Embedding。

而是会把文档切成很多小片段。

这些片段通常称为 Chunk。

Chunk 可以理解为：

知识库中用于检索和传递给大模型的最小知识单元。

例如一份300页文档，可能被切成1000到3000个 Chunk。

为什么必须切分？

第一，Embedding 模型有输入长度限制。

第二，如果整个文档只生成一个向量，那么这个向量会混合整本文件中的大量主题，无法准确表示某一个具体条款。

第三，用户提问时只需要其中少量内容，没有必要取回整本文件。

最简单的切分方式是：

每500字切一块

但这种方式可能把一条完整规定从中间切开。

例如：

第十二条 设备发生异常振动时，应当立即停机，并由

下一块：

专业维护人员完成检查后方可重新启动。

如果两个片段分别入库，检索时可能只找到其中一半。

因此，更好的方式是结构化切分：

• • 按章节；
• • 按标题；
• • 按条款；
• • 按段落；
• • 按表格；
• • 按语义边界。

一个 Chunk 可以包含：

文档：设备维护管理办法章节：第三章 设备管理小节：第二节 定期检查第十二条 设备应当每季度进行一次预防性维护。

每个 Chunk 还应保留元数据：

{  "chunk_id": "chunk_00125",  "document_id": "doc_001",  "page_start": 32,  "page_end": 33,  "heading_path": [    "第三章 设备管理",    "第二节 定期检查"  ],  "department": "技术部",  "source_type": "ocr",  "ocr_confidence": 0.96}

这些元数据以后可以用于：

• • 权限过滤；
• • 文件过滤；
• • 页码引用；
• • 版本过滤；
• • 原文跳转；
• • OCR 质量判断。

九、Embedding 究竟在做什么？

Embedding 并不是摘要，也不是把文字翻译成另一种语言。

它做的是把文字映射到一个高维语义空间。

可以把这个空间想象成一张巨大的地图。

在这张地图中：

• • 与设备维护有关的内容聚集在一起；
• • 与财务预算有关的内容聚集在一起；
• • 与人事制度有关的内容聚集在一起。

语义越相近，位置通常越接近。

例如：

设备多久检修一次？

即使文档中没有完全相同的句子，但存在：

设备应当每季度进行预防性维护。

Embedding 模型仍然可能认为二者语义相似。

向量相似度通常通过余弦相似度、点积或欧氏距离等数学方法计算。

对业务人员来说，不必过度关注公式，只需理解：

系统通过比较两段文字向量之间的距离，判断它们的语义是否接近。

Embedding 的质量会直接影响知识库召回。

如果使用的模型不擅长中文、专业术语或长文本，即使文档解析正确，也可能找不到合适内容。

十、为什么不能只使用向量检索？

向量检索擅长语义相似，但并不擅长所有问题。

例如用户搜索：

合同编号 HT-2026-0082

这类编号没有丰富语义。

又例如：

A-103GB/T 190012026年7月21日

如果只依赖向量检索，结果可能不稳定。

因此，生产环境通常采用混合检索，也就是 Hybrid Search。

混合检索一般包括：

1. 向量检索

负责找到“意思相近”的内容。

2. 关键词检索

负责找到精确词语、编号、人名、日期和专有名词。

3. 元数据过滤

负责限定范围，例如：

• • 只查某个部门；
• • 只查某个项目；
• • 只查2026年版本；
• • 只查指定知识库；
• • 只查用户有权限查看的文件。

最终结果可能是几种检索方式的综合得分。

十一、用户提问之后，系统究竟做了什么？

假设用户提出问题：

公司设备多久需要维护一次？

系统通常不会直接把这个问题交给大模型。

第一步：识别用户身份和权限

系统先判断：

• • 用户是谁；
• • 属于哪个部门；
• • 能访问哪些知识库；
• • 能查看哪些密级文件。

企业知识库中的权限控制必须发生在检索阶段。

如果一份文件用户无权查看，就不能先把内容发给大模型，再要求大模型“不要展示”。

因为在内容发送给模型的一刻，权限边界已经被突破。

第二步：理解和改写问题

如果是多轮对话，用户的问题可能依赖上文。

例如：

第一轮：

A-103设备有哪些维护要求？

第二轮：

多久检查一次？

单独搜索“多久检查一次”会非常模糊。

系统需要根据对话上下文，将其改写为：

A-103设备多久检查一次？

这个过程通常叫作 Query Rewrite，也就是查询改写。

第三步：生成问题向量

用户问题也通过 Embedding 模型转换成向量。

然后系统用问题向量在向量数据库中寻找最相似的 Chunk。

第四步：执行混合检索

系统可能同时执行：

• • 向量语义检索；
• • Elasticsearch 关键词检索；
• • 元数据过滤；
• • 文件名检索；
• • 标题检索。

例如先召回50个候选片段。

第五步：Rerank 重排序

向量检索速度很快，但不一定能精确判断哪个片段真正回答了问题。

例如问题是：

设备维护周期是多少？

向量检索可能找到：

• • 设备维护部门职责；
• • 设备维修申请流程；
• • 设备维护周期；
• • 设备采购办法；
• • 设备报废要求。

它们都与“设备”有关，但只有其中一部分真正回答了“周期”。

Rerank 会逐条比较问题和候选内容，把最相关的片段排到前面。

典型流程是：

从百万个Chunk中快速召回50个→ Rerank重新排序→ 选出最相关的5到10个

第六步：组装上下文

系统把最终选中的知识片段，与用户问题一起组成大模型 Prompt。

例如：

你是企业知识库助手。请只依据以下资料回答问题。如果资料中不存在明确答案，请说明无法从知识库确认。回答时必须标注文件名和页码。用户问题：公司设备多久需要维护一次？参考资料1：文件：《设备维护管理办法》页码：第32页内容：设备应当每季度进行一次预防性维护。参考资料2：文件：《设备巡检实施细则》页码：第8页内容：关键生产设备每月进行一次巡检。

这时，系统才真正调用大模型。

十二、大模型在整个链路中负责什么？

大模型的主要任务是：

• • 阅读问题；
• • 阅读检索到的资料；
• • 提取关键结论；
• • 综合多个来源；
• • 处理表达冲突；
• • 组织自然语言；
• • 生成清晰答案；
• • 输出引用。

例如最终答案可能是：

根据《设备维护管理办法》第32页，普通设备应当每季度进行一次预防性维护。对于关键生产设备，还需要按照《设备巡检实施细则》第8页，每月进行一次巡检。

需要注意，大模型并不是答案的原始来源。

原始来源仍然是企业上传的制度、合同、手册、表格和数据库。

在可靠的企业知识库中，应尽量要求大模型：

• • 只依据检索资料回答；
• • 没有资料就说明不知道；
• • 不自行补充未经确认的事实；
• • 给出文件名和页码；
• • 区分不同文件中的冲突内容。

十三、为什么答案必须能够跳转回原文？

企业知识库与普通聊天机器人最大的区别之一，是答案必须能够溯源。

用户不能只看到一个看起来很合理的答案，还需要知道：

• • 答案来自哪个文件；
• • 来自哪一页；
• • 来自哪个章节；
• • 原文具体写了什么；
• • OCR 是否可靠；
• • 文件是否为最新版本。

因此，在文档入库时，每个 Chunk 都应该保存：

• • 文件ID；
• • 文件名；
• • 页码；
• • 章节路径；
• • 页面坐标；
• • 原始文本；
• • OCR 置信度；
• • 文件版本。

这样用户点击引用后，系统可以：

1. 1. 打开原始 PDF；
2. 2. 跳转到对应页；
3. 3. 高亮对应文字区域；
4. 4. 显示原文；
5. 5. 对比大模型回答和原始内容。

对于 Excel，还可以定位到：

工作表：2026年度预算单元格：B12:D15

对于 Word，可以定位到：

第三章 > 第二节 > 第十二条

十四、知识搜索和知识问答并不是一回事

企业知识库通常提供两类能力。

知识搜索

用户输入：

设备维护

系统返回相关文件和段落列表。

这一过程可以不调用大模型，核心是检索和排序。

知识问答

用户输入：

设备多久维护一次？

系统先检索相关资料，再调用大模型综合生成一个直接答案。

所以：

知识搜索 = 检索结果展示知识问答 = 检索 + 大模型生成

对于精确文件查找、编号查询和原文浏览，搜索往往更加可靠。

对于需要综合多个文件、解释规定和生成自然语言答案的场景，问答更加合适。

十五、RAG 和 Agent 又有什么区别？

基础 RAG 通常是一条固定流程：

用户提问→ 检索文档→ 调用大模型→ 返回答案

但有些问题仅靠文档检索无法完成。

例如：

A-103设备下一次应该在什么时候维护？

系统可能需要：

1. 1. 从制度文档中找到维护周期；
2. 2. 从设备管理数据库中找到上次维护日期；
3. 3. 调用日期计算工具；
4. 4. 综合得出下次维护日期。

此时系统不仅要检索知识库，还要查询数据库、调用计算工具，甚至执行多步判断。

这种由大模型自主决定调用哪些工具、按什么顺序完成任务的模式，通常称为 Agent。

可以简单理解为：

RAG：先检索资料，再回答Agent：根据任务自主调用知识库、数据库和工具

十六、一个300页扫描 PDF 的完整生命周期

假设客户上传了一份300页扫描版文件：

《设备运行维护手册.pdf》

入库阶段

系统可能依次执行：

1. 用户上传PDF2. 原文件保存到MinIO3. PostgreSQL创建文档记录4. 后台任务检查PDF结构5. 发现页面没有有效文字层6. 将每一页渲染为图片7. OCR检测页面中的文字区域8. OCR识别中文内容9. 版面模型识别标题、正文和表格10. 删除重复页眉页脚11. 合并被错误断开的段落12. 输出统一Markdown或JSON13. 按章节和条款切成多个Chunk14. 为每个Chunk生成Embedding15. 向量写入向量数据库16. 原文写入全文搜索引擎17. 元数据写入关系型数据库18. 文档状态变为ready

问答阶段

用户提问：

A-103设备出现异常振动后应该怎么处理？

系统可能执行：

1. 获取用户身份和访问权限2. 识别实体“A-103”和“异常振动”3. 改写和扩展检索问题4. 生成问题向量5. 在向量数据库中召回相关段落6. 在全文搜索引擎中精确搜索“A-103”7. 合并检索结果8. 执行权限过滤9. 使用Rerank选出最相关内容10. 将问题和资料组装成Prompt11. 调用大模型生成处理步骤12. 返回答案及第126—128页引用

十七、为什么很多知识库效果不好？

很多时候，用户看到错误答案，会认为是大模型能力不足。

但企业知识库中的大量问题，实际发生在调用大模型之前。

1. OCR 错误

如果原文中的“15kW”被识别成“ISK W”，后续检索和回答都会受影响。

2. 版面顺序错误

双栏文档如果左右栏交叉拼接，大模型拿到的是错误文本。

3. Chunk 切分不合理

完整条款被切成两半，导致检索只能召回部分内容。

4. Embedding 模型不适合

模型不擅长中文或行业术语，语义检索效果就会下降。

5. 只使用向量检索

编号、标准号、合同号和设备号容易漏检。

6. 缺少 Rerank

召回的内容表面相关，但无法真正回答问题。

7. 上下文过多

一次给大模型几十个片段，可能导致重点丢失。

8. 权限过滤不严

无权限内容可能被错误召回，造成数据泄漏。

9. 缺少版本控制

新旧制度同时存在，大模型可能综合出一个并不存在的结论。

10. 缺少引用和溯源

答案即使正确，用户也无法验证。

因此，知识库的最终质量并不只由大模型决定。

它更像一条乘法链路：

文档解析质量× 文本清洗质量× Chunk切分质量× Embedding质量× 检索质量× Rerank质量× 权限控制× Prompt设计× 大模型能力

其中任何一项明显偏低，都会拖累最终效果。

十八、可以用五层架构理解企业知识库

为了更容易形成整体认识，可以把企业知识库分为五层。

第一层：数据接入层

负责接收：

• • Word；
• • PDF；
• • Excel；
• • PPT；
• • 图片；
• • 数据库；
• • 网页；
• • 音视频。

第二层：文档理解层

负责：

• • 文字提取；
• • OCR；
• • 版面分析；
• • 表格解析；
• • 公式识别；
• • 图片理解。

第三层：知识加工层

负责：

• • 文本清洗；
• • 文档结构化；
• • Chunk 切分；
• • Embedding；
• • 索引构建；
• • 版本管理。

第四层：检索编排层

负责：

• • 用户问题理解；
• • 查询改写；
• • 混合检索；
• • 权限过滤；
• • Rerank；
• • 上下文组装。

第五层：大模型应用层

负责：

• • 知识问答；
• • 知识搜索；
• • 文档摘要；
• • 文件对比；
• • 报告生成；
• • Agent 工具调用。

结语

经过完整梳理后，我对企业知识库有了一个更清晰的认识：

企业知识库的本质，并不是把文件直接交给大模型，让大模型把所有内容记住。

真正的过程是：

先把不同类型的文件解析成可检索、可定位、可管理的知识单元；用户提问时，再从这些知识单元中找到最相关且有权限访问的内容，最后将这些内容临时提供给大模型，让大模型据此生成答案。

因此，一套知识库是否好用，不能只看接入了哪个大模型。

模型只是最后负责表达和综合的一环。

前面的文件解析、OCR、版面分析、文本切分、Embedding、检索、重排序、权限控制和版本管理，才是决定知识库质量的基础工程。

对于相关负责人来说，真正需要掌握的，也不只是如何部署一个大模型，而是要理解整条数据链路：

文件如何进入系统→ 内容如何被识别→ 知识如何被切分→ 语义如何被索引→ 问题如何被检索→ 资料如何被筛选→ 大模型如何基于资料回答→ 答案如何回到原始证据

只有把这条链路真正看清楚，面对“为什么搜不到”“为什么答错了”“为什么扫描件效果差”“为什么同一个问题换种说法就失效”等问题时，才能准确定位究竟是哪一个环节出现了问题。

这也是我写下这篇文章的原因。