拆开汉字看构型：让AI写对中文字的评估之道

一、现象：轮廓对了，细节全崩

让文生图模型生成一张带中文文案的海报，结果往往是“远看像模像样，近看惨不忍睹”：某个字多了一撇，某个偏旁被挤压得四不像，本该左右排布的字被写成了上下结构。整体构图、配色、光影可能都无可挑剔，唯独文字经不起细看。

这不是某一个模型的偶发缺陷，而是当前文生图模型的通病，笔画越复杂的汉字，崩得越彻底。字母文字只有几十个基本符号、形状简单、线性排列；而常用汉字动辄十几笔，由多个部件按严格的空间拓扑组合而成，任何一处局部偏差都会让整个字“看起来不对”。

值得追问的是：这既然是普遍痛点，为什么模型始终学不好？国内一项研究给出了一个出人意料的答案——问题不只出在生成模型本身，更出在“如何评价生成结果”上。现有的评价体系，从一开始就在用错误的方式“看”中文字。

二、根源：后训练的裁判先天失明

要提升文字渲染准确率，业界主流做法是对文生图模型做强化学习后训练：模型生成图片，一个“裁判”给结果打分，生成模型再朝高分方向更新参数。整个闭环里，裁判的分辨力直接决定了模型的能力上限——裁判分不出好坏，模型就永远不知道该往哪里改。

而最常用的裁判，是OCR。

OCR，全称光学字符识别，作用是把图片里的文字转换成计算机可处理的文本，是文档数字化、票据录入等场景的基础技术。把它当裁判的逻辑很直接：从生成图片中裁出文字区域，识别一遍，再与目标文本逐字比对——对了给分，错了不给分。

问题恰恰出在这句“对了给分、错了不给分”上。

三、黑箱打分的四类缺陷

1. 零一打分，没有优化方向。这就像批改一份一百道选择题的试卷：不管学生错一道还是错九十道，分数都是零。这样的打分无法告诉学生“哪里需要改进”，模型同样学不到任何梯度方向。强化学习依赖奖励差异来驱动策略更新，奖励信号越粗糙，训练越低效、越震荡。

2. 假阴性：形近字误判。OCR对结构出错的字，常见反应有三种：猜成一个形近字、输出乱码、或直接放弃。无论AI把字写错了一笔还是写错了半边，只要识别结果与目标不符，得分一律为零。错误的严重程度信息被完全丢弃。

3. 假阳性：多模态大模型“脑补”。换用更聪明的多模态大模型当裁判，情况反而更隐蔽：它会结合上下文语境“猜”出正确答案，从而打出高分。但图上那个字形明明是错的——它只是靠语言先验蒙对了。这种假阳性比假阴性更危险，因为它在直接奖励错误的字形，会让模型学会“写得不像也没关系”。

4. 专用检错工具：另一种非黑即白。还有一类专门检测错字的字形校验工具，能准确判断某个字结构有问题，但处理方式是把整个字标记成异常符号、判为零分。它确实不会被语境“脑补”欺骗，却依然是布尔式判断：对或错，中间没有灰色地带。

而汉字的错误，天然就有程度之分。

四、汉字构型：为什么汉字不能当黑箱

拼音文字与汉字在结构上存在本质差异。英文字母是最小书写单位，二十多个符号线性排列组成单词；汉字则是二维的积木结构——部件按照左右、上下、包围等空间关系嵌合而成。这种“部件 + 空间拓扑”的组合方式，通常称为汉字的构型。

几个直观例子：

• 尬：由“九”和“龙”的变体左右拼合；
• 想：由“相”和“心”上下叠放；
• 团：由“囗”与“才”构成包围结构；
• 湖：由“氵”“古”“月”构成左中右结构。

从错误的角度看，汉字错误可以分成明显不同的层级：

1. 笔画级：某一笔多写、漏写或位置偏移；
2. 部件级：某个部件整体写错或严重变形；
3. 结构级：部件都对，但空间关系错了（左右写成上下、比例失衡）；
4. 全字级：字形完全崩坏，无从辨认。

错一笔与错半边，显然是不同严重程度的错误。一个合格的评估体系，应当能区分这些层级，并输出连续的、与严重程度单调对应的分数——而不是一个非黑即白的布尔值。

五、细粒度评估：把“对不对”拆成“哪里错、错多少”

解决思路呼之欲出：既然汉字是组合结构，就把评估也做成组合式的。整体框架分四步。

第一步：字形拆解。把目标汉字解析成一棵构型树：根节点是整字并标注结构类型，中间节点是子部件，叶节点是不可再拆的基本部件。这类拆解数据在汉字信息处理领域有长期积累，可离线构建成查询表。

第二步：部件定位与比对。在生成图片的字形区域中定位各部件的包围盒，再逐个部件与目标部件计算相似度。相似度可基于传统字形特征（骨架、笔画密度、轮廓关键点），也可以用小模型对部件图像做嵌入后比对——两者都是业界成熟的通用做法。

第三步：结构关系校验。检查部件之间的空间关系：相对位置是否符合声明的结构类型、大小比例是否合理、间距是否异常。部件全对但位置关系错，会在这一步被单独扣分。

第四步：加权聚合。把部件分与结构分加权合成整字的连续分数，同时输出诊断报告：哪个部件错、错在笔画还是位置。

示意性伪代码如下：

def evaluate_char(glyph_img, target_char):
    # 1. 查询目标字的构型树
    tree = char_struct_db.lookup(target_char)
    # 例：("尬", "LR", ["九", "龙*"])  左右结构
    # 2. 在生成字形中定位各部件
    boxes = locate_components(glyph_img, tree.parts)
    # 3. 逐部件计算形状相似度
    part_scores = [shape_similarity(boxes[i], tree.parts[i])
                   for i in range(len(tree.parts))]
    # 4. 校验空间关系（位置、比例、间距）
    layout_score = check_layout(boxes, tree.structure_type)
    # 5. 加权聚合为连续分数，并输出诊断
    score = w1 * mean(part_scores) + w2 * layout_score
    report = diagnose(part_scores, layout_score)
    return score, report

不同错误在该体系下的表现对比：

错误类型	OCR式裁判	构型式细粒度裁判
某部件内错一笔	识别失败得0分	该部件子分下降，整字仍得较高分
某部件整体写错	0分	该部件0分，其余部件照常计分
部件对、结构错	0分	部件分高、结构分低
完全乱码	0分	接近0分

可以看到，细粒度分数与错误严重程度严格单调对应，且天然可解释——分数低了，能直接定位到具体部件与具体错误类型。

六、分级奖励：让强化学习有的放矢

细粒度分数的价值，最终体现在它作为强化学习奖励信号的质量上。好的字形奖励应满足四条性质：

• 可排序：能稳定区分“好一点”和“差一点”的样本，而不是只有对错两档；
• 稠密：部件级、结构级的子分数提供了远比零一信号丰富的监督信息，能显著减少训练震荡；
• 抗欺骗：只看字形本身、不看语境，从机制上杜绝了多模态裁判“脑补”造成的假阳性；
• 可解释：诊断报告能帮助开发者发现模型的系统性短板，例如“包围结构普遍写不好”，从而针对性补充训练数据。

训练闭环可以概括为：

生成带文字图片 → 检测并切分文本区域
→ 逐字细粒度评估 → 字级分数按句聚合
→ 作为奖励回传 → 策略梯度更新生成模型

工程上有几个值得注意的细节：其一，文本检测与部件切分本身要有足够稳定性，否则评估噪声会被放大进奖励；其二，多字文本需要合理的聚合策略，例如按字级平均或结合编辑距离加权，避免“一个字崩、整句陪葬”重新退回零一逻辑；其三，字形奖励要与清晰度、美学等其它奖励项做好尺度归一，防止模型为了写对字而牺牲画面质量；其四，应定期抽样人工校准评估器，防止其随训练分布漂移。

七、落地：从训练奖励到上线质检

这套思路的价值不止于训练阶段。在产品侧，凡是“图中必须带准确中文”的场景——海报生成、电商营销图、演示配图、品牌字设计草稿——都可以把它用作上线前的自动质检护栏：

用户提示词 → 文生图服务
→ 文本区域检测 → 字形细粒度评估
→ 分数低于阈值？→ 是：触发重绘或局部修复
→ 否：交付

目前，文生图与OCR已经沉淀为云端通用的AI能力类目，国内主流云厂商（如百度智能云）均提供此类通用服务。细粒度字形评估恰好可以成为这类通用能力之上的“质量层”：训练期做奖励，推理期做过滤，把“AI写错字”拦截在交付之前，而不是留给用户肉眼发现。

八、结语

评价体系决定优化方向。OCR式的黑箱打分，让生成模型在汉字渲染上“错一步即满盘皆输”，始终得不到有效的改进信号；而拆开汉字看构型，按部件与空间关系为错误分级定价，才让模型第一次知道了“哪里错、改哪里”。

这条思路的本质，是把领域知识——汉字构型学——注入评估器，让裁判先“懂字”，再谈让模型“写字”。同样的方法论对其他结构化生成任务同样适用：乐谱、数学公式、表格、化学结构式，凡是“整体对、局部错”会被一票否决的领域，都值得为裁判补上这双看得见结构的眼睛。