RAG 第一道坎:一份 PDF 年报,怎么解析成能查、能对账的字

01

PDF 是第一道坎

做财报问答，数据源翻来覆去就一种东西：PDF 年报。

偏偏 PDF，是 RAG 这道门里最难进的那个门槛。

难在三处：

最要命的，是图省事直接复制。

Ctrl+C 一拷，结构当场就没了。

表格塌成一排没头没尾的数。

页码飞了。

哪块是标题，哪块是正文，谁也认不出谁。

可 RAG 后头的活儿（分块、检索、溯源），桩桩件件，都搭在「结构」这根梁上。

梁要是歪的，上头盖什么都白搭。

所以解析这一步交出来的货色，好不好，直接顶住了整个系统的天花板。

我们对解析就两条要求，不多:

02

选型与语言边界

解析的家伙事儿，我们挑了 MinerU。

挑它的理由不绕：开源，免费，中文加表格，认得最准。

财报偏巧就是中文，偏巧就表格密。

一拳正打在它的力气上。

可这里头有桩绕不开的事。

MinerU 是 Python 家的人。

我们这一整摊主程序，却是 TS 和 Mastra 的天下。

怎么办？硬把它塞进 TS 里头去？

不。

强扭的瓜不甜，硬塞的人不和。

我们在中间划一道清楚的界。

Python 就管一件事：把 PDF 变成结构化文本，拿 HTTP 露出一个 POST /parse，到此为止。

TS 这头，只接归一化之后的那个形状，版面也好、表格也好，TS 一概不沾手。

这就是这篇头一个要紧处，叫「多语言架构」。

用 HTTP，把两种语言的脾气，全关在服务这道墙后头。

TS 一辈子只跟一份稳稳当当的数据契约打交道（src/lib/parser.ts）：

只要 Python 吐出来的 JSON，合 { pages: ParsedPage[] } 这个规矩，底下解析引擎换成谁，TS 一个字都不用动。

这就是划界的好处。

两边各说各的母语，各干各的拿手活。

到了接口这道门口，认契约，不认人。

03

快档取舍

MinerU 出厂默认走 hybrid，自动引擎。

什么 PDF 都能啃，可慢。

什么都想要的人，往往什么都慢。

我们手里的样本，是巨潮资讯网上扒下来的茅台、五粮液年报。

清一色数字版，字能直接抽。

杀鸡，犯不上动那把宰牛的刀。

所以解析服务里头，我们另配了一套「快档」的环境变量（services/parser/app.py）：

这套配置背后，是四笔算得明明白白的账：

取舍的理，一句话就记住了：数字版走 txt，扫描件才劳烦 ocr；表格开，公式关。

这叫把力气使在该使的地方。

解析整本年报，搁 CPU 上，本就得磨蹭好几分钟。

能省下一个数量级，那就是实打实的快慢，骗不了人。

最后落到 MinerU 的 CLI 上，就是这么一行：

这就是我们要归一化的那块生料。

04

归一化

MinerU 吐出来的 content_list.json，是个「什么都往里装」的大清单。

我们拿 normalize()，把它收一收，收成 TS 想要的那个样（services/parser/app.py）：

拢共十几行，里头藏着四个主意：

解析即取舍

normalize() 里那句 else: continue，瞧着轻飘飘的。

可它一挥手，扔下去的东西不少。

拿 maotai_2024 实打实跑一遍。

这一本年报，统共 2360 个条目。

按 type 一摊开，是这么个分法：

末了只剩 text + table = 1796 + 275 = 2071 个原始块（这些往后再分块，还得再生出一摞来）。

凭什么扔得这么干脆？

因为这些东西，对「回答财报里的问题」，一点查头都没有。

留着它，它就是噪声。

页眉页脚（「贵州茅台股份有限公司 2024 年年度报告」这行字，每页都来一遍），还有那些孤零零的页码，塞进向量库里，只会把检索的水搅浑，把嵌入的额度白烧。

说一千道一万，解析的本分，就是取舍。

对活儿有用的，留下。

是噪声的，在门口就拦住，不让进。

05

真实表格有多脏

这儿得先给你打一针预防针。

不是你心里头那种竖线一道道的 Markdown 表。

底下是 maotai_2024 第 8 页那张主要财务数据表的真片段（一个字没改）：

你瞅瞅 170, 899, 152,276. 34 这串数。

它本该是 170,899,152,276.34。

也就是 1708.99 亿的营业收入。一千七百多个亿，是个体面数目。

可数里头，硬生生混进了几个不三不四的空格。

这不是谁手抖抄错了。

这是数字版 PDF 抽字时，自带的真噪声。

PDF 里那个千分位的逗号、那个小数点，跟数字挨得太近，字符间的那点空当，被引擎一眼看花，认成了空格。

我把它原样端给你看，不是图你看个笑话。

是想让你瞧清数据层的真相：解析交出来的货，从来就没干净过。

这种脏活儿，在金融 RAG 里头，遍地都是，低头就能踩着一个。

这一篇是 MVP，我们先把脏的如实摆出来，不急着洗。

往后讲「结构化清洗」那一回，它正好是个现成的、不用花钱请的反面教员。

得先认下这脏，才谈得上往后治这脏。

06

两个工程坑

把 MinerU 接进 TS，路上埋着两个坑。

这坑，不亲自栽一回，你不知道它有多硌脚。

坑一：undici 默认 5 分钟就撂挑子，不够使。

MinerU 在 CPU 上解一本年报，动不动就是好几分钟。

可 TS 这头使的 undici，默认 headers 超时，是 5 分钟。

年报稍微厚那么一点，它当场就超时，给你撂脸子报错。

解法，是单给这个请求配一个把超时关死的 dispatcher（src/lib/parser.ts）：

headersTimeout: 0、bodyTimeout: 0，意思是「你解到天荒地老，我都候着」。

可 connectTimeout: 10_000 这一条得留。

连不上服务，那是另一码事，得让它麻溜地死，别跟「解析慢」混作一谈。一个是人没来，一个是人来了在干活，两回事。

坑二：别一回一回地从头解。

解析本就这么慢。

你要是每跑一回 npm run ingest，都把它从头到尾再解一遍，这等法，能把人等出火来。

所以解析服务里，搁了个缓存。

缓存的钥匙 = {文件名stem}_{mtime}，说白了，就是文件名加上它最后改动的时辰。

撞上现成的 content_list.json，直接拿来用，重复的解析一概跳过：

只要这 PDF 没动过（mtime 没变），第二回解析，就是抬手之间的事。

慢操作配上内容寻址的缓存，是数据层离线流程里，老搭档一对，缺谁都别扭。

07

PDF 解析端到端管线

08

小结

1、解析是 RAG 第一道坎

PDF 版面乱，表格密，还分数字版和扫描件。

图省事直接复制，结构当场就散。

我们要的，是带着页码、标好 isTable 的规整块。

2、挑中 MinerU，划清语言界

Python 只管 PDF 变结构化文本，拿 POST /parse 露出来。

TS 只认 ParsedBlock / ParsedPage 这份契约。

底下换引擎，TS 纹丝不动。

3、快档是一笔工程账

数字版走 txt，快一个数量级。

扫描件才走 ocr。

表格开，公式关。

4、解析即取舍

maotai_2024 统共 2360 条目。

只留 text(1796) + table(275) = 2071 块。

页眉、页码、图，全扔。拦噪声，从门口拦起。

5、对脏数据，认账

数里头混着不三不四的空格(170, 899, 152,276. 34)。

这一篇先如实摆出来，往后再洗。

6、两个工程坑

把 undici 的超时关死的 dispatcher。

拿 stem+mtime 当钥匙做缓存，重复的解析跳过去。

规整文本，这就有了。

可你也瞧见了。光一个表格，就能抻出好几百个块，又长又脏。

这些块，尤其是表格，往后该怎么切，才不把好端端的意思给切散了？

这是下一篇的事。

下一篇，我们就说「分块」。

09

点击下方卡片，关注「解药不甜SM」

谢谢你一路看到这儿！

这篇实战文要是真给你提了个醒，有劳点个赞，点个在看。

也欢迎你顺手转给身边正在啃 AI 的朋友。

你做 PDF 入库、做文档 RAG 那会儿，栽得最深的解析坑，是哪一个？

是表格被拉平了，是页码丢了，还是扫描件死活抽不出字？

评论区里说说，我挑几个有代表性的，往后的内容里掰开了讲。

10

持续成长

延伸阅读

系列文章

点下头那个「阅读原文」，本篇整套脚本代码，都在里头 ~