PDF明明看得懂，RAG为什么把两栏读成了一段？

把一份双栏PDF拖进知识库，系统提示“解析成功”。后来问到左栏的设备规定，AI却把右栏的维修建议接到了后面，还给出一个能打开的原文链接。

这不一定是模型没读懂。有时，它读到的根本不是你眼前那一页，而是一条顺序已经变样的文字流。

本文只解释一个问题：PDF进入RAG——先检索资料、再据此回答——之前，怎样确认“文字提取出来了”没有被误当成“原页意思保住了”？

AI原创概念插画：摊开的立体书左页是青绿河流与银鱼，右页是朱红花藤，前景纸条把两种图案交错排列，旁边有黄铜放大镜。画面只隐喻完整页面与重排片段的区别，不是PDF解析结果或真实实验。

看得见的页面，不等于有顺序的文章Copy Anchor Link

PDF首先需要让内容在页面的适当位置显示。你看到标题在上、两栏在下，会自然地先读完左栏再读右栏；但提取程序面对的可能是文字对象、位置、字体和不同的内部存储顺序，而不是一份已经排好的文章。

PyMuPDF的官方文本提取指南给了一个直观例子：如果页眉、页脚在正文完成后才插入，它们在页面上仍可正确显示，普通文本提取却可能先输出原正文，再输出页眉和页脚。[1] 这说明显示位置与提取次序可以不同，并非每份PDF都会出错，也不意味着任何一种PDF内部顺序都相同。

另一份来源来自W3C的PDF阅读顺序技术说明。它针对带标签PDF与辅助技术，解释了多栏页面可能被错误地跨栏横读，而不是读完第一栏再进入下一栏。[2] 这是无障碍技术材料，不是RAG性能研究；它支持的是阅读顺序会改变内容含义这一结构性事实，不能据此宣称某个解析器的准确率。

因此，“复制粘贴能得到很多文字”“输出文件不是空的”“没有异常退出”，都只是低门槛的运行检查。

一个可以手工跟随的双栏案例Copy Anchor Link

下面的设备说明、提取片段和修复步骤均为虚构教学设计，没有对应真实产品，也没有运行PDF解析器、OCR或模型。

假设原页有两栏：

这里的表只是为了在本文中并排展示两栏，不是要讨论表格单元格识别。两栏各有自己的标题和连续段落。

一种错误的扁平化结果，可能是按同一水平位置穿过两栏：

使用限制 清洁步骤
此型号不可水洗。外壳可用微湿布擦拭。
进水后须断电送检。清洁前必须拔下电源。

字符几乎都还在，段落的归属却弱了。接下来若按固定长度切片，可能得到一块带有“使用限制”的混合材料，把两栏当成同一组连续规则。系统未必一定答错，但它失去了原页提供的分组线索，错误拼接的机会增加了。

再设另一种故障：左栏首句在文本层里少了一个“不”，变成“此型号可水洗”。无论检索命中多准，回答阶段都可能忠实复述错误文本。原PDF链接能打开，也不能替这句话证明正确。

这里必须分开两类检查：

• **顺序检查：**字符是否按正确的栏、段、标题关系进入阅读材料？
• **内容检查：**被提取的字，是否真的对应渲染页上可见的字？

只做其中一项不够。读序正确的错误字符仍然错；字符齐全的乱序段落也可能改变意思。

不要把“按坐标排序”当作万能修复Copy Anchor Link

PyMuPDF指南介绍了带坐标的文字块、单词提取，以及使用sort参数重排输出的方式。[1] 这些是建立阅读顺序的工具，不是“任何页面都已恢复自然阅读”的证书。

比如双栏版面里，只按纵向位置、再按横向位置排列，可能仍把同高度的左右栏交错起来。遇到跨栏标题、旁注、插图说明或跨页段落，需要先识别区域和关系，再决定区域内部及区域之间的顺序。这一判断是本文的工程推断，不是对某个库当前排序实现的完整描述。

更稳妥的验收对象不是“打开了哪个排序开关”，而是实际输出：

1. 先读哪一栏，下一段接到哪里？
2. 标题是属于下方整页，还是只属于一栏？
3. 页眉、页脚、侧边注是否混进正文句子？
4. 段落跨页时，是否被另一个版面区域插断？

对于原生文本清楚、单栏规则的页面，直接提取可能已经足够。复杂版面才需要更细的结构识别与复核；没有必要把所有文档都送入最昂贵的路线。

OCR不是“更高级”的同义词Copy Anchor Link

OCR是从图像识别文字。它能帮助处理扫描页，但“再做一次OCR”与“修复阅读顺序”不是同一件事。

Unstructured的开源分区文档列出了fast、hi_res、ocr_only与自动选择等策略，并说明不同路线对可提取文本、布局识别与OCR有不同依赖、适用条件和回退行为。[3] 同一段文档还明确提醒其hi_res路线在多栏元素排序方面的困难，并对某些无法提取文本的多栏文档给出其他路线建议。

这份动态文档不是所有解析器的通用排名，也没有证明“高分辨率”必然比其他模式差。它更实际地说明：路线的名字不能代替在自己文档上的验收。 环境缺少依赖时，实际执行的路线还可能与请求的路线不同。

在案例里，可以这样逐步排查：

• 如果页面主要是扫描图，普通提取没有得到正文，再比较合适语言配置下的OCR输出与原页。
• 如果正文可选择，却出现错字或缺失关键否定词，先对照该区域的可见页面与提取文本；必要时对可疑区域增加图像识别复核，而不是自动信任已有文本层。
• 如果字对了、栏顺序错了，优先检查布局与读序；换OCR引擎不保证修复区域拼接。
• 如果两条路线结果冲突，保留冲突与原页位置，不能仅因新结果更通顺就覆盖旧证据。

这些是应用层建议，不是本文已经执行的服务测试。OCR也会识错字，视觉模型也可能看错、漏读或错误关联。对安全规定、金额、型号等高风险字段，应该采用与业务风险相符的复核门槛；自动抽检不能保证每个未抽中的页面都正确。

先验收入库，再调检索Copy Anchor Link

一个实用的排查顺序，是沿着证据真正经过的几个形态往回看：

渲染页 → 带位置与读序的提取结果 → 分块文本 → 实际交给回答阶段的材料 → 答案。

对虚构案例，可按以下步骤修复：

1. 在原页确认两栏标题、正文与“不可水洗”的可见字形。
2. 检查提取结果，把左右栏作为不同区域核对；对缺失的“不”记录为内容不一致，而非普通格式差异。
3. 在经过核验的结构中，分别保留“使用限制”和“清洁步骤”的标题与段落顺序。不要把清洁说明擅自改写成允许水洗。
4. 从修正后的解析产物重建受影响的切片；只更换回答提示词，不会改变库中已经损坏的文本。
5. 回查检索结果和最终模型输入，确认仍带着正确标题与关键限制，再检查最终回答和引用。

这组步骤不要求把原页所有像素都送给语言模型。关键是系统能回到原页，定位争议区域，并知道经过了哪一版解析。若连原文件都丢了，纯文本摘要无法可靠地补回“不”字，应明确报告证据缺口，而不是让模型猜。

解析产物至少值得保留：源文件版本或摘要、页索引与页面显示页码的区别、区域定位、原始提取文本、经过哪些修复、解析器与配置版本，以及复核结论。字段怎样命名由系统决定，不是某个标准统一要求。

定位信息也有边界：一个边界框只证明记录了一个区域；不证明框内文字已经识别正确。文件哈希可以帮助辨认文件版本，但不证明文件来源真实或内容事实正确。

一份入库前就能用的检查清单Copy Anchor Link

以下是可复用的建议测试，未作为模型评测执行：

• 样本是否覆盖单栏、双栏、扫描页、混合页、页眉页脚和侧边注，而非只抽第一页？
• 同页是否比较了可见内容、文本字符、栏顺序与标题归属？
• 是否专门检查“不／无／除外”、型号、日期、单位与关键数字，避免只看文字总量？
• 请求路线和实际路线是否一致？依赖缺失、回退、局部失败是否有记录？
• 一份PDF中的不同页面是否允许分开诊断，而非按整份文件“一刀切”？
• 不确定区域是否保留待复核状态，而不是把空白、乱码和冲突默认为不存在？
• 切片是否来自已核验的解析版本，修复后是否更新了受影响索引及相关缓存？
• 引用能否定位到相应页与区域，并与最终回答使用的文本版本对应？
• 清理页眉等重复内容时，是否避免误删正文中真正有意义的重复限制？
• 对外部OCR或视觉服务的使用，是否仍符合资料权限与数据处理范围？

如果要比较解析路线，先用同一批源页和固定的人工核对项做对照，分别观察漏字、读序、标题归属、定位与最终答复。不要只比较提取长度，也不要将某条路线生成的文本反过来当成唯一标准答案。

RAG并不从“向量入库”才开始。把一页变成可检索的证据，本身已经是一段需要验收的工程。模型回答之前，先确认它拿到的文字，仍然是读者看到的那份意思。

来源、日期与阅读范围Copy Anchor Link

本文由AI内容创作者墨笺原创整理。设备说明、混合片段、排查步骤和测试项均为教学设计，未运行PDF解析、OCR、模型、向量库或任何厂商SDK；不报告准确率与性能提升。资料检索截止：2026年10月23日23:57 UTC。以下均为本轮实际阅读的公开资料，未核实独立原始发布日期，亦未锁定相应软件发布版；不把动态页面当成新品公告。

1. PyMuPDF：Text。实际读取普通文本提取、文字块／单词位置与“自然阅读顺序”相关完整章节，包含后插入页眉页脚的例子。支持显示位置与提取次序的区别，不作为本轮库调用或质量测试。
2. W3C WAI：PDF3，Ensuring correct tab and reading order in PDF documents。实际阅读适用范围与Description相关正文，重点核对带标签PDF、多栏阅读及复杂版面限制。本条是WCAG 2.2技术说明中的可选实现技术，不是任意PDF解析器必须遵循的接口规范，也不是RAG效果证据。
3. Unstructured：Partitioning。通过公开HTML补读partition_pdf相关完整策略与回退说明，并核对多栏排序警告。只用于解释路线选择与输出验收的必要性，不将动态文档中的建议推广为所有版本、所有工具的统一结论。