1. 为什么 bbox 能治多栏排版和水印 PDF 的“病”
先交代一下背景。我在给 RAG 知识库做文档解析时，最头疼的输入不是那种干净的单栏 PDF，而是两类“刺头”：一类是学术论文、财报、报纸截图导出的多栏排版 PDF，一类是带各种水印的扫描件或网上下载的资料。这两类文件如果直接用 pdfplumber 或 PyMuPDF 按默认顺序抽取文本，抽出来的结果基本没法看——多栏文件会把左栏和右栏的文字交错混在一起，水印 PDF 会把“机密”“内部资料”“仅供学习”这种水印文字当成正文一并入库。等检索阶段一查，命中的 chunk 可能是一段被拦腰截断的句子，或者一条没头没尾的水印文本。整个 RAG 管线的召回质量直接从 90 分掉到 60 分，而且你还很难定位问题出在哪一步。
解决这个问题的关键，就是标题里的 bbox（bounding box，边界框）。说白了，bbox 就是每个文字块、每个单词、每张图片在页面上的坐标位置，通常用(x0, y0, x1, y1)四个值表示。有了坐标，我们就可以回答三个灵魂问题：这段文字在页面的什么位置？它和旁边的文字是同一栏还是跨栏？它到底属于正文、页眉、页脚，还是水印？这三个问题回答清楚，多栏排版和水印 PDF 的解析问题就解决了一大半。
这篇文章是我“RAG 文档解析”系列的第三篇，前面的内容分别讲了整体解析管线的搭建和文本清洗，这篇专门聚焦 bbox 实战。我会把多栏排版怎么分栏、水印怎么识别和剔除，从思路到代码再到踩坑记录完整过一遍。适合正在搭 RAG 知识库、被文档解析质量折磨的工程师和数据爱好者参考，哪怕你之前没接触过 bbox 概念，跟着实操一遍也能上手。
在继续往下读之前，先建立一个基本认知：文档解析本质上不是“读文字”，而是“还原版式”。人类阅读纸质文档时，眼睛会自动根据版面布局决定阅读顺序，但机器没有这个能力。如果不在解析阶段显式地利用版面信息，任何 PDF 抽取工具给出的都只是“文本流”，而不是“人类理解的文本顺序”。bbox 的价值，就是让我们能把机器看到的“文本流”重新组织成符合人类阅读习惯的“文本块序列”。
2. 前置准备：拿到可靠的 bbox 信息
2.1 三种获取 bbox 的途径
bbox 数据从哪来？取决于 PDF 的类型。我实际工作中通常把它分成三种情况：
第一，原生文本型 PDF。也就是文字还能被鼠标选中的 PDF。这种情况下不需要 OCR，直接用 PyMuPDF（fitz）或者 pdfplumber 就能拿到每个字符、单词、行、块的精确坐标。PyMuPDF 的速度比 pdfplumber 快不少，处理几百页的文档也不觉得卡，我主力用 PyMuPDF，pdfplumber 用来做交叉验证。
第二，扫描图片型 PDF。页面本质上是图片，没有文本层，必须先走 OCR。PaddleOCR 是我用得最多的工具，它返回的识别结果里每一行都带一个四边形的四点坐标，左上、右上、右下、左下，转换成 bbox 就是x0 = min(x坐标),y0 = min(y坐标),x1 = max(x坐标),y1 = max(y坐标)。这一步是 OCR 的标配能力，几乎所有主流 OCR 都支持。
第三，带文本层但排版混乱的 PDF。比如从某些网站导出的电子书，有文本层但 Tagged PDF 结构缺失，或者文本层的顺序是乱的。这种情况我一般先尝试直接用 PyMuPDF 抽取，再用 bbox 重新排序。如果文本层本身就是乱序的（比如一段话被拆成几十个碎片随机存放），那就要考虑对页面渲染成图片再做 OCR，用 OCR 结果里的 bbox 重建阅读顺序。
我这里有一个执行顺序上的建议：能不开 OCR 就不开 OCR。OCR 不仅慢，还会引入识别错误，而且对公式、代码、特殊字符的识别能力参差不齐。PDF 有原生文本层时，直接抽坐标是又快又准的方案。但是要注意，原生文本层的坐标也是“从 PDF 内部结构读取的坐标”，并不保证是合理的阅读顺序，所以即使有文本层，分栏和水印过滤的逻辑依然需要。
2.2 最小实战环境准备
我这里用一个最小实验环境来演示，避免依赖太多库导致大家复现困难：
pip install pymupdf pdfplumber paddleocr paddlepaddle scikit-learn numpy如果你的机器装 PaddlePaddle 比较麻烦，可以用paddleocr的 CPU 版本，识别速度会慢一点，但处理少量调试页面完全够用。还有一个更轻量的替代方案是用rapidocr_onnxruntime，它基于 ONNX Runtime，不需要安装 PaddlePaddle 全家桶，对 CPU 环境更友好，我这里演示以 PaddleOCR 为主，但思路在 RapidOCR 上完全一致。
另外，如果你处理的 PDF 本身是带文本层的，那只需要pymupdf就够了，OCR 相关的依赖可以不装。
2.3 PyMuPDF 输出的 bbox 数据结构
用 PyMuPDF 抽取单词级坐标非常简单：
import fitz doc = fitz.open("sample.pdf") page = doc[0] # 获取页面尺寸，单位是 point（1/72 英寸） page_width = page.rect.width page_height = page.rect.height # 抽取所有单词，每个元素包含： # (x0, y0, x1, y1, word, block_no, line_no, word_no) words = page.get_text("words") print(len(words)) print(words[:5])输出大概是这样的：
[(72.0, 106.5, 89.3, 119.2, 'Abstract', 0, 0, 0), (90.1, 106.5, 155.7, 119.2, '—', 0, 0, 1), (156.5, 106.5, 178.9, 119.2, 'This', 0, 1, 0), ...]每个 tuple 的前四个值是 bbox，第五个是单词文本，最后三个是块号、行号、词号。这个数据对我们有用吗？有用，但 block_no 和 line_no 是 PyMuPDF 自己根据 PDF 内部结构算出来的，在多栏排版时往往不符合人类阅读顺序。所以我们的原则是：block_no、line_no 只能当辅助参考，真正的排序依据是 bbox 坐标本身。
再补充一个重要概念：PyMuPDF 的坐标单位是 point，和 PDF 内部坐标一致。如果你渲染成图片再 OCR，得到的 bbox 单位是像素。两种单位不一致，但逻辑一致，换算关系是像素 = point × 渲染分辨率 / 72。调试多栏排版时，我建议统一用 point 坐标系，这样不容易搞混。
3. 多栏排版实战：把两栏 PDF 还原成正确阅读顺序
3.1 分栏的核心思路：聚类而不是画中线
多栏排版最大的问题是什么？两栏文字从上到下、从左到右交叉排列。如果你直接按 y 坐标从上到下排序取文本，你会得到左栏第一行、右栏第一行、左栏第二行、右栏第二行……读起来像两段文字被做了拉链拼接，语义完全断裂。RAG 切块时如果正好切在这个“拉链区”，检索效果会非常差。
最常见的分栏做法是：以页面宽度中线为界，左边归左栏，右边归右栏。这个方案对“严格两栏等宽排版”有效，但遇到不等宽栏位、三栏混排、或者页面中有一个跨栏标题时就会翻车。比如论文首页经常是标题和作者信息横跨两栏，然后正文才分成两栏，如果一刀切按中线分，标题文字会被切成左半句和右半句。
所以我的做法是：用聚类算法按文字块中心点的 x 坐标来分栏，而不是机械地画中线。思路是这样的：
- 把页面里的所有文本块或单词收集起来，计算每个文本块中心点的
x_center = (x0 + x1) / 2。 - 把这些中心点作为一维样本，做聚类（比如用 scikit-learn 的 KMeans，簇数设为 2 或根据页面宽度自动判断）。
- 聚类完成后，每个文本块会得到一个“栏标签”，然后按“栏标签 + y 坐标”排序输出。
我用一个简化版的代码演示：
import numpy as np from sklearn.cluster import KMeans def group_columns(words, max_columns=2): """ 根据单词的 x 中心点坐标做聚类，给每个单词分配栏号。 words: PyMuPDF 的 get_text("words") 输出 返回：words + 栏号列表 """ if not words: return [], [] centers_x = np.array([(w[0] + w[2]) / 2.0 for w in words]).reshape(-1, 1) # 如果所有词都挤在页面一小块区域，直接判定为单栏 x_std = centers_x.std() if x_std < 50: # 阈值需要根据实际情况调整 labels = [0] * len(words) return words, labels n_clusters = min(max_columns, len(set(np.round(centers_x.flatten() / 20)))) if n_clusters < 2: labels = [0] * len(words) return words, labels km = KMeans(n_clusters=n_clusters, n_init=10, random_state=42) labels = km.fit_predict(centers_x) # 把栏号按左侧坐标排序，保证左边是第0栏，右边是第1栏 cluster_x0 = {} for idx, label in enumerate(labels): cluster_x0.setdefault(label, []).append(words[idx][0]) sorted_labels = sorted(cluster_x0.keys(), key=lambda lbl: min(cluster_x0[lbl])) label_map = {old: new for new, old in enumerate(sorted_labels)} labels = [label_map[l] for l in labels] return words, labels然后按栏分组、组内按 y 排序：
def reorder_by_columns(words, labels): columns = {} for w, label in zip(words, labels): columns.setdefault(label, []).append(w) ordered = [] for label in sorted(columns.keys()): col_words = sorted(columns[label], key=lambda w: (w[1], w[0])) # 按行聚合（y 坐标相近的视为同一行） lines = merge_words_into_lines(col_words) ordered.extend(lines) return orderedmerge_words_into_lines的作用是把同一行的单词合并成句子，不能直接按单词排序输出，否则一个句子被单词级拆散。合并逻辑是基于 y 坐标的相近性：如果两个单词的 y 中心点差小于某个阈值（比如 12pt），就认为是同一行。
3.2 跨栏标题和特殊元素的处理
聚类分栏解决了大部分问题，但还有一个隐藏陷阱：跨栏元素。论文首页的标题、作者列表、摘要有时是跨栏的，有时摘要本身又是单栏的。如果这些元素被聚类进了某一个栏，那就会导致栏内文本顺序错乱。
我的处理方式是在分栏前先做一次“跨栏判断”，把横跨大半页面的文本块单独拿出来：
def is_spanning_block(w0, w1, page_width): """判断一个文本块是否横跨页面的大部分宽度""" span_ratio = (w1 - w0) / page_width return span_ratio > 0.6如果文本块的宽度占页面宽度 60% 以上，就认为它是跨栏标题或跨栏段落，不参与聚类，直接作为独立区块放在整页文本的最前面（因为跨栏标题通常在正文之前）。
这个 60% 的阈值不是我拍脑袋定的，而是测试了一批论文 PDF 后得到的经验值。你可以根据自己的文档类型调整。关键点是：先识别跨栏块，再对剩余块做聚类，顺序不能反。如果先聚类再识别，标题已经被拆散分进两个栏了，后面就很难再还原。
3.3 多栏顺序还原的校验方法
排完序之后怎么知道对不对？靠肉眼翻页看太慢，我一般用两个快捷的校验手段。
第一个是输出顺序审查：把重排后的文本按行打印出来，每行前面打上行号，随机抽几页查看。重点看栏目衔接处——左栏最后一行是否完整，右栏第一行是否应该是下一句。如果出现明显的“断句”现象，说明栏内排序或行合并逻辑有问题。
第二个是嵌入前验证：在处理好的文本上先跑一遍检索测试。拿几个典型问题去查，看命中的 chunk 是否语义完整。多栏解析做得好的话，检索质量不会比单栏 PDF 差太多；做得不好，往往会召回一些“前言不搭后语”的文本。
我强烈建议你在正式批量解析前，先把一套“校验样本”确定下来，包含至少 5 种不同类型的多栏 PDF：论文首页、财报两栏、报纸式多栏、含跨栏标题的页面、含表格的页面。每次改动解析逻辑，先跑校验样本，肉眼确认输出质量再放量处理。这套方法帮我避免了好几次“改一处、炸一片”的事故。
4. 水印 PDF 实战：识别、定位、剔除
4.1 水印的形态分类
水印是 RAG 文档解析里最容易“看着不起眼、实际很致命”的问题。如果水印文本进了知识库，轻则浪费 embedding 的存储空间，重则导致检索结果返回无意义文本，用户一问问题，召回的水印“机密”两个字，体验非常糟。
我接触过的水印场景大致分四类：
| 水印类型 | 典型特征 | 对解析的影响 |
|---|---|---|
| 重复文字水印 | “机密”“禁止外传”“样例”等字样在页面上大量重复出现 | 直接混入正文文本流，污染 chunk |
| 半透明图形水印 | 图片形式，透明度高，铺满整页或斜向分布 | 视觉有干扰，但 OCR 一般不会把它识别为文本 |
| 页眉页脚式水印 | “第 X 页 / 共 Y 页”“公司内部文件”固定在页面顶部或底部 | 每个 chunk 都可能重复包含，稀释有效信息 |
| 斜向大字水印 | 文字沿对角线排列，字号大、颜色浅 | 与正文文字区域重叠，OCR 可能把水印文字和正文混在一起识别 |
处理水印的核心原则和分栏一样：不能用“是否在文本流里”判断一段文字是不是水印，要用布局特征判断。bbox 恰恰就是布局特征的量化表示。
4.2 基于 bbox 特征的规则过滤方案
我实战中用的水印识别方案是一个“规则组合”，不依赖机器学习模型，解释性和可控性都很好。对每个文本块，我计算下面这些特征：
- 重复性：同一页面中，是否有大量文本块的文本内容完全一致。如果某个字符串在页面上出现 3 次以上，而且都分布在不同的 bbox 位置，基本可以断定是水印。
- 位置分布：水印文字块通常分散在页面各个区域，但和正文不同，它的位置与阅读顺序无关，经常落在页面的中部或偏离常规正文区域。可以统计文本块中心点坐标的分布，做一个简单的一维聚类，如果某个“位置簇”里的文本块内容高度重复，判定为水印。
- 面积占比：水印文字块常为“大面积稀疏文本”，即 bbox 很宽但包含的字很少。比如斜向水印每个字的 bbox 跨度可能很大，但实际文本只有两三个字。
- 旋转特征：PyMuPDF 的
page.get_text("dict")或rawdict里可以拿到字符的旋转信息。水印文字经常有 45 度或 90 度的旋转，正文文字的旋转角度通常为 0。 - 颜色特征：PDF 原生文本的
dict结构里有 color 信息。水印文字经常是浅灰色（灰度值接近 0.7~0.9），而正文是黑色或深色。
这里给一段基于 PyMuPDF 原始 dict 数据抽取颜色和旋转信息的示例：
def extract_block_info(page): data = page.get_text("dict") blocks_info = [] for block in data["blocks"]: if "lines" not in block: continue for line in block["lines"]: for span in line["spans"]: bbox = (span["bbox"][0], span["bbox"][1], span["bbox"][2], span["bbox"][3]) blocks_info.append({ "text": span["text"], "bbox": bbox, "color": span["color"], # 十进制 RGB 值 "size": span["size"], "font": span["font"], # 旋转角度需要从 rawdict 或 CharFlags 里提取，不同版本 API 有差异 }) return blocks_infospan["color"]是一个十进制整数，需要转成 RGB。比如 0x999999 是浅灰色，换算方式是color & 0xFFFFFF，再拆出 R、G、B。实战中我主要看灰度是否偏高（R=G=B 且数值大于 150 左右）。
再结合文本的重复性判断：
from collections import Counter def detect_repeated_watermark(blocks_info, min_repeat=3): text_list = [b["text"].strip() for b in blocks_info if b["text"].strip()] counter = Counter(text_list) repeated_texts = {t for t, c in counter.items() if c >= min_repeat} watermark_blocks = [ b for b in blocks_info if b["text"].strip() in repeated_texts ] return watermark_blocks这个规则简单有效，尤其对付“机密”“内部资料”这类整页重复的水印。但要注意，不要一看到重复就删，正文里完全可能有合法的重复内容，比如“目录”两个字在每章标题前都会出现。所以需要结合其他特征交叉验证。
4.3 与 OCR 文本置信度结合的水印过滤
扫描型 PDF 的情况和原生文本型不一样，OCR 输出的每行不仅带 bbox，还带置信度。水印文字因为和背景对比度低、可能被正文遮住一部分，OCR 置信度普遍偏低。我在处理扫描件水印时，会把置信度作为一个重要的过滤维度。
具体做法是：OCR 完成后，把识别结果按 bbox 还原到页面上，统计每个文本行的置信度分布。如果某一行和其他行相比置信度明显偏低（比如低于 0.7，而页面上其他行都在 0.9 以上），并且该行的内容与页面上其他行有重复，就把它标记为疑似水印。
不过这里有个坑：正文中有些元素本身 OCR 置信度就低，比如公式、带底色块上的文字、印章盖住的字。如果把“低置信度”一刀切过滤，会误删正文。我的策略是：水印文本必须同时满足“低置信度”和“高重复性”才删除，只满足一个条件就先保留，留到人工审核阶段再处理。
还有一类特殊情况：整页都是水印图片，也就是 PDF 的每一页底面都覆盖了一张半透明的水印图，而正文是后印上去的文字。这种情况在 PDF 结构层里有明确体现：页面上有图片对象，且图片的 bbox 覆盖页面大部分区域，图片之上才是文字。PyMuPDF 可以直接读取页面图片的 bbox：
def get_image_bboxes(page): image_rects = [] for img in page.get_images(full=True): # 获取图片在页面上的放置位置 rects = page.get_image_rects(img[0]) image_rects.extend([(round(r.x0, 1), round(r.y0, 1), round(r.x1, 1), round(r.y1, 1)) for r in rects]) return image_rects如果某张图片的 bbox 与页面尺寸相当（比如覆盖超过 80% 页面），同时页面上还有正常的文字块，那这张图基本就是背景水印图。它对文本抽取没有影响，但对图片解析管线可能有影响——如果你后续要把页面图片也纳入多模态 RAG，需要把这类背景水印图排除掉，不能让它作为独立图片进知识库。
注意：这里说的“剔除水印文本”是针对 RAG 解析流程里的文本过滤，不是要把 PDF 视觉上的水印删掉，那属于 PDF 编辑和去水印软件的工作范畴。我们是做知识库整理，目标是让入库内容干净，不需要改原文件。
5. 常见问题与排查技巧实录
5.1 表格跨栏被切成两半怎么办
多栏论文里经常出现“表格横跨两栏”的情况，比如一个宽表格宽度超过了单栏范围，排版时被放在页面顶部或底部跨栏显示。聚类分栏时，这种跨栏表格块因为宽度大、中心点在页面中央，可能会形成一个独立的簇，也可能被误分到某一栏里。无论哪种情况，表格内容被夹在正文文本流中，RAG 检索时会把表格碎片和正文混在一起。
我的处理方案分两步：
第一步，先用规则识别表格区域。PyMuPDF 的page.find_tables()（新版本里叫page.find_tables()）能返回表格的 bbox 和单元格结构。pdfplumber 也提供类似能力。识别出来后，可以把表格 bbox 从“分栏聚类”的样本里排除掉，让表格单独处理。
第二步，表格内容单独抽取、单独入库。表格按 bbox 落到“靠近页面顶部”或“靠近页面底部”时，我会把它作为独立的 block 追加到该页文本流的开始或末尾，而不是按坐标插到正文中间。这样虽然牺牲了“绝对位置还原度”，但保住了表格数据的完整性，RAG 检索表格内容时效果好很多。
5.2 扫描件上的水印误删正文
刚才提到低置信度规则，这里展开讲一个我踩过的坑。有一批扫描 PDF，页面左上角有浅的“扫描专用”水印，同时正文中有一段“专用术语”也被 OCR 识别得很差，置信度同样很低。我第一版过滤规则把所有低置信度且重复出现的文本都删了，结果把正文里的术语表删掉了一部分。
后来排查发现，被误删的文本块虽然置信度低，但它们的位置和上下文关系是连续的：前一块讲的是 A 内容，后一块讲的是 A 内容的延伸，中间被删的块刚好是衔接部分。于是我改进规则：只有同时满足“重复出现”“位置分散”“上下文不连续”三个条件，才判定为水印。正文中的术语即使置信度低，它在阅读顺序中的上下文是连贯的，不会同时满足位置分散和上下文不连续。
5.3 页眉页脚和页码干扰
严格来说页眉页脚不算水印，但处理逻辑很接近。RAG 解析时，页码和重复的页眉会污染 chunk 一致性。比如“第 3 页 / 共 120 页”这种字符串出现在每个 chunk 里，检索时既占 token 又没信息量。
我用 bbox 直接做一刀切：定义页眉区为页面顶部 10% 高度范围，页脚区为底部 8% 高度范围。凡是 bbox 完全落在这些区域内的文本块，直接过滤。这个规则简单粗暴，但有个反例：有的论文页眉里包含了章节标题，这对检索其实有正面价值。所以我增加了白名单机制——保留包含“关键词/摘要/引言/方法/结论”等章节关键词的页眉，过滤纯重复的页眉。
具体阈值上，顶部 10% 底部 8% 是我处理 A4 学术 PDF 的经验值。如果你的文档有比较宽的页边距，需要根据实际渲染效果调整。我的建议是先对几个典型页面打印 bbox 坐标分布，看页眉页脚到底落在哪个区间，再定阈值。
5.4 代码环境层面的经典问题
处理几百个 PDF 时，PaddleOCR 偶尔会崩，常见原因有三个：
一是显存不足。如果批量 OCR 扫描 PDF，建议单张图长边限制在 2000 像素以内，既能保证识别精度，又不会让显存爆炸。如果机器性能差，可以加--use_fp16或者干脆换成 RapidOCR。
二是坐标单位不统一。PaddleOCR 返回的坐标是图像像素坐标，而 PyMuPDF 返回的是 point 坐标。同一套代码里同时处理原生 PDF 和扫描 PDF 时，一定要先做一个单位统一函数，把所有坐标转成同一个坐标系再进入后续的逻辑，否则分栏和水印判断会全部错乱。
三是多线程处理 PDF 时，OCR 引擎的并发问题。PaddleOCR 的predict方法线程不安全，我用的是进程池而不是线程池，每个进程单独初始化一个 OCR 引擎。实测下来，进程数为 CPU 核心数的一半时速度和稳定性最均衡。
5.5 效果评估的量化方法
最后分享一个评估解析效果的小工具。我手动整理了一批“标准答案”：拿 20 个多栏页面，手工标出每一块的阅读顺序，然后写脚本比较算法输出顺序和标准答案的顺序一致性。指标用简单的“逆序对比例”——计算算法输出中的相邻块关系与标准答案的差异，逆序对越少越好。
这个指标虽然粗糙，但足够用来做回归测试。每次改进解析逻辑，就跑一遍这 20 个页面，看逆序对比例是否下降。如果下降了，才继续测试更大规模的 batch。这样做的好处是避免“感觉修好了，其实只是换了另一种错误方式”的陷阱。
在实际项目中，我用这个评估方法调了三轮参数：第一轮把聚类距离阈值从 50 调到了 80，第二轮给跨栏表格加了预识别，第三轮给页眉加了白名单机制。每轮调整都有量化指标支撑，而不是靠感觉拍板。
6. 一点个人经验
这套 bbox 处理流程，我在本地 RAG 知识库项目上反复打磨过。最大的感悟是：文档解析没有银弹，规则越多越要控制在可解释范围内。不要一上来就堆深度学习版面分析模型，先从 bbox 规则入手，把 80% 的常见问题解决掉，剩下的边角情况再考虑模型。
给读者一个实操顺序建议：第一步，把你手头所有 PDF 按“原生文本型”和“扫描型”分类；第二步，只对原生文本型做 PyMuPDF 坐标抽取，先跑通多栏排序；第三步，再处理扫描型的 OCR + 水印过滤。每一步都拿 5 个典型页面做肉眼验证，确认没问题再扩大批量。
最后再分享一个调试技巧：解析阶段把 bbox 信息可视化输出，Windows 上可以直接用 PyMuPDF 把 bbox 画到页面上，生成标注图看一眼，哪里分栏错了、哪里水印没删干净，一目了然。我刚入门时靠这个可视化方法省了大量时间——很多问题看文字日志死活找不到原因，一看标注图就明白了。后续这个系列我可能还会写一篇关于表格解析和版面模型选型的实战对比，如果你现在手头有更刁钻的文档类型卡住了，也欢迎在评论区分享你的案例，我可以拿真实的项目数据继续做测试。
