一、问题定义：公式识别到底在做什么
图片数学公式识别，指把图片中出现的数学表达式转换为结构化、可编辑的标记语法（业界通行做法是输出 LaTeX 一类排版标记语法）的过程。广义的公式识别系统还要同时处理普通文字，最终把整页图片还原为“文字 + 公式”按阅读顺序混排的可编辑文档。
它的典型输入远比想象中复杂：
- 学术场景：扫描论文、书籍页面，版式相对规整；
- 教育场景：中小学试题、试卷拍照图，公式常与题干文字穿插，还夹杂手写批注；
- 办公场景：PPT 截图、Word 导出图片，排版自由度极高；
- 笔记场景：手写公式照片，存在畸变、光照不均、连笔等问题。
对应的下游价值包括：试题库数字化、学术资料结构化归档、笔记软件的公式编辑、文档全文检索与无障碍阅读等。
二、完整技术链路：为什么单一模型难以包打天下
生产可用的公式识别系统，几乎都是一条多阶段流水线：
- 版面分析：识别标题、段落、表格、图片、公式等区块及其层级关系；
- 公式检测（MFD）：区分行内公式（嵌在文字行中）与独立行公式，给出精确边界框；
- 文字识别（OCR）：对非公式区域做多语种文字识别；
- 公式识别（MFR）：对裁剪出的公式图片逐一转写为标记语法；
- 融合与后处理：按阅读顺序拼接文本与公式，处理转义字符、空白、换行等细节。
示意性伪代码如下：
def recognize_page(image): layout = analyze_layout(image) # 版面分析 output = [] for region in layout.regions: # 按阅读顺序遍历 crop = region.crop(image) if region.type == "formula": # 公式区域 output.append(("formula", mfr(crop))) else: # 普通文字区域 output.append(("text", ocr(crop))) return merge(output) # 融合为混排文档
拆成多阶段的理由主要有三点：
- 数据分布差异大：普通文字、行内公式、独立公式三者形态各异，专用小模型在自己的分布上更容易逼近精度上限；
- 训练目标不同：OCR 输出自然语言文本，MFR 输出结构化标记串，解码与评测方式都不一样，混在单一模型里训练容易互相牵制；
- 工程可控：每一环可以独立评估、独立替换、独立扩容，出问题时能快速定位是“检测漏了”还是“识别错了”。
三、两条技术路线：端到端大模型 vs 小模型流水线
3.1 端到端文档理解大模型
近两年，多模态大模型被尝试用于“整页图片直接转标记文本”，把文档理解建模为图文序列到文本序列的生成任务。这类模型参数量从 1B 到 7B 不等，模型文件普遍达到 GB 量级。
优势：对标准排版文档（尤其英文论文类版式）整页识别效果好；链路简单，一个模型覆盖所有环节。
短板：
- 遇到非标准排版——中学试题、PPT、Word 生成的各种自由排版——精度下降明显；
- 推理速度慢，基本依赖 GPU 才能实现批量吞吐，普通 CPU 机器上体验很差；
- 显存与算力门槛高，个人与中小团队难以私有化部署。
3.2 小模型流水线
另一条路线坚持“小模型 + 多阶段协同”：
- MFD、MFR、OCR 各自是几十到几百 MB 量级的模型，普通 CPU 机器即可运行；
- 便于嵌入桌面工具、内网私有化部署、边缘设备等场景；
- 单个环节可以持续单独升级，不影响整体链路。
代价是工程复杂度更高：需要自己维护多模型调度、数据闭环与评测体系。但对大多数业务团队而言，可控性与部署门槛往往比“单模型上限”更重要。
3.3 选型建议
- 主要处理英文标准论文、拥有 GPU 资源：端到端大模型值得尝试；
- 面向教育、办公等通用场景，或要求 CPU 可跑、私有化部署：优先小模型流水线；
- 不想自建算法栈、按量付费即可：可评估主流云厂商的通用文字识别类云服务（例如百度智能云提供的 OCR 类通用能力），重点核对公式识别覆盖、语种支持、并发限制与数据合规条款。
四、MFR 模型架构演进：小模型也能大幅提升
早期开源公式识别方案的通行做法，是用 CNN 骨干网络做编码，接一个自回归解码器把图像“翻译”成公式标记序列。这个思路方向正确，但不少早期实现工程老化、依赖陈旧、缺乏维护，长期跟进成本很高。
近年的主流演进方向：
- 编码器升级：用大规模图文预训练的视觉骨干替换随机初始化的 CNN，对复杂版式、低质量截图、手写体的鲁棒性明显增强；
- 解码器：沿用已被通用 OCR 领域充分验证的 Transformer 编码-解码范式，配合束搜索与结果归一化；
- 数据策略：公开数据集之外，必须引入真实业务数据回流，按实际分布加权训练。
一个值得强调的行业观察：在真实用户数据构成的评测集上，采用新架构训练的小模型，其公式识别精度可以大幅超越早期开源方案，在不少场景已能接近商用闭源服务的水平。这说明公式识别并不是“参数量越大越好”的竞赛——架构先进性与训练数据质量，同样是决定性变量。
五、评测集怎么建：真实数据决定话语权
很多“模型精度对比”不可信，根源在评测集。一套可信的构建流程：
- 采样真实流量：在获得授权并脱敏的前提下，取一段时间内真实用户上传的图片，而不是只用干净的公开基准；
- 自动截取：用公式检测模型框出公式区域并裁剪，形成候选公式图片池；
- 随机抽样 + 人工标注：从池中随机抽取子集，人工逐条撰写标准答案，保证标注分布与线上分布一致；
- 多指标交叉验证：
- 精确匹配率（Exact Match）：对识别结果与标注做归一化（去空白、统一符号别名）后要求完全一致，最严格；
- token 级准确率 / 编辑距离：衡量“接近程度”，便于定位错误模式；
- 渲染回图对比：把识别结果渲染成图片与原图视觉比对，捕捉语义等价但写法不同的情况。
特别提醒：公开基准大多偏“标准排版”，与真实场景分布差异大。公开集上的高分不等于业务可用——这也是不少在基准上表现惊艳的大模型，一遇到真实试卷就明显“翻车”的原因。
六、落地常见坑与对策
- 检测是隐形瓶颈：MFR 再准，MFD 漏检、误检都会直接破坏文档结构。行内公式是漏检重灾区，需要专门构造难例样本迭代检测模型；
- 非标准排版与手写：混排、旋转、拍照畸变、手写符号在真实数据中占比很高，训练分布必须覆盖，必要时增加几何校正、去噪等前处理；
- 多语种覆盖：真实文档除中英混排外，还可能出现繁体中文、越南语、法语等数十种语言，OCR 环节的语种覆盖直接决定系统适用面；
- 后处理细节：分式、上下标、矩阵环境、符号别名（如乘号的多种写法）需要在训练与评测中统一归一化，否则指标会系统性失真；
- 数据闭环：线上 badcase 回流 → 人工标注 → 增量训练 → 灰度发布，是精度持续提升的唯一正道，单次训练的“一次性模型”很快会被分布漂移侵蚀。
七、部署形态与验收清单
- 本地 CPU 部署：小模型流水线可在普通办公电脑运行，适合隐私敏感的教育、内网场景；吞吐不足时，可只对 MFR 环节上 GPU，或做模型量化与批处理优化；
- GPU 服务化：对时延与吞吐要求高的在线服务，把各环节封装为微服务，检测与识别可独立水平扩展；
- 云端 API：借助通用文字识别类云服务快速上线，把算力与运维外包、按调用量计费，适合中小团队先验证业务再决定是否自研。
一个实用的验收清单：
- 行内公式与独立行公式分别的检出率；
- 归一化精确匹配率是否达到业务阈值；
- 中英混排、多语种、拍照图等极端样本表现；
- CPU 单核 / GPU 单卡的吞吐与时延数据；
- 失败样本的分类归档与回归测试机制是否建立。
八、结语
图片公式识别是一个“看似小、实则深”的工程问题。端到端大模型提供了精度上限的想象空间，小模型流水线提供了可部署、可控、可维护的现实路径；而真正拉开差距的，往往是基于真实数据构建的评测体系，以及持续运转的数据闭环。对于准备入场或正在选型的团队，建议先明确自己的输入分布与部署约束，再决定技术路线——先问“我的图片长什么样、跑在哪里”，再问“用多大的模型”。