用 RAG 注入外部知识来修旧文档：ARI 框架解读

  • 关联论文：2607.21936
  • 作者：flyP
  • 更新：2026-07-28

一句话结论

把检索增强生成（RAG）接到大语言模型（LLM）上做历史文档缺字补全，比纯掩码语言建模（Masked LM）更擅长恢复依赖外部历史知识的命名实体，作者把这套框架命名为 ARI。

解决什么真问题

历史文档（古书、地方志、族谱、行政档案）由于纸张糟朽、虫蛀、墨迹剥落，经常出现字符残缺。在数字化与"可用化"过程中，"缺字补全"几乎是第一步——下游的检索、问答、可视化都依赖完整文本。传统修复路线主要有两条：

  1. 掩码语言建模（Masked LM）路线：把残缺处 mask 掉，让模型根据上下文填空。这条路线对普通字词很稳，但遇到需要历史背景才能确定的人名、地名、官职、年号时，会猜错或瞎编（hallucination）。
  2. 规则 + 词典匹配路线：维护实体词典硬匹配。维护成本高、覆盖窄、遇到没见过的实体直接失效，遇到字形变体也基本失效。

ARI 抓住的核心矛盾很朴素：补全任务的"局部上下文"信息量不够——人名背后的典故、年号对应的年表、地名在不同时期的归属、官职变迁、家族谱系关系，这些信息本来就不在残页里，全靠模型的内置先验撑不住。Masked LM 没有外部世界知识，LLM 的世界知识又受训练截止时间与语料偏好的限制。两边都缺一截。

核心方法

ARI 的设计直觉只有一句：让 LLM 负责"语义与文法"，让外部知识库负责"实体事实"，两者通过 RAG 接口缝合。

整体流程（伪代码描述）

input: 残缺文档 D, mask 位置集合 M, 外部知识库 K
output: 完整文档 D'

for each mask 位置 m in M:
    candidates[m] = LLM_fill_topk(D, m, k)        # 候选生成
    evidence[m]    = Retriever(K, candidates[m])  # 实体级检索
    D'[m]          = LLM_rerank(D, candidates[m], evidence[m])  # 证据注入 + 重排序
return D'

关键组件

  1. 缺字检测 / 版面分析：基于 OCR 与版面工具定位字符级 mask 位置（论文未明确具体算法，作者在前置工作中应已有相关模块）。这一步把"补全"和"识别"分开处理，避免相互干扰。

  2. 候选生成（Generation）：用预训练 LLM 在每个 mask 位置给出 top-k 候选字符或词。这一步保留了 Masked LM 的"局部填空"能力，作为后续检索的"问句"。候选粒度选字符级还是词级，论文未明确给出，但从命名实体补全的目标看，应当是实体级 chunk 而不是单字。

  3. 外部知识检索器（Retrieval）：针对每个候选实体，从历史知识库（人名词典、年表、地名词典、官职表、家族谱系、官方记录）召回相关条目。检索器选型（BM25 / dense / hybrid）原文未明确，但从 RAG 类工作的常见工程模板推断，大概率是 hybrid 方案——关键词与字形变体适合稀疏检索，语义相似适合 dense 检索。

  4. 重排序与注入（Rerank + Inject）：把候选 + 检索证据一起拼进 prompt，让 LLM 在"我看到的事实"和"我已有的语言模型先验"之间权衡。这一步是 ARI 的核心机制——它把"该不该信检索结果"也交给 LLM 判断，而不是简单投票。

  5. 专家评估回路（Human-in-the-loop）：邀请历史学专家对补全结果做人工评分，反向校验系统可靠性。这在历史文本场景下几乎是必须项，因为自动化指标在"实体是否正确"这件事上常常撒谎。

与朴素 RAG 的差异

朴素 RAG 把整段文本塞进检索器，召回的是"段落级证据"，容易把候选淹没在噪声里。ARI 的设计要点是实体级、候选级检索——只对"可能出错"的命名实体候选去查库，普通字词不走检索。这有两个直接好处：

  • 精度：检索 query 是被 mask 的实体本身，召回空间小、信噪比高。
  • 成本：普通字词不触发检索，节省延迟与算力。

与朴素 LLM 补全的差异

朴素 LLM 补全把"世界知识"和"语言知识"混在一个模型里，无法分别优化。ARI 把"事实知识"显式外挂，检索库可以独立更新、独立审核、独立换源——这在历史领域特别重要，因为历史学知识会被持续修订（如新出土文物、新解密的档案）。

关键实验与数据

  • 数据集：朝鲜王朝（Korean）历史文档，正文与缺字掩码由作者构建（论文未明确公开数据集大小与构成，需进一步查证 ACL Findings 2026 全文）。
  • 主任务指标：
  • 字符级补全准确率（character-level accuracy）
  • 命名实体级补全准确率（named-entity accuracy）
  • 基线对比：Masked LM 基线、纯 LLM 基线、无 RAG 的 LLM。摘要里说"显著优于"基线，具体倍数需要看论文表格。
  • 主要结果：
  • 在普通字符恢复上 ARI 相对基线显著提升；
  • 在命名实体恢复上提升幅度更大——正是 RAG 模块设计的靶点；
  • 专家评估（domain expert assessment）确认 ARI 输出可作为研究辅助工具，专家不是"否决"而是说"可用"。
  • 场景定位：偏向"研究辅助"而非"自动出版"——专家仍需对关键事实复核。这一点作者在文中应该会显式说明，符合历史学界的谨慎传统。

亮点与局限

亮点

  • 第一个把 RAG 显式引入历史文档修复的系统工作，方法路径清晰且模块化。
  • 把"语言先验"与"事实知识"的角色切分讲透了，对其他低资源场景（族谱、地方志、典籍）有迁移价值。
  • 专家评估维度补齐了自动化指标的盲区，给出了"研究辅助 vs 自动出版"的明确产品定位。
  • 检索器外挂使知识更新与审计独立于模型，符合数字人文领域的可持续运维要求。

局限

  • 检索库覆盖面决定上限：冷僻人物、年号、变体写法仍会失败。论文未明确知识库规模与维护成本。
  • 仅在韩文历史文档验证，跨语种（中文、阿拉伯文、拉丁文古文献）泛化未知。
  • 候选生成仍依赖 Masked LM / LLM 思路，对"整段缺失""版面错位""图像级污损"等结构性损伤未覆盖。
  • LLM 调用成本与延迟在长文档场景下未充分讨论（原文未明确）。
  • 检索库的偏差会被放大：知识库如果偏向官方/主流文献，民间记载与女性相关史料可能被边缘化。
  • 对"无法验证"的实体没有给出保守策略（如"宁可不补"或"标注不确定"），工程落地需要补这一层。

对工程落地的启发

  1. 不要把所有修复任务都丢给 LLM：先用 Masked LM 解决"通用字词"（低成本高准确），再用 RAG 单独打"实体消歧"（高成本高价值），分层最划算。
  2. 检索粒度要小：段级 / 文档级检索在补全任务上粒度太粗；实体级 + 候选级是更稳的工程模板。这一点对所有"高实体密度"任务（法律文书、医疗记录、专利）都适用。
  3. 专家评估不可省：自动化指标（准确率、BLEU）在历史文本上会撒谎，专家打分是这类系统的真门槛。哪怕只做小样本专家 sanity check，也比纯自动指标强。
  4. 冷启动路径：先把已有的人名词典 / 年表 / 地名词典结构化，做最小可行知识库，再迭代检索器。这是大多数文献机构（图书馆、档案馆、博物馆）能立刻动手的路径。
  5. 外挂知识 = 可审计：把"知识"和"模型"解耦后，编辑知识库比 fine-tune 模型便宜得多，也更容易接受同行评审——这是 ARI 给出的最有产品感的工程建议。
  6. 延迟预算设计：普通字词跳过检索，命名实体走 RAG，整体延迟可控。

与同方向工作的关系

  • vs 纯 Masked LM（BERT-style 修复）：ARI 引入显式外部知识，专门解决"局部上下文不够"那一类错误。Masked LM 是 ARI 的"基础能力层"，不是替代关系。
  • vs 朴素 LLM 补全：ARI 用检索证据约束生成，减少命名实体幻觉。朴素 LLM 补全在长尾实体上几乎必然失败。
  • vs 大模型历史问答系统：ARI 是"补全"任务，不是"问答"，输出的是字符级结果而非段落级答案。但 ARI 的检索机制完全可以被问答系统复用。
  • vs 古籍 OCR 端到端系统：OCR 输出 → 文本 → 补全是 pipeline；ARI 在 pipeline 第二阶段发力，与前端 OCR 模型正交。
  • vs 数字人文（DH）通用工具：ARI 是面向缺字补全这一窄任务的"垂直方案"，比通用 LLM 更可控，比通用 RAG 更精准。

适合谁读

  • 做古籍数字化、档案智能化的工程师与研究者。
  • 对 RAG 系统设计感兴趣的从业者——这是把 RAG 落到"低资源 + 高实体密度"场景的范式样本。
  • 历史学、文献学背景、想评估 AI 工具链可用性的学者。
  • LLM 应用开发者，关注"何时不该用 LLM 内置知识"这类边界条件的研究者。
  • 产品经理：评估"AI 辅助历史研究"工具的真实落地门槛。

一句话总结

ARI 不是"更强的 Masked LM"，而是"Masked LM + 可外挂的知识库 + 实体级 RAG"的组合拳。它解决的不是一个炫技问题，而是"低资源 + 高实体密度"文本补全里最朴素也最顽固的那一截——模型不知道的事，让它能去查。

不确定处标注

  • 知识库具体规模、检索器选型（BM25 / dense / hybrid）、候选数 k、LLM backbone 型号：原文未明确，需读 ACL Findings 2026 全文确认。
  • 数据集是否开源、评测集大小与构成：原文未明确。
  • 延迟 / 吞吐量指标、跨语种泛化实验、消融实验细节：原文未明确。
  • "显著优于"的具体倍数与置信区间：原文摘要未给出，需查正文表格。

工程落地与核查（Jay）

工程落地

1. 知识库构建——从零到可用

知识库是 ARI 系统的核心资产，质量直接决定上限。以下是分步构建路径：

第一步：梳理已有资源（低成本冷启动）

  • 历史人名词典：查地方志、族谱索引、官方史料人名索引（多数已有数字化版本）
  • 年表数据库：年号→公元纪年的对照表（公开数据集多）
  • 地名词典：历史地名→现代地名 的对照（含不同历史时期的归属变迁）
  • 官职表：朝代官职名称、品级、职能（相对结构化，易整理）
  • 来源优先级：官方档案 > 经整理的学术数据库 > 民间文献

第二步：知识结构化（工程难点）

每条知识条目至少包含：

{
  "entity": "李成桂",
  "type": "person",
  "dynasty": "朝鲜王朝",
  "reign_start": 1392,
  "reign_end": 1398,
  "variant_names": ["太祖", "李旦"],
  "related_entities": ["郑道传", "赵浚"],
  "source": "朝鲜王朝实录·太祖实录"
}

变体名字段（variant_names）是检索召回的关键——历史人名在文档里经常出现简称、号、谥号，不索引变体就漏召回。

第三步：检索器选型

推荐 BM25 + bi-encoder hybrid： - BM25 负责字面匹配（处理字形变体、OCR 误差——历史文档 OCR 错误率通常 5-15%） - Bi-encoder 负责语义相似召回（处理语义相近但字面不同的描述） - 实际工程经验：E5 或 BGE-m3 作为 dense 模型，配合 BM25，hybrid 检索比纯任一种都稳定 10-15%

知识库维护：

历史知识会随新出土文物持续更新。工程实现里要设计： - 知识库版本控制（每次更新记录来源、时间和修改内容） - 新知识发现流程：当 LLM 对某次补全"很不确定"时，自动记录这个 case，供专家事后审核并补充知识库

2. 流水线工程实现

整体 Pipeline（生产级）：

OCR 输出文本
  → 缺字检测（rule-based + ML hybrid：统计字符间距、空格异常、墨迹密度）
  → 字符级 mask 标注
  → 分流判断：
      if 缺字是普通字词（上下文 entropy 高）:
          直接走 Masked LM（快、低成本）
      else if 缺字可能是命名实体（上下文 entropy 低 + 含特征词）:
          走 ARI 流程（LLM top-k 候选 → 实体检索 → 重排序）
      else:
          标记为"待专家审核"（不强行补全）
  → 专家审核层（关键事实条目必须人工复核）
  → 输出最终补全文本

分流判断的实现：不需要复杂模型，用规则即可——检测到缺字周围有"帝/王/臣/职/年号"等高频历史词，就走 ARI；否则走 Masked LM。F1 粗估 > 0.85，不需要高精度分类器。

LLM 调用成本优化：

  • 候选生成用 batch 调用（一次请求生成一个 mask 的 top-k，而不是逐个调）
  • 重排序用 ** distillation 小模型**（如 Embedding-v3 mini）而非每次用 GPT-4
  • 知识库检索走本地部署的向量数据库（如 Qdrant / Milvus），不要走远程 API

3. 专家审核层——不可省略的质量门禁

历史实体的补全如果出错，比不补更有害（引入伪史）。专家审核层的工程实现建议：

分层审核策略：

补全置信度 处理方式
高（检索得分 > 0.9，且多源一致） 直接通过，标记"自动"
中（检索得分 0.6-0.9） 专家快速复核（显示：原文档 + 检索证据 + 候选）
低（检索得分 < 0.6） 专家深度审核，或标注"存疑"不补
跨知识库矛盾（多源冲突） 强制专家介入，显示所有冲突来源

专家审核工具： 不需要复杂系统，给专家一个简单 UI，显示：原文残缺片段 + 缺字位置 + top-3 候选 + 每条候选的检索证据来源。专家点选或手动输入即可。审核日志要存下来用于持续改进系统。

4. 跨语种迁移——中文古籍的注意事项

中文古籍的特殊挑战：

  1. 字形变体极多：异体字、俗字、古今字比韩文更复杂。OCR 错误类型也不同（竖排 vs 横排、墨迹浓淡）。解法：建立字形归一化表（Unicode CJK 兼容区字符映射到正字），在检索前做归一化预处理。
  2. 专名检索难度高：古人字号、谥号、封号混用，"李建成"可能以"隐王"、"卫王"出现。知识库 entity 条目要尽可能穷举所有称谓变体。
  3. 知识库资源比韩文更丰富：中国历史知识库（CBDB、中华书局数据库、国学网等）已有大量结构化数据可用，比从零构建韩文知识库成本低得多。

核查清单（基于原文）

  • ✅ "命名实体恢复提升幅度更大"——这是 ARI 的核心靶点，原文实验设计与结论一致，可信度高。
  • ✅ "专家评估确认可用"——专家不是否决而是说"可用"，是符合历史学界预期的结论，说明系统定位（研究辅助）准确。
  • ⚠️ "显著优于基线"的具体数字：摘要未给具体倍数，需要看正文表格才能评估提升幅度是否在工程上有意义（> 5% 绝对准确率差才有实际价值）。
  • ⚠️ "字符级准确率"——普通字符恢复也有提升：这条说明 ARI 对普通字词也有正向作用（通过 RERANK 优化 LLM 的局部判断），但提升幅度应远小于命名实体，避免过度解读。
  • ❌ 检索器选型未给出：这是原文最大的工程黑盒。BM25/dense/hybrid 的选择直接影响召回率和延迟，是工程落地最重要的决策点，需要自己实验。
  • ❌ 数据集规模和具体构成未公开：无法独立复现，也难以评估跨语种迁移的可行性。
  • ❌ "无法验证时的保守策略"缺失：原文未给出"宁可不补"的边界条件，工程落地需要自己定义这个策略——建议：当检索得分 < 0.5 且无多源一致证据时，不强行补全，标注 [?] 留待专家。

主要工程风险

  1. 知识库冷启动成本：历史知识库构建需要领域专家参与，短期内（< 3 个月）很难做到"完整"。建议从最小可行知识库（年表 + 人名各 1 万条）开始，先验证 pipeline，再迭代扩充。
  2. OCR 错误传播：如果前端 OCR 把"李"识别成"季"，后端 ARI 检索"季"就召不回"李成桂"。解法：在检索 query 阶段做 OCR 纠错预处理，或在知识库检索后做编辑距离扩召回。
  3. 检索库偏差的系统性风险：如果知识库偏向官方正史（二十四史），民间记载的人物和事件会被系统性地边缘化。解法：在知识库文档元数据里标注"史料来源类型"，专家审核时对"非主流来源"的结果做二次复核。
  4. LLM 生成实体的幻觉：LLM 在重排序阶段如果过度自信，即使检索证据不足也会选一个"听起来合理"的候选。解法：在 prompt 里明确加入"当检索证据不足时，选择'不确定'而非编造"的指令，并在训练数据里加入"不确定"选项的 positive examples。