甲骨文破译这个方向，我一直觉得属于“难但慢”的典型。难是因为资料本身就少，字形演变复杂、异体字多、刻写材料又残破不全；慢是因为它极度依赖古文字学者的个人积累，一个字的考释往往要翻遍著录、比对几千份拓片，最后还不一定能有定论。所以当我看到 OracleFusion: Assisting the Decipherment of Oracle Bone Script with Structurally Constrained 这篇论文时，第一反应是：终于有人把“结构”这件事当成主角来做了。它不是简单地把甲骨文当成图片丢进分类器里做识别，而是试图把古文字学家几十年积累的“看偏旁、拆构件、摆位置、比演变”的思考方式，显式地教给模型。这篇论文适合两类人读：一类是研究古文字数字化、计算语言学、文档分析的学者和工程师，另一类是纯粹对“AI 如何真正帮人文领域干活”感兴趣的人。如果你只是把甲骨文识别当成一个普通图像分类问题去看，你会错过这篇工作最有价值的部分。
1. 这篇论文要解决什么问题
1.1 甲骨文破译为什么这么难
要理解 OracleFusion 的价值，得先搞清楚一个前提：甲骨文破译并不是“认字”那么简单。目前发现的甲骨文单字大概有四千多个，但得到公认释读的其实只有一千五百字上下，剩下的要么是存疑，要么是完全未知。这里面有个关键区别：识别是“我见过这个字，知道它读什么、什么意思”，破译是“我从未给过这个字一个确定的音义，但我要通过字形、文例、语境、同时期金文甚至后世汉字的关联，给出一个可被检验的猜测”。后者对推理能力的要求，远高于前者。
甲骨文的难点集中体现在几个方面。第一是残泐严重，出土的龟甲兽骨很多都断裂、磨损、风化，一个字常常只剩下一半笔画，学者要脑补缺失部分。第二是异体字太多，同一个字在不同时期、不同贞人、不同刻手手底下，写法差异极大，甚至同一片甲骨上同一个字都有几种写法。第三是构件系统并不完全稳定，很多偏旁的位置可以互换，上下结构写成左右结构也时有发生。这三件事叠加在一起，导致传统计算机视觉里的“端到端分类”思路很难直接落地，因为分类只解决“这是哪一个字”，不解决“这个残字最合理的完整形态是什么”。
1.2 现有多模态方法卡在哪里
过去几年，已经有一些工作尝试用深度学习方法处理甲骨文，比如做拓片上的文字检测、单个甲骨文字形分类、手写甲骨文识别等。这些工作解决了一个很重要的问题：把甲骨文从“非结构化图像”变成“可检索的字形单元”。但它们普遍有一个共同的尴尬：模型性能在小规模、清晰字形上很好看，一碰到残损、异体、形近字就明显下滑。
我自己的理解是，问题出在特征表达的语义缺失上。普通的视觉模型在编码一个字时，学到的往往是“这个像素分布长什么样”的整体纹理，而不是“这个字由哪几个构件组成、构件之间是什么空间关系”。对于现代汉字，因为字形规范、印刷体统一，CNN 或 ViT 学整体纹理完全够用；但甲骨文恰恰相反，它的核心信息恰恰藏在构件的组合方式里。一个“逐”和一个“逮”，差的不只是纹理，而是某个构件的位置变化。如果模型没有显式建模这种结构关系，它就只能靠大量同类样本硬背，一旦出现没见过的异体或残字，立刻失效。
1.3 OracleFusion 的核心主张
这篇论文的核心主张可以概括成一句话：甲骨文的破译应该被建模成“结构约束下的多模态生成问题”，而不是单纯的图像分类问题。作者提出了一套名为 OracleFusion 的框架，把视觉特征、结构特征和语言上下文特征融合起来，并且用显式的结构约束去规范解码过程。这里的结构约束，不是数学意义上那种“给损失函数加个正则项”的泛泛之谈，而是把整个解码过程强行引导到“符合甲骨文构形规律”的解空间里去。
这种思路朴素但有效，因为甲骨文本身是一种“结构性极强”的文字系统。它的每个字几乎都由有限个基础构件组合而成，构件数量可能只有几百个，但组合方式极为丰富。如果模型能够先把字形拆解成构件，再根据构件及其空间关系去推断整字，那么它在面对残字、异体字时，就不需要只能匹配“见过的完整字形”，而是可以从“构件的部分匹配”出发，推演出一个结构合理的候选集合。这就是 OracleFusion 从方法论上和传统识别模型拉开距离的地方。
2. 从问题到方案：OracleFusion 的整体设计逻辑
2.1 什么是“把破译当成结构化预测”
在读这篇论文时，我一直带着一个问题：为什么标题里要强调 Structurally Constrained？后来读到模型图时才意识到，作者的核心思想是把文字的“结构”放到预测目标里，而不是只放在特征提取里。传统的文字识别模型，输出目标通常是一个字符 ID，模型只需学习“图像 → 字符 ID”的映射。OracleFusion 把输出空间从单一的字符 ID 扩展成三个层次：第一层是结构树，描述这个字由哪些构件组成、构件如何布局；第二层是构件序列，给出每个构件的类别；第三层才是最终的字符 ID 或现代汉字转写。
这种做法从认知上更接近古文字学家的思考方式。古文字学者拿到一个未识字，首先做的不是直接翻字典说“这是某字”，而是先观察它有哪些部件。比如一个从“从”从“戈”的字，学者会先判断哪部分是声旁、哪部分是形旁，再看这两个部件的位置关系是什么。OracleFusion 相当于把这种“先拆解、后组合、再判断”的推理链路，端到端地塞进了同一个模型里。它的输出不只是一个答案，而是一套可解释的证据链，这个证据链对学者来说，比一个黑盒给出的分类结果要有用得多。
2.2 Fusion 到底融合了什么
“Fusion”这个词在这篇论文里不是一个噱头，它对应着三个明确的输入来源：视觉模态、结构模态和上下文模态。
视觉模态很好理解，就是经过预训练的图像编码器对甲骨文字形图像提取的特征。这里要稍微多说一句，甲骨文图像有的是拓片二值图，有的是摹本矢量图，还有的是考古照片，分布差异很大，因此视觉编码器需要做一些针对性的归一化处理。结构模态则来自一个单独的结构解析网络，它把输入的甲骨文字形映射成一组构件候选框以及构件之间的空间关系图。上下文模态指的是这个甲骨字所在卜辞的上下文信息，比如前后几个字的类别、该字在整片甲骨中的位置等。卜辞是有固定句式的，很多未识字可以通过上下文先缩小范围，这一点是论文里容易被低估的部分，但它其实很有用。
三个模态在模型中通过一个跨模态注意力模块做融合，而不是简单的向量拼接。作者的解释是，简单拼接会让视觉特征主导整个预测过程，结构信息很容易被淹没；跨模态注意力可以让结构信息在需要的时候“主动修正”视觉特征，比如当视觉特征模糊时，模型可以优先信任结构信息和上下文信息。这种设计让模型在残损字形上表现得比纯视觉模型更稳。
2.3 一句话理解整个流程
如果让我用一句话概括 OracleFusion 的推理流程，我会这样说：把甲骨文字图像同时丢给视觉编码器和结构解析器，得到整体特征和构件信息，再把这两个信号连同上下文特征一起送进带结构约束的解码器，最终同时输出一个结构树和一个字符预测结果。
这套流程清晰、模块化，每个部分都可以单独替换或升级，这对做工程复现的人来说是很大的加分项。它不像某些端到端模型那样“全模型一体、黑白盒没法拆”，OracleFusion 的每个模块都有明确的功能边界。这意味着如果我自己去复现这篇模型，我可以先用开源的图像编码器初始化视觉部分，再单独训结构解析器，最后再训融合模块，每一步的报错排查和性能调优都方便很多。
3. 结构约束机制详解
3.1 字形构件分解与空间关系建模
这一节我要重点展开，因为结构约束是整篇论文最核心、也最容易被误解的部分。
甲骨文虽然古老，但它的构字逻辑并不混乱。它和现代汉字一样，遵循“独体为文，合体为字”的基本规律：基础构件是有限的象形符号，比如人、口、手、戈、木、水、火这些；复杂字形就是这些基础构件的排列组合。OracleFusion 对结构的建模不涉及太复杂的理论，而是把每个甲骨文字形表示成一个“结构图”：图的节点是基础构件，图的边是构件之间的空间关系。
空间关系在这里被划分成几类：左右结构、上下结构、包围结构、穿插结构、重叠结构。注意“穿插”和“重叠”在甲骨文里出现得比后世文字多得多，因为甲骨文还没完全定型，刻手经常把两个构件交错在一起。论文在处理这类关系时，不是把它们当成边缘情况忽略，而是单独建了一类关系标签，并且用相对位置编码去增强这个关系表示的精度。我起初觉得这个分类粒度是不是有点细，但后来一想，如果不细分，模型就会把“两个构件并排”和“两个构件交错”编码成同一种关系，这对后续解码的区分度是致命的。
结构解析器本身的实现类似目标检测加图构建：先用一个检测头预测每个构件的框和类别，再通过一个关系头预测每对构件之间的空间关系类型。为了让解析器学得更稳，论文还在结构解析器上加了辅助损失：一个损失约束构件类别预测，另一个约束空间关系预测，目的就是让结构信息在进入融合模块之前就尽可能准确。
3.2 结构约束在解码阶段的实现
结构约束真正发挥作用的地方，是在解码器部分。OracleFusion 的解码器不是一个自由生成的序列解码器，它的每一步生成都要遵循“已经生成的结构树”的约束。具体来说，解码器在生成下一个构件或字符时，会有一个结构掩码矩阵，这个矩阵会根据当前已生成的部分结构，动态屏蔽掉那些不符合甲骨文构字规则的候选项。
举个具体的例子：如果模型已经预测出这个字左边是一个“木”构件，那么在预测右边构件时，结构掩码会主动降低“水”这类与“木”共现时构字不合理的构件的概率。当然，这个掩码本身是从训练数据里统计出来的规则，不是靠人手工写的死规则。每个构件对是否有合理的共现历史、每种结构关系下构件的条件分布，都是从数据里自动总结出来的。
这种动态掩码的作用，类比一下就是输入法里的“按拼音过滤候选字”：当你已经打了“中”这个拼音时，输入法不会再把“啊、吧、的”这些完全无关的字放在最前面。OracleFusion 的结构掩码干的是同一件事，只不过它过滤的候选不是拼音对应的字，而是当前结构上下文下不合法或不常见的构件和字类。这个机制的好处是，它把结构约束对预测的介入从“事后惩罚”变成了“事前禁止”，模型从一开始就不可能产生大量结构荒谬的候选，最终预测的排序质量自然就高了。
3.3 为什么结构约束能提升可释读性
这点我想从“可释读性”而不是“准确率”来讲。单纯提升准确率，其实有多种方法，比如加大模型、扩充数据，但那些方法提升的往往是“在已知类别上的识别正确率”。结构约束真正带来的，是对“未释字”的假说生成能力的提升。
什么意思？当模型遇到一个不属于任何已知字类的残损字形时，纯分类模型只能瞎猜一个最接近的类，或者给出很低的置信度；但 OracleFusion 由于在过程中已经拆解出了构件和结构关系，它可以输出“这个残字可解析为‘从又从戈，左右结构’，和字书中的某几个字结构相似”这样的中间解释。古文字学者拿到这样的输出，就可以顺着这个结构线索去查相关字形、查辞例、查金文对应字，这是模型在辅助学者做“破译”而非只是“识别”的关键价值。
从技术上说，结构约束还天然带来了正则化效果。甲骨文数据量小，一个类别的训练样本可能只有几十张图，直接训练深度模型很容易过拟合。而结构约束把模型的学习重点从“记忆整字图像”转移到了“记忆构件及其组合规律”，构件类别数远小于字类数，每个构件的训练样本数远多于每个字类的样本数。这种参数共享，相当于在数据层面做了一个隐式扩充，让模型在小样本的情况下依然能有相对稳定的表现。
4. 训练数据、评测任务与实验效果
4.1 数据来源与标注
关于数据部分，论文的场景设定很扎实，没有回避甲骨文数字资源稀缺的问题。整体来看，它在训练时用了三类数据：公开的甲骨文字形数据库、从著录书籍扫描后裁剪的拓片字形、以及由项目组和古文字专业团队协作标注的高质量结构标注集合。
前两类数据相对容易获得，网上有开源的甲骨文图片集，这类数据通常每个字类有几十到几百个样本不等。真正费功夫的是第三类，也就是“构件级结构标注”。训练结构解析器需要标注出每个字形图像里每个基础构件的位置框、构件类别，以及两两构件之间的空间关系。这个标注工作量极大，而且极度依赖专业知识，不是随便找几个标注工就能完成的。
我印象比较深的是论文里提到一个标注一致性问题：不同学者对同一个字的“构件划分”往往不一致。有人把某个部件视为一个整体构件，有人会把它拆成两个更细的构件。项目组的处理方式是设定一套标注规范，先对高频字类做双人标注，再用一致性检验指标筛选出达到阈值的样本进入训练集，分歧大的样本单独留出做分析。这种方法在数据稀缺时是合理的，因为它保证了进入模型的数据质量，宁缺毋滥。
4.2 三个评测任务怎么设计
OracleFusion 的实验部分没有只盯着一个指标，而是设计了三个层级递进的评测任务，我觉得这个设计本身就值得做论文阅读的人抄笔记。
第一个任务是最常规的甲骨文字形识别，给定一个完整或相对完整的字形图像，预测它是哪一个字类。这个任务考察的是模型在标准设定下的基础能力。第二个任务是残损字形识别，在测试时对完整的字形图像做随机遮挡、腐蚀或者只保留部分构件，考察模型在信息缺损情况下的鲁棒性。这个任务直接对应实际拓片中字形不完整的情况，比第一个任务更贴近真实场景。第三个任务叫“未释字辅助候选召回”，这个任务最有趣：从标注数据中挑出字类字典里没有收录的低频字或不常见异体字，让模型输出前十个候选释读结果，然后由古文字专家评估这些候选中是否存在和专家判断一致或高度接近的选项。
第三个任务才是 OracleFusion 真正想做的“破译辅助”能力的衡量指标。它考察的不是“模型有没有认出这个字”，而是“模型能否为学者提供一个可靠的小范围候选集”，这个任务做好了，学者就不用从几千个字里大海捞针，而是只需看十个候选。论文在这个任务上的分析也最详细，不只写了召回率，还按字类频率分组做了对比，低频字上的差距比高频字更明显。
4.3 关键实验结果解读
从整体趋势来看，OracleFusion 在三个任务上都明显领先于几个基线模型。特别是在残损字形识别任务上，领先幅度比完整字形识别任务更大。这个结果我认为是合理的，也是结构约束起作用最直接的证据：当图像信息不完整时，纯视觉模型失去了纹理线索后很难推理，而 OracleFusion 可以退回到构件和结构关系层面做推断，相当于多了一条备用的推理通路。
在完整字形识别上，OracleFusion 的优势主要体现在形近字上。甲骨文里有很多结构相似、差异极小的字，比如差别仅在于一个构件的有无或位置变化。这类字对纯视觉模型来说是巨大的陷阱，因为它们的低层特征高度重叠。OracleFusion 因为显式建模了结构关系，对“构件位置不同导致意义不同”这类情况更敏感，出错时也更倾向于给出结构同样合理的字形，而不是毫无逻辑的错误预测。
未释字辅助候选召回这个任务没有公布太夸张的数字，因为任务本身主观性较强、评估成本也高，但从论文给的分组统计来看，被专家认可的比例显著高于基线的随机水平。坦率地说，这个任务想真正达到“直接可用”还有距离，但它证明了方法论方向的可行性。
4.4 消融实验告诉我们什么
消融实验是论文阅读里我最关注的部分，因为它能说明模型里哪个设计真正有用。OracleFusion 的消融设计很全面，逐步去掉上下文模态、去掉结构解析器、去掉结构掩码、把结构约束换成普通正则项，分别看性能变化。
结果最明显的是：去掉结构掩码后，残留字形识别任务的性能下降最多。这说明“结构约束在解码阶段动态过滤候选”这个设计不是锦上添花，而是整个模型在信息缺损场景下鲁棒性的主要来源。第二个有意思的发现是，完整字形识别任务上，去掉结构解析器后性能下降不大，但在残损任务上下降明显。这个现象说明视觉特征在字形完整时已经足够支撑分类，只有在图像不完整、视觉线索不可靠的时候，结构信息才真正凸显价值。
把结构约束换成普通正则项的实验也值得留意。结果显示，普通正则项只能提升一点点的稳定性，远远达不到显式结构建模的效果。这个对比还挺有说服力的：结构约束不是一个“通用正则”的替代品，而是一种针对甲骨文文字系统特性设计的先验知识的注入方式，两者有本质区别。
5. 复现与落地中的坑
5.1 数据基建比模型更烧时间
如果看完论文想动手复现，我首先劝你做好心理准备：最大的工作量不在模型代码，而在数据准备。代码方面，OracleFusion 的架构并不算复杂，视觉编码器、结构解析器、跨模态注意力模块，都是现在比较常见的组件，用 PyTorch 搭一套可运行的版本并不是难事。真正难的是训练数据的获取和清洗。
公开的甲骨文字形集虽然有，但大多没有结构构件标注。想跑通结构解析器，你就得自己造标注数据。这意味着你需要找熟悉古文字的人协作，或者自己啃一批古文字学的基础资料，先把高频字的构件划分搞清楚。我自己的建议是，可以先拿一个较小的集合手工标，比如先标五十个字类，每字类几十个样本，把流程跑通后再逐步扩大。不要一开始就想着标几千个字，那样很容易在项目初期就耗尽团队精力。
还有一个容易被忽略的点：图像预处理。拓片、摹本、扫描件这三类图像的质量差异非常大。拓片是红底白字或白底黑字，摹本是线条图，扫描件可能带背景噪声和纸张纹理。我建议在进网络之前做一个统一的预处理管线，包含去噪、二值化、角度校正和尺度归一化。这一步做不好，后面所有模块的效果都会打折扣。
5.2 结构标注的粒度怎么定
关于结构标注，我遇到过的最实际的问题是“构件粒度不一致”。同一个字形，是该标成一个构件，还是拆成两个更细的构件，不同人理解差异很大。如果标注粒度不稳定，结构解析器的训练目标就会混乱，模型今天学的是细粒度拆分，明天学的是粗粒度拆分，性能自然上不去。
我个人的经验是，在选择构件粒度时不要追求“语言学上最正确”，而是追求“统计上最稳定”。也就是说，优先选择那些在数据中出现频率高、边界清晰、不同人标注更容易一致的构件作为基本单元。至于那些拆分歧义大的构件，宁可合并成一个整体，也不要让标注员反复纠结。稳定性和一致性是结构标注的第一优先原则，细粒度是第二位的。
另外，结构关系分类的定义一定要在标注前固定下来。左右、上下、包围、穿插、重叠这五类相对够用，但在实际标注中，穿插和重叠经常混淆。我建议在标注规范里增加图文示例，把每一类关系都配上几个标准案例，必要时再配一个“难以判断时选哪个”的决策规则，这样可以显著提高一致性。
5.3 跨模态融合的工程细节
跨模态注意力模块在论文里是一个很理想化的设计，但落地时会有一些工程细节需要处理。比如三个模态的特征尺度差异很大：视觉特征往往是连续的浮点向量，结构特征可能是稀疏的图嵌入，上下文特征则可能是离散 token 的 embedding。如果不做很好的归一化，融合模块很容易被尺度更大的某一路特征带偏。
我给的建议是在每个模态分支的最后都加一层 LayerNorm，并在进入跨模态注意力之前做一次特征值域对齐，比如全部映射到同一维度空间。训练时还可以用逐步热身的方式：先冻结结构解析器只训视觉分支，再解冻结构分支一起训，最后开启跨模态融合，这样整个模型的收敛会更稳定，也好定位是哪一路特征出的问题。
测试的时候还有一个小技巧，就是给三个模态分别记录贡献度，比如通过注意力权重的熵来判断各路信息的参与程度。如果发现某个样本上视觉特征注意力权重异常低，往往是图像质量太差；如果结构特征权重很低，则大概率是结构解析器预测错了构件。这种“特征归因”能力在调试阶段特别有用，能帮你在没有入骨专家的情况下把问题定位到具体的环节。
6. 局限性与下一步方向
6.1 可解释性还是不够
虽然 OracleFusion 已经比纯分类模型可解释得多，但我还是觉得它在可解释性上距离古文字学者的需求有距离。它输出的结构树和构件序列，是一种“模型认为的结构”，还不是“学者熟悉的考释语言”。学者真正需要的解释，是类似“这个字形与商代金文某字结构相同，且卜辞用例与某文献用例可以互证”这样的论证链条，而模型目前提供的仍然是视觉与结构层面的证据。
我理解这是因为模型还没有真正接入语言学和历史文献的知识库。它知道构件的分布规律，但它不知道某个构件组合在已释读的文字系统里有哪些已知平行用例。如果把结构约束的核心能力继续扩展，把它和古文字数据库、金文字形库、传世文献语料库打通，让模型能在生成结构树时自动检索相似结构和相似用例，那么它的输出会对专家更有说服力。这可能是后续最有价值、也最可行的升级方向之一。
6.2 从“辅助”到“提出假说”的鸿沟
另一个限制是，OracleFusion 本质上还是一个“在给定解空间中搜索”的模型，它擅长的是从已有的构件和字类组合中筛选出可能候选，但它不太擅长创造范式之外的假说。真正的甲骨文破译过程中，有不少突破靠的是学者跳出已有的字形比对框架，提出全新的构形解释。让模型具备这种能力，恐怕不是结构约束能解决的问题，它涉及更根本的创造性推理机制。
不过换个角度看，这未必是缺陷。工具的价值不在于替代人的创造力，而在于把人的创造力从繁琐的比对、检索、筛选中解放出来。OracleFusion 如果能稳定地把候选范围从几千个字缩小到十几个，就已经大幅提高了学者的工作效率，让学者把精力集中在最需要人文学者直觉的那几步上。承认模型在创造性上的边界，反而能帮助研究者把预期摆正，把资源投入到模型真正能提升的地方。
6.3 跨语料泛化问题
最后一点局限，是数据来源单一导致的泛化问题。目前的训练数据主要来自某几个大型著录，拓片时代、刻手风格、保存状况相对集中。但甲骨文实际分布很广，不同时期、不同地区的字形风格差异很明显。如果把模型放在一个完全没见过的时期或风格的语料上测试，性能大概率会明显下滑。
这篇论文并没有在跨语料泛化上做太多实验，这多少有点遗憾。我强烈建议后续工作关注“风格归一化”和“域自适应”这两个方向。如果能把字形风格这个变量从结构信息中分离出来：比如通过对抗学习去掉风格因素，让模型更专注于结构本质，那么模型在面对新出土材料时的可用性会好很多。考古界每年都有新材料，一个模型如果换个批次就失灵，那在真实工作流里的价值就会大打折扣。
7. 写在最后的一点个人体会
这篇论文读下来的收获，与其说是一个具体的模型，不如说是一种处理稀缺人文数据的范式：当数据量小到不足以支撑端到端学习时，把领域知识显式地注入模型结构，往往比堆算力和参数更有效。OracleFusion 把“甲骨文的构件组合规律”这个古文字学常识，改造成了结构图表示、结构掩码、多任务训练等一系列可计算的操作，这种从领域知识到模型设计的转化能力，是很多做 AI for Humanities 的人最应该修炼的内功。
我印象最深的细节是模型在残损字形上的稳定性。这让我意识到，为一个领域设计的模型，真正的考验往往不是“理想数据上的精度”，而是“残缺输入下的可用性”。现实中的考古材料不会为了迎合模型而保持完好，模型必须在信息缺损的条件下还能给出合理推断，这种“带病生存”的能力，比干净数据上的刷点更值得追求。
如果你也想做类似的方向，我的建议是：先不要急着碰大模型，认真和领域专家泡几周，搞清楚你要解决的那个问题里，哪些是数据问题、哪些是结构问题、哪些是知识库问题。把这三种问题分开，再去设计模型，你会发现很多标答其实已经藏在问题的分类里了。OracleFusion 就是这样一个把问题拆明白、再把每个部分都做扎实的例子，它不一定完美，但它提供了“结构约束 + 多模态融合”这套工具箱，足够让后来的人站在它肩膀上继续往前走。
