普通的文档解析往往只停留在提取纯文本，对于标题层级、段落关系、表格结构和图片内容等更丰富的语义信息，要么丢弃，要么用简单规则粗暴处理。但在构建高质量知识库时，这些被忽略的结构与多模态信息，正是提升检索准确率和答案完整性的关键。本节介绍三种进阶的解析能力，帮助你将原始文档转化为真正“可被理解”的知识单元。
19.2.1 版式理解：从字符流到文档结构
PDF、Word 等格式的文档在计算机内部只是“在某个坐标画某个字符”的指令集合，人类一眼就能看出的标题、正文、列表、页眉页脚，对程序而言却是无差别的字符序列。版式理解的目标，就是重建文档的逻辑结构——这是一级标题、这是它下属的正文段落、这是一个编号列表。
为什么重要？
- 切分更合理：按照章节、小节自然边界切分 chunk，远比按固定字数硬切更能保持语义完整。
- 元数据更丰富：可以为每个 chunk 附上所属的章节标题、层级等信息，在检索时用作过滤条件或加权因子。
- 回答可定位：溯源时能精确到“第 3 章第 2 节”，而不只是“文档某处”。
实用方法
- 基于规则的版式分析
对于排版规范的 PDF，可以利用字体大小、加粗、编号模式等特征。例如：字体大于 16pt 且居中的视为一级标题，14pt 加粗视为二级标题。工具如 pdfplumber 可以提取每个字符的坐标与字体信息，方便编写规则。缺点是通用性差，遇到样式不统一的文档就容易失效。
- 基于模型的版式识别
近年来涌现出专门用于文档结构理解的深度学习模型，比如 LayoutParser（基于 Detectron2 的版面分析模型）、DocTR 中的版面分析模块，以及 Unstructured 库中的 auto 分区策略。这些工具能够自动识别文本块、标题、列表、表格、图片等区域，并输出结构化的 JSON。对于复杂版式的 PDF，推荐优先使用这类模型。
- 直接使用文档原生结构
如果文档本身是带有大纲的 Word 或 Markdown 文件，应尽量从源格式出发解析层级，而不是转为 PDF 再提取。比如用 python-docx 遍历段落样式，识别 Heading 1、Heading 2 等，天然保留结构信息。
实践建议：先用模型工具自动解析，再人工抽检并补充少量规则。版式解析做不到 100% 完美，但大部分场景下，将准确率提升到 95% 以上就能带来显著的检索效果提升。
19.2.2 表格识别：让数据结构可查询
文档中的表格承载着高度结构化的信息，例如产品规格、价格清单、财务报表等。如果只是把表格当作文本流提取，行列关系和表头含义就会完全丢失，形成类似“型号A 199元 型号B 299元”这样难以检索和理解的碎片。
目标：将表格还原为具有行列关系、能保留表头-数据对应关系的结构化形式，例如 Markdown 表格或 JSON 数组。
实用方法
- 直接提取原生表格
对于 Word 文档，python-docx 可以直接读取表格对象，遍历行和单元格，生成 Markdown 表格。对于网页，BeautifulSoup 可以提取 <table> 标签。尽量在源头解决问题，避免进入图像转换环节。
- PDF 表格提取
PDF 中的表格可以分为两类：有边框线和无边框线（仅靠空白对齐）。前者用 pdfplumber 的 extract_table() 效果较好，它通过检测线条交集来定位单元格。后者则需要尝试 camelot（能检测文本对齐形成的隐式表格）或 tabula-py。这些工具都有 flavor 参数可调整，遇到复杂表格时需要交叉尝试。
- 基于视觉模型的表格识别
如果遇到扫描件或图片中的表格，传统方法几乎无能为力，这时候需要借助视觉模型。Table Transformer（由 Microsoft 发布）能够检测表格区域并识别表格结构，搭配 OCR 引擎（如 Tesseract 或 PaddleOCR）可以将图片表格转为结构化数据。一些商用 API（如 Azure Form Recognizer、阿里云文档智能）也提供了端到端的表格识别服务，准确度高，适合大规模处理。
- 表格内容的语义描述
提取出的 Markdown 或 JSON 表格可以直接作为 chunk 保留。还有一种更精细的做法：将表格每一行的关键字段拼接成一句自然语言描述，例如“型号 A 的价格为 199 元，库存 120 件”。这样做的好处是，当用户用口语化的问题（如“哪个型号最便宜？”）检索时，向量相似度更容易匹配。但要注意保留原始表格以备溯源。
经验之谈：不要过分追求提取“完美无缺的表格”。很多业务场景中，能保留关键列和大致对应关系就够了。如果一张表格极其复杂（多层表头、合并单元格），评估是否真的需要全文检索，还是可以将其作为附件单独提供。
19.2.3 图片语义提取：打破模态壁垒
技术文档中的架构图、产品手册中的示意图、医学文献中的病理切片，这些图片信息往往直接支撑着关键结论。但传统文本检索无法触及图片内容，导致相关知识完全沉默。图片语义提取的目的，就是将图片转化为可检索、可被语言模型理解的文本描述。
几个层次与对应方法
- 提取图片中的文字（OCR）
很多图片本身含有文字，如截图、流程图中的标注。使用 OCR 工具（Tesseract、PaddleOCR、EasyOCR）提取这些文字，并作为图片所在 chunk 的附加文本，就能让这些信息进入检索池。注意，OCR 文字往往是零散的词或短语，最好与上下文合并，或附上位置的描述（如“图片说明文字：……”）。
- 生成图片的自然语言描述（Image Captioning）
对于照片、图表等，可以使用多模态模型生成对图片内容的摘要。比如 BLIP-2、LLaVA、GPT-4V（通过 API）都可以接收图片并输出描述。你可以将描述文本与图片附近的正文一起存储。描述的质量取决于模型对领域的适应程度，通用模型对专业图表的描述可能会流于表面，可以尝试在 prompt 中加入领域提示。
- 针对特定图类的专项提取
- 流程图/框图：可以使用专门的图表理解模型（如 DiT 或基于 LayoutLM 的衍生模型）识别图中的元素和连接关系，输出结构化描述。
- 图表（柱状图、折线图等）：DePlot 等模型可以直接将图表图片转换为底层数据表格，再生成文字总结。
- 公式：如果有 LaTeX 公式图片，使用 LaTeX-OCR 将其转回可编辑、可检索的 LaTeX 代码。
- 多模态嵌入（Multi-modal Embedding）
当需要支持以图搜图，或让问题直接与图片内容匹配时，可以使用 CLIP 等模型将图片和文本嵌入到同一个向量空间。这样用户提问时，向量距离可以直接将相关图片片段召回，再配合描述文字供给 LLM 生成回答。这适用于知识库中包含大量设计稿、产品图的场景。
实用建议
- 不要对每一张图片都做全链路处理，成本太高。先根据文档类型判断图片的信息价值：产品手册中的产品图很重要，而段落间的装饰图标则可以忽略。
- 将提取的文字或描述作为 chunk 的元数据或附加字段，而不是单独当成孤立的 chunk。比如一张架构图与其周围的段落组成一个 chunk，图片描述作为该 chunk 的补充文本，这样检索时能提供更完整的上下文。
- 评估投入产出比：如果业务对图片信息的依赖度不高，可以先采用轻量级的 OCR 提取文字，或干脆将图片以链接形式保留在答案中，让用户自行查看。
通过版式理解、表格识别和图片语义提取这三项进阶解析技术，你能将原始文档从“字的集合”升级为“结构清晰、多模态可检索”的知识资产。这直接决定了后续检索召回的质量和答案生成的完整度，是 RAG 系统中不可跳过的重要工程环节。