拆开汉字看结构：让AI文生图画对中文字

一、背景：能画逼真人脸，却写不好一个“想”字

近年来，文生图模型在构图、光影、质感等维度进步显著，但“在图里写字”始终是公认的硬骨头。生成的海报文案中，文字常常出现笔画粘连、部件缺失、部件错位，甚至整字垮塌成谁也不认识的符号。对中文场景而言，这一问题尤其突出——海报、封面、电商物料对“字必须写对”有刚性要求，一个错字就足以让整张图报废。

问题的根源在于：生成模型在预训练阶段学到的是“看起来像字”的像素分布，而不是“结构上成立”的组合规则。汉字类别数以万计，每个字又是一套独立的二维结构，仅靠数据驱动的拟合，很难保证每一笔、每个部件都严丝合缝。因此，业界普遍的做法是引入后训练（post-training）阶段，用强化学习对模型进行针对性“纠偏”。

二、现行方案：请OCR来当“裁判”

强化学习需要一个奖励来源，即“裁判”负责给模型的生成结果打分，告诉它好还是不好。这个裁判通常由OCR（Optical Character Recognition，光学字符识别）模型担任——OCR是让机器“认字”的通用技术，把图片中的文字转换为计算机可处理的文本。

打分流程大致如下：

# 伪代码：OCR裁判的典型打分逻辑
def ocr_reward(image, target_text):
    crop = locate_and_crop(image)      # 定位并裁出文字区域
    pred = ocr_model.recognize(crop)   # OCR识别裁剪区域
    return 1.0 if pred == target_text else 0.0  # 对了给分，错了不给分

在英文场景中，这套机制相对够用：英文字母是最小书写单位，26个字母按一维线性顺序拼成单词，识别结果与目标文本逐字符比对即可，错误类型有限，奖励虽然粗糙但方向大体正确。

三、失灵根源：汉字是二维构型，OCR却把它当黑箱

3.1 汉字的“积木”本质：部件 + 空间关系

汉字与拼音文字有本质差异。英文以字母为最小单位做一维排列；汉字则是由部件（偏旁、部首等构件）按照特定空间关系组装而成的二维结构，这种结构在汉字信息处理中通常称为构型。常见的构型类型包括：

构型类型	示例
左右结构	明（日+月）、尬（尢+介）
左中右结构	湖（氵+古+月）
上下结构	想（相+心）、花（艹+化）
上中下结构	意（立+日+心）
全包围结构	困（囗+木）
半包围结构	病（疒+丙）、句（勹+口）
品字形/叠架结构	森（三个木纵向叠置）

更重要的是，这种拆解具有层级性：“想”由“相”和“心”上下叠放，而“相”又可继续拆为“木”和“目”的左右组合。同时，部件在组字时还会发生形变与让位：“水”作左偏旁时写作三点水“氵”，“木”在“相”的左侧时末笔捺变为点，“尬”的左侧部件“尢”本身也是“尤”作偏旁时的变形。此外还有“中”“山”“人”等独体字，直接由笔画构成，拆解到部件层面即告终止。

对OCR而言，这意味着识别对象不是一条线性序列，而是一张复杂的二维结构图。面对结构异常的生成图，OCR经常把整个字直接判为“不认识”，要么瞎猜一个形近字，要么干脆放弃输出。

3.2 黑箱打分的三大结构性缺陷

1. 奖励信号过于稀疏。 整字层面只有“对/错”两档，而汉字的生成空间近乎天文数字，模型很难通过随机试错恰好命中“完全正确”的样本。强化学习需要的是“往哪个方向改进”的梯度信号，而不是一份死刑判决书。
2. 奖励信号存在系统性失真。 一方面，OCR自带语言模型的纠错与“脑补”能力，一个结构上已经写错的字，仍可能被识别为正确结果，造成误加分；另一方面，结构大体正确的字，也可能因为笔画粗细、断连、字体风格差异被形近误识，造成误扣分。结果是奖励与“字形是否真的好”之间不对齐，模型被引导去优化“让OCR认出来”，而非“把字写对”。
3. 奖励信号无定位能力。 即便识别失败，裁判也说不出错在哪个部件、哪种空间关系。模型只能整字重采样，学习效率低下。

3.3 长文本场景进一步放大问题

生成一句话时，只要任意一个字出错，整句奖励即归零，奖励方差极大；再叠加文字区域裁剪不准、排版透视等干扰，OCR自身的错误率也会上升，训练信号进一步被噪声淹没。

四、升级思路：从“认字裁判”到“懂字裁判”

近期相关研究给出的解法可以概括为一句话：与其问OCR认不认识这个字，不如问这个字的每个部件是否到位、部件间关系是否正确。具体分三步。

4.1 第一步：构建汉字构型知识库

以常用字为首批覆盖对象，为每个字建立“部件拆解树 + 空间关系描述”：

想（上下结构）
├── 相（上部，约占60%高度；内部为左右结构）
│   ├── 木（左，约占50%宽度）
│   └── 目（右，约占50%宽度）
└── 心（下部，约占40%高度）

知识来源可以是权威字形规范、字典数据，以及通用字库字体的渲染结果——离线渲染标准字形，即可批量导出部件掩码与包围盒，作为结构先验。独体字则退化为笔画级或整字级描述。

4.2 第二步：把0/1奖励拆成多维连续奖励

在强化学习训练时，用三个子项替代单一整字判定：

• 部件存在性奖励 s_exist：各部件是否出现、形态是否正确，由部件级检测/分割模型打分；
• 空间关系奖励 s_layout：部件间的相对位置、宽度高度占比、基线对齐、包围关系是否符合构型先验；
• 整字识别奖励 s_ocr：保留OCR结果作为兜底校验，但降低权重。

# 伪代码：构型化奖励的计算流程
def glyph_reward(img, target_char):
    tree = config_knowledge.decompose(target_char)  # 查构型知识库
    comps = component_detector(img, tree.components)  # 部件检测定位
    s_exist  = existence_score(comps, tree)   # 部件是否齐全、形态对不对
    s_layout = layout_score(comps, tree)      # 位置比例符不符合构型
    s_ocr    = ocr_score(img, target_char)    # 整字识别兜底
    return 0.4 * s_exist + 0.4 * s_layout + 0.2 * s_ocr

两种裁判的对比一目了然：

维度	OCR整字裁判	构型化奖励
信号形态	0/1两点分布	连续、多维
可定位性	无	可定位到具体部件与关系
与字形质量的对齐度	可能脱节	直接相关
额外计算成本	低	中（需部件检测）

奖励一旦从“单点判决”变为“可分解、可定位的连续信号”，训练质量就发生了质变：假如“想”字的“心”写歪了，只有与“心”相关的子项被扣分，模型明确知道该改哪里，而不必推倒重来。

4.3 第三步：补齐训练组件，防住“钻空子”

• 部件检测器从哪来：用字体渲染引擎批量合成“标准字形 + 部件掩码”数据，配合字体、笔画粗细、噪声、透视等增广手段保证泛化，训练一个轻量检测/分割模型即可。
• 接入策略优化：将上述奖励接入PPO等策略梯度类算法的后训练流程。奖励密度提升后，同样的算力能产出更多有效学习信号。
• 防范reward hacking：模型可能学会画出“检测器认识、人眼看着不像”的部件组合。对策是保留整字OCR兜底项、采用多字体多视角交叉校验，并对生成结果做周期性人工抽检，动态校准各子项权重。

五、工程落地清单

• 覆盖优先级：先保证数千常用字的高质量渲染，再分层扩展生僻字；独体字采用降级策略。
• 评测体系：除整字准确率外，应引入部件召回率、结构相似度、多字句准确率与人工可读性抽检，避免单一OCR指标造成评测盲区。
• 成本控制：奖励计算包含额外的部件检测推理，可采用离线批量打分、异步队列缓冲的方式控制训练吞吐；在云端搭建训练闭环时，可依托GPU算力、容器化调度、消息队列、监控告警等通用基础能力，例如在使用百度智能云等平台提供的文生图、模型精调类通用服务时，也应将“文字渲染质量”单列为独立评测项。
• 合规注意：字形知识数据与字库字体需确认授权范围，避免训练资产引入版权风险。

六、结语：从“认识字”到“理解字”

这一思路的本质，是把与任务结构脱节的黑箱奖励，替换为与汉字构型对齐的可解释、可分解奖励——让裁判从“认字”升级为“懂字”。同样的方法论还可以迁移到图表生成、UI还原、公式排版等结构化生成任务：把“整体像不像”拆解为“每个结构单元对不对”。

对中文AIGC而言，文字渲染是绕不开的硬指标。拆开汉字看结构，让奖励信号落在每一个部件、每一种空间关系上，正是补齐这块短板、让AI真正“写对中文字”的关键一步。