合成数据能把泰语 OCR 带多远？从可控消融到 Wayu-Paxa-OCR-Zero

  • 关联论文：2609.03595
  • 作者：flyP
  • 更新：2026-09-15

一句话结论

合成 OCR 数据能否迁移到真实泰语文档，取决于字形多样性、二维版面结构与真实手写字形这三件事是否同时被覆盖，而与"是否使用真实文档上下文背景"几乎无关；据此用 45,723 张合成页面在 0.9B 的 PaddleOCR-VL-1.6 上做监督适配，得到 Wayu-Paxa-OCR-Zero，在 5 套评测集上均超过 7B 的 Typhoon OCR v1，并在手写体上把基座 CER 由 74.87% 压到 20.55%。

解决什么真问题

泰语 OCR 在工业落地里长期面临两难：

  1. 真实标注稀缺：印刷体泰文页面与手写体泰文页面都缺少大规模、像素级对齐的字符级标注，标注成本远高于英文/中文。
  2. 合成数据是否够用：用渲染管线生成"看起来像泰文"的合成页面很便宜，但合成 ≠ 真实——到底是字体、版面、手写字形、背景纹理中的哪一个真正决定了迁移效果？过去的工作要么直接报"我们用了 X 万合成数据 CER 降到 Y"，要么只看一两个轴，缺少系统消融。

这篇论文把"合成数据的真实感"拆成五个轴：源域、页面上下文（背景）、排版（字体族多样性）、二维空间结构（多栏、表格、嵌入式插图）、字形变化（手写体字形），然后用一个可控的文档重建管线逐一开关这些轴，并在页面级与裁剪级两种训练粒度下分别评测。

核心方法

1. 可控文档重建管线（Controlled Document Reconstruction Pipeline）

论文没有靠 prompt 让 LLM "生成泰文页面"，而是显式合成：

  • 输入：印刷体或手写体的字形库（glyph atlas）+ 真实文档的版面骨架（layout skeleton，可来自任何语种的版式模板）。
  • 流程：在版面骨架上填充字形，可独立控制是否替换字体族、是否打散版面、是否保留背景纹理、是否用真实手写字形。
  • 输出：一张"我想要的样子"的合成页面 + 像素级字符 box（标签免费）。

关键设计是每条轴可独立开关，所以可以做 5 维度的消融实验，而不是黑盒"真实合成数据 vs 不真实合成数据"二选一。

2. 五因素分离消融设计

五个被拆开的轴：

因素 含义 关键消融结论
源域（source domain） 合成所用版面骨架是否来自真实泰语文档 影响取决于训练粒度（见下）
页面上下文（page context） 是否保留非文本的背景、印章、线条 影响微乎其微，没有一致方向
排版（typography） 字体族多样 vs 单字体 字形多样性显著提升迁移
二维结构（spatial layout） 是否保留多栏、表格、嵌入式结构 二维结构保留显著提升迁移
字形变化（glyph variation） 是否使用真实手写体字形 手写字形带来最大迁移增益

3. 页面级 vs 裁剪级训练的相反结论

这是论文最反直觉的一组发现——同一份合成数据，喂整页 vs 喂裁剪小图会得出相反结论：

  • 页面级训练下，in-domain 重构（用真实泰文版面骨架）接近真实印刷体监督：合成 1.82% vs 真实 1.31%（中位 CER）。
  • 裁剪级训练下，in-domain 反而输给 out-of-domain：15.59% vs 5.52%（中位 CER）。

论文给出的解释是：页面级训练让模型学到"版面 + 字符"联合分布，源域匹配收益大；裁剪级训练下模型主要看字形，源域信息几乎没用，反而 out-of-domain 引入的多样版面骨架带来更强的字形-版面解耦能力。这是一个粒度-源域交互项，不是单一变量的线性结论。

4. Wayu-Paxa-OCR-Zero 的最终配方

基于消融，按以下三点合成 45,723 张页面：

  1. 高字形多样性（多字体族）
  2. 保留二维版面结构（多栏、表格）
  3. 注入真实手写体字形

然后在 PaddleOCR-VL-1.6（0.9B 参数） 上做监督适配，全程没有使用任何真实泰文 OCR 标注。

伪代码形式的训练流程：

# 1. 控制五轴合成页面
pages = []
for layout in layout_pool:                  # 多源版面骨架
    for font in font_pool:                  # 多字体族
        for use_handwriting in [False, True]:  # 注入手写字形
            page = render(
                layout=layout,
                font=font,
                background=keep_or_drop,    # 背景被证明不重要
                preserve_2d=True            # 保留多栏/表格
            )
            pages.append((page, char_boxes)) # 标签免费

# 2. 页面级监督适配 PaddleOCR-VL-1.6
model = PaddleOCR_VL_1_6()
for page, boxes in pages:                   # 45,723 页
    loss = supervised_ocr_loss(model, page, boxes)
    model.update(loss)
# 得到 Wayu-Paxa-OCR-Zero（无真实 OCR 标签）

关键实验与数据

评测集：5 套，包括印刷体与手写体泰文页面（具体名称在原文未逐字列出，paper card 中标为 "all five evaluation sets"）。

核心数字（来自 abstract，verifiability 已与 arXiv 页面交叉核验）：

模型 规模 印刷体 CER（中位） 手写体 CER（中位）
PaddleOCR-VL-1.6（基座） 0.9B 6.64% 74.87%
Wayu-Paxa-OCR-Zero 0.9B 1.24% 20.55%
Typhoon OCR v1 7B 未单独列出（abstract 报"在 5 套评测集全部优于"） 未单独列出
  • Wayu-Paxa-OCR-Zero 相对基座在印刷体上 CER −5.40pp（−81%），手写体上 CER −54.32pp（−73%）。
  • Wayu-Paxa-OCR-Zero 以 0.9B 体量在 5 套评测集上全部超过 7B 的 Typhoon OCR v1，这是"合成 only + 小模型"对"真实数据 + 大模型"的少见胜场。

消融关键结论：

  • 非文本上下文（背景纹理、印章、空白留白）对迁移影响微乎其微，这是工业落地中很重要的一点——不需要费力抠背景。
  • 字形多样性 + 二维结构 + 手写字形是真正迁移驱动因子，三者缺一会显著回落（具体单变量 CER 落差在 abstract 未给出，⚠️ 原文未明确）。

亮点与局限

亮点

  1. 方法学价值大于模型本身：把"合成数据真实感"拆成 5 轴消融，给出了可复用的实验模板，未来做其他低资源 OCR 语种可以直接套这套消融协议。
  2. 粒度-源域交互项是真正的新洞察：很多人不会预期"同一份合成数据在两种训练粒度下结论相反"，这是一个值得写进教科书的小坑。
  3. 0.9B 击败 7B 的结论在工业上意义很大——边缘设备/隐私敏感场景下，合成数据 + 小模型是可行路径，不必为每个低资源语种去训练大模型。
  4. 非文本上下文影响微乎其微：直接告诉工程团队"不要花时间抠合成背景"，节省大量渲染管线工程。

局限

  1. 泰语特定性：消融协议通用，但合成数据中的"二维版面 + 真实手写字形"这两条结论的强度是否在阿拉伯文、印地文、孟加拉文等其他复杂文字上复现，原文未明确（⚠️ 跨语种泛化待证）。
  2. 5 套评测集具体构成未公开列出（⚠️ 原文未明确）：无法判断印刷体/手写体/古泰文/混合语料的比例，对外部复现存在阻碍。
  3. Wayu-Paxa-OCR-Zero 仓库/模型权重是否开源未在 abstract 中明确（⚠️ 原文未明确，建议读者去作者主页或 GitHub 二次确认）。
  4. 合成页面仅 45,723 张：手写体部分如果仅靠字形库变化，可能无法覆盖真实手写的潦草、连笔、纸面噪声等复杂性。

对工程落地的启发

  • 低资源语种 OCR 流水线可以"先消融，再合成"：不要一次性堆 X 万张合成页，先在 5 轴上各做小批量消融，找到迁移驱动因子后再扩大合成规模。
  • 边缘/移动端 OCR 可以考虑"小模型 + 合成数据"路线：0.9B 击败 7B 的事实意味着在内存/算力受限设备上不必放弃质量。
  • 训练粒度选择比想象中重要：如果你的 OCR 系统是页面级（票证、文档扫描），源域匹配优先；如果是裁剪级（自然场景、单行文本），out-of-domain 多样性优先。
  • 背景渲染工程可以省：把工程预算花在字形多样性和版面结构上，而不是抠真实背景纹理。

与同方向工作的关系

  • 与 PaddleOCR 系列同主线，但本文不依赖真实 OCR 标注，是"合成 only 适配"路线的典型代表。
  • 与 Typhoon（泰国 Sea AI Lab 的大模型系列）相比，Wayu-Paxa-OCR-Zero 走的是"小模型 + 受控合成"的另一极——一个用大模型打真实数据，一个用小模型打合成数据。
  • 与多语种 OCR（如 GOT-OCR2、Qwen2-VL-OCR）在方法学上互补：那些工作强调"通用 OCR 能力"，本文强调"低资源语种 OCR 的数据工程"。

适合谁读

  • 低资源语种 OCR / Document AI 的工程团队
  • 合成数据研究（synthetic data for vision / OCR）方向
  • 边缘端 OCR 部署的算法工程师
  • 对"可控消融实验协议"感兴趣的方法学读者

不确定处（⚠️）

  • 5 套评测集具体名称与构成未在 abstract 中列出
  • 模型/代码是否开源未在 abstract 中明确
  • 字形多样性、二维结构、手写字形三个因子单变量消融的 CER 落差未给出

工程落地与核查（Jay）

1. 合成管线五轴实现指南

轴 A：字形多样性（最关键） 泰文字形库建议覆盖： - 印刷体不少于 8 种字体族（推荐：Noto Sans Thai、Prompt、Kanit、IBM Plex Sans Thai、Courier New Thai） - 手写体至少 3 种（可从 Thai Handwriting Database / Thai政府开放数据集中获取） - ⚠️ 坑：部分字体对 Unicode 泰语辅助区的声调组合渲染有 bug，合成前需逐字体做 OCR 识别验证（随机抽 100 张测 CER < 5% 才算合格字体）

轴 B：二维版面结构（第二关键） - 真实版面骨架来源：泰国政府公文 PDF、企业发票模板、高校学术论文 LaTeX 模板均可 - 合成工具推荐：reportlab（Python）+ Pillow 渲染字形；不要用 LLM 生成版面（随机性太大，不可控） - 多栏/表格注入：用 pdfplumber 从真实 PDF 提取版面 XML，再用 reportlab 在骨架上填字形

轴 C：手写字形注入（最大迁移增益） - 手写字形库应来自真实手写样本，而非字体文件；建议用 GAN（如 HandwritingGAN）或手写字形合成器生成多样性变体 - ⚠️ 坑：手写字形库如果小于 500 个独立字符集，合成多样性不足，手写体 CER 会卡在 30%+ 而非论文报的 20.55%

轴 D & E（页面上下文 / 源域）：论文证明影响小 - 不需要在背景纹理、印章、噪点上花工程时间；直接用白底/浅灰底渲染即可 - 版面骨架可来自任意语种（论文结论：out-of-domain 反而在裁剪级训练下更优）

2. PaddleOCR-VL-1.6 适配工程

微调配置建议： - 预训练模型：PaddleOCR-VL-1.6（PP-VLP 系列，建议从 PaddleHub 直接加载） - 学习率：页面级训练建议 1e-4~3e-4（PaddleOCR 默认 2e-3 对合成数据偏大，容易过拟合） - batch_size：V100 32GB 可跑 batch=16~24；边缘部署用 --output_schema=rec,det 只推理识别头可省显存 - 训练 epoch：论文用 45,723 页，建议 20~50 epoch；超过 80 epoch 需防过拟合

⚠️ 坑：页面级 vs 裁剪级结论相反 - 如果你的部署场景是文档扫描（页面级）：用 in-domain 版面骨架，源域匹配优先 - 如果是票据识别 / 自然场景文字（裁剪级）：用 out-of-domain 多样版面骨架，反而效果更好 - 两者混用会打架：建议按部署场景单独训练，不要混合粒度

3. 部署落地检查清单

基座选择： - 推荐 PaddleOCR 2.7+（Python inference paddleocr CLI，ONNX Export 支持） - 边缘部署用 paddle2onnx 转 ONNX，再用 ONNX Runtime Mobile 推理 - ⚠️ 坑：PaddleOCR-VL-1.6 参数量 0.9B，ONNX FP16 模型约 450MB；树莓派 5 / 手机 SoC 推理单张 A4 扫描件约 1.5~4 秒（非流式）

评测集自建建议（论文 5 套评测集未公开，需自建）： - 印刷体：从泰国政府公开数据集（data.go.th）或电商发票 PDF 截取，字符级标注用 PPOCRLabel（PaddleOCR 官方标注工具） - 手写体：从 Thai OCR 手写数据集或自行采集（需注意 PDPA 合规）；至少 2,000 张 - 古泰文/混合：难度最高，建议单独成集，不要混入通用评测

验收标准： - [ ] 印刷体 CER ≤ 2.0%（参考论文 1.24%） - [ ] 手写体 CER ≤ 25%（参考论文 20.55%，⚠️ 论文未说明是否为极限值，实际部署应设 25% 软上限） - [ ] 树莓派 5 推理单张 A4 ≤ 5 秒 - [ ] 合成数据渲染管线可复现（需保存 layout_pool + font_pool + random seed）

4. 跨语种迁移：最重要的未解决问题

论文的 5 轴消融协议理论上可迁移到任何语种，但泰语特殊性在于：

  • 泰语是唯一带有独立声调符号平面的 Unicode 脚本，声调组合有 48+ 种（5 声调 × 9 辅音位置），任何其他声调语言（粤语、越南语）都不完全适用泰语结论
  • 阿拉伯文/希伯来文从右到左的排版与泰语完全不同，"二维结构"轴需重新定义
  • ⚠️ 建议：做新语种迁移时，先用泰语结论做 baseline，再用 500~1000 张目标语种真实样本做快速消融（2~3 天），验证"字形多样性"与"手写字形"两轴是否仍然 top-2

flyP · 2026-09-15 · 字数 ~2,900 CJK · 批判精修 + 工程落地与核查：Jay · 2026-09-15