OCR与STR本质区别：文档识别vs场景文本理解-开发者社区

1. 项目概述：为什么OCR和STR不是一回事，但又必须放在一起看

你打开手机相册，随手拍下一张超市小票，几秒后文字就自动提取出来——这是OCR。
你刷短视频，看到画面里一闪而过的电影海报标题、街边店铺招牌、甚至弹幕里快速滚动的字幕，系统能实时框出文字区域并识别内容——这背后靠的是STR（Scene Text Recognition）。

很多人第一次接触这两个词时会下意识认为：“不都是把图里的字变成文本吗？是不是同一个技术换了个马甲？”
不是。差别大到足以决定一个工业质检系统能不能上线、一款教育类APP能不能通过审核、甚至影响某款车载中控屏在强光直射下的文字响应准确率。

OCR（Optical Character Recognition）本质是“文档图像的文字还原”，它的理想输入是：

页面平整（A4纸、PDF截图）
文字方向统一（横排为主，极少旋转）
字体规范（宋体、黑体、等宽字体居多）
背景干净（白底+黑字，无干扰纹理）
字符间距稳定（印刷体字符间空隙可预测）

而STR（Scene Text Recognition）面对的是真实世界：

文字可能扭曲在曲面瓶身上（如饮料瓶标签）
出现在倾斜角度的路牌上（俯拍/仰拍导致透视畸变）
被雨滴、反光、阴影、模糊、低分辨率严重污染
字体千奇百怪（手写体、艺术字、霓虹灯管拼接字、毛笔书法）
单张图中混杂多语种（中英日韩+数字+符号，且排版毫无规律）

我做过一个横向对比实验：用同一套通用OCR模型（Tesseract 5.3 + LSTM后处理）去识别三类图像——
① 打印版《人民日报》扫描件（标准OCR场景）→ 识别准确率99.2%
② 手机拍摄的银行回单（轻微褶皱+阴影）→ 准确率跌至86.7%，错字集中在金额栏“¥”符号后数字串
③ 夜间拍摄的烧烤摊LED招牌（红底黄字+运动模糊+强光过曝）→ 准确率仅41.3%，连“烤”字都常被识别成“考”或“灬”

这个落差不是模型不够强，而是任务定义根本不同：OCR解决的是“如何从高质量文档图像中高保真还原文字”，STR解决的是“如何在不可控的真实场景中鲁棒地定位并理解任意形态的文字”。

所以，“OCR和STR识别整体概述”这个标题，绝不是简单罗列两个技术名词。它是一条分水岭——一边是传统图像处理+模式识别的老路，另一边是计算机视觉+深度学习+多模态理解的新战场。

适合谁读这篇？

做智能办公软件的工程师：你需要知道为什么用户上传歪斜发票时，OCR模块总报错“未检测到有效文本区域”；
教育类APP产品经理：当家长反馈“孩子拍课本习题识别不准”，你要判断是OCR预处理流程缺陷，还是该引入STR级的形变校正能力；
工业质检系统集成商：产线上金属铭牌因反光导致字符断裂，是该加补光灯硬件，还是该升级文本检测模型结构？
甚至高校课程设计者：如果只教Tesseract调参，学生毕业后面对车载摄像头拍下的限速牌，将完全无法下手。

这不是理论科普，而是我过去三年在五个落地项目中踩坑、试错、重构后沉淀下来的实战认知框架。下面我会一层层拆开：为什么必须把OCR和STR放在同一套技术栈里设计？它们的底层能力边界在哪？哪些环节可以复用，哪些必须重造？以及——最关键的一点：当你只有两周工期、一台RTX 4090和3000张标注样本时，该怎么取舍？

2. 技术演进脉络与核心能力解耦：从“端到端黑盒”到“模块化可控”

2.1 OCR的三次代际跃迁：从规则驱动到数据驱动

早期OCR（1990年代–2005年）本质是“图像工程+模板匹配”。典型代表是OCR-A、OCR-B字体标准——这些字体本身就是为机器识别设计的：字母O必须是正圆，数字0必须带斜杠，I和l必须有明显区分。系统工作流极其机械：

二值化（用固定阈值把灰度图转黑白）
噪声滤波（开运算去噪点，闭运算连断笔）
行切分（找连续黑像素的水平投影谷值）
字切分（找垂直投影谷值分割单字）
模板比对（把切出来的字图和标准字体库逐像素比对）

这套方法在银行支票识别中曾稳定运行十年，但致命缺陷是泛化性为零。一旦遇到手写体、斜体、加粗字体，或者扫描仪没压平纸张导致行弯曲，整个流水线就崩了。

第二代OCR（2005–2015年）转向统计学习。核心突破是HMM（隐马尔可夫模型）+ Gabor滤波特征。比如识别“8”字：系统不再比对完整字形，而是提取其上下两环的边缘方向分布、中间连接处的曲率变化概率。这使得模型能容忍一定形变，但训练依赖大量人工标注的字符切片——你得先手动把一万张发票上的“¥12,345.67”每个数字都框出来，再分类打标。成本极高，且对中文这种字符集大（GB2312含6763字）、字形差异小（“己已巳”三字仅靠微小笔画位置区分）的语言极不友好。

第三代OCR（2015年至今）是深度学习革命。关键转折点是2016年EAST模型提出“文本行检测即回归”思想——不再切分字符，而是直接预测文本行的四边形顶点坐标。随后CRNN（2016）、ASTER（2018）、PGNet（2021）等模型将检测+识别合为一体，用CNN提取图像特征，RNN建模字符序列依赖，CTC Loss解决不定长输出对齐问题。此时OCR真正具备了“端到端可训练”能力，但代价是：它把所有问题打包进一个黑盒，调试困难，错误归因模糊。

提示：很多团队在项目初期直接套用PaddleOCR或EasyOCR，结果在产线部署时发现——检测准但识别错，或识别准但漏检小字号文字。根源在于：这些开源方案默认按“文档场景”优化，而你的实际输入可能是“手机拍摄的模糊药盒说明书”，需要针对性调整backbone（如用ResNet50替换MobileNetV3）、修改CTC解码阈值、甚至重训检测头的anchor尺寸。

2.2 STR的破局点：从“检测+识别”双阶段到“端到端可微分”

STR的难点不在识别本身，而在“找到文字在哪”。真实场景中，文字占比可能不到图像面积的0.3%（比如远距离拍摄的楼顶广告牌），且常与背景纹理高度融合（如木纹门牌、大理石地砖上的刻字）。传统OCR的“先二值化再投影”方法在此完全失效——二值化会把文字和木纹一起吃掉，投影法根本找不到连续峰谷。

STR真正的技术分水岭是2017年提出的TextBoxes++和2018年的TextSnake。前者首次将SSD目标检测框架适配到任意方向文本框（支持旋转矩形），后者更激进：用中心线+半径场表示文字区域，能精准拟合弯曲文本（如轮胎侧壁上的环形文字）。但这只是检测环节的突破。

识别环节的瓶颈更隐蔽：STR输入的文本图像往往存在严重几何畸变。比如拍摄立式奶茶店招牌，顶部文字被拉伸，底部被压缩。若直接送入CRNN识别，RNN的时序建模会因像素空间错位而崩溃。于是ASTER（2018）提出TPS（Thin Plate Spline）形变校正模块——它像一张弹性网格，学习将扭曲文本“拉平”成标准矩形，再送入识别网络。这个模块可微分，能和检测、识别网络联合训练。

但TPS也有硬伤：它假设文字区域是单平面曲面，对多平面文字（如同时包含墙面和玻璃窗上的字）或极端透视（仰拍摩天楼LED屏）效果骤降。2022年PGNet引入更灵活的Bezier曲线拟合，用4个控制点定义文字基线，再沿基线采样生成规整文本块。实测在无人机航拍文本识别中，PGNet比CRNN+TPS的mAP高12.6%。

注意：STR模型的“端到端”不等于“无需调参”。我在某物流单据识别项目中发现，PGNet在检测小字号运单号时召回率不足。排查后发现是其默认的最小文本尺寸阈值（10像素）过高——实际运单打印字号仅7pt，在600dpi扫描下对应约8像素。将配置文件中的min_text_size从10改为6，并增加合成数据中微小字号样本比例，召回率从73%提升至91%。

2023年新动向：多模态与轻量化博弈

2023年起，两大趋势正在重塑OCR/STR技术栈：

多模态理解渗透：纯视觉模型开始融合语言先验。例如，识别到“¥12,345.67”后，结合上下文“订单金额：”可校验数字合理性；识别到“北京朝阳区建国路8号”时，利用地理知识库确认“建国路”在北京真实存在，避免将“建园路”误纠为“建国路”。这类能力在PaddleNLP的PP-StructureV2中已工程化，但需额外部署语言模型服务，对边缘设备不友好。
轻量化不可逆：车载、IoT设备、手机端APP要求模型在<5MB体积、<200ms延迟下运行。这就逼着开发者做残酷取舍：是保留TPS形变校正但增加30ms耗时，还是用更轻量的SCATTER（2023）模型——它用空间注意力替代TPS，体积仅1.2MB但对弯曲文本识别率下降8%？我的经验是：在车载HUD场景中，宁可接受8%的弯曲文本误差，也不能让文字识别延迟超过150ms（否则驾驶员视线离开路面时间超标）。

3. 核心模块拆解与实操选型指南：什么该自研，什么该直接抄作业

3.1 文本检测（Text Detection）：精度与速度的生死线

检测模块是OCR/STR的“眼睛”，它决定了后续所有环节的输入质量。选型时必须回答三个问题：

你的文字主要形态是什么？（水平/旋转/弯曲/多方向）
图像分辨率和噪声水平如何？（高清扫描件 vs 手机抓拍）
硬件资源是否受限？（服务器GPU vs 手机端CPU）

检测模型	适用场景	参数量	CPU推理耗时（1080p）	关键优势	典型缺陷
DBNet（2019）	通用文档、水平/轻度旋转文本	32M	420ms	对小文本敏感，抗噪声强	弯曲文本检测框不贴合
EAST（2017）	高速场景、CPU部署	18M	280ms	结构极简，易移植	对密集小字漏检率高
TextSnake（2018）	弯曲文本（如食品包装弧形标签）	45M	650ms	曲线拟合精度业界第一	训练难收敛，需大量弯曲样本
PGNet（2021）	多方向+弯曲混合（如机场指示牌）	58M	780ms	支持任意形状文本建模	推理慢，内存占用高
SCATTER（2023）	移动端实时OCR（如微信扫码）	4.2M	110ms	体积小，支持INT8量化	对低对比度文本鲁棒性弱

实操心得：

如果你的业务80%以上是A4文档扫描件（合同、发票、证件），DBNet是安全选择。我用DBNet+ResNet18 backbone在Jetson Xavier上做到18FPS，检测准确率98.5%。关键技巧是：关闭其默认的“二值化后处理”，改用自适应阈值（cv2.adaptiveThreshold），能显著提升扫描件阴影区域的文字召回。
若涉及大量弯曲文本（如酒瓶标签、轮胎侧壁），别硬刚TextSnake训练——它需要至少5000张带精确中心线标注的弯曲文本图。更务实的做法是：用DBNet先粗检出文本区域，再对每个区域单独跑一个轻量版TPS校正（基于OpenCV的getPerspectiveTransform），最后送入CRNN识别。这样组合方案在白酒产线项目中，弯曲标签识别F1值达92.3%，开发周期仅3天。
对手机端APP，SCATTER是目前最优解。但要注意：它的训练数据必须包含大量手机拍摄失真样本（运动模糊、镜头畸变、JPEG压缩伪影）。我们曾用合成数据生成工具TextRecognitionDataGenerator（TRDG）批量制造10万张带手机失真效果的训练图，使模型在iPhone 12实拍测试中准确率从67%提升至89%。

3.2 文本识别（Text Recognition）：从“字符级”到“语义级”的跨越

识别模块的演进，本质是“如何理解文字”的认知升级。

第一代：字符分割+独立识别
把检测框内的图像切分成单个字符（如用投影法），每个字符送入CNN分类器。优点是模型小（单字符分类器仅几MB），缺点是切分错误会传导（“川”字被切成“丿”和“一”），且无法建模字符间依赖（如“Q”后面大概率是“U”）。

第二代：序列识别（CRNN/ASTER）
用CNN提取整行图像特征，RNN（LSTM/GRU）建模字符时序关系，CTC Loss解决对齐问题。这是当前主流，但CTC有个隐藏缺陷：它假设字符间独立，无法利用语言知识。比如识别“th3 qu1ck br0wn f0x”，CTC可能输出“the quick brown fox”，但无法纠正“br0wn”为“brown”——因为0和o在CTC中是不同类别，没有语义关联。

第三代：语言模型增强（Transformer+LM）
2022年后，主流方案转向Transformer架构（如ABINet、VisionLAN）。它用自注意力机制捕捉长距离字符依赖，再接一个轻量BERT微调模型做后处理。例如，识别到“北京市朝阳区建囯路8号”，Transformer先输出“建囯路”，BERT后处理模块根据“北京朝阳区”地理常识，将“囯”纠正为“国”。

实操选型建议：

纯技术验证期：直接用PaddleOCR的PP-OCRv3。它已集成DBNet检测+SVTR识别+语言模型后处理，一行命令即可启动：

paddleocr --image_dir ./test_images --use_angle_cls true --lang ch

实测在标准测试集ICDAR2015上，它达到86.2%的端到端F1值，且支持中英文混合识别。

生产环境部署：必须拆解。原因有三：
1. PaddleOCR的SVTR模型体积达120MB，而我们的车载设备Flash仅剩80MB可用空间；
2. 它的默认语言模型是通用中文维基，但我们的业务场景是医疗报告，需识别“心电图”“QTc间期”等专业术语；
3. 它的后处理逻辑固化，无法插入业务规则（如金额字段强制校验“¥”符号后必须为数字）。

我们最终采用“DBNet检测 + CRNN识别 + 自研规则引擎”三段式架构：

CRNN用ResNet34+BiLSTM，输出CTC概率矩阵；
规则引擎接收原始CTC输出和置信度，对特定字段执行强约束：
- 金额栏：正则匹配¥\d+\.\d{2}，若不匹配则触发二次识别（放大ROI区域重新检测）；
- 日期栏：校验是否符合YYYY-MM-DD格式，否则调用NLP模型分析上下文（如“就诊日期：”后文字）；
- 医学术语：查本地术语库，对低置信度词（如“QTc”识别为“QTC”）进行编辑距离匹配。

这套方案使医疗报告识别准确率从81%提升至94.7%，且规则引擎代码仅300行Python，运维人员可随时更新正则和术语库。

3.3 后处理（Post-processing）：被严重低估的“最后一公里”

90%的OCR项目失败，不是因为模型不准，而是后处理没做好。常见陷阱：

陷阱1：盲目信任模型置信度
CRNN输出的每个字符都有置信度，但这个值在不同场景下含义不同。在清晰文档中，置信度<0.8的字符大概率错；但在模糊车牌识别中，所有字符置信度都低于0.6，此时若按0.8阈值过滤，会直接丢弃整行。

解决方案：动态置信度阈值。我们按图像质量指标（BlurLevel + ContrastRatio）映射阈值：

BlurLevel < 5（清晰）→ 置信度阈值0.75
BlurLevel 5–15（中度模糊）→ 阈值0.55
BlurLevel > 15（严重模糊）→ 阈值0.35，并启用N-gram纠错

陷阱2：忽略业务语义校验
识别出“订单号：ABC123456789”，但数据库中不存在该订单号。此时不应直接返回错误，而应检查：

是否少识别了末尾数字？（常见于低分辨率图像）
“B”是否被误识为“8”？（字形相似）
是否多识别了空格？（“ABC 123”被识别为“ABC123”）

我们构建了一个轻量级业务校验层：

对订单号字段，预设正则[A-Z]{3}\d{9}，若不匹配，则用Levenshtein距离在数据库最近100条记录中搜索相似项；
对手机号字段，强制校验前三位运营商号段（139/186/155等），并验证11位长度；
对地址字段，调用高德地图API做模糊匹配，返回匹配度>80%的标准化地址。

这套校验层使某快递单识别系统的用户投诉率下降63%，因为系统不再返回“无法识别”，而是给出“您要找的是‘北京市朝阳区建国路8号SOHO现代城’吗？”的智能提示。

4. 全流程实操：从0到1搭建一个工业级OCR/STR系统

4.1 需求分析与场景建模：拒绝“拿来主义”

很多团队一上来就下载PaddleOCR，跑通demo就以为成功了。结果在客户现场，识别率惨不忍睹。根本原因是：没做场景建模。

以我参与的某汽车零部件铭牌识别项目为例，需求描述只有短短一句：“识别发动机铭牌上的型号、序列号、生产日期。”
但深入现场调研后，我们发现真实场景复杂得多：

光照：车间顶灯为频闪LED，导致铭牌反光呈条纹状；
角度：工人手持扫码枪拍摄，倾角在±25°内随机波动；
材质：铭牌为金属蚀刻，部分批次表面覆哑光膜，部分为镜面不锈钢；
干扰：铭牌边缘有油污、划痕，序列号区域常被手指遮挡；
字体：型号用标准黑体，但生产日期用激光打标的小号等线体，字号仅2pt。

这些细节决定了技术方案：

必须加入主动光源（环形LED补光灯），消除频闪干扰；
检测模型需支持±30°旋转框，放弃EAST改用DBNet；
识别模型要针对2pt小字优化：将输入图像resize到128×32（而非默认64×256），并用超分网络ESRGAN预增强；
数据增强必须模拟油污（用Perlin噪声生成污渍mask）、手指遮挡（随机覆盖矩形区域）、金属反光（添加高斯光斑）。

关键动作：在现场用手机拍100张真实样本，人工标注“哪些图识别失败”，然后归类失败原因。我们总结出TOP3失败模式：

反光导致字符断裂（占失败样本42%）→ 解决方案：在预处理加CLAHE对比度增强；
小字号日期被漏检（31%）→ 解决方案：检测头增加小尺度anchor（8×8, 12×12）；
镜面不锈钢反射操作员身影（27%）→ 解决方案：在采集端加偏振镜滤除反射光。

这个过程耗时2天，但避免了后续2周的无效模型调优。

4.2 数据准备：不是越多越好，而是越“像”越好

OCR/STR的数据困境在于：真实场景数据获取成本高，合成数据又容易“假”。我的经验是：用70%合成数据+30%真实数据，但合成数据必须带真实退化模型。

合成数据生成四步法：

字体与内容生成：用TRDG生成基础文本图。重点不是字数多，而是覆盖业务全字符集。例如医疗场景，必须包含“αβγδε”希腊字母、“℃”“±”“×”等符号，以及“心电图”“血氧饱和度”等长词。
背景注入：不用纯色背景！从真实场景图中抠取背景（如车间地面、医院白墙、快递纸箱纹理），用泊松融合嵌入文字。
退化模拟：这是最关键的一步。不能只加高斯模糊，要按物理规律模拟：
- 运动模糊：用cv2.blur模拟手持抖动，模糊核方向随机（0°–360°），长度按拍摄距离估算（1m距离对应3px模糊）；
- 镜头畸变：用OpenCV的cv2.undistort反向施加桶形畸变，模拟广角镜头；
- JPEG压缩：用cv2.imencode以不同quality参数（30–70）保存，模拟手机上传画质损失。
噪声叠加：在最终图像上叠加传感器噪声（用np.random.normal生成高斯噪声）和椒盐噪声（模拟CMOS坏点）。

真实数据标注规范：

检测标注必须用多边形（非矩形框），尤其对弯曲文本；
识别标注必须严格按阅读顺序，中文从左到右，但古籍竖排需从上到下、从右到左；
对低置信度区域（如反光处），标注“模糊”标签，模型训练时可加权损失。

我们在某银行票据项目中，用此方法生成5万张合成图+5000张真实图，模型在测试集上F1值达93.1%，比纯真实数据训练（仅5000张）高11.2%。

4.3 模型训练与调优：避开那些“看起来很美”的坑

学习率策略：别迷信cosine衰减。OCR任务中，前期需要快速收敛检测头，后期需要精细调整识别头。我们采用分段学习率：

第1–20轮：检测头LR=1e-3，识别头LR=5e-4（冻结识别头，专注学检测）；
第21–40轮：检测头LR=5e-4，识别头LR=1e-3（解冻识别头，联合微调）；
第41–60轮：全局LR=1e-4，加余弦衰减（精细收敛）。

损失函数组合：

检测头：Dice Loss（对小目标更敏感） + L1 Smooth Loss（回归框坐标）；
识别头：CTC Loss（主损失） + 字符级交叉熵Loss（辅助损失，监督每个位置分类）。

关键调参经验：

Batch Size不是越大越好：在8卡V100上，DBNet用BS=32比BS=64收敛更快。因为大BS导致梯度平均化，削弱了对小文本的梯度信号；
图像尺寸要匹配硬件：训练时用1280×720输入，但部署时显存受限，需缩放到960×540。此时不能简单resize，而要用cv2.resize(img, (960,540), interpolation=cv2.INTER_AREA)（区域插值），避免高频信息丢失；
早停（Early Stopping）要看检测头mAP，不是整体loss：我们曾遇到loss持续下降但检测召回率停滞，原因是识别头过拟合，拖累了检测头梯度。

4.4 部署与监控：让模型活在真实世界里

部署不是终点，而是新问题的起点。

边缘设备部署要点：

用TensorRT加速：将PyTorch模型转ONNX，再用trtexec编译。注意：DBNet的FPN结构在TRT中需手动指定fp16_mode=True，否则精度暴跌；
内存优化：识别模块输出CTC概率矩阵后，立即释放GPU显存，再用CPU做后处理；
热启动缓存：预加载常用字体库和术语表到内存，避免每次识别都IO等待。

线上监控体系：

基础指标：每小时统计识别准确率、平均耗时、失败率；
深度归因：对失败样本自动聚类，识别TOP失败模式（如“反光导致漏检”“小字号识别错”）；
漂移检测：每周用KS检验对比新旧数据分布，若图像模糊度分布偏移>0.15，触发数据重采样告警。

在某快递分拣系统中，我们通过监控发现：每月15号后识别失败率上升12%。排查发现是快递员更换了新款手机（华为Mate50），其计算摄影算法自动锐化图像，导致OCR预处理的二值化阈值失效。解决方案：在预处理加“锐化强度检测”，对高锐化图像自动降低二值化阈值。

5. 常见问题与避坑指南：那些没人告诉你的“血泪教训”

5.1 典型问题速查表

问题现象	可能原因	排查步骤	解决方案
检测框严重偏离文字区域	检测模型未适配小目标	1. 用OpenCV画出检测框与原图叠加 2. 统计框面积/文字面积比值	增加小尺度anchor；在FPN最底层加额外检测头
识别结果中英文混杂乱码	字符集不匹配	1. 检查训练时label.txt是否含中文 2. 查模型输出logits维度是否=字符集大小	重建字符集，确保排序一致（ASCII在前，中文在后）
同一图片多次识别结果不同	随机性未禁用	1. 检查torch.backends.cudnn.benchmark=True 2. 查模型中是否有Dropout层未设eval()	训练/推理均设`torch.backends.cudnn.deterministic=True`；推理时`model.eval()`
CPU部署耗时暴涨	内存拷贝瓶颈	1. 用`perf record -g`分析热点 2. 查OpenCV imread是否用BGR转RGB耗时	改用`cv2.cvtColor(img, cv2.COLOR_BGR2RGB)`替代PIL转换；预分配numpy数组避免重复malloc
低光照下识别率骤降	预处理未适配	1. 统计图像平均亮度值 2. 查CLAHE参数是否固定	动态CLAHE：亮度<50时clipLimit=3.0；亮度50–150时clipLimit=2.0

5.2 独家避坑技巧

技巧1：用“失败样本反哺”代替盲目扩数据
不要一遇到失败就去爬10万张新图。先做失败分析：

收集100个失败样本；
人工标注“失败根因”（如“反光”“模糊”“小字”“字体特殊”）；
对每类根因，只生成100张针对性合成图（如专攻反光，就用高斯光斑+金属材质背景）；
重训模型，观察该类错误是否下降。
我们在某药盒识别项目中，用此法3天内将“反光导致漏检”错误从38%降至9%，而盲目扩数据需2周。

技巧2：给模型加“人类常识”
纯数据驱动模型不懂业务。例如识别“生产日期：2023-02-30”，模型可能照单全收。解决方案：

在后处理加规则引擎，对日期字段强制校验有效性（用datetime.date(2023,2,30)会抛异常）；
对金额字段，检查小数点后位数（人民币必须2位），不符则触发重识别；
对车牌号，用正则[京津沪渝冀豫云辽黑湘皖鲁新苏浙赣鄂桂甘晋蒙陕吉闽贵粤青藏川宁]*[A-Z]{1}[A-Z0-9]{5}校验。

技巧3：警惕“过拟合测试集”幻觉
很多团队在ICDAR2015上跑出95% F1就宣布成功。但ICDAR2015是精心裁剪的干净图。务必做“野外测试”：

用手机随机拍100张真实场景图（超市小票、餐厅菜单、公交站牌）；
不做任何预处理，直接送入模型；
统计真实F1值。
我们某项目在ICDAR上95.2%，野外测试仅68.7%。根源是：模型学会了“猜”——ICDAR图中文字总在中央，模型把中央区域默认为文字区。解决方案：在训练时加入随机裁剪（RandomCrop），强制模型学习全局特征。

技巧4：版本管理必须包含“数据快照”
模型版本号（v1.2.3）没用，关键是要记录：