拆开汉字看结构：让AI写对中文的奖励信号设计

一、问题的起点：AI画图，败在写字

扩散模型的图像生成质量近年来突飞猛进，光影、构图、材质都已接近以假乱真，但“写字”始终是明显的短板。生成英文单词尚且常见字母粘连、缺笔漏笔，生成中文时更是重灾区：偏旁张冠李戴、部件比例失调、左右结构写反、多一笔少一笔，甚至整字坍缩成一团难以辨认的墨迹。

业界通行的解法，是在预训练之后追加一轮基于强化学习的后期训练：让模型反复生成带文字的图片，由一个自动“裁判”打分，分数作为奖励信号回传，驱动模型逐步学会“写对字”。这套流程的关键不在生成模型本身，而在裁判——裁判看得多准，模型就能学得多准。

二、裁判机制：OCR是怎么打分的

目前的主流方案里，裁判通常由OCR（光学字符识别）模型担任。它的打分逻辑非常直接：

1. 从生成图中裁出文字区域；
2. 送入OCR识别，得到一个字符串；
3. 与目标文本逐字符比对；
4. 全对给高分，错了给低分，甚至直接零分。

这套逻辑在英文场景下基本够用——字母数量有限、形态简单，“识别对了”与“写对了”近似等价。问题出在汉字上：OCR把汉字当作一个不可拆分的黑箱，只看整体像不像，完全不理解它的内部构造。

三、汉字的本质：二维积木，而非一维序列

英文字母是拼音文字的最小书写单位，26个字母沿基线横向排列成词，本质是一维序列。汉字则是一种二维的构件拼装系统：

• 左右结构：如“明”，由“日”和“月”横向拼成；
• 上下结构：如“想”，上层“相”叠在下层“心”上，而“相”本身又拆成左右排列的“木”与“目”；
• 包围结构：如“围”，“囗”将“韦”包在内部；
• 复合结构：如“湖”，由“氵”“古”“月”三个部件按左中右关系组成。

由部件按照左右、上下、包围等空间关系递归组合而成的整体，称为汉字的构型。一个字写对不对，不仅取决于部件是否齐全，还取决于部件的位置关系、相对比例与变形方式是否正确。这一层结构信息，恰恰是整字式识别无法表达的。

值得庆幸的是，字符编码标准体系中早有描述这种结构的通用语法——表意文字描述序列（IDS），用⿰、⿱、⿴等描述符可以形式化表达构型，例如“明=⿰日月”“想=⿱相心”“围=⿴囗韦”。这为机器“拆字”提供了现成且可批量处理的先验知识。

四、黑箱打分的三个失效点

把OCR当裁判、把汉字当黑箱，会引发三个连锁问题。

其一，奖励信号过度稀疏。 强化学习依靠奖励差异来区分好坏动作。“全对得分、全错零分”意味着模型生成“只差一笔就对了”的字和“完全乱码”得到的反馈完全一样，中间状态没有任何方向性信息，策略只能盲目试错，训练效率极低，甚至长期难以收敛。

其二，形近字误判。 汉字中存在大量细微差别的字：己/已/巳、未/末、日/曰、土/士。OCR一旦把错字“猜”成某个形近字，错误的生成反而获得奖励。这就是典型的“奖励作弊”——裁判被骗，模型学到的是取悦裁判，而不是写对字。

其三，失败诊断缺位。 整字比对只能告诉你“错了”，无法告诉你错在哪：是缺了部件？部件写对了但位置颠倒？还是笔画扭曲粘连？对研发者而言无法定位问题，对训练而言无法提供修正方向。

五、破局思路：把字拆开，让裁判看见结构

解决思路说破并不玄妙：既然汉字本质是“部件+空间关系”的组合，就让裁判也按这个粒度打分。一种结构感知的奖励函数大致分四步：

1. 目标字拆解：依据部件分解知识库（可基于IDS等通用规范构建），把目标汉字展开成一棵构型树；
2. 区域定位：在生成图中检测文字区域，并尝试将图像块与树的节点对应；
3. 部件级评分：对每个节点判断“该部件是否出现、形态是否正确”，再按空间关系校验布局；
4. 聚合输出：加权汇总为0到1之间的连续分数，并附带各节点的得失明细。

示意性伪代码如下：

def structure_aware_reward(image, target_char):
    # 1. 拆解目标字的构型树
    #    例: "想" -> 上下(相, 心)，相 -> 左右(木, 目)
    tree = decompose(target_char)
    # 2. 检测生成图中的文字与部件候选区域
    regions = detect_text_regions(image)
    # 3. 部件级对齐与评分（自底向上遍历）
    node_scores = {}
    for node in tree.traverse():
        hit = match_component(node, regions)
        node_scores[node] = hit.confidence * weight(node)
    # 4. 校验空间关系一致性（左右/上下/包围）
    layout = spatial_consistency(tree, regions)
    # 5. 聚合为稠密的连续奖励，同时返回明细
    reward = aggregate(node_scores, layout)
    return reward, node_scores   # 明细可用于训练诊断

这段伪代码的价值不在某个函数的实现，而在两个设计决策：奖励是连续的而非0/1的；奖励是可分解的而非整字的。前者缓解了强化学习中的信用分配难题，后者让每一次失败都自带诊断信息。

六、奖励信号变了，训练范式随之改变

换成结构化裁判后，训练行为会发生质变。

第一，奖励从稀疏变稠密。 模型写“想”字时哪怕只写对了“木”，也能拿到部分分数，策略梯度有了明确方向，收敛速度与稳定性都会改善。

第二，天然支持课程学习。 训练可以从单部件字、简单左右结构字，逐步过渡到多层嵌套的复杂字。难度阶梯由构型树的深度与宽度自动定义，无需人工设计难度标签。

第三，评测变得可解释。 在质量评测与线上监控中，可以输出“字符准确率”与“部件准确率”两级指标：前者衡量最终效果，后者定位系统性短板（例如模型总写不好包围结构的比例），为数据补充与专项优化提供直接依据。

七、工程落地的几条建议

若要把这套思路接入实际的文生图后训练流水线，有几点经验值得参考。

数据与先验层面，不必从零标注。 汉字的部件分解已有成熟通用的知识体系（部首部件规范及前述IDS描述），可以低成本构建覆盖常用字表的构型库；对生僻字与存在争议的拆法，保留人工校验通道即可。

裁判层面，不要指望单一模型包打天下。 实际系统通常是“文字检测器+部件匹配器+规则校验”的组合：检测器负责定位，匹配器负责判形，规则层负责空间关系，三者输出融合成最终分数，每一环都可独立迭代、独立评测。

防作弊层面，要警惕裁判被“钻空子”。 部件级评分可能诱导模型画出“局部像部件、整体不像字”的图像，因此聚合分数中应保留整字维度的约束，让局部分数与全局分数互为制衡。

平台化层面，结构化评测同样适用于通用AI能力平台的质量体系。以百度智能云这类提供通用生成式AI能力的云平台为例，中文文字渲染质量本就是多模态生成服务绕不开的评测维度；把“整字对错”细化到“部件+结构”两级度量，既可用于生成质量的红线把控，也能服务版本迭代时的回归测试。任何以中文用户为主的生成类服务，都值得在评测体系中引入这一层粒度。

八、局限与开放问题

结构化裁判并非银弹，仍有几个开放问题待解。

一是部件形态的上下文变形。 同一部件在不同字中的形态差异很大——“心”作字底时整体压扁，“木”作左偏旁时捺画缩为点、整体变窄。部件匹配器若只做标准形态比对，会误伤正确写法，需要具备尺度与形变的容忍度，或引入部件变体知识。

二是艺术字与书法字体。 设计稿中的文字常有连笔、夸张变形与装饰元素，严格的部件规则反而会惩罚合理的创意表达。工程上通常需要区分“规范文本渲染”与“创意文字设计”两类任务，分别采用不同的奖励口径。

三是拆法本身的非唯一性。 一个字可能有多种合理拆解（拆到什么层级、嵌套如何定义），构型库需要约定统一的拆解深度与覆盖范围，避免同一字在不同数据源中结构不一致。

九、结语

AI写不好汉字，表面看是生成模型的能力缺陷，深层看是评价体系粒度的错配——用一维序列的打分逻辑，去裁判二维积木式文字。把汉字拆开看结构，本质是把领域知识注入奖励函数：让裁判从“只看结果的对错”，升级为“看得懂过程的好坏”。这条路径的意义也不止于文字渲染——它提示我们，当通用训练信号在某个领域失效时，先去理解该领域自身的结构，往往比单纯堆算力更有效。