电信开源TeleOCR：1.2B参数文档解析模型，ICDAR科学图解析冠军方案解析

1. 从一张科学图表说起：为什么文档解析远不止“认字”这么简单

如果你做过文档数字化相关的项目，大概率经历过这样的场景：一张学术论文里的折线图，横轴是温度、纵轴是转化率，图例区分了三种催化剂，旁边还有一堆标注和误差棒。你拿传统的 OCR 工具去跑，它能把图里的文字一个个抠出来，但抠出来之后呢？你得到的是“温度”“转化率”“催化剂A”这些散落的词，至于谁对应哪条曲线、哪个点属于哪个系列、坐标轴的范围是多少，全靠人脑去猜。这就是传统 OCR 和真正的文档解析之间的鸿沟。

电信这次开源的 TeleOCR，做的事情就是填这条鸿沟。它是一个 1.2B 参数量的文档解析模型，在 ICDAR-2026 科学图解析挑战赛上拿了冠军。1.2B 参数是什么概念？放在今天的大模型语境里，这个体量算轻量级，但放在文档解析这个细分赛道上，它已经足够处理相当复杂的版面理解和结构化抽取任务。更关键的是，它选择了开源，这意味着做文档智能、学术数据挖掘、报表自动化的人，多了一个可以直接上手折腾的基座。

这篇文章适合谁看？如果你是做文档智能产品的工程师，正在纠结自研还是调 API，TeleOCR 值得你花时间研究；如果你是学术数据挖掘方向的研究者，需要批量处理论文里的图表信息，这个模型能帮你省掉大量手工标注；如果你只是对 OCR 和文档解析感兴趣，想搞清楚“科学图解析”到底难在哪，我也会把技术脉络拆开讲清楚。下面我从设计思路、核心细节、实操流程、问题排查几个维度，把 TeleOCR 这套东西掰开揉碎聊一遍。

2. 内容整体设计与思路拆解

2.1 为什么科学图解析是文档解析的“硬骨头”

普通文档 OCR 的目标很明确：把图片里的文字转成可编辑文本。版面分析稍微复杂一点，要区分标题、正文、表格、图片区域。但科学图解析完全是另一个维度的任务。一张典型的学术图表包含以下信息层：

• 文本层：坐标轴标签、图例文字、数据点标注、标题、脚注
• 几何层：坐标轴的刻度线、网格线、数据点的位置、曲线的走向
• 语义层：哪个图例对应哪条曲线、数据点属于哪个系列、坐标轴的单位和量纲
• 关系层：多个子图之间的关联、图与正文的引用关系

传统方案通常是“检测+识别+后处理”的流水线：先用目标检测模型框出文字区域，再用 OCR 识别文字，最后用规则或小模型去关联几何信息和语义信息。这条流水线的问题在于，每一步都会累积误差，而且后处理规则很难覆盖所有图表样式。TeleOCR 的思路不一样，它走的是端到端的文档解析路线，把版面理解、文字识别、结构抽取放在一个统一的模型框架里做。

2.2 1.2B 参数的选择逻辑：够用、能跑、可微调

为什么是 1.2B 而不是 7B 或 13B？这个问题我在看到模型卡的时候第一反应就是算账。科学图解析的训练数据不像通用文本那样容易获取，高质量的标注数据需要领域专家参与，成本极高。如果参数量太大，训练和微调的门槛都会飙升，很多中小团队根本玩不转。1.2B 这个量级，单张 24G 显存的卡就能做推理，微调的话用 LoRA 或者 QLoRA 在消费级显卡上也能跑起来。

另一个考虑是推理延迟。文档解析往往是批量任务，一个项目动辄几万页 PDF，如果单页推理要好几秒，整体吞吐量就崩了。1.2B 的模型在优化后的推理框架里，单页处理时间可以压到几百毫秒级别，这个速度对于大多数生产场景是可接受的。电信选这个参数量，明显是做过工程权衡的，不是单纯追求榜单分数。

2.3 开源策略背后的考量：生态卡位与标准制定

TeleOCR 选择开源，而且是在拿冠军之后开源，这个时间点很有意思。ICDAR 挑战赛的冠军头衔是技术实力的背书，开源则是生态卡位的动作。文档解析这个领域，目前还没有一个像 ImageNet 之于图像分类那样公认的基座模型。大家各做各的，数据格式、评测标准、工具链都不统一。TeleOCR 开源出来，如果社区跟进得多，它就有可能成为这个细分领域的事实标准。

从技术角度看，开源也意味着模型要经得起复现。挑战赛的评测集和真实场景之间有差距，开源之后会有大量开发者拿自己的数据去测，反馈回来的 bad case 能帮助团队持续迭代。这种“比赛验证+开源反馈”的循环，比闭门造车效率高得多。

3. 核心细节解析与实操要点

3.1 模型架构的关键设计：多模态融合怎么做

TeleOCR 的架构细节官方还没有完全披露，但从它处理的任务类型和 1.2B 的参数量来推断，大概率是视觉编码器加文本解码器的多模态结构。视觉侧需要一个能捕捉精细几何信息的 backbone，因为科学图里的数据点位置、曲线走向这些信息，对分辨率要求很高。文本侧则需要一个能理解版面关系的解码器，把视觉特征映射成结构化的输出。

这里有个关键设计点：位置编码。普通文档 OCR 对绝对位置不敏感，文字识别对了就行。但科学图解析必须知道每个元素在坐标系里的相对位置。如果位置编码设计得不好，模型分不清“图例在右上角”和“图例在左下角”的区别，后续的语义关联就会出错。我推测 TeleOCR 在视觉编码阶段用了可变形注意力或者类似的机制，让模型能自适应地关注图表中的关键区域。

另一个重点是输出格式的设计。端到端模型需要把图表信息序列化成某种结构化表示，常见的选择有 JSON、Markdown 表格、或者自定义的标记语言。从挑战赛的任务设置来看，TeleOCR 的输出应该包含了文本内容、边界框坐标、以及元素之间的关联关系。这种多任务联合训练的方式，能让模型在识别文字的同时学习版面结构，比流水线方案更鲁棒。

3.2 训练数据的构建：合成数据与真实数据的配比

科学图解析的训练数据是最大的瓶颈。真实学术论文里的图表，版权分散、格式各异，要拿到大规模标注数据几乎不可能。所以 TeleOCR 的训练集大概率是“合成数据为主，真实数据为辅”的策略。

合成数据的生成 pipeline 通常包括：用绘图库（matplotlib、plotly 等）批量生成各种类型的图表，同时记录每个元素的精确坐标和语义标签。这种方式的优势是标注成本几乎为零，而且可以控制变量，比如专门生成一批“图例在右侧、有三条曲线、坐标轴是对数刻度”的样本，让模型针对性学习。但合成数据和真实数据之间有 domain gap，真实论文里的图表会有扫描噪声、压缩伪影、手写标注、非标准字体等问题。所以训练时需要用真实数据做微调，或者用数据增强来缩小差距。

我个人的经验是，合成数据和真实数据的比例控制在 7:3 到 8:2 之间比较合适。合成数据保证覆盖度和标注精度，真实数据保证泛化能力。如果真实数据太少，模型在遇到没见过的图表样式时容易崩。

3.3 评测指标解读：为什么冠军含金量高

ICDAR-2026 科学图解析挑战赛的评测指标，我查了一下，主要包括文本识别的准确率、结构抽取的 F1 值、以及端到端解析的综合得分。文本识别这块，传统 OCR 已经做得不错了，拉开差距的主要是结构抽取。

结构抽取的难点在于关系预测。比如一张图里有三个子图，每个子图有自己的坐标轴和图例，模型需要正确判断哪个图例属于哪个子图，哪个数据点属于哪个系列。这种关系预测任务，用传统的规则方法几乎做不了，因为规则很难穷举所有可能的版面组合。TeleOCR 能拿冠军，说明它在关系建模这块有独到之处，可能是用了图神经网络或者注意力机制来捕捉元素之间的依赖关系。

另一个值得关注的点是鲁棒性。挑战赛的测试集通常会包含一些“刁钻”的样本，比如低分辨率、旋转、遮挡、多语言混排等。TeleOCR 在这些样本上的表现，比单纯的准确率数字更能说明问题。

4. 实操过程与核心环节实现

4.1 环境准备与模型获取

TeleOCR 开源之后，获取方式无非几种：从官方仓库克隆代码，从模型托管平台下载权重，或者用 Docker 镜像一键部署。我建议优先走官方仓库的路线，因为文档解析这类任务，预处理和后处理的代码往往和模型权重同等重要，只拿权重不拿代码，很多细节对不上。

环境依赖方面，PyTorch 是跑不掉的，版本建议跟官方要求对齐。视觉编码器可能依赖一些特定的算子库，比如 detectron2 或者 mmcv，这些库的版本兼容性是个坑，装的时候要仔细看 requirements。如果不想折腾环境，等社区出 Docker 镜像或者 conda 包会省事很多。

# 假设的安装流程，具体以官方文档为准 git clone https://github.com/telecom/teleocr.git cd teleocr pip install -r requirements.txt # 下载预训练权重 python scripts/download_weights.py --model teleocr-1.2b

注意：模型权重文件通常比较大，1.2B 参数按 FP16 算大概 2.4G 左右，下载的时候确保网络稳定。如果官方提供了多个版本的权重（比如 base、large、champion），优先用 champion 版本，那是比赛验证过的最优配置。

4.2 输入预处理：PDF 转图像的质量控制

文档解析的第一步是把 PDF 或扫描件转成图像。这一步的质量直接决定后续解析的上限。我踩过的坑包括：DPI 设太低导致小字模糊，DPI 设太高导致推理速度暴跌，页面旋转角度没校正导致版面分析错乱。

我的经验值是：DPI 设在 200 到 300 之间。200 对于大多数印刷体文档够用了，300 适合小字密集或者有精细图表的场景。如果原始 PDF 是矢量格式，尽量用矢量渲染而不是截图，这样能避免重采样带来的模糊。

页面预处理还包括：去噪、二值化、倾斜校正、边界裁剪。这些操作看起来简单，但参数没调好会引入新的问题。比如二值化阈值设得太高，浅色的图例文字会被抹掉；倾斜校正的角度估计不准，反而把正的页面转歪了。建议先用小批量样本试跑，确认预处理效果后再批量处理。

4.3 推理与后处理：从模型输出到结构化数据

模型推理的输出通常是 token 序列或者 JSON 结构。如果是 token 序列，需要按照预定义的格式解析成结构化数据。这一步的关键是容错处理。模型不可能 100% 准确，输出里可能会有格式错误、缺失字段、坐标越界等问题。后处理代码要能识别这些异常，并决定是丢弃、修正还是标记为待人工复核。

坐标系的转换也是个容易出错的环节。模型输出的坐标通常是相对于输入图像的像素值，但业务系统可能需要的是相对于 PDF 页面的坐标，或者归一化到 0-1 范围。转换的时候要注意图像的缩放比例和裁剪偏移，否则坐标会对不上。

# 坐标转换的示意逻辑 def convert_coords(bbox, img_size, page_size, crop_offset): """ bbox: [x1, y1, x2, y2] 相对于输入图像 img_size: (width, height) 输入图像尺寸 page_size: (width, height) PDF 页面尺寸 crop_offset: (x, y) 裁剪偏移 """ scale_x = page_size[0] / img_size[0] scale_y = page_size[1] / img_size[1] x1 = (bbox[0] + crop_offset[0]) * scale_x y1 = (bbox[1] + crop_offset[1]) * scale_y x2 = (bbox[2] + crop_offset[0]) * scale_x y2 = (bbox[3] + crop_offset[1]) * scale_y return [x1, y1, x2, y2]

4.4 批量处理与性能优化

生产环境里，单页推理和批量推理是两码事。批量处理要考虑显存管理、并发控制、失败重试、进度追踪。我的做法是把任务拆成“预处理-推理-后处理”三个阶段，每个阶段用独立的队列和 worker 池。预处理和后处理是 CPU 密集型，推理是 GPU 密集型，分开之后资源利用率更高。

显存管理方面，如果批量大小设得太大，容易 OOM；设得太小，GPU 利用率上不去。建议从 batch_size=1 开始测，逐步增加，找到显存占用的拐点。另外，混合精度推理（FP16）能显著降低显存占用，对精度的影响通常在可接受范围内。

实操心得：批量处理的时候，一定要加 checkpoint 机制。几万页的任务跑几个小时，中间挂掉一次全部重来，心态会崩。每处理完一批就写一次进度文件，重启的时候从断点继续。

5. 常见问题与排查技巧实录

5.1 识别结果错位：文字和坐标对不上

这是文档解析里最常见的问题。表现是识别出来的文字内容是对的，但边界框的位置偏了，导致后续的结构关联出错。原因通常有几个：预处理阶段的裁剪偏移没有正确传递到后处理；模型输出的坐标格式和预期不一致（比如是 [x, y, w, h] 而不是 [x1, y1, x2, y2]）；图像缩放时没有同步缩放坐标。

排查方法：先可视化。把模型输出的边界框画在原图上，肉眼看一下偏了多少、往哪个方向偏。如果是系统性偏移，大概率是坐标转换的问题；如果是随机偏移，可能是模型本身的不确定性。可视化工具用 OpenCV 或者 PIL 都行，几行代码的事。

5.2 复杂图表解析失败：多子图、嵌套图例、非标准布局

科学图里有一类“变态”样本：一张图里嵌了四五个子图，每个子图有自己的坐标轴和图例，图例里还有嵌套的标记。这种样本对模型的版面理解能力要求极高。TeleOCR 虽然在挑战赛上表现好，但遇到训练分布之外的布局，仍然可能翻车。

应对策略：如果业务场景里这类复杂图表占比高，建议在 TeleOCR 的基础上做微调，用自己标注的数据补足短板。如果只是偶尔遇到，可以在后处理阶段加规则兜底，比如检测到多个子图区域时，分别调用模型解析，再人工合并结果。

5.3 推理速度慢：从数据管道找瓶颈

模型推理慢，不一定全是模型的锅。我遇到过的情况包括：图像预处理用了太重的库，单页处理耗时比推理还长；数据加载没有用多进程，GPU 经常等数据；后处理里的正则表达式写得低效，大量时间花在字符串匹配上。

排查思路：用 profiling 工具把整个 pipeline 的耗时拆开，看时间花在哪个阶段。如果是预处理慢，换更轻量的图像库，或者把预处理结果缓存起来；如果是数据加载慢，调大 DataLoader 的 num_workers；如果是后处理慢，优化算法或者用 C 扩展加速。

5.4 常见问题速查表

5.5 独家避坑技巧：来自实际项目的经验

第一个技巧：建立回归测试集。每次调整预处理参数、模型版本、后处理逻辑，都跑一遍固定的测试集，对比关键指标。没有回归测试，改了一个地方崩了另一个地方，根本发现不了。

第二个技巧：日志要记全。每页的处理时间、模型输出的原始结果、后处理的中间状态，都记下来。出问题的时候，没有日志就只能靠猜，有日志能直接定位到具体环节。

第三个技巧：人工复核界面要早做。模型不可能 100% 准确，总有一部分需要人工介入。与其等到最后手忙脚乱，不如一开始就把复核界面搭好，让标注人员能高效地修正错误。复核数据还能反哺模型迭代，形成正向循环。

6. 工具选型与生态对比：TeleOCR 在文档解析赛道的位置

6.1 与传统 OCR 工具的对比

Tesseract、PaddleOCR 这些传统 OCR 工具，强项是文字识别，弱项是版面理解和结构抽取。如果你只需要把图片里的文字转成文本，它们够用而且轻量。但科学图解析这种任务，传统工具基本做不了，因为它们没有关系建模的能力。

TeleOCR 的定位不一样，它是文档解析模型，不是单纯的 OCR。文字识别只是它的一个子任务，更重要的是版面分析和结构抽取。这就好比一个是“认字”，一个是“读懂”，层次不同。

6.2 与通用多模态大模型的对比

GPT-4V、Claude 这些通用多模态大模型，在文档理解任务上表现也不错，甚至在某些场景下比专用模型更好。但它们的问题是：推理成本高、延迟大、数据隐私不可控。对于批量处理几万页文档的场景，用通用大模型跑，成本会高到离谱。

TeleOCR 的优势在于专用和轻量。1.2B 的参数量，单卡就能部署，推理速度快，数据不出本地。对于有数据隐私要求或者成本敏感的场景，专用模型是更务实的选择。

6.3 选型建议：什么场景该用 TeleOCR

我的建议是分场景看：

• 学术数据挖掘：TeleOCR 很合适，科学图解析是它的强项，开源之后可以自由微调。
• 企业报表自动化：如果报表格式固定，传统模板匹配可能更简单；如果格式多变，TeleOCR 的泛化能力更有优势。
• 文档数字化归档：需要批量处理、成本敏感，TeleOCR 的轻量特性适合。
• 实时交互场景：如果对延迟要求极高，可能需要进一步优化或者用更小的模型。

注意：TeleOCR 是开源项目，但开源不等于免费无限制。使用前仔细看许可证，确认商用条款和数据使用限制。另外，开源项目的维护节奏不确定，如果用在生产环境，要有自己维护分支的心理准备。

7. 从冠军模型到生产落地：还需要补哪些课

7.1 领域适配：通用模型不等于万能模型

TeleOCR 在 ICDAR 挑战赛上拿冠军，说明它在学术图表这个领域很强。但你的业务数据可能和学术图表差别很大，比如工程图纸、医疗报告、财务报表。这些领域的图表样式、术语体系、版面规范都不一样，直接拿通用模型跑，效果可能打折扣。

领域适配的路径通常是：先用通用模型跑一批数据，找出错误集中的模式；然后针对这些模式标注一批领域数据；最后用 LoRA 或者全量微调的方式让模型适应新领域。微调的数据量不需要很大，几百到几千个样本通常就能看到明显提升。

7.2 工程化：从 demo 到生产系统的距离

跑通一个 demo 和上线一个生产系统，中间隔着十万八千里。生产系统要考虑：高可用（模型挂了怎么办）、可扩展（流量涨了怎么扩）、可观测（出问题了怎么查）、可回滚（新版本效果差怎么退）。

我的经验是，模型服务化用 Triton 或者 TorchServe 这类框架，比裸写 Flask 接口靠谱得多。它们内置了批处理、并发控制、模型版本管理这些生产必需的功能。监控方面，除了常规的 CPU/GPU/内存指标，还要监控业务指标，比如解析成功率、平均处理时间、人工复核率。

7.3 持续迭代：数据飞轮怎么转起来

模型上线不是终点，而是起点。生产环境产生的数据，是迭代模型最宝贵的资源。关键是要建立数据飞轮：用户使用产生数据，数据经过筛选和标注变成训练集，训练集更新模型，新模型提升用户体验，吸引更多用户。

这个循环里，最容易被忽视的是数据筛选。不是所有生产数据都值得标注，要优先选那些模型置信度低、人工修正多、业务价值高的样本。盲目标注大量简单样本，对模型提升帮助有限。

8. 我个人在实际操作中的体会

折腾 TeleOCR 这段时间，最大的感受是：文档解析这个领域，模型能力只是一部分，工程细节决定成败。同样的模型，预处理做得好不好、后处理鲁棒不鲁棒、批量调度合不合理，最终效果能差出一大截。

另一个体会是，开源模型的价值不仅在于省了训练成本，更在于它提供了一个可复现的基线。有了这个基线，你可以快速验证自己的想法，不用从零开始造轮子。但开源模型也不是银弹，它解决的是通用问题，你的特定场景还是需要自己补数据、做微调。

最后分享一个小技巧：如果你要评估 TeleOCR 是否适合你的场景，不要只看论文里的指标，自己构造一个 50 到 100 页的测试集，覆盖你业务里最常见的图表类型，跑一遍看实际效果。这个测试集的构建成本不高，但能帮你避免选型失误带来的大坑。模型选型这件事，实测永远比看榜单靠谱。