## 0. 那个磨了 57 分钟的 PDF

2026 年 10 月 2 日凌晨 1 点，跑批的日志停在 `23:04:28`。
![fig1_57min_clean.png](https://developer.qcloudimg.com/http-save/yehe-8674888/f621384dfcc059b79bd51cefa07bc16c.png)
不是崩溃，是**停止出活**。56,224 份报告里跑完 56,223 份，剩最后 1 份啃了整整 57 分钟没动。当时 6 个 worker 进程全活着，CPU 各占 1,600 多秒，内存 8 GB 空着，看起来像在忙。

我另写了个诊断脚本去探，也卡在同一处。

那份 PDF 叫 `601117.SH_2025_half`，贵州茅台隔壁的中国化学 2025 年半年报。226 页，3.2 MB。第一反应当然是下载截断，去核：

```
服务器 Content-Length   3,226,758 字节
本地实际大小            3,226,758 字节     ← 一模一样
文件尾部                startxref 3175387 + %%EOF   ← 结构完整收尾
```

没截断。但 MuPDF 一直在刷同一行：

```
MuPDF error: format error: cannot find object in xref (561 0 R)
```

反复刷了几百次。文件大小对、`%%EOF` 也在，唯独交叉引用表指向的 561 到 585 号对象**根本不存在**。

**这是源 PDF 本身就坏的。** 企业挂出来的那一份就是坏的，重下多少次都是同一个文件。MuPDF 只能退回逐页重建的路径，`find_tables` 于是退化到耗时不可接受。

那一刻我才想明白一件事：这份数据里真正难的不是怎么把 PDF 抽成文本，而是**你怎么知道自己的抽取结果有没有问题**。前者是工程，后者是方法论。后者花了我们更久的时间，而且推翻了好几次我们以为自己已经搞对的东西。

下面写的是那条方法论。

---

## 1. 问题：看起来是体力活，其实是信任问题

任务的表面目标是：把上市公司的定期报告，抽成保留表格结构的纯文本。

干过的人都知道，单份 PDF 抽文本，PyMuPDF 几行代码的事。全量 5,700 多家、5 万多份，跑一晚上也就出来了。

真正的问题在于下游要用它做什么。只要有人拿这个数据做统计、做训练、做财务指标的抽取，就必须回答一个问题：

> 这份文本里有多少是我真的抽到了，有多少是我以为我抽到了？

前者能数出来，后者数不出来。抽出来 500 万字不代表抽对了 500 万字——表格里一个数字被拆成两半，正文里 12 行的表被挤成一行，某个章节的标题因为版式怪没匹配上，这三件事都不会报错，只会让你的数字悄悄变错。

所以整个任务真正的难点是：**建立一套能自己指出自己毛病的机制。**

我们是这么拆的：

```
发现问题的能力  ≠  模型聪明
发现问题的能力  =  两个本该相等的数字不相等
```

这个判断后面会被反复用到。它是全文唯一真正重要的东西。

---

## 2. 方法：三段式，每段都要留下可核对的数字

### 2.1 发现：先立对账，不立判断

我们做的第一件事不是写抽取器，是**先给未来的自己埋对账点**。

抽取器每抽一份，就在账本 `_delivered.jsonl` 里追加一行，记录这份报告的原始数据。同时在 txt 头部写一行注释：

```

```

有了这个，之后任何一条统计结论都能反查到具体文件，反查不动就是结论有问题。

这一步听起来平淡，但**它是后面所有发现的唯一来源**。我们后面抓到的每一个问题，都是账本上的某个数字和现实对不上，而不是靠人肉翻样本翻出来的。

### 2.2 分析：先验变异，再谈相关

我们做了一个可视化，把 5,000 多家公司按提取难度铺成一张点阵图，每格一家公司，颜色深浅是难度。做完顺手做了个相关性分析，看看难度和公司营收有没有关系。
![fig5_dianzhen.png](https://developer.qcloudimg.com/http-save/yehe-8674888/2e03e90dffb6b36847e3825387732513.png)

出来一条：

> 披露完备度与营收的秩相关 ρ = 0.0024，基本无关。大公司并不更规范。

数字很干净，故事也顺。我当时把它写进了页面，还配了一句：规模越大越规范这个假设不成立。

**这条结论是错的。** 而且错法很有意思。

完备度这个分数是这么算的：缺一项结构锚点扣 12 分，满分 100。听起来合理。但我当时忘了先看一眼这个分数有没有区分度。事后一查：

```
缺 0 项的公司    3,034 家  (72.3%)
缺 1 项             961 家  (22.9%)
缺 2 项及以下       192 家  ( 4.7%)
```

七成以上的公司拿满分。拿这么个东西去分五档算均值，五档的结果是 97.4 / 97.6 / 98.0 / 97.6 / 96.9，**极差 1.1 分**。

一个几乎不变的序列和营收求相关，得到的 0.0024 不代表两者无关，它代表**这个指标在原理上就测不出差异**。天花板效应。

改用有真实分布的原始变量——缺项数，0 到 5 的离散值——重算，结论方向没变，但这次它是有信息量的：

```
缺项数 ~ 营收   ρ = -0.0035  (n = 5,161)
缺项数 ~ 页数   ρ = -0.2110  (n = 5,465)
```

与规模无关，与篇幅有关。报告越长，结构越全。

**从这次之后我们立了一条硬规矩：任何自造指标，先验它在分组之间有没有变异，再拿去算相关。** 这一条后来又救了我们两次。

### 2.3 解决：判据要选不可伪的那一个

最后一类问题是身份识别。

代码表里同一家公司出现了两次。新三板的老代码是 `832225.BJ`，北交所现行统一代码是 `920225.BJ`，两家都叫利通科技。公司数因此虚高 246 家。

第一反应是按公司名去重。但**公司名是不可靠的判据**——`920575.BJ` 叫 ST康乐，`833575.BJ` 叫康乐卫士，同一家公司被 ST 之后名字就变了。按名去重会漏掉 4 家。

我们换了个判据：

> 同一 `source_hash` 即同一份 PDF，即同一主体。

一个公告只对应一个代码，如果两个代码下某一年的年报 PDF 是逐字节相同的，那它们必定是同一家公司。这不是猜测，是可验证的事实。

跑下来 242 组同名、4 组改名或被 ST，合计 246 组，5,782 个代码归并成 5,536 个主体。

**然后出现了第 5 组，规则拒绝了它**：

```
000401.SZ  金隅冀东
601992.SH  金隅集团
```

这两家共用同一个 PDF 哈希，但它们是**两家不同的上市公司**，前者是后者的子公司，代码尾号也对不上。

如果按哈希无脑合并，我们就会把两家公司的数据混成一家。规则没有合并，而是把它踢进人工复核清单。

这是一个 PDF 挂错了公司，不是重复主体。**能区分这两种情况，靠的是规则里那条尾巴**

---

## 3. 数据：全量跑下来是什么样

### 3.1 规模

```
契约范围槽位     69,876
实际匹配到       56,225
交付             56,224  (99.998%)
主体             5,536 家  (5,782 代码归并 246 组)
error 记录       0
source_hash 完整 100%
```

### 3.2 产物

```
文本        90.55 亿字符
表格块      8,154,447 个
表行        76,824,535 行
PDF 页数    5,722,588 页  (平均 102 页/份)
```

### 3.3 质量分布

| 等级 | 份数 | 含义 |
|---|---|---|
| high | 24,071 | 文本充足且结构锚点全中 |
| medium | 32,059 | 可用，关键字段建议回原 PDF 核对 |
| low | 94 | 文本不足 2000 字符，等于没抽到 |

### 3.4 结构缺失：缺的是哪一项

年报口径，5 项结构锚点，样本 5,465 家：

| 子项 | 缺失率 | 95% 置信区间 |
|---|---|---|
| 管理层讨论与分析 | 0.38% | 0.25 – 0.59 |
| 主营业务构成(分部) | 0.70% | 0.51 – 0.95 |
| 客户与供应商 | 1.32% | 1.05 – 1.66 |
| 产销量与产能 | 11.71% | 10.89 – 12.59 |
| 成本分析 | 6.77% | 6.13 – 7.47 |

这张表比五项全中的比例更有信息量。前三项几乎从不缺，**全部缺项压在两项上，而这两项恰好是有条件适用的**——服务业没有产销量，很多公司不单独出成本分析表。
![fig3_anchor_clean.png](https://developer.qcloudimg.com/http-save/yehe-8674888/4be4309108b116726c7d5165531447dd.png)

所以那个五项全中率测的其实是**适用性**，不是规范度。

### 3.5 单位声明

抽取的时候顺手统计了表格有没有声明单位：

```
含数值的表    3,736,209 张
  已声明      2,212,716  (59.2%)
  未声明      1,523,493  (40.8%)
```

**四成带数字的表格没说单位。** 这个数字对下游比任何质量指标都重要，因为它决定了你能不能直接拿这些数做聚合。

---

## 4. 结果：最有价值的产出，是它抓到了我们自己

跑到这一步，数据本身已经能交付了。但真正让我觉得这套东西值得写出来的，是另外几件事。

### 4.1 同一天里，同一个错误犯了三次

一天之内，我们三次栽在同一个坑上：**拿没做完的数据当完整数据用**。

| # | 场景 | 看到的现象 | 真相 |
|---|---|---|---|
| 1 | 分板块对比结构完整性 | 北交所五项全中只有 2.6% | 关键词锚点对北交所整体失效 |
| 2 | 跨年度对比 | 成本分析跨版差 2.52pp 显著 | 两组根本不是同一批公司 |
| 3 | 逐项缺失率 | 全中率 73.5% | 快照只有 59% 完成度 |

第 1 个的细节值得展开。我们去查北交所的年报原文，统计词频：

```
产能          出现  10 / 10 / 8 次     ← 披露是有的
营业成本      出现  26 / 26 / 20 次    ← 成本信息是有的
成本分析      出现   0 /  0 /  0 次    ← 但从不叫这个标题
```

成本数据人家披露了，只是不用这个词做标题。我们的锚点写得太死，北交所整块被误判成不合规。

**当时最省事的做法是加几个同义词把数字修好看。** 我们没那么做，因为那只是把错得离谱变成错得隐蔽。做法是把整块结论标成不可用，写清楚原因和边界，等后面做监管章节对照时用真正的章节结构识别来解决。

第 2 个更隐蔽。我们按 basis 年份把公司分成两组比较缺失率，发现成本分析跨版差 2.52pp 且统计显著。差点写成一条发现。改用同一批公司相邻两年对比之后，差异归零。

**那天学到的规矩：跨版本结论必须做同公司内比较。** 分子分母不是同一批公司，显著性再高也没意义。

第 3 个是版面数字。页面上的缺失率是拿当天 13:21 的快照算的，那时批次才跑完 59%，600 和 601 开头的沪市代码只抽了 113 家。而大盘股年报恰恰是最规整的那一类。语料冻结后全量重算，同一个指标从 73.5% 变成 86% 左右。

最后我们把这条写成了硬约束：**分析必须等语料冻结**。

### 4.2 一个校验器，先学会了项目的命名约定

**写校验器之前，先把项目里已有的命名约定认全。** 这一条看起来是废话，我们还是在两次自己的项目里各踩了一次。

### 4.3 有些数字，天生就是不该拿来算相关的

最后说说那些推不出结论的指标，免得后面的人重复劳动。

我们构造过一个披露完备度分数，也构造过一个按营收分档的规范性梯度。这两个都做得很像模像样，放在任何报告里都不会被挑出毛病。

问题在于它们都饱和了。完备度七成满分，五档极差 1.1 分；规范性梯度的完备度也是 97 到 98 之间。**一个测不出差异的指标，无论你怎么算相关系数，得到的都是零，而那个零会被误读成没有关系。**

这类错误特别危险，因为它不报错，甚至能给出一个看起来很有说服力的结论。

我们现在给自己加了三道必查：

- 这个指标在分组之间的极差，是不是远小于它的量程
- 算出来的相关系数，是不是恰好接近零——接近零往往说明饱和，不说明独立
- 用的关键词锚点，在对照组里到底出不出现——抽三份原文数一下词频

以及一条硬规定：**所有分组的差异都要配 95% 置信区间，区间两两重叠就写不显著。** 我们有一组数字是 82% / 84% / 86% / 85% / 82%，看起来是个漂亮的倒 U，当时差点就写成发现了。配上区间之后才发现五档的置信区间两两重叠，那就是一条平线。

---

## 5. SOP：可以照着做的检查清单

如果只留一句话：**建立可核对的中间产物，然后持续对账。** 具体拆成下面这些。

### 抽取层

1. 每份产物写清可回溯的元信息
2. 表格原样保留
3. 修复数字折断这类问题要在**正则层**做，不要事后人工修
4. 没把握的信息宁可标出来，也不要猜

### 分析层

5. 自造指标先验变异，再谈相关
6. 跨版本比较必须同公司内
7. 分组差异一律配置信区间，重叠就写不显著
8. **分析必须等语料冻结**，这是我们一天栽三次换来的

### 身份层

9. 主体去重用不可伪的判据
10. 规则要留一个拒绝的口子

### 校验层

11. 校验器先认全项目已有的命名约定，包括改名后缀
12. 串行之前先测环境
13. 后台进程一定要带日志重定向

### 判断层

14. 指标的缺陷要写在产物里，不要靠记住

---

## 6. 收尾

这次任务从下午两点做到第二天凌晨，前后三十多个小时，中间崩过两次、停摆过两小时、算错过三次。

最后交付的是 5,536 家上市公司、56,224 份报告、90 亿字符的结构化文本，附一份 manifest 和一份使用说明。

但回头看，最有价值的产出不是这些文件，是那张对账表和它揪出来的东西：

- 一个源 PDF 自身损坏，磨了 57 分钟才定位
- 一个关键词锚点在某个板块整体失效，差点让我们把检测口径问题写成披露事实
- 一个自造指标饱和到没有区分度，产出过一条看起来很专业的错误结论
- 一个校验器不认自己的改名约定，报了一堆不存在的缺失
- 一个串行跑了 9 小时才被并发 5 分钟替代

这些没有一个是靠盯样本盯出来的，全是对账对出来的。

所以要跟同行分享的其实只有一件事：**先把可核对的中间产物建起来，剩下的交给对账。** 抽取本身是可以外包的工程活，判断自己抽对了没有是没法外包的。

---

*数据与图表来源：本人独立研究，样本为全市场 A 股上市公司定期报告。*
*本文数据可用文末清单中的脚本复现。*

2026 年 10 月 2 日凌晨 1 点，跑批的日志停在 23:04:28。不是崩溃，是停止出活。56,224 份报告里跑完 56,223 份，剩最后 1 份啃了整整 57 分钟没动。当时 6 个 worker 进程全活着，CPU 各占 1,600 多秒，内存 8 GB 空着，看起来像在忙。

一份财报抽取任务，是怎么把自己变成审计工具的

一个把 5 万多份上市公司财报 PDF 抽取成结构化文本的任务，最终把自己跑成了一套自我审计工具。真正的难点不是抽取，而是怎么知道抽取结果有没有问题。作者的做法是：每步留下可核对的中间产物，然后持续对账——靠"两个本该相等的数字不相等"发现问题，而不是靠盯样本。这套机制抓到了源 PDF 自身损坏、关键词锚点对整个板块失效、自造指标饱和失真、同公司不同代码重复计数等一系列隐蔽错误，最终沉淀为一份覆盖

农民伯伯

后端

开发工具

职业发展

这份56,224份PDF抽取任务的核心难点不是技术实现，而是建立可验证的信任机制。通过源文件哈希对账、锚点变异检测和不可伪判据，我们定位了源PDF损坏、板块误判和指标饱和等隐蔽问题。最终交付90亿字符结构化文本，但更有价值的是那套能自我纠错的对账方法论，它让所有统计结论都可反查、可复现。

代码解释

服务器

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

一份财报抽取任务，是怎么把自己变成审计工具的-腾讯云开发者社区-腾讯云

一份财报抽取任务，是怎么把自己变成审计工具的

一份财报抽取任务，是怎么把自己变成审计工具的

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐