以字为本：文言文智能处理中的字级语义建模

一、为什么“字”是文言文智能处理的根基

《文心雕龙》有一句经典论述：“夫人之立言，因字而生句，积句而成章，积章而成篇。”这句话不仅描述了文章的生成规律，也恰好刻画了自然语言处理系统的信息流：任何面向文言文的机器理解能力，最终都要落到“字”这一最小语义单元上。字义不清楚，句子的切分、理解、翻译就都是空中楼阁。

与现代汉语相比，文言文在字级层面有三个显著特点，它们直接决定了技术路线的差异：

1. 单字成词为主。 先秦两汉文献中，双音节词占比远低于现代汉语，一个字往往就是一个词，直接充当句法成分。这意味着现代中文分词器所依赖的“词边界”统计规律在古文里大面积失效，处理单元应当下沉到字级。
2. 一字多义是常态。 文言常用字的义项动辄十几条，而且义项之间并非简单并列，多数存在“本义→引申义”的派生链条。不理解派生关系，就只能在十几条平行的释义里“盲选”。
3. 通假与活用普遍。 通假是“以音借形”，同一字形实际记录的是另一个词，如“说”通“悦”；词类活用则让同一字形在句中临时改变语法功能，如“沛公军霸上”中“军”用作动词“驻扎”。以现代语料训练的词向量与预训练模型，直接迁移到古籍上会出现系统性偏差。

因此，做好文言文智能处理，第一步往往不是堆更大的模型，而是先把“字”的知识弄清楚、存起来、算得动。对应到工程上就是三件事：字义知识的结构化建模、字级语义消歧、可查检可服务的字库基础设施。下文依次展开。

二、字义知识的结构化建模

2.1 从“给人看的辞书”到“给机器算的知识”

权威古汉语辞书以“字头—注音—义项—书证”的线性形式组织内容，供人翻阅毫无问题，但机器需要显式结构。建模时可以围绕四类核心对象展开：

• 字头（Character）：记录字形、读音（含多音）；
• 义项（Sense）：记录释义、词性、语法特征；
• 义链（Sense Link）：记录本义与引申义之间的派生关系，整体构成一张有向图；
• 书证（Evidence）：记录支撑义项的经典例句及出处，是消歧训练与人工校验的依据。

其中“义链”是最有价值的增量信息：市面上不少古汉语数据停留在“字头+释义列表”的扁平结构，而引申链恰恰是把知识从“可查”升级为“可算、可解释”的关键。

2.2 以“行”为例：一条引申链长什么样

“行”的早期汉字字形（如甲骨文）像两条相交的道路，因此“道路”是本义。以此为根节点，可以梳理出一棵清晰的义项树：

道路（本义）
 ├─ 人在道路上移动 ──→ 行走（"三人行，必有我师焉"）
 │      └─ 推及物体运动 ──→ 运行、运动（"天行有常"）
 ├─ 在道路上做事 ──→ 做、执行、实行（"言必信，行必果"）
 │      └─ 抽象为立身准则 ──→ 品行（"听其言而观其行"）
 └─ 道路纵横成列 ──→ 行列（读 háng）

它对应的示意 Schema 如下：

{
  "character": "行",
  "readings": ["xíng", "háng"],
  "senses": [
    { "id": "s1", "gloss": "道路", "type": "本义",
      "note": "字形像两条相交的道路", "derived": ["s2", "s4", "s6"] },
    { "id": "s2", "gloss": "行走", "type": "引申",
      "path": "道路→人的移动", "parent": "s1", "derived": ["s3"],
      "evidence": ["三人行，必有我师焉"] },
    { "id": "s3", "gloss": "运行；运动", "type": "引申",
      "path": "人的移动→物体的移动", "parent": "s2",
      "evidence": ["天行有常"] },
    { "id": "s4", "gloss": "做；执行；实行", "type": "引申",
      "path": "在路上走→做某事", "parent": "s1", "derived": ["s5"],
      "evidence": ["言必信，行必果"] },
    { "id": "s5", "gloss": "品行", "type": "引申",
      "path": "做事→立身行事的准则", "parent": "s4",
      "evidence": ["听其言而观其行"] },
    { "id": "s6", "gloss": "行列", "type": "引申",
      "path": "道路→纵横排列", "parent": "s1", "readings": ["háng"] }
  ]
}

通假关系则可以作为独立字段挂在字头上：

{
  "character": "说",
  "phonetic_loan": {
    "target": "悦", "gloss": "高兴、喜悦",
    "evidence": ["学而时习之，不亦说乎"]
  }
}

2.3 建模四原则

• 义项粒度适中。 粒度过粗，消歧失去区分能力；过细，标注成本与义项边界争议会被放大。工程上常用“核心义项＋组合规则”折中，边缘细微差别交给规则或模型处理。
• 保留引申链的中间节点。 中间节点既是解释性资产（可直接用于教学展示、注释生成），也是消歧先验——引申通常发生在语义相邻的义项之间，链上距离越近的义项越可能出现在相近语境。
• 音、义、用例绑定。 多音多义字必须把读音与义项绑定在同一节点上（如“行”的 háng 读音只属于“行列”义），先定音再定义，避免跨音串义。
• 书证必须可溯源。 每条例句标注出处，保证任何一条机器判定结果都能回溯到原文，这是后续人工评审与 badcase 分析的基础。

三、字级语义消歧：从结构到算法

3.1 问题定义

给定字 c 及其上下文 ctx，从候选义项集合 S(c) 中选出当前语境下最合适的义项 s。它是注释生成、文白翻译、古籍检索等上层任务共享的基础能力。

3.2 三种互补的策略

1. 规则与词典驱动。 利用句法槽位与固定搭配：如“天行有常”中“天”作主语、“行”居谓语位，谓语位置优先取动词性义项；“行列”等高频双字组合可直接命中词级缓存。
2. 语义表示驱动。 把上下文窗口内的字词编码为向量，与各义项书证（或释义文本）的向量做相似度匹配；书证稀缺的义项可退化为用释义文本的向量表示，实现零样本覆盖。
3. 结构先验约束。 引申链提供先验权重：当上下文词汇更接近某义项书证的语义场（如出现“路、道、途”等字时提高“道路”义权重），或候选义项在链上距离悬殊时，利用先验打破平局。

示意代码：

def disambiguate(entry, context):
    """根据上下文从候选义项中选择最合适的一项（示意）"""
    ctx_vec = encode(context)
    best, best_score = None, -1.0
    for sense in entry["senses"]:
        texts = sense.get("evidence") or [sense["gloss"]]
        vec = mean(encode(t) for t in texts)
        score = cosine(ctx_vec, vec) + prior(sense)  # 先验：链上距离、义项频率
        if score > best_score:
            best, best_score = sense, score
    return best

3.3 评测与迭代

• 指标设计：义项标注的准确率/F1；多音字按“先定音、再定义”分层评测，单独统计串音率。
• 回归测试集：固定一批覆盖典型引申链与通假现象的经典句子，任何字库或模型变更都必须全量回归。
• badcase 回流：线上低置信样本与人工纠错记录定期回流，一部分进入模型训练，一部分触发字库修订，形成“数据—模型—评测”的闭环。

四、工程落地：让字库“查得快、算得稳、改得动”

4.1 存储与查检

常用汉字规模在数千量级，但义项与书证可达数十万条。在线查检用哈希表按字头 O(1) 定位；同时预建两张归一化表——字形规范表（异体字、繁简对应）与通假关系表，在索引层把“说→悦”这类变体归一到规范字头，避免上层逻辑重复处理。

class CharKB:
    def __init__(self, entries, alias_map):
        self.by_char = {e["character"]: e for e in entries}
        self.alias = alias_map  # 异体/繁简/通假 → 规范字头
    def lookup(self, ch):
        return self.by_char.get(self.alias.get(ch, ch))

4.2 分层架构

一个典型的四层落地架构：

• 数据层：字库与古籍语料以版本化快照存放（如对象存储），任何修订走“变更集＋评审”流程；
• 计算层：分词对齐、义项消歧、注释生成等服务无状态化、容器化部署，可水平扩展；
• 应用层：辅助阅读、文白翻译、语义检索、教育应用通过统一 API 消费能力；
• 治理层：日志服务记录每次义项判定及其置信度，监控告警跟踪延迟与置信度分布漂移，低置信样本自动进入人工复核队列。

若在公有云环境落地，可以基于百度智能云等平台提供的通用能力组装上述各层，例如用对象存储托管字库快照、用容器平台承载推理服务、用日志服务与监控告警保障运行质量。架构的关键不在选型本身，而在于让字库版本、模型版本、线上效果三者始终可追溯——出现效果回退时，能快速定位到具体变更。

4.3 质量保障

• 双人独立标注、分歧仲裁，书证摘录逐条核对原文；
• 字库每次修订生成结构化 diff，审计可查；
• 教育类输出（如引申链展示）增加专家抽检环节，因为此类场景的错误会被放大传播。

五、应用场景与价值

• 辅助阅读：划词即返回“本句义项＋引申路径”，比单纯给一条释义更可解释，也更利于学习者举一反三；
• 文白翻译：把消歧结果作为翻译环节的输入特征，可显著减少“行路”被误处理为“行业”一类的低级错误；
• 教育产品：将引申链渲染为可交互的“字义树”，帮助学生建立“由本义推引申”的方法论，而非死记义项；
• 古籍检索：以义项而非字形为粒度建索引，支持“检索‘行’字‘道路’义的用例”这类语义级查询。

这些场景共享同一份字级知识库，边际成本低、复用价值高，这正是“以字为本”策略在经济性上的优势。

六、结语

“因字而生句，积句而成章，积章而成篇”——古人的写作规律，同样是机器理解古籍的处理次序。把“一个字为什么会有这些意思、意思之间如何派生”这条链路数字化、结构化，不仅能让消歧、翻译、检索更准，也让古汉语学习本身多了一件工程化的脚手架。对开发者而言，这是一块投入不大、方法论清晰、却能托举所有上层应用的基建，值得在项目早期就认真规划。