尧图网页设计 
1. 从 OmniDocBench 榜单说起TeleOCR 凭什么排到第一第一次看到 TeleOCR 在 OmniDocBench 上排到第一我的反应是又一个刷榜的。做 OCR 这行久了见过太多在特定测试集上分数漂亮、一换真实文档就原形毕露的模型。但把 OmniDocBench 的评测维度拆开看之后我改变了看法——这个榜单不是单纯比字认得准不准它考的是文档解析的完整链路版面分析、阅读顺序还原、表格结构识别、公式识别、多栏混排处理最后才是文本识别准确率。能在这个榜单上排第一说明 TeleOCR 不是单点强而是整条链路都稳。OmniDocBench 这类基准的设计思路本质上是冲着真实场景去的。你随便拿一份扫描版的产品手册、一份带合并单元格的财务报表、一篇双栏排版的学术论文丢进去传统 OCR 工具的表现往往是文字认出来了但顺序全乱表格认出来了但行列对不上公式直接变成一堆乱码符号。TeleOCR 在这几个维度上的综合表现是它登顶的核心原因。这篇文章适合谁看如果你正在做文档数字化、票据结构化提取、合同关键字段抽取、问卷拍照识别这类项目或者你被 Tesseract 的版面还原能力折磨过、被某度 OCR 的 file format error 卡过、被 PaddleX 识别不了韩文坑过那这篇内容应该能帮你少走不少弯路。我会从架构原理、实测对比、落地代码、踩坑经验几个角度把 TeleOCR 这个东西讲透。需要先说明一点TeleOCR 目前公开的详细技术文档不算多下面涉及架构和参数的部分一部分来自官方披露一部分是我基于同类文档解析模型如 LayoutLM 系列、Donut、以及各类端到端文档理解模型的通用实践做的合理推断我会明确标注哪些是推断。这样你读的时候心里有数不会把推测当成官方结论。2. TeleOCR 的架构拆解它到底和传统 OCR 差在哪2.1 传统 OCR 的两段式瓶颈要理解 TeleOCR 的价值得先搞清楚传统 OCR 是怎么工作的。以 Tesseract 为代表的老一代工具走的是检测识别两段式先用连通域分析或者简单的文本检测算法找出文字块再对每个文字块做字符识别。这个架构有个致命问题——它把文档当成一堆孤立的文字块而不是一个有结构的整体。结果就是你给它一张双栏排版的 PDF 截图它可能把左栏第一行和右栏第一行拼在一起你给它一张带表格的发票它认得出所有数字但完全不知道哪个数字属于金额、哪个属于税额。这就是为什么很多人用 Tesseract 做票据识别最后还得自己写一堆正则和坐标判断逻辑来还原结构——因为 OCR 引擎本身不给你结构。PaddleOCR 这类新一代工具在检测和识别精度上提升很大但本质上还是检测框识别文本的输出范式。你要做结构化还是得在它上面再套一层版面分析模型。而 PaddleX 那条 pipeline 报错识别不了韩文很多时候也不是识别模型的问题而是语言配置和字典没对上——这个坑我后面会专门讲。2.2 TeleOCR 的端到端思路TeleOCR 走的是端到端文档解析路线。它不再把检测和识别当成两个独立任务而是把整张文档图像作为一个整体输入直接输出结构化的文档表示——包括每个文本块的内容、位置、层级关系、阅读顺序以及表格、公式等特殊元素的语义结构。这种架构的核心在于视觉-语言联合建模。模型在训练时不仅学习这个区域是什么字还学习这个区域在文档中扮演什么角色——是标题、是正文、是表头、还是脚注。有了这层语义理解阅读顺序的还原就自然多了模型知道标题下面应该跟正文表头下面应该跟数据行而不是靠坐标硬排。我推测 TeleOCR 的架构大概率包含三个模块一个视觉编码器把文档图像切成 patch 并提取特征、一个文本解码器生成结构化输出、以及一个版面感知的注意力机制让模型在处理某个区域时能看到它在整页中的位置关系。这套思路和 Donut、LayoutLMv3 是一脉相承的但 TeleOCR 在 OmniDocBench 上的表现说明它在训练数据和后处理上做了不少工程优化。2.3 为什么阅读顺序才是真正的难点很多人以为 OCR 的难点是认字其实认字早就不是瓶颈了——印刷体识别准确率普遍在 99% 以上。真正的难点是阅读顺序还原。举个真实例子一份三栏排版的学术论文中间插了一个跨栏的表格表格下面还有一段跨栏的图注。人类读者一眼就知道先读左栏、再读中栏、再读右栏遇到跨栏元素就横着读。但机器不知道。传统 OCR 按坐标从上到下、从左到右排遇到跨栏元素就彻底乱套。TeleOCR 在这方面的处理我实测下来感觉它是先做版面区域划分再在每个区域内做顺序还原最后处理跨区域元素。这个逻辑听起来简单但实现起来需要对文档类型有很强的先验知识。这也是为什么它在 OmniDocBench 这种综合榜单上能拿高分——榜单里专门有阅读顺序的评测项。3. 实测对比TeleOCR vs Tesseract vs 云 OCR3.1 测试集设计光说架构没意义得看实测。我设计了一个小测试集覆盖四类典型文档文档类型特点难点双栏学术论文含公式、图表、跨栏元素阅读顺序、公式识别财务报表含合并单元格、多级表头表格结构还原扫描版合同含印章、手写签名、倾斜抗干扰、字段抽取问卷拍照含勾选框、手写填空非标准版面、手写识别每类文档准备 10 份分别用 TeleOCR、Tesseract 5.x、以及某主流云 OCR 跑一遍人工评估结构化输出的可用性。3.2 结果对比维度TeleOCRTesseract 5.x云 OCR纯文本准确率高中高高阅读顺序还原优差中表格结构识别优无中公式识别良无差手写识别中差中高离线部署支持支持不支持长文档批量处理优中受接口限制几个关键观察Tesseract 在纯印刷体上其实不差尤其是英文文档准确率能到 98% 以上。但它的输出是一堆带坐标的文本行你要做结构化得自己写大量后处理。而且它对中文的版面处理明显弱于英文双栏中文文档经常串行。云 OCR 的表格识别是半结构化的它给你一个 HTML 或者 JSON但合并单元格的处理经常出错多级表头基本还原不了。而且云 OCR 有个绕不开的问题——数据隐私和接口限制。你做合同、票据这类敏感文档数据出不了内网云 OCR 直接出局。另外那个file format error的报错我遇到过好几次多半是图片格式或者 base64 编码的问题云 OCR 对输入格式的容错性其实没想象中好。TeleOCR 的优势在于开箱即用的结构化。它输出的不是文本行而是带层级的文档树。表格给你还原成行列结构公式给你转成 LaTeX阅读顺序直接按人类习惯排好。这意味着你拿到输出后后处理工作量能减少一大半。3.3 一个具体的表格还原案例拿一份带合并单元格的财务报表测试。表格大概长这样| 项目 | 第一季度 | 第二季度 | | | 收入 | 支出 | 收入 | 支出 | | 主营业务 | 1200 | 800 | 1350 | 850 | | 其他业务 | 300 | 200 | 320 | 210 |Tesseract 的输出是 12 个独立的文本块你得自己判断哪个是表头、哪个是数据。云 OCR 输出一个 HTML 表格但第一季度和第二季度的 colspan 经常丢。TeleOCR 直接输出嵌套的 JSON 结构表头层级和数据行的对应关系是完整的。这个差异在简单表格上不明显但表格一复杂差距就拉开了。4. 落地实操把 TeleOCR 接进你的项目4.1 环境准备与安装TeleOCR 的部署方式我建议优先考虑容器化因为文档解析模型依赖比较多裸机装容易出依赖冲突。基本流程是拉取官方镜像挂载模型权重目录暴露推理端口。如果你要在 Python 项目里直接调用大致是这样from teleocr import DocumentParser parser DocumentParser( model_path/path/to/teleocr-weights, devicecuda:0, # 没有 GPU 就用 cpu langch_en, # 中英混合 enable_tableTrue, # 开启表格识别 enable_formulaTrue, # 开启公式识别 ) result parser.parse(contract_scan.jpg) print(result.to_markdown()) # 直接输出 Markdown print(result.to_json()) # 输出结构化 JSON这里有几个参数值得注意。lang参数决定了识别用的字典和后处理规则如果你要识别韩文、日文一定要显式指定语言否则默认字典里没有对应字符识别结果会变成一堆问号或者乱码——这正是很多人用 PaddleX 那条 pipeline 识别不了韩文的根本原因不是模型不行是语言没配对。4.2 批量处理长文档的策略单张图片解析很简单但真实项目往往是几百页的 PDF。我的做法是先做页面级并行再做文档级合并。from concurrent.futures import ThreadPoolExecutor from teleocr import DocumentParser parser DocumentParser(model_path/path/to/weights, devicecuda:0) def parse_page(page_image): return parser.parse(page_image) # PDF 先转成单页图片 pages pdf_to_images(annual_report.pdf, dpi200) with ThreadPoolExecutor(max_workers4) as executor: results list(executor.map(parse_page, pages)) # 合并时保留页码顺序处理跨页表格 full_doc merge_pages(results)这里有个坑跨页表格。一份表格如果从第 3 页延续到第 4 页单页解析会把它们当成两个独立表格。我的处理方式是解析完后检查相邻页面的表格结构如果列数一致且第 4 页表格没有表头就尝试合并。这个逻辑不复杂但能显著提升长文档的解析质量。4.3 和下游系统的对接TeleOCR 输出的结构化 JSON可以直接喂给下游的字段抽取模块。比如合同场景你要抽甲方乙方金额签署日期这些字段可以在 TeleOCR 输出的文档树上做规则匹配或者接一个 NER 模型。import json doc json.loads(result.to_json()) def extract_fields(doc): fields {} for block in doc[blocks]: text block[text] if 甲方 in text: fields[party_a] text.split()[-1].strip() if 金额 in text: fields[amount] extract_amount(text) return fields因为 TeleOCR 已经帮你把阅读顺序和层级关系理清了这里的规则匹配会比在原始 OCR 文本上做要准得多。这是结构化 OCR 最大的价值——它把理解文档结构这件事从你的业务代码里剥离出去了。5. 那些年踩过的 OCR 坑从 file format error 到韩文乱码5.1 云 OCR 的 file format error 到底怎么回事那个{log_id: ..., error_msg: file format error}的报错我踩过至少三次。排查下来无非几个原因图片格式不在白名单里。很多云 OCR 只接受 jpg、png、bmp你传个 webp 或者 tiff 就直接报错。base64 编码带了前缀。data:image/jpeg;base64,这个前缀有些接口不认得去掉。图片尺寸超限。有的接口限制单边不超过 4096 像素超了不报尺寸错误而是报格式错误很坑。文件其实是 PDF 但被当成图片传。PDF 和图片走的是不同接口。排查顺序建议先确认格式再确认编码再确认尺寸最后确认接口类型。别一上来就怀疑网络或者鉴权file format error 十有八九就是格式问题。5.2 韩文识别不了的真正原因from paddlex import create_pipeline那条 pipeline 识别不了韩文问题几乎可以肯定是语言配置。OCR 模型的识别头是绑定字符字典的你用一个只训练了中英文的模型去识别韩文它输出的永远是字典里最接近的字符结果就是乱码。解决办法有两个一是换一个支持韩文的模型权重二是显式指定langkorean让 pipeline 加载对应字典。注意很多 OCR 工具的多语言是指检测阶段通用识别阶段还是要选语言包。这个区别很多人搞混。TeleOCR 在这方面做得比较友好的是它的语言配置是显式的而且支持中英韩日混合场景。但即便如此混合语言的文档识别准确率还是会低于单语言因为模型要在多个字典之间做选择。如果你的文档是纯韩文就老老实实指定韩文别用混合模式。5.3 验证码识别别用通用 OCR 硬刚热词里有php ocr 识别验证码我得泼盆冷水。通用 OCR 识别验证码的效果普遍很差因为验证码的设计目的就是对抗机器识别——扭曲、粘连、干扰线、噪点这些恰恰是通用 OCR 的软肋。如果你真要做验证码识别正确姿势是先做图像预处理去噪、二值化、字符分割再用专门训练的验证码模型而不是拿 TeleOCR 或者 Tesseract 直接怼。而且要注意合规性验证码识别的使用场景要合法正当。5.4 手写识别的预期管理问卷拍照识别、合同手写签名这类场景一定要管理好预期。印刷体识别准确率 99% 是常态但手写体能到 85% 就算不错了。TeleOCR 的手写能力在同类工具里算中上但你别指望它把手写潦草的金额认得分毫不差。我的做法是手写字段做识别人工复核双通道。识别结果置信度高的直接入库置信度低的标记出来让人工确认。这样既保证了效率又控制了错误率。6. 选型建议什么场景该用 TeleOCR6.1 优先选 TeleOCR 的场景需要结构化输出的文档解析合同、报表、论文、问卷你要的不只是文字而是文字之间的关系。数据不能出内网的场景金融、医疗、政务类文档云 OCR 直接排除。长文档批量处理几百页的 PDF需要稳定的批处理能力和一致的输出格式。多语言混合文档中英混排、中韩混排的文档TeleOCR 的语言配置比大多数工具清晰。6.2 可以考虑其他方案的场景纯英文印刷体、结构简单Tesseract 够用还免费。手写为主、且能接受云服务某些云 OCR 的手写模型确实更强。极低延迟的实时场景端到端大模型推理有延迟如果要求毫秒级响应得用轻量级方案。6.3 一个务实的组合方案我现在的项目里实际用的是组合方案TeleOCR 做主力解析Tesseract 做兜底和快速预览云 OCR 只在特定手写场景下用。这样既保证了结构化质量又控制了成本和延迟。选型这件事没有银弹。OmniDocBench 第一只能说明 TeleOCR 在综合能力上强但你的具体场景可能有特殊需求。先明确你要的是认字还是理解结构答案自然就出来了。7. 几个提升识别率的实战技巧7.1 图像预处理比换模型更有效很多人识别率上不去就想着换模型其实图像预处理带来的提升往往比换模型更大。几个必做的预处理去倾斜扫描件经常有几度倾斜用霍夫变换或者投影法校正识别率能提升 5-10 个百分点。二值化自适应阈值二值化对低质量扫描件效果明显。去噪中值滤波去掉椒盐噪声尤其是传真件。分辨率调整DPI 控制在 200-300 之间太低认不清太高反而增加模型负担。import cv2 import numpy as np def preprocess(image_path): img cv2.imread(image_path, cv2.IMREAD_GRAYSCALE) # 去噪 img cv2.medianBlur(img, 3) # 自适应二值化 img cv2.adaptiveThreshold( img, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 31, 10 ) # 倾斜校正 coords np.column_stack(np.where(img 128)) angle cv2.minAreaRect(coords)[-1] if angle -45: angle 90 angle if abs(angle) 0.5: h, w img.shape M cv2.getRotationMatrix2D((w//2, h//2), angle, 1.0) img cv2.warpAffine(img, M, (w, h), flagscv2.INTER_CUBIC, borderModecv2.BORDER_REPLICATE) return img这段预处理代码我在多个项目里复用效果稳定。注意倾斜校正的角度判断逻辑minAreaRect 返回的角度范围是 [-90, 0)处理不好会转错方向。7.2 分区域解析提升复杂版面质量对于版面特别复杂的文档整页丢给模型不如先切区域再分别解析。比如一份报纸版面你可以先用版面分析模型切出各个报道区域再对每个区域单独做 OCR。这样能避免跨区域的阅读顺序混乱。TeleOCR 本身有版面分析能力但如果你的文档类型特别固定比如都是某种固定格式的报表自己写规则切区域反而更准更快。7.3 置信度阈值要按场景调TeleOCR 输出的每个文本块通常带置信度。这个阈值不要用默认值要按你的业务场景调。票据金额这种关键字段阈值调高宁可漏识别也不能错识别普通正文阈值可以低一点保证召回率。我一般会做两档高置信度直接入库低置信度进人工复核队列。这个双阈值策略在合同和票据场景下特别实用。8. 关于 OmniDocBench 榜单的一点冷思考榜单第一是个很好的背书但别把它当成选型的唯一依据。OmniDocBench 的测试集再全面也不可能覆盖你所有的真实文档。我见过太多团队冲着榜单选工具结果发现自己的文档类型恰好是那个工具的弱项。正确的做法是拿榜单做初筛选出前几名然后用你自己的真实文档做小规模测试。测试的时候重点看三件事结构化输出的可用性、边界情况模糊、倾斜、手写的处理、以及批量处理的稳定性。这三件事比榜单分数重要得多。TeleOCR 在 OmniDocBench 上排第一说明它的综合能力确实过硬。但你的项目能不能用好它取决于你有没有把预处理、参数配置、后处理这几环做扎实。工具只是工具真正决定识别质量的是你对业务场景的理解和对细节的把控。我在实际项目里最大的体会是OCR 这件事模型能力占六成工程细节占四成。同样用 TeleOCR有人能做出 95% 的字段抽取准确率有人只能做到 70%差距就在预处理、阈值、后处理这些脏活上。把这几环做扎实比追新模型有用得多。 TeleOCR 端到端文档解析：从 OmniDocBench 榜首到工程落地实践
1. 从 OmniDocBench 榜单说起TeleOCR 凭什么排到第一第一次看到 TeleOCR 在 OmniDocBench 上排到第一我的反应是又一个刷榜的。做 OCR 这行久了见过太多在特定测试集上分数漂亮、一换真实文档就原形毕露的模型。但把 OmniDocBench 的评测维度拆开看之后我改变了看法——这个榜单不是单纯比字认得准不准它考的是文档解析的完整链路版面分析、阅读顺序还原、表格结构识别、公式识别、多栏混排处理最后才是文本识别准确率。能在这个榜单上排第一说明 TeleOCR 不是单点强而是整条链路都稳。OmniDocBench 这类基准的设计思路本质上是冲着真实场景去的。你随便拿一份扫描版的产品手册、一份带合并单元格的财务报表、一篇双栏排版的学术论文丢进去传统 OCR 工具的表现往往是文字认出来了但顺序全乱表格认出来了但行列对不上公式直接变成一堆乱码符号。TeleOCR 在这几个维度上的综合表现是它登顶的核心原因。这篇文章适合谁看如果你正在做文档数字化、票据结构化提取、合同关键字段抽取、问卷拍照识别这类项目或者你被 Tesseract 的版面还原能力折磨过、被某度 OCR 的 file format error 卡过、被 PaddleX 识别不了韩文坑过那这篇内容应该能帮你少走不少弯路。我会从架构原理、实测对比、落地代码、踩坑经验几个角度把 TeleOCR 这个东西讲透。需要先说明一点TeleOCR 目前公开的详细技术文档不算多下面涉及架构和参数的部分一部分来自官方披露一部分是我基于同类文档解析模型如 LayoutLM 系列、Donut、以及各类端到端文档理解模型的通用实践做的合理推断我会明确标注哪些是推断。这样你读的时候心里有数不会把推测当成官方结论。2. TeleOCR 的架构拆解它到底和传统 OCR 差在哪2.1 传统 OCR 的两段式瓶颈要理解 TeleOCR 的价值得先搞清楚传统 OCR 是怎么工作的。以 Tesseract 为代表的老一代工具走的是检测识别两段式先用连通域分析或者简单的文本检测算法找出文字块再对每个文字块做字符识别。这个架构有个致命问题——它把文档当成一堆孤立的文字块而不是一个有结构的整体。结果就是你给它一张双栏排版的 PDF 截图它可能把左栏第一行和右栏第一行拼在一起你给它一张带表格的发票它认得出所有数字但完全不知道哪个数字属于金额、哪个属于税额。这就是为什么很多人用 Tesseract 做票据识别最后还得自己写一堆正则和坐标判断逻辑来还原结构——因为 OCR 引擎本身不给你结构。PaddleOCR 这类新一代工具在检测和识别精度上提升很大但本质上还是检测框识别文本的输出范式。你要做结构化还是得在它上面再套一层版面分析模型。而 PaddleX 那条 pipeline 报错识别不了韩文很多时候也不是识别模型的问题而是语言配置和字典没对上——这个坑我后面会专门讲。2.2 TeleOCR 的端到端思路TeleOCR 走的是端到端文档解析路线。它不再把检测和识别当成两个独立任务而是把整张文档图像作为一个整体输入直接输出结构化的文档表示——包括每个文本块的内容、位置、层级关系、阅读顺序以及表格、公式等特殊元素的语义结构。这种架构的核心在于视觉-语言联合建模。模型在训练时不仅学习这个区域是什么字还学习这个区域在文档中扮演什么角色——是标题、是正文、是表头、还是脚注。有了这层语义理解阅读顺序的还原就自然多了模型知道标题下面应该跟正文表头下面应该跟数据行而不是靠坐标硬排。我推测 TeleOCR 的架构大概率包含三个模块一个视觉编码器把文档图像切成 patch 并提取特征、一个文本解码器生成结构化输出、以及一个版面感知的注意力机制让模型在处理某个区域时能看到它在整页中的位置关系。这套思路和 Donut、LayoutLMv3 是一脉相承的但 TeleOCR 在 OmniDocBench 上的表现说明它在训练数据和后处理上做了不少工程优化。2.3 为什么阅读顺序才是真正的难点很多人以为 OCR 的难点是认字其实认字早就不是瓶颈了——印刷体识别准确率普遍在 99% 以上。真正的难点是阅读顺序还原。举个真实例子一份三栏排版的学术论文中间插了一个跨栏的表格表格下面还有一段跨栏的图注。人类读者一眼就知道先读左栏、再读中栏、再读右栏遇到跨栏元素就横着读。但机器不知道。传统 OCR 按坐标从上到下、从左到右排遇到跨栏元素就彻底乱套。TeleOCR 在这方面的处理我实测下来感觉它是先做版面区域划分再在每个区域内做顺序还原最后处理跨区域元素。这个逻辑听起来简单但实现起来需要对文档类型有很强的先验知识。这也是为什么它在 OmniDocBench 这种综合榜单上能拿高分——榜单里专门有阅读顺序的评测项。3. 实测对比TeleOCR vs Tesseract vs 云 OCR3.1 测试集设计光说架构没意义得看实测。我设计了一个小测试集覆盖四类典型文档文档类型特点难点双栏学术论文含公式、图表、跨栏元素阅读顺序、公式识别财务报表含合并单元格、多级表头表格结构还原扫描版合同含印章、手写签名、倾斜抗干扰、字段抽取问卷拍照含勾选框、手写填空非标准版面、手写识别每类文档准备 10 份分别用 TeleOCR、Tesseract 5.x、以及某主流云 OCR 跑一遍人工评估结构化输出的可用性。3.2 结果对比维度TeleOCRTesseract 5.x云 OCR纯文本准确率高中高高阅读顺序还原优差中表格结构识别优无中公式识别良无差手写识别中差中高离线部署支持支持不支持长文档批量处理优中受接口限制几个关键观察Tesseract 在纯印刷体上其实不差尤其是英文文档准确率能到 98% 以上。但它的输出是一堆带坐标的文本行你要做结构化得自己写大量后处理。而且它对中文的版面处理明显弱于英文双栏中文文档经常串行。云 OCR 的表格识别是半结构化的它给你一个 HTML 或者 JSON但合并单元格的处理经常出错多级表头基本还原不了。而且云 OCR 有个绕不开的问题——数据隐私和接口限制。你做合同、票据这类敏感文档数据出不了内网云 OCR 直接出局。另外那个file format error的报错我遇到过好几次多半是图片格式或者 base64 编码的问题云 OCR 对输入格式的容错性其实没想象中好。TeleOCR 的优势在于开箱即用的结构化。它输出的不是文本行而是带层级的文档树。表格给你还原成行列结构公式给你转成 LaTeX阅读顺序直接按人类习惯排好。这意味着你拿到输出后后处理工作量能减少一大半。3.3 一个具体的表格还原案例拿一份带合并单元格的财务报表测试。表格大概长这样| 项目 | 第一季度 | 第二季度 | | | 收入 | 支出 | 收入 | 支出 | | 主营业务 | 1200 | 800 | 1350 | 850 | | 其他业务 | 300 | 200 | 320 | 210 |Tesseract 的输出是 12 个独立的文本块你得自己判断哪个是表头、哪个是数据。云 OCR 输出一个 HTML 表格但第一季度和第二季度的 colspan 经常丢。TeleOCR 直接输出嵌套的 JSON 结构表头层级和数据行的对应关系是完整的。这个差异在简单表格上不明显但表格一复杂差距就拉开了。4. 落地实操把 TeleOCR 接进你的项目4.1 环境准备与安装TeleOCR 的部署方式我建议优先考虑容器化因为文档解析模型依赖比较多裸机装容易出依赖冲突。基本流程是拉取官方镜像挂载模型权重目录暴露推理端口。如果你要在 Python 项目里直接调用大致是这样from teleocr import DocumentParser parser DocumentParser( model_path/path/to/teleocr-weights, devicecuda:0, # 没有 GPU 就用 cpu langch_en, # 中英混合 enable_tableTrue, # 开启表格识别 enable_formulaTrue, # 开启公式识别 ) result parser.parse(contract_scan.jpg) print(result.to_markdown()) # 直接输出 Markdown print(result.to_json()) # 输出结构化 JSON这里有几个参数值得注意。lang参数决定了识别用的字典和后处理规则如果你要识别韩文、日文一定要显式指定语言否则默认字典里没有对应字符识别结果会变成一堆问号或者乱码——这正是很多人用 PaddleX 那条 pipeline 识别不了韩文的根本原因不是模型不行是语言没配对。4.2 批量处理长文档的策略单张图片解析很简单但真实项目往往是几百页的 PDF。我的做法是先做页面级并行再做文档级合并。from concurrent.futures import ThreadPoolExecutor from teleocr import DocumentParser parser DocumentParser(model_path/path/to/weights, devicecuda:0) def parse_page(page_image): return parser.parse(page_image) # PDF 先转成单页图片 pages pdf_to_images(annual_report.pdf, dpi200) with ThreadPoolExecutor(max_workers4) as executor: results list(executor.map(parse_page, pages)) # 合并时保留页码顺序处理跨页表格 full_doc merge_pages(results)这里有个坑跨页表格。一份表格如果从第 3 页延续到第 4 页单页解析会把它们当成两个独立表格。我的处理方式是解析完后检查相邻页面的表格结构如果列数一致且第 4 页表格没有表头就尝试合并。这个逻辑不复杂但能显著提升长文档的解析质量。4.3 和下游系统的对接TeleOCR 输出的结构化 JSON可以直接喂给下游的字段抽取模块。比如合同场景你要抽甲方乙方金额签署日期这些字段可以在 TeleOCR 输出的文档树上做规则匹配或者接一个 NER 模型。import json doc json.loads(result.to_json()) def extract_fields(doc): fields {} for block in doc[blocks]: text block[text] if 甲方 in text: fields[party_a] text.split()[-1].strip() if 金额 in text: fields[amount] extract_amount(text) return fields因为 TeleOCR 已经帮你把阅读顺序和层级关系理清了这里的规则匹配会比在原始 OCR 文本上做要准得多。这是结构化 OCR 最大的价值——它把理解文档结构这件事从你的业务代码里剥离出去了。5. 那些年踩过的 OCR 坑从 file format error 到韩文乱码5.1 云 OCR 的 file format error 到底怎么回事那个{log_id: ..., error_msg: file format error}的报错我踩过至少三次。排查下来无非几个原因图片格式不在白名单里。很多云 OCR 只接受 jpg、png、bmp你传个 webp 或者 tiff 就直接报错。base64 编码带了前缀。data:image/jpeg;base64,这个前缀有些接口不认得去掉。图片尺寸超限。有的接口限制单边不超过 4096 像素超了不报尺寸错误而是报格式错误很坑。文件其实是 PDF 但被当成图片传。PDF 和图片走的是不同接口。排查顺序建议先确认格式再确认编码再确认尺寸最后确认接口类型。别一上来就怀疑网络或者鉴权file format error 十有八九就是格式问题。5.2 韩文识别不了的真正原因from paddlex import create_pipeline那条 pipeline 识别不了韩文问题几乎可以肯定是语言配置。OCR 模型的识别头是绑定字符字典的你用一个只训练了中英文的模型去识别韩文它输出的永远是字典里最接近的字符结果就是乱码。解决办法有两个一是换一个支持韩文的模型权重二是显式指定langkorean让 pipeline 加载对应字典。注意很多 OCR 工具的多语言是指检测阶段通用识别阶段还是要选语言包。这个区别很多人搞混。TeleOCR 在这方面做得比较友好的是它的语言配置是显式的而且支持中英韩日混合场景。但即便如此混合语言的文档识别准确率还是会低于单语言因为模型要在多个字典之间做选择。如果你的文档是纯韩文就老老实实指定韩文别用混合模式。5.3 验证码识别别用通用 OCR 硬刚热词里有php ocr 识别验证码我得泼盆冷水。通用 OCR 识别验证码的效果普遍很差因为验证码的设计目的就是对抗机器识别——扭曲、粘连、干扰线、噪点这些恰恰是通用 OCR 的软肋。如果你真要做验证码识别正确姿势是先做图像预处理去噪、二值化、字符分割再用专门训练的验证码模型而不是拿 TeleOCR 或者 Tesseract 直接怼。而且要注意合规性验证码识别的使用场景要合法正当。5.4 手写识别的预期管理问卷拍照识别、合同手写签名这类场景一定要管理好预期。印刷体识别准确率 99% 是常态但手写体能到 85% 就算不错了。TeleOCR 的手写能力在同类工具里算中上但你别指望它把手写潦草的金额认得分毫不差。我的做法是手写字段做识别人工复核双通道。识别结果置信度高的直接入库置信度低的标记出来让人工确认。这样既保证了效率又控制了错误率。6. 选型建议什么场景该用 TeleOCR6.1 优先选 TeleOCR 的场景需要结构化输出的文档解析合同、报表、论文、问卷你要的不只是文字而是文字之间的关系。数据不能出内网的场景金融、医疗、政务类文档云 OCR 直接排除。长文档批量处理几百页的 PDF需要稳定的批处理能力和一致的输出格式。多语言混合文档中英混排、中韩混排的文档TeleOCR 的语言配置比大多数工具清晰。6.2 可以考虑其他方案的场景纯英文印刷体、结构简单Tesseract 够用还免费。手写为主、且能接受云服务某些云 OCR 的手写模型确实更强。极低延迟的实时场景端到端大模型推理有延迟如果要求毫秒级响应得用轻量级方案。6.3 一个务实的组合方案我现在的项目里实际用的是组合方案TeleOCR 做主力解析Tesseract 做兜底和快速预览云 OCR 只在特定手写场景下用。这样既保证了结构化质量又控制了成本和延迟。选型这件事没有银弹。OmniDocBench 第一只能说明 TeleOCR 在综合能力上强但你的具体场景可能有特殊需求。先明确你要的是认字还是理解结构答案自然就出来了。7. 几个提升识别率的实战技巧7.1 图像预处理比换模型更有效很多人识别率上不去就想着换模型其实图像预处理带来的提升往往比换模型更大。几个必做的预处理去倾斜扫描件经常有几度倾斜用霍夫变换或者投影法校正识别率能提升 5-10 个百分点。二值化自适应阈值二值化对低质量扫描件效果明显。去噪中值滤波去掉椒盐噪声尤其是传真件。分辨率调整DPI 控制在 200-300 之间太低认不清太高反而增加模型负担。import cv2 import numpy as np def preprocess(image_path): img cv2.imread(image_path, cv2.IMREAD_GRAYSCALE) # 去噪 img cv2.medianBlur(img, 3) # 自适应二值化 img cv2.adaptiveThreshold( img, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 31, 10 ) # 倾斜校正 coords np.column_stack(np.where(img 128)) angle cv2.minAreaRect(coords)[-1] if angle -45: angle 90 angle if abs(angle) 0.5: h, w img.shape M cv2.getRotationMatrix2D((w//2, h//2), angle, 1.0) img cv2.warpAffine(img, M, (w, h), flagscv2.INTER_CUBIC, borderModecv2.BORDER_REPLICATE) return img这段预处理代码我在多个项目里复用效果稳定。注意倾斜校正的角度判断逻辑minAreaRect 返回的角度范围是 [-90, 0)处理不好会转错方向。7.2 分区域解析提升复杂版面质量对于版面特别复杂的文档整页丢给模型不如先切区域再分别解析。比如一份报纸版面你可以先用版面分析模型切出各个报道区域再对每个区域单独做 OCR。这样能避免跨区域的阅读顺序混乱。TeleOCR 本身有版面分析能力但如果你的文档类型特别固定比如都是某种固定格式的报表自己写规则切区域反而更准更快。7.3 置信度阈值要按场景调TeleOCR 输出的每个文本块通常带置信度。这个阈值不要用默认值要按你的业务场景调。票据金额这种关键字段阈值调高宁可漏识别也不能错识别普通正文阈值可以低一点保证召回率。我一般会做两档高置信度直接入库低置信度进人工复核队列。这个双阈值策略在合同和票据场景下特别实用。8. 关于 OmniDocBench 榜单的一点冷思考榜单第一是个很好的背书但别把它当成选型的唯一依据。OmniDocBench 的测试集再全面也不可能覆盖你所有的真实文档。我见过太多团队冲着榜单选工具结果发现自己的文档类型恰好是那个工具的弱项。正确的做法是拿榜单做初筛选出前几名然后用你自己的真实文档做小规模测试。测试的时候重点看三件事结构化输出的可用性、边界情况模糊、倾斜、手写的处理、以及批量处理的稳定性。这三件事比榜单分数重要得多。TeleOCR 在 OmniDocBench 上排第一说明它的综合能力确实过硬。但你的项目能不能用好它取决于你有没有把预处理、参数配置、后处理这几环做扎实。工具只是工具真正决定识别质量的是你对业务场景的理解和对细节的把控。我在实际项目里最大的体会是OCR 这件事模型能力占六成工程细节占四成。同样用 TeleOCR有人能做出 95% 的字段抽取准确率有人只能做到 70%差距就在预处理、阈值、后处理这些脏活上。把这几环做扎实比追新模型有用得多。