在政务网站群项目里我隔三差五就会碰到一个让人头疼的问题责任部门提交上来的PDF材料里混着大量公式型内容——统计年报里的指标说明、经济普查的测算方法、行业技术规范的数学表达式。这些PDF要是只当成附件挂在页面上用户下载下来也能看但很多事就做不了了搜索引擎索引不到公式内容站内全文检索对公式无能为力归档系统抓取不到结构化字段无障碍阅读工具更是直接傻眼。更要命的是政务站群少说也有几十个子站每个子站有各自的责任部门人工一篇篇转换根本不现实。所以问题就摆在这了在WordPress站群架构下能不能把PDF里的公式结构化提取出来让公式变成可检索、可复用、可正确渲染的正文内容先说结论能而且不一定非要上大模型。我用“PDF文字层解析 公式OCR WordPress自定义文章类型 多站点调度”的组合拳做了一条半自动的入库流水线。适用范围是电子版或扫描版PDF公式以规整印刷体为主数学符号密度中等——比如统计指标说明、技术规范、考试辅导材料、论文汇编这一类。手写公式和极度复杂的矩阵推导这套方案会吃力后面我会讲原因。下面我把整个方案的思路、技术选型、落地细节和踩坑过程都拆开讲给同样被这类需求折腾的同行做个参考。1. 需求场景分析政务站群里的公式PDF到底是个什么东西1.1 这类PDF的典型来源和文档特征先别急着聊技术把文件本身的特征摸清楚比选型更重要。政务场景里出现的PDF来源大致可以分成三类上级部门下发的正式文件扫描件通常是红头文件的PDF版里面偶尔出现公式、指标符号业务处室自己提供的电子排版稿多数是用Word或WPS导出的PDF文字层完整但公式往往变成内嵌图片或者OLE域对象第三方机构交上来的报告汇编常见的是LaTeX排版的统计报告或行业论文文字层完整公式是矢量字形。这三类的物理特征完全不同。第一类没有文字层必须走OCR路线第二类有文字层但公式经常是图片需要额外做公式图像区域检测第三类有文字层公式可以直接从PDF里提取但难点在于公式和正文混杂得把公式块的边界判断清楚。你要在方案设计阶段就区分清楚这些情况否则解析器会把大量算力浪费在根本不需要OCR的文件上。政务文档还有一个共性版式规范、页眉页脚固定、正文字体基本统一。这个特征是一把双刃剑——页面模板固定意味着版面分析规则可以复用但字体偏少尤其是生僻的数学符号字体不齐全容易导致OCR识别率下降。我当初对样本库做过一次符号覆盖率统计出现频率最高的前十个符号是Σ、∫、√、±、×、÷、α、β、μ、∞。这些都属于标准Unicode字符识别难度其实不大真正让人头疼的是分式、多层根号、求和上下限这类结构型公式它们不是单个字符识别的问题而是整个版面结构理解的问题。1.2 所谓“结构化提取”到底要提取出什么很多项目在这个需求上卡住是因为连“结构化”的标准都没定清楚。是提取成纯文本还是提取成LaTeX还是提取成MathML三者差别大了去了。我当时的做法是分两级处理。第一级是版面结构化——把PDF的每一页识别成“标题、段落、公式块、表格、页眉页脚”这样的区块把公式从正文流里独立出来第二级是公式语义结构化——把公式块识别成结构化的公式表示便于后续做检索和渲染。目标输出格式定为LaTeX原因是LaTeX可以双向转换前端渲染交给MathJax或者KaTeX数据库检索直接用全文索引将来要转成MathML提供给无障碍阅读器使用也有现成的转换工具链。这里有个容易被忽略的业务点。政务网站的公式内容不只是拿来展示的它还要满足无障碍阅读、数据交换和归档管理的要求。按咱们国家的政务网站无障碍规范GB/T 37668带数学公式的内容需要提供可读的文本替代MathML是理想形态。所以即使第一版只输出LaTeX我也建议在WordPress里同时存一份MathML版本或者至少存一份可人工审核的纯文本描述。否则等甲方提出无障碍整改需求的时候你拿着一堆PDF回头重新跑一遍提取流程那工作量可就大了。2. 技术选型PDF解析与公式识别引擎怎么组合2.1 先分两条路文字层PDF和扫描件PDF这一步是整个管线的基础必须在入口处做文件分类。工具层面我用PyMuPDF做PDF解析说白了就是fitz库。它对文字层提取非常稳定而且能返回每个文字块在页面上的坐标——这个坐标信息在后面做版面分析、公式定界的时候是命根子。pdfplumber也能干这事但处理页眉页脚、处理自定义字体的鲁棒性不如PyMuPDF政务文档里花式页眉页脚又特别多所以我投了PyMuPDF。判断一个PDF有没有文字层不需要什么高深技术直接用PyMuPDF读每一页的text字典就行。如果整页文字量低于一个阈值比如一页少于200个字符而且图像面积占比超过70%就判定为扫描件进入OCR通道。这个阈值建议做成可配置参数因为政务PDF里还有第三种形态文字层完整但公式被图像化。最典型的就是Word里用公式编辑器插入的公式导出PDF后有些版本会变成图片。我建议在解析管线的入口处做一个三分类纯文字层PDF、扫描件PDF、图文混合PDF。给每个文件打上类型标签再决定走哪条子管线。这个分类表面上看只是多写几行判断代码但在站群批量处理场景下特别管用——日志里每个文件走了哪条路径一目了然出了问题能快速定位而不是所有文件都糊里糊涂地走同一套重流程。2.2 公式识别引擎商用API与开源模型怎么选公式识别引擎的选择直接决定了整个项目的成本上限。目前可选的方案大致分三类我先列个表大家有个直观对比方案优点缺点适用场景Mathpix API识别精度高支持复杂公式输出LaTeX/MathML按量计费有调用频率限制公式密度高、精度要求严的正式文件PaddleOCR公式识别开源免费可私有化部署支持版面分析复杂公式精度略低需要GPU加速数据敏感、批量大、成本敏感自研规则字符映射零成本完全可控只能处理结构化明显的公式通用性差公式模式固定、数量少的场景政务环境里“数据不出域”是硬约束这个词不用我解释做过政府项目的都知道。如果客户的PDF属于敏感数据商用API这条路在合规上就有硬伤。我当时给客户推荐的是PaddleOCR的公式识别模块理由有三条一它可以完全私有化部署文件内容不会发给第三方二它对印刷体公式的识别效果在开源方案里属于第一梯队三它对中文与公式混排的处理能力比某些纯英文模型好得多。开源方案的部署细节我多说两句。PaddleOCR的公式识别模型输入是一张包含了公式的裁剪图输出是LaTeX文本。部署的时候需要一台带GPU的云主机哪怕是入门级GPU都行。CPU跑也能跑但速度会让你怀疑人生——我实测过CPU处理一张1000×500的公式图大约要2到3秒GPU只需要几十毫秒。站群批量场景下一天要处理几百个PDF这点性能差异直接决定任务队列会不会积压成死水。2.3 我最终采用的解析管线具体管线是这样设计的每一步都有明确的产出方便单独调试PyMuPDF打开PDF提取每页的文字块和坐标统计文字层覆盖率打上类型标签对扫描件或公式图像用PaddleOCR做版面分析和文字识别输出文本块和公式候选区域对文字层PDF用版面启发式规则找公式块——比如行内居中、字体切换到Cambria Math或等距体、行宽明显短于正文把候选区域裁剪出来把候选公式图统一送入公式识别引擎得到LaTeX文本同时记录识别置信度用版面坐标把识别结果按阅读顺序拼装成文章结构公式块从正文流中独立出来以区块形式存储。这套管线最大的好处是每个环节都能独立调试。公式识别不准的时候你就去看第三步的裁剪是不是把上下文带进来了文本顺序错乱的时候你就去看第一步的坐标排序是不是有问题。工程上模块化解耦比一味追求某个环节的高精度更重要——这个道理在站群这种多文件批量处理的场景里尤其明显一个环节卡住整个队列就瘫了。3. WordPress侧的承接设计站群数据模型与入库流程3.1 自定义文章类型和字段怎么设计拿到结构化后的文章内容下一步就是把它落进WordPress。这里有个常见的错误做法把解析结果直接塞进经典编辑器的HTML视图里公式用一串图片链接代替。这样虽然页面上能看到公式但全文检索、无障碍、数据交换全都做不了。我设计的方案是自定义一套文章类型名叫“doc”再配一组自定义字段。关键的字段包括source_pdf来源PDF的ID关联到媒体库detect_type解析类型标签text/scan/mixed 三选一formula_count公式数量latex_source整篇的LaTeX源文本mathml_source整篇的MathML版本para_order段落顺序的JSON数组每个元素标记类型text/formula/table。这样设计至少有三个好处。第一公式块和正文块在逻辑上是分离的前端可以用不同的模板渲染第二全文检索可以直接针对latex_source建立索引用户搜索“∫”“标准差公式”都能命中第三后续如果要做站内知识库或者数据交换JSON化的段落结构比纯文本好拆得多。3.2 Multisite下的数据共享与权限边界政务站群一般用WordPress Multisite搭建一个主站加一串子站。这里有个核心设计决策处理好的文档是存在主站的共享池里再同步到各子站还是各子站各自存一份我的建议是解析任务在主站集中执行但入库时按内容归属落到各个子站。主站只负责跑队列、调用解析引擎、做日志审计解析结果推送到目标子站的文章类型里。理由有三条避免每个子站重复部署解析环境资源省了维护也简单权限边界清晰各子站管理员只维护自己站点的内容格式转换逻辑由站群管理员统一控制审计日志集中存放符合政务场景里“谁处理、谁负责”的管理习惯。具体实现上可以用WordPress的rest_prepare_{post_type}过滤器在REST API响应里带上latex_source等自定义字段供子站前端渲染。如果子站数量不大走REST API是最省事的方案。我见过有些团队一上来就搞消息队列、Redis说实话在政务站群这个规模下REST API加数据库表就够了别把架构搞复杂。3.3 自动入库流程入库流程我设计成后台处理队列不搞同步处理。原因很简单PDF解析耗时不短在Web请求里同步跑会把PHP进程拖死也容易触及时限。政务网站对页面响应时间有要求不能因为一个PDF解析把整站拖慢。流程是这样的管理员在媒体库上传PDF或者子站编辑上传上传完成后触发add_attachment钩子把PDF文件路径写入处理队列一个基于WP-CLI的常驻脚本逐条取出队列里的PDF调用Python解析服务解析服务返回结构化结果后队列处理器创建“doc”文章并填充自定义字段完成后发送状态通知管理员在后台审核发布。这个流程里解析服务是独立的Python进程和WordPress之间通过HTTP接口通信。我把解析服务封装成一个小型Web API接收PDF路径返回结构化JSON。WordPress侧只需要远程请求一下完全不关心Python内部怎么实现。这么做的另一个好处是以后如果要把解析能力接给其他系统API直接复用就行不用动WordPress代码。4. 批量处理、任务调度与权限控制的工程化细节4.1 任务优先级与资源控制站群场景下批量处理的难点不是“能不能处理”而是“怎么控制节奏”。一个公文PDF好几十页里面上百个公式如果各个子站同时上传一批文件解析服务瞬间被打爆是分分钟的事。我设计了一套简单的优先级调度上传时间戳靠前且类型为“扫描件”的任务优先跑因为扫描件耗时最长先跑能尽早释放队列压力文字层PDF排在后面。同时解析服务设置了并发数上限比如同时最多处理两个PDF其余排队等待。队列用数据库表存储状态字段区分pending、processing、done、failed处理失败的任务自动重试两次超过重试次数转入人工队列。日志方面每个任务都记录PDF路径、开始时间、结束时间、解析结果摘要和错误信息。政务项目验收的时候这套日志是很有说服力的交付物——它能证明系统确实处理过哪些文件、耗时多少、失败原因是什么。项目出问题做复盘时这些日志的价值更是体现得淋漓尽致。4.2 人工审核机制政务内容发布不能全自动这个没有任何商量余地。我的方案是机器解析出来的“doc”文章创建后状态设为“草稿”同时附带一份解析置信度报告。哪些公式块识别置信度低于90%哪些文本段落疑似顺序错乱后台列表里都标得清清楚楚。子站管理员审核时优先处理这些低置信度项可以一键打开对应PDF页面查看原图对照修改LaTeX源。这个机制在项目初期尤其重要。不是所有管理员都懂LaTeX但政务站点的管理员通常看得懂公式对不对。他们不需要会改代码只需要标记“识别错误”或者“需要修正”系统把这个标记回传给技术团队批量修正后重新入库。实际跑下来前两周的错误率下降幅度非常明显——机器识别加人工抽检的比重从最初的人工全量审核逐步过渡到只审低置信度项。4.3 角色权限与审计留痕政务系统对权限的要求比一般企业站严格得多。上传PDF、触发解析、审核发布这三个动作最好分别对应不同的角色。子站管理员可以上传和审核但不能动解析配置站群管理员能看所有子站的解析日志但不应该直接改别家站的已发布内容。这套权限在WordPress里用自定义角色加能力capability就能实现不需要引入重量级的权限插件。审计日志单独建表存储不能由普通管理员删除只能由站群超级管理员查看。我见过不止一个政务项目验收时因为缺少操作审计被退回整改。这个细节前期就考虑进去后面能省掉很多麻烦。5. 前端展示与公式渲染MathJax还是KaTeX5.1 两种渲染引擎的特点对比WordPress前端渲染LaTeX公式主流选择是MathJax和KaTeX这两个我都实际用过。两者的取舍我总结一下对比项MathJaxKaTeX渲染速度较慢公式多时明显快尤其适合长文档LaTeX语法兼容性极好覆盖几乎全部语法较好但个别复杂公式不支持无障碍支持支持MathML输出支持接近MathML的语义资源体积较大较小政务网站的受众和场景决定了单个页面的公式量通常不会特别大但兼容性和可访问性要求高。我最终选了MathJax原因是它的渲染容错率更高——遇到识别稍有偏差的公式它不会直接渲染失败而是给出一个尽量接近的结果。这套容错机制在实际运行里省了太多“页面公式显示空白”的投诉。如果站群子站数量多访问量差异大可以按站点分开配置。公式量小的站点用MathJax就够了公式特别多的技术类子站可以按需加载KaTeX缩短首屏时间。这个优化不急等站点跑起来、数据有了再按需调整也不晚。5.2 政务网站兼容性和无障碍注意事项政务网站经常要过等级保护和无障碍检测这两件事对公式渲染都有直接影响。我踩过的坑里有这么几个值得拿出来说浏览器兼容性。MathJax默认能在现代浏览器跑但部分政务内网环境还在用老内核的浏览器。办法是把MathJax的配置脚本固定在某个稳定版本不要跟着最新版走否则内网环境容易出现渲染异常。无障碍支持。公式的aria-label、MathML替代文本、页面标题的语义化都要在模板里预留。特别提醒一句如果甲方要求过无障碍评测纯LaTeX渲染出来的公式对读屏软件并不友好最好在公式旁边提供可读的文本描述或者在页面源码里嵌一份MathML。字体本地化。某些政务网站的网络策略禁用了外部字体和CDN。MathJax默认从CDN拉取字体一旦内网策略禁外链公式就渲染不出来。解决办法是把字体文件本地化部署到WordPress目录同时修改MathJax的fontURL配置。这一步特别容易被忽略等验收的时候才暴露那场面就尴尬了。6. 实测中的坑公式识别与版面解析的疑难杂症6.1 公式边界识别错误正文被当成公式这是整个方案里最经常遇到的问题没有之一。有些PDF里的正文行是居中的——比如小标题、副标题——或者某些正文文字用了类似数学风格的字体版面启发式规则就会误判。结果就是正文被裁剪成图片送进公式OCR识别出一堆乱码LaTeX文章入库之后完全没法看。定位方法并不复杂在解析管线的第三步和第四步之间加一道“公式块置信度”检查。把公式块图像的长宽比、字符密度、是否包含常见科学符号作为辅助判断依据。如果一个“公式块”里含有大量中文字符那基本可以断定是误判。我在调试日志里把这个检查结果输出出来一眼就能看出哪些公式块实际上是正文段落。按这个思路迭代了两周误判率显著下降。6.2 双栏PDF的阅读顺序错乱政务报告汇编里双栏排版非常常见PyMuPDF按坐标排序的时候很容易把左栏的下一段和右栏的上一段排在一起。这个问题的根源在于坐标排序只看y值没考虑x值的分段。我的处理方式是先按x坐标分栏再按y坐标排序。具体来说统计一页文字块x坐标的中位数小于中位数的归左栏大于的归右栏栏内再按y排序。对大多数双栏文档这就够了。遇到需要精确分栏的文档先做一次区域内文字密度分析找出栏间隙位置再分别排序。这套逻辑写起来不难但对结果质量的影响是决定性的。6.3 数学符号被错识别成英文字母公式OCR的通病躲不开。Σ被识别成Sπ被识别成nβ被识别成B这类问题对指标型的政务文档影响非常大——一个统计指标公式里符号错了整条公式的业务含义就变了。我的应对办法是建立一份“符号映射词典”。在解析完成后遍历生成的LaTeX文本把可疑的纯文本模式替换成正确的数学符号。比如文本里出现S_且上下文是求和式就把S替换成\sum出现n或3.14且上下文是圆相关公式就替换成\pi。这个词典可以持续积累越用越准。同时识别置信度低的公式块进入人工复核队列防止错误静默入库。运营半年之后这份词典大概积累了两百多条映射规则成了项目里最有价值的资产之一。6.4 隐藏文字层导致重复提取还有一种情况比较隐蔽PDF文字层和图像层都有内容。PyMuPDF先提取到了文字PaddleOCR又把图像层识别了一遍两边的结果不一致入库后同一段内容出现两个版本读者看着就乱了。我的解决方法是“来源标记”每段文本都记录它是来自文字层还是OCR层。同一个位置如果两层都有内容优先信任文字层同时在日志里标注冲突。处理策略是文字层完整且文字量大于阈值时整页走文字层管线OCR只负责公式区域只有在文字层缺失时才整页走OCR。这条规则虽然简单但把重复提取的问题彻底解决了。7. 部署形态与运维经验7.1 组件架构与部署清单整套系统实际跑起来的组件并不复杂列个清单WordPress Multisite主站和子站独立的Python解析服务用FastAPI封装内嵌PyMuPDF和PaddleOCR一个MySQL任务队列表复用WordPress的数据库单独建表一个WP-CLI定时脚本扫描任务队列并调用Python服务。部署上Python解析服务建议单独跑在一台云主机上不要跟Web混布。原因很简单OCR任务吃CPU和GPU资源如果跟Web服务跑在一起高峰期WordPress的响应时间会明显变慢。政务环境如果机器紧张至少要给解析服务设置资源限制或者限制OCR并发数。7.2 稳定性与异常处理PDF解析服务的异常情况比我预想的多。密码保护的PDF、损坏的PDF、超大的扫描版PDF上线第一周就全遇到了。我的建议是把所有异常都兜住Python服务统一捕获异常并返回结构化错误码WordPress侧把错误码映射成中文提示。队列里失败的任务不会被反复重试到把系统拖垮超过两次就直接转人工处理。超时设置也重要单个PDF处理超过五分钟的直接标记超时交给人工避免系统资源被一个异常文件占死。政务环境的系统更新也是个需要注意的点。PaddleOCR的模型文件更新、PyMuPDF的版本升级都可能影响旧文件的解析结果。我的做法是把模型文件固化到服务器目录不自动升级每次有版本调整先跑一遍历史样本回归确认解析结果不劣化之后再切换。8. 实话实说这套方案适合什么样的站点最后聊点实在的适用边界问题。这套方案适合的是公式密度中等、版式相对规范、以公文和报告为主的政务站点。它是半自动的机器做完之后必须有人审核。如果你的站点公式极少一个月就几个PDF直接人工转成Word或LaTeX再贴进WordPress比搭这套管线省事得多——别为了一个月几个文件去养一套OCR服务。如果你的站点公式极多、质量要求极高比如数学教材库、学术期刊库那就要认真评估商用公式识别API的方案。Mathpix这类服务在高精度场景下确实省心但数据合规和按量计费的成本问题得单独谈。我在实际项目里的体会是政务项目里合规性永远排在识别精度前面。先把数据不出域的底线守住再谈识别率。跑通这套方案之后最大的收益不是省了多少人力而是文档资产从“黑盒的PDF附件”变成了“可检索、可复用、可审计的结构化内容”。以后不管是要做站内全文检索、无障碍改造还是把公式数据导出给其他业务系统底子都打好了。要是你也在站群里遇到类似的PDF公式提取需求我的建议是先拿一小批真实样本跑通最小闭环再考虑大规模铺开。这样踩坑的成本最低交付的确定性最高。