做OCR这些年，我有个越来越强烈的感受：真正让识别系统变强的，往往不是网络结构又改了多少层，而是训练数据本身能覆盖多少真实世界的噪声。尤其是在小语种场景里，这种感受会更明显。泰文是个典型例子，它不像英文、中文那样有海量公开数据集，想要规模化标注泰文图片，成本高到离谱，而且专业标注员本身就难找。所以很多团队会走一条更务实的路——合成数据。
但如果只是想当然地拿字体渲染几张图片就去训练，结果通常会非常难看。泰文的书写体系非常特殊，元音、声调符号在字符的上、下、左、右都能出现，组合起来之后还能发生变形和位移。这带来一个很本质的问题：合成数据必须足够了解泰文的文字规则，否则生成的数据再多，也只是在固定的模板里打转，模型根本学不到真实场景里的泛化能力。
我一直觉得，这类项目的核心命题不是“要不要用合成数据”，而是“合成数据能做到什么程度、边界在哪里”。这篇文章就基于我做泰文OCR的一点实践经验，聊聊合成数据在泰文识别里的价值、生成细节、训练技巧，以及那些容易踩进去的坑。
1. 泰文OCR的痛点：为什么非走合成数据这条路
1.1 泰文本身的语言学难点
泰文和拉丁字母系语言完全不是一回事。泰文是一种元音附标文字，基本辅音字母 + 上方元音 + 下方元音 + 声调符号可以叠成一个复杂的组合。比如“คำ”（这个词）看起来是三个字符，但实际上由辅音“ค”、上方元音“ำ”和尾音符号组合而成，字母形变和位置关系非常紧密。
更麻烦的是，泰文不像英文那样有明确的空格分词。英文单词之间有空格，OCR模型很容易学到一个词从哪里开始、到哪里结束。泰文整一句话可以连在一起写，中间偶尔出现的空格只是用来断句，而不是分词。这意味着模型必须理解音节边界和上下文，才能准确切分和识别。
还有一个关键点是泰文的字形高度依赖位置。同一个元音符号“ิ”（短音i），放在不同辅音上方时，它的位置会随着字母的高低、宽窄发生变化，甚至会有连写、变形的情况。这种非线性的排版方式，直接用标准OCR框架去搞，很容易出现一个字切得七零八落、另一个字又粘连在一起。
1.2 真实标注数据的成本困境
想做泰文OCR，最理想的情况当然是收集几百万张真实拍摄的街景招牌、文档扫描件、身份证复印件，然后找母语者逐字标注。但实际做下来会发现，这条路几乎走不通。
泰文标注员的稀缺性不用多说，而且泰文的标注难度本身就比拉丁语系高很多。标注员要懂得元音和声调符号的位置规则、要能区分同一字形在不同上下文里的变体、还要知道哪些字符组合属于同一个音节。一套流程下来，单张图片的成本往往是英文场景的好几倍，而且质量还很难保证。
我的实测经验是，标注质量高的泰文图，一千张的采购和清洗成本，足以让我用这个预算去渲染几百万张合成图。虽然合成图和真实图有差距，但量变往往会带来质变，尤其在模型参数量不大、任务相对聚焦的情况下，合成数据完全可以作为主力训练集来用。
1.3 合成数据的路径选择逻辑
既然真实数据太贵，合成数据自然就成了替代方案。但这里需要说明一点：合成数据的目的不是“替代”真实数据，而是把模型训练的前期阶段撑起来，让模型先学会基本的字形、常见的排版规律、基础的噪声鲁棒性。后续再用少量真实数据做微调，效果会好很多。
我通常把合成数据的使用分成三个层级：第一层，用字体渲染生成最基本的字符和音节组合，让模型建立对泰文字形的基础认知；第二层，叠加各种背景、模糊、透视、噪声，让模型适应拍摄环境的多样性；第三层，针对性地合成现实中常见的困难样本，比如模糊文字、弯曲表面、遮挡部分，让模型在极端条件下也不至于彻底摆烂。三层递进下来，合成数据的利用率会明显提升。
2. 高质量泰文合成数据的制作细节
2.1 字体资源与字符集选择
很多人做合成数据的第一步就翻车了，因为只找了一两款开源字体就开始渲染。泰文字符在不同字体下的差异比拉丁字母大得多。以“ก”这个字母为例，在有的字体里底部是一条直线，在另外的字体里会有明显的卷曲，模型看到一个变体就会懵。
我的建议是，字体数量至少要覆盖20款以上，尽量保持风格差异大。除了常见的系统字体，还需要加入一些手写风格的字体、带衬线的字体、广告风格字体。如果项目里要识别身份证、发票这类正式文档，还得专门找政府、银行常用的字体。这个信息通常可以从相关文档规范里查到，或者通过收集样本自行比对字体。
字符集上需要注意，泰文不是只有泰文部分，还有隐藏的梵文转写字符、古泰文符号以及常用的数字和标点。如果场景里有泰国地址、车牌等内容，数字的识别准确率同样重要。我一般会把字符集做成可配置项，按业务场景动态生成。
2.2 泰文的组合规则：不能随机拼字符
这是整个合成流程中最关键的一步。泰文不是把字符符拉到一行上就完事了，字符之间的上下叠放、左右拼接都必须遵循严格的规则。强行随机拼接，会出现一些泰文里根本不会出现的组合，模型学到这些错误规律后，真实场景里会疯狂误报。
泰文里一个完整的组合通常由基础辅音、元音、声调符号按固定顺序构成。书写时，前方元音（比如“เ”“แ”“โ”“ใ”“ไ”）会出现在辅音左边，但键盘输入顺序其实是辅音先输入、元音后输入。这种存储顺序和显示顺序的不一致，对渲染引擎提出了要求：如果直接把Unicode字符串画出来，引擎会按显示规则自动排版，这没问题；但如果合成逻辑里手动移动字符位置，就需要自己理清每个符号的相对坐标。
我实际做的时候，会根据Unicode的泰文组合规则建立一套合法组合表。比如“เ”只能和哪些辅音组合、“ิ”能放在哪些字母上方、声调符号跟哪些元音组合会出现位置冲突，全部预处理成字典，渲染时只在合法组合里抽。这样生成的样本，模型看到的才是“地道”的泰文，而不是一堆字符堆出来的四不像。
2.3 从“干净样本”到“真实感样本”的增广策略
字体渲染出来的图片是非常干净的，如果直接用，模型会严重过拟合于纯色背景、横平竖直的排列。要让合成数据起作用，关键词是“增广”。
我常用的增广策略分几类。几何增广包括透视变换、随机旋转、局部拉伸，幅度不能太大，否则文字本身都已经扭曲得不可读了。模拟拍摄环境的增广包括光照不均、边缘阴影、离焦模糊、运动模糊，这类增广对模型泛化能力帮助很大。噪声和纹理增广包括高斯噪声、椒盐噪声、随机线条、背景纹理叠加，可以模拟低分辨率摄像头和复杂背景的情况。
需要特别提醒的是，泰文的上下部符号对模糊非常敏感。“ิ”“ุ”这类小符号在模糊之后很容易被抹平，模型可能直接忽略它们。所以模糊增广的强度要适度，或者采用“局部模糊+整体清晰”的策略，保证模型既能学到模糊不变性，又不会丢失对上下符号的敏感度。
我一般用这样的思路做增广：先合成干净图，然后随机决定这一张要加哪些扰动，最后以8:2的比例混合“较干净样本”和“严重退化样本”。这比所有样本都统一加中等强度的扰动效果更好，因为模型会同时看到两个极端，更容易学出鲁棒的特征。
2.4 代码落地：一个可用的合成管线参考
这里给一个简化的合成管线思路，方便你理解整个流程是怎么跑的。
import random from PIL import Image, ImageDraw, ImageFont, ImageFilter import numpy as np # 合法组合表：preceding_vowel + consonant + above_vowel + below_vowel + tone valid_combos = load_thai_combo_table() def render_word(word, font_path, font_size, bg_color, text_color): font = ImageFont.truetype(font_path, font_size) img = Image.new("RGB", (512, 128), bg_color) draw = ImageDraw.Draw(img) draw.text((30, 30), word, font=font, fill=text_color) return img.crop(img.getbbox()) def augment(img): if random.random() < 0.7: img = img.transform( (img.width, img.height), Image.QUAD, quad_coords_from_perspective(img.width, img.height), Image.BICUBIC ) if random.random() < 0.5: img = img.filter(ImageFilter.GaussianBlur(radius=random.uniform(0.2, 1.2))) if random.random() < 0.3: bg = Image.fromarray(np.random.randint(120, 200, (img.height, img.width), dtype=np.uint8)) img = Image.blend(img.convert("L").convert("RGB"), bg, alpha=0.15) return img def generate_sample(): combo = random.choice(valid_combos) word = build_word_from_combo(combo) # 按显示顺序输出 font_path = random.choice(font_list) font_size = random.randint(28, 48) base_img = render_word(word, font_path, font_size, bg_color=random_pastel(), text_color=(30, 30, 30)) final_img = augment(base_img) return final_img, combo这个流程可以跑通，但真实工程会比这个复杂得多。比如背景颜色需要和字体颜色保持一定的对比度区间，太相近了模型学不到边；比如透视变换的坐标范围要控制好，避免文字扭曲到语义不可辨；比如生成出来的图片要做清洗，过滤掉极端模糊或者文字被截断的样本。这些细节直接决定训练出来的模型质量。
实际项目中，管线还需要加入“真实感”的环节。一种简单有效的做法是收集一批无标注的真实背景图，把渲染好的文字随机贴到背景上，再进行颜色调整、光影融合。这样能模拟出很多真实场景的纹理，让模型的泛化能力上一个台阶。
3. 从合成数据到可用的识别系统
3.1 模型的选型与输入处理
合成数据确定之后，模型的选型反而相对常规。泰文OCR最常用的方案是基于CNN+LSTM+CTC的序列识别结构，也就是经典CRNN路线，或者直接用基于Transformer的OCR模型。其实对大部分场景来说，模型复杂度的优先级远没有数据质量的优先级高。
我的经验是，先在中等规模的模型上做基线验证，比如ResNet18作为骨干的CRNN，输入高度设为64像素，宽度动态调整。泰文上下部符号太多，输入高度太低会把元音和声调符号直接压没；我试过32像素高度的效果，识别准确率会比64像素低明显一截，尤其对带上下标音符号的组合。所以泰文OCR的输入分辨率必须给足。
另外，泰文OCR的标签空间要额外注意。泰文Unicode的码位比较分散，一些组合字符在存储时是多字节的，训练前需要统一做标准化。如果不做标准化，同一个词的不同编码形式会被当成两个不同的标签，数据量直接打折扣。
3.2 训练与评估：合成数据能做多好
我自己跑过一组对比实验。纯合成数据训练出的模型，在合成测试集上的准确率可以达到95%以上，但拿到真实场景里测，一开始准确率只有60%-70%。这说明合成数据在“内部世界”里的表现容易产生幻觉，必须引入真实数据来校准。
引入大概几千张真实标注图做微调之后，模型在真实测试集上的准确率可以迅速提升到85%-90%。如果你的真实数据来自目标场景，比如专门收集街景门牌照片，那准确率还能进一步上涨。这个结果其实印证了一个观点：合成数据负责“广度”，真实数据负责“精度”，两者缺一不可。
当然，准确率不是唯一指标。泰文OCR还需要关注字符级别的错误率，尤其要区分哪些错误是“可接受的”（比如把某个字体变体识别成同一个字符）、“不可接受的”（比如漏掉声调符号导致语义完全改变）。我习惯在测试阶段单独计算元音、声调符号的召回率，因为这个指标直接关系到泰文单词是否能被正确“读”出来，比单纯看整词准确率更敏感。
3.3 合成数据的天花板：哪些问题它解决不了
合成数据确实强大，但它有先天的局限。最典型的，就是真实世界里的文字并不总是干净、平整、正对着镜头的。比如弯曲的饮料瓶身、带褶皱的塑料袋、反光的金属招牌，这类纹理和光照干扰，纯靠字体渲染几乎无法模拟。你可以在增广阶段加透视变换，但瓶身圆柱曲面带来的非线性畸变，不是简单透视能模拟出来的。
另一个问题是字体之外的手写体。合成数据可以轻松生成印刷体，但泰文手写体的变形非常自由，每个人写出来的“บ”都可以不一样，而且连笔现象严重。合成数据在这个领域只能做到“启蒙”，真正要识别手写体，最终还是要靠大规模的真人手写样本。
这并不意味着合成数据没有意义。正常项目里，合成数据可以覆盖80%的基础场景，剩下20%的极端场景用真实数据慢慢补。知道天花板在哪里，就能在水位以下把合成数据的价值榨到最干。
4. 常见问题与排查技巧实录
4.1 泰文OCR典型问题速查表
这里整理一份我自己在项目里反复用到的排查表，覆盖了从数据合成到模型训练的大部分问题。
| 问题 | 表现 | 可能原因 | 解决思路 |
|---|---|---|---|
| 元音符号频繁漏识别 | “คำ”识别成“ค” | 输入分辨率太低，上下部符号被压缩 | 提高输入高度，保持上下符号充足像素 |
| 模型把“เ”误判成“แ” | 前方元音混淆 | 合成数据里字体太少，字形变化不够 | 扩充字体库，尤其是带衬线风格字体 |
| 真实场景准确率低 | 印刷体准、拍摄体差 | 增广强度不够，模型没见过复杂背景 | 增加透视变换、光照不均、背景纹理模拟 |
| 字符粘连 | 一个词识别成一个乱码 | 泰文组合显示顺序与存储顺序冲突 | 预处理时根据Unicode规则重排合成顺序 |
| 模型训练不收敛 | loss高居不下 | 标签标准化没做，同词不同编码 | 统一用NFC/NFD规范做Unicode标准化 |
| 模型频繁输出不存在字符 | 标签空间出现非法组合 | 合成时随机拼字符，生成非法泰文组合 | 建立合法组合字典，只渲染合法组合 |
这个表看起来简单，但每一条背后都是我踩过的坑。尤其是第一条“输入分辨率太低”，很多人会忽略，因为英文OCR用32像素高度已经够了，泰文直接套用就会出问题。
4.2 合成阶段容易踩的坑
合成数据最常见的坑之一，是背景与字体的对比度失控。泰文字形相对复杂，笔画密集、上下部符号多，如果背景纹理太花、颜色与字体太接近，模型学到的特征会非常杂。我的经验是：先确保“清晰可读”是底线，再叠加干扰项。不能本末倒置，让模型一开始就在模糊不清的数据里学。
另一个容易被忽视的问题是样本失衡。泰文中有些字符使用频率极高，比如“ก”，有些则非常罕见。如果合成数据完全随机生成，高频字符会占掉大部分样本空间，模型对低频字符的识别能力会很弱。我的做法是按字符的现实中真实分布来设定采样概率，同时对低频字符做额外过采样。这样才能让每个字符都有足够多的曝光机会。
还有一个细节是渲染时的字体大小范围。字体大小选择太集中，模型对尺度的适应性就差，真实图片里文字大小一变就识别不出来。我一般会让字体大小在28到48像素之间随机分布，同时配合视图缩放，让模型在不同尺度下都能工作。这里需要解释一下，字体大小指的是渲染时文本的磅值，视图缩放是最后整图缩放时产生的像素尺寸差异，两者是不同层次的尺度变化，结合起来能更好模拟真实拍摄距离远近的问题。
4.3 数据质量验证的必要动作
合成数据制作完之后，不要直接拿去训练，先做一轮“质量抽检”非常有必要。我的习惯是，随机抽200张图，人工快速扫一遍，确认没有出现字体重叠、字符被裁切、背景和文字糊成一团等问题。虽然这个步骤看起来土，但它的效率异常高，能拦住90%的管线低级错误。
除了人工抽检，还可以做一个更系统的小实验：用这些合成数据训练一个轻量模型，然后在真实数据上测试，看哪些类别是稳定崩溃的。如果模型反复漏掉某个元音符号，那大概率是合成数据里这种符号出现的形态太少，或者位置关系没处理好。通过这种方式反推合成策略，比盲目加数据量有效率得多。
我还会监控合成数据中每个字符的覆盖频率，生成一份频率表，检查低频字符是否过少。遇到低频字符，直接手动大量补充。经过几轮这样的迭代之后，合成数据的质量会趋于稳定，训练出的模型在真实场景里才不会到处漏水。
5. 一点个人经验和体会
合成数据在泰文OCR里到底能走多远？我的答案取决于愿不愿意在细节上花时间。只是用现成OCR工具渲染一批泰文字符，那绝对走不远；但如果你研究泰文组合规则，精心设计增广策略，再搭配少量真实数据做微调，那合成数据完全可以撑起一套工程上够用的泰文识别系统。
在我自己的项目里，最后成型的那条数据管线，合成数据和真实数据的比例大概在10:1。合成数据提供海量字形变化和背景多样性，真实数据提供目标场景的“灵魂”。两者结合，模型在真实测试集上的字符准确率从纯合成时的74%提升到了接近92%，元音和声调符号的召回率也从62%涨到了88%。这个提升幅度说明，问“合成数据能走多远”，不如问“合成数据能带着真实数据走到多远”。先靠合成数据把底子打厚，再让真实数据把精度拉满，才是泰文OCR落地最现实的路径。
最后再分享一个小技巧。如果你有足够多的无标注真实图片，试着把它们混入合成管线的背景池，让文字随机渲染在这些真实图片上，不贴任何标签也不做任何后处理，只当背景纹理来用。这一步处理过之后，模型在真实场景里的误检率能下降不少，而且几乎不增加标注成本。原理不复杂，真实背景的纹理和光照分布，是纯程序生成很难完全模拟的，把真实背景当素材直接喂给合成管线，相当于让模型提前见到更多目标场景的底层视觉特征。这个小改动，效果立竿见影。
