PDF-OCR文件识别篇(二):总览与架构

1.1 两个模块各干什么

整套能力由两个模块组成，组成一条「上传 PDF → 拿到结构化数据」的完整流水线：

模块	职责	外部依赖
`baiduocr`	鉴权 + 文档解析（把 PDF 识别成 JSON / Markdown）	百度 AIP OCR 文档解析接口
`pdf-extraction`	PDF 切表、调 OCR 识别、提示词工程、大模型结构化抽取、装配入库	AI 大模型（GLM）、PDFBox

依赖方向：pdf-extraction依赖baiduocr（见其 pom.xml），反之不成立。baiduocr 是一个可独立复用的「能力包」，对外只暴露一个同步 parse()，调用方不必关心 Token 和轮询细节。

1.2 端到端数据流

整条链路只有一条路线：PDF 切分 → 百度 OCR 识别成 JSON → JSON 投喂大模型做结构化。

 PDF 文件     │     ▼  ① 切分                      pdf-extraction  PdfTableSlicer ──── 按「表N」标题把 PDF 切成多段（一表一段）     │     ▼  ② OCR 识别                  baiduocr  IBaiduDocParseClient ─ 对每段调百度文档解析 → 识别结果 JSON     │  （IBaiduOcrTokenService 提供 Access Token，缓存复用）     ▼  ③ 结构化                    pdf-extraction  TableSchemaRegistry ─ 注入该表「字段清单 / 结构示例」到提示词  AiClient ──────────── 把 OCR 结果 JSON 投喂大模型 → 输出结构化 JSON  并行分块 + 合并 ───── CompletableFuture，按表并行、失败隔离     │     ▼  ④ 入库  XxxImportAssembler ── AI-JSON → 业务 VO  IImportService ────── VO → 落库

注意：早期版本曾有「本地 PDFBox/Tabula 还原 Markdown 直接投喂 AI」的备选路径，由于测试不准确原因已经去除。统一走「百度 OCR 识别 → JSON 投喂 AI」这一条线，识别质量更稳定、链路更简单。PDFBox 仅保留用于第 ③ 步之前的「按表切分」与按页导出，不再承担「喂给模型的内容生成」。

1.3 三个关键设计点

1）识别与理解解耦。 「把 PDF 变成文本 JSON」交给百度 OCR（专业 OCR 引擎，扫描件/复杂版式更稳），「把 JSON 变成业务结构」交给大模型（理解字段语义、合并单元格、跨页折行）。两件事各用最合适的工具，互不耦合——换 OCR 引擎或换大模型，都只动其中一环。

2）「按表」为最小处理单元。 一份 PDF 往往有几十张表，按「表N 标题」切分后，每张表独立识别、独立抽取、独立入库，互不影响，单表失败可单独重试。这是准确率和效率的共同前提。

3）Token 与结果文件落盘。 Access Token 缓存进 Redis；OCR 识别 JSON、AI 结构化 JSON 都写文件，数据库列只存路径，避免大字段撑爆表。

1.4 一次完整流程长什么样

以「一份多表 PDF」为例，业务侧的典型顺序：

上传 PDF，按表生成多条 extraction_record（一表一条）。
对某条记录调 ocrParse：走百度文档解析，把该表识别成 JSON 并落盘，JSON 路径绑定到记录。
对该记录「调 AI」：把 OCR 识别结果 JSON + 该表字段定义拼成提示词，提交大模型异步任务，立即返回。
定时任务轮询异步结果，成功后把结构化 JSON 落盘、回写状态与耗时。
「入库」：按表号选对应装配器把 AI-JSON 规整成业务 VO，再落到业务库。

后续各章：PDF 切分（第 3 章）→ 百度 OCR 识别（第 4 章）→ 字段与提示词（第 5 章）→ AI 抽取（第 6 章）→ 入库（第 7 章）。