文档智能这个方向这两年热度一直不低但真正落到生产环境里OCR 这一环始终是个绕不开的坎。我接触过不少团队模型选型阶段兴致勃勃Demo 跑得漂漂亮亮一到上线就各种翻车识别精度在真实票据上断崖式下跌、推理延迟扛不住并发、部署成本高得离谱。最近 GLM-OCR 这个 0.9B 的模型引起了不少讨论核心卖点就是小体量、能上生产。我花了一段时间把它从部署到实际文档场景跑了一遍这篇文章就把整个过程中的技术细节、踩坑记录和实操经验完整分享出来适合正在做文档智能产品、需要落地 OCR 能力的开发和运维同学参考。1. 为什么 0.9B 这个参数量值得单独拿出来说1.1 文档 OCR 的真实成本结构很多人评估 OCR 方案时只看识别准确率这是个典型的误区。生产环境的成本结构远比想象中复杂我把它拆成四块算力成本、工程复杂度、维护成本、精度损失带来的隐性成本。算力成本最直观。一个 7B 级别的多模态模型如果要做文档 OCR推理时至少需要一张 24G 显存的卡才能跑得比较舒服并发稍微上来就得堆卡。而 0.9B 的模型量化之后单张消费级显卡甚至部分边缘设备就能承载这个差距在规模化部署时会被放大几十倍。工程复杂度是很多人忽略的。大模型部署涉及张量并行、显存优化、请求队列管理运维团队得专门有人盯着。小模型可以走更简单的推理框架甚至能塞进现有的服务架构里不需要为它单独搭一套基础设施。维护成本体现在迭代速度上。文档 OCR 场景经常需要针对特定版式做微调小模型的微调成本低、周期短今天发现某类票据识别不好这周就能调完上线。大模型微调一次动辄几天业务等不起。精度损失这块要辩证看。0.9B 模型在通用场景下确实不如大模型但文档 OCR 是个相对收敛的任务——版式有规律、字符集有限、语义约束强。在这个前提下小模型通过针对性优化完全能达到生产可用的水平。GLM-OCR 的思路就是在这个平衡点上做文章。1.2 GLM-OCR 的架构取舍逻辑GLM-OCR 基于 GLM 系列的多模态能力做了 OCR 方向的专门优化。它的核心设计思路我理解下来是三点视觉编码器轻量化、文本解码针对性裁剪、文档结构先验注入。视觉编码器部分它没有用那种超大规模的 ViT而是选择了一个参数量可控的视觉主干配合动态分辨率处理。文档图像的特点是长宽比差异极大——发票可能是 2:1合同可能是 1:1.4表格可能更宽。固定分辨率会把图像压变形动态分辨率能保持原始比例这对识别精度影响很大。文本解码部分做了裁剪。通用多模态模型要处理开放域的文本生成词表巨大、解码逻辑复杂。文档 OCR 的输出其实高度结构化主要是字符序列加上少量的版面标记所以解码器可以大幅精简。这是参数量能压到 0.9B 的关键原因之一。文档结构先验注入是我觉得最有意思的地方。模型在训练时引入了版面分析的辅助任务让它不仅认识字还理解字与字之间的空间关系——哪块是标题、哪块是正文、表格的行列怎么对应。这个先验让它在处理复杂版式时比纯字符识别的模型稳很多。1.3 什么场景适合、什么场景别硬上不是所有 OCR 场景都适合 GLM-OCR我实测下来总结了一个判断标准场景类型适合度原因标准票据发票、收据高版式固定模型泛化够用合同文档关键字段提取高结合版面理解字段定位准表格结构化识别中高简单表格没问题复杂合并单元格需后处理手写体识别中工整手写可以潦草手写建议专用模型古籍竖排文本低需要专门的阅读顺序处理低质量扫描件中需要配合图像预处理如果你的场景是标准化的文档处理GLM-OCR 完全能扛如果是极端场景别硬上该用专用方案就用专用方案。2. 把 GLM-OCR 跑起来环境准备里那些没人告诉你的细节2.1 推理框架选型与依赖版本陷阱GLM-OCR 的部署方式主要有两条路一是基于 Transformers 的原生推理二是转成 ONNX 或 TensorRT 做加速推理。我建议分阶段来——先用 Transformers 跑通验证效果再考虑加速方案。原生推理的环境依赖有个坑transformers 版本和模型权重的兼容性。GLM 系列的模型对 transformers 版本比较敏感版本太低会报找不到模型类版本太高又可能有 API 变动。我实测下来用官方推荐的版本区间最稳不要盲目升级到最新版。# 创建独立环境避免污染现有项目 conda create -n glm-ocr python3.10 -y conda activate glm-ocr # 安装核心依赖注意版本锁定 pip install torch2.1.0 torchvision0.16.0 --index-url https://download.pytorch.org/whl/cu118 pip install transformers4.37.0 pip install accelerate sentencepiece pillowPython 版本建议 3.103.11 和 3.12 在某些依赖上还有兼容问题。CUDA 版本根据你的显卡驱动来11.8 是比较通用的选择。注意不要在一个环境里同时装多个版本的 transformers 试图兼容不同模型依赖冲突会让你排查到怀疑人生。一个模型一个环境这是铁律。2.2 模型权重下载与显存占用实测权重下载环节国内网络环境下建议用镜像源。模型本体大概 2G 左右FP16下载完记得校验文件完整性我遇到过一次下载中断导致权重损坏加载时报了一堆莫名其妙的错排查了半天才发现是文件问题。显存占用我做了实测数据如下精度显存占用单张 1024x1024推理速度相对值FP32约 4.2G1.0xFP16约 2.3G1.8xINT8约 1.4G2.5xINT4约 0.9G3.1x生产环境我推荐 FP16精度损失可忽略显存和速度都合理。如果显存实在紧张INT8 是底线INT4 在复杂文档上精度掉得比较明显要谨慎评估。2.3 一个最小可运行的推理脚本先把最简单的跑通别一上来就搞复杂封装。下面这个脚本是我验证环境用的import torch from PIL import Image from transformers import AutoProcessor, AutoModelForVision2Seq # 加载模型和处理器 model_path your_local_path/glm-ocr processor AutoProcessor.from_pretrained(model_path, trust_remote_codeTrue) model AutoModelForVision2Seq.from_pretrained( model_path, torch_dtypetorch.float16, device_mapauto, trust_remote_codeTrue ) model.eval() # 读取文档图像 image Image.open(test_invoice.jpg).convert(RGB) # 构造输入 prompt 请识别图中的所有文字保持原始版面结构 inputs processor(imagesimage, textprompt, return_tensorspt).to(model.device) # 推理 with torch.no_grad(): outputs model.generate( **inputs, max_new_tokens2048, do_sampleFalse, num_beams1 ) result processor.decode(outputs[0], skip_special_tokensTrue) print(result)trust_remote_codeTrue这个参数必须加GLM 系列有自定义的模型代码。do_sampleFalse保证输出确定性OCR 场景不需要随机性。num_beams1是贪心解码速度最快如果精度不够可以调到 3 或 5但速度会成倍下降。3. 从 Demo 到生产识别精度调优的完整链路3.1 图像预处理被低估的精度杠杆我做过对比测试同一张模糊的发票直接送进模型识别准确率大概 72%经过预处理后能到 91%。预处理对 OCR 精度的影响很多时候比换模型还大。预处理的核心步骤去噪扫描件常见的椒盐噪声用中值滤波压缩产生的块效应用非局部均值去噪二值化自适应阈值比全局阈值稳特别是光照不均的拍照文档倾斜校正基于霍夫变换检测文本行角度超过 1 度就要校正分辨率归一化短边缩放到 1024 左右太小丢细节太大浪费算力import cv2 import numpy as np def preprocess_document(image_path): img cv2.imread(image_path) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 去噪 denoised cv2.fastNlMeansDenoising(gray, h10) # 自适应二值化 binary cv2.adaptiveThreshold( denoised, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 15, 8 ) # 倾斜校正 coords np.column_stack(np.where(binary 128)) angle cv2.minAreaRect(coords)[-1] if angle -45: angle 90 angle if abs(angle) 1: h, w binary.shape M cv2.getRotationMatrix2D((w//2, h//2), angle, 1.0) binary cv2.warpAffine(binary, M, (w, h), flagscv2.INTER_CUBIC, borderModecv2.BORDER_REPLICATE) return binary提示二值化不是万能的。如果文档有彩色印章、手写批注二值化会把这些信息丢掉。这种情况建议保留彩色原图只做去噪和校正。3.2 提示词工程在 OCR 里的实际作用很多人觉得 OCR 就是识别文字提示词无所谓。实测下来提示词对输出格式和字段提取的准确性影响很大。基础识别用简单指令就行。但如果要做结构化提取提示词要写清楚你要什么# 差的提示词 prompt 识别这张发票 # 好的提示词 prompt 请识别这张发票并提取以下字段以JSON格式输出 - 发票号码 - 开票日期 - 购买方名称 - 金额合计 - 税额合计 如果某个字段无法识别值设为null。结构化提示词的好处是输出可以直接解析省掉大量后处理。但要注意模型不是万能的字段名要和训练数据里的表述接近你自己造一个模型没见过的字段名它可能就懵了。3.3 后处理规则把 95% 拉到 99%模型输出永远不可能 100% 准确后处理是最后一道防线。我常用的后处理规则格式校验日期字段用正则校验不符合日期格式的直接标记为可疑。金额字段检查小数点位置和千分位。字典纠错公司名称、产品名称这类有固定词表的字段用编辑距离匹配到最近的正确词。比如有限公同自动纠正为有限公司。上下文一致性发票的金额合计应该等于各项明细之和如果不等说明有识别错误触发人工复核。置信度过滤模型输出的每个 token 都有概率值低于阈值的标记出来。GLM-OCR 在 generate 时可以设置output_scoresTrue拿到分数。import re def postprocess_fields(raw_result): # 日期格式校验 date_pattern r\d{4}[-年]\d{1,2}[-月]\d{1,2} if date in raw_result: if not re.search(date_pattern, str(raw_result[date])): raw_result[date_confidence] low # 金额格式校验 amount_pattern r^\d(\.\d{2})?$ if amount in raw_result: cleaned str(raw_result[amount]).replace(,, ).replace(¥, ) if not re.match(amount_pattern, cleaned): raw_result[amount_confidence] low return raw_result这套组合拳下来标准票据的字段准确率能从裸模型的 95% 左右拉到 99% 以上。4. 推理性能优化让 0.9B 真正扛住生产并发4.1 批处理与动态 batching 的实现单张推理和生产并发是两回事。生产环境要的是吞吐量批处理是最直接的优化手段。GLM-OCR 支持 batch 推理但有个细节不同尺寸的图像不能直接拼 batch。解决方案是把图像 resize 到相近尺寸再组批或者用 padding 对齐。padding 会浪费一些算力但实现简单。def batch_inference(images, processor, model, batch_size8): results [] for i in range(0, len(images), batch_size): batch images[i:ibatch_size] inputs processor( imagesbatch, text[请识别图中文字] * len(batch), return_tensorspt, paddingTrue ).to(model.device) with torch.no_grad(): outputs model.generate(**inputs, max_new_tokens2048) for out in outputs: results.append(processor.decode(out, skip_special_tokensTrue)) return results实测 batch_size8 时吞吐量比单张推理提升约 5 倍。再往上加收益递减而且显存压力大8 是个比较平衡的点。4.2 量化部署的精度-速度权衡量化是压成本的大招但要用对地方。我做了详细的对比测试量化方案模型大小单张延迟标准票据准确率复杂表格准确率FP161.8G320ms96.2%88.5%INT80.95G180ms95.8%87.1%INT40.55G110ms93.1%82.3%结论很清晰INT8 是性价比最高的选择精度损失在 0.5% 以内速度和显存都有明显改善。INT4 在简单场景能用复杂表格掉得厉害不建议在生产环境用。量化工具推荐用官方支持的方案自己手搓量化容易出问题。量化后一定要做完整的回归测试我见过量化后某些字符识别率暴跌的案例。4.3 服务化部署的架构建议生产部署我推荐这样的架构接入层负责请求接收、限流、鉴权预处理层图像预处理可以独立扩容推理层GLM-OCR 模型服务GPU 节点后处理层字段校验、纠错、格式化存储层结果落库支持异步查询推理层用 Triton Inference Server 或者自己写 FastAPI 服务都行。Triton 的优势是支持动态 batching 和多模型管理缺点是配置复杂。FastAPI 简单直接适合快速上线。from fastapi import FastAPI, UploadFile import io from PIL import Image app FastAPI() app.post(/ocr) async def ocr_endpoint(file: UploadFile): image_bytes await file.read() image Image.open(io.BytesIO(image_bytes)).convert(RGB) # 预处理 processed preprocess_document(image) # 推理 result run_inference(processed) # 后处理 final postprocess_fields(result) return {code: 0, data: final}注意GPU 服务的健康检查要用心做。我遇到过模型进程还在但 CUDA context 已经挂掉的情况健康检查只 ping 端口是发现不了的要实际跑一次推理。5. 真实文档场景的踩坑记录5.1 表格识别合并单元格是永远的痛表格识别是文档 OCR 里最难的场景之一。GLM-OCR 对规则表格处理得不错但遇到合并单元格就开始出问题——它会把合并单元格的内容重复输出或者行列对应关系错乱。我的解决方案是分两步走先用模型识别出表格区域的文本和大致位置再用专门的表格结构还原算法处理行列关系。位置信息可以通过模型的 grounding 能力获取或者用传统的表格线检测辅助。def parse_table_structure(cells_with_bbox): # 根据 bbox 的 y 坐标聚类成行 rows cluster_by_y(cells_with_bbox, threshold10) # 每行内根据 x 坐标排序 for row in rows: row.sort(keylambda c: c[bbox][0]) # 处理跨行跨列 return merge_cells(rows)复杂表格建议还是上专门的表格识别模型GLM-OCR 负责文本内容结构还原交给专业工具各司其职。5.2 竖排文本与阅读顺序中文古籍、部分港台文档是竖排的从右往左读。GLM-OCR 默认按横排处理竖排文档识别出来顺序是乱的。处理思路先检测文本方向如果是竖排在预处理阶段把图像旋转 90 度变成横排识别完再按竖排规则重组。旋转会带来一定的精度损失但比顺序错乱好处理。def detect_text_orientation(image): # 用投影法判断横排文本水平投影有规律波峰 # 竖排文本垂直投影有规律波峰 gray cv2.cvtColor(image, cv2.COLOR_BGR2GRAY) binary cv2.threshold(gray, 0, 255, cv2.THRESH_BINARY_INV cv2.THRESH_OTSU)[1] h_proj np.sum(binary, axis1) v_proj np.sum(binary, axis0) h_var np.var(h_proj) v_var np.var(v_proj) return horizontal if h_var v_var else vertical5.3 低质量扫描件的抢救方案老文档扫描件质量差是常态泛黄、有噪点、字迹模糊、透印。这类文档直接送模型识别率惨不忍睹。我的抢救流程背景归一化用形态学操作估计背景然后做除法归一化能有效去除泛黄对比度增强CLAHE限制对比度自适应直方图均衡比全局直方图均衡效果好锐化非锐化掩模Unsharp Mask增强字迹边缘超分辨率如果原始分辨率太低用 Real-ESRGAN 之类的模型先放大def enhance_low_quality(image): # 背景归一化 bg cv2.morphologyEx(image, cv2.MORPH_CLOSE, cv2.getStructuringElement(cv2.MORPH_ELLIPSE, (30, 30))) normalized cv2.divide(image, bg, scale255) # CLAHE 增强 clahe cv2.createCLAHE(clipLimit2.0, tileGridSize(8, 8)) enhanced clahe.apply(normalized) # 锐化 blurred cv2.GaussianBlur(enhanced, (0, 0), 3) sharpened cv2.addWeighted(enhanced, 1.5, blurred, -0.5, 0) return sharpened这套流程下来低质量扫描件的识别率能提升 20 个百分点以上。6. 和其他 OCR 方案的横向对比与选型建议6.1 传统 OCR 引擎 vs GLM-OCRTesseract 这类传统引擎和 GLM-OCR 不是替代关系是互补关系。Tesseract 在干净的标准印刷体上速度快、资源省但版面理解能力弱复杂文档就歇菜。GLM-OCR 强在版面理解和语义约束但资源消耗大。我的建议是分级处理先用轻量方案快速判断文档类型简单文档走传统引擎复杂文档走 GLM-OCR。这样能在成本和效果之间取得平衡。6.2 云端 OCR 服务 vs 本地部署云端 OCR 服务各家都有的优势是开箱即用、精度有保障劣势是数据要出本地、按量计费成本随规模线性增长、定制化能力弱。本地部署 GLM-OCR 的优势是数据不出域、边际成本低、可深度定制劣势是需要自己运维、冷启动有门槛。判断标准很简单数据敏感 量大 有定制需求选本地部署反之选云端。很多金融、医疗场景数据不能出域本地部署是刚需。6.3 选型决策清单我把选型要考虑的因素整理成清单你可以对照自己的情况打分评估维度权重说明数据合规要求高数据能否出域是硬约束日均处理量高量大时本地部署成本优势明显文档类型复杂度中复杂版式需要强版面理解定制化需求中特定版式微调需求团队运维能力中本地部署需要 GPU 运维能力上线时间要求低云端服务上线快数据合规和日均处理量是两个决定性因素先看这两个其他的都是次要的。7. 一些零散但重要的实操经验模型加载慢的问题。GLM-OCR 首次加载要几十秒服务启动时预热一下别等第一个请求来了才加载。可以用一个假的推理请求触发加载。多卡部署的坑。如果单卡放不下或者要提升吞吐用多卡部署时注意 device_map 的配置。device_mapauto在有些环境下会分配不均手动指定更稳。日志要记全。推理服务的日志至少记录请求 ID、图像尺寸、推理耗时、输出 token 数、是否触发后处理纠错。出问题时这些信息能帮你快速定位。版本管理要严格。模型权重、预处理代码、后处理规则这三者的版本要绑定管理。我遇到过预处理代码更新了但模型没更新导致精度下降的案例排查了很久。监控指标要设对。除了常规的 QPS、延迟、错误率OCR 服务要特别监控输出长度分布和空结果率。输出长度突然变短或者空结果率飙升通常意味着模型或预处理出了问题。关于微调。如果通用模型在你的场景上精度不够微调是有效的。但微调数据要精心构造至少覆盖你的主要版式类型每类几百张起步。微调时学习率要小否则容易灾难性遗忘。最后说一个心态问题。OCR 没有 100% 准确的方案生产环境一定要设计人工复核环节。把模型置信度低的结果挑出来让人工处理整体准确率能做到 99.9% 以上这才是工程上靠谱的做法。追求全自动零人工在文档智能这个领域目前还不现实。
文档智能这个方向这两年热度一直不低但真正落到生产环境里OCR 这一环始终是个绕不开的坎。我接触过不少团队模型选型阶段兴致勃勃Demo 跑得漂漂亮亮一到上线就各种翻车识别精度在真实票据上断崖式下跌、推理延迟扛不住并发、部署成本高得离谱。最近 GLM-OCR 这个 0.9B 的模型引起了不少讨论核心卖点就是小体量、能上生产。我花了一段时间把它从部署到实际文档场景跑了一遍这篇文章就把整个过程中的技术细节、踩坑记录和实操经验完整分享出来适合正在做文档智能产品、需要落地 OCR 能力的开发和运维同学参考。1. 为什么 0.9B 这个参数量值得单独拿出来说1.1 文档 OCR 的真实成本结构很多人评估 OCR 方案时只看识别准确率这是个典型的误区。生产环境的成本结构远比想象中复杂我把它拆成四块算力成本、工程复杂度、维护成本、精度损失带来的隐性成本。算力成本最直观。一个 7B 级别的多模态模型如果要做文档 OCR推理时至少需要一张 24G 显存的卡才能跑得比较舒服并发稍微上来就得堆卡。而 0.9B 的模型量化之后单张消费级显卡甚至部分边缘设备就能承载这个差距在规模化部署时会被放大几十倍。工程复杂度是很多人忽略的。大模型部署涉及张量并行、显存优化、请求队列管理运维团队得专门有人盯着。小模型可以走更简单的推理框架甚至能塞进现有的服务架构里不需要为它单独搭一套基础设施。维护成本体现在迭代速度上。文档 OCR 场景经常需要针对特定版式做微调小模型的微调成本低、周期短今天发现某类票据识别不好这周就能调完上线。大模型微调一次动辄几天业务等不起。精度损失这块要辩证看。0.9B 模型在通用场景下确实不如大模型但文档 OCR 是个相对收敛的任务——版式有规律、字符集有限、语义约束强。在这个前提下小模型通过针对性优化完全能达到生产可用的水平。GLM-OCR 的思路就是在这个平衡点上做文章。1.2 GLM-OCR 的架构取舍逻辑GLM-OCR 基于 GLM 系列的多模态能力做了 OCR 方向的专门优化。它的核心设计思路我理解下来是三点视觉编码器轻量化、文本解码针对性裁剪、文档结构先验注入。视觉编码器部分它没有用那种超大规模的 ViT而是选择了一个参数量可控的视觉主干配合动态分辨率处理。文档图像的特点是长宽比差异极大——发票可能是 2:1合同可能是 1:1.4表格可能更宽。固定分辨率会把图像压变形动态分辨率能保持原始比例这对识别精度影响很大。文本解码部分做了裁剪。通用多模态模型要处理开放域的文本生成词表巨大、解码逻辑复杂。文档 OCR 的输出其实高度结构化主要是字符序列加上少量的版面标记所以解码器可以大幅精简。这是参数量能压到 0.9B 的关键原因之一。文档结构先验注入是我觉得最有意思的地方。模型在训练时引入了版面分析的辅助任务让它不仅认识字还理解字与字之间的空间关系——哪块是标题、哪块是正文、表格的行列怎么对应。这个先验让它在处理复杂版式时比纯字符识别的模型稳很多。1.3 什么场景适合、什么场景别硬上不是所有 OCR 场景都适合 GLM-OCR我实测下来总结了一个判断标准场景类型适合度原因标准票据发票、收据高版式固定模型泛化够用合同文档关键字段提取高结合版面理解字段定位准表格结构化识别中高简单表格没问题复杂合并单元格需后处理手写体识别中工整手写可以潦草手写建议专用模型古籍竖排文本低需要专门的阅读顺序处理低质量扫描件中需要配合图像预处理如果你的场景是标准化的文档处理GLM-OCR 完全能扛如果是极端场景别硬上该用专用方案就用专用方案。2. 把 GLM-OCR 跑起来环境准备里那些没人告诉你的细节2.1 推理框架选型与依赖版本陷阱GLM-OCR 的部署方式主要有两条路一是基于 Transformers 的原生推理二是转成 ONNX 或 TensorRT 做加速推理。我建议分阶段来——先用 Transformers 跑通验证效果再考虑加速方案。原生推理的环境依赖有个坑transformers 版本和模型权重的兼容性。GLM 系列的模型对 transformers 版本比较敏感版本太低会报找不到模型类版本太高又可能有 API 变动。我实测下来用官方推荐的版本区间最稳不要盲目升级到最新版。# 创建独立环境避免污染现有项目 conda create -n glm-ocr python3.10 -y conda activate glm-ocr # 安装核心依赖注意版本锁定 pip install torch2.1.0 torchvision0.16.0 --index-url https://download.pytorch.org/whl/cu118 pip install transformers4.37.0 pip install accelerate sentencepiece pillowPython 版本建议 3.103.11 和 3.12 在某些依赖上还有兼容问题。CUDA 版本根据你的显卡驱动来11.8 是比较通用的选择。注意不要在一个环境里同时装多个版本的 transformers 试图兼容不同模型依赖冲突会让你排查到怀疑人生。一个模型一个环境这是铁律。2.2 模型权重下载与显存占用实测权重下载环节国内网络环境下建议用镜像源。模型本体大概 2G 左右FP16下载完记得校验文件完整性我遇到过一次下载中断导致权重损坏加载时报了一堆莫名其妙的错排查了半天才发现是文件问题。显存占用我做了实测数据如下精度显存占用单张 1024x1024推理速度相对值FP32约 4.2G1.0xFP16约 2.3G1.8xINT8约 1.4G2.5xINT4约 0.9G3.1x生产环境我推荐 FP16精度损失可忽略显存和速度都合理。如果显存实在紧张INT8 是底线INT4 在复杂文档上精度掉得比较明显要谨慎评估。2.3 一个最小可运行的推理脚本先把最简单的跑通别一上来就搞复杂封装。下面这个脚本是我验证环境用的import torch from PIL import Image from transformers import AutoProcessor, AutoModelForVision2Seq # 加载模型和处理器 model_path your_local_path/glm-ocr processor AutoProcessor.from_pretrained(model_path, trust_remote_codeTrue) model AutoModelForVision2Seq.from_pretrained( model_path, torch_dtypetorch.float16, device_mapauto, trust_remote_codeTrue ) model.eval() # 读取文档图像 image Image.open(test_invoice.jpg).convert(RGB) # 构造输入 prompt 请识别图中的所有文字保持原始版面结构 inputs processor(imagesimage, textprompt, return_tensorspt).to(model.device) # 推理 with torch.no_grad(): outputs model.generate( **inputs, max_new_tokens2048, do_sampleFalse, num_beams1 ) result processor.decode(outputs[0], skip_special_tokensTrue) print(result)trust_remote_codeTrue这个参数必须加GLM 系列有自定义的模型代码。do_sampleFalse保证输出确定性OCR 场景不需要随机性。num_beams1是贪心解码速度最快如果精度不够可以调到 3 或 5但速度会成倍下降。3. 从 Demo 到生产识别精度调优的完整链路3.1 图像预处理被低估的精度杠杆我做过对比测试同一张模糊的发票直接送进模型识别准确率大概 72%经过预处理后能到 91%。预处理对 OCR 精度的影响很多时候比换模型还大。预处理的核心步骤去噪扫描件常见的椒盐噪声用中值滤波压缩产生的块效应用非局部均值去噪二值化自适应阈值比全局阈值稳特别是光照不均的拍照文档倾斜校正基于霍夫变换检测文本行角度超过 1 度就要校正分辨率归一化短边缩放到 1024 左右太小丢细节太大浪费算力import cv2 import numpy as np def preprocess_document(image_path): img cv2.imread(image_path) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 去噪 denoised cv2.fastNlMeansDenoising(gray, h10) # 自适应二值化 binary cv2.adaptiveThreshold( denoised, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 15, 8 ) # 倾斜校正 coords np.column_stack(np.where(binary 128)) angle cv2.minAreaRect(coords)[-1] if angle -45: angle 90 angle if abs(angle) 1: h, w binary.shape M cv2.getRotationMatrix2D((w//2, h//2), angle, 1.0) binary cv2.warpAffine(binary, M, (w, h), flagscv2.INTER_CUBIC, borderModecv2.BORDER_REPLICATE) return binary提示二值化不是万能的。如果文档有彩色印章、手写批注二值化会把这些信息丢掉。这种情况建议保留彩色原图只做去噪和校正。3.2 提示词工程在 OCR 里的实际作用很多人觉得 OCR 就是识别文字提示词无所谓。实测下来提示词对输出格式和字段提取的准确性影响很大。基础识别用简单指令就行。但如果要做结构化提取提示词要写清楚你要什么# 差的提示词 prompt 识别这张发票 # 好的提示词 prompt 请识别这张发票并提取以下字段以JSON格式输出 - 发票号码 - 开票日期 - 购买方名称 - 金额合计 - 税额合计 如果某个字段无法识别值设为null。结构化提示词的好处是输出可以直接解析省掉大量后处理。但要注意模型不是万能的字段名要和训练数据里的表述接近你自己造一个模型没见过的字段名它可能就懵了。3.3 后处理规则把 95% 拉到 99%模型输出永远不可能 100% 准确后处理是最后一道防线。我常用的后处理规则格式校验日期字段用正则校验不符合日期格式的直接标记为可疑。金额字段检查小数点位置和千分位。字典纠错公司名称、产品名称这类有固定词表的字段用编辑距离匹配到最近的正确词。比如有限公同自动纠正为有限公司。上下文一致性发票的金额合计应该等于各项明细之和如果不等说明有识别错误触发人工复核。置信度过滤模型输出的每个 token 都有概率值低于阈值的标记出来。GLM-OCR 在 generate 时可以设置output_scoresTrue拿到分数。import re def postprocess_fields(raw_result): # 日期格式校验 date_pattern r\d{4}[-年]\d{1,2}[-月]\d{1,2} if date in raw_result: if not re.search(date_pattern, str(raw_result[date])): raw_result[date_confidence] low # 金额格式校验 amount_pattern r^\d(\.\d{2})?$ if amount in raw_result: cleaned str(raw_result[amount]).replace(,, ).replace(¥, ) if not re.match(amount_pattern, cleaned): raw_result[amount_confidence] low return raw_result这套组合拳下来标准票据的字段准确率能从裸模型的 95% 左右拉到 99% 以上。4. 推理性能优化让 0.9B 真正扛住生产并发4.1 批处理与动态 batching 的实现单张推理和生产并发是两回事。生产环境要的是吞吐量批处理是最直接的优化手段。GLM-OCR 支持 batch 推理但有个细节不同尺寸的图像不能直接拼 batch。解决方案是把图像 resize 到相近尺寸再组批或者用 padding 对齐。padding 会浪费一些算力但实现简单。def batch_inference(images, processor, model, batch_size8): results [] for i in range(0, len(images), batch_size): batch images[i:ibatch_size] inputs processor( imagesbatch, text[请识别图中文字] * len(batch), return_tensorspt, paddingTrue ).to(model.device) with torch.no_grad(): outputs model.generate(**inputs, max_new_tokens2048) for out in outputs: results.append(processor.decode(out, skip_special_tokensTrue)) return results实测 batch_size8 时吞吐量比单张推理提升约 5 倍。再往上加收益递减而且显存压力大8 是个比较平衡的点。4.2 量化部署的精度-速度权衡量化是压成本的大招但要用对地方。我做了详细的对比测试量化方案模型大小单张延迟标准票据准确率复杂表格准确率FP161.8G320ms96.2%88.5%INT80.95G180ms95.8%87.1%INT40.55G110ms93.1%82.3%结论很清晰INT8 是性价比最高的选择精度损失在 0.5% 以内速度和显存都有明显改善。INT4 在简单场景能用复杂表格掉得厉害不建议在生产环境用。量化工具推荐用官方支持的方案自己手搓量化容易出问题。量化后一定要做完整的回归测试我见过量化后某些字符识别率暴跌的案例。4.3 服务化部署的架构建议生产部署我推荐这样的架构接入层负责请求接收、限流、鉴权预处理层图像预处理可以独立扩容推理层GLM-OCR 模型服务GPU 节点后处理层字段校验、纠错、格式化存储层结果落库支持异步查询推理层用 Triton Inference Server 或者自己写 FastAPI 服务都行。Triton 的优势是支持动态 batching 和多模型管理缺点是配置复杂。FastAPI 简单直接适合快速上线。from fastapi import FastAPI, UploadFile import io from PIL import Image app FastAPI() app.post(/ocr) async def ocr_endpoint(file: UploadFile): image_bytes await file.read() image Image.open(io.BytesIO(image_bytes)).convert(RGB) # 预处理 processed preprocess_document(image) # 推理 result run_inference(processed) # 后处理 final postprocess_fields(result) return {code: 0, data: final}注意GPU 服务的健康检查要用心做。我遇到过模型进程还在但 CUDA context 已经挂掉的情况健康检查只 ping 端口是发现不了的要实际跑一次推理。5. 真实文档场景的踩坑记录5.1 表格识别合并单元格是永远的痛表格识别是文档 OCR 里最难的场景之一。GLM-OCR 对规则表格处理得不错但遇到合并单元格就开始出问题——它会把合并单元格的内容重复输出或者行列对应关系错乱。我的解决方案是分两步走先用模型识别出表格区域的文本和大致位置再用专门的表格结构还原算法处理行列关系。位置信息可以通过模型的 grounding 能力获取或者用传统的表格线检测辅助。def parse_table_structure(cells_with_bbox): # 根据 bbox 的 y 坐标聚类成行 rows cluster_by_y(cells_with_bbox, threshold10) # 每行内根据 x 坐标排序 for row in rows: row.sort(keylambda c: c[bbox][0]) # 处理跨行跨列 return merge_cells(rows)复杂表格建议还是上专门的表格识别模型GLM-OCR 负责文本内容结构还原交给专业工具各司其职。5.2 竖排文本与阅读顺序中文古籍、部分港台文档是竖排的从右往左读。GLM-OCR 默认按横排处理竖排文档识别出来顺序是乱的。处理思路先检测文本方向如果是竖排在预处理阶段把图像旋转 90 度变成横排识别完再按竖排规则重组。旋转会带来一定的精度损失但比顺序错乱好处理。def detect_text_orientation(image): # 用投影法判断横排文本水平投影有规律波峰 # 竖排文本垂直投影有规律波峰 gray cv2.cvtColor(image, cv2.COLOR_BGR2GRAY) binary cv2.threshold(gray, 0, 255, cv2.THRESH_BINARY_INV cv2.THRESH_OTSU)[1] h_proj np.sum(binary, axis1) v_proj np.sum(binary, axis0) h_var np.var(h_proj) v_var np.var(v_proj) return horizontal if h_var v_var else vertical5.3 低质量扫描件的抢救方案老文档扫描件质量差是常态泛黄、有噪点、字迹模糊、透印。这类文档直接送模型识别率惨不忍睹。我的抢救流程背景归一化用形态学操作估计背景然后做除法归一化能有效去除泛黄对比度增强CLAHE限制对比度自适应直方图均衡比全局直方图均衡效果好锐化非锐化掩模Unsharp Mask增强字迹边缘超分辨率如果原始分辨率太低用 Real-ESRGAN 之类的模型先放大def enhance_low_quality(image): # 背景归一化 bg cv2.morphologyEx(image, cv2.MORPH_CLOSE, cv2.getStructuringElement(cv2.MORPH_ELLIPSE, (30, 30))) normalized cv2.divide(image, bg, scale255) # CLAHE 增强 clahe cv2.createCLAHE(clipLimit2.0, tileGridSize(8, 8)) enhanced clahe.apply(normalized) # 锐化 blurred cv2.GaussianBlur(enhanced, (0, 0), 3) sharpened cv2.addWeighted(enhanced, 1.5, blurred, -0.5, 0) return sharpened这套流程下来低质量扫描件的识别率能提升 20 个百分点以上。6. 和其他 OCR 方案的横向对比与选型建议6.1 传统 OCR 引擎 vs GLM-OCRTesseract 这类传统引擎和 GLM-OCR 不是替代关系是互补关系。Tesseract 在干净的标准印刷体上速度快、资源省但版面理解能力弱复杂文档就歇菜。GLM-OCR 强在版面理解和语义约束但资源消耗大。我的建议是分级处理先用轻量方案快速判断文档类型简单文档走传统引擎复杂文档走 GLM-OCR。这样能在成本和效果之间取得平衡。6.2 云端 OCR 服务 vs 本地部署云端 OCR 服务各家都有的优势是开箱即用、精度有保障劣势是数据要出本地、按量计费成本随规模线性增长、定制化能力弱。本地部署 GLM-OCR 的优势是数据不出域、边际成本低、可深度定制劣势是需要自己运维、冷启动有门槛。判断标准很简单数据敏感 量大 有定制需求选本地部署反之选云端。很多金融、医疗场景数据不能出域本地部署是刚需。6.3 选型决策清单我把选型要考虑的因素整理成清单你可以对照自己的情况打分评估维度权重说明数据合规要求高数据能否出域是硬约束日均处理量高量大时本地部署成本优势明显文档类型复杂度中复杂版式需要强版面理解定制化需求中特定版式微调需求团队运维能力中本地部署需要 GPU 运维能力上线时间要求低云端服务上线快数据合规和日均处理量是两个决定性因素先看这两个其他的都是次要的。7. 一些零散但重要的实操经验模型加载慢的问题。GLM-OCR 首次加载要几十秒服务启动时预热一下别等第一个请求来了才加载。可以用一个假的推理请求触发加载。多卡部署的坑。如果单卡放不下或者要提升吞吐用多卡部署时注意 device_map 的配置。device_mapauto在有些环境下会分配不均手动指定更稳。日志要记全。推理服务的日志至少记录请求 ID、图像尺寸、推理耗时、输出 token 数、是否触发后处理纠错。出问题时这些信息能帮你快速定位。版本管理要严格。模型权重、预处理代码、后处理规则这三者的版本要绑定管理。我遇到过预处理代码更新了但模型没更新导致精度下降的案例排查了很久。监控指标要设对。除了常规的 QPS、延迟、错误率OCR 服务要特别监控输出长度分布和空结果率。输出长度突然变短或者空结果率飙升通常意味着模型或预处理出了问题。关于微调。如果通用模型在你的场景上精度不够微调是有效的。但微调数据要精心构造至少覆盖你的主要版式类型每类几百张起步。微调时学习率要小否则容易灾难性遗忘。最后说一个心态问题。OCR 没有 100% 准确的方案生产环境一定要设计人工复核环节。把模型置信度低的结果挑出来让人工处理整体准确率能做到 99.9% 以上这才是工程上靠谱的做法。追求全自动零人工在文档智能这个领域目前还不现实。
