PDF 入库前，为什么要先做版面检测
OCR 之前少做一步，后面 chunk 和检索都会错。有谷大脑用轻量版面检测把页面拆成标题、正文、表格、图片等区域，框准边界再 OCR——这是扫描件和复杂排版 PDF 能答对的前提。
把一份 80 页的扫描合同丢进知识库，问：「第三条违约责任里有没有赔偿上限？」
系统返回了答案，还附了出处——第 12 页的一段文字。你翻到原文，发现那段其实是页脚的免责声明，真正的第三条在上一栏。模型没有瞎编，它读到的 chunk 里，页脚和正文被 OCR 拼成了一条连续文本。
这类错误很少被归因到「模型不行」，更常见的原因是：OCR 和 chunk 之前，页面没有被正确理解。对扫描 PDF、双栏论文、带大量表格的研报来说，「版面检测」是整条入库链的第一道工序——框出哪里是标题、哪里是正文、哪里是表格、哪里是页眉页脚，后面的 OCR、切块、抽图才有依据。
有谷大脑对复杂 PDF 的处理，把版面检测放在 OCR 之前，用轻量检测器先读懂页面结构，再按区域类型分流处理。
通用 OCR 为什么会在复杂 PDF 上翻车
很多系统的默认路径是：整页 OCR → 拼成一大段文本 → 按 token 数硬切。这在单栏、排版规整的 PDF 上勉强能用，遇到下面几类页面就会系统性出错：
双栏正文左右穿插。 视觉上一页有两栏，OCR 若按坐标从上到下、从左到右扫，会把左栏第 2 段和右栏第 1 段拼在一起。检索「第二节」时，命中的是两个不同栏位的残片。
页眉页脚混入正文。 每页顶部的公司名称、底部的页码和版权声，和正文用同一套 OCR 流水线处理，chunk 里就会出现高频重复的「某某有限公司」「第 8 页」——它们会污染向量空间，还会在问答里被当成有效证据。
表格和图片失去边界。 表格在 OCR 眼里往往是一堆对齐的数字，列名和行号关系丢失；图片区域的说明文字（caption）和正文粘在一起，后续抽图和文本关联都无从谈起。
小图元密集页面。 试卷、表单、发票上大量括号、下划线、小图标——框边界偏几个像素，切出来的内容就不完整。这类场景 mAP@0.5:0.95 比 mAP@0.5 低得多，说明「找到了」和「框得准」是两回事。
版面检测要解决的，就是在 OCR 之前先回答「页面上有哪些区域、各自在哪里」。
文档页面和自然图像不是同一类检测任务
直接拿通用目标检测器（比如 YOLO 在自然图像上预训练的版本）处理文档，常见有三类失败模式：
| 文档特有的难点 | 后果 | 检测器需要的能力 |
|---|---|---|
| 长距离语义配对 | 题注和图片可能横跨半页 | 深层特征上的全局关联 |
| 上采样丢细节 | 插值放大后边界模糊，小图元被糊掉 | 上采样后重建边缘 |
| 相邻区域外观相似 | 正文、公式、括号、下划线易混淆 | 局部纹理 + 上下文联合判别 |
YOLO-GFD 这类改进的做法很克制：不换大骨架，只在骨干网最深层、颈部上采样、中尺度分支三处各加一个轻量模块，参数量只增加约 0.25M，却在多个文档数据集上把 mAP@0.5:0.95 提高了 1.8～2.8 个百分点——对需要私有化部署、端侧推理的知识库产品，这比堆多模态大模型现实得多。
有谷 PDF 入库里版面检测的位置
一份 PDF 进入有谷大脑，大致经过这些阶段：
- 分页渲染 — 把每页变成适合检测和 OCR 的位图（扫描版本身就是位图）
- 版面检测 — 输出每类区域的 bbox 和置信度：Title、Text、Table、Figure、Header、Footer 等
- 区域分流 — 文本区走 OCR 并按阅读顺序排序；表格走表格结构识别；图片区进入Native + VL 融合的抽图路径
- 过滤与合并 — 丢弃页眉页脚、装饰性区域；双栏按栏位重排阅读顺序
- chunk 封装 — 每个 chunk 带上
page_index、bbox、region_type，写入向量库
和第 4 步的合同条款级 chunk 或 Excel 的表格语义切块不同，版面检测解决的是更上游的问题：chunk 的边界首先得和页面上的真实区域对齐。
一个实际收益：用户问「这份研报里的市场份额图」，检索可以先在 region_type=Figure 的 asset 里找，而不是在混有页眉 logo 的全文 chunk 里碰运气。
和后续环节怎么配合
版面检测不是孤立模块，它和入库链上的其他步骤有明确分工：
与 OCR： 检测框缩小 OCR 范围，减少误读面积；阅读顺序恢复依赖「正文块」的相对位置，而不是整页字符流。
与抽图： VL layout 负责语义判断「这是不是有意义的图」；版面检测的 Figure bbox 提供几何位置，两者做 IoU 融合后只保留高置信度资产。
与 chunk： 理想情况下，一个 Text 检测框对应一个或若干语义 chunk 的上界；表格检测框触发专用解析器，不走通用文本切分。
与引用： chunk metadata 里的页码 + bbox，让用户点击出处时能高亮到页面上的具体区域——「据第 7 页表格区」比「据某段 OCR 文本」可验证得多。
什么时候最该关心版面检测
以下几类文档，跳过版面检测的代价最高：
扫描版 PDF — 没有文字层，一切依赖 OCR；页面上有什么区域，只能靠检测 + 识别。
双栏论文和教材 — 阅读顺序不能按简单坐标排序，必须先知道栏位结构。
带大量表格的财务报告 — 表格和正文混在一起 OCR，数字失去列语义（Excel 有专用路径，PDF 里的表格没有）。
试卷和表单 — 小目标密集，框边界精度直接影响切题和字段抽取。
多语言混排年报 — 图表、表格、正文外观相似，相邻区域易混淆。
反过来，单栏、文字层完整、版式简单的 PDF，版面检测的收益会小一些——但页眉页脚过滤仍然值得做。
工程上的一点取舍
版面检测模型再准，也不能替代格式专用解析：Excel 仍然走 excel-parser 流水线，PSD 仍然走图层树双路读取。检测器负责的是「这页面上有什么、在哪里」，不是「这个 xlsx 的公式依赖是什么」。
对知识库产品来说，这条链路的共同目标是：让入库结果可检索、可引用、可回到原文核对。版面检测是扫描件和复杂 PDF 达成这一目标的前提——OCR 认字之前，先让系统「看懂页面长什么样」。