文档处理全流程!PDF 解析、分块、向量化,打造企业知识库的 “知识底座”

从 MinIO 文件存储到 Weaviate 向量入库，手把手教你实现企业文档的智能化处理

企业知识库的核心是文档，企业的产品手册、会议纪要、工单记录、行业手册等都是核心知识载体。但这些文档大多是 PDF、Word 等非结构化格式，无法直接被大模型和向量数据库识别，必须经过解析、分块、向量化等一系列处理，才能成为 RAG 系统可利用的 “知识底座”。

今天我们就来拆解 sk-knowledge 项目中文档处理的全流程，从MinIO 分布式文件存储到Apache Tika 文档解析，再到Chunking 文本分块、Embedding 向量化，最终将向量数据存入Weaviate 向量数据库，手把手教你实现企业文档的智能化处理，让非结构化文档变成可检索、可问答的智能知识！

一、文档处理核心流程：五步打造智能知识

企业上传的 PDF 文档，需要经过以下 5 个核心步骤，才能成为 RAG 系统的有效知识，整个流程自动化执行，无需人工干预：

上传文档到 MinIO → Apache Tika 解析提取文本 → Chunking 文本分块（语义自适应） → Embedding 模型向量化 → 向量数据存入 Weaviate

这五个步骤环环相扣，每个步骤都有对应的技术选型和优化要点，最终实现 “文档上传，知识可用” 的目标。

二、步骤 1：MinIO 分布式文件存储 —— 企业文档的 “保险柜”

企业上传的文档首先需要安全、高效的存储，我们选择MinIO作为分布式文件存储组件，原因很简单：

✅ 开源免费，兼容 S3 协议，可无缝迁移到云对象存储（如阿里云 OSS、腾讯云 COS）；

✅ 高性能，支持海量文件存储，适配企业知识库的文档增长需求；

✅ 轻量级，Docker 一键部署，无需复杂配置；

✅ 支持文件 MD5 去重，避免重复上传相同文档，节省存储空间。

MinIO 核心实现：

1. 配置 MinIO
   
   在 application.yml 中配置 MinIO 的连接信息、桶名称；
2. 文件上传
   
   实现文件上传方法，计算文件 MD5 去重，生成唯一文件名，上传到 MinIO 并返回文件访问 URL；
3. 文件下载 / 读取
   
   实现文件流读取方法，为后续文档解析提供输入流；
4. 文件删除
   
   当文档被删除时，从 MinIO 中删除对应的文件，保证数据一致性。

核心亮点：文件上传时通过 MD5 计算实现去重，若上传相同文档，直接返回 “已存在”，无需重复存储，大幅节省磁盘空间。

三、步骤 2：Apache Tika 文档解析 —— 非结构化文本的 “提取器”

企业文档以 PDF 为主，包含大量非结构化文本，需要先提取纯文本内容，才能进行后续的分块和向量化。我们选择Apache Tika作为文档解析工具，它是 Apache 基金会的开源项目，支持 PDF、Word、Excel 等多种格式的文档解析，解析精度高，能有效提取文档中的纯文本。

PDF 解析核心代码：

/** * 提取PDF中的纯文本 */public String extractPdfText(InputStream inputStream) {    try {        Tika tika = new Tika();        // 直接解析输入流，返回纯文本        return tika.parseToString(inputStream);    } catch (IOException | TikaException e) {        throw new RuntimeException("PDF解析失败", e);    }}

核心亮点：只需传入文件输入流，即可快速提取纯文本，无需关注 PDF 的内部格式，开发效率高。

四、步骤 3：Chunking 文本分块 —— 语义自适应的 “切割器”

提取的 PDF 纯文本通常是长文本，而大模型的上下文窗口有长度限制，且长文本向量化后语义信息会丢失，因此需要将长文本切割为大小适中、语义完整的短文本块（Chunk），这就是 Chunking 文本分块，也是文档处理中最关键的一步。

我们采用语义自适应分块策略，结合 “语义切分” 和 “固定长度限制”，既保证语义完整性，又适配大模型上下文窗口，核心步骤：

1. 分句
   
   将提取的纯文本按标点符号（。！？；）拆分为独立句子；
2. 向量化句子
   
   将每个句子通过 Embedding 模型生成向量；
3. 计算句子相似度
   
   计算相邻句子的余弦相似度，判断语义是否连贯；
4. 合并句子为 Chunk
   
   将语义相似度高的相邻句子合并为一个 Chunk，若 Chunk 长度超过阈值，则停止合并，保证 Chunk 长度可控；
5. 去重
   
   合并完成后，对 Chunk 进行去重，避免重复内容。

核心亮点：

• 基于余弦相似度的语义自适应分块，不破坏文本的语义完整性，解决了固定长度分块 “切割语义” 的问题；
• 可配置 Chunk 最大长度、相似度阈值，灵活适配不同大模型的上下文窗口。

五、步骤 4：Embedding 模型向量化 —— 文本的 “语义转换器”

将分块后的 Chunk 转换为高维向量，是实现语义检索的核心步骤，我们选择BAAI/bge-m3作为 Embedding 模型，它是一款优秀的开源中文 Embedding 模型，语义表征能力强，适配中文企业文档的向量化需求。

通过Spring AI集成 Embedding 模型，只需简单调用，即可将文本 Chunk 转换为高维向量：

/** * 将句子列表转换为向量列表 */public List<float[]> embed(List<String> sentences) {    return embeddingModel.embed(sentences);}

核心亮点：Spring AI 封装了 Embedding 模型的调用细节，无需手动调用 API，只需注入模型对象，即可实现文本向量化，开发效率高。

六、步骤 5：向量入库 Weaviate—— 语义检索的 “记忆中枢”

将生成的 Chunk 向量与元数据（如知识库 ID、文档来源 URL、Chunk 内容）一起存入Weaviate 向量数据库，为后续的语义检索做准备，核心步骤：

1. 创建 Weaviate Schema
   
   手动创建Knowledge Collection，定义属性（content：文本内容，meta_knowledgeId：知识库 ID，meta_source：文档来源）；
2. 转换为 Document 对象
   
   将 Chunk 内容、元数据转换为 Spring AI 的 Document 对象，包含唯一 ID、文本内容、元数据；
3. 向量入库
   
   通过 Spring AI 的 VectorStore 接口，将 Document 对象存入 Weaviate，自动完成向量存储；
4. 相似度去重
   
   入库前检索 Weaviate，若存在相似度超过阈值的 Chunk，直接跳过，避免重复存储。

核心亮点：

• 入库前进行相似度去重，保证向量数据库中无重复的语义内容，提升检索效率；
• 结合知识库 ID 元数据，实现向量的精准过滤，确保后续检索只返回指定知识库的内容。

七、文档处理的分布式事务保障：Temporal 工作流

文档处理的五个步骤涉及多个组件（MinIO、MySQL、Weaviate），任意一步失败都可能导致数据不一致，比如 “文档上传到 MinIO，但向量未存入 Weaviate”。

为了解决这个分布式事务问题，我们引入Temporal分布式工作流编排框架，将文档处理流程封装为工作流，每个步骤作为一个 Activity，若某个步骤失败，自动执行补偿操作（如删除 MinIO 中的文件、删除 MySQL 中的文档元数据），保证流程的最终一致性，即使服务器崩溃，流程也能恢复续跑。

总结

企业文档的解析、分块、向量化是 RAG 知识库的基础工程，也是打造企业 “知识底座” 的核心环节。通过 MinIO 实现文件安全存储、Apache Tika 实现文本提取、语义自适应 Chunking 实现文本分块、Embedding 模型实现向量化、Weaviate 实现向量存储，再加上 Temporal 保障分布式事务，我们实现了企业文档从 “上传” 到 “智能知识” 的全流程自动化处理。

有了这个 “知识底座”，接下来用户的每一次提问，系统都能通过语义检索从向量数据库中找到相关的知识，再结合大模型生成准确的回答，真正实现企业知识的智能问答！