前情提要：上一篇我们搭建了完整的 RAG 知识库系统框架。本篇将深入最核心的前置环节——如何把一份 Word、PDF 或者 Markdown 文件，变成大模型可以"看懂"的文本片段。

一、一个被低估的难题

很多人以为 RAG 最难的是向量检索，其实文档解析和分块才是系统的"第一公里"。这里有多少坑？来看一个真实场景：

文件1：Java从入门到精通.pdf（扫描版，100MB）→ Tika提取为空 → UTF-8回退报错文件2：需求文档.docx（含表格、图片）→ 表格文字提取不全文件3：会议纪要.txt（编码GBK）→ 乱码文件4：技术方案.md（含代码块）→ 代码块被打散

如果你的解析引擎不够健壮，任何一个文件都能让系统"崩"给你看。

二、多格式解析：Apache Tika 一统江湖

2.1 为什么选择 Tika？

Tika 内部集成了 POI、PDFBox 等几十种解析器，对外暴露一个统一的 API：

// 不管你是什么格式，一行代码搞定Stringtext=newTika().parseToString(newFile(filePath));

2.2 实战：我们的 DocumentParserService

@ServicepublicclassDocumentParserService {privatefinalTikatika=newTika();/**     * 读取文件文本内容     * 核心思路：Tika主解析 → 文本格式回退 → 优雅报错     */public String readFileContent(String filePath)throws IOException {Pathpath= Path.of(filePath);// 第一层：Tika自动识别并解析try {Stringtext= tika.parseToString(path.toFile());if (text != null && !text.isBlank()) {return text;  // 大多数情况走这里            }            log.warn("Tika 提取文本为空: {}", filePath);        } catch (Exception e) {            log.warn("Tika 解析失败: {} - {}", filePath, e.getMessage());        }// 第二层：纯文本格式UTF-8回退StringfileName= path.getFileName().toString().toLowerCase();if (fileName.endsWith(".txt") || fileName.endsWith(".md")                 || fileName.endsWith(".csv") || fileName.endsWith(".json")) {return Files.readString(path, StandardCharsets.UTF_8);        }// 第三层：二进制格式无法解析 → 友好报错Stringext= getFileExtension(fileName);thrownewIOException("无法从该" + ext.toUpperCase() + "文件中提取文本内容。" +"可能原因：文件是扫描版/图片版，不含可提取的文字。"        );    }}

2.3 三层防护的精妙之处

文件输入    │    ▼第一层：Tika.parseToString()    ├── 成功且有文本 ──▶ 直接返回    ├── 成功但无文本 ──▶ 继续↓    └── 异常 ──▶ 继续↓    │    ▼第二层：纯文本 UTF-8 读取    ├── txt/md/csv/json ──▶ Files.readString()    └── PDF/DOC/二进制 ──▶ 继续↓    │    ▼第三层：明确错误提示    ──▶ "文件是扫描版，无法提取文字"

这个设计避免了一个经典错误：用 Files.readString(path, UTF_8) 直接读 PDF 二进制文件，得到 MalformedInputException: Input length = 3 —— 这正是我们上一篇踩过的坑。

三、文本分块：RAG 系统最重要的超参数

3.1 为什么需要分块？

大模型的 Context Window 是有限的（qwen-plus 默认 8K tokens），你不能把整本书塞进去。但分块也不是越小越好：

3.2 三种经典分块策略

策略A：固定长度切割

// 简单粗暴，但会把句子从中间切断String[] chunks = text.split("(?<=\\G.{" + chunkSize + "})");

策略B：按段落+句子切割（本项目采用）

// 先按段落分，长段落再按句子分String[] paragraphs = text.split("\\n\\s*\\n");for (String para : paragraphs) {if (para.length() > maxSize) {        String[] sentences = para.split("(?<=[。！？；])");// ... 逐句累积    }}

策略C：语义分块

// 用Embedding相似度判断语义边界，效果好但成本高// 每次分块都要调用Embedding API

3.3 实战：我们的 chunkText 算法

public List<String> chunkText(String text, int maxChunkSize, int overlap, int minChunkSize) {    List<String> chunks = newArrayList<>();// 第一步：按段落分割（保留文档结构）    String[] paragraphs = text.split("\\n\\s*\\n");StringBuildercurrent=newStringBuilder();for (String paragraph : paragraphs) {StringcleanPara= paragraph.trim();if (cleanPara.isEmpty()) continue;if (cleanPara.length() > maxChunkSize) {// 第二步：长段落按句子切分            String[] sentences = cleanPara.split("(?<=[。！？；])");for (String sentence : sentences) {if (current.length() + sentence.length() > maxChunkSize) {if (current.length() >= minChunkSize) {                        chunks.add(current.toString().trim());                    }// 第三步：滑动重叠窗口                    current = newStringBuilder(                        current.substring(current.length() - overlap));                }                current.append(sentence.trim());            }        } else {// 短段落直接累积if (current.length() + cleanPara.length() > maxChunkSize) {                chunks.add(current.toString().trim());                current.setLength(0);            }            current.append(cleanPara).append("\n");        }    }// 第四步：收尾处理（过短合并到前一块）if (current.length() >= minChunkSize) {        chunks.add(current.toString().trim());    } elseif (!chunks.isEmpty()) {intlast= chunks.size() - 1;        chunks.set(last, chunks.get(last) + "\n" + current.toString().trim());    }return chunks;}

3.4 重叠窗口（Overlap）的价值

Chunk 1: "...线程池的核心参数包括核心线程数、最大线程数、"                  ┌─── overlap ──┐Chunk 2: "核心线程数、最大线程数、存活时间、工作队列..."

没有 overlap 时，"存活时间"这个信息就丢失了上下文。设置 100 字符的重叠，确保语义连续。

3.5 最小块过滤：来自生产环境的教训

我们在开发中遇到了这个报错：

Zhipu API Error: Input length = 3

原因是一个段落的末尾残留只有 3 个字符（如"你好啊"或"OK。"），智谱 Embedding API 拒绝嵌入过短的文本。

解决方案：增加 minChunkSize 参数，小于阈值的片段合并到前一个 chunk 或丢弃。

四、参数调优指南

五、完整文件处理流程总结

用户上传文件    │    ▼WebConfig ── 文件大小校验（100MB限制）    │    ▼FileService.uploadFile()    ├── 保存到 /uploads/ 目录    ├── 写入 MySQL knowledge_file 表（status=0处理中）    │    ▼DocumentParserService.readFileContent()    ├── Tika解析 ──▶ 提取纯文本    │    ▼DocumentParserService.chunkText()    ├── 按段落分割 ──▶ 长段按句子 ──▶ 重叠窗口 ──▶ 最小块过滤    └── 返回 List<String> chunks    │    ▼VectorStoreService.addDocuments()    ├── 智谱Embedding-2向量化    ├── 存入Redis（向量+内容）    ├── 更新MySQL status=1（成功）    └── 返回chunk数量给前端

六、下一篇预告

文本已经切成小片段了，下一步就是让这些片段"长出翅膀"——变成机器可以理解的向量。下一篇《万物向量：Embedding嵌入与向量存储的深度实践》，我们将揭秘：

• Embedding 到底是什么？通俗版+技术版双解读
• 智谱 Embedding-2 的 API 调用细节
• 为什么用 Redis 而不是 Pinecone/FAISS？
• 1536维向量怎么存、怎么比、怎么找？

代码仓库：完整源码见 SpringAIAlibabaRAG 项目 上一篇：第1篇：从零到一搭建RAG知识库系统 下一篇：第3篇：万物向量——Embedding嵌入与向量存储的深度实践