BanglaWild基准：孟加拉语场景文字识别与VLM评测实战解析

孟加拉语（Bangla/Bengali）场景文字识别这几年被越来越多的 OCR 团队和视觉语言模型（VLM）研究者关注。BanglaWild 这个基准的名字里，有两个关键词最值得注意：一个是 "In-the-Wild"，说明它收集的是真实街景、店铺招牌、货物包装、广告海报这类自然场景里的文字；另一个是 "Benchmark"，说明它不是直接给你一个现成识别模型，而是给你一套统一的评测数据、评测方法和对比口径，用来检验 OCR 模型和视觉语言模型在孟加拉语场景文字上的真实水平。

这篇内容我会围绕 BanglaWild 这个基准，拆解几个实际做 OCR 或 VLM 评测时绕不开的问题：场景文字和文档文字到底差在哪；一个“野外”基准的构建要解决哪些数据问题；用这套基准评测模型时应该看哪些指标、怎么避免误判；以及从基准走向真实生产时，哪些坑最容易被忽视。

如果你正准备找一份非英文场景文字数据集来检验自己的 OCR 管线，或者想了解视觉语言模型在小语种场景文字上的表现边界，这篇文章值得往下看。

1. 先搞清楚：BanglaWild 测的是“场景文字”，不是文档扫描件

1.1 场景文字和文档 OCR 的根本差异

很多人第一次接触 BanglaWild 时，第一反应是：不就是个 OCR 吗？我拿 Tesseract 或者 PaddleOCR 跑一下不就行了。

这里先纠正一个常见误解。文档 OCR 面对的是印刷体、白底黑字、排版规整的扫描页或 PDF，模型要解决的核心问题是版面解析和字符切分。场景文字识别面对的是招牌、路牌、商品包装、收银小票、公交车身、手机拍摄的屏幕照片，文字和背景混杂，光照、模糊、遮挡、透视变形都是常态。

这个差异直接决定了一件事：不能用文档 OCR 的评测标准来衡量场景文字识别模型。

传统文档 OCR 的评估重点通常是字符级准确率和单词级准确率，因为这些任务里文字区域和版面相对固定。场景文字识别的评估重点则偏向“整句识别是否连贯”“形近字有没有被误判”“弯曲、倾斜文字能不能读出来”。

BanglaWild 作为一个 In-the-Wild 基准，核心目的就是把“自然场景里的孟加拉语文字”变成一批可以量化对比的测试用例。它不是在验证你的模型会不会识别印刷体孟加拉语，而是在验证模型面对真实世界里的复杂干扰时，还能不能稳定输出正确的文本序列。

1.2 孟加拉语文字的特殊性，为什么不能直接套英文场景数据集

孟加拉语属于孟加拉-阿萨姆语支，书写系统是婆罗米系文字的一种。和英文相比，它有几个对 OCR 模型特别不友好的地方。

第一，字符连写和变形。孟加拉语字符不是简单的“字母按顺序排列”，字母在不同位置会出现形态变化，很多字符带上方横线，词内字符通过这条横线连在一起。模型如果只按英文字母的切分思路去提取特征，很容易在字符边界上出错。

第二，元音附标和辅音合字。孟加拉语有大量元音附标和辅音合字，这些符号会叠加在基础字符上方、下方、左侧或右侧。传统 OCR 的“先切字符、再逐个分类”的管线，在遇到这些叠加符号时往往会把一个完整字形拆成多个碎片，或在合并时产生错误。

第三，形近字多。很多孟加拉语字符和符号之间的视觉差异非常细微，比如某些附标和某些独立字母的外观很接近。在低分辨率、模糊、倾斜的照片里，这些细微差异会被进一步放大。

所以 BanglaWild 这类基准如果构建得合理，它的价值不只是“多了一组测试图片”，而是给“孟加拉语场景文字识别”这个任务提供了一套能区分模型高下的测试集。同一套图片，强模型和弱模型之间的分数差距，能真实反映它们在字符建模、上下文理解、图像抗干扰能力上的差异。

1.3 基准和数据集、比赛、模型的区别

再补一个容易混淆的概念。很多人会把基准（Benchmark）和数据集（Dataset）当成一回事，实际上两者的定位不同。

数据集是一堆图片加标注，你可以拿来训练，也可以拿来测试。基准则是一套“标准化考核方案”，它包含数据、评测脚本、指标定义、提交规范，有时候还有排行榜。同一个数据集，如果评测脚本不同，算出来的分数就没有可比性。

BanglaWild 的标题里明确写了 Benchmark，说明它的核心交付物不仅是图片数据，还包括“怎么测”这套规则。这对小语种 OCR 来说尤为重要。没有统一基准之前，每个团队用自己收集的数据做评估，报告里的准确率很难横向比较。有了 BanglaWild，至少在同一套数据、同一套脚本下，不同模型的分数差异是可信的。

如果这个基准还配套了排行榜，那使用时要注意榜单的提交规则：是否允许使用额外训练数据、是否限制模型参数量、是否固定输入分辨率。这些规则直接决定了你看到的榜单排名是否真的代表模型能力，还是代表谁更擅长刷榜。

2. In-the-Wild 基准的构建逻辑：数据怎么来、标注怎么定、指标怎么算

2.1 数据采集：真实采集和合成数据是两条路线

一个场景文字基准的数据来源，通常有两条路线：真实采集和合成生成。

真实采集指的是在街头、市场、商场、公共交通、店铺招牌等场所拍摄照片，再对照片里的文字区域进行裁剪和转写。这条路线的优势是数据分布更接近实际使用场景，缺点是采集成本高、标注难、隐私和版权问题需要处理。

合成生成指的是先收集文字内容，再用渲染引擎把文字叠加到背景图片或 3D 场景中，生成带文字的图片。这条路线的优势是数据量可以做得很大，标注自带，缺点是合成数据和真实拍摄之间的领域差距在多数情况下无法完全消除，在合成数据上训练得很好的模型，到真实场景可能掉点。

BanglaWild 名字里的 In-the-Wild 表明它更偏向真实场景图片路线。对评测基准来说，真实图片的重要性在于能用“真实世界的复杂性”作为一道统一考题。如果所有测试图片都是合成图，那么高质量的合成模型就占便宜，而真实场景里的模糊、遮挡、复杂背景、意外光照就没有被充分测到。

2.2 标注质量：转写、语言标签和边界框

评测基准的标注工作通常分几层。

首先是文字区域定位。对检测模型来说，需要给每个文本框标注边界框或多边形。孟加拉语文字经常出现相邻字符或相邻单词间隙不明显的情况，多边形标注的精细程度直接影响检测评测的可靠性。

其次是文字转写。对识别模型来说，需要给每个文字区域提供准确的 Unicode 文本。这里有个很容易踩的坑：孟加拉语有多种输入方式和视觉编码，同一个词可能因为编码规范化方式不同而看起来一样、实际字节不同。如果基准没有做 Unicode 规范化，或者评测脚本没有统一规范化，模型的输出字符串可能被判定为错误，实际上只是编码形式不同。

然后是语言标签。场景图中经常出现孟加拉语和英语混排的情况，也可能出现少量其他语言。如果基准要给每个文字区域标注语言标签，评测时就可以选择只看孟加拉语部分，也可以选择测多语言混合识别能力。

对使用基准的人来说，需要先读清楚它的标注层级和标注格式。这决定了你评测时输入给模型的是什么：是直接给裁剪好的文字图片，还是给完整场景图让模型先检测再识别。

2.3 评测指标：整词正确率、编辑距离和字符级准确率

场景文字识别常用的评测指标，网上能搜到很多解释，但实际使用时要注意口径。

最常用的是 Word Accuracy，也就是整词正确率。模型输出的一句话或一个词，和标注完全一致才算对，有一个字符不同就算错。这个指标很直观，但对小语种场景文字来说可能过于严格：一个词因为元音附标识别错误，整词就算错，模型实力差异被放大。

另一种常见指标是编辑距离或归一化编辑距离（NED），它计算模型输出和真实标注之间需要多少次插入、删除、替换才能变成一致。这个指标对“部分错误”更友好，能反映模型在字符层面的接近程度。

还有字符级准确率，适合分析模型在字符级别上的系统性问题。比如所有带某个附标的字符都容易出错，看字符级指标会发现这个规律，看整词正确率只能看到“好多词错了”。

使用 BanglaWild 这类基准时，建议先明确两个问题：官方评测脚本用的是什么指标；如果只有一个总分，是否拆分成了检测、识别、端到端三个环节分别报分。如果只有一个端到端结果，模型在检测阶段漏框、错框造成的损失会被算进整体分数里，单看总分很难定位问题在检测还是识别。

下表是几个常见指标和适用场景的对比：

指标	计算方式	适合看什么	注意点
整词正确率	输出和标注完全一致才得分	端到端可用性	对单个附标错误极其敏感
编辑距离	输出转成标注需要的最少编辑次数	模型字符层面的接近程度	需要归一化，否则长文本吃亏
字符级准确率	逐字符判断是否正确	定位形近字、附标问题的系统性规律	忽略词序和语义上下文
端到端分数	检测+识别全流程的分数	真实场景落地能力	检测和识别问题混在一起，需要拆解

2.4 评测脚本里容易被忽视的规范化细节

评测脚本是基准的“裁判”，裁判的判罚标准必须统一。这里最难处理的就是文本规范化。

孟加拉语的 Unicode 字符可以有不同的组合方式。一个词可能在码点序列上完全不同，但渲染出来视觉上一致。如果评测脚本没有先做规范化，模型输出了一个视觉上正确但码点不同的文本，就会被判为错误。

常见规范化步骤包括：

1. 统一 Unicode 规范化形式，使用 NFC 或 NFD 中的一种。
2. 移除或统一空白符，比如把全角空格、制表符、连续空格都转成标准空格。
3. 处理标点符号，比如孟加拉语的句号、逗号在场景图中经常被漏掉或多余添加。
4. 决定是否忽略大小写。对孟加拉语来说，大小写不像英文那么关键，但如果有英文混排，就需要单独处理。

拿到基准后，我建议先花 10 分钟检查评测脚本的规范化逻辑。很多模型分数偏低，不是模型不行，而是输出文本和标注文本在规范化上没对齐。

3. 用这套基准评测 OCR 模型：从环境准备到结果解读

3.1 评测前要确认的三件事

实际跑评测之前，建议先做三件事，而不是直接下载数据就跑模型。

第一，确认基准的提供方式。有的基准会把裁剪好的文字图片直接给出来，方便只做识别模型的人使用；有的基准只给完整场景图和标注文件，需要你自己跑检测器把文字区域裁出来。这两种方式对模型的要求完全不同，评测结果不能直接放在一起比。In-the-Wild 基准通常会更偏向端到端评测，因为真实场景里“定位文字”本身就是难点。

第二，确认评测脚本和代码。好的基准一般会附带官方评测脚本。要检查脚本内部的规范化流程：是否做了 Unicode 规范化、是否忽略大小写、是否过滤空白符和标点。如果脚本对这些细节处理不当，你的模型可能因为一个空格或一个码点差异被误判。

第三，确认模型输入分辨率。场景文字识别的输入图片尺寸，不同模型差异很大。同一个模型，把输入分辨率从较低的值调整到较高的值，在曲线文字和长文字上的表现可能差别明显。评测时如果不统一输入分辨率，结果很难公平。建议先看基准是否规定了推荐分辨率，如果没有，就在评估报告里明确写出测试时的输入尺寸。

3.2 单条样例验证：不要一开始就全量跑

我第一次跑一个新基准时，习惯是先拿少量样本做冒烟测试，而不是直接全量跑。

具体流程是：

1. 下载一张样例图片和对应的标注，确认图片能正常打开，标注能正常读取。
2. 用现有的 OCR 模型跑一遍这张图片，确认输出结果的结构和标注格式对得上。
3. 对比模型的输出和标注，看差异发生在字符层面还是词层面。
4. 确认评测脚本能接收模型的输出格式并进行指标计算。

这个流程看着简单，但能避免最常见的几类问题：数据集路径不对、标注文件编码不对、模型输出和评测脚本期望的格式不匹配、评测脚本里的规范化流程和你的预期不同。

等单条样例跑通，再扩大到一个小批次，比如 50 张或 100 张，观察批量处理的速度和稳定性。这里要特别留意输出日志：遇到空白输出、超长输出、乱码输出时，先排查输入图片是否损坏、模型是否对某些特殊字符产生了不合理输出，而不是急着调参数。

3.3 结果解读：分数高不代表可以上线

评测分数出来后，别急着下结论。同一个分数，在不同使用场景下的含义完全不同。

如果你的目标是学术对比，那么分数高说明模型在这个基准上表现好，可以作为论文里的对比数据。但如果你的目标是落地一个孟加拉语街景翻译或单据识别系统，单看榜单分数远远不够。还需要看模型在低分辨率图片、夜晚拍摄图片、有遮挡图片上的表现是否均衡。

我一般会把测试集按图片质量分成几个子集：清晰文字、中等模糊、严重模糊、遮挡、弯曲文字、竖排文字等。分别统计模型在每个子集上的表现。这样能看出模型的瓶颈在哪里：是字符建模不够好，还是图像预处理模块对模糊文字没什么效果；是检测阶段漏框，还是识别阶段对合字和附标频频出错。

另一个容易被忽略的问题是输出一致性。同一个模型，同一张图片，在多次推理时是否输出相同结果。如果不一致，可能是模型推理时开启了随机采样，也可能是有 batch normalization 在推理阶段的统计量不稳定。对生产环境来说，输出一致性往往比单张最高准确率更重要。

3.4 批量评测时要注意任务队列和输出命名

如果你要评测的数据量大，比如几千张图片，批处理方式就不只是“写个 for 循环跑一遍”这么简单。

先考虑任务队列。OCR 模型跑一张图可能只花几十毫秒，但跑几千张图，如果中间碰到一张损坏的图片或一个异常输入，整个循环可能中断。更稳妥的做法是：每处理一张图，就把结果写入一个独立的输出文件或日志行；如果中途失败，可以从断点继续跑，不需要从头再来。

再考虑输出命名。评测结果必须能对应到具体的输入图片。如果只是按顺序把结果写进一个列表，中途有一张图处理失败或者被跳过，后面的结果就会错位。我习惯用图片文件名作为输出标识，每一行记录“图片路径、标注文本、模型输出、时间戳”，这样后续排查时可以直接定位到具体样例。

最后考虑资源占用。如果你的模型是在 GPU 上跑的，批量评测时要监控显存和 GPU 利用率。不要一上来就开最大批大小，不然遇到长文本或高分辨率图片，显存可能直接溢出。先用小批量试跑，确认显存占用稳定，再逐步调大批大小。

注意：批量任务不是“能跑就行”，要看失败重试、输出命名和断点续跑。这三个点没做好，跑完几千张图后可能根本不知道该信哪个结果。

4. 视觉语言模型（VLM）评测：提示词、解码参数和对比口径

4.1 VLM 和专用 OCR 模型不是同一类东西

BanglaWild 这个基准的标题里专门提到了 Vision-Language Models，这说明它不只是为传统的检测+识别 OCR 管线准备的，也面向 Qwen-VL、InternVL、GPT-4V 这类视觉语言模型。

专用 OCR 模型通常接受裁剪后的文字图像，输出一串文本，任务定义非常明确。VLM 则不同，它接受整张图片或裁剪图，配合一个自然语言提示词，输出模型根据图像内容生成的回答。VLM 的识别能力不是单独训练的，而是和视觉理解、语义推理、指令跟随能力耦合在一起的。

这就带来一个关键差异：VLM 的“识别错误”可能是真的不认识字符，也可能是视觉特征提取时遗漏了文字细节，还可能是模型理解了内容但生成时把孟加拉语转写错了。用同一个基准评测两类模型时，分数差距背后的原因需要分开解读。

4.2 提示词对 VLM 评测结果的影响很大

用 VLM 做场景文字识别评测时，提示词的设计非常关键，而且常常被低估。

同一个基准图片，如果你用不同的提示词，比如“请识别图片中的文字并只输出文字”和“描述这张图片中招牌上的文字”，得到的输出格式和准确率可能完全不同。VLM 会倾向于按照提示词的引导来决定输出长度和内容组织方式。如果提示词没有明确要求“只输出孟加拉语原文”，模型可能会把英文翻译、上下文解释、格式说明都混进来，导致评测脚本无法对齐。

更麻烦的是，不同 VLM 对相同提示词的响应方式差异很大。有的模型天然倾向简短输出，有的模型会输出很长的解释性文字。评测时如果都用同一套提示词，可能对某个模型更有利，对另一个模型更不利。为了让结果更公平，通常需要在提示词层面做一些针对性设计，或者明确记录每个模型使用的提示词版本。

对使用者来说，我的建议是把提示词当作评测配置的一部分，单独记录下来。基准数据、模型版本、提示词、输入分辨率、解码参数，这五项应该是一个完整的评测单元，缺任何一项，结果都很难复现。

4.3 VLM 评测要注意解码参数

除了提示词，VLM 的解码参数也直接影响结果。很多 OCR 基准评测默认使用贪婪解码，这样输出是确定性的。如果为了提升效果开启了采样，比如 temperature 调到 0.7，同一张图每次输出可能都不一样，评测可重复性就下降了。

在记录评测结果时，我会先记录解码参数，再记录输出。如果希望结果稳定可复现，temperature 设为 0 或使用贪婪解码最保险；如果希望看到模型在多种可能输出中的表现，可以设置 temperature 大于 0，多跑几次取平均值或记录方差。

另一个容易出问题的地方是 max_new_tokens。场景文字识别时，如果模型需要在一条图片里识别多个文本区域，输出文本会比较长。如果生成长度限制设置得太小，输出会被截断，评测时就会看到一整段后半部分丢失。这类问题看起来像识别错误，实际上是生成长度限制导致的。

4.4 VLM 的评测结果怎么和专用 OCR 模型对比

把 VLM 分数和专用 OCR 模型分数放在一起比较时，要小心“不可比”陷阱。专用 OCR 模型通常吃的是裁剪后的文字图，输出纯文本；VLM 如果也吃裁剪图，那么两者在输入上接近，可以对比。但 VLM 如果吃完整场景图，并且要同时完成定位和识别，那它本质上是在做端到端任务，和“只做识别”的专用模型不在一个评测粒度上。

更稳妥的做法是分两条线比较：

• 如果只比识别：把所有文字区域裁好，分别输入专用 OCR 模型和 VLM，统一要求输出文本，然后按同一套指标计算。
• 如果比端到端：两边都输入完整场景图，看谁能更准确地定位并识别文字区域。

BanglaWild 这类基准如果同时支持两种评测模式，那是最理想的。但单从标题看，它更强调 In-the-Wild 场景下的端到端能力，所以评测时把“检测+识别”整体衡量，是更贴合基准设计初衷的方式。

5. 从基准到实际工程：最容易踩的坑

5.1 基准分数不错，真机上却翻车

这类问题在很多 OCR 项目里都会遇到。基准测试集不管多“in the wild”，它仍然是一批经过筛选的图片。你手里要处理的真实图片可能有基准里没有的极端情况：柜台台灯直射图片、塑料袋反光、手写字体夹杂打印字体、镜头严重畸变、文字被商品价签部分遮挡。

所以我对基准分数的态度一直是：它能帮你横向比较模型，不能代替你对自己的数据进行抽样测试。拿一个基准做模型选型可以，但上线前必须拿自己业务里的真实图片做验证，而且最好做成一个持续更新的私有测试集，覆盖业务中的高频场景和异常场景。

5.2 Unicode 规范化问题最容易导致误判

处理孟加拉语文本时，Unicode 规范化是我最常提醒的一个点。孟加拉语字符有很多组合情况，同一个词可能通过不同码点序列表示，但渲染出来是一样的。如果模型输出和标注在码点序列上不完全一致，评测脚本又没有做规范化，就会被误判为错误。

要解决这个问题，评测前先对两个文本做统一规范化处理。常用做法是使用 Unicode 标准里的 NFC 或 NFD 形式，具体选择哪种跟基准和标注格式有关。这个步骤看起来不起眼，但经常能解释“为什么模型输出明明看着是对的，评测分数却很低”。

5.3 检测和识别的错误要分开统计

很多 OCR 系统是“检测器加识别器”两段式架构。端到端评测时，检测器漏框、错框会把错误强加给识别器，导致最终分数很低，但实际情况是识别器本身可能没问题。

遇到分数异常时，我的排查顺序是：

1. 先检查检测结果：把检测器输出的框画到原图上，人工看有没有漏框、框偏移、一个文字区域被切成几块。
2. 再检查识别结果：把裁剪区域单独拿出来，用识别器单独跑，看文字内容是否正确。
3. 如果检测和识别单独都正常，但端到端结果不好，问题大概率出现在两个模块之间的接口，比如裁剪区域的坐标偏移、分辨率调整、图像预处理不一致。

这个排查链路既适用于基准评测，也适用于真实业务的日志分析。很多看起来是模型能力不足的问题，实际上是个别模块之间协作出错了。

5.4 低资源环境下的评测和推理

有读者可能会问：孟加拉语这种小语种场景文字，资源是不是很难搞，低配置机器能跑吗？

这里要看具体使用的模型。如果只是跑传统 OCR 管线，比如 Tesseract 加语言包，或者轻量级检测识别模型，普通 CPU 机器也能跑评测，只是速度慢一些。但如果要评测 VLM，特别是参数量很大的 VLM，显存和内存就是硬门槛。评测时可以把输入分辨率调小、把批大小调低、把生成长度限制缩短，但要注意这些改动会影响最终分数，不能和默认配置的结果直接对比。

低配置机器能做的是先跑通流程，用小样本验证评测脚本、数据格式和输出结构，然后再在有 GPU 的机器上跑全量测试。这样既不会因为一个脚本 bug 浪费大量 GPU 时间，也能提前暴露数据读取和路径配置问题。

6. BanglaWild 的扩展用法：模型选型、数据增强、多语言迁移

6.1 用基准做模型选型时，要建立对比基线

如果你要做孟加拉语场景文字识别，最省事的做法不是先找模型，而是先用基准建立一组对比基线。

我会这么操作：

1. 先跑一个通用 OCR 模型，比如没有针对孟加拉语优化的开源模型，记录分数。
2. 再跑一个专门针对孟加拉语或印地语等相似文字优化的 OCR 模型，记录分数。
3. 如果环境允许，再跑一个 VLM，记录分数。
4. 把几个结果放到一张表里，分别记录识别准确率、检测准确率和端到端准确率。

这几组基线能帮你判断：当前模型的问题主要在哪一层；是否需要训练专门的孟加拉语识别头；是否需要引入视觉语言模型做后处理纠错。

如果通用模型和专用模型之间的分数差距很大，说明语言的字符建模很关键，单纯靠数据增强很难弥补。如果差距不大，说明通用模型的特征提取能力已经能够覆盖孟加拉语的大部分字形，后续优化重点可以放在数据多样性和长尾场景上。

6.2 数据增强：从基准数据延伸出训练集

基准数据本身通常不建议直接拿来当训练数据，因为它的标注格式和用途面向评测，且样本量有限。但它可以作为数据增强的参考样本。

常见的做法有三种：

• 用基准图片的变换版本作为额外的验证集，比如旋转、加噪声、亮度变化，测试模型在变换后的稳定性。
• 用合成数据渲染引擎生成更多孟加拉语场景文字，按照基准图片的风格和干扰类型去设计渲染参数。
• 用基准图片做标注风格的校准，比如确保你自己的训练数据标注和基准的 Unicode 规范化规则一致。

第二种做法需要投入更多工程时间，但它对最终效果的提升通常比调参更明显。场景文字识别模型对训练数据的多样性和真实程度非常敏感，单靠模型架构层面的改进很难覆盖真实世界的无穷变化。

6.3 多语言迁移：孟加拉语的经验可以迁移到哪些语言

孟加拉语属于印度-雅利安语支，和印地语、旁遮普语在文字形态上有相似之处，很多字符和合字原则相近。如果已经针对孟加拉语做了字符集扩展、合字处理和附标建模，迁移到其他使用婆罗米系文字的语言时，可以复用大量经验。

不过，迁移时要注意几个边界：

• 字符集不同。不同语言的字符范围和常用合字不完全一样，直接迁移训练好的字符集分类器会遗漏目标语言的字符。
• 语言模型上下文不同。场景文字识别的序列建模会把字符组合成词，不同语言的词法结构差异会影响语言模型部分的效果。
• 数据集分布不同。BanglaWild 采集的孟加拉语场景图片，其文字内容分布、常见词汇、街景风格，不一定代表其他语言的真实分布。

所以更稳妥的迁移方式是把 BanglaWild 作为一个出发点，理解它在标注流程、评测脚本、Unicode 规范化处理上的设计，然后把这些工程经验复制到新语言基准的构建中，而不是把一个训练好的孟加拉语模型直接部署到所有南亚语言上。

6.4 可以自己建立的评测维度

如果你打算在 BanglaWild 基础上做自己的实验，建议额外建立几个评测维度，帮助定位问题：

• 模糊子集：将图片按清晰度分组，观察模糊对识别率的影响。
• 遮挡子集：将文字被部分遮挡的图片单独统计，观察尾部字符或首部字符的错误率。
• 长文本子集：一个图里包含多个词或一个长句的样例，观察输出截断和词边界错误。
• 混合语言子集：孟加拉语和英文混排的样例，观察模型是否会串语言。
• 低对比度子集：浅色背景上的深色字、深色背景上的浅色字等，观察颜色对比度对识别的影响。

这些子集不用很大，每个几百张就能提供足够的信号。关键是让评测结果从“一个总分”变成“多个可分析维度”，这样后续优化才有的放矢。

7. 评测项目的工程化管理：目录、日志和复现

7.1 评测项目建议用独立目录管理

不管你是个人研究者还是团队工程，建议把评测这件事当作一个独立项目来管理，目录结构至少包含：

• data：原始数据和标注。
• models：模型权重和配置文件。
• scripts：评测脚本、预处理脚本、结果解析脚本。
• results：每次评测的输出，按日期和模型命名。

这样做的原因很简单：评测结果要能复现，就必须把环境、代码、模型和数据固定下来。如果所有文件都散落在临时目录里，几个月后你自己也说不清当时用的是哪个版本。

7.2 评测日志里必须记录的信息

每次跑完评测，我会在日志或 Markdown 文件里记录以下信息：

• 基准名称和版本，比如 BanglaWild 的某个版本号。
• 模型名称和权重文件路径。
• 输入分辨率和预处理方式。
• 评测范围：检测、识别还是端到端。
• 解码参数：temperature、top_p、max_new_tokens。
• 评测指标：整词准确率、编辑距离、字符准确率等。
• 运行环境：操作系统、Python 版本、GPU 型号、依赖库版本。

这个列表看着繁琐，但当你需要复现一个结果、排查一个奇怪分数时，它是最省时间的资产。很多“结果对不上”的争论，最后都会落到“当时输入分辨率不同”或“评测脚本版本不同”上。

7.3 遇到低分时的冷静处理

最后说一句实操经验。跑基准遇到低分，先冷静追踪问题，不要急着换模型。

第一步，确认输入和标注没问题。拿一张图出来，人工读一遍标注，再看模型输出，判断是标注错误、图片损坏、还是模型真的认错。

第二步，确认评测脚本没问题。单独拿一个简单样例跑一遍，看看得分是否符合作业。如果模型对一个明显正确的输出被判错，优先检查规范化、空白符、标点过滤等细节。

第三步，确认问题在检测还是识别。把两段式系统的中间结果画出来看，判断错误来源。

第四步，再改参数或选模型。很多问题在改参数之前就出在数据准备和接口处理上，直接换模型反而会绕开真正的坑。

7.4 什么时候该看基准，什么时候该看业务数据

最后把基准和业务数据的关系再捋一遍。

模型选型、论文对比、开箱验证，用 BanglaWild 这类公开基准很合适。它提供了一套固定口径，能让不同模型站在同一条起跑线上。

上线部署、效果优化、回归测试，一定要用业务数据做补充验证。业务数据里才有你真正要处理的极端情况：特定的拍摄角度、特定的采光条件、特定的字体和版式。

正确的做法是两条线并行：公开基准用来做横向对比和趋势判断，私有业务测试集用来做垂直验收和回归保障。两者缺一不可。

如果你只是学习场景文字识别，拿 BanglaWild 跑通一遍评测流程，已经能对“检测、识别、端到端、指标、规范化”这些概念建立整体认识。如果你要长期做孟加拉语或类似小语种的 OCR 系统，那就把基准、日志、私有测试集一起纳入日常开发流程，后面会省下大量排查时间。踩过几次之后我发现，很多问题不是工具能力不够，而是前置环境和文本处理没有对齐。