在实际的商铺招牌、路牌、车辆外观、商品包装和街景翻译这类任务里文字经常出现在拍摄条件不可控的自然场景中而不是平整的扫描文档里。这类图像被领域内统称为 in-the-wild 场景文字图像。大多数开源 OCR 模型和公开基准都集中解决英文和中文问题而孟加拉语Bengali / Bangla作为全球使用人数排名靠前的语言之一在场景文字识别方面长期缺少一个足够真实、足够有区分度的公开评测环境。BanglaWild 正是针对这个缺口出现的一个场景文字识别基准它的目标不只是提供一个测试集而是给 OCR 模型和视觉语言模型Vision-Language Model, VLM一起立一把可比较的尺子。这篇文章会围绕 BanglaWild 这一类 in-the-wild 基准展开先讲清楚孟加拉语文字识别的难点在哪里再拆解一个场景文字基准是如何设计、标注和评估的然后落到工程实践如何自建多语言文字识别评估流水线、常见落地方案有哪些、部署到 RK3588 这类边缘设备时要注意什么。希望通过这篇内容你能够理解为什么多语种 OCR 不能靠英文模型“凑合”也能够在自己的项目里复现、扩展和使用类似的评估方法。1. 孟加拉语场景文字识别为什么比英文更难1.1 孟加拉文书写系统带来的三层识别困难先从一个直观对比说起。英文单词由 26 个拉丁字母组成识别时模型只需要从有限字符集中找出字符序列。孟加拉语虽然也属于表音文字系统但其书写形态比英文复杂很多。第一层困难来自合写字形。孟加拉文中存在大量连写、合写结构当一个辅音字母与另一个辅音字母组合时字形会发生明显变化而不是简单地把两个字母并排拼在一起。训练过中文 OCR 的人可以把这种结构类比成汉字中的合体字但孟加拉语的合写规则更系统、更多变。第二层困难来自元音符号和辅音组合的二维排布。部分元音符号会出现在辅音字母的上方、下方、左侧或右侧模型不能只按从左到右的顺序读取字符还需要理解字形之间的相对位置关系。对不熟悉该文字系统的开发者来说这种排版方式很容易和“倾斜文本”混淆。第三层困难来自语言形态。孟加拉语是屈折语言同一词根在不同语法环境下会带上不同后缀一个词在图像里可能出现多音节、多符号叠加的结构。这样造成的结果是真实图像的词汇分布非常稀疏很多单词在训练集里只出现一次模型很难靠“背词表”来蒙对。如果再把这三层困难放到自然场景中模型要处理的就不只是字符识别而是“定位一串符号 理解它们的组合关系 输出正确的 Unicode 文本”。1.2 场景文字与文档文字的本质差别传统文档 OCR 通常处理印刷体、白底黑字、行方向一致、文字清晰的文件。二值化、行分割、字符分割这些经典流程在扫描件上还能工作到了店铺招牌和街道场景中就很难继续。场景文字识别面对的情况是拍摄角度不固定文字区域可能是透视畸变后的四边形。光线不稳定反光、阴影、夜间霓虹灯会造成前景和背景对比度剧烈变化。文字可能被遮挡、弯曲或者位于曲面瓶身、弧形招牌和运动物体上。背景不是白色而是包含纹理、复杂图案甚至其他文字。所以 in-the-wild 场景文字识别通常不是一个“识别”问题而是“检测 识别 场景理解”的组合问题。模型必须先定位文字区域再把区域内的符号转写成正确文本最后还要把文本放到视觉上下文中理解语义。1.3 “In-the-Wild”这个说法到底指什么“In-the-wild”在视觉领域里指数据来自真实自然环境而不是实验室或人工合成环境。对于文字识别来说它意味着图像是手机或相机在真实街头拍摄的文字形式包含各种字体、颜色、尺寸、语言混合和物理变形。用一张表格来对比会更清楚数据类型图像来源文字状态背景复杂度适合解决的问题扫描文档扫描仪、高拍仪印刷体、排版规整低文档数字化、票据识别合成文字程序自动生成字体和背景可控中预训练、数据增强场景文字自然拍摄透视、遮挡、光照多样高街景、拍照翻译、多语种识别BanglaWild 之所以强调 in-the-wild是因为合成数据虽然可以快速制造出海量样本但合成图像和真实拍摄图像之间存在明显的分布差异。一个只在合成数据上训练过的模型进入真实街道后经常会出现“训练时指标很高、上路时崩溃”的问题。这个基准的价值就在于提供一个贴近真实分布、并且有明确评估协议的测试环境。2. 从 BanglaWild 看 in-the-wild 场景文字基准的数据设计2.1 数据采集与标注上的关键权衡一个能被行业长期使用的场景文字基准通常不只是“一堆图片加标注”它还要回答几个问题图片从哪里来标注规范是什么难例如何处理评估如何保证公平。在数据来源上多数 in-the-wild 基准会从街头拍摄、公开图像平台、众包拍摄等渠道收集图像。采集时不会刻意要求固定字体或固定背景这样得到的样本才符合真实环境。对于孟加拉语来说孟加拉国和印度西孟加拉邦的街道、市场、交通标识和商业海报是主要自然来源。在标注规范上场景文字基准通常包含两个层次文本行级别的四边形或多边形标注用来训练检测模型。文本行对应的转写文本用来训练识别模型和计算最终指标。标注时还会给每个文本行标注语言标签。因为在真实街道中同一块招牌上可能同时出现孟加拉语、英语和印地语。语言标签可以帮助评估系统在多语言混合场景下的表现。对于不确定的样本比如遮挡严重、模糊不清或者多位标注者意见不一致的图像比较严谨的做法是保留多位标注者的结果或者单独划分为“难例集”。这样做的好处是避免评估指标被低质量标注稀释。2.2 数据组织方式训练集、验证集和测试集为何要分开学术基准和比赛通常会把数据拆成三类训练集、验证集和测试集。训练集用于模型学习验证集用于调参和选择模型测试集用于最终评估。为了避免数据泄漏划分时一般会尽量保证同一场景、同一招牌的图像不会同时出现在训练和测试里。对场景文字来说还要特别注意字符分布和词汇分布。如果随机切分模型可能在测试集里看到大量训练集出现过的重复词汇导致评估结果偏高。更合理的方式是按场景、按地点或者按语义去重让测试集更接近“没见过的场景”。2.3 一个最小可读的数据集目录结构在工程项目里数据集通常会组织成统一的目录结构。以这类场景文字基准为参考最小结构大致如下banglawild/ ├── images/ │ ├── street_0001.jpg │ ├── street_0002.jpg │ └── ... ├── annotations/ │ ├── train.json │ ├── val.json │ └── test.json ├── scripts/ │ ├── eval.py │ └── visualize.py └── README.md一个文本行标注的 JSON 示例可以写成{ image: images/street_0001.jpg, language: bn, text_lines: [ { text: ঢাকা, box: [120, 340, 420, 345, 410, 410, 130, 405], rotated_box: [[120, 340], [420, 345], [410, 410], [130, 405]], difficult: false, annotation_id: 1 }, { text: DHAKA, box: [430, 350, 610, 350, 610, 400, 430, 400], difficult: false, annotation_id: 2 } ] }这里的box可以用四边形的四个角点表示rotated_box则更适合直接画在图像上。标注中的difficult字段非常关键它标记那些人工也较难确认的样本评估时可以选择剔除或单独统计避免模糊样本对精度产生干扰。需要说明的是实际 BanglaWild 的具体字段设计应以项目发布的说明文档为准这里给出的只是一种通用结构。目录规范和字段命名越稳定后续扩展评测脚本时的成本就越低。3. 基准如何同时服务传统 OCR 与视觉语言模型3.1 传统 OCR 模型在孟加拉语上要闯哪些关传统 OCR 系统通常走“文本检测 文本识别”两级管线。文本检测部分负责找到图像中可能包含文字的区域常见做法是回归文字框文本识别部分负责把裁剪出来的区域转写成字符串。在孟加拉语场景中通用开源引擎的表现通常不如英文和中文。原因主要有三点字符集差异大模型需要对大量合写字形形成稳定特征表达。训练数据不足公开可用的孟加拉语场景文本检测与识别数据比英文少很多。部署时字符解码和 Unicode 规范化容易被忽略导致模型输出无法和标注对齐。以 Tesseract 为例它虽然支持多语言 LSTM 模型但它的强项是相对规整的文档图像。遇到透视变形、背景复杂和曲面文字时识别链路中的检测前置处理就显得不够用了。如果你在项目里打算用 Tesseract 跑孟加拉语场景文字合理的做法是先裁剪文本区域再尽量做透视矫正和图像增强最后再交给识别引擎。更现代的做法是训练 CRNN CTC 或者基于 Transformer 的识别模型。这类模型可以直接接收文本行图像并输出序列不需要显式切分字符这对带有大量连写的孟加拉文字形更友好。3.2 视觉语言模型给评估带来了什么变化视觉语言模型和传统 OCR 最大的区别在于它不只是“把图像中的文字转写出来”而是把图像和文本放在同一个模型里进行联合理解。用 BanglaWild 这样的基准来评估 VLM通常有两种视角第一种是纯粹的文字转写视角。把包含孟加拉文字的场景图像或裁剪后的文字区域输入 VLM要求模型输出其中出现的所有文字然后和真实标注比较。第二种是视觉问答和语义理解视角。例如给定一张路牌图片问模型“这个指示牌上的地名是什么”“店铺几点营业”“菜单上最贵的菜品是什么”。这时模型不仅需要识别文字字符还要理解排版顺序、指代关系和结构化信息。对基准设计者来说VLM 的评估难度更高因为一个问题可能有多种合理答案。评测时需要定义答案匹配规则例如精确匹配、子串匹配、语义等价匹配甚至是基于向量相似度的软匹配。BanglaWild 这类基准如果后续扩展到 VQA 场景需要同时给出问题集、答案规范以及匹配策略而不是只提供一个转写文本。3.3 评测指标不能只看“整词对了没有”在传统 OCR 评估里最常用的指标是字符错误率CER和词错误率WER。如果只计算整词是否完全匹配会因为孟加拉语的屈折形态变化而低估模型的真实能力。比如一个词从词根কর变成করে字符上只差一个位整词匹配却会直接判错。因此评估场景文字识别模型时至少应该看以下指标指标计算方式适用场景CER编辑距离 / 真值字符数细粒度识别质量适合孟加拉语WER词编辑距离 / 真值词数整词级别质量适合信息抽取精确匹配预测完全等于真值才计 1结构化字段核对最严格词表外识别率测试集里未出现在训练集的词的 CER检验泛化能力对于 BanglaWild 这种 in-the-wild 基准最值得关注的不是模型见过多少常见词而是模型面对没有见过的街道招牌、没有见过的合写结构和轻微模糊文字时能否稳定输出正确 Unicode 序列。4. 自建多语言文字识别评估流水线一个最小实现4.1 评估前的输入准备要把自己的 OCR 或 VLM 预测结果和 BanglaWild 这类基准对齐准备工作有三步第一步读取真值标注得到每个文本行的标准文本字符串。第二步调用模型对同样的图像区域进行预测。第三步把预测文本和真值文本放到统一的匹配逻辑里计算 CER 和 WER。这里最容易被忽略的是文本规范性处理。孟加拉语文本在 Unicode 下可能有不同编码形式例如某些组合字符可以表现为不同的码位序列。建议在计算指标之前对所有文本执行 Unicode 规范化NFC并去掉控制字符和多余空白。4.2 用 Python 实现一个最小指标计算脚本下面这段代码演示了如何读取一个简单的 JSON 标注文件并计算字符错误率和词错误率。import json import unicodedata def normalize_text(text: str) - str: 统一文本编码去除多余空白。 text unicodedata.normalize(NFC, text) text .join(text.strip().split()) return text def edit_distance(a: str, b: str) - int: 计算两个字符串之间的编辑距离。 if len(a) len(b): a, b b, a previous list(range(len(b) 1)) for i, ca in enumerate(a, 1): current [i] for j, cb in enumerate(b, 1): insert_cost current[j - 1] 1 delete_cost previous[j] 1 replace_cost previous[j - 1] (ca ! cb) current.append(min(insert_cost, delete_cost, replace_cost)) previous current return previous[-1] def compute_metrics(pred_text: str, gt_text: str): pred normalize_text(pred_text) gt normalize_text(gt_text) cer edit_distance(pred, gt) / max(len(gt), 1) pred_words pred.split() gt_words gt.split() wer edit_distance(pred_words, gt_words) / max(len(gt_words), 1) exact_match int(pred gt) return { cer: round(cer, 4), wer: round(wer, 4), exact_match: exact_match, } # 使用示例 if __name__ __main__: with open(annotations/test.json, r, encodingutf-8) as f: data json.load(f) total_cer 0.0 total_wer 0.0 exact_count 0 line_count 0 for image_item in data: for line in image_item[text_lines]: gt_text line[text] # 这里替换成你的模型输出结果 pred_text ঢাকা metrics compute_metrics(pred_text, gt_text) total_cer metrics[cer] total_wer metrics[wer] exact_count metrics[exact_match] line_count 1 print(f样本数: {line_count}) print(fCER: {total_cer / max(line_count, 1):.4f}) print(fWER: {total_wer / max(line_count, 1):.4f}) print(f精确匹配率: {exact_count / max(line_count, 1):.4f})代码的关键点有三处。第一normalize_text使用 NFC 规范化文本这是避免同一字形不同编码导致误判的必要手段。第二编辑距离直接把字符串看作字符数组适用于计算 CER计算 WER 时则把字符串按空格切分为词列表再对词列表计算编辑距离。第三max(len(gt), 1)防止真值文本为空时出现除零错误。4.3 运行验证和结果解读如果你用完整 BanglaWild 测试集跑完上述脚本观察指标时要注意两个问题一是 CER 和 WER 之间的差异。如果 CER 很低但 WER 很高说明模型大多数字符都能识别对但在词边界或者个别字符上出错导致整个词被替换。二是精确匹配率通常远低于 CER 反映的水平这在场景文字中是正常的。关键是不要只看单个指标而要把 CER、WER、精确匹配和不同类别样本上的表现一起看。5. 把评估能力迁移到工程项目从服务选型到边缘部署5.1 常见 OCR 落地方案对比工程中接入多语种 OCR 时常见选择是使用商业云 OCR、开源 OCR 框架或自研模型。下面用表格对比几类方案方案类型代表方向适合场景主要约束云 OCR 服务百度 OCR、阿里云 OCR网络带宽充足、不想维护模型依赖网络、按量付费、数据出域开源 OCR 框架Tesseract、PaddleOCR可控部署、离线需求多语种效果需要调优自研模型CRNN、Transformer OCR垂直领域、专有字符集需要大量标注数据和训练资源端侧模型量化 CRNN、轻量检测模型边缘盒子、RK3588 等设备算力、内存、算子支持受限对于孟加拉语这类非主流语种如果团队没有足够标注数据优先建议采用“云服务 开源模型”组合验证效果。先用通用服务评估真实数据上的准确率再决定是否值得自研。5.2 在 RK3588 这类边缘设备上运行 OCR 的思路热搜里出现过“百度 OCR 怎么在 RK3588 运行”这类问题这里从工程角度讲清楚可行思路。RK3588 是面向边缘计算的 ARM 平台拥有 CPU、GPU 和 NPU 算力。OCR 在这种设备上的部署不是把云服务 SDK 直接塞进去而是需要把模型转换成设备可执行的格式再进行内存和速度优化。部署流程通常分四步第一步在服务器端选型和训练模型。检测模型可以用轻量的文本检测网络识别模型用 CRNN 或轻量 Transformer。第二步把模型导出成 ONNX再根据目标硬件工具链转换成 RKNN 等格式。第三步在设备端验证算子兼容性、内存占用和推理耗时。第四步设计下游逻辑比如图像前处理、结果后处理和业务联动。在 RK3588 上运行 OCR 时最重要的三个检查点是模型输入尺寸是否固定动态尺寸在 NPU 上可能会触发额外转换增加耗时。是否启用了 INT8 量化量化后模型体积和推理速度会改善但 CER 可能上升需要结合业务阈值评估。是否控制了并发数多个模型同时推理时NPU 资源分配和内存冲突是常见崩溃原因。需要说明的是商业云服务通常不提供直接给边缘设备使用的离线 SDK所谓“在 RK3588 上运行”更准确的解释是从云端或开源模型出发在边缘设备上重新部署一个独立运行的 OCR 服务。若一定要用商业云端模型也要走 HTTP API 调用而不是把模型文件直接搬到本地。6. 常见的坑与排查路径6.1 模型在测试集表现好上线后崩溃现象模型在 BanglaWild 这类公开测试集上跑出不错的结果部署到真实业务场景后准确率明显下降。原因业务场景的数据分布和测试集不一致例如业务画面里大量出现夜景、俯拍、曲面文字或特定字体而测试集里这些样本比例较低。检查方式在真实业务数据上重新抽样并人工标注 200 到 500 个文本行用第 4 节的评估脚本分别计算 CER对比测试集和业务集的指标差异。解决方式把业务数据按比例混入训练集微调模型或者先做针对性数据增强再评估效果。预防手段是建立业务专有的“影子评估集”每次发布模型前都跑一遍。6.2 Unicode 编码不统一导致指标虚高或虚低现象人工检查模型输出时发现文字是正确的但评估脚本里的精确匹配率非常低。原因同一个孟加拉语文本在 Unicode 下可能有多种组合序列比如变音符号顺序不同。预测端和标注端没有统一规范化直接比较字符串就会判定不相等。检查方式打印预测文本和真值文本的 Unicode 码位比较是否完全一致。解决方式在评估和模型后处理阶段统一使用 NFC 规范化并清理零宽字符和不可见控制字符。6.3 词表外词汇处理不当现象模型在训练集覆盖的高频词上表现很好遇到未见过的词汇时整句崩溃。原因后处理阶段加入了基于词表的语言模型或者强纠错逻辑比如把低置信度字符强行替换成词表内近邻词。在孟加拉语这类形态丰富的语言中这种做法会伤害原本正确的预测。检查方式移除词表纠错逻辑重新计算 CER统计预测结果中落在词表外词汇的比例。解决方式场景文字识别中不要盲目叠加词表约束优先提高字符级识别质量。如果必须使用语言模型要允许词表外词通过并设置置信度阈值。6.4 标注规范不一致带来的评估误差现象不同标注者对同一图像给出的转写文本不一致或者有的标注包含标点有的不包含标点。原因缺少标注规范例如是否保留标点、数字是否统一为半角、英文和孟加拉语混合时如何处理。检查方式抽样检查 JSON 标注对比多个标注者对同一图像的结果。解决方式在标注阶段建立明确规范评估阶段提供多种匹配模式比如忽略标点、忽略大小写、统一数字格式并按不同模式分别报告指标。7. 可复用的评估与数据治理清单7.1 构建一个多语种场景文字评估集当你要在自己项目里构建类似 BanglaWild 的小型评估集时可以按下面这份清单执行确定目标语种和分布先统计业务数据里各语种、各场景类型的占比。确定标注单位文本行还是单词级别是否需要框坐标。确定标注规范标点、数字、英文混合、大小写、编码统一方式。建立难例标记模糊、遮挡、多人标注不一致的样本单列。划分数据按场景去重避免同一招牌同时出现在训练集和测试集。编写评估脚本至少实现 CER、WER、精确匹配三项指标。固化模型输出格式统一为 JSON 或 TSV方便后续对比。这份清单在学习和生产环境中都适用区别在于生产环境还要增加权限控制、数据加密和版本管理。7.2 学习环境与生产环境的差异检查项学习环境生产环境数据规模几百张图像即可需要按业务场景分层抽样标注精度能看懂即可需要多人交叉验证指标解读看 CER 和 WER 总体情况分场景、分语种、分难易度统计模型部署单机跑通即可需要考虑服务化、监控、回滚隐私与合规可用公开数据敏感数据需要脱敏和权限管控在生产环境里评估不应该是一次性动作而是每次模型发布前都要执行的回归流程。比较好的做法是写一个 CI 任务在推送模型新版本时自动跑 BanglaWild 或自建评估集把 CER 变化直接反馈到模型发布记录里。8. 下一步可以从哪里扩展从 BanglaWild 这个基准可以延伸出三个值得关注的方向。第一个方向是场景文字理解而非单纯识别。传统 OCR 输出的是字符串但许多业务需要的是结构化字段比如从广告牌上抽出地名、从菜单上抽出价格、从商品包装上抽出生产日期。评估基准需要从“字符转写准确”升级为“字段抽取准确”。第二个方向是多语种联合建模。真实街道中经常是孟加拉语和英语混排模型能否在处理同一个场景时自动切换语言并且根据上下文判断哪部分是地名、哪部分是店铺名这比单独优化某个语种的 CER 更有工程价值。第三个方向是视觉语言模型在弱监督条件下的评估。VLM 在图像级描述、基于文字的视觉问答等任务上表现更强但它是否真的在“读字”还是在“猜语义”这需要像 BanglaWild 这样专门设计样例来检验。后续基准可以加入对抗样本例如把招牌文字和背景语义设置成不一致从而判断模型是否真的关注到了文字本身。在实际项目中无论你选择商业 OCR 服务、开源框架还是自研识别模型都应该把“建立一套稳定可复现的评估集”放在模型训练之前。文字识别是一项对数据分布极其敏感的任务没有一把可信的尺子模型迭代就会变成在误差上跳舞。BanglaWild 的价值不止于孟加拉语本身它的设计思路值得所有面对小语种、多文字系统、复杂场景的开发者参考。