图片OCR与结构修复：扫描件进知识库的Pipeline

博客园技术文章 · AI材料柜架构实现系列

一、引言：为什么扫描件是知识库的"硬骨头"

搭一个 RAG 知识库，Demo 阶段谁都能做：文档丢进向量库、接上大模型、开个聊天界面，三天就能出成果。可一旦把几十上百页的扫描版 PDF、图纸、历史归档放进来，事情就完全不一样了。

扫描件本质上是"图片"，不是文本。它没有可供直接解析的字符层，只有一张像素图。要做知识库，第一步就必须把像素还原成"人话"，再把"人话"还原成有结构的文档——这一步，恰恰是整个知识库工程里最容易被低估、也最容易翻车的一环。

现实中的坑往往是这样的：

表格被 OCR 识别成一团散乱文本，检索时根本拼不回去；
图纸的标题和说明文字错位，尺寸标注数字混进正文；
手写批注被误识别为正文，污染了检索结果；
最夸张的案例是：一份 200 页的设计手册，OCR 后的文本里包含了图纸的尺寸标注数字，被大模型误读成操作参数，给出了一套完全错误的水处理药剂配比建议。

结论很直接：没有高质量、有结构的数据输入，再好的模型也白搭。 本文就以 AI材料柜为蓝本，拆解一条从"扫描图片"到"可检索结构化数据"的完整 Pipeline——图片 OCR 与结构修复，到底是怎么落地的。

二、扫描件入库在整体架构中的位置

2.1 材料柜的分层架构

AI材料柜整体采用分层架构，把系统划分为四个层次：

前端界面层：基于 React 构建，负责文档管理、检索、编辑与 AI 写作辅助的交互；
后端服务层：基于 Python FastAPI 实现，负责业务逻辑、文档解析、向量索引与模型调用；
向量数据库层：选用 Qdrant，为文档语义搜索提供高维向量相似度计算；
模型服务层：集成本地轻量模型与云端大语言模型 API，按任务复杂度智能调度。

分层的好处是各层职责清晰、可独立扩容。扫描件入库这件事，主要落在后端服务层的文档解析模块，但它产生的结构化数据，最终要喂给向量数据库层和检索引擎。

2.2 文档解析模块的职责

文档解析模块负责多格式文档的内容提取与结构化处理。它集成 OmniParser 视觉解析引擎，基于 YOLOv8 做文档元素检测，能自动识别标题、段落、表格、图片等元素；针对中文文档，再结合 PaddleOCR 与 EasyOCR 提升文字识别准确率。

可以这样理解解析模块的定位：它是知识库的"前端"，决定了后续所有环节的输入质量。 扫描件这类"视觉型"文档，正是这个模块最需要发力的场景。

三、Pipeline 总览：从图片到可检索的结构化数据

3.1 五步预处理管线

处理扫描件，不能"一把梭"地只跑一个 OCR。成熟的做法是分层预处理管线，把问题拆开、逐个击破：

Step 1 文档分类  →  PDF、Word、扫描件、CAD 输出分别走不同管线
Step 2 扫描件    →  高精度 OCR（保留表格结构和标题层级）
Step 3 结构化提取 →  表格数据独立存储、图注分离、正文清洗
Step 4 质量校验  →  随机抽样 10%，人工核对提取精度
Step 5 元数据标注 →  文档类型、日期、版本号、责任部门

3.2 一条扫描件的完整流转链路

把五步串起来，一条扫描件从进库到可检索，大概经历这样的链路：

扫描图片→ 文档分类路由（判断是不是真扫描件）→ OCR 文字识别（像素 → 文本流）→ 结构修复（文本流 → 结构树：表格/标题/图注/正文）→ 质量校验与元数据（抽样核对、打标签）→ 入库索引（语义分块 + 向量化 + 倒排索引）→ 可被检索、被 AI 引用

后面几章，就沿着这条链路的每一环展开。

四、第一环：文档分类与路由

4.1 按来源分派不同管线

很多团队一上来就让所有文档走同一条处理管线，这是第一个隐性错误。扫描版 PDF、原生电子 PDF、Word、CAD 导出图，它们的处理难度和手段完全不同：

原生电子文档：自带字符层和样式标记，直接结构化解析即可，几乎不用 OCR；
扫描版 PDF / 图片：只有像素，必须走 OCR + 结构修复；
CAD / 图纸：往往含大量矢量图形与尺寸标注，需要专门的视觉理解与图注分离策略。

所以在 Step 1，系统会先对文档做分类，把不同类型路由到各自最适合的管线。这一步看似简单，却能避免大量"拿 OCR 硬啃原生 PDF"的浪费。

4.2 识别"电子文档 vs 扫描件"

如何判断一份 PDF 到底是电子版还是扫描件？常用手段包括：

检查 PDF 是否含文本层（有无可提取的字符对象）；
抽样渲染若干页面，统计文字密度与图像占比；
结合页面中是否存在大块位图（扫描件通常整页是一张图）。

判定的结果直接决定后续是否走 OCR。这一步的准确性，决定了整条管线是否"对症下药"。

五、第二环：OCR 文字识别引擎

5.1 引擎选型：PaddleOCR / EasyOCR 与视觉解析

对中文文档，PaddleOCR 与 EasyOCR 是两条主力路径，各有取舍：

PaddleOCR：中文识别准确率高、支持竖排与多种版式，适合作为主识别引擎；
EasyOCR：部署轻、语言模型切换灵活，可作为兜底或补充；
视觉解析引擎（OmniParser）：不满足于"认出字"，而是进一步理解页面上的元素布局，把"哪里有字、哪里是表格、哪里是图"一并建模。

实际工程里，往往先用元素检测定位版面，再对文字区域做 OCR，而不是全页无差别识别——这样既能提升准确率，也能为后续的结构修复保留版面坐标。

5.2 YOLOv8 元素检测与 OmniParser 的角色

OCR 只是"认字"，结构修复还需要"认版式"。这一步依赖 YOLOv8 这类目标检测模型：它把文档页面当作图像，检测出标题、段落、表格、图片、图注等元素及其包围框。OmniParser 则在这些检测结果之上做视觉解析，把元素的层级关系组织起来。

可以这样理解分工：

YOLOv8  → 告诉我"页面上有哪些元素、分别在什么位置"
OCR     → 告诉我"每个文字区域里写了什么字"
OmniParser → 把两者合并，重建"标题-段落-表格-图注"的结构

OCR 负责"内容"，结构检测负责"骨架"，两者缺一不可。

六、第三环：结构修复——从"文字流"到"结构树"

这一环是整条 Pipeline 的灵魂，也是最容易被轻视、坑最多的地方。OCR 输出的往往是一段"平铺的文字流"——没有表格边界、没有标题层级、没有图注与正文之分。结构修复要做的，就是把这段"文字流"重新组装成一棵结构树。

6.1 表格结构重建

扫描件里的表格，是 OCR 的重灾区。表格一旦被识别成散乱文本，行与列的关系就全丢了，后续检索和引用都无从谈起。修复思路通常是：

借助 YOLOv8 / 版面分析定位表格包围框与行列线；
结合 OCR 识别出的单元格文字，按行列坐标重新拼接成结构化表格；
将表格数据独立存储，而不是混在正文里，便于精确检索。

6.2 标题层级与版式恢复

一份 500 页的手册，如果没有标题层级，检索到的永远是"孤零零的一段话"，而不是"第 3 章第 2 节下的某个步骤"。结构修复会根据元素检测得到的标题包围框位置、字号差异，重建 章节 → 小节 → 正文 的层级关系。这样后续按文档结构分块时，每个块都能带上父级标题作为上下文。

6.3 图注分离与正文清洗

图纸或文档中，图注、尺寸标注、手写批注是三类最容易污染正文的信息：

图注分离：把"图 X-XX：xxx"这类说明文字从正文中剥离，单独标记；
尺寸标注隔离：图纸上的尺寸数字不应混入正文，否则会被大模型误读为操作参数（前面那个水处理药剂配比的案例就是这么翻车的）；
正文清洗：去掉噪声字符、重复行、页眉页脚，只保留干净、可用的正文内容。

七、第四环：质量校验与元数据

7.1 抽样人工核对与回退

OCR 和结构修复再强，也做不到 100%。为了保证进入知识库的数据可用，需要在管线末端加一道质量闸门：

随机抽样 10%，人工核对 OCR 与结构修复的提取精度；
对识别置信度过低的页面，打回重跑或转人工处理，而不是放任低质量数据入库；
抽样结果反向反馈给前端的识别参数，形成迭代闭环。

这一步是 Harness 工程思想的具体体现——不只在检索和生成环节做质量门禁，入库前就先把脏数据挡在门外。

7.2 文档元数据标注

结构修复完成后，还要给文档补上元数据：文档类型、日期、版本号、责任部门等。元数据的作用很实际：

支撑后续的过滤检索（如"只看 2025 年后的操作规程"）；
让 RAG 生成阶段能做信息分级治理，知道哪些来源更权威、哪些只能参考；
为知识库的持续更新和版本管理提供依据。

八、第五环：入库与索引

8.1 语义分块策略

结构修复出来的结构树，直接决定了分块质量。这里不建议用固定 token 数硬切，而应按文档结构切分：

<h1>章节 → <h2>小节的父级
<h2>小节 → 正文的基础单元

当某个块内容过长时，再按段落边界切分，并保留该段的标题作为上下文前缀；检索命中某块时，自动带上父级标题和相邻块的摘要。这套"按结构分块 + 语义补全"的策略，能把准确召回率从 67% 拉到 89%——而这背后，恰恰是第三环结构修复打下的基础。

8.2 向量索引 + 倒排索引双通道

入库的最后一步，是把分好的语义块写入索引：

向量索引：基于 Qdrant，用预训练模型把块转成高维向量，做近似最近邻检索，理解深层语义；
倒排索引：基于 SQLite，维护精确的关键词匹配。

线上通常采用混合检索——向量检索保证语义召回、关键词检索保证精确命中，再用重排序融合两者结果。这样扫描件里那些"语义相近但用词不同"的内容，也能被可靠地找出来。

九、工程化经验与踩坑

9.1 常见坑：尺寸标注误读、手写批注、表格散乱

把上面所有环节走下来，真正值得记住的坑有三个：

尺寸标注误读：图纸上的数字被 OCR 进正文，被大模型当成操作参数，轻则答错、重则给出危险建议——必须靠图注/标注隔离解决；
手写批注误识别：批注被当成正文，污染检索结果——需要结合元素检测区分"注释区域"与"正文区域"；
表格散乱：表格变成一段文字流，行、列关系尽失——必须做表格结构重建与独立存储。

9.2 从 70% 到 95% 的可用率提升

一位一线团队的经历很有代表性：初期直接用常规 OCR 管线处理扫描版设计图纸，预处理可用率只有约 70%，频繁出现表格散乱、文字错位、手写批注误判。后来重构为分层预处理管线——文档分类路由、高精度 OCR 保留结构、结构化提取、质量校验、元数据标注——预处理可用率直接从 70% 拉到 95% 以上。

这组数字背后，正是"图片 OCR + 结构修复"整套 Pipeline 的价值所在。