在 RAG 中，索引流程中的文档解析你们怎么做的？

标签：AI、大模型、RAG

🏛 业务架构师

文档解析是 RAG 的第一道工序，我们的原则是"按文档类型分流，效果和成本分级"：

常规电子文档（Word/Markdown/HTML）：结构化解析库直接抽取，保留标题层级和表格，成本最低。
PDF 类：区分"原生 PDF"与"扫描件"。原生 PDF 用 PyMuPDF/Unstructured 抽文本；扫描件走 OCR（PaddleOCR）或版面识别（MinerU），重点保住表格和双栏排版——财务报表、技术标书里表格信息占大头，解析丢了表格，后面检索全废。
多模态兜底：2026 年更主流的做法是把复杂页面转图片，直接用多模态大模型（Qwen-VL 类）抽取内容+生成描述，对复杂版面的鲁棒性远超规则解析，成本也在快速下降。
在线知识源（Confluence、飞书文档）：走 API 同步增量解析，避免重复全量处理。

治理动作：解析环节必须保留元数据（来源、时间、版本），并对解析质量做抽检打分，低于阈值的文档退回清洗而不是带病入库。

业务账：解析质量决定 RAG 效果上限。我宁可多花一周调解析流水线，也不愿意后面在检索层反复救火——上游一分工，下游十分功。

🏗 系统架构师

文档解析是 RAG 离线链路的质量地基，我的生产选型按格式分层：

HTML/Markdown：结构化最好的输入，直接保标签层级，走标记感知分块；
PDF（最大坑）：分两类处理——数字原生 PDF 用 PyMuPDF/pdfplumber 抽文本和表格；扫描件走 OCR（版面分析模型如 PaddleOCR/PP-Structure，或 VLM 直接解析）。复杂版面（双栏、跨页表格）2026 年越来越多用视觉模型整页解析，准确率上了一个台阶但成本翻倍，按文档价值分级使用；
Office 文档：Word 走 poi/docx 库保样式语义，Excel 视用途分流——说明书类转 Markdown 表，数据类不进 RAG 而是建 Text-to-SQL 通道；
统一出口：全部归一为"Markdown/JSON + 结构元数据（标题路径、页码、表格标记）"，后面分块、嵌入、溯源只认这一种格式。

架构要点：解析服务无状态化、独立部署（CPU 密集，和 GPU 嵌入服务分开扩缩容）；每个文档记录解析器版本 + 内容 hash，解析规则升级时能精准圈出需要重建的文档子集做增量重跑；解析失败和低质量（乱码率超阈值）要有告警和人工兜底队列。解析质量差一档，后面全链路调优都白费。

💻 全栈开发专家

文档解析我们分级处理，原则是「简单文档用轻量库，复杂版式上重武器」：

数字原生 PDF：PyMuPDF/pdfplumber 提取文本，快且便宜，占 70% 流量。
复杂版式（双栏、图文混排）：MinerU 或 IBM Docling 做版面分析，输出结构化 Markdown，标题、表格、图片位置都保留——这一步对 RAG 质量影响最大，裸文本提取会把表格打碎成乱序字符。
扫描件：先 OCR（PaddleOCR），再做版面还原；模糊件用多模态模型（Qwen-VL）直接「看图转 Markdown」，对印章、手写体效果远超传统 OCR。
Office/HTML：Unstructured 或 mammoth/pandoc 转 Markdown，保留表格与标题层级。
后处理：统一中间格式为 Markdown，做清洗（去页眉页脚水印）、段落重组、表格转 HTML 保留结构。

坑与经验：解析质量一定要抽检——我们做过统计，RAG 坏例里约三成根因在解析而不是检索；建立「文档类型 → 解析器」的路由配置而不是一刀切；解析失败的文档进人工兜底队列，别静默丢弃；图片中的图表要抽出 caption 关联存元数据，否则图表内容检索不到。