提示词优化再优化模型一换再换从固定chunk到语义动态chunk单一或多路召回粗排、精排、前置后置过滤、混合检索等等策略回头发现只能是垃圾进垃圾出。PDF文档格式设计我们常见的文档格式中DOCX、HTML 和 PDF 是完全不同的三种设计。DOCX内容优先渲染交给应用程序DOCX 本质是一个 ZIP 压缩包解压后得到一系列 XML 文件明确声明内容的语义结构由应用程序决定如何渲染。解析 DOCX 的程序遍历 XML 树语义是显式编码在文件里的解析过程不需要任何空间推断。HTML语义标签 层叠样式内容与表现分离HTML 同样以语义为核心比如h1到h6声明标题层级table/tr/td声明表格结构。CSS 样式是可以完全覆盖元素的视觉表现虽然一个h1可以被渲染成极小的字号但它在语义上依然是一级标题。解析 HTML 是读取标签的问题而非推断视觉关系的问题。PDF渲染优先内容服务于像素PDFPortable Document Format由 Adobe 于 1993 年发布基于 PostScript 的子集演化而来本质是一套页面描述语言Page Description Language。PDF解决的问题是在实现文档的跨平台、跨设备的可移植性确保无论在什么操作系统、什么打印机或屏幕上文档的布局和字体渲染保持一致。PDF 没有段落、没有标题、没有表格这些语义概念。有的只是坐标、字形glyph、线段、颜色以及绘图操作符序列。解析器需要自己去推断这些线段和文字之间的空间关系才能还原出表格结构而这种推断在合并单元格、多级表头的情况下很容易出错。PDF 结构一个 PDF 文件由四个部分构成Header、Body、Cross-Reference Table、Traile。Body是核心由大量COS 对象Carousel Object System组成包括对象类型作用字典Dictionary /Type /Page /MediaBox [...] 描述结构流Stream实际内容数据数组Array页面树、字体列表等字符串String文本内容间接引用Indirect Reference50R表示引用第5号对象xref 表是 PDF 的索引记录每个对象在文件中的字节偏移量。PDF 读取器通过 xref 实现随机访问可以直接跳转到任意对象而无需扫描整个文件。文字内容存储在每个页面的内容流Content Stream中通过操作符序列描述渲染指令。字体、图像等资源通过资源字典Resource Dictionary以间接引用的方式关联到页面。结构性解析难点基于上述格式PDF 解析有几个结构性问题无显式阅读顺序PDF 中的字符对象按渲染顺序存储不是阅读顺序。对于单栏文档两者通常一致。但对于双栏学术论文PDF 生成工具可能先写完左栏所有文字再写右栏也可能按视觉从左到右逐行交替写入取决于生成工具的具体实现。解析器必须基于字符坐标重建阅读顺序对于任意复杂度的多栏布局没啥太好的方案。表格无数据结构PDF 表格是用线段和坐标定位的文字在视觉上模拟出来的。解析器需要检测线段并判断是否构成表格边框根据交点确定单元格边界将字符分配到对应的单元格坐标处理合并单元格内部线段缺失导致边界推断失败。任何一步出错都会导致表格结构崩溃合并单元格是最高频的失败场景。字体编码映射PDF 存储的是字体内部的字形 IDglyph ID而非 Unicode 字符。解析器需要通过字体的 ToUnicode CMapCharacter Map将字形 ID 映射为 Unicode 码位。一般导致映射失败或不完整比如部分 PDF 生成工具不嵌入完整的 ToUnicode 表Type 3 字体允许完全自定义字形形状解析器无法推断其 Unicode 含义复合字体CIDFont的映射关系更复杂文字可能被拆分为单个字形分别渲染字形在字节流中不相邻解析器需要靠坐标推断归属。这类问题的典型表现是提取结果出现乱码、词语内部有异常空格或部分字符缺失。扫描件无文本层基于图像扫描的 PDF 内部没有任何文本流只有光栅图像对象。对这类文档调用文本提取函数返回空结果。必须先对图像做 OCR 将像素还原为字符才能进入正常的解析流程。解析原理从字节流到可读文本常见的 PDF 解析方案可以归纳为三种不同的技术体系。原生文本提取这是最快、资源消耗最低的路线适用于原生 PDF由 Word、LaTeX、Adobe InDesign 等软件直接生成含完整文本层。主要流程PDF 内容流的核心文本操作符序列如下BT % Begin Text object /F1 12 Tf % 选择字体 F1大小 12pt 72 720 Td % 移动到坐标 (72, 720) (Hello, PDF!) Tj % 显示字符串 0 -14 Td % 移动到下一行行距 14pt [(Rag) 20 ( pipeline)] TJ % TJ 操作符允许字形间距调整ET % End Text object解析器逐条读取这些操作符维护一个图形状态机Graphics State Machine追踪当前变换矩阵CTM、当前字体、文字矩阵Text Matrix等状态最终得到每个字符的绝对页面坐标。难点提取出来的是离散的字形点解析器需要将它们重新组合成词、句、段落。PyMuPDF、pdfplumber 等库的核心差异就在于这个聚合算法的实现质量。OCR对于扫描件或图像型 PDF必须先将页面光栅化为图像再用 OCR 引擎识别字符。主要流程Tesseract首先对二值图像做连通分量分析找到字符候选然后用 LSTM 网络对文字行图像做序列到序列的转录。它预设文档是单栏的多栏处理依赖启发式的列分割在复杂布局上表现不稳定。PaddleOCR引入了独立的版面分析模型在识别字符之前先检测文档区域然后对每个区域独立 OCR。。难点•表格识别OCR 引擎识别出文字后还需要额外的表格结构恢复模块才能还原单元格关系•版面分析错误的级联效应一旦区域检测出错该区域内所有文字的阅读顺序都会乱序视觉语言模型VLM视觉模型 将整个页面作为图像输入直接输出结构化文本绕过了坐标提取、字体解码、阅读顺序重建等所有中间步骤。主要流程优势• 自然处理复杂布局多栏、嵌套表格、混排图文• 对合并单元格、跨页表格有理解能力• 直接输出语义结构不需要后处理难点模型会产生幻觉另外就是成本问题当然老生常谈的数据合规和隐私某些时候也是个问题。主流解析方案目前常见的PDF 解析工具可以分为轻量文本提取库PyMuPDF、pdfplumber、pypdf 原生文本提取路线速度极快AI 增强开源框架Docling、MinerU、Marker-PDF 集成布局分析模型面向 RAG 场景收费 API各大云厂商都有提供API 托管服务开箱即用VLM 直接调用GPT-4o、Gemini 2.5、Qwen3-VL 最高理解能力成本最高轻量文本提取库这类工具的基本上都是直接读取 PDF 内容流中的字符坐标按坐标排序后输出文本不做版面分析速度相对来说非常极快但处理能力受制于 PDF 格式本身的局限。我这里使用的是langchain封装的解析器PyMuPDF底层基于 MuPDF 引擎对 PDF 规范的高兼容性说是说MuPDF 的渲染质量接近 Adobe Reader文本提取准确率在格式规整的文档上表现稳定。PyMuPDF4LLM是面向 LLM 场景的扩展在原始提取结果上加了 Markdown 格式化层处理标题层级、列表识别以及基于坐标的简单表格重建。pdfplumber基于 pdfminer.six专注于表格提取在页面上找到所有水平和垂直线段计算交点以交点网格为单元格边界提取文字。对于有清晰边框线的表格效果很好。对于无线框表格靠列间距对齐的纯文本表格或有合并单元格的表格效果很差。https://docs.langchain.com/oss/python/integrations/document_loaders#pdfsAI 增强开源框架这类工具在文本提取的基础上引入了布局分析模型对页面进行区域分类能处理复杂版面问题。DoclingDocling 底层使用 PyMuPDF 做文本提取获取字符坐标中间层用 DocLayNet 布局分析模型将页面划分为标题、段落、表格、图片等语义区域上层用 TableFormer 模型专门处理表格结构恢复。Docling 引入了统一的中间表示DoclingDocument不是纯文本字符串而是一棵完整保留层级结构的文档树每个节点带有类型标签标题/段落/表格/图片、在文档层级中的位置、以及页面坐标。这棵树可以导出为 Markdown、HTML、JSON 或 DocTags 格式这个设计使得下游的分块逻辑可以直接按文档语义结构操作而不是在纯文本上做启发式切割。MinerUMinerU 的架构以 PaddleOCR 作为字符识别引擎配合 PDF-Extract-Kit 布局检测模型在处理中文文档和包含 LaTeX 公式的学术论文上效果比较好。Marker-PDFMarker 是多格式统一入口支持 PDF、DOCX、PPTX、XLSX、EPUB、HTML 以及各种图像格式对需要统一处理异构文档库的场景有便利性优势。商业 API可以直接各大厂的API或者一些垂直领域的API我这里就不再多余分析了。VLM 直接调用VLM 将 PDF 页面光栅化为图像后直接输入多模态模型由模型输出结构化文本。直接就绕过了复杂的坐标提取、字体解码、阅读顺序重建的所有中间步骤对多栏、嵌套表格、合并单元格、手写内容的处理能力是应该是最强的了。场景模型综合最强闭源Gemini 2.5 Pro综合最强开源Qwen2.5-VL-72B、InternVL3文档 OCRGemma 3、LLaMA 3.2 Vision、DeepSeek-OCR轻量部署Phi-4、Pixtral 12B、DeepSeek-VL2中文场景Qwen2.5-VL、GLM-4.5V常见解析问题RAG应用在生产环境中的PDF解析问题主要在解析层和内容层。多栏混排导致阅读顺序错乱问题描述多栏布局是 RAG 解析中影响最大的单一问题。PDF 的物理存储顺序不保证阅读顺序左栏和右栏的文字在内容流中可能交错排列。轻量解析库按存储顺序提取字符不关心区域归属导致左右栏文字被交织拼接形成语义完全断裂的混合文本。正确阅读顺序 [左栏] Introduction [右栏] Abstract [左栏] We propose... [右栏] Recent work...PyMuPDF 默认提取结果部分文档 Introduction Abstract ← 从左栏跳到右栏第一行 We propose... Recent work... ← 又跳回左栏LLM 处理这种交错文本时看到的是两段完全无关内容的混合无法推断语义关系上下文理解质量大幅下降。处理方案按坐标排序是最基础的改善对提取出的文字块按 y 坐标从上到下和 x 坐标从左到右重新排序可以部分解决简单双栏问题但对三栏以上、图文混排或非标准版式可能还是会出问题。最好的解决方案是进行版面分析比如先用布局检测模型DocLayNet 或 PP-StructureV2 等将页面划分为独立的文本区域标记每个区域的类型和阅读顺序然后按区域顺序拼接文字。对于无法通过版面分析解决的极复杂版式杂志排版、广告页面、非标准布局那就得试试VLM了。字体编码缺失导致乱码问题描述当 PDF 生成工具未嵌入完整的 ToUnicode CMap或使用了自定义字体编码时解析器无法将字形 ID 映射回 Unicode 字符输出结果为乱码、方框□□□□或空白。比如使用 Type 3 自定义字体、字体子集嵌入不完整、中文字体 Unicode 映射缺失、文档经过 PDF 优化压缩工具处理后编码表被裁剪。可以用编辑器比如cursor的打开pdf底部可以修改调整编码然后就可以看到下面的内容~PDF 中显示Attention Is All You NeedPyPDF2 提取偛整匯數整數搔搔数搔數处理方案不同解析库对字体编码的处理能力存在差异同一份出现乱码的 PDF换用 PyMuPDFMuPDF 引擎可能正常提取反之亦然。所以有时候可以先试试别的解析器。如果多个解析器都无法正常提取说明可能是字体映射信息在 PDF 层面确实缺失。此时绕过文本层、直接对页面图像做 OCR 是可行的替代方案OCR 从像素识别字符完全不依赖 PDF 内部的字体编码。对于视觉显示正常但文本提取乱码的 PDF最常见的就是字体编码缺失的情况OCR 通常能比较好的解决。极少数情况下例如 Type 3 字体 完全自定义字形形状可能OCR 也无法正确识别那就只能回到文档源头重新生成或寻找原始可编辑版本。跨页内容断裂问题描述物理分页基于纸张尺寸的固定分割与逻辑分段基于语义的可变分割两者天然无法对齐。解析器按页面处理文档时每个页面作为独立单元跨越页面边界的内容被物理截断。跨页类型出现频次可能导致的问题段落跨页常见段落语义断裂上下文不完整句子跨页一般句子在页面边界处被截断语义无法理解表格跨页一般表头在一页数据在下一页行列关系丢失图表与说明跨页一般图片和其对应说明文字被分离列表跨页一般编号或项目符号列表被切断后续条目失去上下文代码块跨页少见代码缩进结构和上下文丢失表格跨页影响比较大比如表头行留在第1页末尾有些复杂的可能注脚都占了很多内容~数据行从第2页开始解析器分别处理两页输出的两段文字都缺乏完整语义。RAG 检索时若只命中其中一段LLM 无法还原行列对应关系。处理方案段落和句子跨页的最常见的方案是分块阶段设置 overlap相邻 chunk 之间保留若干 token 的重叠可以确保跨页处的句子在某个 chunk 中是完整的。另外就是语义分块基于 embedding 检测语义边界后切割效果更好。表格跨页就不能依赖通用的 overlap 方法。可行方案是在解析阶段检测当前页是否以未结束的表格收尾最后一个检测到的结构是表格行但没有表格边框的结束信号并将下一页开头的表格行与当前页合并后再处理。Docling 对这种场景有内置处理逻辑MinerU 同样支持跨页表格连接。版面分析也是解决跨页的比较好的方案。页眉页脚污染索引问题描述页眉页脚在每一页重复出现内容通常是文档标题、公司名称、页码、日期等。比如一份100页的文档相同或高度相似的页眉文字会出现 100次。这些内容一方面会产生大量近似重复的 chunk另外一方面就是不同页的 chunk 因共享相同页眉而向量相似度偏高影响检索的区分能力。处理方案位置过滤和跨页重复检测。因为页眉页脚通常出现在页面顶部和底部固定区所以过滤 y 坐标落在页面顶部 8%这个具体数值具体调试着看看 和底部 8% 区域内的文字块。这个方法对布局规整的文档效果稳定对将页脚放在页面中下部的特殊排版可能过滤不足或过滤过度。跨页重复检测就简单粗暴了。统计每行文字在全文档各页中出现的频率将出现比例超过阈值这个具体数值也得具体调试着看看的行标记为重复内容并过滤。比如可以遍历所有页面的文本以行为单位统计跨页出现频次频次 / 总页数超过阈值的行视为页眉或页脚候选从所有 chunk 中移除。图表信息丢失问题描述纯文本解析对嵌入 PDF 的图片、图表、流程图的处理结果是完全丢失的在提取后不留任何内容相关的引用文字在 RAG 中也就成了空引用。处理方案纯文本提取 OCR 可以恢复图表中的文字内容如表格、标注文字但无法理解图表的视觉语义趋势方向、比较关系、空间布局等等这个时候唯一能解决就只有VLM。先用文本解析构建索引并完成检索一般来说文本内容足以定位相关页面检索到相关页面后将页面光栅化为图像再输入 VLM 进行深度理解最后将文本内容与 VLM 输出结合生成回答。参考文献与脚注处理问题描述参考文献和脚注在 PDF 中的物理位置与其被引用的位置相距较远跟页脚还不一样的解析器按页面顺序处理文档时引用标记比如[1]、上标数字所在的 chunk 和对应的参考文献/脚注内容所在的 chunk 会被分离到向量索引的不同位置。脚注文字要么混入正文末尾要么在页面分割时被截断丢失。比如在法律和金融场景中一般文档脚注常包含免责声明、例外条款丢失这些内容会导致 LLM 基于不完整信息生成误导性回答。处理方案版面分析模型能够区分正文区域和脚注区域Docling 和 MinerU 的输出文档树中脚注作为独立类型节点存在可以选择将脚注内容附加到引用它的正文段落之后或单独存储并在检索时通过元数据关联。对于参考文献完整的处理方案是在索引时解析引用链将[1]对应的参考文献内容嵌入到引用它的 chunk 元数据中检索时一并返回。这个方案在学术论文场景下效果最为明显但实现复杂度高需要先提取完整的参考文献列表并建立引用号到文献内容的映射。稍微简单点的方案是在检索后扩展上下文也就是命中某个引用了[1]的 chunk 后同时返回文档尾部参考文献章节的对应条目由 LLM 综合两段内容生成回答。标题层级在分块后丢失问题描述传统按 token 数固定分块的方式不感知文档层级结构切割结果中每个 chunk 只包含该节的内容文字不携带它在文档层级中的位置信息。无向量 RAG 是否是下一代 RAG文档树的优势了吧处理方案最简单的方法是在分块时为每个 chunk 构建其在文档层级中的完整路径然后作为元数据附加在 chunk 内容前。复杂一点的方法是不按 token 数切割而是按文档的语义边界章节、小节切割确保每个 chunk 对应一个完整的语义单元不跨越标题边界但这需要解析器输出保留层级结构信息。好像也有人使用父子 chunk 策略用小 chunk128-256 token做 embedding 和检索命中后返回其父节点完整小节512-1024 token给 LLM 生成回答。检索基于小 chunk 的语义精度生成基于大 chunk 的上下文完整性两个目标分别优化。结语PDF 解析目前仍然没有完美解的解决方案。格式的设计目的是根本原因PDF 的页面描述语言架构导致语义信息在格式层面缺失解析工具所做的本质上都是在用启发式方法或统计模型还原这些缺失的语义。总体来看如果实际业务场景要求比较高混合解析可能是折中的办法了但是也会带来复杂度上升特别是引入模型还可能带来新的问题。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】