识字还是猜词？乌尔都语字体双生基准揭示多模态模型OCR真相

一场字体对照实验，撕开多模态OCR的"真实力"

当多模态模型"读"出一段乌尔都语文本时，它究竟是在识别字形，还是在用语言先验"猜"出合理答案？这个长期困扰OCR评估的问题，被一位开发者在Kaggle Benchmarking Challenge中用一个精巧的对照实验推到了台前。

据该项目在dev.to发布的原始报告，研究者构建了一个"乌尔都语字体双生基准"（Urdu Font-Twin Benchmark）：将同一段NFC归一化、SHA-256完全一致的乌尔都语Unicode字符串，分别用Nastaliq（波斯体，对角线布局、字形密集、上下文依赖强）和Naskh（纳斯基体，更线性）两种字体渲染。如果模型真的在读字形，换字体不应显著改变转录结果；如果只是在用语言先验填补视觉空白，那么当文本失去可预测性时，字体差异就会被放大。

**Nastaliq（波斯体）与Naskh（纳斯基体）**是阿拉伯字母系统的两大书法/排版风格，二者在乌尔都语中均有使用但视觉结构差异显著。Nastaliq 起源于波斯，是乌尔都语最主流的书写体，其特点是字形沿对角线向下延伸、单词内字符高度依赖上下文变形、水平基线不稳定，且连字（ligature）与堆叠结构极其复杂——一个单词常表现为一条倾斜的视觉流而非离散字符列。Naskh 则更线性、字间距清晰、字符形态相对独立，是阿拉伯语排版与多数数字字体的默认风格。对 OCR 而言，这种差异意味着：Nastaliq 中单个字形的视觉边界模糊，模型更难以逐字切分与识别；而 Naskh 的字形分离度高，逐字识别更可靠。正因如此，同一字符串在两种字体下的视觉可辨识度天差地别，这为区分"读字形"与"猜词"提供了天然对照组。

NFC 归一化（Unicode Normalization Form C，即标准合成形式）是 Unicode 标准定义的四种归一化形式之一，其作用是将等价的字符序列统一为规范形式。例如某些字符既可以由"基字符+组合附标"表示，也可以由预先组合的单码点表示，NFC 会优先选择后者（合成形式）。在文本基准中做 NFC 归一化，是为了确保比较的不是因编码方式不同而产生的表面差异，而是真正的字形识别差异。文中强调"NFC 归一化、SHA-256 完全一致的 Unicode 字符串"，意味着两种字体渲染的底层字符数据是逐字节相同的——任何输出差异只能来自视觉渲染，而不能来自文本输入本身的编码差异。

CER（Character Error Rate，字符错误率）是 OCR 与语音识别中最常用的准确率指标之一，计算方式为：将模型输出与参考答案对齐后，统计替换（S）、删除（D）、插入（I）三类错误的总字符数，再除以参考答案的总字符数，即 CER = (S + D + I) / N。CER 越低表示转录越准确，为 0 表示完全正确。本文使用"配对的 Nastaliq CER 减去 Naskh CER"作为主指标，这种配对差值设计消除了文本难度、模型总体能力等混杂因素，直接测量"仅因字体不同"带来的性能变化。类似地，WER（Word Error Rate）以词为单位计算同类型错误率，文中"伪词 WER"指在伪文本条件下模型输出与参考的逐词错误率。

Bootstrap 置信区间是一种非参数统计方法：通过对样本进行有放回重复抽样（如 1000 次），计算每次抽样的统计量，从而得到该统计量的经验分布与置信区间。在样本量较小（本文试点仅 90 张图像、45 个配对）时，bootstrap 区间能比传统正态近似更稳健地反映估计的不确定性。文中"95% bootstrap 区间 [4.05, 12.82]"表示：若重复抽样，该 CER 差距有 95% 的概率落在 4.05 到 12.82 个百分点之间，且区间不包含零，说明该差距在统计上显著。对于 Claude Sonnet 5 的 -12.5（区间 [-33.5, 10.2]），区间包含零则意味着方向相反但统计上不显著。

实验设计：三种语言条件 × 两种字体

基准包含三个语言条件，层层剥离语言可预测性：

• 自然文本：锁定修订版本的乌尔都语维基百科句子
• 打乱文本：相同词汇按确定性随机顺序排列
• 伪文本：保留空格、标点与token长度的确定性"乌尔都语式"字符序列，但移除普通词汇的可预测性

每个条目渲染两次（Nastaliq与Naskh各一次），配对的图像共享相同源文本。试点集为15个源条目 × 3种条件 × 2种字体 = 90张图像，即45个精确文本字体配对。

渲染本身就是实验的一部分

研究者的一个关键洞见是：如果一种字体静默回退、字形裁剪或渲染尺寸不同，整个基准就失去意义。因此调用模型前，他们用HarfBuzz显式设置rtl、Arab、ur属性整形字符串，再用FreeType直接栅格化字形ID以防止系统字体回退，并验证字符覆盖、GSUB/GPOS表、连字、RTL簇顺序等。离线验证通过全部90张图像和45个配对，无缺失码点、回退或空白渲染。

评分主指标为配对的Nastaliq CER减去Naskh CER。正值意味着同一源字符串在Nastaliq上产生了更多字符错误。评估使用Unicode NFC与空白归一化，且不合并U+06CC/U+064A等易混淆的乌尔都语与阿拉伯语字母。

HarfBuzz 是一个开源的文本整形（text shaping）引擎，被广泛应用于 Linux、Android、Chrome 等系统中。它的核心职责是将 Unicode 字符串转换为带有精确字形 ID 和位置信息的序列，过程中会处理：脚本识别、双向文本（RTL/LTR）排序、上下文相关的字形替换（通过 GSUB 表）、字形定位（通过 GPOS 表，如连字、字距调整）等。文中设置 rtl、Arab、ur 属性，即显式告知 HarfBuzz 这段文本是阿拉伯字母系统、乌尔都语、从右到左书写，避免自动检测出错导致整形错误。FreeType 则是负责将字形轮廓栅格化为位图的字体渲染库；"直接用 FreeType 栅格化字形 ID"意味着绕过操作系统的字体回退机制（font fallback），确保渲染用的就是指定字体，而不会因系统缺少某字形而静默替换成其他字体。GSUB/GPOS 表是 OpenType 字体文件中的两类核心表：GSUB 负责字形替换（如连字、上下文变体），GPOS 负责字形定位（如字距、标记附着）。在 Nastaliq 中，这些表极为复杂，因为它们承载了上下文相关的字形变形逻辑。离线验证这些表，是为了确保字体渲染没有因表缺失或解析错误而产生错误的字形序列。

模型表现：一个比单一结论更有趣的多模型图景

研究者查询了Kaggle的46模型目录，但首轮扩展耗尽了每日AI配额，最终配对分析纳入完成全部90张图像提示的7个端点：Claude Haiku 4.5/5.5、Claude Sonnet 5/5.5、Gemini 3.5 Flash-Lite、Gemini 3.7 Flash、GPT-5.4 Mini。作者明确表示，这是一个已验证的试点与进行中的46模型评估，而非完成的通用排名。

Gemini 3.7 Flash是完成度最高的运行。其Nastaliq减Naskh的配对CER差距为：自然条件+0.18个百分点，打乱条件+0.25个百分点，而伪文本条件高达+8.75个百分点（95% bootstrap区间[4.05, 12.82]）。其伪词WER差距为+40.89个百分点——Nastaliq伪词输出引入了9个参考中不存在的自然词汇词，Naskh则没有。

多模型层面的伪文本CER差距呈现出显著分化：Claude Sonnet 5.5为+35.9，Claude Haiku 4.5为+21.8，Gemini 3.5 Flash-Lite为+12.9，GPT-5.4 Mini为+12.0，Gemini 3.7 Flash为+8.8，Claude Haiku 5.5为+4.9（区间含零），而Claude Sonnet 5为**-12.5**（区间[-33.5, 10.2]，方向相反）。7个图像完整模型中，5个的伪词区间排除零。

语言先验（language prior）在本文语境中指的是：多模态模型在训练中习得了大量自然语言的统计规律，当视觉输入模糊或难以辨认时，模型会倾向于输出"看起来合理"的词，而非忠实转录所见字形。例如看到一段乌尔都语文本的某处模糊，模型可能根据上下文猜测此处应为"کتاب"（书）而非其他字形相近但语义不通的词。语言先验在自然文本中帮助模型补全、提升可读性，但在伪文本条件下反而成为干扰——因为伪文本没有可预测的语义结构，模型若仍强行"猜词"，就会输出参考中不存在的自然词汇。文中"伪词输出引入了 9 个参考中不存在的自然词汇词"正是这一机制的直接证据：模型不是在读，而是在猜。Nastaliq 减 Naskh 的配对 CER 差距之所以在伪文本条件下被放大，是因为 Naskh 的字形更清晰、模型更容易忠实转录；而 Nastaliq 的视觉模糊迫使模型更多依赖语言先验，一旦先验失效（伪文本），错误便集中爆发。

意外发现：字体不只是"外观格式"

研究者坦言，预期伪词更难，但没料到字体之间的差距对某些模型会扩张得如此剧烈，而对另一些模型又保持微小或不稳定。这个结论指向一个更深的判断：字体不是表面的输入格式选择；对某些多模态系统而言，它直接改变了任务的性质。

几个Claude运行在自然或打乱文本上也显示出可观差距，这提醒研究者不应把所有字体效应都简化为"语言先验依赖"。此外，视觉"金丝雀"测试（一个大数字和一个短乌尔都语词）暴露出：出现在多模态目录中的模型名称并不保证端点能接受图像、分配足够的可见输出token或遵循精确转录指令。将端点故障与OCR错误分开报告，避免了把基础设施行为伪装成准确率分数。

下一步：分辨率分层与更大源集

后续运行计划完成重试资格的端点，增加0.5倍和0.25倍分辨率分层，并将源集从15项扩展到60项。研究者还希望加入Tesseract乌尔都语和公开的UrduOCR检查点，但前提是可执行模型工件及其复用许可可被验证。核心分析将保持配对：问题不仅是哪个模型CER更低，而是同一模型读取同一字符串时，仅改变乌尔都语字体是否会改变结果。

这项实验始于一个排版问题，最终却触及了更广阔的命题：当一个视觉语言模型给出正确的词，这个答案有多少来自"看见字母"，又有多少来自"知道那里该是什么词"？

完整任务、代码与可复现资源见Kaggle Benchmark（Reading or Guessing? Urdu Font Twins, version 9）与GitHub仓库syncaimain/urdu-font-twin-benchmark。仓库包含确定性渲染器、源清单、字体许可、金丝雀测试、指标实现、分析脚本、测试、contact sheet与机器可读状态账本。