RAG 处理 Word 与扫描版 PDF 最终优化方案

Table of contents

核心痛点

• Word：标题层级、表格、列表结构极易被打散，导致上下文丢失。
• 扫描版 PDF：OCR 误差 + 版面还原失败（多栏、跨页表格、图文混排）是最大杀手。纯文本提取基本不可用。
• 混合型 PDF：部分页面有文字层，部分页面是扫描图，必须逐页判断，不能整份文件走同一流程。
• 共同瓶颈：解析质量、结构保留、分块策略和引用溯源，往往比单纯更换 embedding 或向量库更影响最终效果。

1. 总体原则与推荐 Pipeline

核心原则

保结构、保页码、保层级、保证据、可追溯。

RAG 处理 Word 与扫描 PDF 的核心不是“抽文字 → 切块 → 塞向量库”，而是要把文档还原成可检索、可引用、可审计的结构化知识单元。

推荐 Pipeline

文档接入
→ 分类识别（Word / 文字 PDF / 扫描 PDF / 混合页）
→ 解析 / OCR + 版面分析
→ 结构化重建（Markdown / JSON）
→ 清洗与元数据增强
→ 结构感知分块（Hierarchical Chunking）
→ 混合索引（向量 + BM25 + 元数据）
→ 检索重排（Rerank）
→ 带引用生成
→ 质量评测闭环

统一目标输出

优先输出以下两类中间格式：

• 高质量 Markdown：保留 # 标题层级、列表、Markdown 表格、图片说明。
• 结构化 JSON：包含元素类型、章节层级、页码、坐标、OCR 置信度、元素顺序等字段。

建议统一将 Word、PDF、扫描件都归一到 Markdown / JSON，再进入后续分块、索引和检索流程。

2. 解析方案：最优先投入

2.1 输入分类处理

2.2 Word 文档处理

推荐工具

• Docling：同时支持 DOCX / PDF，结构化输出能力较强，自托管友好。
• Unstructured：适合将 DOCX 拆成 Title、NarrativeText、ListItem、Table 等元素。
• python-docx：适合轻量场景，可手动保留 Heading、段落、表格结构。
• LlamaParse：适合快速云端验证和复杂文档解析。

关键措施

• 保留标题层级：一级标题、二级标题、三级标题应进入章节路径。
• 保留段落语义：不要把段落全部拼成一坨纯文本。
• 保留列表结构：编号、项目符号、嵌套层级不能丢。
• 保留表格语义：表格转 Markdown 或 HTML，不要拍平成普通文本。
• 处理图片 / 图表：可提取图片后用 VLM 生成 caption，或单独 OCR。
• 清理噪音：页眉页脚、批注、修订标记、重复水印需要按业务规则保留或过滤。

2.3 扫描版 PDF 处理

扫描 PDF 本质是图片，关键在于 页面质量检测、版面分析、OCR、阅读顺序重建和表格结构还原。

推荐处理顺序

按页拆分
→ 页面质量检测
→ 图像预处理
→ 版面区域检测
→ 分区域 OCR
→ 表格结构识别
→ 阅读顺序重建
→ Markdown / JSON 输出
→ 置信度标注

版面分析优先于纯 OCR

扫描 PDF 不应直接整页 OCR 后拼接文本。应先做区域检测：

• 标题
• 正文
• 表格
• 图片
• 页眉页脚
• 脚注
• 多栏区域
• 页码区域

然后按区域 OCR，并重建正确阅读顺序。

推荐工具

图像预处理

OCR 后处理边界

OCR 后处理可使用规则、词典或 LLM 进行纠错，但必须加边界：

• 涉及数字、金额、日期、条款编号时，不允许 LLM 自由改写。
• 必须保留 OCR 原文、纠错后文本和置信度。
• 低置信度内容应进入人工抽检或降权检索。
• 对合同、财报、制度、医疗、法律类文档，纠错策略应更保守。

2.4 表格专项处理：重中之重

表格是文档 RAG 的高风险区域。

禁止做法

• 禁止直接将表格 OCR 成一段线性文本。
• 禁止把表格行列关系拍平。
• 禁止将跨页表格简单拼接而不保留上下文。
• 禁止把复杂表格随意切成多个无标题 chunk。

推荐做法

• 表格输出为 Markdown 表格或 HTML 表格。
• 保留表头、行列关系、合并单元格信息。
• 表格作为独立元素入库。
• 复杂表格可单独建立 Table RAG 或结构化数据库。
• 对跨页表格，记录跨页关系和原始页码。
• 对财报、合同、制度类表格，优先保留原始截图坐标，便于回溯。

2.5 元数据设计

每个 chunk 至少携带以下元数据：

3. 分块策略：决定 RAG 上限

推荐策略：Hierarchical + 结构感知分块

强烈不建议只用固定长度切分。推荐采用父子分块：

1. 先按标题层级切 Parent chunk，保留完整章节上下文。
2. 再对子内容做语义分块或适度固定长度切分，形成 Child chunk。
3. 检索时用 Child chunk 精准召回。
4. 生成时带出 Parent chunk 或章节上下文，避免上下文不足。

不同文档类型的分块方式

参数建议

原子性原则

以下内容尽量保持完整，不要硬切：

• 表格
• 条款
• 清单
• FAQ 问答对
• 图片说明
• 公式说明
• 财务指标解释
• 合同定义条款

4. 索引与检索

4.1 不建议只用向量检索

文档 RAG 应采用混合检索：

向量检索 + BM25 / 关键词检索 + 元数据过滤 + Reranker

各检索方式作用

推荐组件

检索策略建议

• 先通过元数据过滤权限、版本、文档范围。
• 向量检索和 BM25 并行召回。
• 合并候选 chunk 后去重。
• 使用 reranker 重排。
• 返回 top 3–8 个高质量上下文。
• 对低 OCR 置信度 chunk 降权或标记提醒。
• 对表格类问题优先召回表格 chunk。

5. 答案生成策略

生成阶段必须控制幻觉和引用质量。

强制约束

• 只能基于检索内容回答。
• 每个关键结论必须附带来源。
• 信息不足时明确回复：“文档中未找到明确说明”或“不足以判断”。
• 涉及数字、金额、日期、条款时逐条引用。
• 不允许凭常识补全。
• 对 OCR 低置信度内容，应提示“不确定”或要求人工确认。

推荐 Prompt 骨架

你是文档问答助手。只能依据提供的上下文回答。
每个关键结论必须附带来源：文件名 + 页码 / 章节。
如果上下文没有明确依据，回答“文档中未找到明确说明”。
涉及数字、日期、金额、条款编号时必须逐条引用来源。
不得凭常识或外部知识补全答案。

引用格式建议

结论：xxx。
来源：文件《xxx.docx》，第 3 页，章节「2.1 项目范围」，chunk_id=abc123。

或：

- xxx：依据《合同扫描件.pdf》第 12 页「付款条款」。
- xxx：依据《制度说明.docx》章节「3.2 审批流程」。

6. 质量评测与常见坑点

6.1 关键评测指标

解析质量：最高优先级

检索质量

生成质量

6.2 常见坑点与应对

7. 工程落地建议

7.1 最小可用版本：快速验证

Word 为主

Docling / Unstructured / python-docx
→ Markdown / JSON
→ Hierarchical Chunking
→ BGE-M3 / Qwen Embedding
→ 向量检索 + BM25
→ Reranker
→ 带引用生成

扫描 PDF 为主

PaddleOCR PP-Structure / Docling / MinerU
→ Layout + OCR
→ Markdown / JSON
→ OCR 置信度标注
→ Hierarchical Chunking
→ 混合检索 + Reranker
→ 带引用生成

快速云端验证

LlamaParse / Azure Document Intelligence / Google Document AI / AWS Textract
→ Markdown / JSON
→ LlamaIndex / LangChain
→ 混合检索
→ 带引用生成

企业私有化部署

PaddleOCR / Docling / MinerU 自托管
→ Milvus / Qdrant / Elasticsearch
→ BGE-M3 / Qwen Embedding
→ BGE-reranker
→ 权限过滤 + 引用溯源

7.2 推荐增强版本

• 文档解析服务化。
• OCR 置信度标注。
• 低置信度页面人工校验入口。
• 表格单独入库。
• 图片使用 VLM 生成 caption 后文本化。
• 高价值图片 / 图表直接走多模态 RAG。
• 父子 chunk 检索。
• 答案引用可点击回原文。
• 定期使用 RAGAS 或自建指标做回归测试。
• 建立解析失败、OCR 低置信度、表格异常的异常队列。

7.3 生产级必须考虑

8. 选型建议

9. 趋势提示

复杂、高价值、图文混排文档正在逐步从传统 OCR + Layout + 规则拼接 转向 VLM 端到端文档理解。

但在生产系统中，VLM 方案仍需要注意：

• 成本较高。
• 时延较高。
• 输出稳定性需要评测。
• 对数字、金额、日期仍需严格校验。
• 关键结论必须可追溯到原文页面或区域。

因此，短期更稳的方案通常是：

传统 OCR / Layout 负责结构化提取
+ VLM 负责图片、图表、复杂页面理解
+ 规则 / 评测 / 引用机制保证可信度

一句话总结

Word 走结构化解析，保留标题层级、段落、列表和表格语义；扫描 PDF 先做页面质量检测和版面分析，再分区域 OCR，表格单独结构化处理；两者统一输出带丰富元数据的 Markdown / JSON，再做 Hierarchical 分块、混合检索、rerank 和强制 traceable 生成。解析质量、结构保留、分块策略、表格处理、引用溯源和评测闭环，是决定最终效果的核心。