RAG处理Word与PDF文档：解析、抽取与切片的关键技术

1. 先搞清楚 RAG 处理 Word 和 PDF 到底要解决什么问题

如果你正在搭建本地知识库，或者想让大模型能准确回答你私有文档里的问题，RAG（检索增强生成）处理 Word 和 PDF 的能力就是第一个要跨过去的坎。很多人一上来就急着调模型参数、改检索策略，结果发现效果不稳定——问题往往出在最前面：文件根本没解析干净。

RAG 处理文档不是简单把文件扔进去就行。Word 和 PDF 这类格式背后有复杂的结构：标题层级、表格数据、图片注释、页眉页脚、特殊符号。如果解析阶段只抽出一堆乱序的文本块，后面再好的检索模型也找不准答案。

我一般会先看三件事：

• 这个工具或方案能不能保持原文的逻辑结构？比如章节标题和下属段落是否还能关联上。
• 对表格、公式、代码块这类特殊内容有没有单独处理？直接当成普通文本抽出来，数字和格式全乱套。
• 切片（chunking）的时候是硬切还是按语义切？硬切容易把一句话拆到两个片段里，检索时根本搜不全。

下面我会按实际落地顺序，把文件解析、文本抽取、内容切片这三个环节的关键细节和踩坑点全拆清楚。如果你在搭知识库，这套流程可以直接复用。

2. 文件解析：别让格式差异坑了你的数据质量

2.1 Word 解析：除了正文，这些地方最容易被忽略

Word 文档看起来是文字，但背后有 XML 结构（.docx）或二进制格式（.doc）。直接用文本编辑器打开会看到大量标签和控制符。解析工具选不对，轻则丢格式，重则抽出一堆乱码。

优先选支持结构识别的库
比如用python-docx处理 .docx：

from docx import Document doc = Document("your_file.docx") full_text = [] for paragraph in doc.paragraphs: # 能拿到段落样式，判断是否是标题 style = paragraph.style.name text = paragraph.text.strip() if style.startswith('Heading'): full_text.append(f"# {text}") # 标记标题层级 else: full_text.append(text)

但要注意：python-docx对老版 .doc 不支持，如果环境里还有 .doc 文件，需要先用 LibreOffice 或系统命令转成 .docx。
更稳妥的做法是统一用pandoc做格式转换：

pandoc -s input.doc -o output.docx

转换完再解析，能避免很多编码问题。

表格和图片不能直接跳过
表格里的数据往往是关键信息（比如产品参数、统计指标）。解析时要判断表格位置，把表格内容转成结构化标记，比如：

[TABLE_START] | 产品 | 价格 | 库存 | |------|------|------| | A | 100 | 50 | [TABLE_END]

这样后续切片时，表格能作为一个整体处理，不会拆散。图片虽然无法直接抽文本，但至少要记录位置和标题，否则检索到“如图1所示”时根本找不到对应内容。

2.2 PDF 解析：文本型 vs 扫描型，策略完全不同

PDF 分两种：文本型（能从里面直接复制文字）和扫描型（本质是图片）。很多人卡在 PDF 解析，就是因为没先判断类型。

文本型 PDF：优先用 pdfplumber
pdfplumber能提取文字、表格、位置信息：

import pdfplumber with pdfplumber.open("doc.pdf") as pdf: for page in pdf.pages: text = page.extract_text() tables = page.extract_tables() # 记录文字在页面上的坐标，后续切片可能用到 chars = page.chars

它的优势是能保持文字顺序，对表格解析也比其他库准。但碰到复杂排版（比如多栏、注释框）时，可能抽串行。这时候要结合pdfminer的布局分析，手动调整抽取逻辑。

扫描型 PDF：先 OCR，再按文本型处理
如果pdfplumber抽不出文字，说明是扫描件。用pytesseract做 OCR：

import pytesseract from pdf2image import convert_from_path images = convert_from_path("scanned.pdf") texts = [] for img in images: text = pytesseract.image_to_string(img, lang='chi_sim') # 中文需加语言包 texts.append(text)

OCR 后的问题：

• 排版信息全丢，章节标题和正文可能连成一段。
• 识别准确率依赖图片质量，数字、字母容易错。

所以扫描 PDF 能避免就避免，非要用的話，OCR 后一定要人工抽查校正。

2.3 解析阶段的质量检查清单

文件解析完不要直接进下一步，先跑一遍检查：

• [ ] 文件编码是否统一？（特别是 Windows 和 macOS 换行符差异）
• [ ] 特殊符号（如 →、℃、①）是否正常显示？
• [ ] 表格数据是否完整？数字和单位有没有拆散？
• [ ] 标题层级是否保留？（比如 H1、H2 的标记）
• [ ] 图片、图表是否有占位标记？
• [ ] 页眉页脚、参考文献是否混入正文？

发现问题就回调解析逻辑，不要指望后续环节能补救。

3. 文本抽取：干净的数据是检索准确的前提

解析拿到了带结构的原始数据，但里面有很多“噪音”：多余的空格、换行符、页码标记、重复的页眉页脚。这些不断干净的文本直接切片，会严重干扰检索效果。

3.1 清洗步骤：按顺序处理，别跳步

1. 统一换行和空格
   多个连续换行符合并成一个，全角空格转半角，制表符转空格：

   import re text = re.sub(r'\n+', '\n', text) # 合并多余换行 text = re.sub(r'[ \t]+', ' ', text) # 合并空格

2. 移除页眉页脚和页码
   页眉页脚通常有固定模式，比如“第 X 页”或文件名。用正则匹配移除：

   # 移除类似 "第1页" 的页码 text = re.sub(r'第\s*\d+\s*页', '', text) # 移除连续的数字行（可能是页码） text = re.sub(r'^\d+$', '', text, flags=re.MULTILINE)

3. 修复断行和断词
   PDF 解析经常在行末硬断词，比如“人工智\n能”要拼回“人工智能”。针对中英文分别处理：

   # 中文：连接被断开的词语 text = re.sub(r'(\w)\n(\w)', r'\1\2', text) # 英文：连接行末的连字符 text = re.sub(r'(\w+)-\n(\w+)', r'\1\2', text)

4. 标记保留区域
   代码块、公式、表格这些内容清洗时要跳过，避免破坏结构。可以在解析时先包上特殊标记：

   [CODE_START] def hello(): print("world") [CODE_END]

   清洗正则遇到这些标记就不处理。

3.2 质量验证：抽完的文本能不能直接读？

清洗后的人工检查方法：

• 随机选 3-5 段原文和抽取结果对比，看是否有遗漏或错位。
• 搜索文档中的特定术语（比如产品型号、专业名词），看是否完整保留。
• 检查数字、日期、百分比等关键信息格式是否一致。

如果发现大量乱码或丢内容，退回解析阶段换工具重抽。清洗只能优化，不能救根本性解析失败。

4. 内容切片：怎么切才能让检索更准？

这是 RAG 流程里最容易埋坑的一步。切片（chunking）的目标是让每个片段语义完整，且长度适合模型处理。切不好会出现两种问题：

• 切太碎：一个问题答案跨多个片段，检索只返回一部分。
• 切太大：一个片段包含多个主题，检索精度下降。

4.1 切片策略：按长度切 vs 按语义切

按长度切（固定大小）
最简单的方法，设定一个 token 数（比如 512），超过就切：

from langchain.text_splitter import RecursiveCharacterTextSplitter splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50 # 重叠部分避免断句 ) chunks = splitter.split_text(long_text)

适合技术文档、手册这类结构规整的内容。但碰到对话记录、小说等段落长度差异大的材料，可能切碎完整对话或场景。

按语义切（识别边界）
优先在章节标题、段落结尾、自然停顿处切分：

# 用句号、问号等作为切分点，尽量保证句子完整 splitter = RecursiveCharacterTextSplitter( separators=["\n\n", "。", "！", "？", "\n", " ", ""], chunk_size=500, chunk_overlap=50 )

更进阶的做法是用 NLP 模型判断语义边界（比如 spaCy 的句子分割），但对中文支持不一定稳定，需要测试。

4.2 重叠区设置：不是越大越好

重叠区（overlap）能防止切碎关键信息，但设太大会导致：

• 存储翻倍（相邻片段大量重复）
• 检索时相似片段扎堆，影响排序

一般设 chunk_size 的 10%-20% 足够。比如 500 的长度，重叠 50-100。实际测试时，拿几个典型问题在切片后的数据里搜，看答案是否能完整覆盖。

4.3 结构感知切片：保持上下文关联

对于手册、论文这类强结构文档，切片时要保留层级信息。比如：

[CHUNK 1] # 第二章 安装步骤 ## 2.1 环境准备 需要 Python 3.8+ 和 pip。 [CHUNK 2] ## 2.1 环境准备（续） 建议使用虚拟环境，运行：python -m venv myenv。 ## 2.2 依赖安装 pip install -r requirements.txt

这样即使“环境准备”被切成两段，检索时也能通过标题关联找到全部内容。实现时可以在解析阶段给每个段落打上标题标记，切片时优先在标记边界处切。

4.4 切片质量检查清单

切完片不要直接导入向量数据库，先验证：

• [ ] 随机抽 10 个片段，读一遍是否通顺？
• [ ] 找文档中的长表格，是否被切散？
• [ ] 搜索一个专业术语，是否集中在某个片段？
• [ ] 片段长度分布是否均匀？（突然出现极长或极短的要复查）
• [ ] 重叠区是否避免了断句？

测试方法：用切好的数据搭一个最简检索，问几个你知道答案的问题，看返回的片段是否包含完整信息。

5. 整套流程的落地注意事项

5.1 环境依赖：别在版本兼容上踩坑

Python 库版本冲突是常见问题。比如pdfplumber和pdfminer的兼容性，或者pytesseract需要系统安装 Tesseract。建议用 conda 或虚拟环境隔离，并固定版本：

pdfplumber==0.10.3 python-docx==1.1.0 pytesseract==0.3.10 langchain==0.1.0

首次部署时先跑一个测试文件（最好包含表格、图片、中英文），确认全流程无误再处理批量数据。

5.2 批量处理：做好错误处理和日志

处理成百上千个文件时，难免有个别文件解析失败。不能因为一个文件卡住整个流程。需要：

• 单个文件解析加 try-catch，失败时记录文件名和错误原因，跳过继续。
• 设置超时机制，防止解析大文件时卡死。
• 每处理完一个文件，日志记录解析状态、切片数量、错误信息。

import logging logging.basicConfig(filename='process.log', level=logging.INFO) for file in files: try: # 解析和切片流程 logging.info(f"Success: {file}, chunks: {len(chunks)}") except Exception as e: logging.error(f"Fail: {file}, error: {str(e)}")

5.3 性能优化：大文件怎么处理？

超过 100 页的 PDF 或 Word 文档，解析和切片可能占大量内存。对策：

• 流式处理：PDF 按页解析，不要一次性加载全文。
• 分批次切片：切完一批就先保存或导入数据库，清内存再处理下一批。
• 限制并发：批量处理时控制同时处理的文件数，避免内存爆掉。

5.4 后续衔接：切片数据怎么喂给 RAG？

切片完成后，每个片段要带上元数据供检索使用：

• 来源文件名
• 原始页码或章节号
• 片段在文档中的顺序 ID
• 片段类型（正文、表格、标题等）

这样检索到结果后，不仅能返回文本，还能定位到原文位置，方便核对。

6. 常见问题排查顺序

实际落地时，如果效果不理想，按这个顺序查：

1. 检索结果完全不对
   先检查解析阶段：用原始文档对比解析出的文本，看是否大量错位或丢内容。
   常见原因：PDF 是多栏布局但解析器按单栏抽、Word 有复杂表格没识别。

2. 答案不完整
   重点查切片：找一个问题，手动在切片数据里搜，看答案是否被切到多个片段。
   调整策略：减小切片长度或增大重叠区。

3. 响应慢
   检查向量数据库的索引设置，切片是否太大（超过 1000 token 会影响速度）。
   也可能是解析阶段耗时太长，需要加缓存或预处理。

4. 特定类型内容（公式、代码）检索不到
   解析时是否做了特殊标记？切片时是否保留了这些标记？
   需要单独为代码、公式设计抽取和切片规则。

最后提醒：文档处理是 RAG 的基础设施，一旦定下来改造成本很高。所以前期宁愿多花时间测试各种文档类型，也不要急着上大规模数据。