图片数学公式识别：技术路线与工程实践详解

把一张含有数学公式的图片准确转成可编辑的 LaTeX 文本，看似只是 OCR 的一个子任务，实际上是文档智能领域公认的难点之一。本文从问题本质出发，拆解主流技术路线，并覆盖数据、评测、部署等工程落地细节。

一、为什么公式识别是 OCR 领域的“硬骨头”

普通文字识别处理的是一维线性文本：从左到右、从上到下逐行转写即可。数学公式则本质上是一种二维结构：上下标可以多层嵌套，分式的分子分母垂直排布，根号、积分号、求和号这类巨型算符的“作用范围”由几何位置决定，矩阵与行列式还要求多行严格对齐。识别系统不仅要看清每个符号，还必须理解符号之间的空间关系，并将其正确映射为线性化的 LaTeX 序列。

难度还不止于此。真实场景中，公式极少孤立出现：它与正文文字混排，需要区分行内公式与独立成行的公式块；中英文符号经常同框；试题卷、课件、办公文档的排版千奇百怪，拍照还会引入倾斜、模糊与阴影。符号集本身也极其庞大且充满形近字符（例如 l 与 1、O 与 0）。因此在讨论任何方案之前，先要明确目标数据分布——“标准排版的论文截图”与“一张中学试题照片”，是两个完全不同难度的世界。

二、任务拆解：一个完整系统其实是条流水线

工程上成熟的图片公式识别系统，通常不是单个模型，而是拆解为四个职责清晰的模块：

1. 版面分析：判断图片的阅读顺序与区域结构；
2. 公式检测（MFD）：框出公式区域，并区分行内公式与独立公式，这是决定后续流程走向的关键一步；
3. 公式识别（MFR）：把公式区域的小图转写成 LaTeX 字符串；
4. 通用文字 OCR：处理其余普通文字区域。

最后按坐标与阅读顺序，将各区域结果拼装为“文字 + 公式”混合的 Markdown/LaTeX 文档。示意性伪代码如下：

def recognize(image):
    regions = layout_analyze(image)          # 版面分析与区域切分
    outputs = []
    for r in regions:
        crop = image[r.box]
        if r.type in ("inline_formula", "display_formula"):
            latex = mfr_model(crop)          # 公式 -> LaTeX
            wrap = "$%s$" if r.type == "inline_formula" else "$$%s$$"
            outputs.append((r.box, wrap % latex))
        else:
            outputs.append((r.box, ocr_model(crop)))
    return merge_in_reading_order(outputs)   # 按阅读顺序拼装

拆分的收益很直接：每个模块可独立迭代、独立替换、独立评测；单个模型足够小，普通 CPU 机器就能跑；线上出问题时可以精确定位是检测漏框还是识别写错。

三、两条技术路线：端到端大模型 vs 流水线小模型

近两年随着大模型的发展，不少团队尝试把“公式图片 → LaTeX”当作纯粹的序列生成任务，直接交给多模态大模型端到端求解，开源社区也出现了若干权重，参数量从数亿到数十亿不等，模型文件动辄以 GB 计。

这条路线流程简单，对标准排版、英文文字背景的文档页确实能取得可观精度。但工程短板同样明显：其一，资源门槛高，基本要在 GPU 上才能批量运行，CPU 推理慢到难以实用；其二，能力集中在“标准排版”分布上，换成试题、课件或办公文档的随意排版，精度会明显下滑；其三，端到端黑盒难以分模块优化。

与之相对的是流水线小模型路线：把每个模块控制在几十到几百 MB 的量级，保证普通 CPU 服务器可运行；同时通过“开源基础模型 + 可选的高精度商用模型”的组合，兼顾社区生态与商业可持续性。这条路线的核心竞争力不在单点模型的绝对精度，而在数据闭环带来的持续迭代能力。

四、公式识别模型架构的演进

早期开源方案多采用“CNN 特征提取 + 自回归解码”的组合，但不少实现年久失修、依赖陈旧，维护成本很高。当前更主流的做法是采用 Transformer 编码器-解码器架构：编码器用卷积骨干或视觉 Transformer 提取视觉特征序列，解码器以自回归方式逐 token 生成 LaTeX 字符串。

架构之外，训练细节往往才是精度分水岭，几条通用经验值得注意：

• 标签归一化：同一公式在 LaTeX 中有多种等价写法，不归一化会同时污染训练目标与评测结果；
• 数据增广：旋转、模糊、噪声、分辨率扰动、字体替换，用于弥合渲染数据与真实拍照数据的分布差异；
• 解码策略：束搜索与长度惩罚能显著改善复杂公式的生成质量；
• 课程学习：先掌握单行简单公式，再逐步引入多行、深度嵌套的样本。

五、训练数据与评测集怎么建

数据来源通常有三类：人工标注的公开数据（质量高但量少、风格窄）、LaTeX 源码渲染得到的合成数据（量大但与真实分布有差距），以及最有价值的真实数据闭环——从线上真实用户上传的图片出发，用公式检测模型自动截取公式区域，再抽样交由人工标注。这条链路构建的数据天然覆盖试题、课件等非标准排版，用它做评测远比只用渲染数据有说服力。

评测指标建议多维并用：精确匹配率衡量“完全写对”的比例；编辑距离或 BLEU 给部分正确的样本以部分得分；更公平的做法是把识别结果重新渲染成图片，与原图做图像相似度对比，天然容忍 LaTeX 的等价写法。评测集本身也要分层报告：印刷体与手写体、行内与独立公式、简单与复杂结构、中文与英文背景，才能看清系统的真实边界。

六、工程部署与性能优化

部署层面，CPU 场景优先做模型量化与输入分辨率控制，并利用批处理摊薄单张延迟；GPU 场景可用动态 batching 与推理引擎加速。服务化时要设计好超时与降级策略——对超时未返回的复杂公式，宁可降级返回原图占位，也不要阻塞整页结果。此外，公式识别的高频场景集中在教育与科研，数据敏感度不低，“能否完全本地化部署”往往是一票否决的选型条件。

七、自建模型还是使用云服务？

如果团队有定制排版需求、隐私合规要求或超大规模调用量，自建 MFD + MFR 流水线值得投入；如果只是快速验证或中小规模使用，可以先评估文字识别类云服务。以百度智能云的文字识别（OCR）类服务为例，其覆盖通用文字、表格等常见场景，可承担流水线中的文字模块；公式模块再组合自研或专项训练的模型，形成“云端文字 + 本地公式”的混合架构，在成本与可控性之间往往是不错的平衡点。

八、选型清单与趋势展望

落地前不妨用这份清单过一遍：是否区分行内与独立公式？是否支持中英文混排？CPU 能否跑起来还是必须 GPU？输出是纯 LaTeX、混合 Markdown 还是可二次编辑的文档格式？评测是否基于真实数据？是否开源、可否用自己的数据继续训练？能否本地化部署？

往前看，两个趋势值得关注：一是大小模型协同，用小模型扛住主流量、用大模型兜底处理疑难样本；二是识别结果结构化后催生的下游能力——当公式被转成可计算的 LaTeX 之后，数学内容的检索、比对与自动判题才真正成为可能。